悩ましき インシデント管理 @kohbis [HRMOS （BizReach）x みてね（MIXI）] SREのお悩みぶっつけ合いLT大会 2024/07/31

About Me Kohei SUGIMOTO 株式会社MIXI 2022/04 ~『家族アルバム みてね』 SRE X : @kohbis 2/16 SRE NEXT 2024はMIXIのスポンサーブースにもぜひお越しください！！！

Agenda 1. 「インシデント管理」とは 2. 『家族アルバム みてね』におけるインシデント対応フロー（ざっくり） 3. 悩ましきその①〜④ 4. まとめ 3/16

「インシデント管理」とは ● 「インシデント」とは ○ 「アクシデント（事故）」が発生する前の状況 ○ 今回は「サービスにおける定義（アラート閾値など）から逸脱した状態」とする SRE本 14章『インシデント管理』より ※1 ● “効率的なインシデント管理は、インシデントによって引き起こされる混乱を制限し、 できる限り早く通常の運用に復帰させるための鍵” ● “インシデント管理のスキルとプラクティスは、熱意ある個々人のエネルギーを正しい 方向に向けるために存在する” 4/16 ※1 https://www.oreilly.co.jp/books/9784873117911/

『家族アルバム みてね』におけるインシデント対応フロー（ざっくり） 5/16 完了 終息宣言 恒久対応/振り返り 対応 主に暫定対応 切り戻し/緩和 調査 アラート確認 エスカレーション 検知 PagerDuty/Slack オンコール制度については 『家族アルバム みてね』を支えるオンコールエンジニア制度

悩ましきその①

悩ましきその① ランブックの作成・整備不足 理想 ● 頻繁に発生する対応はランブック ● アラートメッセージにランブックURLがリンクされている 現実 ● アラート内容を確認して、慣例的な対処療法 ● 「あれ、どこにあったっけ」と社内ドキュメントを検索 できていること ● 対応手順の整備は順次実施 ● 一部はランブックURLがリンクされている 7/16

悩ましきその②

悩ましきその② 原因調査・特定までの手段が属人的 理想 ● 誰が対応してもまず確認するべきもの（ログやメトリクス）が決まっている ● 原因となった変更が即座に特定できる 現実 ● 「何を確認するか」「どう捉えるか」が属人的 ● 都度関連していそうなリポジトリの変更や開発チームに確認 できていること ● 一部は手順化されている ● 「すぐにエスカレーション」が根付いており （場合によっては）即座に担当チームがロールバック 9/16

悩ましきその③

悩ましきその③ インシデントコマンダー不在 理想 ● インシデントコマンダー（「作業」せずに「意思決定」することが役割）が旗振り ● ウォールーム（対応指揮室）で統制 現実 ● Slackのアラート通知チャンネルでそのまま会話してしまいがち ● 何度目かの「あれ、いま誰がなにやってるんでしたっけ？」 できていること ● 最低限決まっていること（エスカレーションなど）は実施 ● 作業、確認作業について順次Slackに投稿 ● （誰かが言い出せば）対応専用のSlackチャンネルを作成 11/16

悩ましきその④

悩ましきその④ ポストモーテム作成が後回し 理想 ● ライブインシデント状況ドキュメントが作成されている ● インシデントの対応内容からポストモーテムが（自動）生成される 現実 ● とにかく暫定対応が優先されて後回し ● 対応が落ち着いた、完全復旧待ちの時間で作成 できていること ● テンプレートが全体に共有され、随時改善 ● SREチームだけでなく（インシデントの規模に関わらず） ポストモーテムを書く文化が根付いている 13/16

まとめ

まとめ ● 『家族アルバム みてね』の場合、対処療法になっている部分が多い。 ● インシデント対応中は復旧が最優先。 明確に場を作らなければ振り返らない ● このスライド作成時にチーム内にヒアリングしてあらためて出てきた課題もあった ● あくまでも「できる限り早く通常の運用に復帰させる」（再掲）ことが前提 ● インシデント管理フローを改善することによるさらなるメリット ○ 新メンバーのキャッチアップ/SREチーム以外への移譲 ○ ランブック作成/整備 恒久対応/自動復旧 やっていき!!!（たい...） 15/16

No content