概要
システム障害の際に 「ポストモーテム」 という事後の検証イベントをやり始めて1年経ったので、どうだったかを残します。失敗を咎めるのではなく「失敗から学ぶ」という文化や姿勢を育てるのに良い影響があったと感じています。
取り組み内容
- うまくやれたこと
- うまくやれなかったこと
- 幸運だったこと
- 今後できそうなこと
という4つの質問を、30分程度のミーティングで話し合うものです。
障害対応にあたったメンバー全員で「対応のしかた」そのものはどうだったか、次回もっと首尾よくこなすためにどんなことができそうかをディスカッションしました。
※ 前提として障害が発生した場合は、規定の報告書にて「直接・間接原因の調査結果、対応の時系列や修正状況」は報告をしていて、このポストモーテムではそれらとは別で行いました。
気をつけること
- ポストモーテムの目的を忘れない
- 話が拡散しがちなので、システムのあそこどうなってたっけ? とか具体的な話が始まっちゃったら是正する
- そうしないと30分で終わらない
- 誰の責任だ、や批判的な内容を含めない
- 誰か個人のミスであったとしても、チームで仕組み化などを通して改善できないかを話し合うことが大切、個人を責めたところでなんの意味もないどころか、害になる
実際に話し合われたこと例
- 情報の拡散
- うまくやれなかったこと
- バタバタといろんなSlackスレッドで話が進んでしまい、途中参加しにくい、後から追えない
- 今後できそうなこと
-
〇〇-emergencyという、初動のチャンネルを作り、障害かも?というリアクションも作成する- 誰でも少しでも気になったら気軽に投稿し、気づき、周知、状況把握などの初動を可能な限り迅速に行う
-
〇〇-emergencyで障害が確定したら、障害20231001_〇〇の〇〇欠損等での名称で別途チャンネル作成し、速やかに関係者を集め対応にあたる- チャンネル作成のSlack Workflowを作成する
-
- うまくやれなかったこと
- 事象の発見
- うまくやれなかったこと
- ビジネスサイドに数値異常を指摘されて気づいた
- 問題の重大性に、エスカレーション当初に気づけなかった
- 今後できそうなこと
- ビジネスサイドの問い合わせ時点で速やかにSlackハドルを行い、口頭で状況把握と認識合わせを行う
- うまくやれなかったこと
事象の発見については、「幸運だったこと → たまたま〇〇さんが気づいてくれた」 と裏表で話される事が多かった印象です。その他の、システム的な改善案も多数出て修正されましたが、ここでは割愛します。
おわりに
ポストモーテムを、バックエンドやアプリSDK、インフラチームで集まって行うことで、障害発生その時はなかなか理解が追いつかなかった対応内容を関係者全員がしっかり理解し、本質的な問題解決をする、またその文化の醸成に繋がったと感じます。
以前は障害対応内容を一部のメンバーしか把握しておらず、収束後の対応もその方に属人化してしまう問題がありましたが、自然と解消されていました。また、監視や観測の重要性をチームで再認識し、ログ設計の見直しやSLO/SLIといった話に進みやすい環境となっていきました。
余談ですが、この振り返りフレームワークは障害だけではなく、様々なプロジェクトでクロージングの際に行うことも出来そうで、今後取り入れていけたらと思っています。