8.1.1.1.1. 技術を習得する

過去にどのくらいの経験があったか、ハードウェアについての知識などにより、技術の習得はそれほど問題にならないかもしれません。しかし、ハードウェアに関する経験がない場合は、PCの修復についての予備コースを専門学校などで習得するのもいいでしょう。こうしたコースは企業レベルのサーバに関する問題に取り組む管理者には十分とは言えませんが、基本を学ぶには有効な方法です(ツールやコンポーネントの適切な取り扱い方法、基本となる診断方法など)。

	ヒント
	まず修復作業に取りかかる前に、ハードウェアについて次のことを確認します。 ハードウェアの保証期間内かどうか サービス/メンテナンスなどの契約期間内かどうか 保証またはサービス契約で補償されているハードウェアの修復を自分で試みる場合、こうした契約条件に違反し、その保証またはサービス契約の適用範囲を無効にしてしまう可能性があります。

しかし、交換するハードウェアを適切に選べば、最低限の技術であっても障害を起こしているハードウェアを調査して交換することができるかもしれません。

8.1.1.1.2. 予備のハードウェア

予備のハードウェアについては、災害からの修復関連におけるさまざまな側面を考慮する必要があります。次のような事項に気をつけてください。

• 許容できる最長ダウンタイム

• 修復作業に必要とされる技術

• 予備に費やせる予算

• 予備の保管に必要とされる保管スペース

• 同じ予備を利用できる他のハードウェア

各事項それぞれが用意しておくべき予備の種類と関連性があります。例えば、フルセットで予備のシステムを保管すると、ダウンタイムを最小限に抑えるのでインストール技術も最低限ですみますが、予備の CPU と RAM モジュールだけを保管しておくよりずっと費用がかかります。しかし、1台のシステムを予備にすることで利便となるような数十台の同一サーバを保有している企業や組織なら、この経費も価値があるでしょう。

いずれにしても次の問題は避けられないので解説していきます。

8.1.1.1.3. 予備とはならない予備

予備が予備ではないとはどういう状況を指すのでしょうか。日常的に使用しているハードウェアであるけれど、優先度の高いシステムに必要性が生じたときに予備として使用することができる状況のことです。この方法をとると次のような利点があります。

• "生産的ではない"予備にかかる経費の軽減

• このハードウェアが動作することがわかっている

ただし、この方法にはマイナス面もあります。

• 優先度の低い通常の稼働作業が中断される

• 優先度の低いハードウェアに障害が起きたときにダメージがある(優先度の高いハードウェア用の予備がなくなる)

こうした制約を考慮して、別の実稼働システムを予備として使用するのは有効かもしれませんが、この方法の成否はそのシステム特定の作業負担量やシステムの欠落によるデータセンター全体の業務に及ぼす影響にかかってきます。

8.1.1.2.1. 適用範囲

異なるニーズに合う各種のサービス契約があります。各種の契約で変動の大きいもののひとつが適用範囲に関連しています。特権に対する契約料金を払わない限り、電話をするといつでも技術者がすぐに駆け付けてくれるということは期待できません。

代わりに、契約内容によっては特定の日/時間までサービス会社に電話することさえできないかもしれないし、できたとしてもサービス会社は契約に指定されている日/時間まで技術者を送りません。

ほとんどの適用範囲は技術者が送られる時間と曜日について定義されています。一般的な適用範囲をいくつかあげておきます。

• 月曜日から金曜日、09:00 — 17:00

• 月曜日から金曜日、12/18/24 時間対応(合意に基づいた開始及び終了時間)

• 月曜日から土曜日 (または、月曜日から日曜日)、上記と同時間の対応

ご存知かもしれませんが、契約コストは適用範囲によって増加していきます。一般的に、月曜日から金曜日までの適用範囲は、土日を含む適用範囲より低コストになる傾向です。

しかし、ここでもシステム管理者としていくつかの作業を自発的に行なう気があれば経費を軽減できる可能性があります。

8.1.1.2.1.1. 引き取り修理サービス

標準的な営業時間以外で技術者の派遣を必要としない状況でありシステム管理者に何が壊れたのか判別できる十分な経験があれば、引き取り修理サービスについて考慮してみてもいいでしょう。さまざまな名称(ウォークインサービス、ドロップオフサービスなど)で知られるこのサービスは、メーカーがサービスデポを持ち、技術者が顧客から持ち込まれるハードウェアの修理作業を行なっていることがあります。

