# nrrd 911 ic me: The Incident Commander Role ## 概要 SREcon16 Americas（2016年3月）での [[Alice Goldfuss]]（[[New Relic]] SRE）による発表。New Relic が政府・軍の緊急対応フレームワーク ICS（Incident Command System）をソフトウェア運用に適応した経緯と実装を体系的に説明する。IC・TL・CL の3役分離、重大度5段階、Hubot ベースの chatbot ツール「Nrrd」、全員訓練方針を具体的なデモと失敗談を交えて解説した。 ## 主要メッセージ - **ICS の起源**: 1968年アリゾナ州フェニックスの森林火災対応から生まれた指揮体系。2004年に Homeland Security が国家インシデント管理システム（NIMS）として義務化(連邦援助受給条件)。 - **3 役分離**: IC（指令・調整・内部コミュニケーション）・TL（修復・IC への報告・重大変更の事前確認）・CL（外部コミュニケーション・顧客影響判断）は完全に別役割。IC が最も有能な修復者であれば、IC を他者に渡して TL に回るべき。 - **重大度レベル**: 1=赤「Everything exploded」2=橙「One thing exploded」3=黄「A part of a thing exploded」4=緑「A thing is smoldering」5=青「Everything is ok…for now」。Sev1 で EC(Emergency Commander)と LL(Logistics Lead)が追加解放される。 - **全員訓練**: 工学部門全員を IC 候補として、サポート部門全員を CL 候補として訓練。強制でなく任意意思で役割を担う。「信頼している」という文化的シグナルにもなる。 - **ツール**: Hubot fork の「Nrrd」で `nrrd 911 ic me` 一行で宣言・役割割り当て・チェックリスト配布を自動化。10分ステータス未更新でボットが IC に自動促進。 ## 視覚的に重要な図表 **p.10: 基本 ICS 役割図** ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-010.png]] IC を頂点とし TL と CL が並列に配置される3役構成。矢印が指揮・報告の方向を示す。 **p.22: 重大度レベル一覧（完全版）** ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-022.png]] 5段階×色のテーブル。Sev5（青）が最軽微、Sev1（赤）が最深刻。 **p.23: Sev1 拡張役割図** ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-023.png]] EC（紫）が最上位に追加され、IC 直下に TL・LL・CL が並ぶ。LL（Logistics Lead）はピザ発注・シフト管理・帰宅指示などを担う。 **p.38: Nrrd chatbot デモ（開始）** ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-038.png]] `nrrd 911 ic me` で Alice を IC 宣言。ボットが即座に IC コマンド一覧とチェックリストを返す。 **p.42: Nrrd chatbot デモ（解決）** ![[_attachments/2016__SREcon16__nrrd-911-ic-me-The-Incident-Commander-Role/page-042.png]] `nrrd 911 over` でインシデントを終了。「EMERGENCY ENDED BY @alice IN 8 MINUTES AND 9 SECONDS」と宣言開始時刻を自動記録。ボットが IC と CL にそれぞれの事後タスク（Upboard 更新・顧客リスト取得等）を配信。 ## 口頭説明・補足 transcript（Whisper）より補足: - **発端エピソード**: 「クリスマス直前に一部顧客のデータが見えなくなった」インシデントが3日かかった理由は修復でなく「誰が担当するか・誰に連絡するか・いつピザを頼むか」という調整コストだった。この経験から ICS を導入し、Alice はその推進者となった。 - **IC の役割強調**: 「IC は修復しない。修復できる最良の人物が IC なら、IC 役を他者に渡して TL になれ」と明言。役割の混在が最大のアンチパターン。 - **全員訓練の論拠**: 即採用した人間も訓練を受ければ実インシデントのパターン観察で学べる。また経験から「不快でない限り自ら IC に立候補しない」と分かったため、全員訓練が最低ラインを保証する。 - **Sev1 でのボーナス役割の説明**: EC は IC と社内ステークホルダー（マーケ・法務等）の間のリエゾン。IC が技術対応に専念できるよう会社全体の意思決定を引き受ける。LL は長期化 Sev1 でのシフト管理・帰宅指示担当。 - **教訓1 — 単一情報源**: 訓練ドキュメントとボット出力が乖離し混乱が生じた。「訓練内容とインシデント中に出るものは完全に一致させる」。 - **教訓2 — ツールが壊れる**: 「週1〜15回障害のあるチャットシステム」に依存しない。バックアップチャンネルを必ず設ける。 - **教訓3 — 反復**: ICS の最初の展開は荒かった。EC とブレームレス・レトロは後から追加。訓練は1.5時間→45分に短縮。「iterate & stick with it」。 - **ROI**: 「公開企業になり複数国にエンジニアが分散した状態での Sev1 ネットワークイベントを3時間で解決した。3日が3時間になった」。 ## Q&A（transcript より） - **Q: Hubot アダプターはオープンソース化したか?** → A: していない。CoffeeScript で容易に理解できるが OSS 化は未済。 - **Q: IC/CL はサポートチームのローテーション担当か?** → A: 工学部門の全員を IC 候補、サポート部門の全員を CL 候補として訓練。快適に担当できる人が手を挙げる形。 - **Q: 従来型 NOC はどう位置づけるか?** → A: New Relic には従来型 NOC がなく、サイトエンジニアリングチームが担う。直接影響を受けるチームの担当者、または広域障害ではサイトエンジニアリングチームが IC に就く。 - **Q: インシデント宣言しすぎを心配する文化にはどう対応するか?** → A: 対応しない。宣言を促す方向で訓練。「影響なし」で終わればそれで良い。 ## 概念・実体への接続 - [[Incident Commander]] — IC 役割定義・コアコンピテンシー・チーム構成の概念集約 - [[インシデント管理]] — ICS が位置づくインシデントライフサイクル - [[Alice Goldfuss]] — 発表者、New Relic SRE、ICS 社内導入推進者 - [[New Relic]] — ICS 導入企業、APM SaaS 会社 - [[ChatOps]] — Nrrd/Hubot を用いたチャット駆動型インシデント指揮操作 - [[ポストモーテム]] — ブレームレス・レトロが Lessons Learned セクションで強調 ## 限界・不確実点 - `date_published: 2016-03`（SREcon Americas は 2016-03-07〜09。登壇日は特定できていない） - LL（Logistics Lead）の役割名は transcript で確認済みだが、p.23 のスライドラベルは解像度の制約で完全読み取りができなかった（transcript で "logistics lead" と明言） - Nrrd の正確なコマンド体系（`nrrd 911 tl me` が TL を宣言するかどうか等）はデモスライドから確認済みだが、全コマンドは非網羅 - Whisper transcript は自動文字起こし(audio.m4a → transcript)のため固有名詞の一部が不正確な可能性がある（例: "Nrrd" が "nerd" と誤記されている箇所あり）