# Evolution of Incident Management at Slack ## 概要 USENIX SREcon21（2021年10月14日）での [[Brent Chapman]]（Slack, Staff Engineer / Reliability Pillar）による発表。Slack が 2018年の reliability crisis を機に Incident Management プログラムをゼロから構築し、Major IC オンコールローテーションの運用で直面した一連の課題とその解決策を、2021年時点までの進化として時系列で説明する。登壇者自身が Google 出身で ICS（Incident Command System）を SRE 領域に持ち込んだ実践者であり、New Relic の Alice Goldfuss（[[@2016__SREcon16__nrrd 911 ic me - The Incident Commander Role]]）と並ぶ ICS 適用の初期実践事例として本 wiki に位置づく。 ## 主要メッセージ - **iMAG から Slack IM への系譜**: Chapman は Google SRE 時代に「iMAG(Incident Management At Google)」を開発・普及させた人物であり、その原型は自身が航空捜索救難パイロット・インシデントコマンダーとして学んだ公共安全機関の ICS にある(口頭説明)。Slack 入社前にはこの原則を使うコンサルティング業を営んでいた。 - **reliability crisis がプログラム創設の引き金**: 2018年9月、Slack は自己誘発型の障害が連続する「reliability crisis」に見舞われた。原因は緩いリリース体制(全エンジニアが随時本番へ直接ロールアウト、ブロッキングテスト・カナリア・ドッグフード環境なし)。この危機がリリースツール刷新(Deploy Commander 制・段階的カナリアロールアウト)・Service Ownership(旧 Ops チーム解体と You Build It You Run It への移行)・Incident Management 構築の3本柱を生んだ(p.4-9、口頭説明)。 - **Incident Management の3部構成**: Incident Response(緊急時対応)・Incident Review(事後のブレームレス学習)・Incident Analysis(複数インシデント横断の共通要因抽出)の3部として定義される(p.10 の循環図)。 - **Vision & Plan によるボトムアップ合意形成**: プログラム構築の第一歩は Vision(5項目: 重要能力としての認知・全社一貫性・全階層への浸透・育成メカニズム・ブレームアウェアなレビュー文化)と Plan(5段階の訓練体系)を文書化し、社内で議論・合意形成することだった(p.13-22)。 - **PagerDuty クラスを土台にした2階層訓練**: Awareness 訓練は不要と判明し撤回。Responder クラス(3時間)は全エンジニアが受講、Commander クラス(3時間)は目標15%に対し実績約25%(エンジニアリングマネージャー・ディレクターの約75%を含む)が受講した。両クラスは PagerDuty が公開する response.pagerduty.com のクラスを土台にする(p.23-26、口頭説明)。 - **Major IC が抱えた7つの課題と解決策**: (1) Melbourne/Dublin の小チーム負荷過多 → SF が週末対応・現地増員・Pune 追加、(2) 個人の責任過多 → 経営陣の明示支持・ピア支援・Bat Signal、(3) タスク過多で漏れやすい → IC Checklist・Incident Bot、(4) 同時多発インシデント → Slack IC ローテーション新設、(5) リソース競合 → Area Command(メタインシデント)、(6) 長期化インシデント → Slack IC 引き継ぎ・EM への引き継ぎ、(7) 特定チーム/pillar への偏在 → pillar 別 IC ローテーション(p.27-34)。 - **COVID-19/WFH の影響は限定的**: Slack はもともとインシデント対応を Slack チャンネル上で行っていたため、リモートワーク移行の実務影響は小さかった。ただし雑談による社会的つながりの毀損は意識的な補填が必要と認識された(p.35)。むしろ IC がサンフランシスコ一極集中から地理分散した効果があった(口頭説明)。 ## 視覚的に重要な図表 **p.10 Incident Management の3部構成図** ![[_attachments/srecon21-chapman-incident-mgmt-slack/page-010.png]] 中心の「Incident Management」から「Incident Response」「Incident Review」「Incident Analysis」の3つが円環状に配置される構造図。 ## 口頭説明・補足 transcript(Whisper 音声文字起こし、全301行)より、スライドに載らない背景・数値・エピソードを補足する: - **Chapman の経歴**: Google で iMAG を開発・普及。Mountain View・San Francisco・Alameda で Community Emergency Response Team のメンバー・インストラクターとしても活動。Google 退職後は同原則を使う独立コンサルタント業を営み、その後 Slack にフルタイムでリクルートされた。 - **Slack の初期沿革**: 2013年末、失敗したオンラインマルチプレイヤーゲーム「Glitch」の残骸から創業。2015年には毎週数万人規模で新規アクティブユーザーが増加。2017年には人気ツールとなった一方、指数関数的成長にインフラが追いつかず頻繁にダウンした。2018年6月までにダウンタイムが顧客離反の懸念material化し、Safety Engineering チームの採用が始まる(Chapman は2018年10月入社)。 - **reliability crisis の詳細**: 危機当時、1日に何十回も本番へのマージ・ビルド・ロールアウトが緩い調整のみで行われていた。危機後、数週間全デプロイを停止して体制を再構築。Deploy Commander(持ち回り役)がマージ・ビルド・段階的ロールアウトを担当し、まず dog food(Slack 自身のエンジニアリング/social ワークスペース)、次に 1%・10%・25%・50%・75%・100% と canary 段階を経る。各段階を数分監視し、フルロールアウトに約1時間を要する。現在は1日約12回のリリースをこの体制で実施している。 - **Service Ownership**: 旧来の Ops チームを解体し、サービスを開発するチーム自身が運用責任を持つ「You Build It, You Run It」モデルへ移行した。この移行自体は Holly Allen らが別途講演で扱っている(本資料の対象外)。 - **訓練クラスの詳細**: Responder/Commander クラスは共に PagerDuty が公開する response.pagerduty.com のクラスを土台とする。新入社員は入社後数週間~1ヶ月程度で Responder クラスを受講。既存社員は Service Ownership 移行時にチーム単位で受講した。Commander 受講は経験を積んでから任意で行う。 - **Awareness 訓練の撤回理由**: 大半の社員が十分な認知を既に持っており、オズモーシス的に習得できたため不要と判明した。 - **演習(Exercise)がパンデミックで頓挫**: 対面実施が前提の演習は Zoom に翻訳しづらく、パンデミック後に代替演習を模索中だが決定版はまだない(登壇時点)。 - **Major IC の follow-the-sun 詳細**: 当初 San Francisco・Melbourne・Dublin の3拠点。後に Pune(インド)と US East Coast を追加。週末シフト(金曜16時SF時間~日曜16時=月曜朝Melbourne時間)は全て San Francisco が担当。 - **地域間負荷格差の数値**: 初期は San Francisco に約10名、Melbourne・Dublin にそれぞれ4~5名。San Francisco は数百名のエンジニアから10名が「志願」した一方、Melbourne/Dublin は少人数から「voluntold(実質指名)」されていた。現在は San Francisco の Major IC 要員が15名に増加し、週末負荷は10分の1程度まで軽減。 - **Bat Signal の仕組み**: San Francisco・Melbourne・Pune・Dublin の4地域それぞれについて、その地域の Major IC 全員と follow-the-sun 直前地域(現地時間で夜であり起きている可能性が高い)の Major IC 全員にページする仕組み。応答義務はないが、実際には複数名が応答する文化がある。 - **Checklist Manifesto への言及**: IC Checklist の設計思想の一つとして、Atul Gawande の『The Checklist Manifesto』を明示的に引用・推奨している。 - **Incident Bot**: 社内環境に強く結合しているため OSS 化していないが、Netflix・Monzo Bank 等が類似ボットを公開していると言及。 - **中央値インシデント時間**: 直近の統計で中央値124分、約3分の2のインシデントが4時間以内に解決。 - **長期化インシデントの引き継ぎロジック**: 「数時間後・翌日に必要」という見通しが立つ問題は即応性より team resource management の性質が強く、そのため Engineering Manager の管轄とする、という判断基準が示される。 - **Incident Review の引き継ぎ規律**: Incident Commander の最後の責務は、インシデントレビュー責任を負う Engineering Manager を指名すること。この指名は「no give backs(後戻りなし)」であり、指名された EM がさらに委譲するかは EM 自身の裁量で、IC には戻さない。ブレームレス文化の推進者として Will Gallegos・[[John Allspaw]] の講演にも言及。 - **Slack ダウン時のオペレーション課題**: Slack 自身が主要インシデント対応ツールであるため、Slack 自体が落ちる(年1~2回)と対応・調整手段を失う。頻度が低いため代替運用の練度も上がりにくいという構造的ジレンマが指摘される。 ## Q&A 登壇後の質疑応答は transcript に収録されていない(音声は登壇本編で終了し、「今または後で質問を受け付ける」という案内で終わる)。 ## 概念・実体への接続 - [[Incident Commander]] — Major IC/Slack IC/Area Command という具体的なオンコール設計の実例 - [[インシデント管理]] — Response/Review/Analysis の3部構成という定義の一実装例 - [[Brent Chapman]] — 発表者。Google iMAG の設計者、Slack Reliability Pillar Staff Engineer - [[Slack Technologies]] — 本資料の主題企業 - [[PagerDuty]] — IC/Responder 訓練クラスの土台を提供 - [[ポストモーテム]] — Incident Review における EM 主導・ブレームレス文化の実例 ## 限界・不確実点 - Q&A セッションの内容は音声/スライドいずれにも収録されておらず、質疑応答の詳細は不明。 - `date_published` は USENIX の公式ページに記載の発表日時(2021-10-14 02:00, SREcon21 内のセッション枠)をそのまま採用しているが、タイムゾーン表記は USENIX ページの表示をそのまま使用しており厳密な基準時は未確認。 - pillar 別 IC ローテーションを導入済みの「2つの pillar」の具体名はスライド・音声いずれにも明示されていない。 - Slack IC の同時稼働数「最大3名」は登壇時点(2021年)の値であり、その後の変化は追跡していない。