# Runbookに何を書き、どのようにアラートを振り分けるか？ ## 概要 Sohei Iwahori が SRE NEXT 2023 で発表した、[[GREE, Inc]] における Runbook 整備とアラート追加ガイドラインの事例である。既存の障害対応手順書が一次対応の How に寄り、エスカレーション先が参照する背景情報やアラートの Why を残せていなかった課題に対し、アラート通知へ Runbook を組み込み、追加フローで通知チャンネル・対応アクション・適用スコープを明示させる運用を提示する。 ## 主要メッセージ - グリーの環境は、オンプレ、EC2 on AWS、EKS/GKE が併存し、タイトルごとに似たワークロードが数十存在するため、アラートルールを横断共通化しつつ個別設定する必要がある。これは Runbook による知見蓄積が効きやすい前提である。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.4-5) - 従来の障害対応手順書は、エスカレーション先が参照できる情報、検索性、アラート自体を見直すための背景説明が不足していた。特に How だけでは、なぜそのアラートがあるのかが失われる。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.10) - Runbook は「短期的な定型解決策」よりも、背景、判断材料、解決につながる文脈やヒントを残すものとして設計されている。定型コマンドで解決できるなら自動化対象であり、人間を起こす以上は判断の材料が必要になる。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.21; [[.raw/slides/runbook-alert-triage/transcript.md]]) - 実装は Git リポジトリ運用、アラート通知システムへの組み込み、簡易テンプレートからの作成で構成される。アラート処理時に Runbook 情報を付加し、存在しない場合は作成を促す。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.26-29) - アラート追加ガイドラインは、検知目的か、サービス影響があるか、具体的対応アクションがあるか、今すぐ対応が必要か、機械的対応が可能かを分岐させ、チャット通知・チケット・オンコール通知を選ばせる。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.33) - 横断オンコールアラートでは、偽陽性検証、対応 Runbook の記載、背景を含めた全体周知を追加条件とする。これにより追加時点でアクションを固め、アラート疲れを軽減する。(Source: [[.raw/slides/runbook-alert-triage/pages]], p.34-36) ## 視覚的に重要な図表 **p.7 Dev と Ops の組織構造** ![[_attachments/runbook-alert-triage/page-007.png]] プロダクトごとの開発チーム、担当インフラメンバー、共通基盤・専門 unit・運用チームの関係を示し、エスカレーション先向け Runbook が必要になる組織的背景を与える。 **p.23 Runbook テンプレート** ![[_attachments/runbook-alert-triage/page-023.png]] 症状、背景、確認項目、解決、事後確認、関連情報という構成で、しきい値詳細ではなく背景と判断材料を残す方針を具体化している。 **p.27 Runbook の反映フロー** ![[_attachments/runbook-alert-triage/page-027.png]] Runbook リポジトリからインデックスを生成し、アラート処理ワーカーがアラートメッセージへ Runbook 情報を付加する流れを示す。 **p.33 チャンネル選択ガイドライン** ![[_attachments/runbook-alert-triage/page-033.png]] 調査目的、サービス影響、具体的アクション、即時性、機械的対応可否を使って通知チャンネルを選ぶ分岐を示す。 **p.34 横断アラート追加のガイドライン** ![[_attachments/runbook-alert-triage/page-034.png]] 横断オンコールアラートの追加条件として、偽陽性検証、対応 Runbook、背景つき周知を求める。 **p.36 ガイドライン策定による効果** ![[_attachments/runbook-alert-triage/page-036.png]] 追加時点で「いつ、どの通知チャンネルで、どう行うか」を考えさせ、アラート自体の必要性を再検討させる効果をまとめる。 ## 口頭説明・補足 YouTube 自動字幕では、グリーの運用規模として、オンプレは大きく減ったものの残存し、EC2 が約 2000 台強、GKE/GCP 側のノードが数百程度あると説明されている。スライド本文は「オンプレ / VM ベース / コンテナベースがすべて存在」とだけ述べるため、台数は口頭説明由来として扱う。(Source: [[.raw/slides/runbook-alert-triage/transcript.md]]) 口頭説明では、Runbook が有効な環境として「似たワークロードが複数ある」「ベース技術の変化が比較的緩やか」「原因ベースのアラートを利用している」ことが強調される。ブラックボックスベースの症状アラートは原因が無数にあり、固定 Runbook で対応することが難しいという補足もある。(Source: [[.raw/slides/runbook-alert-triage/transcript.md]]) 実装面では、GitLab のテンプレートを参考にしつつ背景情報を追加し、必須項目を減らして作成のハードルを下げたと説明される。通知 UI では Runbook がある場合はリンクを出し、ない場合はリポジトリをクローンして生成コマンドを実行する導線を出す。(Source: [[.raw/slides/runbook-alert-triage/transcript.md]]) ## 概念・実体への接続 - [[アクショナブルアラート]]: この資料は、アラートが「人を起こすだけ」で終わらず、期待するアクション・タイミング・背景・Runbook と結びつく必要があることを実務側から示す。 - [[アラート管理]]: 既存研究が発火後の集約・ランキング・抑制を扱うのに対し、この資料は「アラートを追加する前」に通知チャンネルとアクションを設計する上流統制を示す。 - [[SRE]]: Runbook をプレイブックとして推奨する SRE Book / SRE Workbook と、Runbook 維持コストへの懐疑を、組織条件に応じて調停する事例である。 - [[Sohei Iwahori]] / [[GREE, Inc]] / [[SRE NEXT]]: 登壇者、所属、発表イベント。 ## 限界・不確実点 - p.24-25 の Runbook サンプル、p.28-29 の通知画面、p.34-35 の社内リンクや一部テキストにはマスクまたは小さい文字があり、詳細値や URL は読めない。 - YouTube transcript は自動字幕から整形したため、「Runbook」が「ラブック」「LAN ブック」と誤転写される箇所がある。本文ではスライド画像と PDF 抽出テキストを優先した。 - 動画の英語字幕取得は HTTP 429 で失敗した。日本語自動字幕と抽出済み音声 `audio.m4a` は保存済みである。