研發效能參考課程《研發效率破局之道》，穩定性保障參考《SRE實戰手冊》。
一、研發效能
1）效能度量
推薦從團隊和個人這兩個維度對度量指標進行分類，其中團隊維度中又分為速度、準確度和質量 3 類，所以一共是 4 類。
- 速度：天下武功，唯快不破，速度指標主要用來衡量團隊研發產品的速率。比如，前置時間，從任務產生到交付的時長。
- 準確度：關注產品是否跟計劃吻合，跟使用者需求吻合，能否提供較大的使用者價值。一個例子是功能的採納率，也就是有百分之多少的使用者使用了功能 x。
- 質量：如果質量有問題，產品的商業價值會被大打折扣。質量包括產品的效能、功能、可靠性、安全等方面。
- 個人效能：個人開發過程中的效率指標，比如開發環境生成速度、本地構建速度等。
總結了一張導圖，展示了這 4 個方面的度量指標，供參考。可以看到，一共給出了 40 多個指標。
提供使用者價值是公司存在的根本，因此與之相關的指標是最重要的。這一點非常好理解。從這個角度來看，以下幾個相關度量指標比較有效：
- 淨推薦值 (Net Promoter Score，NPS)，是透過調研瞭解使用者滿意度，實用性很強。
- 系統 /App 當機時間 (System/App Downtime) 和嚴重線上事故數 (Incidents)，衡量的是系統的可用性，通常與使用者價值直接掛鉤。
- 熱修復上線時間 (Hotfix Time)，指的是從編碼完成到部署到生產的時長，關係到解決重大缺陷的效率，與使用者價值強相關。
在度量效能時，很多團隊往往是一上來就不加辨別地扎到某幾個豎井裡去尋找問題。這樣的區域性最佳化往往對全域性最佳化無效，還會影響團隊之間的關係，帶來負面效果。正確的做法應該是，先檢查全域性，找到關鍵瓶頸之後，再進入細節分析和解決的環節。具體實現起來，方法也很簡單，就是收集產品週期中每一個階段所佔用的時間，包括計劃的時間和最後實際花費的時間，然後尋找問題最大的地方。
針對個人研發效能作評價，可以採用類似 360 度績效考評的方式來收集同事之間的評價。評價的標準基於在使用者價值輸出上做出的貢獻，包括自身產生的價值，以及幫助團隊成員產生的使用者價值。下面列了一些可以用來收集反饋的問題，涵蓋開發效率、質量、團隊貢獻等方面。
作為管理者 / 內部效能團隊，應該關注開發人員的高頻活動，並自動化和最佳化這些步驟，讓開發人員能專注開發。
2）程式設計師聚焦開發
持續開發（不受阻塞的開發狀態）的基本原則主要包括兩條：
- 規範化、自動化核心步驟。根據團隊實際情況，找到合適的工具和配置進行這些檢查，並讓團隊成員統一使用。
- 快速反饋，增量開發。靈活使用各種 Linter 和測試；建設並最佳化沙盒環境；使用實時檢查工具。
3）高效協同
如何做到資訊流通，從而讓開發人員更順暢地生產出高價值的產品。總結來說，就是要從以下三個方面入手：
- 首先，從人入手，建設共享文化，鼓勵共享行為，使資訊共享與團隊成員利益一致，從而讓大家願意共享。
- 然後，在流程和工具方面，針對與研發相關的資訊，設計並實現對應程式碼、文件的共享，以及資訊在流水線上的自動化流動。
- 最後，在溝通技巧上下功夫，掌握高效溝通的原則，根據場景選擇合適的溝通方式和工具。
4）程式碼審查
程式碼審查的作用很多，主要表現在 5 個方面。
- 作用 1，儘早發現 Bug 和設計中存在的問題。
- 作用 2，提高個人工程能力。
- 作用 3，團隊知識共享。
- 作用 4，針對某個特定方面提高質量。
- 作用 5，統一編碼風格。
按照審查範圍，程式碼審查可以分為增量審查和全量審查兩類。
5）技術債
控制技術債主要有以下 4 步：
- 讓公司管理層意識到償還技術債的重要性，從而願意投入資源。
- 採用低成本的方式去預防。由於開發團隊的能力問題引入的技術債，可以使用加強計劃和程式碼審查等方法實現低成本的預防。
- 識別技術債並找到可能的解決方案。對於主動引入的技術債，可以在引入的時候就新增任務到 Backlog。而對於被動引入的技術債，則需要週期性的審視，這需要技術管理者主動地收集、整理技術債問題。
- 持續重構，解決高優先順序技術債。作為技術管理者，除了業務目標外，還要制定團隊的技術目標，來解決最重要、最緊急的技術債任務。
6）測試左移
向左擴充套件，就是讓測試介入程式碼提測之前的部分。比如，擴充套件到開發階段，在架構設計時就考慮產品的可測試性，並儘量進行開發自測等。另外，測試可以更進一步擴充套件到需求評審階段，讓測試人員不只是瞭解需求，更要評估需求的質量，比如分析需求的合理性以及完整性等。
要做好測試左移，有 3 個基本原則：
- 調整團隊對測試的態度。
- 把測試新增到開發和產品需求步驟中。
- 頻繁測試，快速測試。
7）效率心法
在實踐中被證明有效的 3 條原則，包括：
- 抽象和分而治之，這個拆分處理的過程，就是常說的分而治之；而用子系統來隱藏一個領域的內部細節，就是抽象。
- 快速迭代，不要過度計劃，儘量讓自己的程式碼能夠儘快執行起來。
- DRY（Don’t Repeat Yourself），程式碼邏輯的重複，不僅僅是工作量的浪費，還會大大降低程式碼的質量和可維護性。
8）深度工作
實現深度工作的辦法可以概括為以下三步：
- 以終為始，尋找並聚焦最重要的任務。
- 追根究底，尋找最高效的解決方案。
- 安排時間和精力，高效執行解決方案。
二、穩定性保障
1）穩定性指標
SRE（Site Reliability Engineering，網站可靠性工程） 是一套體系化的穩定性保障方法，下面是一張 SRE 框架圖。從職能分工上，SRE 體系的建設絕不是單個崗位或單個部門就能獨立完成的，必然要求有高效的跨團隊組織協作才可以。
從業界穩定性通用的衡量標準看，有兩個非常關鍵的指標：
- MTBF（Mean Time Between Failure），平均故障時間間隔。
- MTTR（Mean Time To Repair）， 故障平均修復時間。
通俗地說，MTBF 指示了系統正常執行的階段，而 MTTR 則意味著系統故障狀態的階段。如果想提升穩定性，就會有兩個方向：提升 MTBF，也就是減少故障發生次數，增加故障發生間隔時長；降低 MTTR，故障不可避免，那就提升故障處理效率，減少故障影響時長。
MTTR 可以細分為 4 個指標：MTTI、MTTK、MTTF 和 MTTV。
2）可用性指標
目前業界有兩種衡量系統可用性的方式，一個是時間維度，一個是請求維度，我們先來看這兩個維度的計算公式。
- 時間維度：Availability = Uptime / (Uptime + Downtime)
- 請求維度：Availability = Successful request / Total request
時長維度，是從故障角度出發對系統穩定性進行評估。可以用一系列的標準和判定邏輯來說明系統是否正常。比如，系統請求狀態碼為非 5xx 的比例，也就是請求成功率低於 95%，已經連續超過 10 分鐘，這時就要算作故障，那麼 10 分鐘就要納入 Downtime（當機時間），如果達不到這個標準，就不算作故障，只是算作一般或偶然的異常問題。
這裡有三個要素：衡量指標，系統請求狀態碼；衡量目標，非 5xx 佔比，也就是成功率達到 95%；影響時長，持續 10 分鐘。
因此，只有當問題達到一定影響程度才會算作故障，這時才會計算不可用時長，也就是上面公式中的 Downtime。同時，還要求一個週期內，允許的 Downtime，或者說是系統的“生病時間”是有限的，用這個有限時間來約束系統穩定性。下面是常見的按時長維度統計的可用性對照表：
這裡最顯著的問題就是，穩定性只與故障發生掛鉤。所以這種用時長維度來衡量系統穩定性的方式，其主要缺點就是粒度不夠精細。這些小的異常問題和它們的影響，如果從更長的週期來看，也是有一定參考價值的。這就需要第二種衡量方式了，也就是從請求維度來衡量系統可用性。
用一句話來說，請求維度，是從成功請求佔比的角度出發，對系統的穩定性進行評估。假定系統一天內有 10W 次請求，期望的成功率至少是 95%，如果有 5001 次請求失敗了，也就是成功率低於 95% 了，就認為系統執行狀態是不正常的。
請求維度的系統可用性同樣包含三個關鍵要素，第一個衡量指標，請求成功率；第二個衡量目標，成功率達到 95% 才算系統執行正常；第三個是統計週期，比如一天、一週、一個月等等，在一個統計週期內計算整體狀況，而不是看單次的。
到這裡，可以總結出一條至關重要的經驗：故障一定意味著不穩定，但是不穩定，並不意味著一定有故障發生。
3）On-Call機制
MTTR 細分為 4 個指標：MTTI、MTTK、MTTF 和 MTTV，之所以分組分塊，也是為了更加有目的性地做到系統穩定性。
在一個分散式的軟體系統下，判定一個問題發生在哪兒，影響範圍到底是怎麼樣的，要召集哪些人共同參與定位排查等等，這個會消耗更多時間，所以 MTTI 階段佔比會更重。
MTTI，就是故障的平均確認時間，也就是從故障實際發生時間點，到觸發採取實際行動去定位前的這段時間。這個環節其實主要有兩件事情要做：
- 第一件事，判斷出現的問題是不是故障。
- 第二件事，確定由誰來響應和召集。
第一件事其實主要依賴於監控和告警體系。這裡再強調一下，在 On-Call 階段，並不是所有的告警都要響應，如果不影響穩定性，一般的告警是可以降低響應級別的。第二件事往往容易被忽視，也就是 On-Call 的流程機制建設。
On-Call 關鍵 5 步法：
- 確保關鍵角色線上。這裡的關鍵角色不是指一兩個值班的運維或 SRE 人員，而是整個產品體系中的所有關鍵角色。
- 組織 War Room 應急組織。建立專門處理故障的“消防群”（暗含著滅火的意思），將關鍵角色納入其中。
- 建立合理的呼叫方式。建議使用固定的 On-Call 手機，建立手機與所有 On-Call 系統的對應關係，比如這個手機號碼對應交易核心應用，另一個號碼對應 IDC 機房運維等等。
- 確保資源投入的升級機制。要給到運維和 SRE 授權，當他發現問題不是自己或現有 On-Call 人員能解決的時候，他有權調動其他必要資源投入。
- 與雲廠商聯合的 On-Call。把雲產品和雲廠商作為系統的一部分，而不是單純的第三方。
4）恢復業務
在故障處理過程中採取的所有手段和行動，一切以恢復業務為最高優先順序。
當一個問題被定性為故障，這時就要成立 War Room，如果是在辦公時間，大家可以聚集到同一個會議室，或者同一塊辦公區域集中處理；如果是非辦公時間，可以是影片、電話或微信會議的方式，形成虛擬的 War Room。但無論是真實還是虛擬的 War Room，根本目的是快速同步資訊，高效協作。
有了角色分工，也明確了流程，那整個故障響應是否高效的關鍵就是溝通機制了。有時涉及的團隊和人員比較多，很多具體執行的同事就只顧悶頭定位和排查了，往往沒有任何反饋，甚至做了很多的操作也是自行決定，不做通報。這時就極有可能衍生故障或者導致故障更大範圍的蔓延，這是極為影響協作效率和決策的。
一般要求以團隊為單位，每隔 10～15 分鐘做一次反饋，反饋當前處理進展以及下一步 Action，如果中途有需要馬上執行什麼操作，也要事先通報，並且要求通報的內容包括對業務和系統的影響是什麼。
所以，除了要做好怎麼快速恢復業務，資訊同步的及時和透明也非常關鍵，並且有些安撫措施必須要快速執行到位。故障處理在一定程度上，就不單單是技術團隊的問題了，而是需要整個公司都投入資源的。
5）故障覆盤
在做故障覆盤的時候，首先會結合 Timeline 來做，也就是按照 MTTI、MTTK、MTTF 和 MTTV 先做一個分類；然後針對耗時長的環節，反覆討論改進措施是什麼；最後定好責任人和時間點，後續持續跟進執行狀況。如果把這些經驗再提煉一下，那就是總結出來的故障覆盤黃金三問：
- 第一問：故障原因有哪些？
- 第二問：怎麼做才能確保下次不會再出現類似故障？
- 第三問：當時如果做了什麼，是否可以用更短的時間恢復業務？
透過黃金三問，找到了故障發生的原因，也明確了做什麼可以最佳化，那接下來就是落地。要落地，就要明確到底應該由誰來承擔主要的改進職責。具體怎麼來做呢？最重要的就是下面這三條故障判定原則。
- 健壯性原則。這個原則是說每個部件自身要具備一定的自愈能力，比如主備、熔斷、限流、降級和重試等等。
- 第三方預設無責。例如公有云的各類服務，包括 IaaS、PaaS、CDN 以及影片等等。
- 分段判定原則。當發生衍生故障，或者故障蔓延的原因與觸發原因不同時，會將一次故障分段判斷。比如大促故障，前半段是由於模型評估不準，沒有故障隔離手段造成的，但是後半段，就是因為 DBA 的誤操作，以及流程機制不完善造成的。