ポストモーテムを導入して不具合に向き合う組織を作る

メリークリスマス〜！

この記事は トラストバンク AdventCalendar24日目の記事です！
こんにちは、初日も投稿させていただきました @kazuyaseo です。

クリスマス・イブというハッピーな日に障害の話をしてしまい恐縮ですが、大事な取り組みのため書かせていただこうかと思います！

概要

長期運用しているWebサービスにおいて「障害対応」は切っても切り離せない重要な対応です。
ふるさとチョイスもリニューアルしてから5年近くが経過している長期運用サービスのため、
想定していない障害が発生することがあり、その都度対応を行っています。

サービスをエンハンスし続けていると不具合は必ず起きるものです。必ず起きるからこそ、不具合が発生した時にどの様な行動を取るかはとても重要でだと思いますし、不具合対応をしっかりする人や組織をとても尊敬しています。

今までも障害があった際は「障害報告」と「再発防止策の実施」は行っていました。
ただし、障害報告は関係内外に向けた 報告 の意味が強いものでした。
また、資料作成時は開発担当とそのリーダーで資料作成と再発防止を考えるシーンが多く、障害内容と再発防止が組織の知見として蓄積されにくいと言う課題がありました。

今年から開発部はグループ単位でプロジェクトに関わる体制になったので、起きた障害もグループ内で分析し、再発防止も含めて開発部とメンバーの知見として貯まるようにしようと思いポストモーテムを導入し始めました。

ポストモーテムについて

ポストモーテムは「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」を参考にしています。
言葉の意味は「事後検証」でして、主にSREが利用する言葉でもあり、一言で言うと 障害に対する振り返り です。

ただの振り返りではなく、その中でも重要なのは以下の2点かなと思います。

・障害から学ぶ
・言いにくいことを言える環境にする

誰しも障害は起こしたくて起こしている訳では無いです。
ですが、システムが複雑化していればしているほど想定していない場所で不具合が起きてしまいますし、
障害が発生してしまうと現場の空気や「申し訳ない気持ち」に苛まれてしまい、メンバー含めて全体の士気も下がってしまいます。

そうならないためにも、「障害から学ぶ」文化を作って、ちゃんと向き合う組織にする活動として進めて行きたいです。

ポストモーテムのルール

今回、開発部では以下の様なルールと流れでポストモーテムを実施しています。
まだまだ始めたばかりなので内容は荒いですが、回数が増えるたびにフォーマットやルールもブラッシュアップしていきたいです。

グランドルール

• 一人で実施せず、関係者を揃えて実施する。
• ファシリテーターは上記の関係者に当たらない人が実施する。
• 実現不可能な再発防止策を提示しない。
• 資料作成は協力して実施する。
• 参加者全員が必ず以下を守る。

・人を非難しない
・責任追求しない

流れ

1. 開始の挨拶とルールの説明
2. 目的・ゴールの確認と共有
3. フォーマットの順番に沿って、ヒアリングをしながら記載する
   1. 作者の確認
   2. インシデントの確認
   3. インパクトの確認
   4. ユーザー影響の確認（時間がかかるようであれば記載を依頼する
   5. タイムラインの確認
   6. 根本原因の確認
   7. 対応内容の確認
   8. 現状のステータスの確認
4. 再発防止策の策定と実施予定日を決める
5. 教訓を参加メンバーから確認
6. 参考情報の記載漏れ確認
7. 再発防止をタスクリストに記載する

フォーマットと注意点

フォーマット

## 作者：このページの作者
## サマリ：障害の内容を記載
## インパクト：どのような事が起こったか
## ユーザー影響：ユーザー・収益への影響をできれば数字で記載
## タイムライン：起こった事象を発生〜修正〜収束まで時間ベースで記載
## 根本原因：発生の原因を記載する
## 対応：障害に対してどのようなことをしたか
## ステータス ：現状のステータス ( Draft / In Review / Reviewed / Closed
## 再発防止策：今後の再発防止策を記載
## 教訓：うまくいったこと、うまくいかなかったこと、幸運だったこと
## 参考情報：今回の事象に対して参考にした情報

各項目を記載する上で注意する点

• ステータス
  • 特に無し、確実な情報の記載をお願いします
• 作者
  • 作者を書く、作者は会のファシリテーションも実施する。
• サマリ
  • どんな障害だったかを記載する。
  • 誰が見てもわかるように記載することを心がける。
• インパクト
  • 発生している事象や懸案は全て洗い出すようにする
• ユーザー影響
  • 日付と状況を明確に記載する。数字で記載できるものは数字で記載する。
    ex ) XXXX年MM月DD日 〜 XXXX年MM月DD日 の間 〇〇名のユーザが アクセスできなかった
• タイムライン
  • 開始時間・アラート発生 or 検知時間・初動時間・対応時間・解決の流れを明確に書く
• 根本原因
  • 根本的な原因を記載する、責任追及ではない。
• 対応
  • 暫定対応・恒久対応など、対応した内容を記載する。
• 再発防止策
  • 再発防止策を検討した上で、記載する。
  • 否定はせずに、考えられるものは全て出して、その上でやる・やらを判断して実際に取り組むことを選択すると良い。
  • 再発防止策はできるだけ仕組みを考える。
  • 「忘れないようにする」や「確認する」のようにせず、「忘れないように〇〇にXXを加えて常に確認できるようにする」や「システムで確認できる状況を作る」などにする。
  • 再発を防止する観点として、以下を視点に考えるようにする。
    • 予防をする
    • 検出を早める
    • 影響範囲や度合いを緩和する
    • 復旧・修正速度を上げる
• 教訓
  • 参加メンバー一人一つを記載する
  • 教訓はできるだけ前向きに考える。
• 参考情報
  • 漏れのないように記載する

実施してみて

上記のルールで運用し始めていますが、まだまだ日が浅く回数が出来ていないですが、既に以下の様な課題にぶつかっています。

• もう少しルール減らしても良かった、時間がかかる。
• どの規模の不具合でポストモーテムを実施するべきか？
• 再発防止策の優先度をどう付けるか？
• ポストモーテムの実施後を振り返らなくて良いのか？

また、教訓の項目に入れた「幸運だったこと」はgoogleの方針から拝借しましたが、障害から幸運を連想させるというのは初の試みなのでとても新鮮でしたし、メンバーからも良い意見が上がってきています。

今後も回数を重ねながらルールの改善をしていこうと思います！

終わりに

いかがでしたでしょうか。
不具合に対して反省したりすることは多いですが、向き合うと言うのはとても難しいかと思います。
個人ではなくチームで向き合うとなるともっと大変な事だと思いますが、不具合もチームの成長に繋げられることができれば、もっと良いエンジニア部隊になれると思って日々頑張っています。

これから「不具合減らしたい！」と言う方の参考になれば幸いです。

トラストバンクでは一緒に働いてくれるエンジニアを募集中です。
色んな職種で募集しているので是非チェックお願いします！