AI 協助開發者生成程式、測試與設定檔後，團隊可以在短時間內完成更多變更。
同一個服務一天內可能經過多次合併與部署，功能開關、模型版本、環境設定與外部依賴也可能一起被調整。正式環境發生異常時，開發者需要檢查的變更範圍會隨之擴大。
過去一週部署一次時，團隊還能從少數幾筆提交紀錄尋找原因。部署頻率提高後，異常可能來自程式邏輯、資料格式、設定值、基礎設施或相依服務版本。
若每次變更缺少清楚的版本、發布批次與執行環境標記，團隊就很難判斷哪一項改動和問題發生時間有關。
AI 也會讓變更看起來完整。一次生成可能同時修改多個檔案、補上測試、調整錯誤處理，甚至更新部署設定。這類變更通過測試後，仍可能在特定資料、流量或服務組合下出現異常。
診斷工作需要把程式版本、設定變動、請求路徑與執行結果連在一起，才能重建當時發生的情況。
團隊需要讓每次發布都留下可辨識的線索，例如提交版本、部署時間、功能開關狀態與變更負責範圍。事故發生時，開發者才能先排除無關改動，把注意力放在和問題時間相近的變更上。
分散式系統中的一個使用者操作，會經過 API 閘道（API Gateway）、應用服務、資料庫、訊息佇列與第三方服務。
任何一個節點發生延遲、逾時或資料錯誤，都可能讓使用者看到相同的失敗畫面。只查看單一服務的錯誤訊息，很難還原完整原因。
例如，訂單服務顯示付款失敗，問題來源可能是付款服務回應太慢，也可能是訊息重複傳送、庫存鎖定逾時，或身分驗證資訊在服務間傳遞時遺失。每個服務單獨檢查時都仍在運作，整個流程串起來後，交易卻已經無法完成。
AI 能快速產生新的服務介面、背景工作與整合程式，也會讓服務之間的互動關係更快改變。
某個欄位名稱、重試規則或逾時設定被調整後，影響可能沿著呼叫鏈傳到其他團隊負責的服務。若各服務只保留自己的局部紀錄，開發者就需要人工比對時間、請求內容與錯誤訊息，好確認哪段資料才是相關的，事故處理時間也會被拉長。
跨服務追蹤需要共用的請求識別資訊，例如追蹤識別碼（Trace ID）與關聯識別碼（Correlation ID）。當這些資訊能穿過 API、訊息與背景工作，團隊才有機會把分散的紀錄串成同一條執行路徑，確認故障從哪裡開始，以及影響傳到了哪些服務。
AI 生成的程式會先聚焦在功能是否完成，例如資料能否寫入、API 能否回傳預期結果、測試能否通過。
正式環境需要的診斷資訊若沒有寫進提示詞（Prompt）、架構規範或完成條件，生成結果很可能只留下基本錯誤訊息，缺少後續調查需要的背景。
一段程式捕捉例外後，如果只在日誌裡寫下「處理失敗」的記錄，事故發生時，開發者仍不知道失敗的是哪一筆請求、哪個處理步驟、使用了哪個設定版本，也無法確認外部服務回傳了什麼狀態。日誌數量很多，不代表資訊足以支援診斷。
另一項風險是 AI 可能生成過量紀錄，把完整請求、個人資料或驗證資訊直接寫入日誌。這會增加儲存與查詢成本，也可能引入安全與隱私問題。
可觀測性需要明確定義應記錄哪些事件、使用哪些欄位、哪些資料需要遮蔽，以及錯誤層級如何分類。
測試能確認系統在預先設定的條件下是否符合預期，可觀測性（Observability）則協助團隊了解系統進入正式環境後的實際行為。
使用者操作方式、資料內容、網路延遲、流量變化與外部服務狀態，都會形成測試環境難以完整重現的組合。
團隊若只從「服務是否正常運作」判斷系統狀態，只能看到最後結果。例如 API 回應失敗、交易沒有完成，或頁面載入時間變長。這些訊息能說明異常已經發生，卻不足以解釋請求經過哪些服務、停留在哪個步驟，以及當時使用了哪些設定。
可觀測性會透過日誌（Logging）、指標（Metrics）與追蹤（Tracing）資料，留下系統執行時的線索。開發者可以觀察某個版本上線後的錯誤率、延遲與資源使用情況，也能沿著單一請求追查跨服務流程。系統狀態因此能從模糊感受，轉成可查詢、可比對的執行證據。
這些資料也能協助不同角色對齊現況。開發者可以確認程式行為，維運人員能掌握資源與服務狀態，產品角色則能了解異常影響哪些使用者流程。討論有同一批執行紀錄可查，就能減少只靠印象判斷的落差。
自動化測試使用的是團隊事先設計的案例，驗證範圍會受到當時理解、測試資料與環境條件限制。正式環境中的資料組合、操作順序與流量型態更加多樣，有些問題會在功能被大量使用後才出現。
例如單元測試已經涵蓋折扣計算規則，正式環境仍可能遇到舊會員資料缺少欄位、兩個促銷活動同時生效，或外部優惠服務回應過慢。
每個測試單獨執行時都能通過，整體流程在特定條件下仍可能出現錯誤或延遲。
可觀測資料可以讓團隊看見這些未被測試涵蓋的情況。錯誤率集中在哪個資料版本、延遲發生在哪個服務、哪些使用者操作經常失敗，都能成為補強測試的依據。
團隊可以將正式環境出現的失敗模式整理成新的測試案例，調整測試資料，或增加整合與端對端測試。
AI 協助產生測試時，也需要真實資料作為輸入。只依照程式結構生成測試，容易重複驗證開發者已經知道的路徑。將事故紀錄、異常資料特徵與高延遲流程提供給 AI，才能產生較貼近系統風險的測試草稿，讓測試內容跟著系統使用狀況調整。
系統發生故障時，團隊需要先重建事件經過。哪個版本正在執行、請求從哪裡進入、經過哪些服務、使用哪些資料，以及在哪個步驟開始偏離預期，都是診斷過程中的重要資訊。
缺少其中幾段線索，開發者就需要透過猜測與重複操作縮小範圍。
可追蹤線索需要能把分散資訊連接起來。日誌中的追蹤識別碼可以串起同一個請求，部署標記（Deployment Tags）可以對應程式版本，時間戳記能排列事件順序，結構化欄位則能讓團隊依照服務、錯誤類型與使用者流程查詢。這些設計會直接影響事故處理效率。
診斷資料也需要保留足夠背景，並控制資訊範圍。錯誤紀錄可以包含處理階段、結果狀態、相依服務與重試次數，敏感資料則應遮蔽或使用識別碼代替。
紀錄內容缺少背景時，開發者看不到原因。紀錄內容過多時，搜尋成本、儲存費用與安全風險都會提高。
當線索具備一致格式與明確關聯，團隊可以較快確認問題來源及影響範圍，也能判斷應該回退版本、關閉功能開關，或修正特定服務。
日誌用來記錄系統執行過程中的事件細節，例如收到哪一筆請求、執行到哪個步驟、呼叫了哪個外部服務，以及失敗時出現什麼錯誤。
當開發者需要理解某一次操作為什麼沒有完成，日誌會是最直接的調查來源。
有用的日誌需要保留足夠的執行背景。單純記錄「付款失敗」只能說明結果，若能加上訂單識別碼、處理階段、付款管道、回應狀態與追蹤識別碼，開發者就能縮小問題範圍。
日誌內容也要避免直接寫入密碼、存取權杖（Access Token）、信用卡號與個人資料，敏感欄位需要遮蔽，或改用可查詢的識別碼。
結構化日誌（Structured Logging）會將資訊拆成固定欄位，例如服務名稱、版本、事件類型與錯誤代碼。這種格式方便系統集中搜尋與分類，也有助於 AI 協助整理事故時間線、歸納相似錯誤，並找出異常模式。
日誌適合回答「這一次發生了什麼」。團隊若只依賴大量文字日誌，事故發生後會面對龐大的搜尋範圍。因此，日誌還需要搭配指標掌握整體變化，再用追蹤資料連接跨服務流程。
指標會將系統狀態整理成可計算的數值，例如每秒請求數、錯誤率、回應時間、CPU 使用率、訊息佇列長度與交易成功率。這些資料能協助團隊觀察系統在一段時間內的變化，及早發現服務是否偏離平常狀態。
單一錯誤日誌代表某次失敗，錯誤率從百分之一上升到百分之十，則表示問題已經影響大量請求。
團隊可以透過儀表板查看版本發布前後的差異，也能依服務、區域、功能或客戶類型拆分數據，確認異常集中在哪個範圍。
指標也常被用來設定告警（Alert），例如五分鐘內錯誤率超過門檻、關鍵 API 延遲高於服務目標，或背景任務積壓超過可接受數量。告警條件需要對應使用者影響與處理方式。若資源數值稍有波動就通知，值班人員會被大量低價值訊息干擾。
當問題與 CPU、記憶體配置或程式執行效率有關時，團隊還可以加入持續效能剖析（Continuous Profiling）。它會長時間收集正式環境中的函式執行時間、CPU 使用、記憶體配置與呼叫堆疊，讓開發者看見資源實際消耗在哪些程式路徑。
某個版本上線後 CPU 使用率升高時，指標能指出異常發生的時間，持續效能剖析則能協助找出哪個方法或呼叫路徑消耗了較多資源。
這類資料在頻繁變更的環境中特別有價值。AI 產生或重構程式後，功能測試可能全部通過，正式流量下仍可能出現額外配置物件、重複計算或效率不佳的呼叫路徑。
保留效能剖析資料，才可以比較版本前後的資源使用差異，也能將效能退化對應到實際程式碼變動。
指標適合回答「系統目前發生多大變化」與「問題影響多廣」，持續效能剖析則補充程式執行層級的資源消耗資訊。當團隊找到異常時間與服務後，接下來還需要找到具體請求，這時可以透過範例標記（Exemplars）連接指標與追蹤。
範例標記可以在指標資料點旁保留一筆具有代表性的追蹤識別資訊。例如延遲指標突然升高時，開發者可以從圖表上的異常資料點直接找到對應的追蹤識別碼，再查看那筆高延遲請求實際經過哪些服務。調查可以從指標圖表進入單筆請求，省下用時間區間反覆搜尋追蹤資料的工夫。
分散式追蹤（Distributed Tracing）用來記錄一筆請求經過多個服務的完整路徑。
當使用者送出訂單後，流程可能依序經過訂單、庫存、付款與通知服務。追蹤資料會保留每個步驟的開始時間、結束時間、呼叫關係與執行結果。
一條追蹤由多個跨度（Span）組成，每個跨度代表一次服務呼叫或處理階段。開發者可以從中看出時間花在哪裡、哪個服務回傳錯誤、是否發生重試，以及延遲如何沿著呼叫鏈傳遞。這對微服務、事件驅動架構與背景工作特別重要。
追蹤需要讓追蹤識別碼穿過 API、訊息佇列與非同步任務。若識別資訊在某個服務中斷，後續執行紀錄就無法接回原始請求。
團隊也要控制取樣比例，保留錯誤與高延遲請求，避免收集所有追蹤資料造成過高成本。
範例標記在追蹤調查中會成為入口。當 95% 請求的回應時間突然升高，開發者可以從異常資料點開啟對應的分散式追蹤，確認延遲集中在哪個跨度，再查看相關日誌。若問題最後指向某段程式執行時間異常，也能接著查看持續效能剖析的呼叫堆疊與資源使用資料。
日誌提供事件內容，指標呈現整體變化，追蹤連接執行路徑，持續效能剖析補充程式執行效率，範例標記則讓圖表上的異常點連到具體請求。
當服務名稱、版本、追蹤識別碼及其他關聯欄位使用一致規則，開發者就能從告警追到程式執行位置。
OpenTelemetry（OTel）可以作為這些可觀測資料的共同收集與標準化基礎。它是一套開源且與廠商無關的可觀測性框架，用來產生、收集與匯出日誌、指標、追蹤等遙測資料，也透過語意慣例（Semantic Conventions）統一服務名稱、屬性與事件欄位。
團隊採用 OpenTelemetry 後，可以讓不同服務使用一致的資料格式，再將資料送往既有的監控與分析平台。各團隊不需要各自發明欄位與串接方式，後續要整合日誌、指標、追蹤、範例標記與效能剖析資料時，也不會因為格式差異造成整合困難。
當系統發生異常時，團隊可以把前面的可觀測資料串成一條固定的排查路徑。
告警先通知某項服務指標超出預期範圍，工程師接著查看指標，確認錯誤率、延遲或資源使用量從什麼時間開始偏移，以及影響範圍有多大。
若指標資料帶有範例標記，就能從異常資料點直接找到代表性的追蹤識別碼。接著透過分散式追蹤查看請求經過哪些服務與跨度，確認錯誤或延遲集中在哪個節點。
找到受影響服務後，再查看日誌中的錯誤內容、輸入狀態與執行背景。若問題與 CPU、記憶體或函式執行時間有關，也可以搭配持續效能剖析找出消耗資源的程式路徑。
最後，團隊再利用部署標記確認異常開始前後部署了哪個版本，並比對對應的提交（Commit）、拉取請求（Pull Request, PR）與程式碼差異。
整個排查流程可以依序理解為：告警先指出需要處理的異常，指標接著確認影響範圍，範例標記協助找到代表性請求，追蹤用來定位受影響節點，日誌與持續效能剖析負責還原問題細節，部署標記則用來對照部署版本與程式碼變更。
這樣的排查方式能讓開發者從系統層級的異常，逐步縮小到單筆請求、特定服務與程式執行位置，再回頭確認是哪一次部署或程式碼修改造成的行為改變。
監控系統發出告警後，值班人員需要快速判斷問題影響、可能來源與下一步處理方式。若告警內容只有「CPU 過高」或「服務異常」，開發者還需要重新查詢服務版本、錯誤率、部署時間與請求路徑，處理時間會被拉長。
可行動的告警需要帶出足夠背景，例如受影響服務、異常開始時間、目前版本、錯誤比例、關鍵指標變化與相關儀表板。若團隊已有處理手冊（Runbook），告警也可以直接連到對應步驟，協助值班人員先完成確認、降級、回退或功能關閉。
告警條件也要依照使用者影響設定。資源短暫波動未必需要立即通知，交易成功率下降、請求大量逾時或訊息堆積，才更接近需要處理的服務問題。告警數量過多時，值班人員容易忽略重要訊號，時間一久便會形成告警疲勞。
團隊可以定期回顧哪些告警曾經促成有效處理，哪些訊息經常被忽略，以及哪些事故完全沒有觸發提醒。這些結果應回到監控規則、服務目標與處理手冊中，讓告警內容跟著系統風險調整。
正式環境中的錯誤、延遲與使用行為，能補充開發與測試階段看不到的資訊。若監控資料只在事故當下被查看，問題處理完成後就不再使用，團隊會失去改善系統的重要來源。
團隊可以將重複出現的錯誤模式轉成待辦工作。例如某個 API 經常因舊資料格式失敗，就需要補上相容處理、資料修正或測試案例。某段跨服務流程經常逾時，則可以安排查詢效能、重試策略與服務邊界的改善。
監控資料也能協助產品與工程角色判斷改善順序。錯誤發生頻率、受影響使用者數量、恢復時間與人工處理成本，都能作為排序依據。排序討論有具體數字可對照，先做哪一項會比較清楚。
事故檢討、迭代回顧與架構討論，都可以固定帶入正式環境資料。團隊需要關注哪些問題再次發生、哪些風險正在擴大，以及哪些改善已經產生效果，監控結果就能進入產品待辦清單、技術債清單與架構決策紀錄。
功能完成時，團隊會確認程式、測試與部署是否符合要求。可觀測性若留到上線前才補，常會出現日誌欄位不一致、重要指標缺漏、追蹤資訊中斷，以及告警無法對應實際風險等問題。
團隊可以在完成定義（Definition of Done）中加入觀測要求。重要流程需要具備結構化日誌、關鍵業務與技術指標、跨服務追蹤資訊，以及基本儀表板與告警。高風險功能還需要確認敏感資料遮蔽、錯誤分類與回退判斷所需資訊。
程式碼審查（Code Review）可以檢查這些內容。審查者除了確認功能行為，還要確認故障發生時能否找到足夠線索。AI 協助生成程式時，相關要求也應放入提示詞（Prompt）與專案規則上下文，降低每位開發者自行補充造成的落差。
例如使用以下的提示詞：
生成這段 API 程式碼時，請確保：
1. 採用 JSON 結構化日誌
2. 必須從 HTTP Header 擷取 `x-trace-id` 並帶入外部呼叫
3. 例外處理需記錄 error_code 與 resource_id，但嚴禁記錄任何個人識別或敏感資訊。
持續整合與持續交付（Continuous Integration and Continuous Delivery, CI/CD）流程也可以加入靜態應用程式安全測試（Static Application Security Testing, SAST）與個人識別資訊（Personally Identifiable Information, PII）敏感資料掃描，檢查程式碼與設定是否可能把密碼、權杖、個資或其他敏感欄位寫入日誌。
這類自動化檢查能在合併與部署前先攔下明顯風險，讓 AI 生成的觀測程式碼同時符合診斷、安全與隱私要求。
部署後的驗證同樣重要。團隊在發布後應持續觀察關鍵指標、錯誤率與追蹤資料，確認新版本是否符合預期。若觀測資料不足以支援判斷，就代表這次變更仍缺少必要的運行證據，後續需要補回開發流程。
iThome鐵人賽
看影片追技術