前端業務開發的通用經驗

什麼是品質？

衡量品質的常用名額

• 開發階段：提測 bug 數（日均 bug 數、提測打回、千行 bug 率）
• 上線階段：終止次數、釋出失敗次數、復原次數
• 運維階段：線上故障、報警數

品質保障的基本要義，就是確定各項名額長期維持在合格線以上。具體操作上，一般由 QA 團隊定期整理，公開釋出。

線上故障需進行分級管理，定級标準主要看影響面和影響程度。比較重大的故障，通常有兩種類型：一是影響了核心名額，如單量、交易額等，二是阻塞主流程，比如某個核心功能無法使用。

還有兩類故障需要格外關注：一是低級錯誤，比如小數運算不考慮精度，這會嚴重影響技術團隊的聲譽和專業可信度；二是重複錯誤，同類問題再次發生，說明上次發生之後的複盤和後續保障動作沒有做到位。

對于線上故障，技術團隊應該定期複盤，研讨學習，管理者應該将其作為品質保證的長期管理手段，提高團隊的品質意識和排查技能。

什麼是故障？

技術故障 / 邏輯故障

技術故障是指像按鈕點不動、js 報錯、接口報錯、圖檔不展示、頁面白屏、伺服器當機、接口請求死循環等純因技術問題導緻的故障；邏輯故障是指非技術的業務邏輯故障，即一切技術名額都正常，代碼運作什麼錯都沒有，但功能表現和執行結果不合邏輯或不符合預期，例如明明輸入了手機号，卻提示手機号不能為空。

技術異常通常能夠被監控發現，而邏輯異常一般很難靠監控發現，技術手段上一般是靠自動化測試發現，或者靠人工深入到業務邏輯中主動埋點監控（例如監控訂單總額，如果小于 0，就上報異常）。

内部故障 / 外部故障

内部故障是指團隊負責範圍内發生的故障，故障修複職責在己方。除了内部故障，其他的都是外部故障，也就是外部依賴發生的故障，需要由其他團隊解決。

外部依賴，對業務方而言，不妨稱之為供應鍊。對前端來說，供應鍊主要包括網絡、用戶端/容器、橋方法、接口、前端架構、各類第三方 sdk 等等。

任何外部依賴問題，其實也是内部問題，反映出對外部依賴的不了解、技術選型不合理、對供應鍊的風險評估與監控有缺失。

品質保障的“三層四面”

品質保障是一個系統化工程，從開發周期上，可劃分為事前、事中、事後三個階段，事前重【預防】，事中重【檢測】，事後重【監控】；從保障手段上，可劃分為四個方面：基建、測試、風控和管理。接下來本文将分階段講述其中的幾個重點事項。

開發階段

測試服務

品質保障最基礎的措施是測試。是以測試環境、測試工具、測試平台服務是否給力，對于品質保障很重要。比如相容性問題，如果有工具能一鍵驅動幾十台機子渲染某個頁面，截圖比對，直接生成報告，标出問題機型，那這樣相容問題的發現基本就不用人操心了。再比如自動化測試，如果能友善的錄制流程，無需人工寫代碼驅動，那麼回歸的覆寫面和效率都會大大提升（比如網易的 airtest）。

技術架構标準化

技術架構标準化是指有限制力的最佳實踐。最佳實踐的兩個核心利益點是：開發效率、開發品質。也就是說一種經驗能否算作最佳實踐的基本門檻，是看它能不能提高效率，以及是否有利于品質保障。

技術架構标準化之是以能保障品質，主要原理是預防甚至消解導緻故障的基本隐患。軟體開發領域的一個元問題，是規模。簡單、小規模的軟體就不容易出問題，也就不需要太多工程化手段。規模是現實需求決定的，也即技術不可控的，可控的是技術實作的複雜度。為什麼用架構、元件化、mvvm，核心原因是降低複雜度。

限制開發模式，統一團隊開發風格，也是為了控制複雜度，因為每個人的個性設計雜糅在一起會帶來額外的複雜度。

