新連載：障害対応マニュアルを作成しよう
（1）
〜いざというときに備える〜
システム障害に対応する、とは？
北原静香
2003/7/4
この連載を開始するに当たって、読者の方には「悪いニュース」と「いいニュース」を伝えなければなりません。まず悪いニュースですが、現在稼働しているシステムは、どんなに堅牢に作成されたシステムであっても障害が発生する可能性があります。そしていいニュースの方は、それらのシステム障害をあらかじめ予測して被害を最小限に食い止めることができるということです。
この連載では「システムには障害が発生する」ということを前提として、障害をいち早く検知する方法や、障害が発生した場合の対処方法などについて解説します。しかし、発生した障害への技術的な対応方法や、障害原因の切り分け方法などはもっと詳細なほかの技術解説記事に譲ることにして、ここでは「システムの障害時にスタッフはどのように行動するべきか」に注目してみることにしましょう。
 |
ダウンしたときの痛手∝資産価値 |
システム障害を検知して対応するというのは「システムの運用・管理」の一部です。ではシステムの運用・管理とは何でしょうか？
ネットワークシステムとは資産の集合体です。そのためシステムの運用・管理とは、資産を運用・管理することと同じであると考えてください。
ところが、システム管理には管理コストが掛かります。最も大きな支出はシステム管理者の人件費ですが、そのほかにもシステム監視に掛かる費用、予備機の維持費、修理代などさまざまな支出があります。もちろんこれらのシステム管理コストは、システムの維持費として計上されるべき支出ですが、管理費用を含めたシステムの維持費が、そのシステムを維持することによって得られる利益を超えるべきではありません。つまりシステムを管理するためのコストには、おのずから限界があるわけです。
では、どのようにしてシステムの管理コストの限界を見極めたらいいのでしょうか？
|
重要度から管理コストを算出 |
システムの資産価値は、そのシステムの重要度に比例します。つまり、そのシステムが稼働していることで得られる利益が大きいほど、システムの重要度も高くなるのです。ただし、ネットワークシステムは、正常に稼働している状態でなければ本来の資産としての価値を持ちません。それどころか規模の違いはあってもシステムは存在するだけで管理コストなどを発生させるため、障害の発生しているシステムはそれだけで自分たちに損害を与えているといってもいいでしょう。システムの構築に掛かった費用なども併せて考えると損害はさらに大きくなります。
ところがシステム管理者の多くは、そのシステムがどれほどの資産価値を持っているかを正確に認識していません。ただ漠然と「このシステムの重要度は高い」とか「このシステムは絶対に必要」と思っているシステム管理者は、実際の障害に遭遇した場合にどこまで対処していいのか正しく判断できずに損失を最小限に食い止められないことがあります。そのシステムから得られる利益をハッキリと認識して、どこまで管理コストを掛けていいのかを判断できるようにしておく義務があるのです。
|
目的を明確にするための3項目 |
システムの重要度は、その目的から検討します。本来そのシステムから得られる利益は、構築時に稟議などの形でハッキリさせているものです。しかし、拡張を繰り返したり当初の目的から別の目的に移り変わるなどした場合には、システムの資産価値は変化します。まず次の事柄を検討してみましょう。
- そのシステムが提供するサービスは何か？
- それぞれのサービスを利用するユーザー数と利用時間は？
- サービスを利用したユーザーから得られる対価は？
サービスを利用したユーザーから得られる対価というと、外部に向けてサービスを提供するシステムに限られるように思うかもしれません。しかし、社内システムであってもこの原則は同じです。このときに得られる対価とは、社内スタッフの作業の効率化（場合によっては福利厚生などかもしれませんが）です。つまりそのシステムが稼働していることによって、間接的に自分たちに利益があるわけです。また実際に形として表れない技術的信用度や宣伝費なども検討する必要があります。
このようにしてそのシステムから得られる利益を明確にすることで、システムの重要度もはっきりします。サービスの単位で検討することによって、システム内のサーバの重要度や障害対応の優先順位なども明確にすることができます。
|
損失の大きさを知る |
システムの目的を明確にすることで、そのシステムがダウンしている間に失われる利益も明確になります。しかし、実際の損失はそれだけではありません。
例えばメールサービスがダウンした場合を考えてみましょう。メールサーバを社内に設置して10人の営業スタッフが顧客とのやりとりをメールで行っている場合、メールサーバがダウンしていることをすべての顧客に通知し、急ぎの用件がないかを確認するなどの作業が必要になります。このときの電話料金や、その作業に追われている間にできなかったほかの作業などは失われた利益以上の損失です。また、障害の検知が遅れたり、連絡がつかなかった場合には、さらに大きな損失が出る可能性もあります。社内のサーバが使えないために代替手段として外部のメールサービスを利用するスタッフがいるかもしれません。
さらにそのシステムのサービスを外部の顧客に対して提供しているような場合、損害賠償などが発生することもあります。お客さまが必要なときに必要なデータが提供できない、あるいはお預かりしているデータを破損してしまうといった致命的な障害など検討するべき事柄はたくさんあります。とはいえ、外部の顧客に対してサービスを提供している場合には、契約時に障害時の保証などを明確にするのが普通ですから、これらの障害時の損失を算出するのは比較的楽かもしれません。
一番問題なのは、自社のシステムが原因で別のシステムに損害を与えてしまった場合です。例えばウイルスに感染したことに気付かずに、自分たちのシステムからほかのシステムを攻撃してしまうなど想定できる状況はいろいろあります。最悪の場合には、損害賠償を請求されてしまうこともあります。しかし、ある程度以上の規模のシステムでなければ、実際にここまで検討することはほとんどといっていいほどありません。ただし、このようなケースも起こり得るということは覚えておいた方がいいかもしれません。
|
掛けられる費用はいくらまで？ |
システムから得られる利益とダウンによって発生する損失を検討したら、次にそのシステムに掛けられる維持コストを検討します。システムの維持コストの原則は「そのシステムから得られる利益を超えない」です。システムがダウンすることによって発生する損失が大きい場合には、一時的に障害対応で管理コストが利益を上回ることもあるかもしれません。しかし、あくまでも「一時的」であることが重要です。常に利益を超える管理コストの掛かるシステムを維持することはナンセンスです。
システムの維持コストには、分かりやすいコストと分かりにくいコストがあります。機材の保守費用、インフラコスト、ハウジングコストなどははっきりと数字に出る分かりやすいコストといえます。一方分かりにくいコストとして、技術スタッフの人件費などが挙げられます。契約社員やアルバイトのスタッフの場合にはそうでもないのですが、なぜか技術スタッフが社員の場合、コスト計算があいまいになる傾向があります。特に勤務時間に対する考え方に問題があるようで、コストを下げようとするあまり超過勤務になることが多いようです。
しかし、24時間×365日稼働し続けるシステムを管理しようとするのであれば、管理・運用スタッフの勤務時間をあいまいにするべきではありません。超過勤務によって集中力が維持できなくなるなど、時間によってクオリティに差が出るようではシステムの管理者として不適格です。それぞれのスタッフの勤務時間は、常識の範疇を超えないことを前提に検討しなければなりません。
システムの規模が大きくなってくると、管理・運用を外部の運用代行サービスに依頼した方がコストを抑えられることもあります。実際技術者の人件費は高いので、アウトソーシングは前向きな解決方法ですが、しかしあくまでもシステムの管理・運用の方針を決定するのは自分たちであることを忘れてはいけません。障害が発生した場合に、きちんと連絡を受けてどのような対応がされるかを確認できる技術スタッフは社内に残しておくべきでしょう。
|
障害発生時の復旧範囲は？ |
システムに何かの障害が発生した場合、状況を改善するためには障害を切り分ける必要があります。しかし、すぐに原因を特定できる場合とできない場合があります。しかし、システムの重要度が高ければ高いほど、サービスを利用できない時間の損害は大きくなるため、障害の切り分けに十分な時間を割くことができない場合もあります。ユーザーにとって障害の原因は問題ではありません。ユーザーにとって最も重要なことは、早急にサービスが利用できるようになることなのです。
例えばネットワークの疎通が確認できない障害が発生した場合、どうして疎通が途絶えたのか原因を究明するよりも、「どことどこの間の疎通が途絶えているのか」を確認してリブートしたり、機材を交換するといった対処でシステムを早急に復旧するのは普通の対応でしょう。しかし、この症状が頻発している場合には、やはり根本的な原因を究明しなければならなくなります。その場合、システムの管理者は現状の暫定的な対処と、ユーザーの少ない時間に根本的な対処を計画的に作業する方向で検討しなければなりません。このようにシステムの管理者は、障害の検知から復旧までの状況を判断して、障害の規模や深刻さから損失を最小限に抑えるように努める必要があります。
|
考えられる障害のタイプ |
システム障害がどのように発生するかは、原因が多過ぎてすべてを予測することはできません。しかし、障害の症状を系統化することで、障害の対処方法をある程度までは系統立てることができます。そこで、システム障害の症状を次のように分類してみましょう。
- 疎通が確認できない
- サービスが利用できない
- パフォーマンスの急激な低下と上昇
- ファシリティのトラブル
もちろん実際に発生した障害を切り分けるにはもっと詳細に系統立てる必要がありますが、ここでは少し大ざっぱに考えてみることにしましょう。
ネットワークの疎通が確認できない
最も発見しやすいシステム障害は、ネットワークの疎通断といえるでしょう。障害の発生ポイントによっては発見が遅れることもありますが、システム内のユーザーの多くが利用する外部とのゲートウェイや、グループウェアなどとの疎通が途絶えると、障害がユーザレベルでも認知されます。
システム管理者は疎通が途絶えているポイントとその原因を究明し、疎通を回復するか回避策を提供する、あるいは復旧できない旨を通知して対策を講じる必要があります。
サービスが利用できない
Webやメールなどのサービスが利用できない状態です。サービスを提供するサーバへの疎通断が発生すれば自動的に発生する障害ですが、pingなどに応答するにもかかわらずサービスが利用できない状態になることもあります。主にサービスを提供しているサーバの障害が原因ですが、途中の経路や、同じネットワーク内の別の障害が原因で発生する場合もあります。
システム管理者はどのサービスが利用できないのか、なぜ利用できないのかといった原因を究明し、早急にサービスを復旧するか、あるいは復旧できない旨を通知して対策を講じる必要があります。
パフォーマンスの急激な低下と上昇
比較的検知が遅れる障害として、システムパフォーマンスの低下と上昇があります。Webサーバなどアクセスが集中してパフォーマンスが低下することもありますが、これは比較的発見しやすい障害といえます。しかし、それよりも問題なのはパフォーマンスが急激に上昇した場合です。一見するとパフォーマンスが向上するのはいいことのようにも思えますが、特別な理由もなくシステムのパフォーマンスが向上するのは、そのサービスへのアクセス経路のどこかにトラブルが発生している可能性を示唆しています。サービス稼働をシステムの内部からのみ監視していると、これらの障害がなかなか発見できないことがあります。
システムパフォーマンスの低下は必ずしも早急に応対しなければならない障害ではないことも多いのですが、ウイルスやハッキングなどのアタック、大きな事件などによるアクセスの集中によって急激にパフォーマンスが低下した場合には、何らかの措置を取らなければならない場合もあります。また、パフォーマンスの急激な向上は、致命的なシステムの障害の可能性があるので、このような状態を検知した場合にはシステムのどこかに障害が発生していないかを確認する必要があります。いずれにせよ、システム管理者は常に管理しているシステムのパフォーマンスの適正値を認知しておかなければなりません。
ファシリティのトラブル
インフラ障害や停電などファシリティのトラブルが発生した場合、すぐに回避策を講じられないことがほとんどです。UPSなどでかろうじて電源を維持できたとしても、外部のトラブルが原因の障害は復旧のめどを立てることも困難です。できることといえばデータのバックアップを確実に取り、どうしても必要であれば別の場所に暫定的な代替システムを稼働させたりします。
このようなトラブルが発生した場合、システム管理者は速やかに関係者と連絡を密に取って、現状の把握と関係者への情報伝達に努めなければなりません。普段からシステムの目的と重要性を認知しておけば、どうしてもシステムの停止が避けられない場合にどこのだれに連絡すればいいのかがすぐに把握できるはずです。
|
重要なものは投資して、そうでないものはそれなりに |
今回はシステムの運用・管理の観点から、システムの障害に対応するとはどういうことなのかを解説しました。システム管理者（あるいはシステム管理グループ）は、普段からシステムの目的と重要度を把握し、障害が発生した場合にシステム管理者はそれぞれの重要度に応じた対処が重要になるということを覚えておいてください。
次回はシステムの障害発生に備えて、普段からどのようにシステムを監視し、スタッフをどのように配置するかといった事柄について触れたいと思います。
|