引き取り修理サービスには迅速な対応という利点があります。技術者が送られ現場に到着するまで待つ必要がありません。デポの技術者が顧客からの電話を受けて現場へ向かうのではなく、顧客がハードウェアをデポに持ち込み次第、修理作業にとりかかれる技術者がいるということです。

引き取り修理サービスは集中センターで行なわれるため、必要となる部品の用意がある可能性が高いと言えます。その部品の予備が在庫に入ったばかりの別の支店から翌日到着で発送させたり、クーリエで取り寄せる必要がなくなります。

しかしトレードオフがいくつかあります。最も明らかなのはサービスの時間帯を選ぶことができないことです。デポが開いている間にサービスを受けることになります。また、技術者は退社時刻を延長して作業はしないため、金曜日の16:30 に障害が発生してそのシステムをデポに 17:00 に持ち込んだ場合、技術者が翌週の月曜日の朝に出社するまで修理作業は行なわれません。

また、デポが近くにあるかどうか、オフィスの所在地が都市部である場合にはさほど問題にはなりませんが、地方の場合にはデポまで長距離を運転していくことになるかもしれません。

	ヒント
	実際にハードウェアをデポまで移動する運搬方法を考慮に入れておきます。会社の車両を使用するのか、それとも自分の車を使用するのか。自分の車を使用する場合には、ハードウェアを積み込むのに必要なスペースや収容力があるのか。保険についてはどうなっているのか。運搬に複数人数が必要か。 ありきたりなことですが引き取り修理サービスを利用するか決める前に考えておく必要があります。

8.1.1.2.2. レスポンスタイム

適用範囲に加え、多くのサービス契約はレスポンスタイムのレベルを指定しています。つまり、電話をかけてサービスを依頼したときに技術者が到着するまでにどのくらいかかるでしょうか。ご想像の通り、レスポンスタイムが早いほどサービス契約は高額になります。

レスポンスタイムには限度があります。例えば、メーカのオフィスから顧客のところまでの移動時間は可能なレスポンスタイムに大きく関連してきます [1]。4 時間以内のレスポンスタイムは通常、早い方の対応だとされています。これより遅いレスポンスタイムは 8 時間(事実上、標準営業時間契約の"翌日"サービスになる)から 24 時間の範囲になります。他のサービス契約事項と同様に、レスポンスタイムも相応の価格で交渉が可能です。

	注記
	よく起こることですが、レスポンスタイムの条項があるサービス契約ではメーカのサービス機関の応対能力を超えて拡大されていることがあることを知っておく必要があります。非常に忙しいサービス機関は契約レスポンスタイムを守るためにレスポンスタイムが短いサービスの依頼に対してはとりあえず誰かを — 誰でも構わない — 送るというのは聞いたことがないこともありません。どうやらこの人が問題を診断して「オフィス」に電話をかけ「適切な部品」を誰かに持って来させるようです。 実際には、この人は入ってきた依頼を処理できる人を待っているだけということになります。 特別な状況ではこうしたことが起こることも理解できなくはありませんが(サービスエリア全体のシステムに影響している電力の問題など)、これが一貫した営業方針であるならサービスマネージャに連絡をとり説明を求めるべきでしょう。

レスポンスタイムに緊急性が必要であれば(あわせて予算も増大する)、レスポンスタイムをさらに短縮できる方法がひとつあります — レスポンスタイム無し。

8.1.1.2.3. パーツの入手可能状況

明らかに、パーツの入手が可能な状況はハードウェア障害に対して企業のダメージを食い止める大きな役割を果たします。サービス契約の文脈では、パーツの入手可能状況がもうひとつ別の範囲となり、パーツの入手可能状況はその顧客に対してだけでなく同じパーツを同様に必要とする可能性があるメーカの守備範囲の他の顧客にも利用されます。自分の会社より多くのハードウェアをそのメーカから購入している会社があればその会社の方がパーツの入手(及び技術者)に関して優先的な扱いを受けるかもしれません。

残念ながら、サービスマネージャに相談する以外にはこうした状況の場合できることはほとんどありません。

