「早期検知と迅速対応」ポリシー策定への道障害対応マニュアルを作成しよう(2)

» 2003年08月20日 00時00分 公開
[北原静香@IT]

 連載「障害対応マニュアルを作成しよう」の1回目『システム障害に対応する、とは』では、「システムの障害に対応する」の意味をお話ししました。いざというときに備えることが、システム管理の一部であること、また、システム管理コストは、そのシステムが稼働していることで得られる利益と密接にかかわっているということがお分かりいただけたでしょうか。

 そこで、今回は管理コストを念頭に置いたうえで、実際のシステム障害にどのように備えるべきかについて解説しましょう。

障害を早期に検知する

 システムの障害を早期に検知するには、常にシステムの状態を監視している必要があります。そこでの問題は、システムの「何を」「どのように」監視するか、です。

 システムの監視に掛かるコストは、監視するポイントや頻度などで大きく異なります。ただし、システムの管理コストはシステム稼働によって得られる利益を超えることは許されません。必然的に監視できる内容には限界があるため、損益で決定される管理コストの限界を理解したうえで、最も効率の良いシステム監視を実行することが重要になります。

常時、一定の間隔でシステム状態をチェックする

 システム監視は定常的に自動化された処理です。つまり常に一定の間隔でシステムの状態をチェックする必要があるわけです。システム監視は基本的には人間(オペレータ)が手作業でチェックするわけではありません。もちろんオペレータが手動でコマンドを実行したり、あるいはシステムを構成しているハードウェアを目視で確認することもありますが、管理コマンドを実行するマクロの実行や、システム監視ツールの利用が一般的なシステム監視の方法です。もちろん実際に障害を検知した後は人間が対応しなければならないのですが、定期的なpingやポートへの接続確認などのコマンド、システムリソースの確認などは、自動化する方が手動で確認するよりも正確で安価です。

 少し例を挙げて監視のコストを考えてみましょう。実際に数分置きにシステムの稼働を確認するためにpingコマンドを実行することを想定してみてください。24時間×365日のシステム稼働中、常に手動でコマンドを実行するには、1人あたり8時間担当の3交代制の最少人数を想定しても3人以上のオペレータが必要です。もちろん彼らはコマンドを実行して、その結果を理解する能力がなければなりません。人手によるpingコマンドで監視するとなると、人件費だけでも1年間で1000万を超えるコストが掛かるわけです。年間にこれだけの管理コストが掛けられるシステムであれば、システムの詳細な情報を定期的に確認し、データとして記録できるような質の高い自動監視ツールによる「システム監視」を実行する方が前向きです。

 ただしシステム監視のマクロやツールは、指定された処理しか実行しないため、複合的な原因によって発生する障害が発見できないこともあります。多少検知が遅れても問題にならない障害もありますが、大抵の場合1つの障害の検知が遅れることによって、より重大なシステム障害に発展します。発生した障害が致命的であるほどシステムの管理スタッフや、さらにはシステムのユーザーが目視で障害を発見することになります。

 その場合、障害を検知してから対応するまでの時間が重要になります。対応できない時間が長くなればなるほど、より障害の重大性が増す可能性が高いからです。ツールなどで自動的にシステム監視を実行する場合であっても、決してツールに任せて放置したままにはせずに、システム管理者は常にシステムの状態に気を配っておくことが大切です。リソースのグラフや、エラーログなどをこまめにチェックするように普段から心掛けるようにしたいものです。

ツール任せにしない、できない

 システムの何を監視するのかに関しては、明確な回答はありません。システムの監視ポイントは無数にあり、そのうちのいずれを選択するかはシステムの用途、規模、重要度などによって大きく異なります。とはいっても、実際に監視ツールなどで監視できる状況はそう多いわけではありません。システム監視のポイント「どのような障害を検知したいのか」は次のように分類することができます。

1.稼働監視

 システムを構成している機器、サービス、プロセスなどが正常に稼働しているかを監視します。システムの稼働監視では、処理がリクエストされてから終了するまでの時間もチェックして、システムのパフォーマンスも同時に確認します。リクエストされた処理が一定の時間内に終了しない場合、監視対象が正常に稼働していないと判断できますが、逆に通常状態よりもパフォーマンスが著しく向上した場合にも、システム内のどこかがダウンしていると考えることができます。

 機器の稼働監視は、pingコマンド(ICMP)などで死活を監視したり、SNMPトラップなどで機器の状態異常がないかを確認します。SNMPトラップによる機器の監視は、その機器がどのような情報をトラップとして通知できるかによって監視できる内容が異なります。

 サービスの稼働監視は、そのサービスのポートへの接続が確立できるかを確認したり、実際にサービスを利用して一定時間内に正しい結果が返ってくるかを確認します。例えばHTTPサービスの稼働監視を例に取ると、一定の時間内に特定のHTTPページが表示されるか、表示された内容に改ざんされた形跡はないかなどを確認します。

 プロセスの稼働監視は、任意のプロセスが正しい個数で、正しく稼働しているかを確認します。