除了控制複雜度，最佳實踐的另一個主要目的是預防故障，避免重複踩坑。這些開發實踐中總結出的一系列經驗（比如：前端業務開發的通用經驗 - JavaScript 篇），需要用技術手段自動檢驗（比如靜态掃描），形成限制力，才能成為技術架構的一部分。

供應鍊品質

一個頁面到底都依賴啥？通常一個業務時間一久，維護的人換過一茬，基本就不容易搞清楚了。通用的依賴一般來說有：CDN、網絡、容器、接口、基礎架構/庫、sdk（埋點、監控之類的）、打包工具等等。

每個項目都需要盤清依賴項，明确邊界。關鍵有兩點：第一，依賴是否可靠，比如出問題了能否找到維護方；第二，依賴是否徹底解耦，比如某些配置不應該跨項目或者跨團隊存在，否則會互相中傷。

針對每一種依賴，還需要一些防範和監控措施。

CDN

CDN 的一個主要問題是節點故障，該問題的一種常見表現是：某個手機上請求靜态資源耗時很長，但是切換下網絡，發現就好了，再切回去，還是耗時很長，其它手機一切正常。說明有可能是某個 CDN 節點發生了故障，而因為 DNS 緩存的緣故，出問題的手機可以穩定複現這個問題，清緩存後問題可能就不再複現。監控這類問題的基本政策是拿到所有資源的加載時長，如果超過門檻值，則上報。

網絡

網絡的一個主要問題是劫持。比如這種場景：因為 js 靜态資源是單獨部署的，是以需要解決跨域問題，script 标簽上要加 crossorigin=anonymous，響應頭要帶 Access-Control-Allow-Origin: *。資源被劫持後，響應沒有帶這個頭，就會導緻資源因跨域而被浏覽器拒絕執行，頁面肯定就挂了。監控劫持的一種思路是 IP 白名單，另一種思路是 hash 校驗，參考 Subresource Integrity。

容器

Webview 可能出各種問題，舉個我遇到過的例子：h5 頁面自适應設計依賴 rem，rem 的計算需要取頁面寬度，這段 js 通常會放到 

<header>

 标簽内執行。然後因為容器背後的預加載邏輯有問題，導緻 html 解析到 rem 計算腳本的時候，取出的頁面寬度是 0，相當于容器頁面還沒有初始化好，但 html 已經開始執行了。結果就是所有以 rem 為機關的尺寸，實際都等于 0px，頁面就白屏了。那這怎麼監控呢？基本思路是從 html 元素開始遞歸周遊每個元素，用 getBoundingClientRect 算出尺寸，如果發現所有元素都沒有尺寸，就證明白屏了（細節上還要考慮 display、visibility、opacity 等問題），發現白屏，就把整個 dom 文檔報上去（document.documentElement.innerHTML）。很暴力吧，不過上述問題就是通過這種方式發現的（發現 html 标簽的 font-size 為 0）。

容器提供的橋方法，業務方最好做一次封裝，統一處理異常上報。

接口

接口異常一般有三類：網絡異常（5xx、逾時）；業務異常（一般用自定義狀态碼辨別）；資料結構問題（缺字段、資料不合法等）。

網絡異常監控主要是通過網絡庫的能力，業務異常和資料結構異則需通過代碼監控。舉個資料異常的例子：後端某天發現一個接口的經緯度寫反了（顯然前端也是反的，是以功能沒問題），于是單方面修改後，悄悄上線，上線後沒實際在 app 上測，自以為問題修複了，那肯定就出問題了。這種情況，前端可以對經緯度的範圍做下校驗，有問題就報出來，這就是主動監控。

除了異常監控，還需要考慮對接口的調用量進行監控，調用量的驟增或驟降其實也是一種異常。我遇到過因前端死循環導緻接口調用量上漲幾千倍的案例，就是因為缺調用量監控，故障持續了整整一天才被發現。不過後端隻能對總量做監控，如果隻是小樣本使用者遇到死循環不斷調接口，不一定能觸發後端的監控報警，是以前端最好主動監控下接口短時間重複調用的情況。

基礎架構/庫

