這一篇的例子是一個短網址服務（需求規格見 0.23 短網址服務的需求定義）：入口 Nginx 把請求轉給後端程式，登入的使用者建立短網址、看點擊統計，訪客點短網址時由服務轉址。

錯誤碼與請求編號

使用者回報錯誤時，工程要從那一句「我剛剛建立短網址失敗」找到兩件事：這是哪一種錯誤，以及是哪一次請求。這兩件事由錯誤畫面上的兩個欄位分別提供。

錯誤碼代表一類錯誤，同一種錯誤每次出現都一樣，例如 LINK_EXPIRED（短網址已過期）、QUOTA_EXCEEDED（本月建立額度用完）。客服拿它去查錯誤碼對照表，就知道這一類錯誤的意思與答覆方式，不必知道是哪一次請求。畫面上的錯誤碼可以直接沿用錯誤回應裡給程式判讀的 code 欄位（見 11.4 錯誤模型設計），客服、工程與程式用同一個字串，對照表不必另外維護一份對應；API 的 code 分得比客服需要的細時，由前端對應成較粗的類別再顯示。不論哪一種，對照表的鍵是畫面上顯示的那個字串，而畫面上只放錯誤的類別，不放服務名稱或內部細節。

請求編號代表單一次請求，每次都不同，例如 9c8561d5272320ba8aafd57145eb9894。它是那一次請求的 Request ID，工程拿它去 log 與 trace 裡找到那一次請求的完整紀錄。畫面上的欄位名稱也寫「請求編號」，與系統內部用同一個名字，客服與工程說的是同一件事。

錯誤碼與請求編號缺一個，查證就少一段。只有錯誤碼，客服知道是額度用完，而使用者說「我明明還有額度」時，工程查不出那一次請求實際讀到的額度是多少；只有請求編號，客服手上是一串看不出意思的字元，每一則回報都要轉給工程才知道是什麼錯誤。Microsoft Entra 的登入錯誤頁同時給兩者：畫面上有 AADSTS 開頭的錯誤碼，展開的疑難排解資訊列出 Request Id、Correlation Id（同一次登入的多個請求共用的編號）與時間戳記，管理員在登入紀錄裡以這些值找到使用者遇到的那一次失敗。系統之間的 API 也是同一個做法：Stripe 在每個回應的 Request-Id header 帶一個 req_ 開頭的編號，並請使用者聯絡客服時附上它。

錯誤畫面上的欄位

錯誤畫面要同時給使用者與客服用，所以畫面上放四個欄位：

• 給使用者看的訊息：發生了什麼、他現在能做什麼，不含內部的服務名稱、資料表或堆疊追蹤（stack trace）。錯誤訊息透露內部結構會成為攻擊者的偵察材料，見 OWASP error handling：錯誤訊息是攻擊者的偵察面；訊息怎麼分成標題、說明與行動，見 錯誤訊息撰寫原則，錯誤碼、請求編號與發生時間這三個欄位，放在那篇說的次要位置（折疊區塊或複製按鈕）。
• 錯誤碼。
• 請求編號，旁邊放一個複製按鈕。
• 發生時間，標明時區。

訊息與錯誤碼對應的是錯誤的類別，可以在程式裡逐一寫好；請求編號與時間是每一次請求才有的值，要由產生錯誤的那一段程式帶到畫面上。

請求編號的長度要和回報的管道一起考慮。網頁與 App 上，使用者按複製再貼進客服表單，32 個字元不成問題；電話客服要使用者唸出來，32 個十六進位字元太長。做法之一是畫面顯示完整的編號、電話上只請使用者唸前 8 碼，工程以前 8 碼加上帳號與時間範圍篩選 log。8 碼十六進位有 16⁸ 種、約 43 億種組合。設工程篩選的那個帳號與時間範圍裡共有 n 次請求，除了使用者要找的那一次，其餘請求之中至少有一次的前 8 碼也相同的機率約為 n ÷ 43 億：一小時一千次請求時約是四百萬分之一，帳號的請求量大時把 n 換成自己的數字重算。

請求編號要是隨機產生的值，不能由帳號編號、遞增序號或時間組成；要讓使用者在電話上只唸前 8 碼時，也不帶固定的前綴。由帳號編號組成的編號讓別人從編號推出帳號；遞增序號讓別人推算服務的請求量，也讓別人猜出其他使用者的編號；以時間開頭的編號前幾碼是時間戳記，UUIDv7（開頭 48 位元是毫秒時間戳記的 UUID）的前 8 碼約每 65 秒才變一次，ULID（開頭是時間戳記、可依時間排序的編號格式）的前 8 碼約每秒變一次，同一段時間內的請求前 8 碼相同；固定前綴（例如 app-）佔掉前幾碼，前 8 碼裡的隨機字元也少了；Stripe 的 req_ 這類前綴不影響複製貼上，只影響唸前幾碼的做法。這幾種情形下，電話上只唸前 8 碼就分不出是哪一次請求。

請求編號的產生與傳遞：Nginx 入口、後端程式、前端與 App

請求編號要在 log 裡查得到，前提是同一個值同時出現在三個地方：回給使用者的錯誤畫面、入口的 access log，以及後端程式處理這個請求時寫的每一行 log。最直接的做法是由請求最先抵達的入口產生請求編號，再把它傳下去。

Nginx 從 1.11.0 起提供 $request_id 變數，每個請求以 16 個隨機位元組產生，寫成 32 個十六進位字元。以下設定讓 Nginx 把它寫進 access log、加在回應的 header 上，並以 X-Request-Id header 傳給後端程式：

 1# 以下兩行寫在 http 區塊（server 之外）
 2log_format withid '$remote_addr [$time_iso8601] "$request" $status rid=$request_id';
 3access_log /var/log/nginx/access.log withid;
 4
 5server {
 6    listen 80;
 7    # 每一個回應（包括錯誤回應）都帶上同一個編號
 8    add_header X-Request-Id $request_id always;
 9
10    location / {
11        # 把編號傳給後端；後端從這個 header 讀出編號寫進自己的 log
12        proxy_set_header X-Request-Id $request_id;
13        # app:8080 換成自己後端程式的位址
14        proxy_pass http://app:8080;
15    }
16}

這段設定要拆開併進既有的設定檔，各行的位置與作用：

