K8s障害対応設計｜Severityとオンコール

第15回で決めたのは、何が鳴るかまでです。エラーバジェットの消費速度が14.4倍を超えたら人を呼ぶ、CPUの飽和はチケットに回す、という振り分けまでは確定しました。

しかし、鳴った後に何が起きるかは、まだ何も決まっていません。空欄は4つあります。誰が最初に受けるのか。何分以内に応答するのか。どの時点で人を増やすのか。終わった後に何を残すのか。

目次

1. 鳴らす設計の次に来るのは、鳴った後の設計
   1. この記事で作る成果物
2. 深刻度は「影響の大きさ」ではなく「呼び出しの強さ」で分ける
   1. 形容詞の階段では、深夜に判定できない
   2. Sev1からSev3の定義（そのまま転記して使う）
   3. 検知の遅延を、一次応答の時計に含めるか
   4. 自組織のSeverityと、クラウドのケース優先度を対応づける
3. オンコールは人数から決めない。1シフト2件という上限から決める
   1. 上限は2件、平均は0件
   2. 25パーセントの上限から、必要な人数が出る
   3. 8名を確保できないとき、削るのは人数ではなくカバー範囲
   4. 負荷は感想ではなく、4つの数値で測る
   5. 通知が届かない経路を1つ潰しておく
4. エスカレーションは人を増やすことではなく、役割を分けること
   1. 宣言する条件を3つに固定する
   2. 3つの役割と、兼任してよい範囲
   3. 引き継ぎは、明示的な言葉で行う
5. ランブックに残してよいのは、分岐と判断だけ
   1. 手順が決定的になったら、それは自動化の設計書
   2. 最初の3分でやることは、原因の調査ではない
   3. 原因が分からなくても打てる手を、先に4つ用意する
   4. 対応の基盤そのものが落ちる前提で書く
   5. ランブック1本と、アラート台帳1行の紐づけ方
6. ポストモーテムは「書く条件」を先に決めないと書かれない
   1. 実施の条件を5つに固定する
   2. 非難しないことを、文書の規則に落とす
   3. アクションアイテムの4要件と、必ず入れる2件
   4. 遅いポストモーテムは、書かなかったのと同じになる
   5. 再発したときに疑うのは、対策ではなく対策の選び方
7. シークレットローテーションは、戻せなくなる時点から書く
   1. 戻せなくなる時点は「破棄」
   2. スケジュールしただけでは、回っていない
   3. 漏洩時の手順は、定期ローテーションと順序が逆
8. 【実務テンプレート】Severity定義表・ランブック・ポストモーテム
   1. Severity定義とエスカレーション表
   2. ランブック（必ず持たせる5項目）
   3. ポストモーテムのテンプレート
9. 次回予告

鳴らす設計の次に来るのは、鳴った後の設計#

この4つを埋めるのが本記事です。そして本記事は、次の3つの立場を採ります。

1. 深刻度は「障害の大きさ」ではなく「呼び出しの強さ」で分ける。Sev1からSev3は影響度のラベルではなく、誰を・何分以内に・どの経路で起こすかという拘束の強さの区分です
2. 体制は人数ではなく、負荷の上限から決める。1シフトあたり2件という上限から、必要な人数もカバーできる時間帯も逆算できます
3. ランブックは手順書ではなく、判断の並び順にする。手順が完全に決まっているなら、それは自動化の対象であって人を起こす対象ではありません

先に、混ざりやすい2つの線引きを引いておきます。

1つ目は、平時と有事の分離です。第2回で決めた「一次応答4時間」は、平時の問い合わせ窓口のSLAでした。有事の一次応答は別の時計で測ります。この2つを同じ表に並べると、どちらも守られなくなります。

2つ目は、計画作業との分離です。移行の切り戻し判断は第13回、更新の中止判断は第14回で扱いました。あれは日程が決まっている作業を止める判断です。本記事が設計するのは、いつ起きるか分からない事象に対する恒常的な体制です。

この記事で作る成果物#

1. Severity定義とエスカレーション表。深夜に一人で判定できる形にした1枚
2. ランブック。第15回のアラート台帳の1行に対して1本
3. ポストモーテムの実施基準とテンプレート。書く条件を先に決めたもの

加えて、2番目の具体例としてシークレットローテーションの手順を1本書き切ります。第5回で「何を・どの頻度で更新するか」というポリシーは決めましたが、実行手順は空欄のままでした。

深刻度は「影響の大きさ」ではなく「呼び出しの強さ」で分ける#

形容詞の階段では、深夜に判定できない#

多くの組織のSeverity定義は、次のような形をしています。

• Sev1: 重大な影響がある障害
• Sev2: 大きな影響がある障害
• Sev3: 中程度の影響がある障害

これは定義ではなく、形容詞の階段です。深夜2時に一人で判定できない定義は、定義として機能しません。判定に迷った担当者は、まず上長に電話して「これはSev1ですか」と聞くことになり、その時点で判定の時間が対応の時間を食い始めます。

判定できる定義にするには、2つの条件が必要です。

1. 判定に使う入力が、その場で観測できるものだけで構成されている
2. 判定した結果として何が起きるか（誰が起きるか）が、定義そのものに書いてある

1つ目の実例は、意外なところにあります。Google Cloud のサポートケースの優先度の定義です。P1（重大な影響。本番環境でサービスを使用できない）の判定条件には、次の項目が含まれています。

• 本番環境でアプリケーションまたはインフラストラクチャが使用できず、ユーザー側でエラーが大量に発生している
• 簡単（30分以内）に実装できる回避策がない
• 影響を受けるコンポーネントまたは機能の分類が一般提供である

2番目が形容詞ではありません。「回避策があるか」「その実装に何分かかるか」という観測できる条件です。P2（影響が大きい）の定義にも「重大な影響を軽減できる回避策があり、簡単に実装できる」が入っています。つまりP1とP2の境界は、影響の大きさではなく回避策の有無で引かれています。

この軸を自組織のSeverity定義に持ち込みます。影響の大きさを主観で測るのをやめると、判定が会議ではなく計算になります。

Sev1からSev3の定義（そのまま転記して使う）#