我從來沒有遇到過 vue 和 react 本身的 bug，隻能說用得晚而淺吧。一般通用架構的品質還是很可靠的，畢竟有那麼多人在用（當測試）。架構也提供了一些異常處理機制，需要利用起來，比如 vue 的全局配置方法 errorHandler 和 react 的 ErrorBoundry 元件。

引入第三方庫，原則上需要鎖定版本，不要完全指望開發者遵循 semver 版本語義。

sdk

我們引入的 sdk 也是可能出問題的。像監控類的 sdk 必須先加載，且必須是同步加載，可考慮内聯，避免網絡加載失敗（網絡成功率不會是百分之百，一般 99.9% 上下）。然後一定要控制版本。

舉個我見過的例子，某 sdk 内部有一個上報邏輯，為減小代碼體積，自己手寫了 ajax 方法，但忘了設定異步，搞成了同步，而容器不允許同步網路請求，就崩了，這種業務方除了猛怼似乎也沒什麼轍。sdk 的品質必須得由服務方保障。是以就需要明确：依賴的服務得找得到負責人。

打包工具

像 webpack 這樣通用的工具也會出問題嗎？一般工具本身的 bug 不容易遇到，常見的是用法導緻的 bug。比如打包出的代碼包含 es6 導緻相容問題（沒錯，2020 年安卓 5.x 仍有不小的使用者量），那顯然是某個環節出問題了（比如 import 了 node_module 裡未經編譯的 js），還有像我之前用 tapable.js 導緻 es6 代碼被引入，都莫法編譯：

是以說選擇外部依賴時，要麼是一個通用依賴，有很多人在用，并且跟你是同一種用法（tapable 是一個通用依賴，但很少有人直接使用），要麼非常清楚背後的代碼實作，再不然就得靠全面的測試。否則貿然引入就會有風險。

針對打包環節，一般需要的監控手段有：

• 檢測 es6 代碼（es-check ）
• 檢測循環引用（circular-dependency-plugin ）
• 檢測重複包（inspectpack）

日志

哪些場景需要記日志？

• 為了統計某個名額
• 為了排查問題
• 為了監控異常

哪些地方需要記日志？

• 主動監控：接口、橋方法、業務異常
• 被動監控：網絡/資源時延與成功率、頁面性能、js error

日志覆寫不全，意味着監控有漏洞。但也不是越多越好，增加流量消耗，浪費伺服器資源。

怎麼記日志？

首先是做分類和分級，主要目的是有助于針對性的配置報警，比如可以針對某個頁面的 x 類問題的 x 級别配置一個報警政策。

• 分類：網絡 / js / 自定義
• 分級：Error / Warn / Info
  • Error 是指明确對使用者有嚴重影響的、不允許存在的異常，如果允許存在，就不能是 Error 級别。理想情況下，Error 級日志隻要存在，就應該想辦法清零，報警政策上，敏感度應該最高，隻要一出現就報警
  • Warn 是指明确是個問題但也明确一定有少量出現，同時對使用者影響不算嚴重。這種級别在報警政策上，主要是看量級，少量 Warn 允許存在
  • Info 一般就是純提供問題排查資訊的日志，完全不用考慮監控。

手動上報的日志名稱，最好和自動上報的日志名有所區分（例如統一加個字首），同時帶上标記，例如頁面名、接口路徑、方法名，好處是一目了然。日志的參數内容，應該盡可能包含問題排查所需的必要資訊（通用的如用戶端型号、系統版本、網絡類型、地理位置等等）。

日志存到哪裡？

• 本地：量較大但使用頻率極低的日志，存使用者本地，以避免過度消耗伺服器資源，需要通過回撈才能檢視，不能即時檢視
• 雲端：使用頻率較高，需要即時檢視

技術方案

很多時候，技術方案都是後端主導，畢竟業務邏輯主要在後端，前端隻是負責展示，而且後端涉及庫表、緩存、接口、系統調用關系、邏輯流等，很容易畫出一堆圖來講，前端要是沒個明确指南，技術方案往往不知道寫啥。

一般估時超過一定值的有規模的需求，需要書面的技術方案和評審環節，尤其是涉及多人分工開發的場景。做技術方案主要目的有三個：

