runbook

ランブック — 運用ランブックを作成または読み込む

トピック（例：/runbook ARI management group）を指定して呼び出した場合：

1. runbooks/ を検索し、トピックに一致する既存のランブックを探します
2. 見つかった場合は、ランブックを読み込んで表示します
3. 見つからない場合は、次のテンプレートを使用して新しいものを作成します：

# Runbook: {{title}}

## Purpose
[One sentence — when and why to use this]

## Prerequisites
-

## Steps
1.

## Verification
- [ ]

## Troubleshooting
| Symptom | Cause | Fix |
|---------|-------|-----|

## Last Tested
{{date}}

kebab-case のファイル名を付けて runbooks/ に保存します。

---

注意点

• 古いランブックは、ランブックがないよりも危険です： 18 か月前にテストされたランブックには、コマンドのフラグ、ダッシュボードの URL、ロールバック手順について、誤った情報が確信たっぷりに書かれている可能性があります。Last Tested が 90 日を超えているものは疑わしいとみなし、インシデント対応のプレッシャーの中で信頼する前に、再検証してください。
• テストされていないロールバック手順は飾りにすぎません： この状態から terraform destroy を実行したことがないなら、機能するかどうかはわかりません。ロールバック手順は書き留めるだけでなく、少なくとも一度は本番環境以外のレプリカでリハーサルしておく必要があります。
• 前提条件が不足すると、午前 2 時にランブックが失敗します： 「スクリプトを実行するだけ」という手順は、kubectl のコンテキスト、VPN、踏み台サーバーでの sudo 権限、有効なトークンが揃っていることを前提としています。前提条件はすべて、正確な確認コマンドとともに記載してください。オンコールエンジニアは、ターミナルを開いているあなたではありません。
• 一度うまくいった手順をコピーしただけでは、手順とは呼べません： 稼働中のセッションから取得した kubectl patch コマンドには、Pod 名、タイムスタンプ、特定のリソースバージョンがハードコードされている場合があります。実行のたびに変わる値はすべてパラメーター化してください。そうしないと、2 回目には失敗します。
• コマンドのない確認用チェックボックスは、願望にすぎません： 「サービスが正常であることを確認する」は手順ではありません。curl -fsS https://x/healthz | jq .status こそが手順です。確認項目はすべて、期待される出力を記載した、コピーして実行できるコマンドにしてください。
• システムが変わると、ランブックは知らないうちに劣化します： デプロイメント名の変更、キーコンテナー名のローテーション、イングレスホストの変更によって、何の通知もなくランブックが無効になります。インフラの変更がランブックのレビューにつながるよう、各ランブックをシステムの IaC リポジトリからリンクしてください。