谷歌提出的衡量 DevOps 質(zhì)量的 DORA 指標(biāo)讓 MTTR（平均恢復(fù)時(shí)間） 名聲大振。在本文中，你將了解到 MTTR 的作用、為什么它對(duì)行業(yè)研究很有用、你可能被它誤導(dǎo)的原因以及如何避免 MTTR 產(chǎn)生的弊端。
?

MTTR 究竟是在測(cè)量什么？

MTTR 指平均恢復(fù)時(shí)間，既是 Mean Time to Recovery，有時(shí)也是 Mean Time to Restore。它是指在發(fā)生故障后使系統(tǒng)恢復(fù)運(yùn)行所需的時(shí)間，它是 DORA 指標(biāo)的一部分，目前已經(jīng)成為軟件交付性能的標(biāo)準(zhǔn)。
?

當(dāng)你的所有 DORA 指標(biāo)都表現(xiàn)良好，那么就會(huì)擁有快速交付的高質(zhì)量軟件、更滿(mǎn)意的員工，從而在所處的行業(yè)中取得競(jìng)爭(zhēng)優(yōu)勢(shì)。
?

如何計(jì)算 MTTR

收集 MTTR 需要收集每個(gè)故障從開(kāi)始到結(jié)束的持續(xù)時(shí)間，然后將這些時(shí)間相加，并用總數(shù)除以數(shù)量。一些團(tuán)隊(duì)會(huì)對(duì)所有事件進(jìn)行排序，并選擇中間值來(lái)計(jì)算恢復(fù)時(shí)間的中位數(shù)。
?

軟件交付過(guò)程會(huì)影響恢復(fù)時(shí)間，尤其是：

• 軟件架構(gòu)

• 文檔

• 可觀測(cè)性

• 部署流水線(xiàn)性能
  ?

當(dāng)你可以快速恢復(fù)，事件的影響就會(huì)降低，客戶(hù)也會(huì)更滿(mǎn)意。因此，企業(yè)應(yīng)該檢查和調(diào)整流程以快速恢復(fù)并降低風(fēng)險(xiǎn)。
?

為什么 MTTR 對(duì)行業(yè)研究很有用？

DevOps 研究和評(píng)估（DORA）將調(diào)查作為研究方法的一部分。需要各類(lèi)數(shù)據(jù)和性能水平不同的企業(yè)對(duì)問(wèn)題進(jìn)行回答。DORA quick check 將 MTTR 問(wèn)題表述為：
?

對(duì)于您開(kāi)發(fā)的主要應(yīng)用程序或服務(wù)，當(dāng)發(fā)生影響用戶(hù)的服務(wù)事件或故障（例如，計(jì)劃外中斷、服務(wù)受損）時(shí)，通常需要多長(zhǎng)時(shí)間才能恢復(fù)服務(wù)？

• 超過(guò)6個(gè)月

• 1-6個(gè)月之間

• 1周到1個(gè)月之間

• 1天到1周之間

• 小于1天

• 小于1個(gè)小時(shí)

?
大多數(shù)從事軟件交付工作的人對(duì)故障持續(xù)時(shí)間都有大概的感覺(jué)，因此在調(diào)查中使用寬泛的選項(xiàng)可以讓人們很容易選擇答案。研究人員利用這些信息來(lái)尋找數(shù)據(jù)中的性能組，他們還尋找各種實(shí)踐之間的關(guān)系以及對(duì)業(yè)務(wù)成果的影響，并利用這些發(fā)現(xiàn)搭建 DevOps 結(jié)構(gòu)方程模型。
?

為什么 MTTR 數(shù)據(jù)可能誤導(dǎo)你的團(tuán)隊(duì)？

雖然 MTTR 在研究中對(duì)性能組有幫助，但這并不是你在團(tuán)隊(duì)中使用故障信息的方式。你應(yīng)該利用這些信息從服務(wù)中斷中學(xué)習(xí)，并改進(jìn)今后的處理方式。最終目標(biāo)并不是與其他團(tuán)隊(duì)或組織進(jìn)行攀比。
?

