真新しいサーバーをインストールするか、システムのバックアップ実行手順の文書を記述するかの選択を迫られた場合、平均的なシステム管理者は毎回新しいサーバをインストールするでしょう。これはまったく珍しいことではありませんが、システム管理者が実行することは文書化しなければなりません。多くのシステム管理者がさまざまな理由を付けて必要な文書化を後回しにしています。
残念ながら、"後でやりますから"は正しくありません。システム管理者が楽観視しているわけではなくても、通常、日常業務などの性質は、"後でやる"には忙しすぎるからです。さらに、放置しておくほど、多くのことを忘れてしまい、文書化の詳述性に欠けることになります(従ってあまり役に立たなくなる)。
写真のように詳細な記憶を持てるような希少な人でない限り、すべては覚えていないはずです。最悪の場合、半分しか覚えていず、全体的なことを忘れているのに認識していないことです。このため、忘れてしまったことを思い出すため、または状況理解の不足で壊してしまったものを修復するために余計な時間がかかることになります。
しばらくの間は効果があるかもしれませんが、これはポジションを保証するのではなくいずれ必ず危険にさらす結果となります。緊急事態が発生した際のことを想像してみてください。自分はそこに居合わせないかもしれません。自分がそこにいない場合に、あなたが作成した文書があれば他の人が問題を解決して助かる可能性があります。また、緊急事態の発生は管理上層部の注意を引く機会となることを忘れないでください。この場合、自分がいなかったことが問題の一部となるのではなく、あなたが文書化したものがソリューションのひとつとなる方がよいはずです。
また、まだ小規模だが急成長している企業なら、最終的にもう一人システム管理者が必要となるでしょう。すべてのことが自分の頭に記憶されている場合、もう一人のシステム管理者はバックアップの方法をどうやって知ることができるでしょう。文書化しないということは自分が不可欠の存在となる可能性があり、昇進がかなわなくなるかもしれません。自分をアシストするために雇用したその人のために働くことになるかもしれません。
これでシステムの文書化の利点が理解できたと思います。それでは、管理者は何を文書化するのでしょうか。ここにいくつか例をあげます。
ポリシーとは、企業内のユーザーとの関係を正式に確認し明確にするために記述されます。ユーザーのリソースやヘルプの要請がどのように処理されるかユーザーに対して明確にします。ユーザー全体に対するポリシーの普及方法、スタイル、特性は企業によってそれぞれ異なります。
手順とは特定の作業を達成するために必要とされる段階的な一連の動作です。文書化される手順にはバックアップ手順、ユーザーアカウントの管理手順、問題報告の手順などが含まれます。自動化と同様、手順が複数回続く場合には文書化した方がよいでしょう。
システム管理者の職務の大半が変更の作業の繰り返しです — 最大パフォーマンスを得るためのシステム設定、スクリプトの微調整、設定ファイルの変更、などです。これらの変更すべては特定の様式で文書化される必要があります。さもないと、数ヵ月前に行った変更などと完全に混同してしまうかもしれません。
変更の履歴を保存するために複雑な方法をとっている企業もありますが、ほとんどの場合、必要となるのはファイルが変更される時点での改訂歴だけです。最小限、改訂歴には次の各エントリが入っていなければなりません。
変更を加えた人の名前、またはイニシャル
変更が行われた日付
変更が行われた理由
次のようなエントリは簡潔な上に役に立ちます。
ECB, 12-June-2002 — 会計部門のプリンタを新しい機種に更新(両面印刷機能に対応するため)