ポストモーテムを書いて障害対応による修正・改善のWhyを残す
障害や問題が発生したときに行う振り返りのことをポストモーテムと呼び、SRE本の15章でも紹介されています。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者:
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本（ソフトカバー）
また、実際に実践している会社の事例もブログで紹介されています。
私の今のチームの開発でも活用すべく、上記を参考にポストモーテムのサンプルのテンプレを作ってみました。
# 1.起きた事象 発生した事象を事実ベースで時系列で書く。 起きた事象がひと目でわかるタイトルをつけるとよい（「テレビ放映でアクセス増加に伴うDBダウン」など） # 2.影響範囲 起きた事象によって発生したサービスに対する直接的、間接的影響を列挙する。 # 3.暫定対処 発生した事象を復旧させるあたって暫定的に対処した内容を書く。 ## 3-1. 対応策候補 暫定対処として候補にあげた解決策を列挙し、最終的にその選択肢を選択した理由を書く。 ## 3-2.アクション事項 暫定対処を完遂するために実際に行ったアクションを書く。 # 4.原因分析 ## 4-1.直接原因 事象が発生した直接的な原因を書く。 ## 4-2.根本原因 事象が発生した根本の原因を書く。 # 5.恒久対処 ## 5-1.対応策候補 恒久対処として候補にあげた解決策を列挙し、最終的にその選択肢を選択した理由を書く。 ## 5-2.アクション事項 恒久対処を完遂するために実際に行ったアクションを書く。 # 6.その他 上記以外の内容があれば書く。
実際に書くときは判断や対処のWhyを残すことを念頭において、事実と仮説を分けて記述することおよび最終的な意思決定に至った過程を残すことを重視しています。
なぜなら、そのとき行った対処が1年後・2年後も正しいとは限りませんし、実際に開発・運用するメンバーが入れ替わってチームのスキルレベルが変われば最適な策は変わりえます。
なので今その設定になっている根拠や捨てた選択肢を残すことは将来的に技術的負債にならないための予防策と言えます。
今負債になってないものが将来も負債にならない保証はないのです。
似たような思想で設計のWhyを残すADR(Architecture Decision Record)もありますね。
kawashima さんの日本語訳
https://gist.github.com/kawasima/e325eda1c910d2abc5fb5f69d6a692e2
簡易ポストモーテム / ADRでちょっとした修正・Whyを残す
ポストモーテムやADRは開発プロセスや運用プロセスに組み込んで使うことを想定しているもののため、結構腰を据えて時間をかけて書かないといけません。
そのまま使うと結構重そうだったので、ちょっとした内容を残すときにも使えるように簡易的なテンプレートを作ってみました。 この簡易的なものをドキュメントに残す文化を作っておくと、属人的で暗黙的になっているちょっとした知識をチームの集合知として昇華できるのでおすすめです。
例えば開発の初期段階での検討事項の一部が漏れていて、終盤になってちょっとした問題が発覚したケースや、QAで発覚した軽微なバグ修正の横展開のメモを残すような用途を想定しています。
30分~1時間くらいで書けるくらいシンプルな内容にするため、事象・原因・対処の三点セットがあればよいでしょう。これらの内容はIssueや修正のPull Request、チケットなどに記述し、あとで参照可能な状態にしておくことが大事です。
# タイトル ひと目でわかるタイトルを書く ## 発生事象 何が起きたかを書く。 ## 原因 事象が発生した原因を書く ## 対処 解決策を書く
例えばGitLab CIがエラーでジョブが失敗したケースは以下のような内容を書きます。
# GitLab CIがJob's log exceeded limit of 4194304 bytesで失敗する ## 事象 GitLab CIのジョブが「Job's log exceeded limit of 4194304 bytes」のエラーが発生して失敗する。 ## 原因 ログの上限設定がデフォルト値（4096KB）のままになっていて、GitLab CIのログ上限に達してジョブが失敗した。 ## 対処 GitLab CI Runnerの設定で.gitlab-runner/config.toml のoutput_limitを拡張する。 ... executor = "shell" output_limit = 16384 ... 参考 : https://gitlab.com/gitlab-org/gitlab-runner/issues/1024
これがチームメンバ一人ひとりが自律的に書けるようになるチームを目指して、引き続きEM業を頑張りたい所存です。
SRE Next行きたかったな・・・。。。
