研發效能與穩定性保障

咖啡机(K.F.J)發表於2024-05-06

  研發效能參考課程《研發效率破局之道》,穩定性保障參考《SRE實戰手冊》。

一、研發效能

1)效能度量

  推薦從團隊和個人這兩個維度對度量指標進行分類,其中團隊維度中又分為速度、準確度和質量 3 類,所以一共是 4 類。

  • 速度:天下武功,唯快不破,速度指標主要用來衡量團隊研發產品的速率。比如,前置時間,從任務產生到交付的時長。
  • 準確度:關注產品是否跟計劃吻合,跟使用者需求吻合,能否提供較大的使用者價值。一個例子是功能的採納率,也就是有百分之多少的使用者使用了功能 x。
  • 質量:如果質量有問題,產品的商業價值會被大打折扣。質量包括產品的效能、功能、可靠性、安全等方面。
  • 個人效能:個人開發過程中的效率指標,比如開發環境生成速度、本地構建速度等。

  總結了一張導圖,展示了這 4 個方面的度量指標,供參考。可以看到,一共給出了 40 多個指標。

  研發效能與穩定性保障

  提供使用者價值是公司存在的根本,因此與之相關的指標是最重要的。這一點非常好理解。從這個角度來看,以下幾個相關度量指標比較有效:

  1. 淨推薦值 (Net Promoter Score,NPS),是透過調研瞭解使用者滿意度,實用性很強。
  2. 系統 /App 當機時間 (System/App Downtime) 和嚴重線上事故數 (Incidents),衡量的是系統的可用性,通常與使用者價值直接掛鉤。
  3. 熱修復上線時間 (Hotfix Time),指的是從編碼完成到部署到生產的時長,關係到解決重大缺陷的效率,與使用者價值強相關。

  在度量效能時,很多團隊往往是一上來就不加辨別地扎到某幾個豎井裡去尋找問題。這樣的區域性最佳化往往對全域性最佳化無效,還會影響團隊之間的關係,帶來負面效果。正確的做法應該是,先檢查全域性,找到關鍵瓶頸之後,再進入細節分析和解決的環節。具體實現起來,方法也很簡單,就是收集產品週期中每一個階段所佔用的時間,包括計劃的時間和最後實際花費的時間,然後尋找問題最大的地方。

  針對個人研發效能作評價,可以採用類似 360 度績效考評的方式來收集同事之間的評價。評價的標準基於在使用者價值輸出上做出的貢獻,包括自身產生的價值,以及幫助團隊成員產生的使用者價值。下面列了一些可以用來收集反饋的問題,涵蓋開發效率、質量、團隊貢獻等方面。

  研發效能與穩定性保障

  作為管理者 / 內部效能團隊,應該關注開發人員的高頻活動,並自動化和最佳化這些步驟,讓開發人員能專注開發。

2)程式設計師聚焦開發

  持續開發(不受阻塞的開發狀態)的基本原則主要包括兩條:

  • 規範化、自動化核心步驟。根據團隊實際情況,找到合適的工具和配置進行這些檢查,並讓團隊成員統一使用。
  • 快速反饋,增量開發。靈活使用各種 Linter 和測試;建設並最佳化沙盒環境;使用實時檢查工具。

3)高效協同

  如何做到資訊流通,從而讓開發人員更順暢地生產出高價值的產品。總結來說,就是要從以下三個方面入手:

  • 首先,從人入手,建設共享文化,鼓勵共享行為,使資訊共享與團隊成員利益一致,從而讓大家願意共享。
  • 然後,在流程和工具方面,針對與研發相關的資訊,設計並實現對應程式碼、文件的共享,以及資訊在流水線上的自動化流動。
  • 最後,在溝通技巧上下功夫,掌握高效溝通的原則,根據場景選擇合適的溝通方式和工具。

4)程式碼審查

  程式碼審查的作用很多,主要表現在 5 個方面。

  • 作用 1,儘早發現 Bug 和設計中存在的問題。
  • 作用 2,提高個人工程能力。
  • 作用 3,團隊知識共享。
  • 作用 4,針對某個特定方面提高質量。
  • 作用 5,統一編碼風格。

  按照審查範圍,程式碼審查可以分為增量審查和全量審查兩類。

5)技術債

  控制技術債主要有以下 4 步:

  • 讓公司管理層意識到償還技術債的重要性,從而願意投入資源。
  • 採用低成本的方式去預防。由於開發團隊的能力問題引入的技術債,可以使用加強計劃和程式碼審查等方法實現低成本的預防。
  • 識別技術債並找到可能的解決方案。對於主動引入的技術債,可以在引入的時候就新增任務到 Backlog。而對於被動引入的技術債,則需要週期性的審視,這需要技術管理者主動地收集、整理技術債問題。
  • 持續重構,解決高優先順序技術債。作為技術管理者,除了業務目標外,還要制定團隊的技術目標,來解決最重要、最緊急的技術債任務。