8.1.1.2.4. 利用できる予算枠

前述したように、サービスの契約は提供されるサービスの性質によって値段が異なります。サービス契約関連のコストは繰り返し発生するものであることに留意してください。契約期限が切れる度に新規の契約を協議して支払う必要があります。

8.1.1.2.5. サービスが適用されるハードウェア

コストを最小限に抑えるために役立つ点をここにあげます。24x7 のオンサイト技術者、オンサイトのスペア(指定したもの)が含まれるサービス契約について協議していると考えてみます。このベンダから購入したハードウェアはすべて適用範囲に入ります。重要度がそれほどは高くない作業を行なうのに会社の受け付けで使用する PC もこれに含まれます。

この PC は本当にオンサイトで 24x7 体制で誰かが必要でしょうか。この PC が受付での作業に非常に重要であったとしても、受付営業時間は 09:00 から 17:00 の間だけです。次のような状況はあまりありません。

• 17:00 から翌朝の 09:00 までの間にこの PC が使用される (週末以外)

• 09:00 から 17:00 までの時間帯以外で、この PC の障害発生に気づく

したがって、この PC が土曜日の真夜中に修理を必要とする可能性にコストをかけるのはムダです。

重要性が高くない作業をするためのハードウェアは重要性の高いハードウェアとは別にグループ分けするなどサービス契約を分割します。このように、コストをできるだけ低く抑えることができます。

	注記
	設定が全く同一になされたサーバが 20 台あり、会社にとって極めて重要な作業を行なっている場合、1 台か 2 台に高レベルのサービスを適用し、その他はずっとコストが低いものを適用するようなサービス契約にしたい誘惑に駆られるかもしれません。すると、週末にサーバのどれが障害を起こしても、そのサーバが高レベルサービスが適用されるサーバだと言えるわけです。 これはしないでください。不正であるばかりでなく、ほとんどのメーカはシリアル番号でこれらを追跡しています。こうしたチェックを回避する方法を見つけたとしても、あとで発覚した結果、正直に本当に必要としているサービスの対価を支払うよりもはるかに多額の出費となります。

8.1.2.1.1. クラッシュ

クラッシュはオペレーティングシステムが回復できないエラー状態になると起こります。クラッシュの要因はハードウェアにある障害を処理できない場合からオペレーティングシステムを構成するカーネルレベルのコードでのバグまでさまざまです。オペレーティングシステムがクラッシュした場合、稼働を続行するにはシステムの再起動が必要となります。

8.1.2.1.2. ハング

オペレーティングシステムがシステムのイベント処理を停止すると、システムは停止状態になるまで稼働し続けます。これがハングと呼ばれます。ハングはdeadlock(リソースを消費している2 つが相手の持つリソースを争うこと)とlivelock(複数のプロセスがお互いのアクティビティに応答しているが有益な動作を行なっていないこと)によって起こりますが、これらの結果は同じで、生産性がまったく失われます。

8.1.2.3.1. ドキュメント

見落とされがちですが、ソフトウェアのドキュメントはレベル 1 サポートツールとして役に立ちます。オンラインのドキュメント、印刷されているものいずれにしても、多くの問題を解決するために必要とされる情報がよく含まれています。

8.1.2.3.2. セルフサポート

セルフサポートはソフトウェア関連の問題の解決にオンラインリソースを使用する顧客向けです。Web ベースの FAQ (よくある質問)やナレッジベースなどの形態をよくとります。

FAQ には選択機能がないことが非常に多く、自分の問題に該当する質問を見つけるためにひとつづつ質問を見ていかなければなりません。ナレッジベースはもう少し高度に作られていることが多く用語検索の入力ができます。また、ナレッジベースは非常に広範囲で問題を解決するのに役立つツールとなります。

8.1.2.3.3. Web または電子メールによるサポート

セルフサポートに似た ウェブサイトには多くの場合 Web ベースのフォームや電子メールアドレスがあり、サポートスタッフに質問を送信できるようになっています。一見、有益なセルフサポートウェブサイトの改良版に見えるかもしれませんが、実際にはこの電子メールへの回答者によります。

