社内で読書会を開きました。
僕が9章を担当したのでブログにも転載しておきます
キーワード
- インシデント
- ポストモーテム
9章まとめ
- 非難し合うようなポストモーテムは効果的ではありません
- 意思決定をよりよく理解するために、エンジニアのシステムに対するメンタルモデルを理解しましょう
- アクションアイテムでは、誰がいつまでに何をするのかを定義しましょう
- ポストモーテムをドキュメント化し、それぞれの対象者ごとに節を設けましょう。
- すべてのポストモーテムを同一の場所で共有しましょう
9章自分なりまとめ
- ポストモーテムは学習の場
- ポストモーテムも一種の振り返り、弊社でもKPTや障害報告書という形で自然とポストモーテムのエッセンスができていそう
- ポストモーテムの場では人の問題でも技術的な問題とも捉えない
- ドキュメントに残して広く共有する
9.1 良いポストモーテムの構成要素
- 大規模なインシデントが発生したときは責任のなすりつけあいが起こりその後面倒なプロセスが追加されてしまう
- 弊社はどう？なすりつけあいは見たことない気がする
- ポストモーテムの経験は浅いけどポストモーテムと同等のことをやってそう
- 問題が人にあるのではなくシステム（=仕組み）にある
- なぜを繰り返すと根本的な原因が出てきそう
- ポストモーテムが罰をあたえる機会になってはいけない。透明性がなくなる
- 非難のない文化は一夜にして実現できるものではない。自分が傷つきやすいということや自分のミスをチームや組織で最初に共有することで、この変革を促進できます。
- サーバントリーダーシップってやつかな？
- 自分も人間性を出す、泥臭くなる、っていうのは自分で気をつけてる（つもり
- ポストモーテムを機に、失敗に関与したシステムのメンタルモデルを全員で更新しましょう
- 確かに保守運用だけやってる人はAWSアカウントの全容を知らないことが多いしDjangoにどんなモジュールがあることを知らない
- 弊社の場合だと保守運用担当者が意図的に人を集めてポストモーテムを開催しないといけないなと感じた
- 24時間以内にポストモーテムを行うべき
- 警戒心が薄れる/状況の詳細がなくなる
- ポストモーテムのルール
- 1.人を直接批判してはならない
- 2.誰もが、その時点で最善の仕事をしたと考える
- 3/会議の進行役によってルールが守られるか大きく変わる
- KPTのルールと似てるなと思った
9.2 インシデントの発生
- ショーンさん、キューを消費するサービスのこと知らないのまずくないか…それぐらいは知っていてほしいと思った
- 根本的にはメンタルモデルが古くなっていたのが問題、ショーンさん頭悪くはない
9.3 ポストモーテムの実施
- 技術的な問題と捉えない
- ビジネス側の人が無関心になってしまうのでこれは気をつけないといけない
- notエンジニアの人と話すときは注意しないといけない
- ビジネス側の人が無関心になってしまうのでこれは気をつけないといけない
- ポストモーテムに招待すべきは、関与した全ての人
- ある程度権限あるメンバーもいることでポストモーテムでの決定事項に組織を巻き込んだ権限を持たせられるので良いと感じた。多少関与の薄い人も呼んで良い気がする（関与しなかったのは偶然かもしれないので）
- ポストモーテムにはまずタイムライン。事実のみ書く。意見を書くと議論の余地が出てしまうから
- タイムラインを書いた人の悪意やバイアスが入りそうですもんね
- ポストモーテムには名前ではなく役割で書く。非難されると感じるのを防ぐ・どのような文脈か後からわかるため
- これって何かと使えそうですね、cwt定例MTGでもやってみると面白そうだけど短期的には読みにくそう
- タイムラインの後に文脈を付け加える
- 行動が正しい行いだとしても、その行動を取るに至った背景・経緯を理解することが重要
- 正しい行動に至った経緯をみんなに共有できるため
- ポストモーテムのテクニック、KPTの場でも使えそう。
Keepはなぜそうしたのか他の人が真似できるようにするためProblemはなぜそうしたのか他の人が真似しないようにするため
- 最後にアクションアイテムを決める。これは誰がいつ何をするかまで明確に定義されているべき。具体的な進捗がなくなる
- 誰がいつ何をするか決まってなくて消滅するの、あるある
- アクションアイテムはフォローアップを行う
- アイテムは短期と長期に分け、長期のものはオーナーがサポートする
- ポストモーテムの主催者やファシリテーターは期日が切れたアイテムの期日交渉や情報のアップデートを行う
- めちゃ大変そう…
- アクションアイテムの担当者に緊張感は出る
- 特に僕には効果ありそうだなとおもいました笑
- 対応しなくても合理的選択。ただしみんなで合意をとっておこう。
- なんか新しい考え方だなと思った。対応しない場合は「対応しません」と周知してみんなで合意とる。リスクを大きく評価する人がいる場合は別途担当者を当てるとか対策が打てる
- ポストモーテムをドキュメントにまとめる
- ドキュメントの構造は 1.インシデントの属性、2.サマリ、3.ウォークスルー、4.認知とプロセス、5.アクションアイテム
- 属性は検索性を上げたいから必須で欲しいですよねー、
- サマリは外から見た事象、ウォークスルーは中から見た事象と見ることもできそう
- サマリにはユーザー体験も含めて書きましょう
- ドキュメントは制限せずみんなに共有しましょう
- 受託会社だと、アクションアイテムも社内で決めるのではなくお客さんと話して決めるべき。リスクとコストをうまく説明しないといけない
- 結論、弊社の場合はポストモーテムと同様の目的を達成するものは自然とできている
- タイムラインで書いたりとか
- 事実と感想を分けたりとか
- 短期的/長期的に対策を考えるとか