• log_format 只能寫在 http 區塊，寫進 server 時 nginx -t 會回報 "log_format" directive is not allowed here。官方映像與多數套件的主設定檔在 http 區塊裡以 include 引入 conf.d/*.conf，所以寫在 conf.d 底下某個檔案的最外層、不包在任何 server 裡的指令，就屬於 http 區塊。名字 withid 與欄位標記 rid= 都是自取的，access_log 那一行以同一個名字引用它；log 檔的路徑換成自己主機上的位置。
• 套件預設的 nginx.conf 在 http 層已經有一行 access_log … main;。這時把那一行的格式名改成 withid，或在原本的 main 格式後面加上 rid=$request_id；另加一行 access_log 的話，每個請求會以兩種格式各寫一次。讀這份 access log 的工具照原本的格式解析，格式一改，結果依工具而不同：GoAccess 回報 Format Errors 並停止，ngxtop 不報錯而讀到 0 筆（見 終端機看 nginx 請求）。既有格式有工具在讀時，採用在 main 格式最後加 rid=$request_id 的做法：GoAccess 的 COMBINED 格式照樣解析得到，ngxtop 與 log 收集器的解析規則要把新欄位加進它們的格式定義。
• add_header 併進既有的 server，proxy_set_header 併進每一個有 proxy_pass 的 location。這兩個指令都只在當層沒有同名指令時才繼承上一層的設定，所以某個 location 自己寫了其他 add_header 或 proxy_set_header 時，要在那個 location 裡再寫一次這一行。
• add_header 後面的 always 讓 Nginx 在 4xx 與 5xx 的回應上也加這個 header。少了它，Nginx 只在 200、201、204、206、301、302、303、304、307、308 這幾種回應加 header，而使用者回報的正好是錯誤回應。

以 Nginx 1.27.5 實測這段設定：一次請求的回應 header、後端收到的 X-Request-Id 與 access log 的 rid= 欄位是同一個值。用戶端自己在請求裡帶了 X-Request-Id 時，Nginx 產生 $request_id 不讀這個 header，仍然產生新的值，後端收到的是 Nginx 產生的那一個；入口因此不必信任外部送進來的編號，與 W3C Trace Context 允許在信任邊界重新開始 trace 是同一個考量（見 錯誤回報的回饋迴路：request-id、trace 與呈現回報分工 的〈定位鉤子：request-id 與 trace 的契約〉）。

Nginx 前面還有 CDN 或雲端負載平衡器時，連不上 Nginx 的錯誤頁由那一層產生，不會有 $request_id。有的那一層會在錯誤頁顯示自己的編號（CDN 服務 Cloudflare 的錯誤頁顯示 Ray ID），這時 Nginx 的 access log 也要記下那一層傳給 Nginx 的編號 header（Cloudflare 是 CF-Ray），兩個編號才接得起來；Cloudflare 的文件說明 Ray ID 不保證每個請求唯一，以它查 log 時另外加上時間範圍，那一層的編號也同樣要確認不是以時間開頭。有的那一層只能回一個靜態頁（AWS 的 CDN 服務 CloudFront 的自訂錯誤頁是存放在某個路徑下的固定物件），放不了每次請求的編號，這時改請使用者回報發生時間，工程以時間範圍查那一層的 log。

後端程式要做兩件事。第一件是從 X-Request-Id header 讀出編號，放進這個請求的 log 欄位，讓這個請求寫的每一行 log 都帶著它；多數 logging 函式庫把「這個請求期間每一行 log 都自動帶上的欄位」稱為 context 或 MDC（Mapped Diagnostic Context），log 欄位怎麼命名、跨服務怎麼保持一致，見 4.1 log schema 與搜尋規劃。第二件是回應錯誤時把它放進錯誤回應的 body，讓前端顯示在畫面上。

錯誤回應採用 RFC 9457（HTTP API 錯誤回應的 Problem Details 格式）時，編號可以放在 instance 成員，它要寫成 URI，RFC 建議帶完整路徑，例如 /requests/9c8561d5272320ba8aafd57145eb9894；也可以放在自訂的欄位。

後端程式不能用自己產生的編號取代入口的編號：錯誤畫面與 access log 上寫的是入口的編號，後端的 log 只寫自己的編號時，拿使用者給的編號就找不到後端那一段紀錄。後端需要自己的編號時，兩個一起寫進 log。請求在後端又呼叫其他服務時，跨服務的關聯改由 trace 承擔，log 同時寫入 trace-id，工程從請求編號找到 log，再從 trace-id 找到整條呼叫鏈。

入口自己產生的錯誤也要帶編號。後端程式停掉時，Nginx 回 502，錯誤頁是 Nginx 產生的，不經過後端；以 error_page 把這些錯誤導到一個以 return 回應的具名 location，錯誤頁就能顯示同一個編號：

 1location / {
 2    proxy_set_header X-Request-Id $request_id;
 3    proxy_pass http://app:8080;
 4    # 後端連不上或逾時時，改由下面的 location 產生錯誤頁
 5    error_page 502 503 504 = @upstream_error;
 6}
 7
 8# @upstream_error 是自取的名字
 9location @upstream_error {
10    default_type text/plain;
11    return 502 "服務暫時無法使用。錯誤碼 UPSTREAM_UNAVAILABLE，請求編號 $request_id\n";
12}

error_page 寫了 = 而沒有接回應碼時，Nginx 回給用戶端的回應碼改用 @upstream_error 回的值；上面的 @upstream_error 寫的是 return 502，所以 502、503、504 三種錯誤送到用戶端時都變成 502。要保留 503 與 504 的區分，就為它們各寫一個具名 location，各自 return 自己的回應碼。錯誤頁要用 HTML 時，把 default_type 改成 text/html，內文換成 HTML。這裡的 UPSTREAM_UNAVAILABLE 也會顯示在使用者畫面上，同樣要在錯誤碼對照表上有一列。實測時把 proxy_pass 指向一個沒有程式在聽的埠，回應是 502，內文的請求編號、header 的 X-Request-Id 與 access log 的 rid= 三者相同。

入口自己產生的錯誤不經過後端，只記在 Nginx 自己的 log 裡：access log 帶請求編號，error log 記下連不上後端的原因而不帶編號。上面的 withid 格式沒有帳號欄位，這一類錯誤只能以時間範圍、請求路徑與來源位址篩選，電話上唸前 8 碼時比對的範圍也因此是那段時間的全部請求。

前端或 App 自己畫錯誤畫面時，請求編號有兩個來源：後端錯誤回應 body 裡的欄位，以及每一個回應都帶的 X-Request-Id header。入口自己回的 502 是 @upstream_error 回的那段純文字，不是後端的錯誤格式，前端從 body 解析不出欄位，這時改讀 header。網頁前端與 API 不同源時，瀏覽器依 CORS（跨來源資源共用）的規則只讓前端程式讀到伺服器明確公開的 header，入口要在 add_header X-Request-Id … always; 那一行所在的區塊再加一行 add_header Access-Control-Expose-Headers X-Request-Id always;；實測 502 回應同時帶著 X-Request-Id 與 Access-Control-Expose-Headers 兩個 header。

行動 App 的錯誤可能根本沒有到達伺服器（沒有網路、DNS 解析失敗、連線逾時），這時沒有入口產生的編號。App 可以在每次送出請求時自己產生一個隨機編號，在畫面上顯示 App 自己的錯誤碼（例如 NETWORK_UNREACHABLE）與這個編號，並把它與錯誤一起寫進 App 自己送出的 log 或當機回報；請求沒有到達伺服器時，伺服器上沒有任何紀錄，工程只能在 App 送出的 log 或當機回報裡查到這個編號。這個編號要放在另一個 header 送出，例如 X-Client-Request-Id，因為入口會以 $request_id 覆寫 X-Request-Id。請求到達了伺服器、只是回應沒有回到 App 時，要讓工程在伺服器的 access log 查得到這個編號，把前面寫在 http 區塊、只記 rid=$request_id 的那一行 log_format withid 換成下面這一行（同名的 log_format 只能定義一次，另加一行同名的，nginx -t 會回報 duplicate "log_format" name）：

1# 取代前面寫在 http 區塊的 log_format withid：在 rid= 之後多記 App 送來的編號；沒有帶這個 header 的請求記成 -
2log_format withid '$remote_addr [$time_iso8601] "$request" $status rid=$request_id crid=$http_x_client_request_id';

$http_x_client_request_id 是 Nginx 讀請求 header 的變數，名字由 $http_ 加上 header 名稱的小寫、連字號換成底線組成。以 Nginx 1.27.5 實測，帶了 X-Client-Request-Id: 7f3a9c0e 的請求在 access log 記成 crid=7f3a9c0e，沒帶的記成 crid=-；Nginx 預設把請求裡的其他 header 原樣轉給後端（header 名稱本身含底線的會被丟棄），後端不必另外設定就收得到它。App 若已經依 4.24 Client-to-Server 端到端觀測串接 送出 traceparent（W3C Trace Context 規定的 trace 傳遞 header），可以不另外產生編號，直接以其中的 trace-id 當作 App 端的編號，用戶端與伺服器端的紀錄由同一個 trace 串起來。拿 trace-id 當編號、又要在電話上唸前 8 碼時，trace-id 的開頭要是隨機產生的：AWS 的分散式追蹤服務 X-Ray 的 trace-id 把請求時間的 Unix 秒數放在開頭 8 個十六進位字元，用這種 trace-id 時，電話上改唸最後 8 碼（隨機產生的那一段）。

錯誤碼對照表

錯誤碼對照表讓客服不經過工程就答覆使用者。每一個會顯示在使用者畫面上的錯誤碼佔一列，欄位如下：

同一個錯誤碼多數時候代表使用者端的狀況，少數時候是程式錯誤：LINK_EXPIRED 出現在一個期限未到的短網址上，代表到期判斷寫錯了。只寫錯誤說明的文件分不出這兩種情形，客服只能每一則都照「已過期」答覆；對照表多了「轉給工程的條件」這一欄，客服才分得出來，使用者端的狀況自己答覆，程式錯誤轉給工程。

錯誤碼與它的使用者訊息一旦出現在使用者畫面上，就是對客服與使用者的承諾：重新命名一個錯誤碼，客服的對照表與知識文章就對不上，使用者手上的舊截圖也查不到。錯誤碼的變更紀律因此與 API 欄位相同，見 11.6 向後相容的變更紀律；命名用可讀的字串而不是連續數字，理由見 11.4 錯誤模型設計 的〈常見設計錯誤〉。

對照表最常見的失效是程式新增了錯誤碼而對照表沒有跟上，客服遇到一個查不到的錯誤碼，只能把整張單轉給工程。一種做法是讓對照表從程式裡的錯誤定義產生：每一個錯誤碼在定義的地方同時寫上客服用的欄位，文件由建置流程從那裡產生，CI（每次提交時自動執行的建置與檢查）在客服欄位空白時讓建置失敗。新增錯誤碼的那一次變更因此必須同時寫好客服的答覆。不從程式產生時，至少把負責的團隊寫在每一列上，並在每週營運會議裡比對客服單出現過的錯誤碼與對照表的列（見 4.29 值班的例行檢查 的〈每週營運會議讀的訊號〉）。

客服收件的欄位

客服收到回報時要收齊的欄位，每一個都對應工程查證的一個步驟：

• 帳號（或使用者自己看得到的使用者編號）：沒有請求編號時，以帳號篩選 log；也用來查這個帳號的資料狀態。
• 發生時間與時區：縮小 log 的查詢範圍。使用者說的「下午三點」沒有時區時，工程可能在差八小時的位置找。
• 錯誤碼：查對照表，客服自己就可能答覆。
• 請求編號：直接找到那一次請求。
• 功能：從固定的清單選一項（短網址服務是轉址、建立短網址、點擊統計、付款與帳號）。每週的計數與排名用它分類，沒有錯誤碼的回報也只能靠它歸類。
• 裝置、作業系統與 App 版本或瀏覽器：判斷是否只發生在某個版本；只發生在低於最低支援版本的 App 上時，處理方式是請使用者更新（見 Minimum Supported Version）。
• 操作步驟與螢幕截圖：重現問題，也從截圖補回使用者沒抄下的錯誤碼與請求編號。

錯誤碼與功能要存成客服單上可以篩選的欄位，客服系統才算得出件數；從截圖補回的錯誤碼，由客服填進欄位。

使用者沒有抄下請求編號時，工程以帳號加上前後幾分鐘的時間範圍查 log，再以錯誤碼與請求的路徑縮小到那一次請求。這條退路成立的前提是 log 有帳號與錯誤碼欄位可以篩選，而帳號屬於個人資料，寫進 log 時要依 PII 的規則處理：寫內部的使用者編號，不寫電子郵件或姓名。

客服查詢工具的權限

客服查詢工具（Internal Admin Tool（客服後台））讓客服以帳號或短碼查到資料的狀態，取代請工程查資料庫。工具的設計重點在客服看得到什麼、以及每一次查詢留下什麼紀錄：

• 只讀：工具只顯示狀態，延長期限、退款、解除停用這類會改資料的動作另外走有核准流程的後台。
• 欄位層級的遮罩：客服看得到短碼的狀態、原始網址、到期日、建立時間與檢舉紀錄，以及帳號的方案、本月剩餘額度與本期的扣款紀錄；電子郵件、姓名這類個人資料不顯示，付款資訊只顯示卡號末四碼。遮罩的做法見 Data Masking。
• 查詢要附還在處理中的單號：客服以帳號查詢時要填這次查詢對應的客服單號，工具只在那張單還在處理中時顯示資料，結案的單號解不開查詢。這讓每一次查詢都有理由與有效期間，與 7.2 身分與授權邊界 的〈代理操作的授權邊界〉要求的發起理由與有效時窗是同一件事。來電者自稱帳號本人時，客服先依 7.41 單一帳號被接管 的做法確認身分，再查那個帳號。
• 每一次查詢都寫進稽核紀錄：誰、什麼時間、以哪一張單、查了哪個帳號（見 Audit Log）。各客服帳號的查詢量寫成一條告警：某個帳號在一小時內的查詢量超過它平常的最高值時，通知資安的負責人，查詢量突然升高的帳號可能已經被盜用。客服帳號被盜用時，攻擊者用的就是這個工具，稽核紀錄是事後查出影響範圍的依據；客服支援系統被入侵而外洩客戶資料的實例見 Okta 支援系統事件。

一線客服不直接查 log。log 裡有其他使用者的資料與內部細節，而且 log 系統的權限多半以整個資料集為單位，給了一線客服就等於給了全部；一線客服需要的狀態，由查詢工具挑出來顯示。技術支援是分層支援裡處理需要讀系統資料的那一層（見 Tiered Support），它要讀 log 時，權限縮到它負責的服務與遮罩過的欄位。權限的整體設計原則見 Least Privilege。

log 保留期：從使用者遇到錯誤到工程查 log 的時間

請求編號在 log 裡查得到的前提，是那一行 log 在工程查詢時還在，而且仍是逐筆的完整紀錄。從使用者遇到錯誤到工程以請求編號查 log，下文稱為錯誤到查證的時間，由幾段相加：使用者隔幾天才回報、客服單在佇列裡等、客服處理後轉給工程、工程排到這張單並開始查。開單在上班時間處理的回報，這段時間常以天甚至週計算。Retention（保留期） 比錯誤到查證的時間短的 log，工程拿著正確的請求編號也查不到，看起來像使用者抄錯了編號。

所以可以逐筆以請求編號查詢的那一層 log（完整粒度、沒有聚合），保留期至少要涵蓋錯誤到查證的時間的上限，再加上餘裕。例如使用者一週後才回報（7 天）、客服兩天內轉單、工程在 8.24 客服回報的處理 舉例的兩個上班日內第一次回覆（這兩段加起來四個上班日，最多跨一個週末，約 6 天）、工程排到這張單實際查 log 再隔兩週（14 天），加起來約二十七天，再加上餘裕，請求層級的 log 保留四十五天；這幾段時間換成自己服務的數字重算。

錯誤到查證的時間給出的是保留期的一個下限。合約與法規可能給出更長的下限：服務水準協議的補償申請有期限（例如 AWS 要求在事件發生後第二個帳單週期結束前申請），證據要留到那時；處理信用卡資料的系統適用 PCI DSS（支付卡產業資料安全標準）4.0.1，要求稽核紀錄保留 12 個月、其中最近 3 個月能立即取用。這兩個下限多半落在聚合的可用性指標與稽核紀錄這兩層，不必延長完整粒度的請求 log。個資法規則可能給出上限。每一層的保留期取它適用的下限中最長的那一個，並且不超過適用的上限；下限長過上限時，個資欄位先遮罩或改存內部編號，再保留到下限。

access log 的保留期另外確認，它不一定在 log 平台上。Debian 與 Ubuntu 套件版 Nginx 附的 logrotate（Linux 上定期輪替與刪除舊 log 的工具）設定每天輪替、保留 14 份；官方 Docker 映像把 access.log 連到標準輸出，保留期由 Docker 收集容器輸出的 log driver 決定，預設的 json-file driver 在刪除重建容器時一起刪掉。入口自己回的 502 只記在 Nginx 的 log 裡，所以 access log 要送進和後端 log 同一個 log 平台，或把輪替份數調到涵蓋錯誤到查證的時間。

保留期越長，儲存成本與個人資料外洩的影響範圍越大，所以常見的做法是分層：請求層級的 log 以完整粒度保留到涵蓋錯誤到查證的時間為止，其中的個人資料欄位遮罩或只存內部編號，更長期的統計改用聚合過的指標。4.7 Cardinality 治理與成本邊界 的保留階梯以最近 7 天的熱層保留完整粒度、7 到 30 天聚合為例，用在請求 log 時要把完整粒度那一層延長到錯誤到查證的時間；營運 log（operational log）的保留期與它的漂移見 4.12 Audit Log 邊界與 PII 治理 的〈Retention 與保留策略漂移〉。

延伸閱讀：客服流程、系統之間的錯誤回報與錯誤分類

• 客服當場答覆時用的資訊、轉給值班的條件、工程查證後給客服的回覆：8.24 客服回報的處理
• API 呼叫方與提供者之間以 request-id 與 trace 回報錯誤、錯誤內容分成給使用者的呈現與給工程的回報：錯誤回報的回饋迴路：request-id、trace 與呈現回報分工
• 錯誤分成可重試與終態、錯誤回應的格式與演化條款：11.4 錯誤模型設計
• API、非同步工作與外部呼叫的錯誤要帶哪些診斷欄位：4.19 Debuggability by Design

這一篇的例子是一個短網址服務（需求規格見 0.23 短網址服務的需求定義）：登入的使用者建立短網址、看點擊統計，付費方案每月扣款並提高建立額度，訪客點短網址時由服務轉址到原本的網址。

分層支援：一則回報停在哪一層

客服組織常把處理回報的人分成幾層，業界叫分層支援（Tiered Support）：一線客服接所有回報，技術支援處理需要讀系統資料的回報，工程處理需要改程式、或讀完整 log 與資料庫的回報。小團隊多半只有兩層，客服直接轉給工程。

一則回報停在哪一層，由那一層手上的資訊與工具決定，不由回報者的身分或語氣決定。客服手上有進行中的事故清單與錯誤碼對照表，「短網址打不開」這類回報多數在一線就有答案；客服手上只有一個轉單按鈕，同一則回報就會一路轉到工程，工程的時間花在查一個客服本來查得到的狀態。客服手上的資訊答不了的回報，才依影響範圍與損害能否補回，決定呼叫值班或開單。呼叫值班（page）指由值班通知系統打電話或推播給排班表上這一班的值班工程師，要他立即處理，半夜也會把人叫醒。有些回報即使客服答得出來也要立即呼叫值班，例如重複扣款，因為損害在等待的時間裡擴大。有技術支援這一層的組織，開單的回報先到技術支援，技術支援讀得到的系統資料比客服查詢工具顯示的欄位多，查不出來才轉給工程。

客服當場答覆時用的資訊

客服當場答覆需要五種資訊：進行中的事故、已知錯誤清單、排定的維護與近期變更、錯誤碼對照表，以及帳號層級的查詢工具。前四種是要有人更新的內容，下面各自寫了由誰更新；查詢工具直接讀線上的資料，要維護的是它顯示哪些欄位。

進行中的事故：一份內部版的狀態頁，列出目前確認中的事故、受影響的功能、開始時間、對客戶的說法與下次更新的時間。它比對外的 Status Page 多一欄「對客戶的說法」，因為客服要逐一回覆，而對外狀態頁寫的是給所有人看的一段公告。這一份由事故中的對外聯絡人（liaison，見 8.2 事故指揮與角色分工；小團隊由值班兼任）更新。PagerDuty 的事故流程把這個角色叫 Customer Liaison，職責是把確認過的狀態送給客戶，並把客服收到的回報彙整給事故指揮，溝通紀律是不說謊也不猜測（見 PagerDuty Customer Liaison）。內部狀態頁上的說法因此只寫確認過的事，不寫還在推測的原因與修復時間。

已知錯誤清單：已經確認、還沒修好、而影響小到不必開事故的問題。每一條寫症狀、log 裡對應的內部錯誤類別、替代做法與追蹤單號（追蹤單上看得到修正的進度）。ITIL 問題管理把這類紀錄稱為 Known Error（已知錯誤），存放它們的地方叫已知錯誤資料庫（KEDB）。一個問題要列進已知錯誤清單還是開事故，在這套流程裡看影響是否會擴大：「某一款舊版瀏覽器開啟統計頁時圖表空白，換瀏覽器可以看」影響固定、有替代做法，列進已知錯誤清單；「所有人的統計頁都空白」開事故。清單由確認問題的工程寫入，由發布修正的人在修正上線時移除；修好的條目沒有移除，客服會繼續用一個已經不需要的替代做法回覆。

排定的維護與近期變更：維護時段與最近上線的變更（例如短網址的有效期限從永久改成兩年）。客服接到「我的短網址突然失效」時，第一個要對照的是最近是否改過規則。這一份由發布變更的團隊在上線前送給客服，對外公告與客服用的版本同時發出。

錯誤碼對照表：使用者畫面上顯示的每一個錯誤碼，寫明它代表什麼、使用者能做什麼、客服可以怎麼答覆，以及什麼條件下要轉給工程。對照表由擁有那個錯誤碼的服務團隊維護，欄位與維護方式見 11.16 面向終端使用者的錯誤碼與請求編號 的〈錯誤碼對照表〉。

帳號層級的查詢工具（客服後台）：一個只讀的頁面，讓客服以帳號或短碼查到這一筆資料的狀態，例如短碼存在、已過期、被檢舉停用，帳號的方案、本月剩餘額度與是否簽了服務水準協議，以及本期的扣款紀錄（時間、金額、狀態）。它取代「請工程幫我查一下資料庫」，由工程維護它顯示的欄位，客服缺欄位時提出需求；設計時要決定客服看得到哪些欄位、每一次查詢是否留下稽核紀錄，見 11.16 面向終端使用者的錯誤碼與請求編號 的〈客服查詢工具的權限〉。

以「短網址打不開」為例，客服先以查詢工具查那個短碼，因為查詢工具讀的是這一筆資料本身：短碼不存在、已過期或被停用，都能當場答覆並說明原因。短碼狀態正常，客服用自己的瀏覽器開一次那個短網址。開得起來，問題多半出在使用者那一端的網路或裝置。開不起來時看瀏覽器停在哪裡：已經轉到原本的網址、而那個網站打不開，問題在原本的網址那一端，由客服答覆；停在短網址服務的網域上（錯誤頁或逾時），問題出在多人共用的元件上，這時對照內部狀態頁有沒有轉址相關的事故，有的話把這則回報附到那個事故上。沒有的話，轉址是短網址服務的核心功能，客服又在自己的瀏覽器重現出來了，照〈轉給值班的條件與轉交方式〉裡「客服照使用者的步驟操作一次就重現得出來」那一條立即呼叫值班。

轉給值班的條件與轉交方式

客服判斷一則回報要怎麼處理時，有三種去處：立即呼叫值班、開單在上班時間處理、由客服答覆。這三種去處就是客服這一端的分級。《The Site Reliability Workbook》的值班章收錄的 Evernote 案例把事件分成三級：P1 立即處理並呼叫值班，P2 下一個上班日處理、寄信給團隊並發到事件頻道，P3 只是資訊。立即呼叫值班對應 P1，開單對應 P2；由客服答覆的回報不需要工程處理，接近 P3，其中附到進行中事故上的那些則是那個事故影響範圍的證據。

立即呼叫值班的回報，共同點是影響正在擴大，或者損害事後補不回來：

• 客服照使用者的步驟操作一次就重現得出來，不是單一帳號的資料造成的，而且受影響的是作業規則列出的核心功能（短網址服務是轉址與建立短網址）。 重現得出來代表問題不在使用者自己的網路或裝置；夜間只有少數使用者的服務，等到回報件數夠多可能已經天亮，所以這一條不必等件數。核心功能以外、重現得出來的錯誤（例如某一款舊版瀏覽器的統計頁圖表空白）開單處理。
• 多位使用者在短時間內回報同一個症狀或錯誤碼，而內部狀態頁沒有對應的事故。 單一使用者的回報多半出在他自己的資料、網路或裝置；不同使用者回報同一個症狀，指向的是他們共用的元件，而內部狀態頁上沒有事故，代表監控沒有發現它。客服有好幾位時，每一位只看得到自己手上的單，件數要由客服系統計算：收件時把錯誤碼與功能填進單子的欄位，客服系統統計最近十五分鐘同一個錯誤碼（沒有錯誤碼的以功能）的件數，越過門檻時直接在值班通知系統建立事件；已有進行中的事故時，值班通知系統把新事件併進那個事故，不再重複呼叫。這是 4.29 值班的例行檢查 那條原則（一個訊號能寫成越過某個門檻就送出的規則，就寫成告警）用在客服單上。門檻數字的依據是平常的基線：取過去幾週同一個錯誤碼在每一個十五分鐘內的件數，先排除有事故的時段，以及沒有宣告成事故、但件數異常的時段（留在基線裡會把門檻抬到那次的件數，同樣規模的故障再發生時就越不過），門檻設在剩下的最高值之上，而且至少兩件，平常不會越過、共用的元件出錯時才越過。基線取幾週、門檻設多高由團隊依自己的件數定。
• 金流、資料遺失或資料外洩。 重複扣款、短網址的資料整批不見、使用者在自己的統計頁看到別人的短網址，這三種即使只有一位使用者回報也立即呼叫值班。重複扣款先以查詢工具看這個帳號本期的扣款紀錄：同一期有兩筆成功的扣款，立即呼叫值班，由值班確認重複扣款的來源（自己的扣款批次、或對金流商重送了同一筆扣款）是否已經停止，來源還在執行時，每多處理一批就多一批使用者被重複扣款；只有一筆成功、另一筆是信用卡的預授權暫扣，由客服答覆。資料遺失只能在備份與交易日誌的保留範圍內還原，拖得越久，能還原的時間點越少；資料外洩要在證據還在的時候保全。看到別人資料、帳號被盜這一類屬於資安事件，處理路線與一般事故不同，見 8.17 Security Incident vs Operational Incident 分流；外洩是從服務本身、還是從客戶持有的帳號或客戶自己的系統流出，怎麼判斷、判斷完成前後各通知誰，見 8.26 資料外洩時對商家的通知；使用者自稱帳號被盜時，客服要先確認來電者是帳號本人，見 7.41 單一帳號被接管。
• 簽了服務水準協議（SLA）的客戶，合約定義的核心功能無法使用。 合約上的可用性承諾以一段期間內的停機時間或錯誤率計算（例如 Amazon S3 以每五分鐘的錯誤率取整月平均），故障拖到上班時間才處理，中間的每一段時間都會算進去。這一條要客服判斷得了，查詢工具要看得到帳號是否簽了服務水準協議，作業規則要列出合約定義的核心功能（短網址服務是轉址與建立短網址）以及合約怎麼算「無法使用」：多數合約以錯誤率計算，只有變慢不一定算。

客服回報沒有寫成呼叫值班的條件時會發生什麼，Google SRE Workbook 記錄的 Google Home 案例是一個實例：裝置對喚醒詞回應錯誤訊息，客服陸續接到大量使用者回報，這些回報卻沒有觸發升級，過了約四天問題才被提到最高優先度，團隊始終沒有宣告事故（見 Google Home 客訴訊號）。

開單、上班時間處理的回報，是不符合立即呼叫值班的條件、而客服手上的資訊答不了的回報，例如某一個帳號的點擊統計少算了一天。單一使用者、影響沒有擴大到其他使用者，是這一類的典型樣子；工程重現不了、或沒有替代做法，都不改變它開單的去處，客服在單子上註明，工程排序時看得到。單子上要帶齊客服收件欄位（見〈工程查證的順序與給客服的回覆〉），工程才不必回頭向客服要資料；開單之後工程第一次回覆的期限也寫在那一節。

由客服答覆的回報是錯誤碼屬於使用者自己能處理的那一類（密碼錯誤、輸入的網址格式不對、額度用完），或是已知錯誤清單、內部狀態頁上已經有的問題。已經有事故的回報不另開單，而是附到那個事故上：每一則附上去的回報都是受影響範圍的一筆證據，事故的影響評估會用到它們（見 8.20 Customer Impact Assessment）。

立即呼叫值班要走和告警同一套值班通知系統：客服在 PagerDuty、Jira Service Management 或 Grafana Cloud IRM 這類值班通知服務手動建立一個事件，帶上客服收件欄位、目前收到幾件與第一件的時間，由排班表決定通知誰，沒有回應時照 Escalation Policy 往下一層轉。客服因此要有在值班通知系統建立事件的入口（帳號、表單或整合的信箱位址）。只有一兩個人、沒有值班通知系統的服務，收信的人就是值班自己，改由信箱規則依使用者在表單選的類別（例如「被重複扣款」「網站完全打不開」）自動推播到手機。客服在聊天群組裡標記某一位工程師，那則訊息只送到一個人，他不在值班、在睡覺或在開會時，回報就停在那裡，也沒有任何紀錄可以事後查出它停了多久。

客服外包給另一家公司時，這些入口都跨了組織：值班通知系統的事件入口、內部狀態頁與查詢工具要開給外包人員的個人帳號，查詢工具的稽核紀錄才記得到是誰查的；外包的客服系統若與自己的工單系統分開，兩邊的單要彙總到同一個系統計數，件數門檻才算得到全部的回報；查詢工具驗證單號時也要讀得到外包的客服系統。

值班接手之後，以 8.18 Incident Intake & Evidence Triage 的事故候選欄位建立一筆事故候選（還沒確認是事故、等待查證的紀錄）：來源欄標為客訴（customer ticket），可信度欄記錄這筆紀錄的證據來自哪裡，在找到內部證據之前標為只有外部來源（external-only）。

客服呼叫值班之後，資訊也要從值班回到客服：值班確認是事故之後，由對外聯絡人（或兼任的值班）在內部狀態頁寫上對客戶的說法，客服才知道接下來同類回報要怎麼答覆；少了這一步，客服會把每一則同類回報再轉上來一次。

上面這些判斷要客服照著做，得寫成一份客服的作業規則，內容是：同一個錯誤碼的件數門檻與時間窗、簽約客戶的核心功能與「無法使用」的定義、在值班通知系統建立事件的入口、開單之後工程第一次回覆的期限，以及逾期時往誰追。

工程查證的順序與給客服的回覆

工程收到客服轉來的回報時，查證從回報裡的識別資訊開始。客服收件欄位是帳號、發生時間與時區、畫面上的錯誤碼與請求編號、功能、裝置與作業系統、App 版本或瀏覽器，以及操作步驟與螢幕截圖；這些欄位各自用在哪一步查證、使用者沒抄下請求編號時怎麼退回以帳號與時間查，見 11.16 面向終端使用者的錯誤碼與請求編號 的〈客服收件的欄位〉。

查證從最精確的證據開始，再往外擴。請求編號只對應一次請求，所以先以它查 log，確定錯誤發生在哪一次請求，以及 log 記下的內部錯誤類別是什麼（畫面上的錯誤碼可能由前端對應成較粗的類別，log 裡的比它細）；請求跨了好幾個服務時，以 log 裡的 trace-id 查 trace，找到出錯的那一個服務。有了內部錯誤類別，工程才拿它和進行中的事故與已知錯誤清單比對：客服先前比對的是使用者描述的症狀，工程這一次比對的是 log 裡的內部錯誤類別，所以工程分辨得出兩則症狀相同而原因不同的回報。最後判斷影響範圍：只有這個帳號的資料出了問題，就以這個帳號處理；同一段時間別的帳號的 log 也出現同一個內部錯誤類別，就要回頭檢查它是不是一個還沒被發現的事故，必要時由工程自己呼叫值班。請求編號在 log 裡查不到時，先確認 log 的保留期是否比錯誤到查證的時間（從使用者遇到錯誤到工程查 log，見 11.16 面向終端使用者的錯誤碼與請求編號）短，這種情形下問題出在保留期，不在使用者抄錯。

給客服的回覆要讓客服能直接轉述給使用者，所以包含：

• 原因：以使用者聽得懂的話說明，例如「這個短網址在九月因為收到檢舉被停用」，不寫內部的表名或錯誤類別。
• 對使用者的說法：客服可以直接用的一段話。
• 使用者要做的事：需要重新登入、換瀏覽器、等修復上線，或什麼都不用做。
• 修復狀態：已修好、預計何時修好，或不會修以及理由；預計時間只寫工程有把握的時間，因為客服會把它轉述成對使用者的承諾。
• 追蹤單號：之後同一個使用者再來問，客服查得到進度。
• 是否列進已知錯誤清單：還沒修好、會再有別人遇到的問題，由工程在回覆的同時寫進清單；使用者操作或設定造成、本來就不需要修正的，寫成知識文章或錯誤碼對照表的一列（見〈重複出現的回報：查證結果寫回知識文章、告警規則與查詢工具〉）。寫成對照表的一列時，回覆裡的原因、對使用者的說法與使用者要做的事，分別填進對照表的意思、客服的答覆與使用者能做的事，另外補上轉給工程的條件、處理時查的工具與負責的團隊。

開單的回報也要有回覆期限，例如工程在兩個上班日內第一次回覆。期限寫進客服的作業規則，客服才能告訴使用者什麼時候會有消息；工程沒在期限內回覆時，客服依作業規則往工程團隊的負責人或當週的值班追。

重複出現的回報：查證結果寫回知識文章、告警規則與查詢工具

一則回報查完之後，查證的結果要寫回成下一次不必再查的形式，否則同一類回報每出現一次，工程就重做一次同樣的查證。

客服知識管理有一套方法叫 Knowledge-Centered Service（KCS），由 Consortium for Service Innovation 維護。它的做法是在處理回報的當下就把解法寫成知識文章，用提問者自己的說法描述問題，讓下一個人搜尋得到；之後每一次有人用到那篇文章，就順便確認內容是否仍符合現況，不符合的當場修正或標記。KCS 的重點在時機：寫在處理當下，而不是事後找一段時間整理，因為過了那個時間點，處理的人已經不記得細節，也就沒有人會寫。

同一類回報重複出現的原因有三種，每一種的查證結果寫回不同的地方；一則回報可以同時屬於兩種（例如監控沒有發現，而工程查證時要下資料庫查詢），兩處都要寫回：

• 工程查證時用到的資訊，客服手上的工具也查得到：代表客服本來可以自己答，寫回客服的資訊。有對應錯誤碼的寫成錯誤碼對照表的一列，沒有錯誤碼的症狀寫成一篇知識文章，還沒修好的程式錯誤寫進已知錯誤清單。
• 監控沒有發現：使用者比告警先發現的故障，寫回一條告警規則、一條合成監控（synthetic monitoring）的探測，或一項用戶端監控（在使用者的瀏覽器或 App 裡收集錯誤與效能，見 4.10 Client-side / Synthetic / RUM）。這一類代表監控沒有在檢查這種故障，各層監控各自檢查什麼、怎麼找出這種缺口，見 4.0 服務端監控的分層，業務停了而程式回應正常這類每一層都偵測不到的故障，見 4.0.1 監控鏈事前偵測不到的異常；從事故寫回規則的流程見 4.8 訊號治理閉環，事故證據寫回監控與 runbook 的做法見 8.22 Incident Evidence Write-back。
• 工程查證用到的資訊，客服手上的工具查不到：工程每次都要連進資料庫下同一段查詢，寫回客服查詢工具的一個欄位，或一個給工程用的查詢頁面。重複、手動、可以自動化的維運工作叫 Toil，治理方式見 8.13 Repeated Incident 與 Toil 治理。

同一個程式錯誤造成的重複回報，最後的解法是修掉那個錯誤；寫回是修好之前讓客服與工程不必重複處理的做法。要知道哪一類回報在重複，客服單要以錯誤碼與功能分類計數（兩者都是客服收件欄位），每週由工程與客服一起看排名前幾名的類別（例如前五名，數字由團隊定），這份計數是 4.29 值班的例行檢查 在〈每週營運會議讀的訊號〉裡讀的項目之一。

客服與工程之間的回報流程失效時的徵兆

這套流程失效在哪一段，會在客服單與事故紀錄上留下不同的徵兆：

• 事故時間線上，客訴比告警早出現，而且不只一次：監控沒有在檢查使用者先發現的那一類故障，前幾次的查證結果也沒有寫回告警規則或合成監控。
• 事故時間線上，第一則客訴到值班被呼叫之間隔了很久：客服呼叫值班的條件沒有寫成數字，或件數仍由客服各自計算，要等到有人覺得件數夠多才轉。
• 同一類回報反覆轉到工程：先查這一類在錯誤碼對照表與已知錯誤清單有沒有條目。沒有條目，是查證結果沒有寫回客服的資訊；有條目而內容過期，是清單或對照表沒有人更新。
• 客服把工程的回覆再轉回來問「那我要怎麼跟使用者說」：回覆缺了對使用者的說法與使用者要做的事。
• 事故進行中，客服仍然逐一轉單：先問客服是否知道內部狀態頁。知道而頁面上沒有這個事故，是值班確認事故之後沒有更新；不知道，是內部狀態頁沒有放進客服的工具。
• 工程以請求編號查不到 log：先查同一時段其他請求的 log 是否還在。都不在，是 log 的保留期比錯誤到查證的時間短；其他請求在、這一筆不在，是請求編號沒有寫進 log。見 11.16 面向終端使用者的錯誤碼與請求編號 的〈log 保留期：從使用者遇到錯誤到工程查 log 的時間〉。

延伸閱讀：事故流程、錯誤碼設計與值班的例行檢查

• 客服回報、告警與第三方狀態怎麼以同一組欄位進入事故候選，以及事故候選要填的欄位：8.18 Incident Intake & Evidence Triage
• 事故中對內、對客戶與對外的訊息分層與更新節奏，對外聯絡人寫進內部狀態頁的說法從這裡來：8.4 事故通訊與狀態更新
• 使用者畫面上的錯誤碼與請求編號、錯誤碼對照表的欄位、客服查詢工具的權限與 log 保留期：11.16 面向終端使用者的錯誤碼與請求編號
• 值班接班時、交班時與每週要看的訊號，包括客服單量與排名前幾名的錯誤碼：4.29 值班的例行檢查

概念位置

分層支援處理的是使用者回報，Escalation Policy 處理的是告警與事故：分層支援決定一則回報由哪一層的人回覆，升級策略決定一個沒有回應或沒有進展的事故轉給下一個值班的人。兩者在一個地方交會：客服判斷一則回報要立即呼叫值班時，它就從分層支援進入事故流程，由值班通知系統與升級策略接手。

往上轉在 ITIL 的事件管理裡分成兩種：functional escalation 是把回報轉給專業能力更深的一層（一線客服轉技術支援、技術支援轉工程），hierarchical escalation 是往有權調動資源或做決定的人升（主管、事故指揮），通常發生在處理逾期或影響擴大時。同一則回報可能兩種都經過：客服把重複扣款的回報立即呼叫值班，是 functional escalation；開單之後工程逾期沒有回覆、客服往工程主管追，是 hierarchical escalation。

分層之外另有一種做法叫 swarming（Consortium for Service Innovation 稱為 Intelligent Swarming）：回報不逐層轉，而是由能處理它的人直接協作處理。它省掉逐層轉手的等待，代價是每一則回報都要找到合適的人，適合問題種類多、單一層的資訊不夠用的組織。

可觀察訊號與例子

一則回報停在哪一層，由那一層手上的資訊與工具決定。短網址服務的客服手上有查詢工具（客服後台），查得到短碼存在、過期或被停用，「短網址打不開」多數在一線就能答覆；客服手上沒有這個工具，同一類回報就一路轉到工程。分層運作不良的訊號是同一類回報反覆轉到上一層、而上一層每次查的都是下一層本來查得到的資料。

判讀方式

看到回報大量往上轉時，先問上一層這次用了什麼資訊才答出來，再問這份資訊能不能交到下一層手上：能的話補成下一層的工具或知識文章，不能的話（需要改程式、需要讀含個人資料的 log）才是該轉的回報。客服與工程之間的完整流程見 8.24 客服回報的處理。

概念位置

ITIL 把三種紀錄分開：事故（incident）是一次服務中斷或品質下降，包括單一使用者遇到的；問題（problem）是一個或多個事故的原因或可能的原因，建立問題紀錄時根因通常還不知道；問題分析過、還沒解決的，就是已知錯誤。在 ITIL 裡事故是事件、已知錯誤是原因，兩者會同時存在：每一位撞上同一個已知錯誤的使用者回報，都是一筆連到它的事故，以已知錯誤裡的替代做法處理。

本站的事故流程另有一條分界，用的「事故」是需要指揮處理、影響可能擴大的那一類（接近 ITIL 的 major incident）：影響固定、有替代做法的問題列進已知錯誤清單，由客服與值班照著處理；影響正在擴大、需要有人指揮的，走 Incident Severity 與事故流程。

可觀察訊號與例子

短網址服務的統計頁在某一款舊版瀏覽器上圖表空白，換瀏覽器就看得到：影響只限那一款瀏覽器的使用者，不會擴大，有替代做法，修正排在下一次發布。這一則列進已知錯誤清單，寫明症狀、受影響的瀏覽器版本、客服給使用者的替代做法與追蹤單號。客服接到「統計頁空白」時先查清單，符合的當場答覆，不轉給工程。

判讀方式

清單的價值取決於它是否跟上現況。修好上線的條目沒有移除，客服會繼續給使用者一個已經不需要的替代做法；新確認的問題沒有寫進去，同一類回報就繼續轉給工程。維護責任因此要指定給確認問題與發布修正的人：確認時寫入、修正上線時移除。客服怎麼用這份清單、工程什麼時候寫入，見 8.24 客服回報的處理。

概念位置

KCS 把處理回報的流程稱為 Solve Loop，Practices Guide 列出四個動作：在當下記錄（capture）新的知識、把它整理（structure）成人與機器都能使用的形式、重用（reuse）既有的知識避免重做、在使用時改進（improve）它，讓它保持正確。另有兩個原則：「Reuse is Review」指每一次使用一篇文章就是在檢查它；「Flag It or Fix It」指使用文章時發現要改的地方，有把握而且有修改權限的人當場改掉，否則標記出來交給有權限的人。寫下的文章與 Known Error（已知錯誤） 清單的差別在範圍：已知錯誤只收還沒永久修正的問題，KCS 的文章也收使用者操作與設定這類本來就不需要修正的問題。它與事後集中寫文件的差別在時機：處理的當下，處理的人還記得細節，提問者的說法也還在手上；事後整理時兩者都已經不在。

可觀察訊號與例子

短網址服務的工程查完一則「短網址突然失效」，原因是那一批網址在服務改了有效期限之後到期。依 KCS 的做法，工程在回覆客服的同時寫一篇文章，標題用使用者的說法「短網址突然打不開」，內容寫判斷方式（查到期日）與答覆；下一則同樣的回報，客服搜尋得到這篇，當場答覆。

判讀方式

判斷一個組織的知識是否在累積，看同一類回報轉到工程的次數是否下降。次數不降時，先查答案有沒有被寫下（處理流程裡沒有寫文章這一步），再查寫下的文章能否以使用者的說法搜尋到（標題用了內部術語時搜尋不到）。客服與工程之間把查證結果寫回的流程，見 8.24 客服回報的處理 的〈重複出現的回報：查證結果寫回知識文章、告警規則與查詢工具〉。