監視は整った、デプロイも自動化した。しかし、実際に障害や運用作業が起きたときに頼れる手順書（Runbook/SOP）が見当たらない――そんな悩みは多くの現場で聞かれます。本記事では「現場で本当に使える手順書」の設計原則と、WordPressに貼れるテンプレート、さらにPythonでの自動生成・検証・配布の最小実装を示します。実務担当者がそのまま導入できる手順を重視しました。
1) なぜRunbook/SOPが必要か（現場で起きる具体例）
運用現場では次のような状況で手順書が求められます。
- 夜間にアラートが上がったが、対応手順がまとまっておらず判断が遅れる。
- 担当者が不在で、代替担当が対応に手間取る。
- 対応後に何を記録すべきかが曖昧で、再発防止が進まない。
こうした課題に対して、手順書は「誰でも同じ初動ができること」「所要時間と期待できる効果が明示されていること」「エスカレーションの入口が明確であること」が重要です。
2) 良い手順書の要件
現場で使える手順書の要件を、短く分かりやすくまとめます。
| 要件 | 説明 |
|---|---|
| 簡潔さ | 初動で必要な手順のみ。長い背景説明は別ページへ。 |
| 所要時間の明示 | 各ステップに見積り時間（例：5分）を付ける。 |
| エスカレーション | 条件付きで誰に連絡するかを明示（連絡手段・電話/SlackのID）。 |
| 実行チェックリスト | 確認済みチェックを残せる項目（ログ取得、プロセス再起動など）。 |
| 検証手順 | 処理後に正常を確認する具体的な方法。 |
よくある失敗
- 長文で読むのに時間がかかる（初動を遅らせる）。
- 実行文書と実際の監視/運用フローが切れている（例：アラート名と手順の紐付けがない）。
- 更新履歴が追えず、古い情報が残る。
3) テンプレート設計（WordPressに貼れるHTML例）
ここではそのままWordPress投稿に貼れる簡易テンプレートを示します。必要な箇所を埋めて運用してください。
単一RunbookのHTMLテンプレート（貼り付け例）
<div class="runbook" id="rb-{{id}}">
<h3>{{タイトル}}</h3>
<p><strong>対象アラート:</strong> {{アラート名}}</p>
<table>
<thead><tr><th>項目</th><th>内容</th></tr></thead>
<tbody>
<tr><th>影響範囲</th><td>{{影響範囲}}</td></tr>
<tr><th>所要時間</th><td>{{所要時間}}</td></tr>
<tr><th>緊急度</th><td>{{緊急度}}</td></tr>
</tbody>
</table>
<h4>手順（チェックリスト）</h4>
<ul>
<li>[ ] {{ステップ1}} <small>（{{目安時間}}）</small></li>
<li>[ ] {{ステップ2}} <small>（{{目安時間}}）</small></li>
</ul>
<p><strong>完了確認:</strong> {{確認方法}}</p>
<p><strong>エスカレーション:</strong> {{担当者名}}（Slack: @user, 呼び出し電話: 080-xxxx-xxxx）</p>
</div>上のテンプレートはコピー＆ペーストでそのままWordPressに貼れます。必要に応じてCSSで見やすさを調整してください。
4) 実践パート（Python中心の最小実装）
ここでは3つの最小実装を示します。いずれも現場ですぐに使える「最小限」で、実務での拡張を想定しています。
A) MarkdownからHTMLへ変換するスクリプト
runbookの作成はMarkdownで行い、配布用にHTMLへ変換するのが扱いやすいです。Pythonの例：
from markdown import markdown
def md_to_html(md_text):
# シンプルに変換（必要なら付加処理を追加）
return markdown(md_text, extensions=['tables'])
if __name__ == '__main__':
with open('runbook.md', 'r', encoding='utf-8') as f:
md = f.read()
html = md_to_html(md)
with open('runbook.html', 'w', encoding='utf-8') as f:
f.write(html)
print('runbook.html を出力しました')
ポイント：Markdownでテンプレートを管理するとPRベースでの編集・レビューがしやすく、Gitでの差分管理も楽になります。
B) 監視アラートから該当Runbookを自動取得・表示する小サービス（Flaskの例）
Prometheus AlertmanagerやCloudWatchのアラートを受け取り、対応するRunbookのURLを返す最小例です。
from flask import Flask, request, jsonify
# 簡易マッピング（実際はDBや検索インデックスを使う）
ALERT_TO_RUNBOOK = {
'HighCpuUsage': 'https://example.com/runbooks/high-cpu',
'DBConnectionError': 'https://example.com/runbooks/db-conn',
}
app = Flask(__name__)
@app.route('/alert', methods=['POST'])
def alert():
payload = request.get_json() or {}
alert_name = payload.get('alertname') or payload.get('title')
runbook_url = ALERT_TO_RUNBOOK.get(alert_name)
if runbook_url:
return jsonify({'runbook': runbook_url}), 200
return jsonify({'error': 'runbook not found'}), 404
if __name__ == '__main__':
app.run(port=8080)
運用案：AlertmanagerやCloudWatchの通知設定でWebhook先をこのエンドポイントに向け、受け取ったアラートをSlack等へ簡易的に展開します。
C) 手順の定期検証（チェックリスト自動実行スクリプトの例）
Runbook内の「確認項目」を自動で検証するスクリプト。ここでは単純なHTTPチェックの例を示します。
import requests
CHECKS = [
{'name': 'サービス応答', 'url': 'https://api.example.com/health', 'expect': 200},
]
def run_checks():
results = []
for c in CHECKS:
try:
r = requests.get(c['url'], timeout=5)
ok = r.status_code == c['expect']
results.append((c['name'], ok, r.status_code))
except Exception as e:
results.append((c['name'], False, str(e)))
return results
if __name__ == '__main__':
for name, ok, info in run_checks():
print(f"{name}: {'OK' if ok else 'NG'} ({info})")
このようなテストをCIで夜間に回すことで、手順の想定通りの検証が続けられるかをチェックできます。
5) インテグレーション（監視・アラートとの紐付け）
実務ではアラートペイロード→Runbook呼び出し→現場表示（Slack/メール/ポータル）の流れを設計します。以下に想定ペイロードと処理の例を示します。
| 発信元 | 例ペイロード（簡略） | 処理 |
|---|---|---|
| Prometheus Alertmanager | {“labels”:{“alertname”:”HighCpuUsage”,”instance”:”app01″},”annotations”:{“summary”:”CPU高負荷”}} | alertnameでRunbookを検索してURLをSlackに投稿する。ボタンで『手順を表示』。 |
| AWS CloudWatch | {“AlarmName”:”DBConnectionError”,”State”:”ALARM”} | AlarmNameでRunbookを検索、オペレーション用メールテンプレを生成する。 |
Slack連携時の運用例：
- アラート投稿にRunbookリンクと「簡易ステータス更新ボタン（対応中／完了）」を付ける。
- ボタン押下で簡易記録（誰がいつ対応を開始・終了したか）を自動保存。
6) 検証と維持
手順書は作ったら終わりではありません。以下のワークフローを推奨します。
- 定期ドライラン：四半期ごとに想定ケースで実行（50〜90分の短縮版で実施）。
- 変更時のQA：変更はPRで提出、ステークホルダが承認してからマージ。
- バージョン管理：Gitで履歴を管理し、差分とリリースノートを自動生成。
簡易QAフロー（例）
| ステップ | 担当 | 期限 |
|---|---|---|
| 草稿作成 | 作成者 | 作成日+3日 |
| レビュー（技術） | オンコール/エンジニア | レビュー依頼+2営業日 |
| レビュー（現場） | 運用担当 | レビュー依頼+2営業日 |
| 承認・公開 | 運用責任者 | 承認後即時 |
7) ロールアウトと運用ルール
導入時のポイント：
- オンボーディング：現場向け30分のハンズオン（テンプレートの読み方・Slack連携の使い方を実演）。
- SLA/エスカレーション：Runbook内に「初動許容時間」と「次の連絡先」を明示する。
- 短縮版の用意：非専門スタッフ向けに、最重要3ステップだけの短縮カードを準備する。
付録・配布物
まず作るべきRunbook一覧（優先度目安）
| 優先度 | Runbook名 | 理由 |
|---|---|---|
| 高 | サービスのヘルスダウン対応 | ユーザ影響が大きく初動が重要 |
| 高 | データベース接続エラー | データ整合性リスクが高い |
| 中 | バックアップ失敗 | 復旧計画と再実行手順が必要 |
| 低 | 証明書期限切れ対応 | 事前検知で回避できるが用意は必須 |
WordPress貼り付け用：導入チェックリスト（HTML）
<ul>
<li>RunbookをMarkdownで作成し、Gitで管理する</li>
<li>Markdown→HTMLのCIジョブを用意し、WordPress投稿へ自動公開（またはドラフト保存）する</li>
<li>監視アラートとRunbookのマッピングを実装する（Webhookで呼び出す）</li>
<li>四半期ドライラン計画をカレンダー化し、結果をGitで記録する</li>
</ul>実務導入時の注意点
- 最初から完璧を目指さない：まずは最重要の数本を整備して運用に馴染ませる。
- 現場の声を反映するプロセスを用意する：現場が使わない手順書は意味がない。
- 自動化は補助に留める：手順の自動実行は便利だが、最終判断は人が行う前提を忘れない。
まとめ
本記事では、現場で回るRunbook/SOPの要件とWordPressに貼れるテンプレート、Pythonによる最小実装（Markdown→HTML変換、アラート連携、小さな自動チェック）を紹介しました。まずは次の3ステップから始めてください：
- 最優先のRunbook（サービス停止・DB接続等）をMarkdownで作成し、Gitに登録する。
- Markdown→HTML変換をCIに組み込み、WordPressへ公開するワークフローを作る。
- 監視アラートとRunbookを簡易マッピングするWebhookを用意し、Slack等で即座に参照できるようにする。
これらが整えば、次はドライランによる検証と運用ルールの定着です。Manage AI では、AIとPythonを使って「知識」ではなく「現場で回る運用」に結びつける方法を今後も紹介していきます。実際に導入するときに参考になるテンプレートとサンプルコードは本文中のコピーをお使いください。