行完全指南：三種觸發(fā)方式、執(zhí)行視圖與審計追溯)
OneUptime Runbook 執(zhí)行完全指南三種觸發(fā)方式、執(zhí)行視圖與審計追溯【免費下載鏈接】oneuptimeComplete open-source monitoring and observability platform.項目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文基于 OneUptime 開源倉庫中的 Runbook 運(yùn)行文檔英文原版 / 法文版撰寫。Runbook運(yùn)行手冊是 OneUptime 平臺中可復(fù)用的響應(yīng)流程——由有序的「手動步驟 自動化步驟」組成可掛接到事件Incident、告警Alert或計劃維護(hù)Scheduled Maintenance上。閱讀本文后你將掌握 Runbook 執(zhí)行的三種觸發(fā)路徑、執(zhí)行視圖的界面要素、手動與自動化步驟的交織運(yùn)行機(jī)制、取消與重跑的正確姿勢以及如何利用快照語義與 50KB 輸出上限構(gòu)建可審計、可追溯的應(yīng)急響應(yīng)流程。一、Runbook 執(zhí)行的三種觸發(fā)路徑在 OneUptime 中一條 Runbook 執(zhí)行Execution只會通過以下三種方式被創(chuàng)建通過規(guī)則自動觸發(fā)——在事件、告警或計劃維護(hù)的Rules → Runbook Rules菜單中配置規(guī)則當(dāng)實體的標(biāo)題或描述匹配正則時自動啟動 Runbook。詳細(xì)規(guī)則語義見 Runbook 規(guī)則文檔。從 Runbook 頁面手動觸發(fā)——在某個 Runbook 的概覽頁點擊Run Now立即運(yùn)行。這種執(zhí)行不掛接到任何事件、告警或計劃維護(hù)屬于臨時性ad-hoc運(yùn)行。從實體流Entity Feed手動觸發(fā)——在某個事件、告警或計劃維護(hù)上點擊Run Runbook運(yùn)行 Runbook。這種執(zhí)行會**掛接attached**到該實體并出現(xiàn)在該實體的頁面中。從源碼結(jié)構(gòu)看第三種路徑體現(xiàn)得尤為直接RunbookExecution數(shù)據(jù)模型為每次執(zhí)行預(yù)留了incidentId、alertId、scheduledMaintenanceId三個可空外鍵以及記錄觸發(fā)人的triggeredByUserId字段見 RunbookExecution.ts。執(zhí)行創(chuàng)建時這些外鍵被寫入執(zhí)行便天然地關(guān)聯(lián)到來源實體。提示規(guī)則觸發(fā)的執(zhí)行同樣會寫入來源實體外鍵——規(guī)則文檔中明確說明規(guī)則觸發(fā)后「執(zhí)行被鏈接到來源實體它會出現(xiàn)在事件/告警/計劃維護(hù)的頁面以及 Runbook 的 Executions 列表中」。二、執(zhí)行視圖一次運(yùn)行的完整檢查清單打開任意一條執(zhí)行你會看到一個檢查清單ChecklistUI。每個步驟顯示以下要素狀態(tài)徽標(biāo)Status Pill——Pending待處理、Running運(yùn)行中、Waiting for you等待你操作、Done已完成、Skipped已跳過、Failed失敗。標(biāo)題與描述——在執(zhí)行時從 Runbook 復(fù)制而來快照語義見下文第六節(jié)。輸出Output可折疊——stdout、返回值、HTTP 響應(yīng)等。錯誤信息——僅當(dāng)步驟失敗時顯示。對于處于WaitingForUser狀態(tài)的手動步驟會顯示Mark Complete標(biāo)記為已完成和Skip跳過兩個按鈕。一個值得注意的細(xì)節(jié)只要執(zhí)行尚未進(jìn)入終態(tài)頁面每 3 秒輪詢刷新一次因此你可以近乎實時地看到自動化步驟完成。這在人工值守大屏或共享排查頁面上非常有用——響應(yīng)者無需手動刷新即可持續(xù)跟蹤進(jìn)度。從源碼可以印證這些狀態(tài)的定義步驟級狀態(tài)枚舉RunbookStepExecutionStatus包含Pending、Running、WaitingForUser、Completed、Skipped、Failed、Cancelled七種見 RunbookStepExecutionStatus.ts而執(zhí)行級狀態(tài)RunbookExecutionStatus則包含Scheduled、Running、WaitingForManualStep、Completed、Failed、Cancelled六種見 RunbookExecutionStatus.ts?？梢钥吹健竁aiting for you」對應(yīng)步驟的WaitingForUser而執(zhí)行整體會停駐在WaitingForManualStep。三、手動與自動化步驟的交織一次執(zhí)行、一條時間線Runbook 的核心能力在于把「人類判斷」和「機(jī)器執(zhí)行」編排進(jìn)同一條時間線。文檔給出的經(jīng)典故障切換流程如下腳本步驟Script捕獲系統(tǒng)當(dāng)前狀態(tài)寫入 S3。手動步驟Manual「通過狀態(tài)頁橫幅通知客戶」。由值班響應(yīng)者確認(rèn)勾選。HTTP 步驟HTTP通過 PagerDuty 呼叫 DBA。手動步驟Manual「確認(rèn)從庫已切換為主庫」。由值班響應(yīng)者確認(rèn)勾選。腳本步驟Script向 Slack 發(fā)送「一切已恢復(fù)」消息。其中步驟 2 和步驟 4 會暫停執(zhí)行直到有人勾選確認(rèn)步驟 1、3、5 自動運(yùn)行。整條流程是一次執(zhí)行、一條時間線、一個真相源one source of truth——每個步驟的狀態(tài)、輸出、錯誤與耗時都被永久記錄在該執(zhí)行上事后復(fù)盤無需再靠記憶拼湊。源碼層面RunbookExecution模型中的stepExecutions字段是一個 JSON 數(shù)組每條記錄「鏡像 Runbook 中的一個步驟并攜帶其狀態(tài)、輸出與時間戳」見 RunbookExecution.ts 相關(guān)的模型注釋RunbookExecution.ts。手動步驟被勾選后執(zhí)行會從下一個步驟繼續(xù)——這正是「暫停-恢復(fù)」機(jī)制的落點。四、取消一次執(zhí)行在執(zhí)行的頁面點擊Cancel Execution取消執(zhí)行即可終止運(yùn)行。取消的語義很明確當(dāng)前步驟如果有會正常結(jié)束不會被強(qiáng)行中斷后續(xù)步驟不再啟動執(zhí)行狀態(tài)變?yōu)镃ancelled。對應(yīng)的執(zhí)行級狀態(tài)Cancelled已包含在RunbookExecutionStatus枚舉中見 RunbookExecutionStatus.ts。對于掛接在事件/告警/計劃維護(hù)上的執(zhí)行取消操作同樣適用——例如誤觸發(fā)或場景已變化時值班人員可以干凈地收尾而不是放任流程繼續(xù)執(zhí)行。五、輸出保留與 50KB 上限為防止失控腳本撐爆數(shù)據(jù)庫每個步驟的輸出被限制為 50KB。超出部分會被截斷并在截斷處打上標(biāo)記見 配置與安全文檔。如果你需要更大的產(chǎn)物artifacts正確的做法是在腳本中將大文件寫入S3 或日志系統(tǒng)然后把URL 存儲在返回值return value中。這樣既保證了執(zhí)行記錄足夠輕量又不丟失可審計的原始數(shù)據(jù)——復(fù)盤時只需點擊步驟輸出里的 URL 即可拉取完整產(chǎn)物。配置文檔中的運(yùn)維建議也呼應(yīng)了這一點「捕獲 URL而不是數(shù)據(jù)塊Capture URLs, not blobs」——一旦步驟產(chǎn)生超過幾 KB 的輸出就寫入 S3 或日志棧并返回 URL。六、重新運(yùn)行 Runbook不可變的快照語義一條 Runbook 執(zhí)行是一次性、不可變的記錄one-shot, immutable record。要重新運(yùn)行請再次點擊Run Now——這不會覆蓋原執(zhí)行而是創(chuàng)建一條全新執(zhí)行攜帶 Runbook 當(dāng)前步驟的新鮮快照snapshot原始執(zhí)行保持原樣用于審計追蹤。這種快照語義貫穿整個 Runbook 設(shè)計步驟的「標(biāo)題與描述」在執(zhí)行時被復(fù)制到執(zhí)行記錄上見第二節(jié)模型中的runbookNameSnapshot字段專門保存「執(zhí)行創(chuàng)建時的 Runbook 名稱」「即使 Runbook 之后被重命名或刪除也會保留」見 RunbookExecution.ts運(yùn)行時編輯 Runbook 模板永遠(yuǎn)不會篡改在途in-flight的執(zhí)行——執(zhí)行繼續(xù)使用自己的快照。這對事后審計意義重大每次故障處理的記錄是「當(dāng)時真實發(fā)生過的步驟與配置」而不是「后來被修改過的模板」。規(guī)則文檔也強(qiáng)調(diào)執(zhí)行是「步驟被快照到新執(zhí)行上」且「編輯事件標(biāo)題不會重新觸發(fā)規(guī)則」。七、檢索歷史執(zhí)行Executions 標(biāo)簽頁每個 Runbook 都有一個Executions執(zhí)行記錄標(biāo)簽頁列出該 Runbook 的全部運(yùn)行記錄支持按以下維度過濾狀態(tài)status——Scheduled/Running/WaitingForManualStep/Completed/Failed/Cancelled等日期范圍date range來源實體source entity——事件、告警或計劃維護(hù)。反過來從某個事件、告警或計劃維護(hù)的頁面進(jìn)入Runbooks 標(biāo)簽頁會展示掛接在該實體上的所有執(zhí)行。規(guī)則觸發(fā)的運(yùn)行也可以在Runbooks → Executions下按狀態(tài)、Runbook 或日期過濾查看見 規(guī)則文檔。結(jié)合數(shù)據(jù)模型可以更清晰地理解檢索能力RunbookExecution對runbookId、incidentId、alertId、scheduledMaintenanceId都建立了數(shù)據(jù)庫索引Index()注解這正是 Executions 列表按 Runbook 或按來源實體快速過濾的底層支撐見 RunbookExecution.ts 等處的索引聲明。八、源碼視角執(zhí)行背后的數(shù)據(jù)模型與隊列8.1 RunbookExecution 表結(jié)構(gòu)核心數(shù)據(jù)表RunbookExecution的關(guān)鍵字段見 RunbookExecution.ts字段類型說明projectId/runbookIdObjectID所屬項目與所屬 Runbook必填runbookNameSnapshotShortText執(zhí)行時的 Runbook 名稱快照statusShortText執(zhí)行級狀態(tài)RunbookExecutionStatusstepExecutionsJSON步驟級執(zhí)行狀態(tài)數(shù)組狀態(tài)、輸出、時間戳incidentId/alertId/scheduledMaintenanceIdObjectID可空來源實體外鍵triggeredByUserIdObjectID可空手動觸發(fā)的用戶startedAt/completedAtDate起止時間failureReasonLongText可空失敗原因權(quán)限方面該模型的表級訪問控制將「創(chuàng)建執(zhí)行」授予ProjectOwner、ProjectAdmin、CreateRunbookExecution、ProjectMember、RunbookAdmin、RunbookMember「讀取執(zhí)行」額外允許Viewer與RunbookViewer見 RunbookExecution.ts。這與 配置與安全文檔 中Runbook權(quán)限組的說明一致RunbookAdmin聚合了全部細(xì)粒度權(quán)限。8.2 隊列與執(zhí)行引擎Runbook 執(zhí)行運(yùn)行在RunbookBullMQ 隊列上Worker 并發(fā)數(shù)為25可在部署中調(diào)整以應(yīng)對大量并發(fā)運(yùn)行。手動步驟被勾選后執(zhí)行會重新入隊從下一步繼續(xù)——讓 Worker 保持熱狀態(tài)避免整條鏈路等待。JavaScript 與 Bash 步驟永遠(yuǎn)不會在 OneUptime Worker 上執(zhí)行而是派發(fā)為RunnerJob含targetAgentId、腳本、狀態(tài)機(jī)Pending → Claimed → Running → Succeeded/Failed/TimedOut/Cancelled、租約、輸出與退出碼由你在自建基礎(chǔ)設(shè)施中安裝的 Runbook Agent 領(lǐng)取執(zhí)行詳見 配置與安全文檔 與 Agent 文檔。這意味著即使執(zhí)行視圖上的腳本步驟「瞬間完成」其實際計算發(fā)生在你的主機(jī)上Worker 只負(fù)責(zé)編排與匯總。8.3 超時與失敗兜底執(zhí)行相關(guān)的超時配置見 Authoring 文檔執(zhí)行超時Execution timeoutJavaScript、Bash、HTTP 步驟默認(rèn)30 秒可在步驟上逐條覆蓋領(lǐng)取超時Claim timeoutBash/JavaScript 步驟默認(rèn)2 分鐘——Worker 等待所選 Agent 領(lǐng)取任務(wù)的時長超時則步驟失敗兩者的可設(shè)范圍均為1 秒到 1 小時超出范圍的值會在步驟運(yùn)行時被鉗制既不會禁用超時也不會讓 Worker 槽位被無限占用。這些限制與 50KB 輸出上限一起構(gòu)成了 Runbook 執(zhí)行的安全邊界腳本再失控也只能拖住自己所在的步驟而無法阻塞平臺或數(shù)據(jù)庫。九、實戰(zhàn)小結(jié)一條可落地的執(zhí)行工作流綜合以上機(jī)制一個生產(chǎn)可用的 Runbook 執(zhí)行流程可以這樣設(shè)計規(guī)則兜底在事件/告警/計劃維護(hù)的Rules → Runbook Rules中配置標(biāo)題正則讓匹配實體自動啟動 Runbook參考 規(guī)則文檔 中的 DB 故障切換示例。手動補(bǔ)充值班人員需要臨場排查時從實體流點擊Run Runbook手動掛接一次執(zhí)行。交織執(zhí)行腳本步驟捕獲狀態(tài) → 手動步驟等人工確認(rèn) → HTTP 步驟調(diào)用外部系統(tǒng) → 手動步驟再確認(rèn) → 腳本步驟收尾發(fā)通知全程一條時間線。異常處理誤觸發(fā)時點擊Cancel Execution腳本可能被重試時保持步驟冪等Worker 重啟或 Agent 租約過期可能導(dǎo)致自動化步驟重復(fù)執(zhí)行。事后審計在 Runbook 的Executions標(biāo)簽頁按狀態(tài)/日期/來源實體篩選結(jié)合每次執(zhí)行快照與步驟輸出含 S3 URL撰寫復(fù)盤報告。至此你已完整掌握 OneUptime Runbook 的「運(yùn)行」這一環(huán)節(jié)——從三種觸發(fā)路徑到執(zhí)行視圖從取消/重跑到快照審計再到背后的數(shù)據(jù)模型與隊列機(jī)制。下一步可深入閱讀 Runbook 編寫Authoring、Runbook 規(guī)則Rules 與 Runbook Agent 安裝構(gòu)建完整的自動化響應(yīng)體系。【免費下載鏈接】oneuptimeComplete open-source monitoring and observability platform.項目地址: https://gitcode.com/GitHub_Trending/on/oneuptime創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 OneUptime Runbook 執(zhí)行完全指南：三種觸發(fā)方式、執(zhí)行視圖與審計追溯
OneUptime Runbook 執(zhí)行完全指南三種觸發(fā)方式、執(zhí)行視圖與審計追溯【免費下載鏈接】oneuptimeComplete open-source monitoring and observability platform.項目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文基于 OneUptime 開源倉庫中的 Runbook 運(yùn)行文檔英文原版 / 法文版撰寫。Runbook運(yùn)行手冊是 OneUptime 平臺中可復(fù)用的響應(yīng)流程——由有序的「手動步驟 自動化步驟」組成可掛接到事件Incident、告警Alert或計劃維護(hù)Scheduled Maintenance上。閱讀本文后你將掌握 Runbook 執(zhí)行的三種觸發(fā)路徑、執(zhí)行視圖的界面要素、手動與自動化步驟的交織運(yùn)行機(jī)制、取消與重跑的正確姿勢以及如何利用快照語義與 50KB 輸出上限構(gòu)建可審計、可追溯的應(yīng)急響應(yīng)流程。一、Runbook 執(zhí)行的三種觸發(fā)路徑在 OneUptime 中一條 Runbook 執(zhí)行Execution只會通過以下三種方式被創(chuàng)建通過規(guī)則自動觸發(fā)——在事件、告警或計劃維護(hù)的Rules → Runbook Rules菜單中配置規(guī)則當(dāng)實體的標(biāo)題或描述匹配正則時自動啟動 Runbook。詳細(xì)規(guī)則語義見 Runbook 規(guī)則文檔。從 Runbook 頁面手動觸發(fā)——在某個 Runbook 的概覽頁點擊Run Now立即運(yùn)行。這種執(zhí)行不掛接到任何事件、告警或計劃維護(hù)屬于臨時性ad-hoc運(yùn)行。從實體流Entity Feed手動觸發(fā)——在某個事件、告警或計劃維護(hù)上點擊Run Runbook運(yùn)行 Runbook。這種執(zhí)行會**掛接attached**到該實體并出現(xiàn)在該實體的頁面中。從源碼結(jié)構(gòu)看第三種路徑體現(xiàn)得尤為直接RunbookExecution數(shù)據(jù)模型為每次執(zhí)行預(yù)留了incidentId、alertId、scheduledMaintenanceId三個可空外鍵以及記錄觸發(fā)人的triggeredByUserId字段見 RunbookExecution.ts。執(zhí)行創(chuàng)建時這些外鍵被寫入執(zhí)行便天然地關(guān)聯(lián)到來源實體。提示規(guī)則觸發(fā)的執(zhí)行同樣會寫入來源實體外鍵——規(guī)則文檔中明確說明規(guī)則觸發(fā)后「執(zhí)行被鏈接到來源實體它會出現(xiàn)在事件/告警/計劃維護(hù)的頁面以及 Runbook 的 Executions 列表中」。二、執(zhí)行視圖一次運(yùn)行的完整檢查清單打開任意一條執(zhí)行你會看到一個檢查清單ChecklistUI。每個步驟顯示以下要素狀態(tài)徽標(biāo)Status Pill——Pending待處理、Running運(yùn)行中、Waiting for you等待你操作、Done已完成、Skipped已跳過、Failed失敗。標(biāo)題與描述——在執(zhí)行時從 Runbook 復(fù)制而來快照語義見下文第六節(jié)。輸出Output可折疊——stdout、返回值、HTTP 響應(yīng)等。錯誤信息——僅當(dāng)步驟失敗時顯示。對于處于WaitingForUser狀態(tài)的手動步驟會顯示Mark Complete標(biāo)記為已完成和Skip跳過兩個按鈕。一個值得注意的細(xì)節(jié)只要執(zhí)行尚未進(jìn)入終態(tài)頁面每 3 秒輪詢刷新一次因此你可以近乎實時地看到自動化步驟完成。這在人工值守大屏或共享排查頁面上非常有用——響應(yīng)者無需手動刷新即可持續(xù)跟蹤進(jìn)度。從源碼可以印證這些狀態(tài)的定義步驟級狀態(tài)枚舉RunbookStepExecutionStatus包含Pending、Running、WaitingForUser、Completed、Skipped、Failed、Cancelled七種見 RunbookStepExecutionStatus.ts而執(zhí)行級狀態(tài)RunbookExecutionStatus則包含Scheduled、Running、WaitingForManualStep、Completed、Failed、Cancelled六種見 RunbookExecutionStatus.ts?？梢钥吹健竁aiting for you」對應(yīng)步驟的WaitingForUser而執(zhí)行整體會停駐在WaitingForManualStep。三、手動與自動化步驟的交織一次執(zhí)行、一條時間線Runbook 的核心能力在于把「人類判斷」和「機(jī)器執(zhí)行」編排進(jìn)同一條時間線。文檔給出的經(jīng)典故障切換流程如下腳本步驟Script捕獲系統(tǒng)當(dāng)前狀態(tài)寫入 S3。手動步驟Manual「通過狀態(tài)頁橫幅通知客戶」。由值班響應(yīng)者確認(rèn)勾選。HTTP 步驟HTTP通過 PagerDuty 呼叫 DBA。手動步驟Manual「確認(rèn)從庫已切換為主庫」。由值班響應(yīng)者確認(rèn)勾選。腳本步驟Script向 Slack 發(fā)送「一切已恢復(fù)」消息。其中步驟 2 和步驟 4 會暫停執(zhí)行直到有人勾選確認(rèn)步驟 1、3、5 自動運(yùn)行。整條流程是一次執(zhí)行、一條時間線、一個真相源one source of truth——每個步驟的狀態(tài)、輸出、錯誤與耗時都被永久記錄在該執(zhí)行上事后復(fù)盤無需再靠記憶拼湊。源碼層面RunbookExecution模型中的stepExecutions字段是一個 JSON 數(shù)組每條記錄「鏡像 Runbook 中的一個步驟并攜帶其狀態(tài)、輸出與時間戳」見 RunbookExecution.ts 相關(guān)的模型注釋RunbookExecution.ts。手動步驟被勾選后執(zhí)行會從下一個步驟繼續(xù)——這正是「暫停-恢復(fù)」機(jī)制的落點。四、取消一次執(zhí)行在執(zhí)行的頁面點擊Cancel Execution取消執(zhí)行即可終止運(yùn)行。取消的語義很明確當(dāng)前步驟如果有會正常結(jié)束不會被強(qiáng)行中斷后續(xù)步驟不再啟動執(zhí)行狀態(tài)變?yōu)镃ancelled。對應(yīng)的執(zhí)行級狀態(tài)Cancelled已包含在RunbookExecutionStatus枚舉中見 RunbookExecutionStatus.ts。對于掛接在事件/告警/計劃維護(hù)上的執(zhí)行取消操作同樣適用——例如誤觸發(fā)或場景已變化時值班人員可以干凈地收尾而不是放任流程繼續(xù)執(zhí)行。五、輸出保留與 50KB 上限為防止失控腳本撐爆數(shù)據(jù)庫每個步驟的輸出被限制為 50KB。超出部分會被截斷并在截斷處打上標(biāo)記見 配置與安全文檔。如果你需要更大的產(chǎn)物artifacts正確的做法是在腳本中將大文件寫入S3 或日志系統(tǒng)然后把URL 存儲在返回值return value中。這樣既保證了執(zhí)行記錄足夠輕量又不丟失可審計的原始數(shù)據(jù)——復(fù)盤時只需點擊步驟輸出里的 URL 即可拉取完整產(chǎn)物。配置文檔中的運(yùn)維建議也呼應(yīng)了這一點「捕獲 URL而不是數(shù)據(jù)塊Capture URLs, not blobs」——一旦步驟產(chǎn)生超過幾 KB 的輸出就寫入 S3 或日志棧并返回 URL。六、重新運(yùn)行 Runbook不可變的快照語義一條 Runbook 執(zhí)行是一次性、不可變的記錄one-shot, immutable record。要重新運(yùn)行請再次點擊Run Now——這不會覆蓋原執(zhí)行而是創(chuàng)建一條全新執(zhí)行攜帶 Runbook 當(dāng)前步驟的新鮮快照snapshot原始執(zhí)行保持原樣用于審計追蹤。這種快照語義貫穿整個 Runbook 設(shè)計步驟的「標(biāo)題與描述」在執(zhí)行時被復(fù)制到執(zhí)行記錄上見第二節(jié)模型中的runbookNameSnapshot字段專門保存「執(zhí)行創(chuàng)建時的 Runbook 名稱」「即使 Runbook 之后被重命名或刪除也會保留」見 RunbookExecution.ts運(yùn)行時編輯 Runbook 模板永遠(yuǎn)不會篡改在途in-flight的執(zhí)行——執(zhí)行繼續(xù)使用自己的快照。這對事后審計意義重大每次故障處理的記錄是「當(dāng)時真實發(fā)生過的步驟與配置」而不是「后來被修改過的模板」。規(guī)則文檔也強(qiáng)調(diào)執(zhí)行是「步驟被快照到新執(zhí)行上」且「編輯事件標(biāo)題不會重新觸發(fā)規(guī)則」。七、檢索歷史執(zhí)行Executions 標(biāo)簽頁每個 Runbook 都有一個Executions執(zhí)行記錄標(biāo)簽頁列出該 Runbook 的全部運(yùn)行記錄支持按以下維度過濾狀態(tài)status——Scheduled/Running/WaitingForManualStep/Completed/Failed/Cancelled等日期范圍date range來源實體source entity——事件、告警或計劃維護(hù)。反過來從某個事件、告警或計劃維護(hù)的頁面進(jìn)入Runbooks 標(biāo)簽頁會展示掛接在該實體上的所有執(zhí)行。規(guī)則觸發(fā)的運(yùn)行也可以在Runbooks → Executions下按狀態(tài)、Runbook 或日期過濾查看見 規(guī)則文檔。結(jié)合數(shù)據(jù)模型可以更清晰地理解檢索能力RunbookExecution對runbookId、incidentId、alertId、scheduledMaintenanceId都建立了數(shù)據(jù)庫索引Index()注解這正是 Executions 列表按 Runbook 或按來源實體快速過濾的底層支撐見 RunbookExecution.ts 等處的索引聲明。八、源碼視角執(zhí)行背后的數(shù)據(jù)模型與隊列8.1 RunbookExecution 表結(jié)構(gòu)核心數(shù)據(jù)表RunbookExecution的關(guān)鍵字段見 RunbookExecution.ts字段類型說明projectId/runbookIdObjectID所屬項目與所屬 Runbook必填runbookNameSnapshotShortText執(zhí)行時的 Runbook 名稱快照statusShortText執(zhí)行級狀態(tài)RunbookExecutionStatusstepExecutionsJSON步驟級執(zhí)行狀態(tài)數(shù)組狀態(tài)、輸出、時間戳incidentId/alertId/scheduledMaintenanceIdObjectID可空來源實體外鍵triggeredByUserIdObjectID可空手動觸發(fā)的用戶startedAt/completedAtDate起止時間failureReasonLongText可空失敗原因權(quán)限方面該模型的表級訪問控制將「創(chuàng)建執(zhí)行」授予ProjectOwner、ProjectAdmin、CreateRunbookExecution、ProjectMember、RunbookAdmin、RunbookMember「讀取執(zhí)行」額外允許Viewer與RunbookViewer見 RunbookExecution.ts。這與 配置與安全文檔 中Runbook權(quán)限組的說明一致RunbookAdmin聚合了全部細(xì)粒度權(quán)限。8.2 隊列與執(zhí)行引擎Runbook 執(zhí)行運(yùn)行在RunbookBullMQ 隊列上Worker 并發(fā)數(shù)為25可在部署中調(diào)整以應(yīng)對大量并發(fā)運(yùn)行。手動步驟被勾選后執(zhí)行會重新入隊從下一步繼續(xù)——讓 Worker 保持熱狀態(tài)避免整條鏈路等待。JavaScript 與 Bash 步驟永遠(yuǎn)不會在 OneUptime Worker 上執(zhí)行而是派發(fā)為RunnerJob含targetAgentId、腳本、狀態(tài)機(jī)Pending → Claimed → Running → Succeeded/Failed/TimedOut/Cancelled、租約、輸出與退出碼由你在自建基礎(chǔ)設(shè)施中安裝的 Runbook Agent 領(lǐng)取執(zhí)行詳見 配置與安全文檔 與 Agent 文檔。這意味著即使執(zhí)行視圖上的腳本步驟「瞬間完成」其實際計算發(fā)生在你的主機(jī)上Worker 只負(fù)責(zé)編排與匯總。8.3 超時與失敗兜底執(zhí)行相關(guān)的超時配置見 Authoring 文檔執(zhí)行超時Execution timeoutJavaScript、Bash、HTTP 步驟默認(rèn)30 秒可在步驟上逐條覆蓋領(lǐng)取超時Claim timeoutBash/JavaScript 步驟默認(rèn)2 分鐘——Worker 等待所選 Agent 領(lǐng)取任務(wù)的時長超時則步驟失敗兩者的可設(shè)范圍均為1 秒到 1 小時超出范圍的值會在步驟運(yùn)行時被鉗制既不會禁用超時也不會讓 Worker 槽位被無限占用。這些限制與 50KB 輸出上限一起構(gòu)成了 Runbook 執(zhí)行的安全邊界腳本再失控也只能拖住自己所在的步驟而無法阻塞平臺或數(shù)據(jù)庫。九、實戰(zhàn)小結(jié)一條可落地的執(zhí)行工作流綜合以上機(jī)制一個生產(chǎn)可用的 Runbook 執(zhí)行流程可以這樣設(shè)計規(guī)則兜底在事件/告警/計劃維護(hù)的Rules → Runbook Rules中配置標(biāo)題正則讓匹配實體自動啟動 Runbook參考 規(guī)則文檔 中的 DB 故障切換示例。手動補(bǔ)充值班人員需要臨場排查時從實體流點擊Run Runbook手動掛接一次執(zhí)行。交織執(zhí)行腳本步驟捕獲狀態(tài) → 手動步驟等人工確認(rèn) → HTTP 步驟調(diào)用外部系統(tǒng) → 手動步驟再確認(rèn) → 腳本步驟收尾發(fā)通知全程一條時間線。異常處理誤觸發(fā)時點擊Cancel Execution腳本可能被重試時保持步驟冪等Worker 重啟或 Agent 租約過期可能導(dǎo)致自動化步驟重復(fù)執(zhí)行。事后審計在 Runbook 的Executions標(biāo)簽頁按狀態(tài)/日期/來源實體篩選結(jié)合每次執(zhí)行快照與步驟輸出含 S3 URL撰寫復(fù)盤報告。至此你已完整掌握 OneUptime Runbook 的「運(yùn)行」這一環(huán)節(jié)——從三種觸發(fā)路徑到執(zhí)行視圖從取消/重跑到快照審計再到背后的數(shù)據(jù)模型與隊列機(jī)制。下一步可深入閱讀 Runbook 編寫Authoring、Runbook 規(guī)則Rules 與 Runbook Agent 安裝構(gòu)建完整的自動化響應(yīng)體系。【免費下載鏈接】oneuptimeComplete open-source monitoring and observability platform.項目地址: https://gitcode.com/GitHub_Trending/on/oneuptime創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考