2つ目の条件、つまり「誰が起きるか」を定義に埋め込むと、次の形になります。

応答時間の3段には根拠があります。Google SRE は現実的な応答時間の例として、収益に影響するネットワーク障害に5分、顧客の注文バッチ処理の停止に30分、本番前サービスのバックアップ失敗にはチケット（業務時間内の対応）という3段を挙げています。

5分と30分の違いは、担当者の生活の拘束度の違いです。5分は「充電済みで認証済みのノートPCとネットワークが常に手の届く範囲にあり、移動できない」状態を意味します。30分なら「短時間の外出や通勤ができる」。この差を定義に併記しないと、Sev1の応答時間を軽く設定してしまいます。

Sev3の4時間は、新しく作った数値ではありません。第2回で決めた平時の一次応答4時間に揃えたものです。ここを揃えておくと、平時の問い合わせ窓口とSev3の窓口を同じ運用で回せます。

Sev1の欄に「3名が起きる」と書いてある効果は大きいものです。Sev1の乱発が自動的に抑制され、逆に「Sev1にしなかったせいで一人で抱え込む」事故も、セカンダリを呼ぶのはSev1だと定義に書いてあれば減ります。

Sev2の判定条件にある「エラーバジェットの消費が止まっている」を入れた理由は、後の章の縮退設計で説明します。

この表には、注記を3つ添えてください。

1. 設計上想定されている事象は、それ単体ではSeverityの対象にしません。第4回で扱ったSpot VMのプリエンプションによるPodの再起動がこれにあたります。判定はあくまでユーザーへの影響で行います。想定内の事象をSev1にすると、Sev1が毎日発生します
2. リージョン全体の障害はSev1に該当しますが、ディザスタリカバリの発動判断は本記事のプロセスではありません。第17回で扱います。Sev1の宣言とDRの発動は別の判断であり、判断者も、判断に使う数値も違います
3. 一次応答は「通知を受け取った時刻」から測ります。理由は次のとおりです

Severityの段数は3で固定してください。段を増やしたくなったときに増やすのは、段ではなく判定条件の列です。「深夜帯か」「複数のサービスにまたがるか」といった列を足せば、段を増やさずに解像度を上げられます。4段以上に増やすと、増えた段の判定条件が形容詞に戻ります。

検知の遅延を、一次応答の時計に含めるか#

第15回で確認したとおり、Cloud Monitoring のアラートは即座には鳴りません。多くの指標は収集後60秒は参照できず、アラートポリシーの計算にさらに最大5分30秒かかります。合計すると最短でも約6分30秒で、再テスト期間を設定していればそれが加算されます。

この6分30秒を、一次応答の時計に含めるかどうかを本記事で決めます。結論は、含めません。時計の起点は「通知を受け取った時刻」です。

障害の発生時刻から測ると、Sev1の一次応答5分は検知だけで6分30秒かかるため、定義上達成できません。達成できない定義を置くと、誰も守らなくなります。

ただし、発生から通知までの時間は別に記録します。ポストモーテムの「検知までの時間」がこれにあたります。この数値が縮まらない限り、一次応答をいくら速くしても総復旧時間は縮まりません。検知を速くする作業は第15回の管轄ですが、その必要性を数値で示すのは本記事の記録です。

経営層への説明では、この足し算を先に共有してください。「一次応答5分」は「障害発生から5分で人が動く」ではなく「検知から5分」であり、検知に最短6分30秒かかるため、総計では11分30秒が下限です。これを共有していないと、障害の後に「なぜ5分で止まらなかったのか」という議論になります。

自組織のSeverityと、クラウドのケース優先度を対応づける#

Sev1を宣言しても、Google Cloud 側のサポートケースが自動でP1になるわけではありません。優先度は起票時に自分で指定します。そして目標初回応答時間は、契約している支援の等級によって大きく違います。

※印は営業時間内であることを示します。ここでいう営業時間は日曜17時から金曜17時（太平洋時間）で、地域の祝日を除きます。

この表で最も重要なのは1行目です。Standard サポートには、P1の目標初回応答時間が設定されていません。「本番環境でサービスを使用できない」というケースに対して、目標がありません。

Sev1の一次応答を5分と定義しておきながら、エスカレーション先の目標応答時間が未設定という状態は、設計として成立していません。サポート契約の等級は、体制設計の入力値として先に確認してください。第1回で計算したK8s税の項目に、これが含まれていたかどうかを見直す場面です。

営業時間の定義にも罠があります。P3とP4は営業時間内のみです。金曜17時（太平洋時間）以降に起票したP3は、次の営業日まで処理されません。これは日本時間では土曜の午前9時に相当します。土日に持ち越したくないものをP3で起票しないでください。

もう1つ、P1には自組織側の義務が付きます。Google はP1のケースについて、解決まで顧客側が継続的に連絡可能な状態を維持することを求めています。P1を上げるということは、自組織側も24時間張り付くということです。セカンダリの体制がないと、この義務を果たせません。

対応づけの既定案は、Sev1をP1、Sev2をP2、Sev3をP3とします。ただし、クラウド側に原因がある可能性を排除できないときだけ起票してください。自組織の設定ミスをP1で起票しても、目標応答時間は消費されますが解決には近づきません。

起票のタイミングも決めておきます。「自分たちで直せないと分かってから」では遅すぎます。Sev1を宣言した時点で、クラウド側に原因がある可能性を排除できていないなら起票してください。目標初回応答時間は、ケースの作成時刻から進みます。

なお、優先度の変更とエスカレーションは別の操作です。サポートポータルではケース作成の30分後にエスカレーションのボタンが表示され、エスカレーション後は1時間以内に連絡があります。ただしGoogle自身が注意を明記しています。エスカレーションはプロセスの中断を知らせるための仕組みであり、影響の大きい問題を速く解決する手段ではありません。影響が大きいなら、まず優先度を正しく設定してください。

オンコールは人数から決めない。1シフト2件という上限から決める#

上限は2件、平均は0件#

Google SRE は、オンコール設計の基礎として2つの数値を公開しています。

