第１回関西SREコミュニティスライド構成

# スライド構成ノート — アラーティングをどう進歩させるのか？ [[第１回関西SREコミュニティ登壇アウトライン]] に基づくスライド設計。全15枚・15分。理論と実践をフェーズごとに束ね、聴衆が原則を聞いた直後にその照合結果を見る構成。 --- ## Slide 1: タイトル（§1 導入、〜10秒） **レイアウト**: 中央揃え、余白大きめ ``` ┌──────────────────────────────────────────┐ │ │ │ アラーティングをどう進歩させるのか？ │ │ — 最先端とのギャップ分析 │ │ │ │ │ │ 坪内佑樹 │ │ ホンマでっかSRE勉強会 #1 2026-07-18 │ │ │ └──────────────────────────────────────────┘ ``` - タイトルは2行構成。メインタイトルを大きく、サブタイトルをやや小さく。 - 所属は「さくらインターネット研究所」 --- ## Slide 2: アラーティングの重要性（§1、〜50秒） **レイアウト**: 上に「SDLCの消滅」図、下に逆説の帰結 ``` ┌──────────────────────────────────────────┐ │ AIの時代でもアラーティングは消えない │ │ │ │ "The Software Development Lifecycle │ │ is Dead" │ │ │ │ ┌──────────────────────────────────┐ │ │ │ Requirements ░░░░░░░░░░░░░░░░░ │ │ │ │ Design ░░░░░░░░░░░░░░░░░ │ │ │ │ Development ░░░░░░░░░░░░░░░░░ │ │ │ │ Testing ░░░░░░░░░░░░░░░░░ │ │ │ │ Deployment ░░░░░░░░░░░░░░░░░ │ │ │ │ ★Monitoring ████████████████★ │ │ │ └──────────────────────────────────┘ │ │ SDLCの中で Monitoring は最後まで残る │ │ │ │ 自動化が進むほど、予期しないイベントで │ │ 人間/エージェントに制御が戻る │ │ → その起点は「アラート」 │ │ Bainbridge 1983 / Google SRE 2026 │ └──────────────────────────────────────────┘ ``` - SDLCの各フェーズを横棒グラフ風に並べ、Monitoring以外をグレーアウト（░）、Monitoringを塗りつぶし（█）+★で強調。 - 下部にBainbridge 1983の「自動化の逆説」とGoogle SRE 2026のAgentic AIを組み合わせ、「アラーティングの品質が初動を大きく左右する」で締める。 **脚注引用**: "The Software Development Lifecycle is Dead," 2026 / Bainbridge, "Ironies of Automation," *Automatica*, 1983 / Papapanagiotou+, "AI in SRE," *Google Cloud Blog*, 2026 --- ## Slide 3: 発表概要（§1、〜30秒） **レイアウト**: 上に概要、下に3つの問い ``` ┌──────────────────────────────────────────┐ │ 本日の発表 │ │ │ │ 多数の論文・SREcon講演等の文献から、 │ │ アラーティングのライフサイクルを │ │ 4フェーズで整理し、7つの設計原則を抽出した。 │ │ │ │ 自身が設計・運用する │ │ マネージドHPC/AIサービスの │ │ Grafana Alerting設計を │ │ フェーズごとに照合し、 │ │ ギャップをどう埋めるかを示す。 │ │ │ │ ┌──────────────────────────────────┐ │ │ │ 最先端はどこにあるのか？ │ │ │ │ 自分たちはどこにいるのか？ │ │ │ │ どう進歩させるのか？ │ │ │ └──────────────────────────────────┘ │ └──────────────────────────────────────────┘ ``` - 上部に「文献→4フェーズ→照合→ギャップ→埋め方」の論理構成を提示。 - 下部にコールアウトボックスで3つの問い。聴衆がこの3問を頭に置いて聞ける構造。 - この3問の構造自体がキーメッセージ（最先端を体系的に整理すれば、場当たり的改善から体系的ギャップ充填へ転換できる）の伏線。Slide 15 で回収。 --- ## Slide 4: 4フェーズモデル（§2、〜40秒） **レイアウト**: 上にパイプライン図、下にフェーズごとの設計問い ``` ┌──────────────────────────────────────────┐ │ アラーティングの4フェーズモデル │ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │A.保証 │→│B.抑制 │→│C.配信 │→│D.解決 │ │ │ │ │ │ │ │ 最適化│ │ 支援 │ │ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │ ───────── 横断: 品質 ───────── │ │ │ │ A 何で鳴らすか？本当に鳴るか？ │ │ B 不要な発火をどう減らすか？ │ │ C 誰に、どう届けるか？ │ │ D 受け手が何をするか？ │ │ 横断品質をどう測るか？ │ │ │ │ ★ Aが壊れていれば、B以降を │ │ どれだけ磨いても意味がない │ └──────────────────────────────────────────┘ ``` - A→B→C→Dを水平の矢印パイプラインで描く。横断は点線の帯として全幅に走らせる。 - 各フェーズの設計問いを箇条書きで端的に。原則番号は出さない。 - 「Aが壊れていれば〜」を赤字で強調。Phase Aのボックスだけ赤枠。 --- ## Slide 5: 照合対象のサービス（§2、〜30秒） **レイアウト**: 中央にシステム構成の概略図 ``` ┌──────────────────────────────────────────┐ │ 照合対象: マネージドHPC/AIサービス │ │ │ │ ┌──────────────────────────────────┐ │ │ │ [User] ─→ [Login] ─→ [Slurm] │ │ │ │ │ │ │ │ │ │ │ [LDAP] [GPU Nodes] │ │ │ │ [Lustre] │ │ │ │ [RoCE NW] │ │ │ └──────────────────────────────────┘ │ │ │ │ • Grafana Alerting で監視 │ │ • 1チーム運用 │ │ • GPUノード、Lustreストレージ、 │ │ RoCEネットワーク、Slurm、LDAP │ │ │ └──────────────────────────────────────────┘ ``` - 簡潔な構成図。ユーザーからジョブ投入までの主要経路を5–6ノードで描く。 - 「Grafana Alerting」「1チーム運用」を明記。 - 過度に詳細にしない。聴衆が「どういう環境か」を一瞬で把握できればよい。 --- ## Slide 6: ギャップ全体像（§2、〜30秒） **レイアウト**: ギャップテーブル + Phase A 強調 ``` ┌──────────────────────────────────────────┐ │ 4フェーズモデルに照合したギャップ │ │ │ │ ┌─────────┬──────────────────────────┐ │ │ │ フェーズ │ ギャップ │ │ │ ├─────────┼──────────────────────────┤ │ │ │★A.保証 │ SLO/バーンレート未導入 │ │ │ │ │ CI検証なし・常設カナリアなし│ │ │ │ B.抑制 │ — │ │ │ │ C.配信 │ ML系は意図的に対象外 │ │ │ │ D.解決 │ 自動収集/RCA/エージェント未着手│ │ │ │ 横断(品質)│ QoA/コストモデル未導入 │ │ │ └─────────┴──────────────────────────┘ │ │ │ │ → Phase A にギャップが集中 │ │ ここから Phase A を掘り下げる │ └──────────────────────────────────────────┘ ``` - テーブルの Phase A 行を赤背景で目立たせる。B・C行はギャップなし/対象外でグレー。 - 「Phase Aにギャップが集中」を太字で。ここから Phase A ブロックへ入る導線。 --- ## Slide 7: 症状で鳴らす、原因では鳴らさない（§3 Phase A 理論、〜1分） **レイアウト**: 左右2カラム比較 ``` ┌──────────────────────────────────────────┐ │ Phase A: 症状で鳴らす、原因では鳴らさない │ │ │ │ ┌────────────────┐ ┌────────────────┐ │ │ │ ❌ 原因起点 │ │ ✅ 症状起点 │ │ │ │ │ │ │ │ │ │ CPU > 90% │ │ エラーレート │ │ │ │ Disk > 85% │ │ > バーンレート │ │ │ │ OOM 発生 │ │ │ │ │ │ │ │ 「顧客が影響を │ │ │ │ → 組み合わせ爆発 │ │ 受けている」 │ │ │ │ → 手動チューニング│ │ で鳴る │ │ │ └────────────────┘ └────────────────┘ │ │ │ │ 4 Golden Signals → Multi-burn-rate SLO │ │ Ewaschuk 2016 Thurgood+ 2018 │ └──────────────────────────────────────────┘ ``` - 左に「原因起点」の問題点、右に「症状起点」の解を対比。 - 下部に進化の流れ（4 Golden Signals → SLO burn-rate）をタイムライン矢印で。 **脚注引用**: Ewaschuk, "Monitoring Distributed Systems," *SRE Book*, 2016 / Thurgood+, "Alerting on SLOs," *SRE Workbook*, 2018 --- ## Slide 8: 鳴るべきアラートが本当に鳴るか（§3 Phase A 理論、〜1分） **レイアウト**: 中央に「壊れ方の分類」図、下にデータ ``` ┌──────────────────────────────────────────┐ │ Phase A: 鳴るべきアラートが本当に鳴るか │ │ │ │ アラートの故障モード: │ │ │ │ 鳴りすぎ ◄──────────────► 静かに壊れる │ │ (false alarm) (silent failure) │ │ │ │ ┌──────────────────────────────────┐ │ │ │ 検知失敗の最大要因: │ │ │ │ 「そもそもアラートが無い」= 40.41% │ │ │ │ Ganatra+ FSE 2023 │ │ │ └──────────────────────────────────┘ │ │ │ │ 対策: pint CI + daemon の二重保証 │ │ 挿入の防止（CI）× 漸進劣化の検出（常駐） │ │ Cloudflare SRE 2022 │ └──────────────────────────────────────────┘ ``` - 上部に双方向の矢印スペクトラム。右端「静かに壊れる」を赤で強調。 - 中央にコールアウトボックスで「40.41%」を大きく表示。最も印象に残るべき数字。 - 下部にpintの二重保証を2つのアイコン（CI = ゲート、daemon = 常駐監視）で表現。 **脚注引用**: Ganatra+, "Detection Is Better Than Cure," *ESEC/FSE*, 2023 / Cloudflare SRE, "Monitoring our Monitoring," *Blog*, 2022 --- ## Slide 9: Phase A 到達点（§3 Phase A 実践、〜1分） **レイアウト**: 左右2段で2つの到達点 ``` ┌──────────────────────────────────────────┐ │ Phase A: 到達点 │ │ │ │ ┌─────────────────┐ ┌─────────────────┐│ │ │ severity×urgency │ │ Meta Monitoring ││ │ │ (重大度×緊急度) │ │ (監視系の監視) ││ │ │ の直交分離 │ │ の完全分離 ││ │ │ │ │ ││ │ │ ┌───┬────────┐ │ │ notification ││ │ │ │ │imm│norm│ │ │ policy tree で ││ │ │ │cri│ 🔴│ 🟡 │ │ │ 構造的に強制 ││ │ │ │wrn│ 🟡│ 🟢 │ │ │ ││ │ │ └───┴────────┘ │ │ [本体障害] ││ │ │ │ │ ↕ 分離 ││ │ │ 「criticalだが │ │ [監視系障害] ││ │ │ 静かな対応でよい」│ │ ││ │ │ を表現できる │ │ → 第零の介入点 ││ │ └─────────────────┘ └─────────────────┘│ └──────────────────────────────────────────┘ ``` - 左: severity×urgencyの2×2マトリクス。多くの設計がseverity 1軸しかないこととの対比。 - 右: notification policy treeの分岐簡略図。「本体障害」と「監視系障害」の経路が分離。 - ポジティブなトーン。「ここは最先端に近い」。 **脚注引用**: Zeng+, "TraceArk," *ICSE-SEIP*, 2023 / Cloudflare SRE, "Monitoring our Monitoring," *Blog*, 2022 --- ## Slide 10: ギャップ1 — SLOと二層構成（§3 Phase A、〜1.5分） **レイアウト**: 上に現状→理想の遷移、下にHPC/AI固有の二層図 ``` ┌──────────────────────────────────────────┐ │ ギャップ1: SLO/バーンレートの不在 │ │ │ │ 現状どう進歩させるか │ │ ┌──────────┐ ┌──────────────┐ │ │ │閾値ベース │ ──→ │SLO + 原因の │ │ │ │手動チューニ│ │二層構成 │ │ │ │ング │ │ │ │ │ └──────────┘ └──────────────┘ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ 上層 (SLO) │ │ │ │ ジョブ投入可用性 / GPU計算容量 │ │ │ │ / ストレージ可用性 │ │ │ ├──────────────────────────────────┤ │ │ │ 下層 (原因) │ │ │ │ GPU Xid / NVLink degraded │ │ │ │ / NIC link down │ │ │ │ → 放電再起動 / ベンダー修理 │ │ │ └──────────────────────────────────┘ │ │ │ │ HPC/AIでは原因ベースも不可欠 │ └──────────────────────────────────────────┘ ``` - 上段: before/after 形式。下段: 二層構成を2段の積み重ねボックスで（上層=青、下層=オレンジ）。 - 「放電再起動」「ベンダー修理」がSLOでは拾えないことを強調。 **脚注引用**: Thurgood+, "Alerting on SLOs," *SRE Workbook*, 2018 --- ## Slide 11: ギャップ2 — ルール健全性CI（§3 Phase A、〜1.5分） **レイアウト**: 上にリスクの図解、下に対策のパイプライン ``` ┌──────────────────────────────────────────┐ │ ギャップ2: ルール健全性のCI検証がない │ │ │ │ リスク: アラートの静かな死 │ │ ┌──────┐ label変更 ┌──────┐ │ │ │rule A │───×───→ │ 空結果 │→ 発火せず │ │ └──────┘ └──────┘ │ │ ┌──────┐ chain切断 ┌──────┐ │ │ │rec. │───×───→ │ rule │→ 発火せず │ │ │rule │ │ 参照先│ │ │ └──────┘ │ 消失 │ │ │ └──────┘ │ │ │ │ どう進歩させるか: │ │ ┌────────────────────────────────────┐ │ │ │ Preview → [+pint CI] → Approve │ │ │ │ → Apply │ │ │ └────────────────────────────────────┘ │ │ + 常設カナリア: vector(1) alert を各route│ │ に配置し通知経路の死活を常時検証 │ └──────────────────────────────────────────┘ ``` - 上部: アラートが「静かに死ぬ」2パターンを図示。×マークで断絶を示す。 - 下部: 既存フローにpint CIステップを挿入する図。挿入箇所を赤枠で強調。 **脚注引用**: Ganatra+, "Detection Is Better Than Cure," *ESEC/FSE*, 2023 / Cloudflare SRE, "Monitoring our Monitoring," *Blog*, 2022 --- ## Slide 12: Phase B〜D: 到達点と将来（§4、〜1分） **レイアウト**: 3フェーズを横並びで到達点表示 + 将来余地 ``` ┌──────────────────────────────────────────┐ │ Phase B〜D: 到達点と将来 │ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │B.抑制 │ ──→ │C.配信 │ ──→ │D.解決 │ │ │ │ ✅ │ │ ✅ │ │ △ │ │ │ └──────┘ └──────┘ └──────┘ │ │ │ │ B 抑制 pending / silence / mute timing │ │ C 配信 quarantine route / 隔離 / │ │ grouping + 重大度×緊急度 │ │ D 解決必須annotation 5項目: │ │ summary / impact / first_action │ │ / dashboard_url / runbook_url │ │ │ │ ┈┈┈ 将来の拡張余地 ┈┈┈ │ │ 自動証拠収集 / RCA / エージェント処理 │ │ │ │ ░░ 意図的な対象外: ML集約・ランキング ░░ │ └──────────────────────────────────────────┘ ``` - B, Cにチェックマーク、Dに△。「B・Cはできている、Dは部分」のトーン。 - 将来の拡張は点線で区切り薄いフォントで。「意図的な対象外」もグレーの帯で。 **脚注引用**: Yang+, "Characterizing and Mitigating Anti-patterns of Alerts," *DSN*, 2022 / Treat, "Less Alarming Alerts!," *SREcon16*, 2016 / 岩堀, "Runbookに何を書き、どのようにアラートを振り分けるか？," *SRE NEXT*, 2023 --- ## Slide 13: 横断 — アラートの品質をどう測るか（§4 横断理論、〜40秒） **レイアウト**: 上にQoA 3軸、下にコストモデル ``` ┌──────────────────────────────────────────┐ │ 横断: アラートの品質をどう測るか │ │ │ │ ┌──── QoA 3軸 (Yang+ DSN 2022) ────┐ │ │ │ Indicativeness Precision │ │ │ │ ╲ ╱ │ │ │ │ ╲ ╱ │ │ │ │ Handleability │ │ │ └───────────────────────────────────┘ │ │ │ │ コストモデル (Zadka SREcon 2022): │ │ ┌────────┐ ┌────────┐ ┌────────────┐ │ │ │偽アラーム│+│真アラーム│+│★欠落アラーム│ │ │ │対応コスト│ │処理コスト│ │ による損害 │ │ │ └────────┘ └────────┘ └────────────┘ │ │ │ │ 欠落のコストを明示的に品質モデルに含める │ └──────────────────────────────────────────┘ ``` - 上部にQoA 3軸を三角形で表示。下部にコストモデル3ボックス。 - 「欠落アラームによる損害」を赤枠で強調。 **脚注引用**: Yang+, "Characterizing and Mitigating Anti-patterns of Alerts," *DSN*, 2022 / Zadka, "Modeling Alert Quality," *SREcon22*, 2022 --- ## Slide 14: ギャップ3 — 品質の定量管理（§4 横断実践、〜50秒） **レイアウト**: 現状 + 3ステップの改善策 ``` ┌──────────────────────────────────────────┐ │ ギャップ3: アラート品質の定量管理 │ │ │ │ 現状: │ │ アラートの「良い/悪い」を体系的に │ │ 判定する枠組みがない │ │ │ │ どう進歩させるか: │ │ │ │ ① QoA 3軸で個々のアラートを評価 │ │ ┌──────────────────────────────────┐ │ │ │ 指示性精度 │ │ │ │ ╲ ╱ │ │ │ │ 処理容易性 │ │ │ └──────────────────────────────────┘ │ │ │ │ ② Zadka式の4区間分解でコストを可視化 │ │ ┌──────────────────────────────────┐ │ │ │ 発生 → 検知 → 確認 → 診断 → 復旧 │ │ │ │ ├ t1 ─┤├ t2 ─┤├ t3 ─┤├ t4 ─┤ │ │ │ └──────────────────────────────────┘ │ │ │ │ ③ 振り返りで「検知すべきアラートは │ │ 存在していたか」を問う → 欠落コスト計測 │ └──────────────────────────────────────────┘ ``` - 上段: 「枠組みがない」で問題を明確に。Slide 13 の理論と直結。 - 中段: QoA 3軸の三角形（Slide 13 の再掲を小さく）。 - 下段: 4区間分解タイムライン。Slide 8 の「40.41%」と呼応。 **脚注引用**: Zadka, "Modeling Alert Quality," *SREcon22*, 2022 / Yang+, "Characterizing and Mitigating Anti-patterns of Alerts," *DSN*, 2022 --- ## Slide 15: まとめ（§5、〜2.5分） **レイアウト**: 上にパイプライン図、中にテイクアウェイ、下にキーメッセージ ``` ┌──────────────────────────────────────────┐ │ まとめ │ │ │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐│ │ │A ⚠ │→│B ✅ │→│C ✅ │→│D △ ││ │ └──────┘ └──────┘ └──────┘ └──────┘│ │ ───── 横断: 品質 ⚠ ───── │ │ │ │ 1. 4フェーズモデルで │ │ アラーティングの最先端を整理した │ │ │ │ 2. Phase A（保証）に │ │ ROI最大のギャップが集中 │ │ SLO + ルール健全性CI │ │ │ │ ─────────────────────────────────────── │ │ 最先端の議論を体系的に整理すると、 │ │ 場当たり的な改善から、 │ │ 体系的にギャップを埋められる │ │ │ │ 坪内佑樹 @yuaboron │ │ さくらインターネット研究所 │ └──────────────────────────────────────────┘ ``` - パイプライン図を小さく上部に再掲。各フェーズに⚠/✅/△のアイコンで到達度を示す。 - テイクアウェイ2項を簡潔に。 - 区切り線の下にキーメッセージを大きなフォントで。Slide 3 の3つの問いの回収。 - 下部に名前と所属。最終スライドとしてQ&A中も表示。 --- ## スライド構成のサマリー | # | スライド | 時間 | ブロック | | --- | ------------------------ | ----- | ----------- | | 1 | タイトル | 10秒 | 導入 | | 2 | アラーティングの重要性 | 50秒 | 導入 | | 3 | 発表概要 | 30秒 | 導入 | | 4 | 4フェーズモデル | 40秒 | 全体像 | | 5 | 照合対象のサービス | 30秒 | 全体像 | | 6 | ギャップ全体像 | 30秒 | 全体像 | | 7 | 症状で鳴らす、原因では鳴らさない | 1分 | Phase A 理論 | | 8 | 鳴るべきアラートが本当に鳴るか | 1分 | Phase A 理論 | | 9 | Phase A 到達点 | 1分 | Phase A 実践 | | 10 | ギャップ1: SLO + 二層構成 | 1.5分 | Phase A 実践 | | 11 | ギャップ2: ルール健全性CI | 1.5分 | Phase A 実践 | | 12 | Phase B〜D 到達点と将来 | 1分 | B〜D | | 13 | 横断: 品質をどう測るか | 40秒 | 横断理論 | | 14 | ギャップ3: 品質の定量管理 | 50秒 | 横断実践 | | 15 | まとめ | 2.5分 | まとめ | | | **合計** | **15分** | | ## デザイン方針メモ - **配色**: Phase A = 赤/オレンジ系（ギャップ・注目）、B/C = 緑系（到達）、D = 黄系（部分）、横断 = 青系 - **フォント**: 日本語ゴシック体。引用識別子は脚注として小さく右下に配置（本文に混ぜない） - **アニメーション**: 最小限。テーブルの行ハイライトと、パイプライン図のフェーズ順送りのみ - **引用の扱い**: 各スライド下部に小フォント（8–9pt）で参考文献を記載。著者名, 短縮タイトル, 会議/誌名, 年の形式。フル引用は配布資料（アウトライン）に集約 - **繰り返し要素**: Slide 4 のパイプライン図を Slide 15 で再利用し、到達度の色が変わる演出 - **構成の特徴**: 理論→実践をフェーズごとに束ねる。Phase A は理論2枚→実践3枚の5枚ブロック。B〜D・横断は各1枚ずつの3枚で手短に。全体像ブロックを3枚（モデル→サービス→ギャップ）に展開し、ギャップテーブルを1枚全面で見せる。