# Incident Response @ FB, Facebook's SEV Process Navigation: [[Incident Commander]] | [[インシデント重大度評価]] | [[クロスインシデント分析]] | [[インシデント管理]] ## 概要 [[Gareth Eason]]([[Facebook]])による SREcon16 Europe(2016年7月12日、Dublin)の発表。Facebookにおけるインシデント管理の基本フロー(Discoverer=Owner、IMOCへのエスカレーション)、学習の仕組み(SEV Manager、二段階のレビュー体制、3つの質問)、そしてブレームレス文化とメトリクスゲーミングへの警告を、実際のカナリア事故の実例を交えて紹介する。 ## 主要メッセージ - **Discoverer is the owner**: インシデントを発見した人(監視・アラート・ページで気づいた人)がまずそのインシデントの所有者になる。ワンライナーで直せる規模ならその場で修正し、大きければ IMOC にエスカレーションする。 - **SEV1/2/3 の意図的な過大分類バイアス**: リスクがあれば SEV1 とラベル付けし、広く伝達したうえで後から SEV2/SEV3 に格下げする運用を推奨する。過小分類より過大分類の方が安全という価値判断。 - **IMOC(Incident Manager On Call)の explicit non-goal**: IMOC は「技術的にインシデントを直さない」ことが明示された役割。フレッシュな視点の提供、複数人が競合して手を出す際の「人間のミューテックス」、コミュニケーション経路の一本化、必要な人員の招集、そして「ブレームアンブレラ」(エスカレーションした人が以後は技術対応に専念できる盾)を担う。 - **SEV Manager**: 進行中・過去のインシデントの単一の真実源(single source of truth)となる中央プラットフォーム。オンコール担当・インシデントオーナー・IMOC・ステータス・関連グラフを一箇所に集約し、レビュー会議の管理機能も兼ねる。 - **二段階レビュー**: まずチーム内・サービス固有の深堀りレビューで根本原因分析を行い、その後 Production Review(全社横断・広い招待リスト・双方向の議論)でパターンとアンチパターンを共有する。 - **3つの質問**: Production Review で毎回問う質問は「(1) 影響は何だったか」「(2) どのように起きたか(根本原因分析)」「(3) 次にどう防ぐか」。 - **ブレームレス文化**: 誰もが SEV を起こしうる。真摯に仕事をしている限り、SEV を起こしたことで解雇されることはない。この文化が正直な報告を支える。 - **メトリクスゲーミングへの明示的警告**: 「SEV 数が減ること」を単純な成功指標にすると、エンジニアがインシデントを過小分類・過小報告するインセンティブを生む「悪いメトリクスの典型例」だと明言している。 - **カナリア事故の実例**: あるチームがカナリアロールバック手順を実行した際、通常のレートリミットが適用されず、本来 1% 未満のはずの操作が全世界でサービスを再起動する重大インシデントに発展した。この事例を Production Review で共有したところ、同じ手順を使っていた少なくとも4チームがその場で気づき、同種の事故を未然に防いだ。 ## 映像で確認できる重要点 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-001.jpg]] frame-001(00:01:00 時点)は講演冒頭の広角ショット。この動画は固定広角カメラ1台のみで撮影されており、右端のスクリーンはごく一部しか映らない。以降のフレームも含め、スライドの大半は画角外にある。 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-002.jpg]] frame-002(00:10:00 時点)ではスクリーン右端に "SEVer…" というタイトルの断片と "SEV1, …" という文字列が見える。SEV1/2/3 の分類を説明する箇所(transcript 00:09:00 前後)に対応するスライドだと推測されるが、タイトル全体・本文は画角外で確認できない。 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-003.jpg]] frame-003(00:14:00 時点)では青系・黄色系に色分けされた行を持つ表の右端が見え、"SEV" という表記が縦に並ぶ。SEV Manager 上のインシデント一覧(ステータス別の色分け)を映した画面だと推測されるが、行のテキストはほぼ判読不能で内容は確認できない。 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-004.jpg]] frame-004(00:20:00 時点)では4人の顔写真が線でつながれた図の一部が見える。IMOC・インシデントオーナーなど役割間の関係を示す図だと推測されるが、ラベルテキストは画角外・不鮮明で確認できない。 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-005.jpg]] frame-005(00:24:50 時点)では青・赤・オレンジ・緑に色分けされたグリッド状のグラフが見える。メトリクスゲーミングの警告(transcript 00:25:34 前後、「SEV 数が増えているように見えるグラフ」への言及)に対応するトレンド表示だと推測されるが、軸ラベル・数値は確認できない。 - ![[_attachments/srecon16europe-eason-fb-sev-process/frame-006.jpg]] frame-006(00:37:30 時点)は Q&A の場面。演台の Gareth Eason に加え、手前に質問者とみられる聴衆が映る。 ## 口頭説明・補足 ### インシデント管理の基本フロー インシデントは監視・アラート・ページのいずれかで発見され、発見者(discoverer)がまずそのインシデントの所有者(owner)になる。ワンライナーで直せる規模ならオンコール担当がその場で修正し、それ以上の規模であれば IMOC にエスカレーションする。エスカレーション後、オンコール担当は「技術修正」に専念し、IMOC が「コミュニケーションと、過度なステータス要求からの保護」を引き受ける。 SEV の分類は SEV1(最も深刻)〜SEV3(軽微)の3段階。リスクがあれば SEV1 に倒して広く伝達し、状況が判明するにつれ SEV2/SEV3 に格下げする運用を推奨する。過小分類より過大分類の方が安全という判断による。 ### IMOC の役割と「ブレームアンブレラ」 IMOC(Incident Manager On Call)は特定サービス群を担当するオンコールのサブジェクトマターエキスパート兼ジェネラリストの集団。IMOC の重要な特徴は「インシデントを技術的に直さないことが明示された non-goal」である点だ。IMOC が担うのは、新しい視点の提供、複数人が同時に対処しようとした際に「まずこの案を試そう、他は待って」と裁定する「人間のミューテックス」役、コミュニケーション経路(会議ブリッジ・IRC チャンネル)の一本化、必要な人員を招集して war room を組成すること、そして過度なステータス要求から技術対応者を守る「アンブレラ」機能である。 Eason はこの保護機能を「ブレームアンブレラ(blame umbrella)」と呼ばれることがあると紹介した。一度 IMOC にエスカレーションすれば、エスカレーションした人は「もう自分の責任範囲を離れた」と感じて技術対応に専念できる、という趣旨。IMOC は必要に応じて他の IMOC を巻き込み、定期的なコミュニケーションの継続とインシデントの解決・周知を保証する。 ### ツール: IRC・SEV Manager・Messenger インシデント管理で最も重視されるのは「学習のためのデータ収集」ではなく「インシデントを直すこと」だが、ツールはその過程で自然にデータを蓄積するよう設計されている。IRC はコミュニケーション手段であると同時に、発言ごとにタイムスタンプが付くログとしてタイムライン再構築に使われる。 SEV Manager は進行中・過去のすべてのインシデントに関する単一の真実源(single source of truth)となる中央プラットフォームで、レビュー会議の管理機能も兼ねる。オンコール担当・インシデントオーナー・IMOC の割り当て、ステータス(対応中・ワークアラウンドあり・解決済み)、関連グラフへのリンクを一箇所に集約し、解決後にはインシデントレポートを記入する場にもなる。 社内チャットツールである Messenger も日常的なコミュニケーションに使われるが、Facebook のプラットフォーム自体が落ちた場合に Messenger や社内 IRC(社内ネットワークに依存)も道連れで使えなくなるリスクがある。そのため、サードパーティ提供のカンファレンスラインなど、社内インフラと共通の障害点を持たない「アウトオブバンド」の通信手段を別途確保している。 ### 二段階レビューと3つの質問 レビューは週次で最大2段階行われる。第一段階はチーム内・サービス固有の深堀りレビューで、専門知識を持つチームが根本原因分析とチーム固有の教訓を扱う。第二段階が Production Review で、招待リストは広く(エンジニアリング・インフラストラクチャの誰でも参加可能)、双方向の議論として運営される——参加者自身も自分のサービスで経験したインシデントの知見を持ち寄る。 Eason が Production Review で毎回問う3つの質問は「(1) 影響は何だったか、それが Facebook 全体にとって何を意味したか」「(2) どのように起きたか(古典的な根本原因分析、どの事象の連鎖がこのインシデントを招いたか)」「(3) 次にどう防ぐか(連鎖を断ち切れば同種のインシデントを防げる)」。この共有により、他チームの障害を先取りして検知したり、アンチパターンを他チームで発生する前に修正したりできる、と説明する。 運用面では、EMEA 向けと米国メンロパーク向けの2つの Production Review 会議に分けて実施しており、Eason 自身が EMEA を、同僚(音声上 "Nick Nicard" と聞こえる人物)が米国側を運営している。会議は週1回・最大90分の枠を確保するが、実際にレビューする件数は1〜6件程度で、通常60分程度で終わる。レビュー対象は取捨選択されており、「pre-commit hook を入れる」のような既知の教訓で他チームが既に対応済みの軽微なインシデントは、この場では扱わずチームレベルのレビューに委ねる。 ### ブレームレス文化とメトリクスゲーミングへの警告 Facebook の文化は「ブレームレス」であると明言される。誰もが SEV を起こしうるし、実際起こす。真摯に仕事をしている限り、SEV を起こしたことで解雇された人はいないし今後もない、という方針が公言される。この心理的安全性が、正直な報告と率直な議論(「自分はこうすればこうなると思ったが、実際にはこの恐ろしいことが起きた」)を可能にしている。 一方で Eason は明確な警告を発する。SEV 数のトレンドグラフに対して聴衆から「SEV 数が増えているように見えるが、良いことなのか」というコメントがあった。Eason はこれを「悪いメトリクスの典型例」だと述べ、「SEV 数を減らすことを成功指標にする」と、エンジニアがインシデントを SEV1 ではなく SEV2/SEV3 として過小分類したり、そもそも報告しなくなったりするインセンティブを生んでしまう、と説明した。ブレームレス文化とメトリクスの健全性を維持することの両立が重要だと強調している。 ### カナリア事故の実例 あるチームが標準的なカナリアプロセス(全体の1%未満にまず新バージョンをデプロイする手法)で新バージョンをリリースしたところ、カナリア対象での不具合を検出し、以前使っていた手順(一部変更あり)でカナリアをロールバックしようとした。本来ならカナリア対象のサーバのみを再起動して本番バージョンに戻すはずだったが、実際にはこの「カナリア再起動」に通常のレートリミットが適用されず、世界中の全サーバでサービスが即座かつ不可逆的に再起動されるという重大インシデントに発展した。 サービス自体は復旧したが、Eason が強調したのはこの事故そのものよりも、Production Review でこの事例が共有された際の反応だった。同じ会議室にいた少なくとも4つの他チームが「まさに自分たちも同じ手順を使っている」と気づき、その場で対応した。つまり1回の Production Review が、少なくとも4件の同種インシデントを未然に防いだことになる。 ### 効果の定量化という未解決課題 Eason は講演の終盤で、SEV 数・分類の推移データは failure budgeting やシステム安定性分析に有用だとしつつ、「防いだインシデントの手柄をどう主張するか」は SRE 業界共通の難題だと認めた。複数回・相互に関連するインシデントのデータ収集は現状ほぼ手作業であり、自動化が今後の課題として挙げられている。 ## Q&A - **アクションアイテムの追跡方法**: バグトラッキングシステムで追跡すると同時に、SEV Manager 上でもフォローアップタスクとしてリンクされる。2件目のインシデントが1件目の未完了アクションアイテムに起因すると分かった場合、これを重く受け止めて優先度を引き上げるトリガーにする。 - **1週間に多数のインシデントが出た場合の選別方法**: 現状はほぼ手作業で選別している。EMEA と米国メンロパークの2つの Production Review に分割して負荷分散しており、既知の教訓(例: pre-commit hook 導入)で他チームが既に対応済みの軽微なインシデントはレビュー対象から外す。 - **フォローアップ作業の徹底方法(エンジニアを追い回す必要はないか)**: 基本的には「同じ会議で同じ話を繰り返したくない」という人間心理と組織文化に依存している。加えて優先度別(高優先度は速やかな修正が必須)のバグ分類と、軽い自動リマインダー(nag)の仕組みも併用している。 ## 概念・実体への接続 - [[Gareth Eason]] — 登壇者。Facebook 入社前は Google、その前は HEAnet(アイルランドの国立研究教育ネットワーク)に所属。 - [[Facebook]] — SEV プロセス・Production Review の実践組織。既存の [[Pedro Canahuati]] による SREcon15 講演(週次金曜 SEV レビュー)を1年後の視点から補強する。 - [[Jay Parikh]] — 週次 Production Review に同席する幹部として言及される(本ソースでは "head of infrastructure" と紹介)。 - [[Pedro Canahuati]] — 大半の Production Staff Review に同席する幹部として言及される(本ソースでは "head of engineering" と紹介)。 - [[Incident Commander]] — IMOC は New Relic の Incident Commander と同型の「技術的に直さない・調整に徹する」役割。「ブレームアンブレラ」という用語も共通する。 - [[インシデント重大度評価]] — SEV1/2/3 への意図的な過大分類バイアスという具体的運用ポリシー。 - [[クロスインシデント分析]] — Production Review はチーム横断の学習を制度化した実践例。 - [[インシデント管理]] — Discoverer=Owner・IMOC エスカレーション・二段階レビューという一連のライフサイクル。 ## 限界・不確実点 - この動画は固定広角カメラ1台のみで撮影されており、スクリーンの大部分が画角外にある。取得した6枚の代表フレームでもスライドのタイトルや本文はごく一部の断片しか読み取れず、多くの内容は登壇者の口頭説明のみに依存している。 - 文字起こしは YouTube の自動字幕(auto-caption)であり、人手による校正を経ていない。"imoc"(Incident Manager On Call)や "sev"、"Canahuati" のような固有名詞・略語の綴りは前後文脈からの推測を含む。 - 公式 USENIX ページにはタイトル・登壇者名(Gareth Eason, Facebook)・BibTeX 書誌情報のみが掲載されており、abstract 本文は存在しない。`date_published`(2016-07-12)は、本編冒頭の「day two」という発言と、SREcon16 Europe の開催期間(2016年7月11日〜13日、Dublin)から推定した値であり、公式ページに明記された講演日ではない。 - Q&A の質問者は自動字幕上で氏名が示されておらず、誰が質問したかは不明。 - 講演冒頭で司会者を "Kurt" と呼ぶ場面があるが、姓の記載がなく本人を確定できないため entity 化していない。 - 米国メンロパークの Production Review を運営する同僚として音声上 "Nick Nicard" と聞こえる人物が言及されるが、綴り・所属の裏取りができないため entity は作成していない。