• 提前想清楚關鍵問題，比如：
  • 影響範圍：本次需求波及的改動範圍，漏掉的話排期肯定就不準，QA 也特别關心改動範圍，因為這決定了 QA 的測試範圍
  • 依賴資源：要完成本次需求，哪些必備功能需要外部提供。需要明确這些功能是否可靠（可能需提前調研）、如果沒有能否及時提供、無法及時提供又怎麼辦
  • 資料來源：展示層所需的所有資料都來自哪裡，放到哪裡或由誰提供才合适
  • 核心邏輯：用圖表說話
  • 接口方案：有時候接口前端定比較好，畢竟作為需求方最知道自己需要啥
  • 兜底方案：假設這個功能出問題了，有沒有備份方案，例如開關、降級等手段
  • 監控方案：通過什麼樣的方法能知道我這個功能上線後是有問題還是沒問題。這個其實很考驗水準，一定程度也決定了自動化測試的設計用例，主動監控和用例設計某種程度上是一回事
  • 測試方案：需要準備哪些條件通過哪些過程達到哪些預期才能證明我的功能是沒問題的。如果在需求開始前，能在腦子裡模拟出整個功能的邏輯實作過程，發現其中的關鍵點和風險點，乃至倒推出需求設計的不合理處，其實很能展現做事的水準。有時候經驗不足的開發，可能開發完後，才發現好些功能很難測甚至沒法測。如果能盡早預見，就可以調整技術方案，或者增加估時。免得提測後，還手忙腳亂
  • 上線方案：主要關心誰先誰後，出問題了復原順序如何，還有避開封禁期，因為确實出現過灰階釋出到一半結果剛好抵達封禁時間，剩下一半發不了的情況（雖說應算作釋出系統的問題）
• 排期的依據：大型需求隻有經過拆解才可能給出準确排期
• 同行把關：從團隊管理角度，一般在各個細分領域有至少主備兩人（或多人）專門負責。評審時視情況将涉及子產品的負責人拉進來，協助确定方案，以便于提前發現問題

如果是多人協作開發的需求，需要仔細劃分，避免互相産生依賴，不能避免則要明确依賴關系。各自負責的範圍也最好有明确邊界，否則代碼容易出現沖突。解沖突其實很容易出問題，凡是依賴人的謹慎與仔細之處，都容易出問題。

技術方案完成後，需要組織評審。評審的一個重要功能是需求再确認，同時也為後續測試方案提供依據，是以産品和 QA 一般都要參加。技術評審需要注意哪些是内部問題，哪些是公共問題。内部問題内部消化，避免在多方參與的會議上讨論内部問題。比如我多次遇到過會上幾個後端在争論内部的技術細節問題，前端、産品、QA 都不知道他們在說啥，這樣的會議效率就特别低。

啰嗦一句開會這事兒，原則上如果一個人隻需聽兩分鐘的内容，那他就不應該參加會議，最好由會議主持私下單獨溝通。像著名産品經理純銀就傾向于開小會，哪怕多同步兩次。這個比較依賴人的素質，多數人不懂怎麼開會但又不得不組織各種評審會議，如果你被迫加入這樣的會議，那聽完兩分鐘就應該走人，别不好意思。

SOP

SOP（标準操作程式）是一種涉及多環節的辦事指南，SOP 應該達到的标準是任何新人看着文檔就能一步步完成整個操作。每個團隊 wiki 裡，都應該有個專門的目錄，記錄各類 SOP。SOP 其實是貫穿所有環節的，比如上線 SOP、下線 SOP、線上故障處理 SOP、值班 SOP、營運活動配置 SOP 等等。

需求管理

有人可能覺得這咋是開發需要關注的事情呢？而且這事兒跟品質保障有毛關系？

通常做開發的人都習慣于執行，而不善于質疑。可能是因為公司未建立起相應的制度或共識，不過【對需求有判斷力】的确是個比較高的要求。個人認為作為研發至少得主動争取表達意見，不表達就不可能有話語權，否則産品一句話，你加班仨小時，能忍？有些大廠就很明确，講不清楚需求的收益，需求評審未通過，研發有權利拒絕執行。這就倒逼産品必須想清楚，說明白。理論上，不做需求就沒有 bug 對不？做經過深思的需求，中途不要瞎改，相比起需求頻繁變更，出 bug 的幾率更小對不？

