谷歌提出的衡量 DevOps 質量的 DORA 指標讓 MTTR（平均恢復時間） 名聲大振。在本文中，你將了解到 MTTR 的作用、為什么它對行業(yè)研究很有用、你可能被它誤導的原因以及如何避免 MTTR 產生的弊端。
?
MTTR 究竟是在測量什么？
MTTR 指平均恢復時間，既是 Mean Time to Recovery，有時也是 Mean Time to Restore。它是指在發(fā)生故障后使系統(tǒng)恢復運行所需的時間，它是 DORA 指標的一部分，目前已經成為軟件交付性能的標準。
?
當你的所有 DORA 指標都表現(xiàn)良好，那么就會擁有快速交付的高質量軟件、更滿意的員工，從而在所處的行業(yè)中取得競爭優(yōu)勢。
?
如何計算 MTTR
收集 MTTR 需要收集每個故障從開始到結束的持續(xù)時間，然后將這些時間相加，并用總數(shù)除以數(shù)量。一些團隊會對所有事件進行排序，并選擇中間值來計算恢復時間的中位數(shù)。
?
軟件交付過程會影響恢復時間，尤其是：
- 軟件架構
- 文檔
- 可觀測性
- 部署流水線性能
?
當你可以快速恢復，事件的影響就會降低，客戶也會更滿意。因此，企業(yè)應該檢查和調整流程以快速恢復并降低風險。
?
為什么 MTTR 對行業(yè)研究很有用？
DevOps 研究和評估（DORA）將調查作為研究方法的一部分。需要各類數(shù)據(jù)和性能水平不同的企業(yè)對問題進行回答。DORA quick check 將 MTTR 問題表述為：
?
對于您開發(fā)的主要應用程序或服務，當發(fā)生影響用戶的服務事件或故障（例如，計劃外中斷、服務受損）時，通常需要多長時間才能恢復服務？
- 超過6個月
- 1-6個月之間
- 1周到1個月之間
- 1天到1周之間
- 小于1天
- 小于1個小時
?
大多數(shù)從事軟件交付工作的人對故障持續(xù)時間都有大概的感覺，因此在調查中使用寬泛的選項可以讓人們很容易選擇答案。研究人員利用這些信息來尋找數(shù)據(jù)中的性能組，他們還尋找各種實踐之間的關系以及對業(yè)務成果的影響，并利用這些發(fā)現(xiàn)搭建 DevOps 結構方程模型。
?
為什么 MTTR 數(shù)據(jù)可能誤導你的團隊？
雖然 MTTR 在研究中對性能組有幫助，但這并不是你在團隊中使用故障信息的方式。你應該利用這些信息從服務中斷中學習，并改進今后的處理方式。最終目標并不是與其他團隊或組織進行攀比。
?
如果要持續(xù)優(yōu)化軟件開發(fā)和交付流程，只關注平均數(shù)可能忽略了一些重要信號。因此需要更細化的信息來了解故障處理的情況，并找到其原因。
?
Verica 事件數(shù)據(jù)庫（VOID）包含了由近600個組織共享的超過10000個事件，他們在 VOID 報告中分析了這些事件。在2022年的報告中對 MTTR 做出如下評論：
?
MTTR 不是衡量復雜軟件系統(tǒng)可靠性的可行指標，原因有很多，其中突出的原因是其存在潛在的差異性。
?
當數(shù)據(jù)量很大時，平均數(shù)所帶來的差異性會變得平緩，但一般而言企業(yè)的故障頻率不太可能會達到每月數(shù)千起（即在這個數(shù)量級才使平均數(shù)有效）。如果事件數(shù)量較少，平均數(shù)則成為一個不穩(wěn)定的指標。甚至盡管在事件管理方面有所改進，但平均數(shù)依舊在增加。
?
VOID 數(shù)據(jù)庫還發(fā)現(xiàn)，大多數(shù)事件在2小時內得到解決，但存在一些長尾數(shù)據(jù)導致平均值被推高或推低，進而無法代表客戶看待系統(tǒng)可靠性的方式。
?
組織可以通過排除異常值來消除這種差異性，但那樣就會隱藏一些有價值的信息。因此需要一個更好的方法使用這些數(shù)據(jù)來改善整個流程。
?
恢復時長的用武之地
與其把事件恢復時間壓縮成一個平均數(shù)，不如把每個持續(xù)時間繪制在圖表上。使用散點圖或箱線圖（Box-and-whisker chart），在不失真實性的情況下將持續(xù)時間可視化。這可以顯示趨勢和異常值，這比平均數(shù)更有價值。
?
?
你現(xiàn)在可以清晰地了解修復時長的趨勢，看看是否隨著時間的推移而改善。還可以識別出異常值，并充分討論如何更好地處理它們，進而利用它們來改善事件管理和系統(tǒng)穩(wěn)定性。
?
如果事件需要代碼修復，恢復時間取決于部署流水線的性能。能夠快速、安全地部署軟件新版本也有助于進行事件管理。另外，引入監(jiān)控和告警工具有助于幫助企業(yè)在影響客戶之前發(fā)現(xiàn)問題。
?
明確事件的定義
要獲取大部分事件持續(xù)時間的數(shù)據(jù)，你需要對此有統(tǒng)一的定義：
- 什么是事件
- 什么是開始時間
- 什么是結束時間
?
對于事件，企業(yè)內部需要有一個清晰、一致的定義。它應該包括當系統(tǒng)可以優(yōu)雅地處理一個故障時，組織是否將其算作一個事件。例如，團隊可以認為只有對客戶產生影響的故障才是事件。
?
對于開始時間和結束時間也是一樣的。是在導致事件發(fā)生的條件首次出現(xiàn)時開始計時，還是在問題對客戶可見時開始計時？根據(jù)定義，甚至可能出現(xiàn)負的事件持續(xù)時間，即在故障影響到客戶之前就解決了它。
?
就事件的定義和如何衡量其持續(xù)時間達成一致，使你的衡量標準更具可比性。當長期使用 DORA 指標時，它們可能不再能激發(fā)你進行下一步改進。你可以用 SPACE 框架設計一個新的衡量系統(tǒng)。
?
使用 SPACE 框架來衡量事件響應
你可以通過 SPACE 框架來全面了解事件響應和管理，其將測量結果分為5個類別：
- 滿意度和幸福感（Satisfaction and wellbeing）
- 表現(xiàn)（Performance）
- 活躍度（Activity）
- 溝通與協(xié)作（Communication and collaboration）
- 效率與流程（Efficiency and flow）
?
企業(yè)不必一次性采用所有指標。SPACE 框架建議至少在3個維度上進行測量，如果能涵蓋個人、團隊和系統(tǒng)層面則更好。最終目標是建議一套合理的測量方法來幫助企業(yè)改進流程。
?
滿意度和幸福感
定性調查在這里最有效，可以調查事件管理者，看他們對事件發(fā)生后恢復的滿意程度：
- 事件管理流程
- On-call 排期
- 在事件發(fā)生期間升級或訪問專家以提供幫助的難易程度
?
還可以去查看相關數(shù)據(jù)以確定 On-call 排期的合理性：
- 當?shù)貢r間幾點電話響起
?
表現(xiàn)
使用以下指標可以衡量事件管理表現(xiàn)：
- 系統(tǒng)是否按照其可靠性目標執(zhí)行
- 事故條件和察覺到事故發(fā)生之前的時長
- 解決事故所需的時間
?
活躍度
事件活躍度并不僅僅是事件數(shù)量，其他指標也可以納入?yún)⒖肌４蟛糠謹?shù)據(jù)其實已經在你的現(xiàn)有系統(tǒng)之中：
- 監(jiān)控工具發(fā)出的告警數(shù)量
- 事件發(fā)生的數(shù)量
- 同時發(fā)生事件的數(shù)量
?
溝通與協(xié)作
信息透明對事件管理至關重要。你應該把這個維度納入事件測量策略中。擁有高質量的溝通將減少解決故障所需的時間，可以衡量以下指標：
- 每個事件所牽涉的人員數(shù)量
- 每個事件涉及多少個不同的團隊
- 為處理一個事件建群的數(shù)量
- 查看事件報告的次數(shù)（或給予積極評價，或在其他事件中提到它）
?
效率及流程
當采用效率和流程的指標時，就會發(fā)現(xiàn)系統(tǒng)中的浪費。如果反復“踢皮球”，那么處理事件的進度就會停滯不前，解決時間更長。以下指標可以幫你發(fā)現(xiàn)瘟疫：
- 重新分配事件的頻率
- 每個事件嘗試緩解的次數(shù)
?
SPACE 框架總結
當需要獲得各種洞察并改進系統(tǒng)時，團隊應該自由構建并根據(jù)實際情況調整指標。企業(yè)可能會發(fā)現(xiàn)從滿意度、溝通和效率這3類指標開始是有幫助的，因為通過測量這些指標并對相關情況進行優(yōu)化會帶來立竿見影的效果。
?
如果你已經對客戶進行調查，不妨問問他們如何為你的系統(tǒng)可靠性評分。
?
SPACE 框架提供了一種構建衡量體系的方法，它可以直接對事件管理產生影響。
?
不囿于數(shù)字，解決問題才是硬道理
衡量相關指標可以通過明確的數(shù)據(jù)來幫助團隊做出調整。如果沒有數(shù)字，可能會把一個實際發(fā)生很頻繁的事件當作一次性事件處理。
?
盡管數(shù)字發(fā)揮了作用，但它們只能告訴你問題所在，而無法解決它。因此，不要囿于數(shù)字，充分利用事件復盤和 review 來研究如何優(yōu)化企業(yè)中的事件管理。
?
數(shù)字并不能推動持續(xù)改進，但它可以消除討論中的偏見和邏輯謬誤，以幫助團隊處理好眼前的現(xiàn)實問題。
?
團隊應該形成在事件發(fā)生后立刻對其進行復盤，以防止回歸到日常工作之后缺少了上下文環(huán)境而無法正確分析出事件發(fā)生的原因。
?
對于根本原因的分析要謹慎，因為軟件系統(tǒng)發(fā)生事故很少只有單一的原因，它通常是幾個因素共同促成的。根本原因分析側重于最接近事件的人，而不是更廣泛的系統(tǒng)性問題。另外，需要進行事件后的 review，詳細說明發(fā)生的一切以及您為減輕和解決它所做的工作。
?
事件復盤的成果可以提供給處理未來事件的人使用，有助于縮短解決時間。
?
安全是吸取事故教訓的能力，而不是沒有故障，事故復盤是最佳的學習機會。
—— Adrian Cockcroft
?
導致事故發(fā)生的原因從來不是單個員工，而是整個工作系統(tǒng)。如果有人登錄服務器，不小心選擇了“關閉”而不是“登出”導致服務器關閉，這本質上是系統(tǒng)的故障——為什么不隱藏“關閉”選項？為什么他們需要直接訪問服務器？我們可以用 runbook 來做這個嗎？
?
定期 review 來復盤最近的事件，可以在冷靜理智的情況下找到模式并思考改進方式。從事件中學習比圍繞恢復時間制定目標更重要。
?文章來源：http://www.zghlxwxcb.cn/news/detail-464233.html
參考鏈接：
https://octopus.com/blog/how-to-measure-mean-time-to-resolve文章來源地址http://www.zghlxwxcb.cn/news/detail-464233.html
到了這里，關于如何科學地利用MTTR優(yōu)化軟件交付流程？的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
