はじめに
こんにちは、webエンジニアの@an_sonyです。
最近、障害対応の振り返りをしていた時に「ポストモーテム」という手法を初めて知りました。これまで「どうやったら良い振り返りができるのか？」と悩んでいた自分にとって目から鱗の知識ばかりでしたので、整理のためにまとめてみます。
ポストモーテムとは？
SRE サイトリライアビリティエンジニアリング1によると、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるドキュメントを指します。
言い換えると、失敗（障害）から学び、再発防止策を決める活動です。
障害報告書との違い
障害報告書と内容が似ていますが、ポストモーテムは読者と目的が違います。
障害報告書は、障害発生によって不利益が生じたユーザーに対して、その説明をするための報告書を指します。対してポストモーテムは障害から学び、より良いサービスにするための報告書です。そのため読者は身内のエンジニアになります。
| 想定読者 | 目的 | |
|---|---|---|
| ポストモーテム | 身内のエンジニア | 障害からの学び・サービス改善 |
| 障害報告書 | 上司・ユーザー | 障害の報告・情報共有 |
フォーマット
SRE 付録D ポストモーテムの例1のフォーマットです。
作成日:
作者:
ステータス:
サマリ:
インパクト:
根本原因:
発生要因:
対応:
検出:
アクションアイテム:
教訓
うまくいったこと
うまくいかなかったこと
幸運だったこと
タイムライン
参考情報
ポストモーテムを実施する上で重要なこと
批判を行わない
これが最も重要なことです。批判をしてしまうと、過失を犯した人間は処罰を恐れて何も語らなくなり、その背後にある本当の原因に気付くことができません。そうするとポストモーテムの目的である障害から学ぶことができなくなってしまいます。批判ではなく原因分析と改善に集中することが大切です。
障害について根本原因を十分に分析し、理解する
障害に対して分析が不十分だと、間違った再発防止策になってしまい、結果的に同じ障害が再発してしまいます。分析は「客観的であること」「原因がシンプルで、かつシステムやプロセスにあること」を意識して、なぜ？をひたすら問い続けることが大切です。
人ではなく仕組みで解決する
再発防止策が「気をつける」とか「頑張る」という結論は人に頼って解決することになりますが、人を簡単に「修正」することはできません。それよりもシステムやプロセスを修正して、人々が正しい選択をすることができる支援に取り込むことが大切です。
多くの人に知識を共有する
障害の原因分析や再発防止策は、障害から学んだ知識の集合です。その知識は他のチームでも活用できるノウハウになります。ポストモーテムはサービス改善が目的なので、知識はどんどん共有していくことが大切です。
どうやって実践していくか
ポストモーテムを書く基準を決める
ポストモーテムはそれなりの時間と労力を費やすため、全ての障害に対して取り組むのは現実的ではありません。そのため、判断基準を決めておく必要があります。
例）
・ダウンタイムが一定の閾値を超えた
・データの損失が生じた
・オンコールエンジニアの介入が必要だった
・解決までに一定以上の時間を要した
・モニタリング自身の障害
文化を根付かせるための継続的な活動
ポストモーテムを書く文化を根付かせるために、過去のポストモーテムを振り返るポストモーテム読書会をやったり、過去のポストモーテムをロールプレイする不運の輪をやったりするのが良いです。
まとめ
「失敗から学ぶ活動」に対しての具体的な意識や行動がイメージを理解できました。
あとは実践して、より良いサービスを開発できるよう改善活動していきます。
参考
-
SRE サイトリライアビリティエンジニアリング (https://sre.google/books/) ↩