此外，需求的規模也是一個問題，這裡要分情況，有時是客觀現實決定一個需求就是很大，有時是因為需求拆分不合理，把多個需求揉到一起導緻一個需求顯得很大，有時是因為解決方案超出了“問題和目标”所定義的範圍，夾帶了太多“私貨”。

需求規模過大，會帶來一系列問題，導緻出問題的機率增大：

• 吸收率。資訊量太大，一次評審是消化不完的，評一次不夠，評多次又浪費時間。合理的粒度，是保障評審效率和效果的基本前提，一個會議超過一小時，有效性就非常可疑（對普通幹活的人而言）
• 資訊量太大，導緻細節問題太多，很容易遺漏，難以提前發現
• 粒度太大，導緻工期較長，可能出現交叉需求、并發需求，可能因人力長期無法釋放阻塞其他事情的進展
• 粒度失控，引入過多資訊，會增大資訊同步成本。如果項目工期較長，還會因記憶問題，中途需要不斷溝通對齊，進一步降低效率
• 容易出現變更。需求變更，經驗不足的開發很容易改舊引新，改舊代碼引入新故障

對研發而言，需求管理可以做的事情包括：

• 質疑合理性，凡事先想為什麼。無明确收益或收益不可衡量的拍腦袋式的需求，拒絕執行或優先級往後排（有些事拖一拖往往有轉變）
• 大需求、探索性需求可考慮分期開展
• 明确要做的事情，符合問題與目标所定義的範疇
• 需求變更不能輕易接受，哪怕是需要接受的合理變更，也應該給需求方施加一點壓力（比如記下本次需求一共變了幾次，來個複盤）
• 對産品本人需要有判斷，比如剛加入團隊，又提比較大的需求，大機率會出現較多的需求變更

涉及多個需求的整體管理問題，一般需要 TL 關注，比如需求間是否存在耦合關系，時間安排是否合理，優先級誰先誰後等。比如這樣一種場景：關聯需求分兩撥人同時做，其實是有風險的，假設 a 依賴 b 的某功能，b 也依賴 a 的某功能，必然隻能一起測試、一起上線，否則就死鎖了對不。但這麼做中間溝通協調的成本就比較高，出問題的機率也比較大。

如果需求間出現了重複，甚至沖突，那就是産品内部管理的事故了，TL 之間就需要友好溝通一番。

內建階段

分支管理

發錯分支，或者本地 master 分支合入了一些測試代碼然後不小心推到遠端，這些絕對出現過不止一次。分支管理必須通過代碼管理平台從技術上限制：

• 禁止本地直接 push master
• 合并 master 強制走 pr，必須有 approve 才能合并
• 鎖定線上環境釋出的分支

封禁期 / 灰階 / 漸進式

封禁期是一種風控手段，避免節假日上線，除了可能因使用者量增加放大故障的後果，還有就是避免因休假無人修 bug，也算是對員工的一種保護吧。不過有時會出現為了趕時間多個上線堆積到封禁期前一天的情況，這也是風險，需管理者注意。

灰階釋出主要是避免一次性上線，導緻潛在故障也跟着瞬間全量。在逐漸開量的過程中如果發現問題，可以及時中止回退，進而降低影響和損失。灰階釋出需要注意比例控制，比如單純因為謹慎，第一階段隻開很小的量，考慮到監控門檻值都是按全量配置的，往往因量太小而無法及時暴露問題。

漸進式是一種基礎理念，不僅展現在釋出過程，也展現在日常做事中。像我入行一年多終于進了大廠，剛進去就幹了件非常愣的事：把 webpack 1 升到 3，以解決編譯速度等問題。因為項目有一定規模，吭哧幹了一星期，一個 pr 改動檔案好幾百個，甚至都超出了代碼管理平台的 diff 上限。這麼大的改動，沒有 QA 測試，自己測了幾遍，就直接上線了。結果就出了一個偶現問題（特定條件下發生），這就懵了吧，幾百個檔案 diff，是哪個改動導緻的呢？如果分成幾批漸進式改造，不僅降低風險，還有助于事後定位問題。

