Webサーバ監視の管理基準書を作ってみよう：障害対応マニュアルを作成しよう（3）

» 2003年10月23日 00時00分公開

　システムの管理や障害の対応は魔法ではありません。たとえどれほどスキルの高い優秀なエンジニアが管理しても、ただそこにいるだけで即座にシステムの障害を検知して対応できるわけではありません。システムで発生する障害を早期に検知するためには、常にシステムを監視し、稼働状況を確認して閾（いき）値と比較し続ける必要があるのです。

　今回は、システム管理者がどのようにシステムの障害に対応するのか、その監視運用の基準の策定をシステムを想定して具体的に解説することにしましょう。

Webサーバの監視を想定する

　検知された障害に適切に対処するには、障害を切り分けて原因を究明する必要があります。つまり「何が原因で障害が発生したのか」を確認するわけですが、障害の原因がクリティカルになるほど、その障害を切り分けるエンジニアのスキルも高いレベルが要求されます。

　この段階で障害対応マニュアルに規定しておきたい事項を確認します。

どのような監視を設定するか
監視・運用スタッフの配置をどうするか
検知した障害をどのように通知するか
だれ（どのチーム）が障害を切り分けるか
だれ（どのチーム）が障害対応をするか
障害対応後の報告はどうするか

　これらの内容はシステムの管理基準書として文書化しておきます。

　さっそく、管理基準書に記載する事項を順を追って検討してみることにしましょう。もちろん監視設定はシステムの目的や重要度などによって異なりますので、今回はWebサーバの監視を想定してみることにしましょう。

効果的な監視項目を設定してみる

　実際の管理基準書にはシステムの詳細図、コンテンツの詳細な目的、監視対象のIPアドレス、ホスト名などシステムの詳細な情報を記述する必要がありますが、ここでは監視の概要だけを抜き出してみます。

１．監視対象システムの目的

　　自社の企業情報、製品情報、サポート情報、イベント情報などを顧客（あるいは将来顧客になる可能性のある人）向けに配信します。

２．監視項目

　　今回は次の4つの監視項目を設定します。

「トップページが参照できる」ことを稼働の最低限の状態と規定して、実際のトップページのURLを用いてコンテンツアクセスによる監視を15分置きに実行します。ページの表示が完了するまでのタイムアウトは3分、それまでにページが表示されなければ（あるいはエラーが返ってきた場合には）障害と判断して通知します。
Getしたコンテンツの内容が正しいかを確認します。本来の内容とは異なるデータだった場合には、ページが改ざんされていると判断して通知します。
エラーログの容量を5分置きにチェックし、前回のチェック時よりも急激に容量が増加した場合には警告を通知します。
ディスク残容量のチェック。ディスクの残容量が10％以下の場合には警告を通知します。

　例に挙げた監視で検知できるのは、何らかの理由でコンテンツアクセスができない障害、ページの改ざん、必要以上に大量のエラーが発生、許容範囲を超えるディスクの残容量減少です。もちろん、これらの監視範囲以外で障害が発生する可能性もあります。しかしどれだけ監視項目を多く設けたとしても、障害が絶対に発生しないシステムがないのと同じように、すべての障害をチェックできる完ぺきな監視も実現はしません。

　そのため、管理者はシステムの目的、重要度、予算などを検討したうえで、最も効果的な監視を設定する必要があります。今回はWebコンテンツに正常にアクセスできている間は、取りあえずこのシステムの役割は果たされていると判断することにします。

　非常に重要度の高いシステムであれば、もっと詳細な監視設定をすることになります。例を挙げるとキリがありませんが、主な監視項目としてエラーログやアクセスログに特定のログが記録された場合の警告、パフォーマンスの著しい低下や向上の警告、特定のプロセスの暴走や消失の警告などの監視などが考えられます。

2名×3交代でのルール

　運用スタッフの配置は、システム管理の中で最もコストの掛かるポイントです。システムの管理にどれだけ予算を割くことができるのかは、次の2点から検討することになります。

そのシステムが稼働していることで得られる利益
そのシステムで障害が発生した場合の損失

　1に関していえば今回は「企業の顔」ともいえるWebサーバの管理ですから、その宣伝効果などが1の利益となります。また製品についてのFAQなどを掲載することで、サポートの費用を軽減する効果も得られると考えます。問題は2による損失をどのように見積もるかです。

　今回の例では情報を配信する“静的”なWebサイトを想定していますので、システムがダウンしたために発生する損失は、重要な情報の通達の遅延、企業の信頼度の低下、宣伝効果の減少といった程度です。ところが、これがほかの企業から委託されたシステムであったり、通信販売などの“動的”なWebサイトである場合、システムがダウンすることではっきりと数値で表すことのできる損失が発生します。

　これらの状況を踏まえたうえで、安定した利益を得ながら損失を最小限に食い止めるために捻出することのできる管理コストを計算します。システムの管理コストから人件費として避ける割合と、その限られた予算の中でできる最も質の良い管理方法はどのようなものなのかを検討します。

　監視ツールからの警告をリアルタイムで確認する1次ラインオペレータ2名で編成されるチームを、3交代で24時間常駐させることにします。基本的に8時間勤務で、途中1時間ずつの食事休憩とお手洗いなどの小休止を交代（2名同時に席を離れないことが条件）で取ります。チーム交代時には、2チームの4名全員がそろった状態で引き継ぎを行います。

