系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

你公司有 Runbook 嗎？

如果你在一家超過 50 人的公司擔任 IT，我問你一個問題：

「你們有 Runbook 嗎？」

大多數人的回答是：「有，但不知道放哪裡。」或是「有，但上次更新是三年前。」

這個現象在英文圈和華文圈都存在，但嚴重程度不一樣。

Runbook 的定義

Runbook，直譯是「執行手冊」，在 IT 與 SRE（Site Reliability Engineering）領域，指的是：

一份記錄特定操作或故障處理流程的結構化文件。

它通常包含：

• 觸發條件（什麼情況下使用這份文件）
• 前置確認（執行前需要知道什麼）
• 步驟清單（按順序執行的具體動作）
• 預期結果（每一步完成後應該看到什麼）
• 升級路徑（如果這份文件解決不了，下一步找誰）

英文圈的 Runbook 文化

在英文圈的 SRE、DevOps 社群，Runbook 是一個非常成熟的概念。

Google、Netflix、Atlassian 都有公開分享過他們的 Runbook 設計哲學。PagerDuty 甚至出了一本《The On-Call Handbook》，裡面大篇幅討論 Runbook 的寫法。

在這些組織裡，每一個 Alert 都對應一份 Runbook：收到告警 → 打開對應 Runbook → 按步驟處理。

這個流程讓一個剛入職兩週的工程師，也能在凌晨兩點獨立處理 Production 問題。

華文 IT 圈的狀況

華文 IT 圈的情況不太一樣。

大多數企業的 IT 知識是存在「人」身上的，而不是「文件」裡。

• 資深工程師知道怎麼處理問題，但沒有時間寫成文件
• 就算有文件，通常是 Word 或 Excel，散落在各處，找不到
• 新人靠「跟著學」，老人靠「憑經驗猜」

這種模式在團隊穩定的時候沒問題。但只要資深工程師離職，知識就跟著走了。

我在東南亞管過的幾個廠，都遇過這種狀況：前任 IT 離職，下一任花了三個月才搞清楚網路架構是怎麼設計的。

為什麼有 Runbook 卻沒人整理？

我問過很多 IT 同行這個問題，得到的答案大致分三類：

1. 沒時間
「每天都在救火，哪有時間寫文件？」這是最常見的答案，也是最真實的。

2. 不知道怎麼寫
Runbook 不是把操作步驟複製貼上，它需要結構化思考：什麼是前提條件？步驟的邊界在哪裡？這需要一定的方法論。

3. 寫了沒人用
「之前寫過，但同事根本不看。」寫 Runbook 的投資報酬率如果不明顯，很難持續投入。

IT Diagnostic Agent 的本質：一個動態 Runbook

這就是為什麼 IT Diagnostic Agent 的核心概念，其實是 Runbook 的數位化與互動化。

傳統 Runbook 的問題：

• 靜態文件，使用者要自己判斷走哪條路
• 假設使用者已經有一定的背景知識
• 更新困難，容易過時

IT Diagnostic Agent 的做法：

• 互動式決策樹：根據使用者的每一個回答，動態決定下一步
• 無前提假設：不需要背景知識，系統引導你問對問題
• AI 補足邊界：決策樹沒覆蓋到的情況，交給 AI 處理

本質上，它是把我二十年的排障經驗，轉換成一個任何人都能操作的互動式 Runbook。

今天的反思

知識管理一直是 IT 部門的隱性成本，卻很少被認真對待。

一個好的 Runbook，不只是救急工具，更是一種知識資產的積累。

IT Diagnostic Agent 試圖降低「整理 Runbook」的門檻，讓排障知識更容易被結構化和共享。

明天預告： 我會展示如何把真實的排障流程拆解成決策樹，以網路故障為例，一步一步建構出可以被程式執行的邏輯。

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