# Storytelling as an Incident Management Skill Navigation: [[index]] | [[sources/_index]] ## 概要 [[Laura de Vesine]]([[Datadog]] スタッフエンジニア)が SREcon24 Americas(2024-03-20、サンフランシスコ)で行った20分の発表。デバッグ・コミュニケーション・プロジェクト管理と並ぶ「ストーリーテリング」という技能に焦点を当て、Joseph Campbell の「英雄の旅」のような人物中心の物語形式ではなく、**設定(システム)の中で因果の論理によって連なる出来事の物語**を組み立てる技能こそが、オンコール準備・インシデント対応中・ポストモーテム作成のすべての段階を支えると論じる。(Source: 公式ページ抄録) ## 主要メッセージ - 「英雄の旅」に代表される人物中心の物語構造は、本発表が扱う「ストーリーテリング」ではないと明示的に否定する。代わりに採用する narrative の定義は「出来事の連なりであり、ランダムではなく因果の論理(cause and effect)で結ばれた順序だった一連の出来事」である。良い narrative の構築はシステムに詳しくない相手への説明を助けるだけでなく、自分自身がシステムの障害の論理を分析する助けにもなる。(Source: スライド p.2-3) - 「An Incident Narrative」の例(p.4)は、a(Producer)→b(Deduplication)→c(Consumer)の3サービス構成を使い、narrative 構築の型を示す: (1)舞台設定としてサービス構成を説明する、(2)気づいた事象(c が受信停止)を起点に、そこが論理連鎖の最初ではないと考え時間を遡って原因を探る(c の異常 → b の過負荷 → a のブロッキング挙動という因果)、(3)時間を進めて短期緩和(b のスケールアップ)と長期対策(動的シャーディング、デッドレター機構)を語る。この narrative は「対応者(us)」による行動は含むが、人物描写("characters")には乏しいことを本人が指摘する。 - インシデント対応中も「協調的ストーリーテリング(collaborative storytelling)」としてこの技能を使う。トリガーが「なぜ a が b につながるのか」という論理連鎖の説明であることに焦点を当てると、次に何をすべきか分からず行き詰まった対応者を「動けるようにする(unstick)」。具体例として、パイプラインの遅延インシデントで「カフカからの読み込みが原因か、下流への書き込みが原因か」で行き詰まった対応者が、サービスの動作を物語として振り返ることで「不正な正規表現がコミットを妨げていた」という結論に至った例を挙げる。(Source: スライド p.11、口頭説明) - 人物中心の物語(いわゆる character-driven な物語)を完全に否定するわけではなく、**目的によって使い分ける**と整理する。オンコール準備における「ページされた時にどう感じたか」を共有する共感構築のストーリー(pager stories)や、Wheel of Misfortune 演習は意図的に人物・感情中心であってよく、論理進行ではなく感情の正規化・共有が目的である。この使い分けは単一ソースの中の対比だが、[[インシデントストーリー]] 概念で扱う「物語形式の複数用途」を考える上で重要な補助線になる。(Source: スライド p.8-10) - 「エンゲージングなポストモーテム」の5段階構成: (1) 舞台設定(サービス構成・チームの運用実態を共有)、(2) ドラマの追加(影響の共有、または「実は foo サービスには特定条件でクラッシュする欠陥があった」のような潜在的な欠陥の開示のいずれか。登壇者自身は後者を好むと明言)、(3) 出来事を連鎖させる(トリガーから始めてシステムへの影響を論理進行で1歩ずつ説明)、(4) 対応の説明(赤いニシンや行き止まりも含め、なぜその対応が論理的だったかを説明)、(5) 修正計画(action item)。(Source: スライド p.12-18) - 「どちらか一つしか残せないなら」という設問に対し、登壇者はトラブルシューティングの経緯(troubleshooting narrative)よりも**システム内の出来事の連鎖(chain of events)**を残すことを明確に選ぶと述べる。理由は「人間は直せないが、システムは直せるかもしれないから」であり、出来事の連鎖さえあれば各リンクごとに体系的な再発防止策を検討できるとする。(Source: スライド p.17、口頭説明) ## 視覚的に重要な図表 **p.2 「英雄の旅」の明示的な否定** ![[_attachments/srecon24americas-devesine-storytelling/page-002.png]] Joseph Campbell の「英雄の旅」図に赤い禁止線を重ね、本発表が扱う「ストーリーテリング」がこの人物中心・冒険譚の構造を指すのではないと明示する。 **p.4 An Incident Narrative(a→b→c の三段構成図)** ![[_attachments/srecon24americas-devesine-storytelling/page-004.png]] Producer(a)→Deduplication(b)→Consumer(c)の構成で、時間を遡って原因(b の過負荷、a のブロッキング挙動)を探り、時間を進めて対応(短期緩和・長期対策)を語る narrative 構築の型を示す。 **p.11 「During an Incident」— 対応中の協調的ストーリーテリング** ![[_attachments/srecon24americas-devesine-storytelling/page-011.png]] インシデント対応中、システムの動作を物語として振り返ることで行き詰まりを解消する例。口頭説明では、正規表現によるパイプライン遅延インシデントで、カフカ読み込み由来か下流書き込み由来か分からず行き詰まった対応者が、「各サービスは一定バイト数まで Kafka から読み込み、下流にコミットできるまで以降の読み込みを一時停止する」という動作の物語を辿ることで不正な正規表現に到達した経緯を説明する。 **p.18 An Engaging Postmortem(5段階の完成形)** ![[_attachments/srecon24americas-devesine-storytelling/page-018.png]] 「舞台設定 → ドラマの追加 → 出来事の連鎖 → 対応の説明 → 修正計画」という5段階すべてが列挙された最終形のスライド(スライド上のページ番号は 16 だが、レンダリングされた PDF ページ番号は 18。ビルド/リビール形式で同じ骨子が複数ページに分割されているため)。 ## 口頭説明・補足 - 5段階のうち(2)ドラマの追加は、影響の共有(「ユーザーがサイトを読み込めずページされた」)と、潜在的な欠陥の開示(「実は foo サービスには rickroll の投稿を試みるとクラッシュする性質がある」「当初このサービスを構築した際、顧客ごとに専用シャードへ分離したが、ホットスポット化のリスクは承知の上で当時は許容可能と判断した」)のいずれかの形を取り得る。登壇者は後者を好むと述べ、前者から始めると自分自身がついトラブルシューティングの経緯を語りたくなる誘惑に駆られると付け加える。(Source: 口頭説明、スライド p.15) - 口頭説明では、キャッシュ層のメモリ不足インシデントの例も語られる。チームは「並列ファイル処理で大量結果のクエリが過負荷を招く」といういつものパターンだと仮定したが、キャッシュのスケールアップは効果がなかった。対応者は既知の「並列ファイル処理が過負荷を招く」という物語を手がかりに、キャッシュ層のエラーか、その背後のサービスのエラーか、特に大きなファイルの読み込みか、特に並列度の高いクエリかを1つずつ検証し、最終的には自動化ツールが実行した病的に大きな1件のクエリが原因だと突き止めた。既知の物語がむしろ仮説の反証・絞り込みに役立った例として言及される。(Source: 口頭説明、transcript.md) - インシデント対応中の narrative は、次の行動を導く「ハンドオフ」としても機能する。「なぜこの行動を取り、どんな結果が得られたか」を淡々と述べることで、途中から加わった対応者にも次に何を試すべきかが自然と見えてくると説明する。(Source: 口頭説明) - オンコール準備における人物中心の物語(パイプストーリー)の目的は、論理進行ではなく感情の共有・正規化であり、「インシデント中に一番怖かったこと」「壊した中で一番ひどかったこと」のようなプロンプトが有効だと述べる。この物語は Wheel of Misfortune 演習をシステムの物語として運営できるようにする土台にもなる。(Source: 口頭説明、スライド p.8-10) ## Q&A 質疑応答パートは口頭説明の締めくくり付近から文字起こしが不明瞭になり、ほぼ聴取不能である。transcript.md の末尾は「And that's it.」の直後に質問への言及とみられる断片が続くが、内容を再構成できるだけの精度がない。質疑の内容は不明として扱う。 ## 概念・実体への接続 - [[Laura de Vesine]] — 本発表を単独登壇。過去2回の SREcon 発表(根本原因分析の安全工学モデル、Datadog 大規模インシデントの舞台裏)に続く3件目の登壇として追加。 - [[Datadog]] — 登壇者の所属。具体例に登場する Producer/Deduplication/Consumer パイプラインとキャッシュ層インシデントは、いずれも自社サービスでの経験に基づく(サービス名は匿名化されている)。 - [[インシデントストーリー]] — 因果論理の narrative と人物中心の narrative を目的別に使い分けるという整理、および「対応中の協調的ストーリーテリング」という新しい用途を追加。 - [[ポストモーテム]] — 「エンゲージングなポストモーテム」の5段階構成を追加。 ## 限界・不確実点 - スライド上に印字されたページ番号(例: p.16)と、PDF レンダリングのファイル連番(page-018.png)が一致しない。ビルド/リビール形式のスライド(同じ骨子を1段ずつ追加表示する複数ページ)が個別の PDF ページとして書き出されているためで、本文中の "p.N" はスライド上表示の番号を優先して記載した。 - 質疑応答の内容は文字起こしの精度不足によりほぼ再構成不能。何が問われたかは不明のまま残す。 - 具体例に登場するサービス名(a/b/c、foo サービス等)はいずれもプレースホルダーまたは匿名化されており、実際の Datadog 内部サービス名は特定できない。