はじめに
チームでやっていたインシデントに対する振り返り方法がよかったのでメモ。体系的に振り返る方法を書くだけで具体的なインシデントについては触れない。自分が担当していたのはWebバックエンドシステム。
なぜ振り返りをするのか
インシデントが発生したらまずは二次災害が出ず素早く行える方法で修正してしまうことがよくある。それだと負債は増えるし、似たような問題は防げない。 振り返りの目的は、同様の問題の発生を防ぐこと。振り返りでは、抽象化して問題を切り分け、より幅広い問題に対する実現可能なアクションを見つける必要がある。
何を見つける必要があるか
インシデントに立ち向かうためには、以下の3ステップに対する対策が必要となる。
- 予防
- 検知
- 影響の最小化
これに対して、以下のようなアクションを検討することができる。
- システム的解決 (適切なエラーハンドリング、自動テストによる検知など)
- 開発フロー (チェックリスト追加、コードレビュールール変更など)
- 運用面 (要員の追加、運用ルールの変更など)
以上の3ステップに対して、それぞれのアクションを検討し、実現可能なものを採用する。
振り返り方法の一例
自分達のチームでは以下のようなブレインストーミングを行った。
設計、開発、テスト、運用といったフェーズごとに、今回起きた問題に関連のある良くなかった判断や見落とし、構造的課題をみんなで挙げる。この方法は以下の2点で大変よかった。
- 設計部分に関して深く議論できる (ただ気づいた問題を出し合うだけだと開発者はコーディングや自動テストあたりに重点を置きすぎる)
- 予防・検知・影響の最小化の各ステップをバランスよく洗い出せる
- 開発フェーズ順に考えるので各自がただ意見を出し合うよりは見落としが少なくより多くの意見がでる。
各課題に対しては思いつくアクションをあげる。最後に、実行コストと効果を見て行うアクションと優先度を決める。
かなり時間のかかる振り返りになるが、絶対に納得できるアクションを見つけたいのでればオススメである。
おわりに
インシデントが起きるのは悲しいが、振り返りはチームの学びになるし、将来のインシデントを潰せるのでがんばろう。
