ynitto runbook-author
「真夜中に叩き起こされた当番が、迷わず動ける」手順書を書く。属人知を、前提・手順・確認・エスカレーションまで含む再現可能なランブックにする。
一般の技術文書は
technical-writer。本スキルは運用・オンコールの手順に特化する。
良いランブックの条件
- コピペで実行可能 — コマンドはそのまま貼れる形（プレースホルダは明示）
- 各手順に確認ステップ — 実行後「成功をどう確認するか」を必ず添える
- 可逆性とロールバック — 危険な操作には影響と戻し方を併記する
- エスカレーション経路 — 手に負えない時に誰へ・いつ上げるかが明確
- 判断を減らす — 当番が迷う分岐は、条件を明示して機械的に辿れるようにする
ワークフロー
Step 1: 対象と種別を決める
ランブックの種類を見分ける:
| 種別 | 例 |
|---|---|
| アラート対応 | 「エラー率上昇」「ディスク逼迫」など監視発報への対処 |
| 定常運用 | デプロイ・バックアップ・証明書更新・バッチ再実行 |
| 緊急時 | 障害時のフェイルオーバー・ロールバック・データ復旧 |
Step 2: 情報を集める
- トリガー（何が起きたらこの手順を使うか）
- 前提（必要な権限・アクセス・ツール）
- 実際の手順（コマンド・画面操作・判断基準）
- 関連情報（ダッシュボード・ログの場所・連絡先）
不明点は推測で埋めず「要確認」とする。
Step 3: 構造化して書く
references/template.md のテンプレートで:
- 手順は番号付きの命令形（「〜する」）。1ステップ1動作
- 各ステップに 確認 を付ける（「成功なら X が表示される」）
- 分岐は
もし X なら → 手順Nと明示 - 危険操作には ⚠️ と影響・ロールバックを併記
Step 4: 連携・配置
- アラート対応ランブックは
observability-designerのアラートに、緊急時手順はincident-responderの止血手段にリンクさせる - 配置先（
wiki-use/obsidian-use/ リポジトリ docs）への保存を提案する
ガードレール
| 制限 | 内容 |
|---|---|
| 推測禁止 | 不確かな手順・コマンドを断定で書かない。未確認は「要確認」と明記 |
| 危険操作の警告 | 破壊的コマンド（削除・本番変更）には ⚠️・影響・ロールバックを必ず添える |
| 秘匿情報 | 手順書に資格情報・トークンを直書きしない。シークレット参照の方法を示す |
| 確認の併設 | 実行ステップには必ず成否確認を付け、「やりっぱなし」の手順を作らない |