如果要持續(xù)優(yōu)化軟件開(kāi)發(fā)和交付流程，只關(guān)注平均數(shù)可能忽略了一些重要信號(hào)。因此需要更細(xì)化的信息來(lái)了解故障處理的情況，并找到其原因。
?

Verica 事件數(shù)據(jù)庫(kù)（VOID）包含了由近600個(gè)組織共享的超過(guò)10000個(gè)事件，他們?cè)?VOID 報(bào)告中分析了這些事件。在2022年的報(bào)告中對(duì) MTTR 做出如下評(píng)論：
?

MTTR 不是衡量復(fù)雜軟件系統(tǒng)可靠性的可行指標(biāo)，原因有很多，其中突出的原因是其存在潛在的差異性。

?

當(dāng)數(shù)據(jù)量很大時(shí)，平均數(shù)所帶來(lái)的差異性會(huì)變得平緩，但一般而言企業(yè)的故障頻率不太可能會(huì)達(dá)到每月數(shù)千起（即在這個(gè)數(shù)量級(jí)才使平均數(shù)有效）。如果事件數(shù)量較少，平均數(shù)則成為一個(gè)不穩(wěn)定的指標(biāo)。甚至盡管在事件管理方面有所改進(jìn)，但平均數(shù)依舊在增加。
?

VOID 數(shù)據(jù)庫(kù)還發(fā)現(xiàn)，大多數(shù)事件在2小時(shí)內(nèi)得到解決，但存在一些長(zhǎng)尾數(shù)據(jù)導(dǎo)致平均值被推高或推低，進(jìn)而無(wú)法代表客戶(hù)看待系統(tǒng)可靠性的方式。
?

組織可以通過(guò)排除異常值來(lái)消除這種差異性，但那樣就會(huì)隱藏一些有價(jià)值的信息。因此需要一個(gè)更好的方法使用這些數(shù)據(jù)來(lái)改善整個(gè)流程。
?

恢復(fù)時(shí)長(zhǎng)的用武之地

與其把事件恢復(fù)時(shí)間壓縮成一個(gè)平均數(shù)，不如把每個(gè)持續(xù)時(shí)間繪制在圖表上。使用散點(diǎn)圖或箱線(xiàn)圖（Box-and-whisker chart），在不失真實(shí)性的情況下將持續(xù)時(shí)間可視化。這可以顯示趨勢(shì)和異常值，這比平均數(shù)更有價(jià)值。
?

你現(xiàn)在可以清晰地了解修復(fù)時(shí)長(zhǎng)的趨勢(shì)，看看是否隨著時(shí)間的推移而改善。還可以識(shí)別出異常值，并充分討論如何更好地處理它們，進(jìn)而利用它們來(lái)改善事件管理和系統(tǒng)穩(wěn)定性。
?

如果事件需要代碼修復(fù)，恢復(fù)時(shí)間取決于部署流水線(xiàn)的性能。能夠快速、安全地部署軟件新版本也有助于進(jìn)行事件管理。另外，引入監(jiān)控和告警工具有助于幫助企業(yè)在影響客戶(hù)之前發(fā)現(xiàn)問(wèn)題。
?

明確事件的定義

要獲取大部分事件持續(xù)時(shí)間的數(shù)據(jù)，你需要對(duì)此有統(tǒng)一的定義：

• 什么是事件

• 什么是開(kāi)始時(shí)間

• 什么是結(jié)束時(shí)間
  ?

對(duì)于事件，企業(yè)內(nèi)部需要有一個(gè)清晰、一致的定義。它應(yīng)該包括當(dāng)系統(tǒng)可以?xún)?yōu)雅地處理一個(gè)故障時(shí)，組織是否將其算作一個(gè)事件。例如，團(tuán)隊(duì)可以認(rèn)為只有對(duì)客戶(hù)產(chǎn)生影響的故障才是事件。
?

對(duì)于開(kāi)始時(shí)間和結(jié)束時(shí)間也是一樣的。是在導(dǎo)致事件發(fā)生的條件首次出現(xiàn)時(shí)開(kāi)始計(jì)時(shí)，還是在問(wèn)題對(duì)客戶(hù)可見(jiàn)時(shí)開(kāi)始計(jì)時(shí)？根據(jù)定義，甚至可能出現(xiàn)負(fù)的事件持續(xù)時(shí)間，即在故障影響到客戶(hù)之前就解決了它。
?