• 1件のインシデント対応に平均6時間かかる。原因分析、修復、ポストモーテムの執筆、バグ修正までを含めた時間です
• したがって、12時間シフトあたりの上限は2件。これを超えると、対応の後片付けが終わらないまま次の障害が来ます

さらに重要な条件が付きます。ページの発生は時間軸上で平らであるべきで、中央値は0が望ましいという条件です。「毎日1件は鳴る要素がある」という状態は、いずれ別のものが同時に壊れて上限を超えます。

ここでいう「インシデント1件」の数え方を先に決めておきます。同じ根本原因に関連し、同じポストモーテムで議論される一連の事象とアラートを1件と数えます。通知の本数ではありません。1つの障害で12通のアラートが飛んでも1件です。

ただし、通知の本数も別に測ります。Google SRE はアラートとインシデントの比を1対1に近づけることを推奨しています。1つの障害で複数のアラートが飛ぶ状態は、対応者が重複の仕分けに時間を使うことになります。これは第15回のアラート設計へのフィードバック項目です。

25パーセントの上限から、必要な人数が出る#

人数側の制約も公開されています。エンジニアの時間の50パーセント以上を開発に充て、オンコールは25パーセントを超えない。残る25パーセントがその他の運用作業です。

ここから最小人数が導かれます。

• 常時2名（プライマリとセカンダリで役割が異なる）で24時間365日を回す場合、単一拠点なら最低8名。週次シフトで、各自が月に1週プライマリまたはセカンダリに入る計算です
• 2拠点体制なら各拠点6名が妥当な下限とされています

逆方向の下限もあります。四半期に1回か2回はオンコールに入る規模にしてください。入らなさすぎると本番環境の勘が鈍り、知識の欠落は障害のときに初めて発覚します。人数が多ければ多いほど良いという設計ではありません。

8名を確保できないとき、削るのは人数ではなくカバー範囲#

ここからが本章の中心です。日本の多くのチームは4名から6名です。8名を確保できないチームが24時間365日・常時2名を宣言するのは、設計ではありません。

削れるものは3つあります。

1. カバーする時間帯。夜間はSev1のみ呼び出す
2. カバーするSeverityの範囲。Sev2以下は翌営業日から対応する
3. セカンダリの常設。常時2名をやめ、Sev1のときだけ2人目を呼ぶ運用に切り替える

削れないものが1つあります。削った結果として何が起きるかを、数値で明示することです。

「夜間のSev2は翌営業日の始業時刻から対応する」と決めたなら、夜間にSev2が発生したときの想定ダウンタイムを計算します。22時に発生して始業が9時なら、最大11時間です。

これを第3回で決めた可用性目標と突き合わせます。

桁が2つ違います。どの目標値でも、夜間に11時間放置すれば1回で予算を使い切ります。

したがって結論はこうなります。夜間の縮退が成り立つのは、その事象がエラーバジェットを消費していない場合だけです。これがSev2の定義に「エラーバジェットの消費が止まっている」を入れた理由です。消費が続いているならそれはSev1であり、縮退の対象にできません。

この計算を先に会議に出してください。「夜間はSev2まで見ません」という提案が通るかどうかは、この1行で決まります。通らないなら、人数を増やすか目標値を下げるかの二択になります。

ここで注意点が1つあります。この議論を金額で行わないでください。「夜間対応を諦めることで年間いくら削減できる」という書き方をすると、金額の比較だけで「障害を受け入れる」が合理的な結論になります。第1回の条件4（専任2名未満）で同じ誤りを避けたのと同じ理由です。提示するのは条件です。「この体制で受けられるのはここまで」と言い切り、それ以上を求めるなら人数かカバー時間のどちらかを変える必要がある、という形にします。

人数を足さずに拘束を分散する手段が1つだけあります。開発チームと運用チームで、役割の異なる2つのローテーションを組むことです。運用チームが一次対応を持ち、アプリケーション起因と判断されたら開発チームの当番へエスカレーションします。第2回のRACIで所有権を分けてあるなら、呼び出しも同じ線で分けられます。

そして、呼び出しの総量そのものを下げる経路は3つあります。バグを減らす（第9回のCIとテスト）。アラートを減らす（第15回）。開発チームが自力で解決できる範囲を広げる（第18回のセルフサービス型トラブルシューティング）。3つとも運用チームの外に手がかかります。第15回で「ログ規約は運用チームだけでは実装できない」と書いたのと同じ構造です。

最後に1点、技術部門だけでは決められない項目があります。待機時間をどう扱うかは、拘束の強さによって変わりうる労務上の論点です。「電話が鳴ったら5分以内に応答する」というSev1の設計は、担当者の生活を実際に拘束しています。シフト表を作ってから人事に相談するのではなく、人事・労務と合意してからシフト表を作ってください。順序を逆にすると、作った表が使えなくなります。

負荷は感想ではなく、4つの数値で測る#

「最近オンコールがきつい」という感想では、経営層との交渉になりません。測る対象は4つです。

1. 1シフトあたりのページ件数（上限2件）
2. 1日あたりのチケット件数（目安として5件未満）
3. シフト中に対応した時間の割合
4. 原因不明のまま閉じたページの件数

4番目を入れる理由を説明します。Google SRE は、ページの原因を「不明」で片付けることをほとんど無くすべきだとしています。「一時的な事象だった」「勝手に直った」で閉じたページは、次の当番に同じページを送るからです。

原因が特定できないなら、その場での正解は「次に同じことが起きたときに特定できるよう、ログか監視を1つ足す」ことです。何もせずに閉じるという選択肢は用意しません。4番目が減らない限り、1番目は減りません。

推移の見方も決めておきます。21日の移動平均を定例で確認します。単発のスパイクではなく、傾向が上を向いているかどうかを見ます。

上限を超えたときに何をするかも、先に決めておきます。

1. 新しいアラートの追加を止める。予算を超えている状態で新規追加しない
2. 開発チームと合同で、ページ件数の多い原因の上位3件を四半期の作業として計画に載せる
3. それでも収まらないならカバー範囲を縮退させる

2番目を通すための計算式も渡します。恒久対処に3週間（約120時間）かかり、1件のページの対応に平均4時間かかるなら、30件で損益が分岐します。この計算があると、恒久対処を後回しにする議論に数値で答えられます。ただしこれは作業量の比較であって、体制そのものの必要性の議論とは別のものです。