2.トラフィック監視

 ネットワークのトラフィックの流量を確認したり、スループットなどを計測します。継続してトラフィックを監視していると、いつごろにどれくらいのトラフィックが発生するのかをデータとして蓄積できます。この数値データを基準にして、トラフィック流量の監視の閾値を決定し、閾値を著しく上回る、あるいは著しく下回る結果が確認された場合、何らかのトラブルが発生していると判断して、その原因を特定して対処します。

3.システムリソース監視

 システムリソースの監視では、HDD(ストレージデバイス)、CPU、メモリなどのシステムリソースの利用状況を確認します。突発的にシステムリソースが著しく消費されている場合には、システムに何らかの障害が発生したと考えるのが普通です。

 また、通常の状態であっても、HDDなどのストレージデバイスの使用量は、大量のデータの損失を招くことがあるため常に残容量に余裕が必要です。常時、容量がギリギリの状態であれば、HDDを増設するなどの処置が必要になります。

 CPUやメモリの使用量はシステムパフォーマンスに影響します。常に限界まで使用されてシステムのパフォーマンスが低下しているようであれば、システムに何らかの改善が必要であることが確認できます。

4.その他の監視

 エラーログやアクセスログも障害を検知する重要な監視ポイントです。一時的に大量のログが記録されたり、エラーログなどに致命的なシステム障害を示すログが記録されるかもしれません。そのためログファイルの著しい容量変化、致命的なログなどを定期的にチェックします。

 また、ファイアウォールなどを導入して、システムセキュリティを常にチェックするのもシステム監視の一部です。ただし、今回の連載はシステム障害と対応についての解説ですので、システムのセキュリティ保全に関しては、より詳しい解説記事に譲ることにしようと思います。

 1〜4のような監視ポイントが考えられるのですが、これらのシステム監視を実行することで、パフォーマンスなど監視対象システムのデータが蓄積します。これらのデータは今後のシステムのマイグレーションを検討するうえで非常に有効な情報となりますので、監視データは残すようにしましょう。

監視データを有効に利用するための通知方法

 監視ツールなどを利用してシステムの稼働を監視する場合、検知した障害をどのような形で管理者に通知するかが問題になります。24時間×365日システム管理者が常駐しているような場合には、管理者の使用している端末に向けて障害をアラートすればいいのですが、管理者が常駐できない場合には工夫が必要です。

 一般的な障害のアラートはSMTPなどメールの機能を利用しての通知です。通常のアドレスにはもちろん、最近では携帯電話のメールに送信することも多いようです。ただし、メールはリアルタイムで読まれる保証はどこにもありません。特に携帯電話のメールは遅延することがよくあるため、確実性の低い通知手段といえます。

 さらにダイヤルアップによるページャーへの通知、自動音声などによる電話への通知などの方法もあります。これらの方法は監視ツール側がそれらの機能に対応している必要があるため、これらの通知方法を利用したい場合にはその機能を持った監視ツールを選択しなければなりません。

 上記のような通知手段を踏まえたうえで、私が個人的にお勧めしたいのは、これらの複合的な通知方法の利用です。システム管理者が常駐している場合には、管理者の端末へのアラートとともに、管理グループ全員へのメール通知、ページャーなどへの通知。管理者が常駐していない場合には、利用できるすべての通知方法に加えて、通知を受けた管理者グループ内で電話による連絡網などの利用です。そのため、システムの管理グループでは、障害発生時にすぐに対応できるような体制を事前に確立しておく必要があるのです。