就事件的定義和如何衡量其持續(xù)時(shí)間達(dá)成一致，使你的衡量標(biāo)準(zhǔn)更具可比性。當(dāng)長(zhǎng)期使用 DORA 指標(biāo)時(shí)，它們可能不再能激發(fā)你進(jìn)行下一步改進(jìn)。你可以用 SPACE 框架設(shè)計(jì)一個(gè)新的衡量系統(tǒng)。
?

使用 SPACE 框架來(lái)衡量事件響應(yīng)

你可以通過(guò) SPACE 框架來(lái)全面了解事件響應(yīng)和管理，其將測(cè)量結(jié)果分為5個(gè)類(lèi)別：

• 滿(mǎn)意度和幸福感（Satisfaction and wellbeing）

• 表現(xiàn)（Performance）

• 活躍度（Activity）

• 溝通與協(xié)作（Communication and collaboration）

• 效率與流程（Efficiency and flow）
  ?

企業(yè)不必一次性采用所有指標(biāo)。SPACE 框架建議至少在3個(gè)維度上進(jìn)行測(cè)量，如果能涵蓋個(gè)人、團(tuán)隊(duì)和系統(tǒng)層面則更好。最終目標(biāo)是建議一套合理的測(cè)量方法來(lái)幫助企業(yè)改進(jìn)流程。
?

滿(mǎn)意度和幸福感

定性調(diào)查在這里最有效，可以調(diào)查事件管理者，看他們對(duì)事件發(fā)生后恢復(fù)的滿(mǎn)意程度：

• 事件管理流程

• On-call 排期

• 在事件發(fā)生期間升級(jí)或訪(fǎng)問(wèn)專(zhuān)家以提供幫助的難易程度
  ?

還可以去查看相關(guān)數(shù)據(jù)以確定 On-call 排期的合理性：

• 當(dāng)?shù)貢r(shí)間幾點(diǎn)電話(huà)響起
  ?

表現(xiàn)

使用以下指標(biāo)可以衡量事件管理表現(xiàn)：

• 系統(tǒng)是否按照其可靠性目標(biāo)執(zhí)行

• 事故條件和察覺(jué)到事故發(fā)生之前的時(shí)長(zhǎng)

• 解決事故所需的時(shí)間
  ?

活躍度

事件活躍度并不僅僅是事件數(shù)量，其他指標(biāo)也可以納入?yún)⒖肌４蟛糠謹(jǐn)?shù)據(jù)其實(shí)已經(jīng)在你的現(xiàn)有系統(tǒng)之中：

• 監(jiān)控工具發(fā)出的告警數(shù)量

• 事件發(fā)生的數(shù)量

• 同時(shí)發(fā)生事件的數(shù)量
  ?

溝通與協(xié)作

信息透明對(duì)事件管理至關(guān)重要。你應(yīng)該把這個(gè)維度納入事件測(cè)量策略中。擁有高質(zhì)量的溝通將減少解決故障所需的時(shí)間，可以衡量以下指標(biāo)：

• 每個(gè)事件所牽涉的人員數(shù)量

• 每個(gè)事件涉及多少個(gè)不同的團(tuán)隊(duì)

• 為處理一個(gè)事件建群的數(shù)量

• 查看事件報(bào)告的次數(shù)（或給予積極評(píng)價(jià)，或在其他事件中提到它）
  ?

效率及流程

當(dāng)采用效率和流程的指標(biāo)時(shí)，就會(huì)發(fā)現(xiàn)系統(tǒng)中的浪費(fèi)。如果反復(fù)“踢皮球”，那么處理事件的進(jìn)度就會(huì)停滯不前，解決時(shí)間更長(zhǎng)。以下指標(biāo)可以幫你發(fā)現(xiàn)瘟疫：

• 重新分配事件的頻率

• 每個(gè)事件嘗試緩解的次數(shù)
  ?

