みなさん障害報告書はどのように書いていますか？
弊社では社内情報システムやサーバインフラ、サービス基盤システムを運用してきた中で、良くも悪くも数多くの障害に立ち向かい報告書を書いてきました。障害やトラブルの報告は、対象システムの利用者や関係者または組織内の管理者や役員など、デリケートな内容なだけ非常に気を使うものです。
そこで、障害報告書を作成する上での注意点とテンプレートを共有したいと思います。
障害報告書の注意点
障害報告書というのは、対象システムのトラブルや障害によって、ステークホルダーに価値が提供できない状況が発生した内容について説明するためのモノです。
ステークホルダーが、社内宛なのか、社外宛なのか、エンジニアなのか、非エンジニアなのかなど、様々な要因によって内容が異なります。なので、まず初めに最大限の情報量をまとめて、提示先に応じて報告書として精査していきましょう。
尚、システムの障害において、報告内容の項目は大きく10項目に分けられます。
- 概要
- 日時と継続時間
- 対象システム
- 障害内容
- 障害規模
- 発生原因
- 暫定対応
- 対応経緯
- 恒久対応
- 謝罪
そして、私たちがそれぞれの項目を記載する際には、下記のような観点に注意しております。
【概要】
発生した障害について、その文章を読めば「どこで」「なにが」「どうなった」を把握できるように記載する必要があります。上司に相談や報告する時と同じく、まず結果から伝えて、その先の詳細な報告内容をいますぐ見るのか、別途ミーティングするのか、あとで見ておくだけでいいのかを相手が判断できる情報を伝えましょう。
- 悪い例）発生部分が曖昧
オフィシャルのホームページの中で問題が発生しましたので報告致します。 - 良い例）
製品サイトの商品検索機能が利用できない問題が発生しましたので報告致します。
【日時と継続時間】
私生活でもビジネスでも時間は重要な意味を持ちます。その時間に対象システムが使えなかったことで、人生のチャンスやビジネスの売上又は利益が大きく左右することがあります。そのため、できる限り正確に分単位（システムによっては秒単位）で、「発生時間」「復旧時間」（障害が継続した時間）を書きましょう。
- 悪い例）時間が曖昧
発生時間：1/3 正午ころ - 良い例）
発生時間：2015年 6月 18日 11:53〜12:32 (24時間表記)
【対象システム】
組織やサービス運用において目的や用途に合わせて複数システムで構成されているケースが多いかと思います。障害が発生したのは、何のサービス又は業務のどのシステムなのかを明確にし、ステークホルダが自分に関係のあるものなのかを一目で判断できるようにしましょう。
- 悪い例）
ホームページの一部 - 良い例）
オフィシャルサイトの製品検索ページ
【障害内容】
なにが起きていたかが明確であれば、その問題を紐解くことができます。障害内容は原因と対応を説明する上で必ず必要な情報です。障害として起きた事象自体をできるだけ具体的に説明しましょう。
- 悪い例）どんな障害なのかわからない
ページに不具合が発生 - 良い例）
高負荷によって商品データベースが正常に処理できない状態
【障害規模】
その障害が発生した際の被害状況は、サービスが提供するはずだった価値にどのような影響があったのかがわからなければ把握できません。障害発生時の影響範囲やその状況を明確に伝えましょう。
- 悪い例）どのくらいの影響があったのかわからない
影響範囲：サーバの不具合でホームページが利用できない - 良い例）
影響範囲：製品サイトの商品検索結果のページが表示できない状況が発生
【発生原因】
オペレーションミスや原因特定できないなど伝えずらいケースも多々ありますが、原因の隠蔽や虚偽はさらに大きな問題を生むことになりかねませんので真摯に伝えましょう。
- 悪い例）どんな問題がおきたのかわからない
発生原因：ミドルウェアの動作に問題があったため - 良い例）
発生原因：データベースに処理に数十分かかるクエリーが多発したため
【暫定対応】
障害状態を復旧させた一時的な対応は、再発や似たような問題が発生した際の参考となります。暫定対応として実行したオペレーション内容も含めて詳細に記載しておきましょう。
- 悪い例）どう回避したのかわからない。
暫定対応：データベースの問題を一時的に回避し復旧 - 良い例）
暫定対応：データベース上にあるクエリーキャッシュを削除し復旧
【対応経緯】
対応経緯を細かく記録し共有することによって、ステークホルダーとの信頼関係を維持することができます。障害内容によっては時間がかかるケースも多いので、時系列に沿って伝えられるようにしましょう。
- 悪い例）時系列に記述されてない。
対応経緯：
障害検知後に、調査原因特定し対応しました。 - 良い例）
対応経緯：
◯◯:◯◯ 監視システムよりアラートを検知
◯◯:◯◯ 運用担当者にて調査を開始
・
・
【恒久対応】
発生した障害が、再発の可能性がある場合には原因を追求し解決しなければ、枕を高くして寝ることができません。恒久対応は改修箇所を見つけるまで長期間に及ぶものもあります。そのため、対応内容だけではなく必要な期間や実施時期など、マイルストーンを立てた上で共有しましょう。
- 悪い例）いつ具体的に何をするのかわからない
恒久対応：原因となった問題を特定し対応 - 良い例）
恒久対応：1週間程度で原因となったクエリーを実行している箇所を特定し、問題箇所の改修計画を立てる
【謝罪】
障害は「想定外」であり「不測の事態」なのは周知の事実です。障害によってそのシステムを利用できなかったユーザの方々や、障害が起きた際にご協力頂いた関係者への謝罪と感謝の気持ちはしっかり伝えましょう。
- 悪い例）障害自体にたいして平謝りになっている。
「問題が発生し障害となってしまい申し訳ありません。」 - 良い例）
「製品サイトをご利用のユーザ様へ ご迷惑をお掛けしました事、深くお詫び申し上げます。」
障害報告書のテンプレート
障害対応の注意点でまとめた、障害報告書内容をもとに弊社では下記のような「障害報告書」として、関係各社に共有しています。
製品サイトの商品検索機能の障害報告書
株式会社◯×◯×
ガイア太郎
2015年6月18日に製品サイトの商品検索機能が利用できない
問題が発生したため報告致します。
株式会社△◯△◯様ならびに製品サイトご利用の皆様へ
ご迷惑をお掛け致しました事、深くお詫び申し上げますと共に、
本書にて障害内容の詳細と経緯・原因、今後の対応について報告させて頂きます。
【障害発生日】
2015年 6月18日 11:53〜12:32 (24時間表記)
【障害内容】
製品サイトの商品検索にてキーワード検索を実行した際に
結果のページが表示できない状況が発生致しました。
【発生原因】
本製品サイトのアプリケーションから数十分かかるクエリーが多発し
その高負荷によって商品データベースが正常に処理できない状態が発生致しました。
【暫定対応】
データベース上にあるクエリーキャッシュを削除することにより、
通常の商品検索処理ができるようになり復旧致しました。
【対応経緯】
11:53 監視システムよりアラートを検知
11:55 運用担当者にて調査を開始
商品データベースでの異常が発覚
クエリーキャッシュが肥大化しているのを特定
10分以上残存しているクエリーを削除
12:32 商品検索画面の復旧を確認
【恒久対応】
1週間程度で原因となったクエリーを実行している箇所を特定し、
問題箇所の改修計画を立て、再発防止を実施致します。
別途、実施タイミングは調整の上、対応させて頂きます。
以上、ご参考になりましたでしょうか？
ちなみに、Reactio(リアクティオ)のインシデントの障害情報とタイムライン機能を利用し、
障害対応オペレーションをしていくことで、自然に障害報告書内容が記録および蓄積されていきます。
※デモデータのためテンプレートの時間と違いますがご了承ください。
また、社内など関係性など近いステークホルダーであれば、Reactio（リアクティオ）のインシデントをそのまま共有するだけで、別途障害内容をまとめ直して共有する必要がなくなります。
ぜひ、Reactio(リアクティオ)をご活用ください。