Runbooks

本番環境でインシデントが発生すると、チームにはランブック—ポッドの再起動、データベースフェイルオーバー、スケーリング操作といった一般的な障害に対するステップバイステップの手順—があります。問題は、深夜3時に適切なランブックを見つけ、プレッシャーの中で正確に実行することです。 CloudThinker Runbooksはそのギャップを解消します。RCA調査中、AIエージェントが接続されたランブックソースを自動検索し、関連する手順を見つけて修復コマンドを実行します—破壊的な操作には人間の関与を保つポリシー駆動の承認コントロールが付随します。

手動アップロードと接続リポジトリを持つRunbook Sourcesダッシュボード

---

​

ランブックの仕組み

---

​

ランブックソースの接続

Deep Response Engine > Runbooks に移動してソースを管理します。CloudThinkerは4種類のソースタイプをサポートしており、それぞれ異なるワークフローに対応しています。

Confluence設定を使った新しいランブックソースの追加

​

Confluence

ConfluenceナレッジベースをAIエージェントに接続し、オペレーション手順のウィキページを検索できるようにします。 セットアップ:

1. Runbooksページで Add Source をクリック
2. 名前を入力（例：「SRE Runbooks」）
3. ソースタイプとして Confluence を選択
4. Atlassianの接続を選択（Connections > Atlassian で設定）
5. オプションで特定の Space Key（例：SRE）に検索範囲を限定
6. Labels を追加してページをフィルタリング（例：runbook、incident-response）
7. Add Source をクリック

エージェントの検索方法： RCA中、エージェントはConfluenceのCQLクエリ言語を使用し、設定済みのスペースおよびラベルフィルタ内でインシデントのコンテキストに一致するページを検索します。

​

GitHub

GitHubリポジトリにあるランブックのMarkdownファイルをエージェントに指定します。 セットアップ:

1. Add Source をクリック
2. ソースタイプとして GitHub を選択
3. GitHubの接続を選択（Connections で設定）
4. ランブックを含む repository を選択
5. branch を設定（デフォルトは main）
6. オプションで path prefix を設定して検索範囲を制限（例：docs/runbooks/）
7. file patterns を設定してマッチするファイルを指定（デフォルトは *.md）
8. Add Source をクリック

エージェントの検索方法： エージェントはGitHub APIを使用してパスとパターンフィルタに一致するファイルを一覧・読み込みし、現在のインシデントとの関連性を分析します。

​

GitLab

GitHubと同じワークフローで、GitHubの代わりにGitLabの接続を使用します。 セットアップ:

1. Add Source をクリック
2. ソースタイプとして GitLab を選択
3. GitLabの接続を選択
4. repository・branch・path prefix・file patterns を選択
5. Add Source をクリック

エージェントの検索方法： エージェントはGitLab APIを使用してリポジトリから一致するファイルを検索・取得します。

​

手動アップロード

外部システムに手順が保存されていない場合は、Markdownのランブックファイルを直接アップロードします。 セットアップ:

1. Runbooksページで Upload Runbook をクリック
2. .md ファイルをドラッグ＆ドロップ（最大20ファイル、各5 MB）
3. 確認前に必要に応じてファイル名を編集
4. Confirm Upload をクリック

アップロード後、CloudThinkerはMarkdownのコードブロックから書き込みコマンド（kubectl apply・aws のミューテーション・helm install など）を自動抽出します。この抽出されたコマンドがコマンドごとのパーミッションの基礎となります。

---

​

コマンドごとのパーミッション

手動ランブックには独自の安全機能—コマンドごとのパーミッションコントロール—が備わっています。Markdownファイルをアップロードすると、CloudThinkerのAIがコードブロックを読み取り、すべての書き込み/変更コマンドを抽出します。これにより、エージェントが自律的に実行できる操作を細かく制御できます。

pod-crashloopbackoffランブックのコマンドごとのパーミッションコントロール

​

仕組み

1. 自動抽出：アップロード後、システムはすべてのコードブロックを解析し、インフラを変更するシェルコマンド（例：kubectl set resources・kubectl rollout restart・kubectl delete）を特定します
2. 読み取り専用コマンドはスキップ：kubectl get・kubectl describe・kubectl logs などのコマンドは抽出されません—エージェントは常に読み取り専用コマンドを実行できます
3. 各コマンドにパーミッションを割り当て：抽出されたすべての書き込みコマンドはデフォルトで Require Approval から始まります

​

パーミッションレベル

​

コマンドの管理

ランブック詳細ダイアログから：

• すべてのパーミッションを一括変更：「Set all to…」ドロップダウンを使用して、すべてのコマンドをAllow・Require Approval・Denyに一括変更します
• 個別パーミッションの変更：任意のコマンドの横のドロップダウンをクリックしてパーミッションレベルを調整します
• コマンドの追加：新しいコマンドパターンを入力してEnterを押すと、リストに追加されます
• コマンドの削除：削除アイコンをクリックしてポリシーからコマンドを削除します
• コマンドの全文表示：展開矢印をクリックして複数行または長いコマンドを全文表示します

---

​

承認ワークフロー

RCA中にエージェントが関連ランブックを見つけ、ポリシーが承認を必要とする場合、次のフローが実行されます。

​

承認フロー

1. エージェントがランブックを発見：調査中、エージェントはソースを検索して一致する手順を特定します
2. ポリシー評価：システムはワークスペースの承認ポリシーをランブックとそのコマンドに照らして確認します
3. 通知の送信：承認が必要な場合、設定されたすべてのチャンネルで通知が届きます：
   • メール：ランブックのタイトル、ソースリンク、ポリシーの理由
   • Slack：インシデントのコンテキストを含むインタラクティブ通知
   • アプリ内：承認待ちを示すインシデントのバッジ
4. 承認または拒否：承認をクリックしてエージェントの続行を許可するか、拒否をクリックして実行をブロックします
5. エージェントが続行：承認されるとエージェントはランブックコマンドを実行します。拒否された場合、エージェントはそのランブックを実行せず調査を続けます

​

承認ステータス

​

実行ステータス

承認後、各実行はその結果を追跡します：

​

実行履歴の確認

Runbooksページの Execution History タブに切り替えると、インシデントをまたいだすべてのランブック実行を確認できます。以下の操作が可能です：

• ランブックタイトルで検索
• ポリシーの決定・承認ステータス・実行結果を確認
• どのランブックがどのインシデントに使用されたかを追跡

---

​

ベストプラクティス

ソースの整理：

• ソースにわかりやすい名前を付ける（例：「K8s Emergency Runbooks」「Database Failover Procedures」）
• パスプレフィックスとファイルパターンを使用して検索を集中・高速化する
• Confluenceではラベルでドメイン別にランブックを分類する（例：kubernetes・database・networking）

パーミッション戦略：

• 信頼が構築されるまで、すべてのコマンドを（デフォルトの）Require Approval から始める
• 十分にテストされた低リスクのコマンド（スケーリング操作・ログ収集など）を徐々に Allow に移行する
• 破壊的なコマンド（delete・drop・force）は永続的に Require Approval に維持する
• 自動化してはならないコマンド（本番データベースのdropなど）には Deny を使用する

ランブックの品質：

• シェル言語ヒント付きの明確なコードブロックでMarkdownのランブックを作成する（```bash）
• 最良の抽出結果のために1行に1コマンドを使用する
• 各手順をいつ使用すべきかのコンテキストを含める—エージェントはこれをランブックとインシデントのマッチングに使用する
• ランブックは集中させる：すべてを1つのドキュメントにまとめるより、1ファイルに1手順の方が効果的

---

​

次のステップ