新しいアラートを呼び出しに昇格させる前の手順も決めておきます。まずページではなくメールなどで流し、しばらく本番で動かして誤検知と予算の消費見込みを確認してから昇格させます。Google SRE は1週間程度を目安として挙げつつ、適切な期間はアラートとシステムによると留保しています。1週間という数字は、定期リリース、クラウド側のメンテナンス、週次のピークを1周させるための長さです。

通知が届かない経路を1つ潰しておく#

呼び出しの一次経路が単一だと、その経路の障害で誰も起きません。Sev1の通知は最低2経路にしてください。

設計の入力値として、Cloud Monitoring 側の上限を挙げておきます。

ここで実務上の落とし穴を1つ挙げます。インシデントを「確認済み」にしても、繰り返し通知は止まりません。Cloud Monitoring のインシデントはオープン、確認済み、終了済みの3状態を持ちますが、繰り返し通知を送る設定の場合、確認済みのマークでは停止しません。

止めるにはスヌーズかポリシーの無効化が必要です。そしてスヌーズには副作用があります。アラートポリシーをスヌーズすると、そのポリシーに関連する対応待ちのインシデントがすべてクローズされます。対応中にスヌーズすると、記録の連続性が切れます。この副作用はランブックに明記してください。

なお、呼び出しツールや当番表管理ツールの選定理由は第6回の管轄です。本記事で決めるのは要件だけです。2経路以上に送れること。当番表と連動して「今の当番」に届くこと。応答されなかったときに次の担当へ自動で回ること。第6回の選定表に、この3行を追加する形になります。

エスカレーションは人を増やすことではなく、役割を分けること#

宣言する条件を3つに固定する#

「これはインシデントとして体制を立ち上げるべきか」という判断も、形容詞で決めさせません。Google SRE が使っている目安は3つで、いずれか1つに該当したら宣言します。

1. 問題の解決に、2つ目のチームを巻き込む必要があるか
2. 障害は顧客から見えているか
3. 1時間集中して調べても、解決していないか

この判断には非対称があります。早く宣言して、簡単に直って、すぐ閉じるほうが、数時間経ってから体制を立ち上げるより安いということです。宣言のコストは低く、宣言しなかったコストは高くなります。

宣言できる人も先に決めます。宣言は一次対応者の権限にしてください。上長の承認を必要とすると、承認者が寝ている時間帯に宣言できなくなります。

承認が必要なのは宣言ではなく、影響の大きい緩和策の実行です。サービスの一時停止、リージョンの切り離し、機能の無効化がこれにあたります。第2回のRACIで、この2つを別の行に分けてください。

ここで第13回・第14回との線引きを再度確認します。更新の中止判断と移行の切り戻し判断は計画作業の中止であり、判断者は作業の前に決めてあります。本記事の宣言は、計画外の事象に対するものです。同じ人が担うことはあっても、判断の性質が違います。

3つの役割と、兼任してよい範囲#

Google のインシデント管理は、災害対応の指揮系統（Incident Command System）を元にしています。役割は3つです。

最も重要な規則は表の2行目にあります。システムに変更を加えてよいのは実作業チームだけです。Google が挙げている失敗例では、善意の第三者が調整なしに設定変更を投入した結果、サーバーが再起動して全滅しました。この規則は、その種の事故を防ぐ唯一の手段です。

兼任の判断基準を決めます。Sev2以下は1名が3役を兼ねてかまいません。Sev1では指揮と実作業を必ず分けます。技術的な問題に集中している人は、全体像を見る余裕を持てません。同じ失敗例では、対応者が技術的な作業に没頭したために、連絡も調整も止まりました。

指揮担当は実作業をしません。指揮を引き受けたら手を止める、という規則を明文化してください。

対応中に2件目が来たときの扱いも、先に決めておきます。Sev1の対応中に別のSev1が発生したら、セカンダリが2件目の指揮を引き受け、両方の優先順位は最初の指揮担当が決めます。決めていないと、2件目が「手が空いた人が見る」という扱いになり、結果として誰も見ません。1シフト2件という上限は、この同時多発を想定した数値でもあります。

連絡担当の側にも決めることがあります。更新の間隔です。決めていないと「まだですか」という問い合わせが対応者に直接届き、対応が止まります。

間隔の決め方は「次の更新まで黙っていても、関係者が不安にならない長さ」です。Sev1で30分ごと、Sev2で2時間ごとが出発点になります。自組織の関係者の数と、経営層の関与の度合いで調整してください。書くことがない回も飛ばしません。「進展なし、次の更新は何時」だけで意味があります。

そして、連絡担当が最初にやることは宛先の一覧を開くことです。宛先の一覧は障害の最中には作れません。Sev1で連絡する先（経営層、カスタマーサポート、関係する開発チーム、外部への告知の承認者）を平時に1枚にしておいてください。Google のGKEクラスタ作成障害では、事前に用意されていたメーリングリストへの一斉連絡が有効に働きました。

引き継ぎは、明示的な言葉で行う#

長期化した障害では、指揮担当が交代します。このときの作法が決まっています。引き継ぐときは「あなたが今から指揮担当です」と明示的に述べ、明確な承諾を得るまで回線を切りません。そして引き継いだことを、対応中の全員に共有します。

形式張って見えますが、理由があります。曖昧な引き継ぎの結果、指揮者が不在の時間帯が生まれるからです。誰も指揮していない状態は、全員が指揮している状態と区別がつきません。

交代の周期にも目安があります。PagerDuty が公開している10時間を超えた障害の事例では、対応者と指揮担当を4時間ごとに交代させています。理由は休息の確保と、新しい視点を入れることの2つです。

記録の引き継ぎも必要です。3名以上が関わったら、作業中の仮説、排除した原因、調査に使ったログやグラフを1つの文書に集約してください。会話の流れの中に埋もれた情報は失われます。交代した人がその文書だけを読んで状況を把握できるかどうかが、文書の品質の判定条件になります。

ランブックに残してよいのは、分岐と判断だけ#