サポートスタッフが過剰労働になっている場合、サポートスタッフにとっては各電子メールに迅速に対応して次の問い合わせに移行するのが主な関心事になるので、必要な情報を得るのが難しくなります。ほぼすべてのサポートスタッフは解決した問題の件数で評価されるためです。特に、自分の問い合わせを読んでいるサポートスタッフが次の問い合わせに進もうと急いでいる場合など、タイムリーで有益な対応を求めるには電子メールだけではほとんど何もできないため、問題をエスカレートするのも難しくなります。

最適なサービスを受けるには、サポート技術者が聞いてくるであろうすべての質問事項を電子メールに明記します。

• 問題の性質を明確に記述する

• 関連のバージョン番号をすべて明記する

• 問題に対処するためすでに試みたことを記述する(最新のパッチを適用した、最小限の設定で再起動をした、など)

詳細な情報をサポート技術者に提示することで、必要としているサポートを得ることができる可能性が高くなります。

8.1.2.3.4. 電話サポート

名前の通り、電話サポートとは電話でサポート技術者と話すことです。サポートが可能なレベルがさまざまであることなど(適用範囲が異なる、レスポンスタイムなど)、このスタイルのサポートはハードウェアサポートとよく似ています。

8.1.2.3.5. オンサイトサポート

オンサイトコンサルティングとも呼ばれ、通常、オンサイトソフトウェアサポートは最初のソフトウェアインストール及び設定、主要なアップグレードなど、特定問題の解決や重大な変更に限られています。予想できる通り、これがソフトウェアサポートの種類の中でも最も高価なサポートになります。

しかし、オンサイトサポートが合理的である例もあります。例として、システム管理者が 1 人しかいない小規模の企業を考えてみます。この企業が初めてデータベースサーバの設置を計画していますが、設置(及びこの企業)にはデータベース専任の管理者を雇用するのに十分とは言えない規模です。こうした場合、滅多に使用しない技術についてシステム管理者にトレーニングを受けさせるより、データベースベンダからスペシャリストを呼んで最初の設置(及び、後日に必要性が発生したら臨時的に)を任せた方がコストを抑えることができる場合が多いことがあります。

8.1.3.2.1. 電源の確保

まず、通常の電力供給がどのように確保されているか確認することが必要になります。ほぼすべてのデータセンタと同様に、恐らく送電線経由で地元の電力会社から電力を得ているはずです。このため、主要な電力供給が可能な限り安定した状態であることを確保するためにできることは限られています。

	ヒント
	電力会社の境界線近くに位置する会社などは 2 種類の電力供給網への接続を交渉できるかもしれません。 自分のエリアに供給している電力供給網 隣接する電力会社からの電力供給網 隣接の電力供給網からの配線に関連するコストはかなり大きく、大企業向けだけに限られたオプションになります。しかし、こうした企業でも多くの場合この冗長性を確保するのはコストがかかりすぎるという結果になります。

確認する主な点は、社内への配線と建物への配線方法です。送電線は地上配線と地下配線のどちらになっていますか。地上配線は次のような事項に影響を受けやすくなります。

• 荒天候による被害(氷雨、暴風、雷)

• 交通事故による電柱や変圧器の破損

• 迷い込んだ動物などによる電線ショート

ただし、地下配線にも独特の短所があります。

• 工事中に誤った場所を発掘したことによる被害

• 洪水

• 雷(地上配線に比べるとかなり少ない)

建物内へ引かれている電線をたどってみてください。最初に外部変圧器に行っていますか。車両が誤って追突したり、木が倒れてこないよう保護されていますか。露出しているすべての遮断スイッチが許可なく使用されないよう保護されていますか。

建物内に入ったら、電線(または電線が取り付けられているパネル)が他の問題に影響を受けやすくなっている可能性はないですか。例えば、配管による問題で配電室に浸水する可能性はないですか。

データセンタへの配線を調べて行きます。電源供給に予定外に割り込みしているものはないですか。例えば、データセンター以外と回線を共有していませんか。共有しているようならその外部からの負荷によりある日、回線のオーバーロードプロテクションが働いて、データセンターも一緒にダウンしてしまうことになるかもしれません。

8.1.3.2.2. 電力の質

データセンタの電力源が可能な限り確保されていることを確認するだけでは十分ではありません。データセンタ全体に配分される電力の質にも注意する必要があります。次のような要素に注意します。