SPACE 框架總結(jié)

當(dāng)需要獲得各種洞察并改進(jìn)系統(tǒng)時(shí)，團(tuán)隊(duì)?wèi)?yīng)該自由構(gòu)建并根據(jù)實(shí)際情況調(diào)整指標(biāo)。企業(yè)可能會(huì)發(fā)現(xiàn)從滿(mǎn)意度、溝通和效率這3類(lèi)指標(biāo)開(kāi)始是有幫助的，因?yàn)橥ㄟ^(guò)測(cè)量這些指標(biāo)并對(duì)相關(guān)情況進(jìn)行優(yōu)化會(huì)帶來(lái)立竿見(jiàn)影的效果。
?

如果你已經(jīng)對(duì)客戶(hù)進(jìn)行調(diào)查，不妨問(wèn)問(wèn)他們?nèi)绾螢槟愕南到y(tǒng)可靠性評(píng)分。
?

SPACE 框架提供了一種構(gòu)建衡量體系的方法，它可以直接對(duì)事件管理產(chǎn)生影響。
?

不囿于數(shù)字，解決問(wèn)題才是硬道理

衡量相關(guān)指標(biāo)可以通過(guò)明確的數(shù)據(jù)來(lái)幫助團(tuán)隊(duì)做出調(diào)整。如果沒(méi)有數(shù)字，可能會(huì)把一個(gè)實(shí)際發(fā)生很頻繁的事件當(dāng)作一次性事件處理。
?

盡管數(shù)字發(fā)揮了作用，但它們只能告訴你問(wèn)題所在，而無(wú)法解決它。因此，不要囿于數(shù)字，充分利用事件復(fù)盤(pán)和 review 來(lái)研究如何優(yōu)化企業(yè)中的事件管理。
?

數(shù)字并不能推動(dòng)持續(xù)改進(jìn)，但它可以消除討論中的偏見(jiàn)和邏輯謬誤，以幫助團(tuán)隊(duì)處理好眼前的現(xiàn)實(shí)問(wèn)題。
?

團(tuán)隊(duì)?wèi)?yīng)該形成在事件發(fā)生后立刻對(duì)其進(jìn)行復(fù)盤(pán)，以防止回歸到日常工作之后缺少了上下文環(huán)境而無(wú)法正確分析出事件發(fā)生的原因。
?

對(duì)于根本原因的分析要謹(jǐn)慎，因?yàn)檐浖到y(tǒng)發(fā)生事故很少只有單一的原因，它通常是幾個(gè)因素共同促成的。根本原因分析側(cè)重于最接近事件的人，而不是更廣泛的系統(tǒng)性問(wèn)題。另外，需要進(jìn)行事件后的 review，詳細(xì)說(shuō)明發(fā)生的一切以及您為減輕和解決它所做的工作。
?

事件復(fù)盤(pán)的成果可以提供給處理未來(lái)事件的人使用，有助于縮短解決時(shí)間。
?

安全是吸取事故教訓(xùn)的能力，而不是沒(méi)有故障，事故復(fù)盤(pán)是最佳的學(xué)習(xí)機(jī)會(huì)。
—— Adrian Cockcroft

?
導(dǎo)致事故發(fā)生的原因從來(lái)不是單個(gè)員工，而是整個(gè)工作系統(tǒng)。如果有人登錄服務(wù)器，不小心選擇了“關(guān)閉”而不是“登出”導(dǎo)致服務(wù)器關(guān)閉，這本質(zhì)上是系統(tǒng)的故障——為什么不隱藏“關(guān)閉”選項(xiàng)？為什么他們需要直接訪(fǎng)問(wèn)服務(wù)器？我們可以用 runbook 來(lái)做這個(gè)嗎？
?

定期 review 來(lái)復(fù)盤(pán)最近的事件，可以在冷靜理智的情況下找到模式并思考改進(jìn)方式。從事件中學(xué)習(xí)比圍繞恢復(fù)時(shí)間制定目標(biāo)更重要。
?

參考鏈接：
https://octopus.com/blog/how-to-measure-mean-time-to-resolve