先日、障害が発生してしまって、初めてポストモーテムを知り、書くことになりました。
障害報告書を書くと凹みますが、ポストモーテムは、失敗からの学びや今後の改善につながる改善活動などの内容なので、とてもポジティブになりました。
もっと詳しく知りたいと思い、ポストモーテムについていろいろなサイトなどから調べてまとめました。
ポストモーテム（事後検証）とは
ポストモーテムはGoogle 社が提唱している 「SRE」の本（SRE サイトリライアビリティエンジニアリング）に書かれているサービスやインフラの信頼性を支えるための技術の一つです。
障害など想定外のインシデントがあったときに振り返る事後検証のことです。
障害報告書との違い
障害報告書→会社や、顧客に障害の状況や内容を伝えるもの、
ポストモーテム→エンジニア内で再発防止や障害の振り返りや事後分析。
失敗からの学びが目的。エンジニアがわかる用語で書いていい。
SRE サイトリライアビリティエンジニアリングについて
詳しく知りたい方は以下のサイトを見てみてください。
英語版は、オンラインで無料で公開されています。
Google - Site Reliability Engineering
日本語版は、オライリー・ジャパンより出版されています。
『SRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチーム』
一部抜粋
何が起こったのかを詳細に確認し、イベントのすべての根本原因を見つけ、問題を修正するか、次回の対処方法を改善するためのアクションを割り当てる必要があります。Googleは、障害を回避または最小化するのではなく、障害を明らかにし、エンジニアリングを適用してこれらの障害を修正することを目的として、非難のないポストモーテムの文化の下で運営されています。
英文）
Postmortems should be written for all significant incidents, regardless of whether or not they paged; postmortems that did not trigger a page are even more valuable, as they likely point to clear monitoring gaps. This investigation should establish what happened in detail, find all root causes of the event, and assign actions to correct the problem or improve how it is addressed next time. Google operates under a blame-free postmortem culture, with the goal of exposing faults and applying engineering to fix these faults, rather than avoiding or minimizing them.
以下のサイトでポストモーテムについて書かれています。とても共感しました。
- ポストモーテムは、非難がなく、人間ではなくプロセスと技術に注目するもの。
- 人間は「修正」できない。環境を修正しなければならない。
ポストモーテムの書き方
今後ポストモーテムを書くにあたってテンプレートを作成しました。
随時改善し更新していく予定です。
———————————————————————————————
タイトル ：
作成日：
作者：
ステータス：Draft / In Review / Reviewed / Closed
サマリ：どんな障害だったか
インパクト：簡単な説明
原因：障害の原因
影響：ユーザーや収益への影響。非常に具体的で正確な数を記載
対応：障害に対してどんな対応をしたのか
再発を防止する方法：
- 予防（障害の再発をポジティブに防ぐにはどうしたらよいか
- 検出（同様の障害を正確に検出するまでの時間を減らすにはどうするべきか）
- 緩和（次回この種の障害が起きたときの深刻度や影響度の％を減らすにはどうしたらいいか）
- 修正（次回障害が検出されたときにどうすればより速く回復できるか）
タイムライン：
（1）始まった時間
（2）アラート発生時間
（3）インシデントが公開された時間
（4）調査開始から解決に至るまでの時間
ポストモーテムサンプル(あくまでも架空の障害です！ほんとに)
タイトル：全サービス接続不安定
作成日：2022年1月19日
作者：日高
ステータス：Draft
サマリ：2022/1/19 17:43頃から全サービスに接続しづらい状態が持続していた
インパクト：外部の特定のPCから大量のアクセスがあった
原因：外部の特定のPCから大量のアクセスがあったことが原因。想定外の負荷、ディスクの容量不足
影響：４０００リクエストがアクセスできなかった
対応：原因となっているPCからのアクセスを制限することで収束
再発を防止する方法：
- 予防：負荷テストをおこない、キャパシティを確保する
- 検出：定期的なモニタリングで予兆に気づくようにする
- 緩和：障害発生時にアラートがなるよう設定し、エンジニアが問題にいち早く気付けるようにする。Slackに障害発生の調査をはじめることを宣言し、状況を共有する。
- 修正:障害対応手順書を作成し共有し、いち早く復帰できるように準備しておく
タイムライン
- 1/19 17:43頃 3台あるWebサーバーのうち1台で負荷が高い状態を確認
- 1/19 17:45頃同一IPアドレスから大量のアクセスを確認
- 1/19 17:50頃負荷の高いサーバーを切断
- 1/19 17:55頃 WAFにて当該IPアドレスを遮断→一時的に復旧
- 1/19 18:00頃 当該IPアドレスの制限を解除し復旧
参考文献