電力会社から直接提供される電力は通常データセンタに必要とされる標準には合致しません。したがって、普通はある程度の電力調整が必要とされます。いくつかの手段をあげておきます。

最後の 2 つの技術に関しては、電力について(バックアップ電力)考慮するときにほとんどの人が思い付く点です。次のセクションでは、バックアップ電力の各種供給方法について説明していきます。

8.1.3.2.3. バックアップ電力

ほとんど誰しもが聞いたことのある電力関連用語のひとつに停電があります。停電とは電力を完全に失うことで、瞬時で復旧することもあれば数週間続くこともあります。

停電の長さは多岐に渡るため、停電の長さによって異なる技術を利用しバックアップ電力を供給する作業を行なう必要があります。

	ヒント
	最も頻繁に起こる停電は平均では数秒以内です。これ以上長い停電はあまり頻繁には起きません。したがって、所要時間にして数分のみの停電に対する保護にまず専念します。それから、これより長い停電時間に対するダメージを軽減する方法を考えていきます。

8.1.3.2.3.2. 数分間の電力を供給する

単一の低価格帯 PC を 5 分間維持するのに十分な小さいサイズのものから、データセンタ全体に 1 時間以上の電力を供給するに十分な大きなサイズのものまで、さまざまなサイズの UPS を購入することができます。

UPS は次のようなパーツから構成されています。

• 切替えスイッチ、主要供給電力からバックアップ電力への切替えを行なう

• バッテリー、バックアップ電力を供給する

• インバータ、バッテリーからの DC 電流をデータセンタのハードウェアが必要とする AC 電流に変換する

ユニットのサイズやバッテリーの容量とは別に、UPS は基本的な 2 つのタイプになります。

• オフライン UPS は主要供給電力が停止するとインバータを使って発電します。

• オンライン UPS はインバータを使って常に発電していて、主要供給電力が停止したときだけバッテリーでインバータに電力供給します。

それぞれのタイプには長所と短所があります。オフライン UPS はインバータが常時稼働している構成である必要はないため、通常はさほど高額にはなりません。しかし、オフライン UPS のインバータの問題は発見されにくいという短所があります(停電が起きるまでわからない)。

オンライン UPS はデータセンタにクリーンな電力を供給するという点では優れていますが、常時、発電し続けています。

使用する UPS のタイプに関わらず、予測される負荷に対して UPS の正しいサイズを決定しなければならず(このため、必要とされる電圧及び電流で発電するために十分な容量が UPS にあることを確認)、また、バッテリ電力でデータセンタを維持できる時間を決定する必要があります。

この情報を確認するには、まず UPS が供給する負荷を確認します。それぞれの機材のところまで行って、それぞれの消費量を確認します(通常、ユニットの電源コードのあたりにあるラベルに記載)。電圧、ワット数、アンペア数を書きとっておきます。ハードウェアすべての数値を書きとったら、これらをVA(ボルト・アンペア)に換算します。ワット数がある場合は記載されているワット数を VA として使用できます。アンペア数がある場合は、ボルト数を掛けて VA を算出します。これらの VA 数を足すと UPS に必要なおおよその VA 定格を割り出すことができます。

	注記
	厳密に言うと、この方法は VA 算出法としては完全には正しくありません。しかし、真の VA を割り出すには各ユニットの電力要素を知る必要があり、この情報はまず提供されていません。いずれにしても、この方法で得た VA 数は最悪の場合の値を反映していますので、かなり余裕があります。

ランタイムに関してはハードウェアよりも業務的な側面を考える必要があります。どの種の停電に対して対応しようとしているのか、どの程度のコストを見積もっているのか。ほとんどの場合、対応対象としているランタイムは 1 時間から最大でも 2 時間以内です。これを超えるとバッテリのバックアップ電力にかかるコストが非常に高くなるためです。

8.1.3.2.3.3. 数時間(及び数時間以上)の電力を供給する

数日に及ぶ停電となるとさらにコストがかかってきます。長期に及ぶ停電に対応できる技術は主にある種のエンジン(ディーゼルやタービン)で動かす発電器に限られてきます。

	注記
	エンジンで動かす発電器は稼働中に定期的に燃料補給が必要となることに留意してください。発電器の最大燃焼率を知っておきそれに応じた燃料を配達してもらうよう手配する必要があります。

