這一篇整理客服與工程之間處理使用者回報的流程，範圍從客服接到一則回報開始，到它由客服當場答覆、併進一個事故，或由工程查證後回覆為止。一則回報確定是事故之後的分級、指揮與對外通訊在 8.1 事故分級與啟動條件、8.2 事故指揮與角色分工 與 8.10 Stakeholder 通訊與外部狀態頁；客服回報、告警與第三方狀態怎麼以同一組欄位進入事故候選，在 8.18 Incident Intake & Evidence Triage。使用者畫面上的錯誤碼與請求編號怎麼設計，在 11.16 面向終端使用者的錯誤碼與請求編號。回報者是 API 的呼叫方（另一個系統的工程師）時，一則回報代表那個系統背後的所有使用者，這一篇以回報件數計算的門檻不適用，改以 log 裡那個呼叫方的錯誤率判斷；呼叫方帶來的請求編號怎麼查，見 錯誤回報的回饋迴路：request-id、trace 與呈現回報分工。

這一篇的例子是一個短網址服務（需求規格見 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 的時間〉。

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