手順が決定的になったら、それは自動化の設計書#

第15回で、決まった手順を実行するだけで済む通知は自動化の対象であって人を起こす対象ではない、と書きました。同じ線引きが、ランブックの粒度にも適用されます。毎回同じコマンドを同じ順で実行するだけなら、それはランブックではなく自動化の仕様書です。

ただし、粒度についてはGoogle SRE 内部でも意見が割れていることを伝えておきます。手順を細かく書けば対応時間のばらつきは減りますが、本番環境の変化に追随できず陳腐化します。粗く書けば陳腐化しませんが、訓練された担当者しか使えません。

公式の推奨は「最低限どの構造化された項目を必ず持たせるかをチームで決めること」です。本記事はその最低限を5項目に固定して渡します（テンプレートの章を参照してください）。「チームで決めてください」で終わらせると、結局決まりません。

陳腐化への対処は2つです。

1. ページを受けた担当者が、そのシフト中に得た新しい知見をランブックに書き戻すことを運用の義務にする
2. ランブックのレビュー時期を、第14回の年3回の更新サイクルに同期させる。更新のたびに壊れ方が変わるためです

ここで、生成AIによる調査支援の位置づけにも触れておきます。Gemini Cloud Assist の調査は、Cloud Monitoring のアラートやログエクスプローラから起動でき、サポートケースへ引き継げます。ただし本稿執筆時点でプレビュー段階であり、対象は単一のプロジェクトまたは単一のApp Hubアプリケーション内に限定され、リージョンのログバケットに保存されたデータやGoogle Cloud 外部のデータは分析されません。

そして決定的な制約があります。同じ調査を再実行すると結果が変わりうるとGoogle自身が明記しています。大規模言語モデルの出力の確率的な性質と、環境の状態が静的でないことが理由です。再現しない出力は手順にできません。調査の補助として使うのは合理的ですが、ランブックの分岐条件をこの出力に置いてはいけません。判断と説明責任は移りません。

最後に着手の順番です。アラート台帳が20行あれば、ランブックは最終的に20本になります。最初から全部書きません。ページを鳴らす行（第15回でいう症状側）から書きます。チケット側は人を起こさないため、業務時間内に調べる時間があります。症状側が5本なら、最初の四半期の作業は5本です。

最初の3分でやることは、原因の調査ではない#

進行中のインシデントに対する順序は、4段で固定されています。

1. 影響を評価する
2. 影響を緩和する
3. 原因を分析する
4. 原因を直し、ポストモーテムを書く

この順序に決定的な補足が付きます。緩和するために、原因を完全に理解する必要はありません。原因がどこにあるかが分かれば足ります。顧客が求めているのは原因の解明ではなく、エラーが返ってこなくなることです。

そのうえで、最初の3分でやることを固定します。

1. Severityの仮判定。後で上げ下げしてかまいません
2. 指揮担当の指名。一人しかいないなら「自分が指揮担当」と宣言して記録します
3. 記録の開始。開始時刻、観測した症状、見たダッシュボードを書き出します
4. 証拠の保全。

4番目には数値の裏づけがあります。Kubernetes の Event は既定で1時間で消えます。第15回で確認したとおり、OOMKilled や FailedScheduling の理由は Event にしか出ないことが多く、ログへ転送していなければ事後調査では失われます。

他の記録にも期限があります。

後から取れないものを最初に取ります。これが最初の3分に証拠の保全を入れる理由です。

順番を紙に固定するのには、もう1つ理由があります。ストレス下では熟慮より直感が優位になります。「先週も同じアラートで、そのときは外部要因だった」という推論は確証バイアスであり、深夜に一人でいるときほど強く働きます。Google SRE はこれを生理学的な現象として説明しています。設計側の対処は「よく訓練する」ではなく、判断の順番を紙に固定することです。

原因が分からなくても打てる手を、先に4つ用意する#

原因が判明する前に打てる、影響を減らす手を汎用的な緩和策と呼びます。代表的なものが4つあります。

1. 直近のリリースのロールバック
2. 影響のあるリージョンやゾーンからのトラフィックの退避
3. 機能フラグによる部分停止
4. 容量の追加

これらは鈍い道具です。精密な解決策より影響範囲が広く、別の副作用を生む可能性があります。それでも、原因の特定を待つより早く影響を止められます。

効果の大きさは、実例で示されています。Google のGKEクラスタ作成障害では、ヨーロッパでクラスタ作成が6時間40分失敗し続けました。IRCには41名が参加し、ログは26,000語に達し、ポストモーテムのアクションアイテムは28件になりました。

この振り返りの結論は、原因のおおよその所在が判明した時点でイメージを既知の正常な状態へ戻していれば、実際の終息より約2時間早く影響を止められたというものでした。加えて、最初のページから正式な指揮体制が敷かれるまでに2時間かかっています。

この4つは障害の最中には作れません。必要だったのはロールバックを短時間で実行できる道具であり、それは平時にしか作れません。

そして4つそれぞれについて、何分かかるかをランブックに数値で書いてください。実測は第12回のカオステストと第13回の移行リハーサルで行います。1番目については、第9回で設計したCDが即時ロールバックできる構成になっていることが前提になります。2番目の退避は、Podの猶予と PodDisruptionBudget の影響を受けるため、所要時間は第11回で決めた設定値で決まります。

ここで重要な例外を書いておきます。データが壊れた場合、この4つはどれも効きません。ロールバックしても、退避しても、壊れたデータは戻りません。データの復旧は第7回で決めたスナップショットの世代管理からの復元になり、所要時間の桁が違います（分ではなく時間です）。

したがってランブックには「データの整合性が疑われる場合はここで分岐する」という行を必ず入れ、復元の所要時間を第7回の設計値から転記します。この分岐を書いていないランブックは、最も影響の大きい障害で使えません。

対応の基盤そのものが落ちる前提で書く#

Personalized Service Health は、プロジェクトに関連するGoogle Cloud の障害情報を見るための主要な経路です。ただしGoogle自身が制約を明記しています。認証にIdentity and Access Management などのコアサービスを使うため、大規模な障害ではログインできない可能性があります。

そのうえで、次のフォールバックが推奨されています。

