Mackerelにおけるインシデント対応とポストモーテム - 現場での工夫と学び

Transcript

1. ja.mackerel.io 2025.10.30 Mackerelにおける インシデント対応とポストモーテム - 現場での工夫と学び
2. 自己紹介 2 西川 拓志 （id:taxintt / @taxin_tt） 2023年3月に株式会社はてなに入社 Mackerel開発チームでEmbedded SREとして 働いています
3. はじめに インシデントレスポンスとは - インシデントが発生した際に、システム・サービスを迅速に復旧させる ためのプロセス - インシデントレスポンスの各ステップ (障害対応フォーメーションの 形成、調査 etc.) におけるハードルを下げるための仕組みが重要 ポストモーテムとは - インシデント発生後に行われるインシデントの分析・学習のプロセス - アクションアイテムの作成 “だけ” に留めないことが重要 3
4. Mackerelにおけるインシデント対応 4
5. Mackerelにおけるインシデント対応 5 アラート通知 問い合わせ インシデント かどうか? 障害対応 ポストモーテム 恒久対応 Yes 障害中 障害収束後
6. Mackerelにおけるインシデント対応 6 アラート通知 問い合わせ インシデント かどうか? 障害対応 ポストモーテム 恒久対応 Yes 障害中 障害収束後
7. Mackerelにおけるインシデント対応(1/3) (※ 前提) Mackerelのサービス基盤の監視にはMackerelを利用している - 情報経路としてはアラートと問い合わせが主 - アラート通知用のSlack channel、ユーザーからの問い合わせが流れて くるSlack channelに開発チームのメンバーが参加 - 障害と思われる事象が発生している場合は、障害対応フォーメーション を組む - 障害対応するか迷った時に、障害対応の実施要否を判定するための フローチャートを用意している 7
8. 障害対応の実施要否を判定するためのフローチャート - ユーザー影響の有無, アラートの有無で分岐 - インシデントを見逃さない方向に倒している Mackerelにおけるインシデント対応(1/3) 8
9. Mackerelにおけるインシデント対応 9 アラート通知 問い合わせ インシデント かどうか? 障害対応 ポストモーテム 恒久対応 Yes 障害中 障害収束後
10. Mackerelにおけるインシデント対応(2/3) - 障害対応は Google Meet + Cosenseを利用 - 障害対応時の情報共有は専用のSlack channelで行う - 「障害が起きたら、とりあえずこのMeetに入って、このSlack channelを見て...」 - 障害対応用のドキュメントテンプレートをCosenseで用意しており、 チェックリスト方式で初動の動きができるようにしている - 障害対応の記録用のページの作成 - 障害対応フォーメーションの形成 (役割分担 etc.) - ユーザーへの第一報の準備 10
12. Mackerelにおけるインシデント対応(2/3) 初動の動きの中には障害のSeverity判定も含んでいる - Incident Severity Levelsを定義しており、障害のSeverityをフロー チャートで判定できるようにしている - Severityを判定することで、障害対応時のエスカレーション先や役 割分担の調整などを機械的に実施できるようにした - ※ 障害対応中のSeverity変更も許容している 12
14. Mackerelにおけるインシデント対応(3/3) 初動の動きが済んだら、障害対応を行う - チームにjoinしたタイミングでSRE 1on1を実施しており、障害対応や アーキテクチャ解説など概要情報はインプット済み - 詳細情報にアクセスできるインデックス集 (Cosense) を用意 - e.g.) ログの検索方法、コンポーネントごとの調査方法 etc… - 障害対応時の定型作業などをまとめたRunbook (GitHub) も用意 - 上記のドキュメントにはアラート通知内のリンクやSlackのBookmarks から飛べるようにしている 14
15. Mackerelにおけるインシデント対応(3/3) 初動の動きが済んだら、障害対応を行う - 障害対応中に障害概要をまとめており、ユーザーへの告知作成時や ポストモーテム実施時に利用する - e.g.) 障害時間、Severity、影響内容とその範囲、原因 etc. - 障害が Resolved になったら、残タスク・申し送り事項などを書いて 障害対応フォーメーションを解散する 15
16. インシデント対応の改善事例 情報共有係 どのような課題があったか - (業務時間外、途中参加などの場合に) 障害対応の状況がわかりづらい - 障害対応の記録用のページだけだと、どの部分の記載が最新の 状況を表現しているかわからない - Mackerel開発チームはフルリモートなので、オンラインでの障害 対応において「会話の混線」を防ぎたい 16
17. インシデント対応の改善事例 情報共有係 課題解決のために何をしたか - 障害対応フォーメーションの中で情報共有係という役割を設けた - 現在の状況と今後の見込みを定期的にSlackに投稿する 17
18. インシデント対応の改善事例 情報共有係 どのような効果があったか - 現在の状況と今後の見込みがSlackに投稿されるようになった - 途中参加の場合でも障害対応の最新の状況が一目でわかる - Slackに最新の情報があるので、障害対応フォーメーションにおいて 会話が混線しない 18
19. インシデント対応の改善事例 Incident Severity Levels どのような課題があったか - 障害の重大度や恒久対応の優先度判断の基準が無かった - 障害対応の温度感や質にむらが出たり、スプリントの状況次第では 恒久対応が後回しにされることもあった - 恒久対応が完了していないことで障害が再発することも... 19
20. インシデント対応の改善事例 Incident Severity Levels 課題解決のために何をしたか - 障害の重大度を判断するIncident Severity Levelsの定義 - Mackerel開発チームでは4段階のSeverityを定義した - 障害対応フローにSeverityの判定を組み込む - 導入時には、Incident Severity Levelsに関するワークショップを実施 20
21. 21 重大度 解説 優先度 SEV1 セキュリティもしくは課金・請求に関する 問題 事後対策を最優先で行う SEV2 すべての顧客が機能を正常に利用できない もしくは Mackerelのコア機能を正常に利用 できない問題 事後対策をデフォルトで通常 のタスクよりも優先して行う SEV3 一部の顧客がコア機能以外を正常に利用で きない問題 通常のタスクも含めて開発 チームで優先度を会話する SEV4 ユーザーを苛立たせているが、顧客が機能 を正常に利用できない程度ではない問題 通常のタスクも含めて開発 チームで優先度を会話する ※ 実際のSeverityの定義から登壇用に文言の修正等を行っています
22. インシデント対応の改善事例 Incident Severity Levels どのような効果があったか - 障害対応の場面では活用できている - SEVという障害に対する共通認識ができた - 一方で、SEVの判定に迷うケースが散見されるので、フローチャー トの修正 or 機械的に判定できるような仕組みを考えたい - 恒久対応での優先度判断においては課題がある - SEVを基にした意思決定が疎かになる場面があるので、Mackerel チーム内での文化の浸透を目指していく 22
23. Mackerelにおけるポストモーテム 23
24. Mackerelにおけるポストモーテム 24 アラート通知 問い合わせ インシデント かどうか? 障害対応 ポストモーテム 恒久対応 Yes 障害中 障害収束後
25. Mackerelにおけるポストモーテム ポストモーテム用の固定時間枠をチームで合意して確保している - 障害ふりかえり帯：毎週金曜日 午後4:00～5:00 - この時間にはミーティングなどの予定を一切被せない - 遅くとも1週間以内にポストモーテムは実施できるようになる - 「鉄は熱いうちに打て」を実現できる 25
26. Mackerelにおけるポストモーテム ポストモーテムは、下記のような流れで実施する (60min) - 1) 障害概要・タイムラインの読み合わせ - 2) ~ 4) のための事実の整理 - 2) GKPT (Good, Keep, Problem, Try) - 整理された事実を分析し、チームにとっての学びを得る - 3) 恒久対応などのアクション・対策の洗い出し - 分析結果や学びを基にインシデントレスポンスの改善に繋げる - 4) 社内共有用の障害報告のアウトライン作成 + 担当者決め - 開発組織にとっての学びを得る 26
27. ポストモーテムの改善事例 恒久対応などのアクション・対策の洗い出し どのような課題があったか - ポストモーテムの品質にばらつきがあった - アクションアイテムの作成 “だけ” になってしまいがち - 参加者などに依存することなく、ポストモーテムにおける学びの 質を高く維持したい 27
28. ポストモーテムの改善事例 恒久対応などのアクション・対策の洗い出し 課題解決のために何をしたか - 事前に決められたオープンクエスチョンを利用する - e.g.) 「対応を開始してから障害の収束までの時間を短くできる余地 はありますか？」 - GKPTだけではなく、事象を分析して学びを得る際の観点を提供する 28
30. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 SRE独自の取り組みとして実施している - ポストモーテム読書会 - アラート点検会 30
31. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 どのような課題があったか - 課題ベースではなく taxin のキャッチアップとして始まったのが きっかけ - 2023年3月：入社 ~ 2023年5月：読書会の初回 - ポストモーテムを通じて、Mackerelのアーキテクチャに対する 理解を深めたい - システム・障害対応フローの課題・改善点も確認できる 31
32. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 課題解決のために何をしたか - 自チームの過去事例・社内外の障害報告を読書候補としてストックする - 過去のポストモーテムでも異なる学びを得られる (個人・チームは経験を積むと 視野・視座・視点が変化する) - 題材のポストモーテムをエクストリームリーディングする - 各自で黙読→参加者全員で議論 - 議論の結果、出てきたアクションはGitHub issueとして起票する 32
33. 33 ref: ポストモーテム読書会のすすめ - Speaker Deck
34. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 どのような課題があったか - インシデント対応において、検知 ~ トリアージ ~チームの構成を 最速で実施する上でアラートは重要な要素である - アラートを見て障害の詳細/重大度が一発でわかるのが理想 - 障害判定フローチャートでも触れたが、偽陽性のアラートが多いと疲弊 するので、改善したい - 逆に既存の監視ルールがカバーできていない部分も発見したい 34
35. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 課題解決のために何をしたか - コンポーネントなどの単位で点検対象を決めて、テレメトリーデータや 監視ルールを確認し気になるところを議論する - 過去のポストモーテムが頭に入っていると、監視自体のCoverageにも 目を向けやすい 35
36. ポストモーテムの改善事例 ポストモーテム読書会・アラート点検会 どのような効果があったか - 直近のポストモーテムの実施有無に関係なく、監視改善について考える ことができるようになった - アラートをよりアクショナブルなものにする - よりユーザー影響を正確に表現できるテレメトリーや監視設定に 改善する etc… 36
37. 最後に 「平時の取り組みが有事の対応力や学びの質を決定する」 - インシデント対応、ポストモーテムを通じた学習はプロセスに 人が介在する以上は質のバラツキができやすいのは事実 - 一方で、人に依存したり、質がバラついたままで良いかというと そんなことはない (ユーザーに対して誠実ではない) 改善のためのプロセスを設計して確実に改善に繋げましょう💪 37