運維手冊 Runbook 怎麼寫提示詞（告警處置步驟：值班同學半夜也能照着做）
給某個告警或常見故障編寫處置手冊時用：把老員工腦子裏的排查經驗整理成「先確認什麼、再看什麼、怎麼止血、什麼時候升級」的步驟文檔，每一步有可複製的命令和判斷標準，新人值班也能處理。
通用大模型 對話模型通用
請幫我為下面的告警編寫一份運維處置手冊（Runbook）。讀者是半夜被叫醒、可能不熟悉這個系統的值班工程師，所以每一步都必須具體到可以照做。 - 告警名稱與觸發條件：[告警名稱與觸發條件]（例：訂單服務 5xx 錯誤率超過 5% 持續 3 分鐘） - 涉及的系統與架構簡述：[涉及的系統與架構簡述]（例：K8s 部署，依賴 MySQL 和 Redis） - 老員工的排查經驗（口述整理即可）： [排查經驗] - 可用的工具與平台：[可用的工具與平台]（例：Grafana、Kibana、kubectl、雲控制台） - 升級聯絡方式與時限：[升級聯絡方式與時限]（例：15 分鐘未恢復聯絡後端負責人，寫角色不寫個人電話） 手冊結構： 1. 概述：這個告警意味着什麼、對用戶的影響、嚴重程度。 2. 首先確認（2 分鐘內完成）：是否誤報；影響範圍有多大；最近有沒有發佈或變更（給出查詢變更記錄的方法）。 3. 排查步驟：按「最常見原因優先」排序，每一步寫清： - 要執行的命令或要打開的面板（命令放在代碼塊裏，可直接複製，變量部分用大寫佔位符並說明怎麼取值）； - 看到什麼結果說明是這個原因，看到什麼結果說明不是、繼續下一步。 4. 止血措施：每種原因對應的快速恢復辦法（回滾、擴容、切流、重啟），寫明操作命令、預期效果、風險和是否需要先請示。有破壞性的操作（刪除數據、清空緩存、強制重啟數據庫）必須標註「需負責人確認」。 5. 升級規則：什麼情況下、多長時間內沒恢復，要通知誰（寫角色）。 6. 恢復後的確認：看哪些指標確認已經恢復、要觀察多久。 7. 事後：需要記錄的資訊，用於後續復盤。 經驗裏沒有提到、但你認為必要的檢查步驟，標「建議補充，需團隊確認」。手冊中不要出現密碼、密鑰和個人聯絡方式。
高亮處換成你自己的內容：[告警名稱與觸發條件]、[涉及的系統與架構簡述]、[排查經驗]、[可用的工具與平台]、[升級聯絡方式與時限]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[排查經驗] 可以直接錄一段老員工的口述轉成文字貼進來，比如「一般先看是不是數據庫連接池滿了，滿了就看有沒有慢查詢……」。AI 會把這些經驗整理成有判斷標準的步驟。
常見坑：
- 步驟寫成「檢查數據庫狀態」這種籠統的話，值班的人根本不知道該敲什麼命令、看哪個數字。每一步都要有具體命令和「看到什麼說明什麼」。
- 止血手段沒有標風險。半夜慌亂時，有人會直接執行清空緩存、重啟數據庫，造成更大的事故。
- 手冊寫完就過時。每次事故復盤後，都要回來更新對應的 Runbook。
追問技巧：手冊寫完後追問「如果按這個順序排查，最壞情況下要多久才能找到原因？有沒有可以並行或提前的步驟」；也可以讓 AI 把手冊改寫成一張一頁紙的速查表。
示例輸出
示例，僅供參考（節選）
3.2 檢查數據庫連接池是否耗盡
bash
kubectl logs -n prod deploy/order-service --since=10m | grep -c "Connection is not available"- 結果大於 0，且持續增長：連接池耗盡，進入 3.3 查找慢查詢；
- 結果為 0：不是連接池問題，進入 3.4 檢查 Redis。
4.1 止血：回滾最近一次發佈（適用於告警開始時間與發佈時間吻合）
bash
kubectl rollout undo deploy/order-service -n prod
kubectl rollout status deploy/order-service -n prod預期 3 分鐘內錯誤率回落到 1% 以下。風險：回滾會撤銷本次發佈的所有功能，無需請示，但須在值班群告知。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～