Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
一番気が重いと言われたポストモーテム委員会の改革
Search
coconala_engineer
April 30, 2025
0
120
一番気が重いと言われたポストモーテム委員会の改革
20250430「MIXI × ココナラのSRE改革大作戦 〜改善のその先へ〜」のLT資料
https://mixi.connpass.com/event/352623/
coconala_engineer
April 30, 2025
Tweet
Share
More Decks by coconala_engineer
See All by coconala_engineer
GraphQLを活用したリアーキテクチャに対応するSLI/Oの再設計
coconala_engineer
0
100
SREの視点で考えるSIEM活用術 〜AWS環境でのセキュリティ強化〜
coconala_engineer
1
300
(みんなやっているはずなのに情報が少ない)DNSレコード管理の改善
coconala_engineer
0
110
クラウド時代のDDoS対策:可用性を守るためのベストプラクティス
coconala_engineer
0
83
「エンジニアマネージャー」の役割を担っている / 担ってみたい方へのキャリアパスガイド
coconala_engineer
1
260
上場前後で描く、「モダンな情報システム部門」への進化とその取り組み
coconala_engineer
0
66
Qiita Organizationに取り組む前後の技術広報活動と今後の展望
coconala_engineer
0
61
ココナラのセキュリティ組織の体制・役割・今後目指す世界
coconala_engineer
0
280
SIEMによるセキュリティログの可視化と分析を通じた信頼性向上プロセスと実践
coconala_engineer
1
4.5k
Featured
See All Featured
Making Projects Easy
brettharned
116
6.1k
How STYLIGHT went responsive
nonsquared
100
5.5k
Scaling GitHub
holman
459
140k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Building Applications with DynamoDB
mza
94
6.3k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Being A Developer After 40
akosma
91
590k
Mobile First: as difficult as doing things right
swwweet
223
9.6k
Automating Front-end Workflow
addyosmani
1370
200k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Transcript
Copyright coconala Inc. All Rights Reserved. 一番気が重いと言われた ポストモーテム委員会の改革
Copyright coconala Inc. All Rights Reserved. 2 自己紹介 吉川拓見(よしかわ たくみ)
• 生まれ 静岡 → 文系大学からエンジニアへ • 経歴 金融SIer → スタートアップ → ココナラ • 趣味 ライブ・イベントに行く
Copyright coconala Inc. All Rights Reserved. 3 本日おはなしすること • テーマに含むこと
◦ ココナラ的なポストモーテム運用の課題 ◦ 課題に対する対処と効果 • テーマに含まないこと ◦ ポストモーテムの文化醸成、波及 ◦ AIを用いた対応策
Copyright coconala Inc. All Rights Reserved. 4 ポストモーテム やってますか?
Copyright coconala Inc. All Rights Reserved. 5 ポストモーテムとは • Post
Mortem ◦ ラテン語で「事後」という意味 ◦ Googleさんは怖い方の翻訳を出してくるけど・・・ • 障害・問題に対して、あとから「振り返り」をしましょうね、という取り組みを指している
Copyright coconala Inc. All Rights Reserved. 6 ココナラでの運用( Before) •
5年ほど前から週次で実施 ◦ ポストモーテム委員会 ◦ 障害報告チャンネルにあがってきた事象を対象 ◦ エンジニアの各グループから委員を募って 30~60分のMTG • 委員会のざっくりとした流れ ◦ 事前に対象の障害に関わったエンジニアがドキュメントを記載 ◦ 週次の委員会(MTG)に持ち込む ◦ ドキュメントを中心に事象や対応について議論 ◦ 議論の内容をもとに再発防止策を Fix
Copyright coconala Inc. All Rights Reserved. 7 このMTGが1週間で 1番重いんですよね・・・
Copyright coconala Inc. All Rights Reserved. 8 なにがそう感じさせたのか 重いと感じさせてしまっていた要素 •
ドキュメントの精度 • 雰囲気
Copyright coconala Inc. All Rights Reserved. 9 なにがそう感じさせたのか 重いと感じさせてしまっていた要素 •
ドキュメントの精度 ◦ 1稿作成に平均4時間程度 ◦ 再発防止等をきちんと考えてくる必要 があった ◦ インシデントの時系列も細かく表化す るようなフォーマットであった (右が一例)
Copyright coconala Inc. All Rights Reserved. 10 なにがそう感じさせたのか 重いと感じさせてしまっていた要素 •
ドキュメントの精度 ◦ 1稿作成に平均4時間程度 ◦ 再発防止等をきちんと考えてくる必要があった ◦ インシデントの時系列も細かく表化するようなフォーマットであった • 雰囲気 ◦ 再発防止まで記載したドキュメントのレビューが中心 ◦ どうしても対象者の処置だったり、その対策の効果に対する議論に始終してしまい、糾 弾するような空気になった ◦ 有志で集まった委員も「自分はああなりたくない」として発言しづらい
Copyright coconala Inc. All Rights Reserved. 11 障害報告委員会だった
Copyright coconala Inc. All Rights Reserved. 12 ぼくの考えるポストモーテムと障害報告の違い 項目 ポストモーテム
障害報告 目的 障害からの組織的な学び 障害の影響度合いと再発防止のまとめ 分析手法・ 範囲 原因を中心として、技術以外にも運用・プ ロジェクトも含めた多角的な視点を求める 根本原因となった点を中心とした技術的 に細かい箇所 & 横展開 ドキュメント フォーマット ある程度の柔軟性がある ほぼ固定
Copyright coconala Inc. All Rights Reserved. 13 ぼくの考えるポストモーテムと障害報告の違い 項目 ポストモーテム
障害報告 目的 障害からの組織的な学び 障害の影響度合いと再発防止のまとめ 分析手法・ 範囲 原因を中心として、技術以外にも運用・プ ロジェクトも含めた多角的な視点を求める 根本原因となった点を中心とした技術的 に細かい箇所 & 横展開 ドキュメント フォーマット ある程度の柔軟性がある ほぼ固定 ドキュメントのフォーマットも委員会の運用も 障害報告向きになってしまっていた
Copyright coconala Inc. All Rights Reserved. 14 雰囲気だけでも変えたい
Copyright coconala Inc. All Rights Reserved. 15 雰囲気だけでも変えたい • 来るまでの重さ
◦ 精度の高いドキュメントを書くために時間がかかる ◦ 通常開発をしながらその時間をなかなか捻出できない • 来てからの重さ ◦ とりあえず空気が重い ◦ なに突っ込まれるかわからない
Copyright coconala Inc. All Rights Reserved. 16 雰囲気だけでも変えたい • 来るまでの重さ
◦ 精度の高いドキュメントを書くために時間がかかる ◦ 通常開発をしながらその時間をなかなか捻出できない • 来てからの重さ ◦ とりあえず空気が重い ◦ なに突っ込まれるかわからない ネガティブポイントばかり捉えてしまうからよくない! ポジティブ要素もちゃんと一緒に振り返って「まなび」を広げたい
Copyright coconala Inc. All Rights Reserved. 17 雰囲気だけでも変えたい • ドキュメントフォーマットを一新
◦ 言葉遣いを変更 ▪ ex.) 再発防止→ アクションアイテム ◦ 学びコーナーによかったことを2つ追加 ▪ 事象に対する処置の仕方 ▪ 事故になったけど〜のおかげで被害が広 がらなかった ◦ タイムライン表記をやめる ▪ もともとSlackのチャンネルでやりとりして いるので、そのリンクを転記するだけ
Copyright coconala Inc. All Rights Reserved. 18 雰囲気だけでも変えたい • アクションアイテムは委員会でブレストする
◦ 事前になにか考えてくる必要はない(もちろん思いつくのであれば OK) ◦ 事象に詳しい人、そうでない人、俯瞰的に捉えている人で考えることは違う ◦ 「これは仕方がないよね」も1つの結論とする ▪ 相応の理由は必要であるけれど • 過去に定めた再発防止策(アクションアイテム)も見直す ◦ 無理やり生み出しただけで対応コスパが悪いものは引き下げ or 考え直し
Copyright coconala Inc. All Rights Reserved. 19 2つを変えて半年間の結果 • 明らかにメンバーからの発言が増えた
◦ 定量的な指標だが、1回につき1人 → 1回につき4~5人(全体は7~10人) ◦ メンバーから「やりやすくなった」という声 • なんでも技術で解決しようとしなくなった ◦ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では?という視点も生まれ るようになった • なによりも委員会のときの空気感が圧倒的に軽くなった ◦ 障害報告じゃないんだ、という感覚を持ってもらえている
Copyright coconala Inc. All Rights Reserved. 20 今後の課題 /展望 •
技術ライン以外のステークホルダーとの戦い ◦ 「技術的には可能ですが」→ プロジェクト/プロダクト運用の問題では?という視点も生まれ るようになった ◦ のはいいが、これをプロダクトラインに理解してもらい、施策として入れ込む必要がある • AI利活用 ◦ フォーマットとSlackスレッド / チャンネルを渡すことでいい感じのものはできる ◦ 過去のポストモーテムを学習してもらい、類似性検索等もしたい
Copyright coconala Inc. All Rights Reserved. 21 ご清聴ありがとうございました