Code Review

估計好多團隊都不搞 Code Review，從實踐來看，通過 Code Review 發現問題的比例，的确很少，因為太依賴人的素質了。不過 Code Review 仍有必要性，首先低階新人的代碼必須 Review；其次，Code Review 是代碼品質保障的一種手段，每個人都在鬧，業務代碼是坨翔，那 Code Review 的時候幹嘛去了呢；第三，可作為團隊内部技術交流的一種方式，互相學習編碼經驗。是以從機制建設上看，Code Review 也許某階段做不好，但不能沒有。不好可以改進，沒有，那整個技術管理機制就太弱了。

為了提高 Code Review 的可行性和有效性，賀師俊在這篇文章裡提到一點：限制單個 pr 的粒度。也有一定道理，不過操作成本略高，視團隊情況而定吧。

一般需要 Review 的内容：

• 代碼品質（前置校驗、邊界條件、複用、技術實作、加日志...）
• 代碼可讀性（指出看不懂的地方、改命名、加注釋...）
• 發現問題（技術實作的問題、業務邏輯的問題...）

重點強調：第一版代碼（新增頁面、新增業務元件）必須嚴格 review，一個變量都不能放過。因為第一版代碼奠定了某種基礎，如果設計上存在問題，後續疊代大機率會在錯誤的方向上越走越遠，到後面每加點新東西都舉步維艱。想重構優化，改動範圍、回歸成本都成倍放大，極其痛苦。第一版代碼一定要找最靠譜的人寫，然後重點 review。初期看可改可不改的問題，隻要有改的理由（哪怕隻是潛在風險）都應該改，不要小看破窗效應。

參考：Google Code Review Developer Guide

Review 有兩種形式，一種是提 PR 時 review，一種是定期複盤型 review。提 PR 一般是提測的同時就要提出來，等上線前提就晚了，一是稽核人不好提意見，會因顧慮阻塞上線而被迫 approve，二是就算提了意見，改還是不改，改了要不要測？是以 PR 提太晚，Code Review 就是無效的。

Code Review 在操作上一般還會面臨一些問題：

• 責任心：“他做事一般比較靠譜，pr 不用仔細看，肯定沒問題”；“何苦互相為難，禮尚往來嘛，直接 approve”
• 逆向選擇：“嗯，已經有兩個人看過 pr 了，那我也不用仔細檢查，肯定沒問題，上線”

解決責任心問題，主要機制是 reviewer 一起擔責，如果事後出問題，複盤時判定這個問題應該可以在 review 時發現卻因沒有仔細 review 而被忽略，那麼 reviewer 是需要承擔一部分責任的。當然，有責任就有權益，approve 的數量和 comment 的數量都可以算作研發的貢獻。

運維階段

監控

監控系統的責任，是盡快發現問題。要做好這點，有兩個基本前提：

• 全
  • 監控的覆寫面全，能盡可能多的捕獲到問題
  • 記錄的資訊全，對問題的描述足夠充分，能為後續定位問題的原因提供足夠的資訊
• 準：報警準确，誤報過多會降低感覺問題的敏銳性

監控系統做得比較深入，可以做很多功能，比如頁面回放，直接複現使用者的操作過程。

參考：淺談前端監控

備份、降級、開關

前端習慣了完全動态化，随時上線，無版本概念的開發模式，有時無法體會兜底措施的重要性。

像 native 這種缺熱修複能力，也沒辦法復原，一發版就沒後悔藥的，各個重點功能都必須考慮備份方案，出問題了可自動降級，或通過開關控制，關閉入口。通常大廠 APP 都有專門的配置下發方案。前端可以利用 json 配置平台，或者接口，或者最粗陋的，直接扔個 json 檔案到伺服器，借此實作遠端開關控制。

故障管理

核心理念

拆解事故，不為追責；看清根因，逐漸提升。

故障處理

處理故障，如何在最短時間内止損、定位原因、修複上限，非常考驗水準和經驗。總結下來，有一系列标準化動作供參考：