• 手動プロセス: ダッシュボードにアクセスできない場合に備え、ランブックにGoogle Cloud Service Health の公開ページ（status.cloud.google.com）を参照する指示を書いておく
• 自動システム: Service Health Status API で Personalized Service Health 自体の異常を検出し、公開のRSSフィードの取り込みにフォールバックする

同じ問題は、Google自身の障害記録にも現れています。設定変更が全社的な障害を引き起こした事例では、調査と連絡に使うソフトウェア群が障害の影響下にありました。障害がもう少し長引いていたら、デバッグ自体が困難になっていたと振り返られています。

ここから設計上の帰結が3つ出ます。

1. ランブックの保管先を、監視対象のシステムと障害を共有しない場所に置く。同じクラスタで動く社内Wikiにだけ置いてあるなら、それは設計されていません
2. 連絡経路を2系統持つ
3. 普段から代替経路を使う。使い慣れていない代替手段は、障害のときに使えません

クラウドのステータス情報の位置づけも決めておきます。GoogleはPersonalized Service Health のイベントごとにオンコールを呼び出さないことを明示的に推奨し、チームのダッシュボードに統合して「疑っている問題がGoogle Cloud の障害に関連するかを素早く判定するための裏付けシグナル」として使うことを勧めています。

加えて、開示には閾値があります。広範囲かつ重大な障害は公開ページと Personalized Service Health の両方で通知されますが、範囲が限定的なものは Personalized Service Health にのみ現れます。そして最初の通知には情報がほとんど含まれず、影響を受けたプロダクト名だけのことも多いとされています。詳細より速報性を優先しているためです。

したがって、「ステータスページに何も出ていないから自分たちの問題だ」という判定は成り立ちません。ランブックの判定ステップは、ステータスページではなく自分たちの指標で影響が確認できるかから始めてください。

ランブック1本と、アラート台帳1行の紐づけ方#

第15回で作ったアラート台帳に、「ランブックID」の列を1つ足します。紐づけの単位は、アラートポリシー1件に対してランブック1本です。

1対1にする理由は、検出できるようにするためです。台帳に載っているのに手順がない行と、手順があるのに鳴らない行を、列の空欄として機械的に見つけられます。

実装は、アラートポリシーのドキュメント欄にランブックのURLを入れる形にします。Cloud Monitoring はインシデント詳細ページの「ドキュメント」欄にこれを表示し、設定していない場合は「ドキュメントが構成されていません」と表示します。つまり未設定を画面から検出できます。

経路はもう1方向用意します。障害の起点がPodやDeploymentであることは多いためです。第10回で設計した共通Helm Chart の values.yaml に、ランブックのURLを入れる項目を1つ足し、既定値としてアノテーションに注入します。こうすると、対応者が手元のマニフェストから該当のランブックへ辿れます。台帳からの経路と、ワークロードからの経路の2方向を用意してください。

管理場所も決めます。アラートポリシーは第8回のTerraform、ランブック本体はリポジトリで管理します。手で作ると、使われていないランブックを消す判断ができません。

棚卸しの規則は、第15回の「使われていない指標を消す」と同じ形にします。四半期に一度も参照されなかったランブックは、対応するアラートポリシーごと削除の候補にします。

ポストモーテムは「書く条件」を先に決めないと書かれない#

実施の条件を5つに固定する#

障害が終わった後に「これは振り返りをやるべきか」を議論すると、忙しい時期には「今回は不要」という結論になります。条件を先に決めます。Google SRE が挙げているきっかけは5つです。

1. 一定の閾値を超えるユーザー可視のダウンタイムまたは劣化
2. あらゆる種類のデータ損失
3. オンコール担当者の介入（リリースのロールバック、トラフィックの迂回など）
4. 解決までの時間が閾値を超えたもの
5. 監視の失敗。つまり人手で障害を発見した場合

加えて、利害関係者は誰でもポストモーテムを要求できます。

5番目を強調しておきます。「ユーザーからの問い合わせで障害を知った」は、障害の大小に関わらず実施対象です。影響が小さくても、検知できなかったこと自体が設計の欠陥だからです。これは第15回の監視設計への直接のフィードバックになります。

1番目と4番目の閾値は、Google が具体的な値を示していません。値ではなく決め方を渡します。第3回で決めたSLOのエラーバジェットの消費率で置いてください。これなら判定が計算になり、会議で揉めません。第15回で確立した「目標値を件数に変換する」という手が、ここで効きます。

例示するときは、必ず換算を添えてください。「単一の事象で月間のエラーバジェットの10パーセント以上を消費したら実施する」と書くなら、「10回起きたら1か月ぶんの予算を使い切る水準」という説明を並べます。換算のない百分率だけを渡すと、読み手は根拠のない数値を転記することになります。

書かない条件も決めます。Sev3で、担当者の介入がなく、検知が自動で、バジェットの消費が閾値未満なら書きません。全部書こうとすると、書く時間が確保できず、結果として全部の質が下がります。

非難しないことを、文書の規則に落とす#

「非難しない文化を作りましょう」で終わる設計書は、翌週には忘れられます。テンプレートと編集規則で担保します。規則は4つです。

1. 個人名を書く欄をテンプレートに作らない（オーナー欄を除く）
2. 「〜すべきだった」という文型を使わず、「〜が検出できなかった」「〜を防ぐ仕組みがなかった」に置換する
3. 感情を表す語（ひどい、信じられない、不注意な）を使わない
4. 根本原因の欄は「何が」を書き、「誰が」を書かない

2番目の効果を、書き換えの例で示します。

オーナーは1名にします。複数人をオーナーにすると、誰も責任を持ちません。単一のオーナーと、複数の協力者という構成にします。オーナーの決め方は「指揮担当が既定。指揮担当を立てていなければ一次対応者」です。決めていないと、書く人が決まらないまま時間が経ちます。

ただしオーナーが1名であることと、執筆が1名であることは別です。対応に関わった全員を執筆に入れてください。1チームだけ、あるいは1人だけで書くと、原因に寄与した要因を見落とします。