6)測試左移

  向左擴充套件,就是讓測試介入程式碼提測之前的部分。比如,擴充套件到開發階段,在架構設計時就考慮產品的可測試性,並儘量進行開發自測等。另外,測試可以更進一步擴充套件到需求評審階段,讓測試人員不只是瞭解需求,更要評估需求的質量,比如分析需求的合理性以及完整性等。

  要做好測試左移,有 3 個基本原則:

  • 調整團隊對測試的態度。
  • 把測試新增到開發和產品需求步驟中。
  • 頻繁測試,快速測試。

7)效率心法

  在實踐中被證明有效的 3 條原則,包括:

  1. 抽象和分而治之,這個拆分處理的過程,就是常說的分而治之;而用子系統來隱藏一個領域的內部細節,就是抽象。
  2. 快速迭代,不要過度計劃,儘量讓自己的程式碼能夠儘快執行起來。
  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)可用性指標

  目前業界有兩種衡量系統可用性的方式,一個是時間維度,一個是請求維度,我們先來看這兩個維度的計算公式。

  1. 時間維度:Availability = Uptime / (Uptime + Downtime)
  2. 請求維度: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 步法:

  1. 確保關鍵角色線上。這裡的關鍵角色不是指一兩個值班的運維或 SRE 人員,而是整個產品體系中的所有關鍵角色。
  2. 組織 War Room 應急組織。建立專門處理故障的“消防群”(暗含著滅火的意思),將關鍵角色納入其中。
  3. 建立合理的呼叫方式。建議使用固定的 On-Call 手機,建立手機與所有 On-Call 系統的對應關係,比如這個手機號碼對應交易核心應用,另一個號碼對應 IDC 機房運維等等。
  4. 確保資源投入的升級機制。要給到運維和 SRE 授權,當他發現問題不是自己或現有 On-Call 人員能解決的時候,他有權調動其他必要資源投入。
  5. 與雲廠商聯合的 On-Call。把雲產品和雲廠商作為系統的一部分,而不是單純的第三方。

4)恢復業務

  在故障處理過程中採取的所有手段和行動,一切以恢復業務為最高優先順序。

  當一個問題被定性為故障,這時就要成立 War Room,如果是在辦公時間,大家可以聚集到同一個會議室,或者同一塊辦公區域集中處理;如果是非辦公時間,可以是影片、電話或微信會議的方式,形成虛擬的 War Room。但無論是真實還是虛擬的 War Room,根本目的是快速同步資訊,高效協作。

  有了角色分工,也明確了流程,那整個故障響應是否高效的關鍵就是溝通機制了。有時涉及的團隊和人員比較多,很多具體執行的同事就只顧悶頭定位和排查了,往往沒有任何反饋,甚至做了很多的操作也是自行決定,不做通報。這時就極有可能衍生故障或者導致故障更大範圍的蔓延,這是極為影響協作效率和決策的。

  一般要求以團隊為單位,每隔 10~15 分鐘做一次反饋,反饋當前處理進展以及下一步 Action,如果中途有需要馬上執行什麼操作,也要事先通報,並且要求通報的內容包括對業務和系統的影響是什麼。
所以,除了要做好怎麼快速恢復業務,資訊同步的及時和透明也非常關鍵,並且有些安撫措施必須要快速執行到位。故障處理在一定程度上,就不單單是技術團隊的問題了,而是需要整個公司都投入資源的。

5)故障覆盤

  在做故障覆盤的時候,首先會結合 Timeline 來做,也就是按照 MTTI、MTTK、MTTF 和 MTTV 先做一個分類;然後針對耗時長的環節,反覆討論改進措施是什麼;最後定好責任人和時間點,後續持續跟進執行狀況。如果把這些經驗再提煉一下,那就是總結出來的故障覆盤黃金三問:

  • 第一問:故障原因有哪些?
  • 第二問:怎麼做才能確保下次不會再出現類似故障?
  • 第三問:當時如果做了什麼,是否可以用更短的時間恢復業務?

  透過黃金三問,找到了故障發生的原因,也明確了做什麼可以最佳化,那接下來就是落地。要落地,就要明確到底應該由誰來承擔主要的改進職責。具體怎麼來做呢?最重要的就是下面這三條故障判定原則。

  1. 健壯性原則。這個原則是說每個部件自身要具備一定的自愈能力,比如主備、熔斷、限流、降級和重試等等。
  2. 第三方預設無責。例如公有云的各類服務,包括 IaaS、PaaS、CDN 以及影片等等。
  3. 分段判定原則。當發生衍生故障,或者故障蔓延的原因與觸發原因不同時,會將一次故障分段判斷。比如大促故障,前半段是由於模型評估不準,沒有故障隔離手段造成的,但是後半段,就是因為 DBA 的誤操作,以及流程機制不完善造成的。

相關文章