Step 0 明确問題

首先是明确問題的嚴重性。如果問題很嚴重，需要将周知對象上升到更進階别管理者。原因是：更進階别的管理者本身有更多的經驗，同時可以調動更多的資源，有助于盡快解決問題。畢竟線上故障，往往優先級最高，快速解決問題是最高目标。如果因為沒有及時上報，而是自己硬抗，導緻故障處理時機延宕，那可就有責任了。

除了判斷嚴重性，還有就是要搞清楚真正的問題究竟是什麼，避免後續排查出現方向性錯誤。尤其是非技術人員回報的問題，很多時候不見得能描述清楚，可以要求截圖或視訊佐證，最好還是自己能複現。

Step 1 及時止損

明确問題後的第一件事一定是止損，而不是埋頭去找問題。當然也需要判斷影響是否足夠嚴重，不是很嚴重的問題，或者止損措施可能導緻更大的損失，那麼需要酌情處理。

Step 2 定位原因

原因定位有很多思路，很考驗能力和水準，也比較有意思，像是在探索解密。

定位過程需要遵循一定的科學方法，不能全靠瞎猜，雖然有些隐蔽問題一開始可能也需要靠猜。

• 新增問題看改動。沒改動，就不會有新增問題
• 正向 / 逆向推導。從代碼入手一步步梳理過程。最好是監控系統能夠提供重制故障路徑的資訊
• 對比法。比如隻改某一個地方，分别釋出後 AB 對照下
• 排除法。一步步删除，逐漸定位病竈

Step 3 修複上線，回歸驗證

故障修複後，需要周知通報。

Step 4 複盤總結

一般線上故障，都需要文字化的記錄整個排查過程、分析根本原因、明确後續措施。

故障複盤

故障管理主要圍繞複盤文檔進行，從技術管理角度看，無論對團隊還是個人，故障複盤文檔其實是一種重要資産和财富，是拿千萬流量和真金白銀喂養出來的，可以沉澱和提煉出大量的實戰經驗，甚至可以結集出版。

複盤文檔主要包括四個部分：

1、時間線

從産生問題到發現問題的分鐘級過程分析，主要目的是看處理的過程和動作是否合理，是否走了彎路，能否更快發現問題，能否找到更好的解決思路，技術層面、管理層面怎麼改進更有利于故障的排查和處理。從管理角度看，主要關注三個時長名額：

• 從故障發生到故障被發現的時長，顯然是越短越好
• 從故障被發現到影響消除的時長，看止損是否及時
• 從故障被發現到問題解決的時長，看解決問題效率

如果時間都太長，那就更有必要深度複盤。

2、影響範圍、定級

影響範圍是定級的依據，定級是一種管理措施。比如：

• 團隊品質目标：全年無 xx 級以上故障
• 達到 xx 級别的故障，需要 xx 職級的老闆參與複盤

3、根因

必須定位到最初的源頭，找到根因，才算真正定位到了原因。找到根因的基本辨別，一是能複現，二是無法再追問，換句話說，找到根因的基本方法就是複現 + 持續追問（5 why 原則）。

判斷原因是否有效，主要看能否針對原因提出可執行的解決方案。按這個标準，以下原因都是無效的（通常都是主觀意識類的）：

• 疏忽大意
• 時間太緊
• 測試回歸不全，要多測試
• 重視程度不夠、缺乏敬畏之心、要加強重視
• 不仔細
• 考慮不全面
• 對代碼不熟悉

從故障複盤角度看，無效的原因，不一定無用。比如長期的疲勞工作肯定會增加出錯的機率，管理者也應該關注，不能過于機械主義，沒人情味，出了故障一頓犀利追問，把人搞成了人犯。

4、後續措施

後續措施主要是針對本次故障的原因給出的改進措施，主要目的是解決這樣幾個問題：如何保證下次不出錯？如何保證下次出了錯能及時發現？如何保證别人不出同樣的錯？如何保證同一類型的問題不再發生？後續措施也需要跟進結果，每次故障複盤會議第一步就是回顧上期布置的 TODO。