# What Is Incident Severity, but a Lie Agreed Upon? Navigation: [[index]] | [[インシデント重大度評価]] | [[インシデント管理]] ## 概要 USENIX SREcon24 Americas(2024年3月19日、サンフランシスコ)での [[Emily Ruppe|Em Ruppe]](当時 [[Jeli]] のプロダクトマネージャー、Jeli は登壇時点で [[PagerDuty]] に買収済み)の講演。インシデント重大度(severity)は「合意された嘘」であるという Fred Nii の言葉を出発点に、重大度を正しく定義することよりも、組織内で重大度の目的について合意することの難しさを論じる。登壇者は「重大度に唯一の正解はない」という結論から出発し、聴衆に持ち帰らせる一連の問いを提示する形式を取る。 ## 主要メッセージ - 重大度が「嘘」であること自体は問題ではなく、重大度という嘘に組織全体が合意できているかどうかが本質的な課題である(Source: transcript 00:00:16-00:02:14)。 - 重大度は「何を測定しているか」(影響 impact か、優先度 priority か)を問い直す必要がある。優先度は本質的に主観的("vibes")であり、影響と優先度を単一の計算式・マトリクスに合成しようとすると破綻する(Source: transcript 00:09:41-00:11:15、frame-006、frame-007)。 - 重大度を巡る議論が長引くのは、severity 自体の欠陥ではなく、過小評価(underleveling)・過大評価(overleveling)・ステークホルダーへの情報共有不足・組織の未成熟さといった組織的問題の兆候であり、severity は「カナリア」としてそれらの問題を歌い上げる(Source: transcript 00:16:39-00:16:57、00:28:30-00:29:11、frame-016)。 - 重大度は測定可能(measurable)・実行可能(actionable)・期待値を設定する(sets expectations)ものであるべきで、単一の重大度体系を組織全体に画一適用する(one size fits all)ことはできない。重大度には賞味期限があり、恒久的な仕組みとして固定すべきではない(Source: transcript 00:23:16-00:26:19、00:31:18-00:32:23、frame-013〜016)。 - 重大度にまつわる問題を解決する唯一の方法は、インシデント対応の最前線(sharp end)にいる実務者と直接対話することである(Source: transcript 00:32:26-00:33:49、frame-017)。 ## 映像で確認できる重要点 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-001.jpg]] frame-001(タイトル前振り)では、登壇者が「回復途上のインシデントコマンダー、現職は Jeli のプロダクトマネージャー」と自己紹介し、同僚から「インシデントレビューのボブ・ロス」と評されたという投稿(スクリーンショット)を示している。これは USENIX 公式ページのバイオ("the Bob Ross of incident reviews")と一致する。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-003.jpg]] frame-003 の手書きスライドは「INCIDENT SEVERITY IS A TAPESTRY OF TRADE-OFFS(インシデント重大度はトレードオフのタペストリーだ)」と述べ、以降の一連の問いかけパートの導入として提示される。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-004.jpg]] frame-004「CAN YOU MEASURE IT?(それを測定できるか)」は、severity が何を測定するものかを問う最初の設問群の一枚。登壇者は影響(impact)の定義が組織で合意されているか、インシデントの開始時・最中・事後のいつ測定可能かを問う(transcript 00:05:04-00:08:19)。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-006.jpg]] frame-006 は「緊急度(Urgency: Not Urgent/Urgent)」×「不確実性(Uncertainty: Known or Mostly Known/Unknown or Mostly Unknown)」の2軸マトリクスで、Bug/P3/P2/P1/P0 の5段階に分類する図。登壇者と Ryan McDonald が試作した重大度算出マトリクスで、優先度(priority)と影響(impact)を1つの数式に統合しようとした試みとして示される(transcript 00:10:31-00:11:08)。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-007.jpg]] frame-007 は frame-006 と同じマトリクスに赤字で大きく「INCIDENT MATH」と斜線バツ印を重ねたスライドで、この種の複雑な数式化アプローチを「やってはいけない」ものとして明示的に否定している(transcript 00:10:35-00:11:15。登壇者は聴衆に「このスライドの写真を撮るな」と念押ししている)。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-011.jpg]] frame-011 は "Fisher's Rule" の引用スライド:「もしインシデントかどうか迷っているなら、それはインシデントだと宣言せよ」。登壇者はこれを講演の中核メッセージの一つとして複数回反復する(transcript 00:04:13-00:04:33、00:22:20-00:22:26)。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-016.jpg]] frame-016 は「WHAT IS SEVERITY」に対する結論スライドで、"Severity is measurable / Severity is actionable / Severity sets expectations / Severity is not 'one size fits all' / Severity is a canary" の5命題が手書きで積み上げられる(transcript 00:23:16-00:29:11 に対応)。 - ![[_attachments/srecon24americas-ruppe-incident-severity/frame-017.jpg]] frame-017「TALK TO THE PEOPLE AT THE SHARP ENDS.(現場の最前線にいる人々と話せ)」は講演の結論スライド。登壇者はこれを「キャリアで得た究極の秘訣」と位置づける(transcript 00:32:26-00:33:12)。 ## 口頭説明・補足 - 登壇者は複数の実体験談(匿名化)を紹介する。あるスプレッドシート管理の outage threshold で「イベント喪失率(24時間以内)」を基準にしていたが、11年前に書かれたレガシーサービスではそもそも欠損イベントの有無を測定できなかったため、閾値自体が測定不能だった、という失敗例を挙げる(transcript 00:06:39-00:08:14)。 - 別の実体験として、"percentage of customer impact" のドロップダウンで "unknown" を2つ以上選ぶと自動的に S1 に格上げされる社内ツールの例を挙げ、severity を現場の判断から切り離した自動計算にすることの危険性を批判する(transcript 00:11:19-00:13:06)。 - 過小評価(underleveling)の背景として、severity を上げることで課される追加プロセス(action item の長期監視等)への恐れがエンジニアにあり、それが「fear(恐怖)」という組織文化上の問題だと上司から指摘された逸話を紹介する(transcript 00:17:09-00:18:29)。この恐怖と燃え尽き(burnout)の関係は、同じカンファレンスの午前セッション(Dr. Mesch の発表、原文まま)への言及とも結び付けられる(transcript 00:18:24-00:18:29)。 - 過大評価(overleveling)の弊害として、S1 に自動格上げされた結果、担当していないエンジニアやサポートチームまで10分SLAでステータスページ更新を強いられ疲弊した経験を語る(transcript 00:19:20-00:19:51)。 - [[Twilio]] が [[Jeli|SendGrid]] を買収した際、複数の組織で個別に育ったインシデント対応プログラムを単一プロセスへ統合しようとした結果、プロダクト・チームごとに severity の運用が大きく異なることが統合の最大の障壁になったと述べる(transcript 00:26:19-00:28:22)。 - 結論部では、severity 自体に「賞味期限」があり永続的な仕組みではないこと、severity の陳腐化はインシデント分析(post-incident analysis)の中で定期的に議題として扱うべきだと述べる(transcript 00:31:18-00:32:23)。 ## Q&A 映像・自動字幕からは質疑応答部分を確認できなかった(取得した自動字幕は登壇本編で終了しており、Q&A セッションの発話は含まれていない)。 ## 概念・実体への接続 - [[インシデント重大度評価]] — 本講演は同 concept の「単一レベル方式 vs. 多次元フラグ方式」の議論に、「重大度は組織的問題のカナリアである」という新たな軸を加える。 - [[Emily Ruppe]] — 本講演の登壇者(USENIX 公式ページでは "Em Ruppe" と表記、本 wiki の既存 entity は "Emily Ruppe" として登録済み)。 - [[Jeli]] — 登壇時点の所属先。講演内で [[PagerDuty]] による buyout(買収)に言及。 - [[PagerDuty]] — USENIX 公式ページの所属表記は "Jeli.io/PagerDuty"(2024年時点で Jeli が PagerDuty に買収済みであることを示す)。 - [[インシデント管理]] — severity を含むインシデント対応プロセス全体の上位概念。 ## 限界・不確実点 - 動画本体は YouTube のサンドボックス制約により自動取得できず、字幕(英語自動生成キャプション)・音声・代表フレーム17枚を個別に手動取得した(`download_status: manual-supplemented`)。 - transcript は YouTube の自動生成英語字幕であり、固有名詞([[Twilio]] の "T-Incidents" ツール名、"Fisher's Rule" の由来人物名など)は聞き取りに基づく推定が含まれる可能性がある。"Fisher's Rule" はスライド(frame-011)で確認できるため字幕の綴りより高い確度で採用した。 - 登壇者バイオ・所属・タイトル・日時は USENIX 公式ページ(https://www.usenix.org/conference/srecon24americas/presentation/ruppe )から取得し、字幕由来の情報より優先した。 - 質疑応答(Q&A)の内容は自動字幕に含まれておらず未確認。 - 代表フレームは約120秒間隔の17枚のみで、口頭説明のみに基づく主張(スライドなし区間)は本文中で transcript 由来であることを明記した。