Upgrade to Pro — share decks privately, control downloads, hide ads and more …

一番気が重いと言われたポストモーテム委員会の改革

coconala_engineer
April 30, 2025
120

 一番気が重いと言われたポストモーテム委員会の改革

20250430「MIXI × ココナラのSRE改革大作戦 〜改善のその先へ〜」のLT資料
https://mixi.connpass.com/event/352623/

coconala_engineer

April 30, 2025
Tweet

More Decks by coconala_engineer

Transcript

  1. Copyright coconala Inc. All Rights Reserved. 2 自己紹介 吉川拓見(よしかわ たくみ)

    • 生まれ 静岡 → 文系大学からエンジニアへ • 経歴 金融SIer → スタートアップ → ココナラ • 趣味 ライブ・イベントに行く
  2. Copyright coconala Inc. All Rights Reserved. 3 本日おはなしすること • テーマに含むこと

    ◦ ココナラ的なポストモーテム運用の課題 ◦ 課題に対する対処と効果 • テーマに含まないこと ◦ ポストモーテムの文化醸成、波及 ◦ AIを用いた対応策
  3. Copyright coconala Inc. All Rights Reserved. 5 ポストモーテムとは • Post

    Mortem ◦ ラテン語で「事後」という意味 ◦ Googleさんは怖い方の翻訳を出してくるけど・・・ • 障害・問題に対して、あとから「振り返り」をしましょうね、という取り組みを指している
  4. Copyright coconala Inc. All Rights Reserved. 6 ココナラでの運用( Before) •

    5年ほど前から週次で実施 ◦ ポストモーテム委員会 ◦ 障害報告チャンネルにあがってきた事象を対象 ◦ エンジニアの各グループから委員を募って 30~60分のMTG • 委員会のざっくりとした流れ ◦ 事前に対象の障害に関わったエンジニアがドキュメントを記載 ◦ 週次の委員会(MTG)に持ち込む ◦ ドキュメントを中心に事象や対応について議論 ◦ 議論の内容をもとに再発防止策を Fix
  5. Copyright coconala Inc. All Rights Reserved. 9 なにがそう感じさせたのか 重いと感じさせてしまっていた要素 •

    ドキュメントの精度 ◦ 1稿作成に平均4時間程度 ◦ 再発防止等をきちんと考えてくる必要 があった ◦ インシデントの時系列も細かく表化す るようなフォーマットであった (右が一例)
  6. Copyright coconala Inc. All Rights Reserved. 10 なにがそう感じさせたのか 重いと感じさせてしまっていた要素 •

    ドキュメントの精度 ◦ 1稿作成に平均4時間程度 ◦ 再発防止等をきちんと考えてくる必要があった ◦ インシデントの時系列も細かく表化するようなフォーマットであった • 雰囲気 ◦ 再発防止まで記載したドキュメントのレビューが中心 ◦ どうしても対象者の処置だったり、その対策の効果に対する議論に始終してしまい、糾 弾するような空気になった ◦ 有志で集まった委員も「自分はああなりたくない」として発言しづらい
  7. Copyright coconala Inc. All Rights Reserved. 12 ぼくの考えるポストモーテムと障害報告の違い 項目 ポストモーテム

    障害報告 目的 障害からの組織的な学び 障害の影響度合いと再発防止のまとめ 分析手法・ 範囲 原因を中心として、技術以外にも運用・プ ロジェクトも含めた多角的な視点を求める 根本原因となった点を中心とした技術的 に細かい箇所 & 横展開 ドキュメント フォーマット ある程度の柔軟性がある ほぼ固定
  8. Copyright coconala Inc. All Rights Reserved. 13 ぼくの考えるポストモーテムと障害報告の違い 項目 ポストモーテム

    障害報告 目的 障害からの組織的な学び 障害の影響度合いと再発防止のまとめ 分析手法・ 範囲 原因を中心として、技術以外にも運用・プ ロジェクトも含めた多角的な視点を求める 根本原因となった点を中心とした技術的 に細かい箇所 & 横展開 ドキュメント フォーマット ある程度の柔軟性がある ほぼ固定 ドキュメントのフォーマットも委員会の運用も 障害報告向きになってしまっていた
  9. Copyright coconala Inc. All Rights Reserved. 15 雰囲気だけでも変えたい • 来るまでの重さ

    ◦ 精度の高いドキュメントを書くために時間がかかる ◦ 通常開発をしながらその時間をなかなか捻出できない • 来てからの重さ ◦ とりあえず空気が重い ◦ なに突っ込まれるかわからない
  10. Copyright coconala Inc. All Rights Reserved. 16 雰囲気だけでも変えたい • 来るまでの重さ

    ◦ 精度の高いドキュメントを書くために時間がかかる ◦ 通常開発をしながらその時間をなかなか捻出できない • 来てからの重さ ◦ とりあえず空気が重い ◦ なに突っ込まれるかわからない ネガティブポイントばかり捉えてしまうからよくない! ポジティブ要素もちゃんと一緒に振り返って「まなび」を広げたい
  11. Copyright coconala Inc. All Rights Reserved. 17 雰囲気だけでも変えたい • ドキュメントフォーマットを一新

    ◦ 言葉遣いを変更 ▪ ex.) 再発防止→ アクションアイテム ◦ 学びコーナーによかったことを2つ追加 ▪ 事象に対する処置の仕方 ▪ 事故になったけど〜のおかげで被害が広 がらなかった ◦ タイムライン表記をやめる ▪ もともとSlackのチャンネルでやりとりして いるので、そのリンクを転記するだけ
  12. Copyright coconala Inc. All Rights Reserved. 18 雰囲気だけでも変えたい • アクションアイテムは委員会でブレストする

    ◦ 事前になにか考えてくる必要はない(もちろん思いつくのであれば OK) ◦ 事象に詳しい人、そうでない人、俯瞰的に捉えている人で考えることは違う ◦ 「これは仕方がないよね」も1つの結論とする ▪ 相応の理由は必要であるけれど • 過去に定めた再発防止策(アクションアイテム)も見直す ◦ 無理やり生み出しただけで対応コスパが悪いものは引き下げ or 考え直し
  13. Copyright coconala Inc. All Rights Reserved. 19 2つを変えて半年間の結果 • 明らかにメンバーからの発言が増えた

    ◦ 定量的な指標だが、1回につき1人 → 1回につき4~5人(全体は7~10人) ◦ メンバーから「やりやすくなった」という声 • なんでも技術で解決しようとしなくなった ◦ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では?という視点も生まれ るようになった • なによりも委員会のときの空気感が圧倒的に軽くなった ◦ 障害報告じゃないんだ、という感覚を持ってもらえている
  14. Copyright coconala Inc. All Rights Reserved. 20 今後の課題 /展望 •

    技術ライン以外のステークホルダーとの戦い ◦ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では?という視点も生まれ るようになった ◦ のはいいが、これをプロダクトラインに理解してもらい、施策として入れ込む必要がある • AI利活用 ◦ フォーマットとSlackスレッド / チャンネルを渡すことでいい感じのものはできる ◦ 過去のポストモーテムを学習してもらい、類似性検索等もしたい