| name | sop-creator |
| description | Create runbooks, playbooks, and technical documentation for engineering teams. Use when the user wants to document a process, create a runbook, build operational docs, or formalize any repeatable technical procedure. Triggers on requests like "create a runbook for...", "document this process", "write a playbook", or any technical documentation request. |
SOP 與 Runbook 建立器
建立人們真的會照著做的實用文件。
理念
沒有人會讀 50 頁的文件。 讓它可掃描、可執行,而且不可能被誤解。
核心原則:
- 可掃描 - 標題、條列、表格。不要整片文字牆。
- 可執行 - 每個步驟都是你要「做」的事,而不是你要「考慮」的事
- 具體明確 - 數字、名稱、閾值。不要用「視需要」或「適當時」
- 可測試 - 明確的成功標準。你怎麼知道它成功了?
- 持續維護 - 負責人、最後更新日期、審查排程
SOP 類別
根據你的使用情境選擇正確的格式:
技術/工程
| 類型 | 何時使用 |
|---|
| Runbook | 緊急回應、事件、值班 |
| 部署 Playbook | 版本發佈、遷移、維護 |
| 故障排除指南 | 除錯、診斷樹 |
| 操作指南 | 一次性設定、組態 |
| ADR | 架構決策 |
營運/業務
| 類型 | 何時使用 |
|---|
| 流程 SOP | 可重複的業務工作流程 |
| 檢查清單 | 品質控制、驗證 |
| 決策樹 | 複雜的條件判斷場景 |
| 交接文件 | 角色交替、班次交接 |
內容/創意
| 類型 | 何時使用 |
|---|
| 製作工作流程 | 內容產出管線 |
| 審查流程 | 審批工作流程 |
| 發佈檢查清單 | 上線前驗證 |
通用
| 類型 | 何時使用 |
|---|
| 標準 SOP | 任何可重複的流程 |
| 快速參考 | 較長 SOP 的精簡版 |
| 入職指南 | 新人上手 |
通用結構
每個 SOP 至少需要:
# [這做什麼]
> **摘要:** 一句話——做什麼、何時做、誰來做。
## 完成定義
以下全部達成即為完成:
- [ ] [主要成果]
- [ ] [驗證步驟]
- [ ] [任何交接/通知]
## 何時使用
[觸發條件]
## 前提條件
[開始前需要什麼]
## 流程
[編號步驟——實際的工作]
## 驗證完成
[回到完成定義,確認全部勾選]
## 出問題時怎麼辦
[常見問題與修復方式]
## 有問題?
[聯絡誰]
完成定義是最重要的區段。 放在最前面。做成檢查清單。要具體。
撰寫規則
要具體
| 不要這樣寫 | 改成這樣 |
|---|
| 「聯絡團隊」 | 「在 #ops-team 頻道中 @sarah」 |
| 「等到準備好」 | 「等到狀態顯示『完成』(約 5 分鐘)」 |
| 「仔細審查」 | 「在儀表板中檢查項目 A、B、C」 |
| 「適當時」 | 「如果數值 > 100」 |
| 「定期」 | 「每週一上午 9 點」 |
| 「盡快」 | 「2 小時內」 |
步驟以動作開頭
# 不好
「報告在發送之前應該先經過審查,以確保
所有資料欄位的正確性和完整性。」
# 好
1. 在 [系統] 中開啟報告
2. 驗證以下欄位已填寫:
- [ ] 客戶名稱
- [ ] 金額
- [ ] 日期
3. 點擊「發送」
警告放在前面
# 不好
1. 刪除舊記錄
注意:此操作無法復原
# 好
> **警告:** 這會永久刪除記錄。如有需要請先匯出。
1. 刪除舊記錄
決策點要清楚
# 不好
「依優先等級處理請求」
# 好
**如果優先等級是:**
- **緊急:** 放下一切,立刻處理,通知主管
- **高:** 4 小時內處理
- **一般:** 24 小時內處理
- **低:** 加入每週批次處理
格式選擇指南
問你自己:
- 這是用於緊急情況嗎? → Runbook
- 這是複雜的多階段專案嗎? → Playbook
- 這是簡單的重複性任務嗎? → 標準 SOP 或檢查清單
- 有很多條件判斷分支嗎? → 決策樹
- 這是用於除錯嗎? → 故障排除指南
- 這是記錄一個決策嗎? → ADR
- 這是給新人看的嗎? → 入職指南
中繼資料(保持簡潔)
---
title: [清楚的名稱]
owner: [負責人或團隊]
last_updated: [日期]
review_schedule: [季度/年度/視需要]
---
就這樣。除非你真的需要,否則不用文件編號、版本矩陣或審批流程。
範本
每個範本都在 references/ 中:
所有範本都以完成定義作為主要的成功標準。
品質檢查清單
發佈前:
反模式
消滅這些:
- 「根據公司政策...」(直接說該做什麼)
- 「建議...」(直接說「做 X」)
- 「請確保...」(直接說「檢查 X」)
- 被動語態(「表單應被提交」→「提交表單」)
- 描述要做什麼而不是展示
- 沒有結構的文字牆
- 一個月後就過時的截圖
要做這些:
- 從最常見的路徑開始
- 把邊緣情況放在底部
- 連結到相關文件而不是複製
- 用表格呈現參考資訊
- 用檢查清單做驗證步驟
- 包含「我卡住了」的逃生出口