もう1つ、人の行動を変える対策は採用しません。「危険なコマンドを実行しないよう教育する」は予防策として弱いということです。システム側で実行できないようにするほうが確実に効きます。

最後に、会議の場での対処も渡しておきます。経営層が「誰かが事前に分かっていたはずだ、なぜその人の話を聞かなかったのか」という発言をした場合、個人を問う問いを、一般化した問いに置き換えます。「見過ごした兆候はあったか。あったとして、なぜそれを退けたのか」。誰が正しかったかを特定するより、誤解を招く情報がどこから来たかを調べるほうが、組織の利益になります。

アクションアイテムの4要件と、必ず入れる2件#

アクションアイテムには4つの要件があります。

1. 単一の所有者
2. 優先度（全部が同じ優先度なら、それは優先度ではありません）
3. 追跡番号
4. 検証可能な終了状態

4番目が最も抜けます。「監視を改善する」は終了を判定できません。「機械の◯パーセント以上が失われたときにアラートを出す」なら判定できます。改善する、強化する、見直すといった曖昧な動詞を使ったら、書き直してください。

そのうえで、どのポストモーテムにも入れるものが2件あります。

1. ユーザーに影響した障害には、最低1件の最優先バグを紐づける。GoogleのVPは「ユーザーから見れば、後続のアクションのないポストモーテムは、ポストモーテムがないのと区別がつかない」と述べています
2. 予防のアクションを最低1件入れる。緩和のアクション（次に起きたときに早く直す）だけを並べると、同じ障害が同じ頻度で起き続けます

2番目を確実にするために、アクションアイテムを分類します。予防、緩和、検知、修復、調査の5分類です。分類ごとに並べると、予防が0件であることが目に見えます。

遅いポストモーテムは、書かなかったのと同じになる#

Googleが公開している良い例と悪い例には、公開までの時間に決定的な差があります。良い例は障害の終息から1週間以内、悪い例は4か月後です。そして悪い例のほうは、その4か月のあいだに同種の障害が再発しました。

速さが必要な理由は2つです。記憶が新しいほうが正確であること。そして、影響を受けた人は説明を待っており、待たされるほど推測で空白を埋めることです。

公開範囲は「社内の全員が読める」を既定にしてください。チーム内に閉じると、他チームが同じ設計上の欠陥を繰り返します。障害の性質によっては、顧客に共有することも検討します。誠実に書かれた記録は、失った信頼を戻す手段になります。

レビューを通していないポストモーテムは、存在しないのと同じです。確認する観点は5つあります。

1. 記録すべきデータが揃っているか
2. 影響の評価は網羅されているか
3. 原因の掘り下げは十分か
4. 対応計画は妥当で、バグの優先度も妥当か
5. 関係者に共有したか

レビュー会は定例で置きます。未完了の議論とコメントを閉じ、文書の状態を確定させる場です。

「時間が取れない」という理由で質が落ちたポストモーテムは、再発の確率を上げます。ポストモーテムの作業そのものを計画に載せてください。1件6時間という数値には、この執筆時間が含まれています。

再発したときに疑うのは、対策ではなく対策の選び方#

同じ障害が繰り返されたとき、多くの組織は「対策が甘かった」と結論づけます。疑うべきは、対策の内容ではなく対策の選び方です。確認する点は5つあります。

1. アクションアイテムのクローズが遅すぎないか
2. 機能開発の速度が、信頼性の修正に優先していないか
3. そもそも正しいアクションアイテムを拾えていたか
4. 該当のサービスは、作り直す時期に来ていないか
5. 深刻な問題に応急処置を重ねていないか

傾向を見るための集計項目も決めておきます。月あたりの件数、平均の継続時間、検知までの時間、解決までの時間、影響範囲。これらをポストモーテムのメタデータ欄から機械的に集められる形にします。

ここで保持期間の制約が効いてきます。Cloud Monitoring の終了済みインシデントの保持は13か月です。四半期の棚卸しには足りますが、前年同期との比較には足りません。年をまたいだ比較をしたいなら、台帳を監視システムの外側に持ってください。

最後に評価の話をします。ポストモーテムを書いたことだけを評価すると、書かれるが閉じられないアクションアイテムが積み上がります。アクションアイテムの完了も評価に含めてください。

シークレットローテーションは、戻せなくなる時点から書く#

ここまでで作ったランブックの型を、具体的な手順に適用します。題材はシークレットローテーションです。

線引きを先に明示します。何を・どの頻度で更新するかは第5回のポリシーです。それをどう実行するかが本記事のランブックです。頻度の決め方には戻りません。また、クラスタ自身の資格情報（APIサーバのIPアドレス、ルート認証局、ServiceAccount署名鍵、集約レイヤ認証局）のローテーションは第14回で扱いました。ここで扱うのは、アプリケーションが使う資格情報です。

戻せなくなる時点は「破棄」#

Secret Manager のシークレットバージョンは、3つの状態を持ちます。

「無効にしたから費用が下がる」は成り立ちません。有効と無効はどちらも課金対象で、課金が止まるのは破棄したときだけです。

第13回で移行計画を、第14回で更新計画を書いたとき、どちらも最初に決めたのは手順ではなく戻せなくなる時点でした。同じ形をここにも適用します。戻せなくなる時点は破棄です。手順は4段になります。

1. 新しいバージョンを追加する。この時点では、まだ誰も使っていません
2. 参照を新しいバージョンへ切り替え、切り替わったことを観測値で確認する
3. 旧バージョンを無効化する。ここまでは戻せます
4. 観測期間を置いてから破棄する。ここから戻せません

3番目と4番目のあいだに置く観測期間の決め方が、この手順の核心です。旧バージョンを参照する可能性のある処理のうち、最も実行間隔が長いものの周期に合わせます。日次バッチしかないなら1日では足りず、月次バッチがあるなら1か月以上が必要です。

第14回で、非推奨APIの検出に30日の観測窓があり、四半期バッチ、年次ジョブ、手順書にしかない操作、停止中のワークロードがそこから漏れると書きました。ここでも同じ4つの母集団が漏れます。実行間隔の長い処理の一覧を先に作ってください。