「障害チケット」で障害をもれなくつぶす

　監視ツールから障害が検知された場合（あるいはユーザーやオペレータが目視で障害を検知した場合）には、1次ラインオペレータは権限が許す範囲で、どのような障害が発生しているかを確認します。このとき「障害チケット」をオープンします。この障害チケットは、1度の障害につき1つ発行され、障害対応が完了するとクローズされます。各チケットにはチケットIDを割り当て、複数の障害が発生している場合でも、どの障害についての対応（あるいは通知）なのかが分かるようにしておきます。

　検知された障害が1次ラインオペレータの作業範囲で切り分けられなかった場合、その障害は2次ラインオペレータへとエスカレートされます。今回の例では2次ラインオペレータは常駐の義務はありませんが、やはり3交代での待機を義務付けます。エスカレートの連絡があった場合には、30分以内に対応できる状態になることを条件にします。また、2次ラインオペレータの待機中の飲酒などは禁止します。

　2次ラインでも切り分けられないほどクリティカルな障害が発生した場合には、3次ラインにエスカレートされます。今回はこの3次ラインが最終ラインとなります。スキルの高いエンジニアがこの任に就くことになりますが、1次および2次ライン同様に、1人ではなく複数の人間が交代で対応できる状態にしておきます。同時に休暇などを取ることがないよう調整が必要になります。

オペレータ同士が障害を伝え合うのは“会話”

　基本的に監視ツールが検知した障害は、1次ラインオペレータのコンソールへのアラートと、関係者全員へのメールで通知されます。このときに障害のチケットがオープンされます。ユーザーやオペレータが何らかの障害を検知した場合にも、手動で障害チケットをオープンします。

　オペレータの障害対応記録はすべてログとして記録されますが、状態が変化した場合にはチケットIDと併せて同じように関係者全員にメールで通知します。

　ただし、1次ラインから2次ライン、あるいは3次ラインへのエスカレートは、メールと電話（近くにいる場合には口頭）の両方で行なってください。メールは相手がリアルタイムで読んでいる保証がなく、遅延などが発生することもあるため不確実要素が大きいので、必ずオペレータ同士が会話によって障害のエスカレートを通知するように義務付けるべきでしょう。

だれがどこまで対応していいのか

　1次ライン、2次ライン、3次ラインで、システムをどこまで操作できるのかを事前に規定しておく必要があります。これはそれぞれのラインに所属するオペレータの技術スキルに依存します。そのため、各ラインでは技術レベルを一定以上の水準に維持しておく必要があります。

　実際の障害の切り分けと障害対応方法については、今回作成する管理基準を基に作成される「障害対応マニュアル」に記述されます。この部分については次回の記事で実際に作成される障害対応マニュアルで詳細に解説したいと思います。

障害対応の無駄や無理を検討

　障害対応完了後は、関係者全員にメールで通知したうえで、障害チケットをクローズします。今回はメールだけで対応完了の通知を終了するように規定しますが、システムのダウン時間などが長引いた場合には、ユーザーなどへも報告が必要となるため、電話で主要な関係者に連絡が必要となる場合もあります。事後報告などは、臨機応変に対応できるように日ごろから関係者の連絡先をすぐに分かる場所に置いておくようにします。

　また、障害対応ログは必ず残すようにしてください。また、関係者は定期的にミーティングを行い、障害の対応方法に無駄や無理がないかなどを、具体例とともに報告して今後の改良に役立てる必要があります。

障害の切り分けと復旧、どちらが先決？

　マニュアル化することが困難な事項として、クリティカルな障害が発生した場合に、障害の切り分けとシステムの復旧のどちらを優先するかという問題が挙げられます。障害によってはすぐに原因が究明できないこともありますが、障害の根本原因をはっきりさせて対処しなければ、また同じ障害が発生してしまうことは大いに考えられます。

　しかし、システムのダウンがあまりにも長時間になってしまう場合には、障害の切り分けを断念して「とにかくシステムを再稼働させる」ことが最優先事項になることもあります。これらの見極めは非常に難しく、技術サイドが現状で把握できる情報を基に、経営サイドが判断することもあります。

TCOに見合った管理基準

　経営者の中にはシステム管理コストがTCO（Total Cost of Ownership）に占める割合を低く見積もっている方も多いのですが、システムの重要度が増すほどに、管理コストがTCOに占める割合は増えていきます。特に重要度の高いシステムでは、人件費が管理コストの大半を占めることはよくあることです。この現状を正しく認識したうえで、システム管理の予算に見合った管理規準を作成することが大切になります。

　今回作成した管理基準は、管理基準書として文書化しておく必要があります。実際の管理基準書にはシステムの詳細な情報も記載されるために、管理基準書の扱いには注意が必要となります。ただし、管理基準書は障害対応マニュアルとは異なります。管理対応マニュアルは、この管理規準を基に障害発生時に各オペレータがどのように対処したらいいのかについて記述されます。次回はいよいよ今回作成した管理基準から障害対応マニュアルを作成することにします。

「次回」へ

「障害対応マニュアルを作成しよう」バックナンバー