スタッフが障害に対応できなかったら

 システムの障害は監視ツールなどを利用することで、ある程度自動的に検知できますが、実際に発生した障害への対応は、やはりシステムの管理者である人間がしなければなりません。しかし、人間は監視ツールのように常に同じクオリティで働き続けることができるわけではありません。人間には休みが必要ですし、体調を崩したりすることもあります。また、管理グループ内で交代勤務をしている場合には、そのときに在席している管理者の資質(スキル)によって、対応する技術力にも差ができてしまいます。では、これらの問題はどのように解決すればいいのでしょうか?

 24時間×365日稼働するシステムの管理は、1人の管理者だけで管理し切れるものではありません。常に一定以上のクオリティを維持したシステムの管理を実現するには、エンジニアのスキルを考慮したシステム管理グループの結成が不可欠です。システムの障害に対応することを前提としたシステム管理グループは、1次ラインと2次ライン(場合によっては3次ライン)に分けることができます。

 1次ラインのスタッフは、常にシステムの状況に気を配り、監視ツールなどから通知される障害のアラートを迅速に確認して障害の内容の把握に努め、可能であれば障害からシステムを復旧させます。常にシステムを監視し続ける必要があるため、2人以上のスタッフで構成されるグループ(食事やお手洗いなどで席を離れる可能性があるためです)が2交代から3交代制で勤務することが理想です。

 障害の内容がクリティカルなものであったり原因が特定できない場合、1次ラインのスタッフはより技術レベルの高い2次ラインへとエスカレートします。エスカレートを受けた2次ラインのスタッフは、より詳細にシステム障害を切り分け、迅速にシステムを復旧するように努めます。2次ライン以降のスタッフは常駐している必要はありませんが、エスカレートを受けたらすぐに対応できるように待機しておく必要があります。そのため3人以上のスタッフが、当番制で待機することが理想です。待機中の2次ラインスタッフは、飲酒などは控えるべきです。また、急病などにより2次ラインスタッフが不在にならないよう、2次ラインのグループ内では密な連絡を取り合う必要があります。

飲酒を控えて待機する2次ラインスタッフの責務

 システムの障害に関する情報は、管理者グループ内で共有できるような体制を作る必要があります。共有しなければならない情報には次のようなものがあります。

  • いつ検知されたか
  • どのような症状が発生しているか
  • 誰がどのように対応したか
  • 対応の結果どうなったか
  • 今後はどのように対処すればいいのか

 これらの情報は対応ログのような形式で残しておき、スタッフ交代時の申し送りで報告します。また、情報をデータベース化して、今後の対応に役立てることも重要です。このような障害対応記録は今後発生する障害への迅速な対応や、新しいスタッフの育成の材料につながる貴重なナレッジデータベースとなります。

 ここまでお話ししたところで、システムの障害検知と対応がシステム管理コストの大部分を占めてしまうことに気付かれた方もいらっしゃるかもしれません。もちろんあまり規模の大きくないシステムや、さほど重要性の高くないシステムであれば、ここまできっちりと管理する必要はないのかもしれません。しかし24時間×365日のシステム管理には、非常に管理コストが掛かるのは事実です。特にコストが掛かるのは管理グループの人件費といえます。そこで、これらの作業を専門の業者にアウトソースするというのも解決手段の1つです。

 システム管理を代行してくれる業者は数多くありますが、システム管理のすべてをアウトソースできる業者は多くありません。また、1次ラインなど一番人手の掛かる部分の利用や、監視ツールだけの利用などシステム監視の一部だけをアウトソースする方が得な場合もあります。どちらにしても決して安いとはいえないコストを掛けるのですから、最も費用効果が高いと判断できるサービスを利用することが大切です。監視システムや対応スタッフなどをきちんと説明してくれる優良な業者を選択するようにしたいものです。

ポリシーの判断材料を経営側に提出するために

 今回はシステムを監視し、それに対応することがどういうことなのかについて解説しました。この連載の前回と今回の記事を通して、読者の方に分かっていただきたいことは「システムの管理は技術スタッフだけで決定するものではない」ということです。システムの構築や管理を技術スタッフだけの判断に任せるのは間違いです。システムを構築し、そのシステムを維持していくことは、経営側が判断して決めるべき問題です。

 これまでシステムの構築や管理には、技術スタッフが「このようなシステムを導入するべきだ。このシステムはこのように管理しなければならない」と経営側に主張し、それが予算を上回ることがなければその主張が通るという図式が多く見られました。

 もちろん、その判断の材料を提供するのは技術側です。つまり両者が現状の問題を把握し、より良い状況を維持するために何が必要なのかを協力して考えなければならないのです。

 さて、次回ですが、技術者が経営側に判断材料を提出するために、実際に管理しなければならないシステムを具体的に想定して、障害対応ポリシーを策定する方法について解説したいと思います。


Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。