完了条件は、第13回・第14回と同じ形にします。設定値ではなく観測値で書きます。「旧バージョンを無効化した」ではなく、「旧バージョンへのアクセスログが観測期間中に0件だった」を完了条件にします。

スケジュールしただけでは、回っていない#

Secret Manager にはローテーションのスケジュール機能があります。ただしこの機能は値を変更しません。指定した時刻に Pub/Sub トピックへメッセージを送るだけで、新しい値の生成とアプリケーションへの反映は自前で実装します。

設定上の制約も押さえておきます。

• ローテーション周期は1時間以上
• 次回ローテーション時刻は5分より先
• 周期を指定する場合は、次回時刻の指定も必須
• Pub/Sub トピックの構成が前提

そして静かに止まる経路が2つあります。

1. 処理中のローテーションがあると、スケジュールされたローテーションはスキップされます。Secret Manager が Pub/Sub へ送信しようとしているあいだは処理中とみなされます
2. 失敗した送信は最大7日間自動で再試行され、その後ローテーションはキャンセルされます

どちらもエラーとして通知されません。したがってローテーションが実行されたことを、別の経路で確認する必要があります。「最終ローテーション日時が予定より古い」という条件を監視対象に1本足してください。第15回の設計に追加する項目です。通知が飛ばなかったことは、通知では検出できません。

なお、本番で latest エイリアスを参照しないという第5回の決定が、ここで効いてきます。参照を明示的なバージョンにしておかないと、手順の2番目（参照の切り替え）を制御できません。

漏洩時の手順は、定期ローテーションと順序が逆#

ここまでの4段は、定期ローテーションの手順です。漏洩が疑われる場合は、順序が逆になります。

理由は単純です。漏洩している資格情報が有効なまま切り替えを待つ時間は、被害が継続する時間です。

この2つを1本の手順書にまとめないでください。分岐条件（漏洩の疑いがあるか）を先頭に置き、2本の別のランブックに分けます。深夜に読む文書で分岐を追わせると、間違えます。

漏洩時に必要なものが1つあります。その資格情報を参照しているワークロードの一覧です。これは障害の最中には作れません。第5回で設計したシークレット管理に加えて、参照元の一覧を用意してください。

そして最後に、第5回で空欄のままだった項目が本記事で埋まります。第5回の実務テンプレートには、緊急時の権限昇格（Break-glass）の有効期限を書く欄があり、その根拠として「Sev1の対応SLAとの対応」という但し書きが付いていました。ここで対応づけるのは一次応答の5分ではなく、対応が終わるまでの想定時間です。本記事で示した「1件のインシデント対応に平均6時間」がその基準になります。6時間を既定の有効期限とし、それを超えるなら延長ではなく再申請にしてください。再申請にすると、長期化した対応が記録に残ります。

【実務テンプレート】Severity定義表・ランブック・ポストモーテム#

ここまでの判断を、そのまま転記できる形にまとめます。

Severity定義とエスカレーション表#

1枚に収めます。列は段、判定条件、呼び出す対象、一次応答、通知経路、ポストモーテムの要否、クラウドのケース優先度の7つです。

表の下に、次の3つの注記を必ず置いてください。

1. 一次応答は通知を受け取った時刻から測る
2. 検知には最短で約6分30秒かかる。発生時刻からの総計はこれを加算する
3. 宣言はこの表の判定に基づき、一次対応者が単独で行う。承認が必要なのは影響の大きい緩和策の実行のみ

ランブック（必ず持たせる5項目）#

アラート台帳の1行に対して1本。中身は5項目に固定します。

1. このアラートが鳴っている状態は何を意味するか。ユーザーに何が起きているかを1文で書く
2. 影響の評価に使う指標とダッシュボード。見る順番まで固定する
3. 打てる緩和策と、それぞれの所要時間。汎用的な緩和策を含め、実測値を書く。データの整合性が疑われる場合の分岐と、第7回の復元所要時間もここに入れる
4. エスカレーションの条件と連絡先。何分経過したら、何が確認できなかったら、誰を呼ぶか
5. やってはいけないこと。過去に状況を悪化させた操作。ここに書かれた1行が、この文書で最も価値のある部分です

ここに書かないものも決めておきます。恒久対処の手順、原因の解説、製品の仕様説明。これらはリンクにします。深夜に読む文書に、読む必要のない段落を置かないでください。

ポストモーテムのテンプレート#

章立ては9つです。

1. 概要（影響と根本原因を各1文から2文で）
2. 影響（ユーザー、収益、チームの3方向。数値で書く）
3. 根本原因と引き金
4. 時系列と復旧の経過
5. うまくいったこと
6. うまくいかなかったこと
7. 幸運だったこと
8. アクションアイテム
9. 用語集

各欄の注意を書き添えます。影響の欄は、正確な数値がなくても推定値を書きます。測り方が分からなければ、直ったことも分かりません。根本原因の欄は「何が」を書き、「誰が」を書きません。アクションアイテムは分類・所有者・優先度・追跡番号・検証可能な終了状態の5列を持たせます。

用語集を必須にする理由は、読者がチームの外にいるからです。用語の説明がない文書は読まれず、読まれない文書は組織に何も残しません。説明が必要な語かどうかは、対応に関わっていない同僚が読んで意味を取れるかで判定します。

最後に、後から集計するためのメタデータ欄を付けます。検知の手段、検知までの時間、解決までの時間、影響範囲、Severityの5項目です。この5項目が全件揃っていれば、四半期ごとの傾向分析が転記作業だけで済みます。

次回予告#

本記事で設計したのは、日常のインシデントに対する恒常的な体制です。Sev1を5分、Sev2を30分と決め、1シフト2件という上限から人数とカバー範囲を逆算し、緩和を原因分析より前に置きました。

しかし、リージョン全体が失われたときの復旧は、この体制の延長線上にはありません。Sev1を宣言してもディザスタリカバリの発動は別の判断であり、判断に使う数値も違います。

次回の第17回「BCP・ディザスタリカバリ設計書」では、RPOとRTOの定義、Veleroによるバックアップ構成、クロスリージョンでの復旧手順を扱います。指揮の体制は本記事のものをそのまま使います。変わるのは判断の内容ではなく、判断に使う数値です。