障害から復旧した後、報告書を埋めることだけが目的になると、確認できたことと推測が混ざりやすくなります。振り返りでは、起きた事実、原因として考えていること、次に変えることを分けると、残る疑問と対策の優先順位を話し合えます。
この記事は、企業のシステム運用担当者や責任者が、復旧後の振り返りを進めるための整理方法です。進行中の障害対応を置き換える手順ではなく、実際の障害を当社で検証した報告でもありません。
まず影響と時系列を、観測できた範囲で記録する
最初に「いつ、誰に、どのような影響があったか」を整理します。検知時刻、実際に影響が始まったと分かる時刻、復旧を確認した時刻は、同じとは限りません。時刻の基準やタイムゾーンも揃えます。
利用者への影響件数が分からない場合、分からないと記録します。ログで確認した値、別資料からの推定、未確認を分け、推定値を実測のように扱わないことが大切です。
| 記録する項目 | 確認する材料 | 区別したいこと |
|---|---|---|
| 検知 | 通知、監視、問い合わせ | 発生時刻と検知時刻 |
| 影響 | エラー、処理件数、利用者報告 | 全体の影響と観測できた範囲 |
| 対応 | 操作記録、判断メモ | 実行したことと予定したこと |
| 復旧 | 応答、業務処理、担当確認 | 一時的改善と復旧判断 |
機密を含むログの全文を広く共有するのではなく、アクセスが認められた場所への参照と、確認に必要な要点を残します。
原因を一つに決める前に、事実と仮説を分ける
「設定を変えた後に直った」は重要な事実ですが、それだけで設定が唯一の原因だったとは限りません。同じ時間帯に別の変化がなかったか、どういう仕組みで症状につながるのかを確かめます。
原因仮説には、支持する材料、反対する材料、未確認の点を添えます。再現できない場合は「再現せず」、保存記録が不足する場合は「記録不足」と書き、推測で詳細を補わないようにします。
原因が未確定でも、次回に備えて観測を改善することは検討できます。ただし、その改善を「原因を除去した対策」とは扱わず、何を明らかにするためのものかを記録してください。
個人への注意だけで、対策を終わらせない
GoogleのSRE Workbookは、個人を責めることを避けた振り返りと、実行可能な改善項目の重要性を説明しています。曖昧な「改善する」だけでは、何を完了とするかが分かりません。Google SREの振り返りガイド
「担当者が気を付ける」にとどめず、その判断をした時点で何が見えていたかを確認します。対象を取り違えやすい表示だったのか、確認すべき情報が手順にないのか、止める条件が曖昧だったのかなど、仕組みや情報の不足を検討します。
これは責任をなくすためではありません。事実を確認し、同じ条件に置かれた別の担当者でも失敗しにくくするための考え方です。
仮例：対象確認の不足を、検証できる改善へ変える
次は、作業対象の確認が不十分だったという仮例です。実在の障害ではありません。
対策を「作業前の確認を徹底する」とすると、どこまで行えば完了か判断しにくくなります。代わりに、作業依頼の対象IDと、操作画面の対象IDを照合する欄を既存手順へ加え、別担当者が試して迷わないか確認する、と具体化できます。
対策を登録するときは、次の情報を一組にします。
- 変えるもの：対象確認の手順と記録欄。
- 担当と期限：誰が、いつまでに案を用意するか。
- 完了条件：確認の実施結果と、未解決の曖昧さが残っていないこと。
- 効果の確認：その後の作業で対象を識別できているかを確認する方法。
この例の方法が、すべての環境で最適とは限りません。操作を止める仕組みが必要なのか、文書の改善で足りるのかは、実際の失敗条件と影響に合わせて判断します。
対策の数より、優先順位と完了の確認を揃える
対策を大量に並べると、どれから取り組むかが不明確になります。再発の可能性、影響、実施に必要な作業、既存対策との関係を整理し、優先するものを決めます。
振り返り資料は、原因や対策が更新されたら、その根拠と版を残します。「文書を作った」で終了せず、担当と期限を持つ改善がどこで追跡されるかを確認してください。
定型作業の書き直しには運用手順書の作り方、検知・通知の論点には監視アラートの設計が役立ちます。運用全体の整理が必要な場合は、確認できた影響と残る課題をまとめてインフラ・クラウド支援へご相談ください。