コラム

  • 2021.11.18
  • ソフトウェアテスト
  • #テスト実行
  • #テスト技法
  • #テスト計画
  • #テスト設計
  • #基礎知識

【テンプレートあり】品質のプロが教える障害報告書の書き方

障害報告書の目的

システム開発や運用業務に携わっていると、「システムにバグがあってエラーが発生した」、「運用作業で人為的ミスをしてデータを欠損させた」、「アクセスが集中してサーバーがダウンした」といった何らかのトラブルに遭遇したことがあるかと思います。
今回は、トラブル発生時に作成する障害報告書の書き方について注意点を踏まえてご説明します。

まず、障害報告書を作成する主な目的は次の2点です。

(1)発生した障害内容を正確に関係者に報告する
障害発生により、関係者は当該システムの信頼性や、作業チームに対して不信感を抱いている事が多いため、真摯な姿勢で発生事象の詳細説明から再発防止策まで文書化して報告することが重要です。

(2)今後の再発防止を図る
発生した事象に対する具体的な解決策は、関係者にとって貴重なナレッジになり、もしもこの先、類似事象が発生してしまった場合は、報告書に書かれている内容を参考にして、迅速に対処できるメリットがあります。
また、当該事象を経験したことのない第三者に報告書を展開してナレッジ共有できれば、当該事象を未然に防止できる可能性もあります。
このため、第三者が報告書を読む際に、事象の内容から再発防止策まで誰が読んでも理解できるようになっていることが理想的です。

障害報告の注意点(一般消費者へ報告する場合)

システムのユーザーが一般消費者であった場合、運営会社としてユーザーへの説明責任を果たす目的で公式サイトやSNS上で事象の説明をすることがあるかもしれません。
その際には、システムの仕様に関わる内容や運用手順など関係者外秘に当たる情報、原因や対処内容は掲載しないよう注意しましょう。
こういった情報が知られてしまうと、サイバー攻撃のヒントを与えてしまうことになり、セキュリティリスクが高まります。
どこまでが社外に公開して良い情報かしっかりと精査した上で報告を行いましょう。

障害報告書の書き方

障害報告書に記載すべき内容と注意点について、項目ごとにご説明します。

障害内容

発生した障害の内容を正確に記載します。発生した障害をトリガーに複数の障害が発生してしまった場合には、時系列で発生した全ての事象を記載しましょう。
発生していた可能性はあるが、事実確認が取れていない事象については記載する必要はありません。

発生日時

障害内容に記載した事象がいつ発生していつ収束したのか、システムのログなどから正確な日時を確認して○○○○年○○月○○日~●●●●年●●月●●日の形式で記載しましょう。
SLA(Service Level Agreement)によっては、障害が発生していた長さによって賠償問題となることもあるので正確さが重要です。
エビデンスを提出して正確さを証明する必要がある場合には、別紙として添付しましょう。

経緯(トリガーとなる障害の発見~現在まで)

障害発生を検知したトリガーが何か、検知したあと誰がどういう対応をしたか、障害が収束するまでに実施したことを事実として時系列で列挙しましょう。
システムの調査・対処内容だけでなく、「誰が誰に対して何を報告してどういう判断がされたのか」というコミュニケーション履歴も必要です。
必要な対処の漏れ、対処の順番の誤り、適切なタイミングで報告できていたかといったプロセスについても後に検証する必要があるためです。プロセスに誤りがあると二次障害として扱われてしまうこともあります。

原因

直接的な原因と、根本的な原因の両方を記載します。
例えば、人為的な作業ミスが直接的な原因である場合には、根本的な原因として、「そもそもなぜ作業ミスが発生したのか」を考察して結論づける必要があります。
個人の作業ミスによって障害が発生しないように、「複数人によるチェック体制を設けていたか=組織として対応する手段を取っていたのか」、「作業者のスキル不足=アサインミス/教育不足でなかったか」など、考えられるあらゆる観点で該当する原因を挙げていきましょう。

暫定対応

経緯のパートで書いた情報と一部重複する部分もありますが、改めて記載を行います。
ここでは、現在発生している障害事象を今すぐ収束するために実施した暫定的な対応内容を記載します。
「システムを障害発生前の状態にロールバックした」などが該当します。

暫定対応を行う前には、手を加える箇所のバックアップを取得してデータの保全を行いましょう。時間経過とともに中身が変わっていくシステムのログや、DBのDUMPなどが対象です。暫定対応を行うにあたり、間違った対応をして障害が収束しない場合や、別の二次障害が起こってしまった場合に、対応前の状態に戻さなくてはならないことがあるためです。また、後の調査やエビデンス提示にも必要となってきます。

恒久対応

経緯のパートで書いた情報と一部重複する部分もありますが、改めて記載を行います。
ここでは、根本的な解決をするために実施する対応内容を記載します。「プログラムやサーバー設定を修正し、テストを行ってからリリースする」「ミドルウェアのアップデートを行う」などが該当します。
根本的な解決に向けて複数のタスクがあり、スケジュールの検討や他社や他部署との調整が必要な場合には、そのように記載します。現時点で考えられる対策とタスクを記載して調整中であることを伝えましょう。
まずは調査を行ってから方針決めを行う場合には、別途対応内容を報告する旨を記載し、障害報告書の作成を優先して一次報告としても問題ありません。

障害による影響

システムに障害が発生したことで、システム利用者に対してどのような影響があったのか、システムが通常利用できないことで滞ってしまった業務内容などを記載します。
a.障害が発生していた時間帯に発生した影響と、b.障害が収束した後にも継続している影響の両方の記載が必要です。
場合によっては、過去の実績から推測される機会損失の記載も求められる場合があります。
例えば、ECサイトで障害が発生し30分間商品購入が出来なかった場合は、同じ曜日、同じ時間帯の平均売上額を調べてその額を損失額として記載します。

再発防止策

原因のパートで挙げた内容に対して、どういう策を講じて再発防止していくのかを記載します。特定の個人の問題として処理するのではなく、チームとして組織的な対応が取れる内容にしましょう。
このとき、実施できれば再発はしないであろうと思われる内容であっても「実現が難しい対策は書かない」、「できない約束はしない」ことが重要です。

障害報告書テンプレートのダウンロード

汎用的かつ簡易的なフォーマットになりますが、障害報告が生じた際にお役立てください。

障害報告書テンプレート ダウンロードはこちら

まとめ

ここまで、障害報告書の書き方について整理してきました。
障害報告書を作成するタイミングは、まさに事態を収束させるための対応に追われているタイミングであり、作成する時間がなかなか取れなかったり、冷静に対処方法を検討する心理的な余裕が無いことが多いかと思います。
しかし、ここで迅速に誰もが納得する報告を行うことで、「障害が発生しても安心して任せられる対応力がある」と、高評価が得られることもあります。ピンチはチャンスと捉えて、迅速かつスマートに対応していきましょう。
このコラムがその一助として、お役に立てれば幸いです。

関連サービス