システム障害対応で活躍する必須ドキュメント５選 – 適切に障害対応するために事前準備すべきこと

はじめに

システム障害対応は、システム開発とは違う考え方で行動する必要があります。
例えば、システム開発では先を見据えて着実に進めることが求められますが、障害対応は答えが見えない中、素早く行動することが求められます。
しかも対処に失敗したら被害が拡大するので、慎重に行動することも求められます。

ミスは許されません。
報告の仕方も間違えられません。
しかし対応が遅れると被害拡大します。

このようなシビアな対応を、何の準備もなしに対処するのは無謀というものです。
そのためシステム障害に備えた準備は必要になります。

ここではシステム障害対応で有効なドキュメントを整理しました。
プロジェクトによって他にあると良い情報やツールもあると思います。
運用保守を行っている方は準備が不足していないか点検すると良いでしょう。
システム構築している人は、運用開始前に作成するものがないか検討するのも良いです。

※システム障害の対応手順についてはこちらで解説しています。

障害対応の運用で使用するドキュメント

エスカレーションルール

システム障害を検知したとき、初動で誰にエスカレーションするのか、その連絡先（電話番号やメールなど）を記載します。
次で説明する障害対応フローほど詳細な情報ではなく、緊急時に担当者が迷わず連絡とれるように「この人に連絡する」がわかるようにします。
見える場所に貼ったり、担当者に紙で配るなど、緊急時に困らないようにすることが大切です。

障害対応フロー

障害対応するメンバや組織が、検知した障害をどのように処理するのか全体像がわかる業務フローです。
この障害対応フローが役に立つ理由は以下のとおり。

• 障害対応の全体の流れを理解できる
• 関係者の役割や責任範囲を明確にできる
• コミュニケーションツールを確認できる（電話、メール、ツールなど）

この障害対応フローの流れが関係者内で共有されておらず認識があってない場合、問い合わせしてもたらい回しにされる場合があります。
酷いときは問い合わせできる先がないことを障害対応時に気づくこともあります。
そうならないためにも障害対応フローを作成し全体合意を取ります。

連絡先一覧

緊急事態で報告したくても、相手の電話番号がわからないでは話になりません。
もしくは営業時間外など、連絡先の相手が電話に出られないこともあります。

もし電話をかけてもつながらない場合、その次に誰に電話をすればよいか明確になっているでしょうか。
さらに、その次は？
そこで相手がつながらない時も想定して、優先順をつけた連絡先一覧を作成します。

またメーカーや製品への問い合わせ窓口に報告したいとき、どのように問い合わせをすればよいかわからないと困ります。
問い合わせ先がWebサイトの場合、ログインするときのID、パスワード、契約番号が必要になるかもしれません。
緊急時でもすぐに連絡がとれるように整理する必要があります。

運用タイムスケジュール

バッチやジョブの実行時間、サービス利用時間など、システムのタイムスケジュールがわかるドキュメントは必要です。
調査やシステムに手当を行うとき、タイムスケジュールがわからないと作業時に２次被害が発生するかもしれません。
例えばデータパッチをAM2:00に適用したところ、実はAM1:00～3:00に夜間バッチ処理が実行していたのでデータ不整合が発生した、など考えられます。

おそらくシステム開発時には作成していると思いますが、運用している中でスケジュール変更している場合があります。
その都度、メンテナンスすることを心がけましょう。

作業手順書

サーバ操作、バックアップ、リリース手順など現場作業の定型作業は手順書を作成します。
作業手順書の必要性は誰でも理解していると思いますが、手間がかかるなどの理由で完備されていないケースを見かけます。
しかし手順書がないために作業ミスで２次被害を起こしている現場も同様に見かけます。

GUI操作の手順もそうですが、特にコマンド入力して操作する場合は要注意です。
コマンド入力ミスで取り返しのつかない事態になることもあります。
少なくともサーバの基本操作とバックアップ／リストア手順だけでも準備するべきです。

調査で使用するドキュメント

メッセージ一覧

システム障害が発生したときにエラーメッセージや障害レポートなどメッセージ出力する仕組みがある場合、メッセージの意味を知るための一覧があると初動対応がスムーズに行えます。
システム障害の時に発生するメッセージを整理し、緊急度がわかる情報があるのが望ましいです。

ログ格納場所

システムでは業務アプリケーションからミドル、インフラなど多くのログが出力されます。
担当しているシステムをよく知っている担当者であれば不要と思えますが、全てのログについて知っている人は意外と少ないです。
例えばアプリは知っているがインフラは知らない、などです。

体制変更などで後からメンバが入ってくることも考慮して、どこに何のログが格納されているか整理することが大切です。

障害管理台帳

システム障害が発生したときに、過去の類似障害を調査するときに使用します。
また直近で障害対応した内容が影響してトラブルにつながっている場合もあります。
障害対応したときは必ず台帳管理するようにしましょう。

また参照できる人は限られるでしょうが他システムの障害対応の記録を閲覧するのも有効です。
特にインフラ関係であれば類似障害を発見するきっかけになります。
例えばOSパニックが発生したとき、同じ型番のサーバで同様の事象が発生していないか、その対処方法など確認することができます。

おわりに

システム障害対応の準備は手間ということもあり準備されていない現場をよく見ます。
しかも保守運用フェーズに入っている場合、ドキュメント作成する工数もないため放置されることも良くあります。
しかし、いざ障害が発生したときに困るのは作業者です。
そして復旧が遅れることでユーザや顧客、つまり関係者全員が困ることになります。
システム障害に備えた準備が整っているか定期的に振り返ることをオススメします。