インシデント対応 実際のとこ、どうやってるの？_SRELoungeHiroshima#1

Transcript

1. インシデント対応 実際のとこ どうやってるの？ みんなで考える障害対応のベストプラクティス 2026/02/21 SRE Lounge Hiroshima
2. 前提
3. うちはこういう組織 組織 開発組織 約20 名（専任SRE 2 名） 運⽤保守は開発と兼務 24/365 オンコール体制ではない プロダクト/ 基盤 製造業向けSaaS （B2B ） AWS ECS / Aurora 中心（監視等でEC2 ） 海外拠点・海外顧客あり インシデント対応成熟度 フロー・コマンダー体制・Runbook 整備済み ただし運⽤はまだ発展途上で人依存が残る
4. 課題と取り組み
5. 準備フェーズ 実践 重⼤度(Severity) の基準は？ 0: インシデントではない( 顧客影響なし) 1: ⼀部顧客に影響( 回避策あり/ 業務継続可能)   2: ⼀部顧客に影響( 業務影響あり) 3: 広範な顧客影響（サービス利⽤に重⼤な支障） 対応の役割分担は？ コマンダー：PFE チーム(SRE 含む) 調査・改修：開発チームローテーション       課題 インシデント対応スキルが経験依存。想定外ケースでの判断基準がブレがち。 開発計画への割込みによるコンテキストスイッチ負荷
6. 検知・初動フェーズ 実践 どんな監視ツール使ってる？ Cloudwatch 、Zabbix 、Datadog 、Slack Slack 通知にアラート種類ごとにRunbook へのリンクを付与 初動は？ 緊急度判断フローチャートでSeverity 仮置き Sev2 以上の可能性( 迷ったら“ 上げる“) → ウォールーム立ち上げ 全社インシデントスレで即時共有            課題 増えたメトリクスを取捨選択しきれておらずノイズが多い( オブザーバビリティ不⾜)
7. 対応・復旧フェーズ 実践 体制はどう決める？ 対応者はローテ対応を基本としつつ繁忙状況で柔軟に調整 社外発信はCS 経由 コマンダーと対応者は原則分離 初動の後はコマンダー何やるの？ 調査タスクの切り分け 暫定対応の優先順位整理 顧客告知内容の整理∕臨時メンテ判断 課題 初報タイミング判断が難しい( 情報を整理している間に顧客から問い合わせがくる)
8. 振り返り/ 恒久対応フェーズ 実践 コマンダー中心にふりかえりを実施( ポストモーテム) 実施しないとチケットはClose 不可 挙がった恒久対応、運⽤改善はチケット化し優先度管理下でトラッキング ふりかえりの内容は？ タイムライン整理 対応の良かった点∕改善点 根本原因分析（RCA ） 再発防⽌策の明文化 課題 繁忙期に後回しになりがち。再発防⽌がプロダクト優先度に埋もれる 組織学習として体系化できていない → PFE チームの定期的フォローとAI 整理で改善傾向
9. おわり