企業の資金が十分であるとすればさまざまなオプションが考えられます。また、ここは企業に最も適したソリューションを判断するために専門の人の手助けが必要となるところです。この種の電力発電システムの購入と設置プランを立てるために必要な専門知識を有するシステム管理者は極小数に限られます。

	ヒント
	あらゆるサイズの携帯発電器は借り出すことができ、購入に必要な初期の出費をすることなく発電器による電力を得ることができます。しかし、災害が近辺一帯に発生した場合は貸し出し発電器の供給が不足するため非常にコスト高になります。

8.1.3.2.4. 停電の延長に備える

5 分間の停電でオフィスのライトが消えスタッフが作業をするのに不便だとすれば、停電が 1 時間続いた場合はどうでしょうか。あるいは、5 時間、1 日中、1 週間の長さに及んだら。

実際には、データセンタが通常に稼働していても停電が延長すると最終的には企業にある程度影響を及ぼします。次のような点を考慮にいれてください。

• データセンタ内の環境を維持する電力がなかったら?

• 建物全体の環境を維持する電力がなかったら?

• 各自のワークステーション、電話システム、電灯を機能させている電力がなかったら?

要するに、企業全体としてどこまでが停電の延長に耐え得る限界かを判断しなければなりません。あるいは、その余地が全くない場合には、停電が続く間、完全に独立状態のオンサイト電力を機能させることができるよう再考する必要が出てきます。つまり、建物全体に電力を供給するためにはかなり大規模の発電器が必要になるということになります。

当然、このレベルのプランでさえ孤立状態では行なうことができません。何が原因であれ停電の延長はその企業だけでなく周りにも影響していて、たとえ無制限に電力を発電できたとしてもこれが企業の運営維持に影響し始める可能性が非常に高くなります。

8.1.4.1.1. アプリケーションの間違った使用

アプリケーションが誤って使用されるとさまざまな問題が起きることがあります。

• うっかりファイルを上書きしてしまう

• アプリケーションへの入力に不適切なデータが使用される

• ファイル名が明確に付けられず不適切な構成になる

• 偶然ファイルを削除してしまう

まだまだ続きますがこの辺でいいでしょう。ユーザーにはスーパーユーザーの特権がないため、たいていの間違いはユーザー自身のファイルに限定されます。得策としては次の 2 つにわかれます。

• アプリケーションの適切な使用方法及びファイル管理のテクニックについてユーザーを教育する

• ユーザーのファイルのバックアップを必ず定期的に作成し、できるだけ合理化した復元作業で迅速に行なえるようにしておく

この他にユーザーのエラーを最小限に抑える術はほとんどありません。

8.1.4.2.1. 手順書に従わない場合

オペレータは文書化された手順書を自分が行なうそれぞれの動作のほぼすべてに対して持っていなければなりません [3] 。決められた手順にオペレータがしたがっていないことがあるかもしれません。これには何か理由があるはずです。

• 過去に環境が変更されたことがあり、そのときに手順書が更新されなかった。今回、再び変更があったため、オペレータが記憶している手順書は役に立たなくなった。この時点で、手順書が更新されたとしても(以前に更新されなかったという事実に基づけば更新される可能性はあまりない)オペレータはその存在を知らない。

• 環境が変更されたが手順書が存在していない。以前の状況よりさらに統制がとれない状態が悪化する。

• 手順書があり内容も正しいが、オペレータが手順書に従わない(従えない)。

社内の管理者側の構成により、該当のマネージャと懸念事項を相談することしかできない場合があります。いずれにしても、その問題解決に役立つことでできることを行動に移せる状態にしておくのが最適な手段です。

8.1.4.2.2. 手順に従っている間に起きる間違い

たとえオペレータが手順書に従っていても、また手順書の内容が正しくても、間違いが起こる可能性はあります。間違いが起こった場合は、オペレータに不注意があった可能性があります(この場合、オペレータの管理者側が関与する必要があります)。

