@takamii228知は力なり2020-01-26ポストモーテムを書いて障害対応による修正・改善のWhyを残す障害や問題が発生したときに行う振り返りのことをポストモーテムと呼び、SRE本の15章でも紹介されています。単行本(ソフトカバー)また、実際に実践している会社の事例もブログで紹介されています。inside.pixiv.blogdeveloper.hatenastaff.comquipper.hatenablog.com私の今のチームの開発でも活用すべく、上記を参考にポストモーテムのサンプルのテンプレを作ってみました。発生した事象を事実ベースで時系列で書く。発生した事象を復旧させるあたって暫定的に対処した内容を書く。して候補にあげた解決策を列挙し、最終的にその選択肢を選択した理由を書く。暫定対処を完遂するために実際に行ったアクションを書く。事象が発生した直接的な原因を書く。事象が発生した根本の原因を書く。して候補にあげた解決策を列挙し、最終的にその選択肢を選択した理由を書く。恒久対処を完遂するために実際に行ったアクションを書く。上記以外の内容があれば書く。実際に書くときは判断や対処のWhyを残すことを念頭において、事実と仮説を分けて記述することおよび最終的な意思決定に至った過程を残すことを重視しています。そのとき行った対処が1年後・2年後も正しいとは限りませんし、実際に開発・運用するメンバーが入れ替わってチームのスキルレベルが変われば最適な策は変わりえます。今その設定になっている根拠や捨てた選択肢を残すことは将来的に技術的負債にならないための予防策と言えます。今負債になってないものが将来も負債にならない保証はないのです。Record)もありますね。ADRでちょっとした修正・Whyを残すポストモーテムやADRは開発プロセスや運用プロセスに組み込んで使うことを想定しているもののため、結構腰を据えて時間をかけて書かないといけません。そのまま使うと結構重そうだったので、ちょっとした内容を残すときにも使えるように簡易的なテンプレートを作ってみました。この簡易的なものをドキュメントに残す文化を作っておくと、属人的で暗黙的になっているちょっとした知識をチームの集合知として昇華できるのでおすすめです。開発の初期段階での検討事項の一部が漏れていて、終盤になってちょっとした問題が発覚したケースや、QAで発覚した軽微なバグ修正の横展開のメモを残すような用途を想定しています。三点セットがあればよいでしょう。Request、チケットなどに記述し、あとで参照可能な状態にしておくことが大事です。CIがエラーでジョブが失敗したケースは以下のような内容を書きます。bytes」のエラーが発生して失敗する。CIのログ上限に達してジョブが失敗した。output_limitを拡張する。https://gitlab.com/gitlab-org/gitlab-runner/issues/1024これがチームメンバ一人ひとりが自律的に書けるようになるチームを目指して、引き続きEM業を頑張りたい所存です。Next行きたかったな・・・。18:44ポストモーテムを書いて障害対応による修正・改善のWhyを残すTweet広告を非表示にする関連記事2019-12-312019年の振り返り的な何か今年もざっくり振り返ろうと思う。2018年の記事はこちら。