別の言い方をすれば単に間違いがあったということです。こうした場合、優秀なオペレータなら何かが間違っていることに気づき救援を求めます。一緒に作業しているオペレータに対しては、何か間違いに気づいたらすぐに適切な人に連絡をとるよう常に奨励しておきます。多くのオペレータが高度な技術を持ち多くの問題を自分で解決できる能力がありますが、それはオペレータの仕事ではありません。また、さらに事態を悪くするのは、もともとは小さな問題であったかもしれないことを迅速に解決することができなかっために、その人の経歴とシステム管理者の能力に傷をつけてしまうことになりかねません。

8.1.4.3.1. 誤設定によるエラー

システム管理者にはさまざまな側面からコンピュータシステムを設定する必要性がよく発生します。こうした設定には次のようなものがあるかもしれません。

• 電子メール

• ユーザーアカウント

• ネットワーク

• アプリケーション

設定はまだまだあります。実際の設定作業はテキストファイルの編集が必要なものから(数百もの異なる設定ファイル構文のひとつを使う)、設定ユーティリティを実行する必要があるものまでさまざまです。

こうした作業はすべて処理が異なるということは、各設定作業によりそれぞれ異なる知識が必要になるという基本的なことに加えさらに作業を難しくしています。例えば、メール転送エージェントを設定するために必要とされる知識は新規ネットワーク接続を設定するために必要とされる知識とは根本的に異なります。

これらのことを考え合わせると、実際に起きる間違いがいかに少ないか驚かされることでしょう。いずれにしても、システム管理者にとって設定は現在もこれからもやりがいのある作業と言えます。では、その工程にエラーが起こりにくくする方法はないでしょうか。

8.1.4.3.2. メンテナンス中に起きる間違い

通常、日常的なメンテナンスにはほぼプラン立てや追跡を行なわないためこのタイプのエラーは気づかないことがあります。

システム管理者はこの種のエラーによる結果に毎日のように接しています。特に、何もしていないのにコンピュータが壊れたと断言する多くのユーザーによるものです。このように言うユーザーはたいてい何をしたか覚えていません。次回、同じことが起こった場合にシステム管理者として今度はあなたが何をしたか覚えていないかもしれません。

注意すべきことは、いずれの問題でも迅速に解決できるようになるためにはメンテナンス中に行なった変更を覚えておくことができなければなりません。一日の中で小さな作業を数百も行なう場合に 1 つの大がかりな変更管理プロセスは現実的ではありません。システム管理者が毎日行なう 101 の作業記録をつけていくにはどうしたらいいでしょうか。

答えは簡単です。メモをとります。ノートでも、PDA でも、影響を受けたファイルの中にコメントを残す形でも構いませんからメモをとっておきます。何を行なったかを追跡記録することで、最近行なった変更に関連する障害を発見する可能性が高くなります。

8.1.4.4.1. 修理が不適切だったハードウェア

この場合、技術者が問題を正しく診断できずに不必要な(またムダな)修理を行なったか、診断は正しかったが修理がきちんと行なわれなかったかのどちらかです。交換パーツ自体が不良品である場合もあるし、修理過程で正しい手順がとられなかった場合もあります。

このため、常に技術者が行なっていることを把握しておくのが重要になります。これにより、何らかの形でオリジナルの問題に関連すると思われる障害について注視しておくことができます。問題がある場合には技術者がその問題に対して正しく作業できるようにします。これを怠ると、技術者がこの障害は新しいもので恐らく修正済みのものとは無関係だとみなしてしまう可能性があります。このようにして、間違った問題を追いかけて時間を浪費しないようにします。

8.1.4.4.2. 一ヶ所修正すると別の所が壊れる

ときどき、問題が診断され正しく修理が完了しても、別の問題が出現することがあります。CPU モジュールを交換したのに、届いた帯電防止用バッグが棚に置きっぱなしだったためファンを遮り高温のためシャットダウンしてしまった。RAID アレイ内の障害が発生したディスクドライブを交換したのに、別のドライブのコネクタがぶつかって偶然に切断されてしまいアレイがダウンしたままになっている。などです。

こうしたことは慢性的な不注意により起こる場合もあれば単純な間違いの場合もあります。いずれにしても、システム管理者として行なわねばならないことは、常に技術者が行なった修理を注意深くチェックし、技術者がその場を離れてしまう前にシステムが正しく機能することを確認するということです。