2009 年，受 John Allspaw 和 Paul Hammonds 在 Velocity 上演講的啟發(fā)，Patrick Debois 組織了一次名為“DevOps Days”的會議。早期，公眾對 DevOps 持有褒貶不一的看法且大部分企業(yè)高層人員對其并不重視。DevOps 本應(yīng)將技術(shù)人員們團(tuán)結(jié)在一起，卻難以定義，更難以衡量，因此很難提出令人信服的支持或反對理由。在這篇文章中，我將從 DORA 指標(biāo)出發(fā)，探索 DevOps 實踐與業(yè)務(wù)成果之間的預(yù)測聯(lián)系。
?

DevOps 現(xiàn)狀報告的由來

2012 年，Alanna Brown 開始編寫年度《DevOps 現(xiàn)狀報告》。后來與 Gene Kim、Nicole Forsgren 和 Jez Humble 組成了一個強(qiáng)大的團(tuán)隊。Nicole Forsgren 是一位具有豐富研究資歷的博士，她領(lǐng)導(dǎo)了 2013 年至 2017 年的研究工作。每年，該團(tuán)隊都會對全球數(shù)萬名不同工作角色和行業(yè)領(lǐng)域的技術(shù)人員進(jìn)行調(diào)查。他們檢查結(jié)果、尋找結(jié)論、并公布數(shù)據(jù)和他們的研究成果。他們的研究結(jié)論常常受到很多人的關(guān)注。
?

如何在技術(shù)領(lǐng)域進(jìn)行性能基準(zhǔn)測試？

為了了解為什么有些團(tuán)隊的表現(xiàn)比其他團(tuán)隊更好，首先需要一個衡量 IT 團(tuán)隊“績效”的標(biāo)準(zhǔn)。DORA 小組討論了各種傳統(tǒng)指標(biāo)（例如代碼行數(shù)、故事點和利用率等）所面臨的挑戰(zhàn)，發(fā)現(xiàn)僅根據(jù)個人或團(tuán)隊投入的工作來定義他們的績效是有問題的。
?

因此需要選擇關(guān)注結(jié)果而不是產(chǎn)出。當(dāng)他們這樣做的時候，他們注意到了 4 個特定指標(biāo)的獨特之處，這 4 個指標(biāo)涵蓋了績效和穩(wěn)定性的平衡。這些指標(biāo)被稱為 "DORA 指標(biāo)"。

• 部署頻率（Deployment frequency）

• 變更交付時間（Lead time for changes）

• 平均恢復(fù)時間?(Mean Time to Recovery, MTTR)

• 更改失敗率?(Change failure rate)
  

當(dāng)團(tuán)隊表現(xiàn)更好時，特別是在這些指標(biāo)方面，他們看到了獨特的、統(tǒng)計上顯著的、可預(yù)測的業(yè)務(wù)成果改善，包括：

• 盈利能力（profitability）

• 市場份額（market share）

• 生產(chǎn)力（productivity）
  

這種聯(lián)系不僅存在于 "科技公司"（即以軟件產(chǎn)品著稱的公司），所有業(yè)務(wù)領(lǐng)域都是如此。到 2018 年，高績效的技術(shù)團(tuán)隊為每個企業(yè)帶來了競爭優(yōu)勢。更重要的是，DORA 繼續(xù)討論了其他 "非營利 "組織，在這些組織中，積極成果并不完全由銀行存款余額決定。他們再次發(fā)現(xiàn)，DORA 指標(biāo)是預(yù)測成功的可靠指標(biāo)。
?

DORA 衡量標(biāo)準(zhǔn)為何有效？

DORA 指標(biāo)之所以有趣，是因為它們能促進(jìn)各種正反饋循環(huán)，同時強(qiáng)化速度和質(zhì)量方面的良好實踐?；ㄙM更少的情況下，這種組合可以讓團(tuán)隊更快地交付質(zhì)量更好的軟件。
?

部署頻率

正如 Chuck Rossi 在 Facebook 工作時所觀察到的 "如果我們想要更多變化，就需要進(jìn)行更多部署"。Chuck 面臨著提高開發(fā)速度的壓力。為了提供更多變更，F(xiàn)acebook 的部署變得越來越大、越來越復(fù)雜。然而，隨著部署的增加，其可靠性也大大降低。一旦部署失敗，就會造成嚴(yán)重后果。發(fā)現(xiàn)問題就像在數(shù)據(jù)中心大海撈針。Facebook 很難通過擴(kuò)大部署規(guī)模來實現(xiàn)其生產(chǎn)率目標(biāo)。
?

通過專注于從根本上提高部署頻率而不是部署規(guī)模，F(xiàn)acebook 取得了更大的成功。他們能夠交付更多更改，同時減少重大部署失敗。當(dāng)出現(xiàn)問題時，診斷起來更容易，修復(fù)速度也更快。他們了解到，生產(chǎn)力是部署頻率的函數(shù)，而不是部署規(guī)模的函數(shù)。
?

為了從根本上提高部署頻率，我們需要對組織層面的交付流程進(jìn)行不同的思考。如果每次部署都需要兩周的測試周期、過于形式的審查流程和 48 小時的停機(jī)時間窗口，我們就無法每周執(zhí)行多次部署，更不用說每天執(zhí)行 10 次部署了！
?

當(dāng)目標(biāo)設(shè)置為提高部署頻率時，我們就需要了解交付時間。
?

變更交付時間

在 Accelerate 中，交付時間被定義為開發(fā)人員開始某項工作與該工作在生產(chǎn)中交付（并驗證）之間的時間。（他們明確不計算某些錯誤修復(fù)或功能請求在高優(yōu)先級 Jira 工單的長尾積壓中等待的時間。）
?

低績效公司以月為單位衡量交付時間，而績效較高的公司則以小時為單位衡量交付時間。對于表現(xiàn)不佳的企業(yè)來說，他們的大部分漫長的交付時間都投入在測試、批準(zhǔn)和驗證上，因此他們理所當(dāng)然地認(rèn)為，想要加快行動就需要在質(zhì)量或安全方面做出犧牲。
?

然而，對于大多數(shù)以前沒有認(rèn)真考慮過交付時間的組織來說，通過尋找流程中最長的等待、延遲和錯誤發(fā)生在哪里，然后進(jìn)行更改或自動化步驟來避免，能夠有在交付時間上獲得巨大改進(jìn)。減少這些問題，通過將大批量的變更分解為更小范圍的、可獨立交付的批次，團(tuán)隊將會收獲另一個巨大的提升。這樣不僅可以更快、更安全地交付，同時也能更容易地進(jìn)行調(diào)整，且不會影響當(dāng)前的進(jìn)度。
?

持續(xù)較短的交付時間并不意味著倉促開發(fā)工作或跳過測試階段的結(jié)果，而是更智能的團(tuán)隊合作和優(yōu)先考慮的自動化工作的結(jié)果，使代碼得到及時審查、更快地發(fā)現(xiàn)錯誤、提高質(zhì)量、更安全的部署和更好的敏捷性。
?

平均恢復(fù)時間 (MTTR)

理解 MTTR 的最佳方法是將其與平均故障間隔時間（Mean Time Between Failure, MTBF）進(jìn)行對比。對 MTTR 的關(guān)注意味著我們更關(guān)心減少故障所帶來的影響，而不是完全避免故障的發(fā)生。相比避免故障，我們更注重故障時恢復(fù)的能力。我們還意識到顯著降低部署頻率和交付時間的安全舉措也應(yīng)當(dāng)被避免，因為這些舉措同樣會產(chǎn)生系統(tǒng)性風(fēng)險，即更長的交付時間或更高的部署風(fēng)險等。
?

如果我們的故障可以在幾分鐘內(nèi)修復(fù)，且這些故障只影響一小部分用戶，同時所有數(shù)據(jù)都可以快速恢復(fù)，那出現(xiàn)故障就變得沒那么可怕了。因此我們應(yīng)當(dāng)把更多精力放在恢復(fù)故障的能力上，而不是將一味捕捉每一個錯誤和故障。
?

當(dāng)我們展示 MTTR（而非 MTBF）方面的持續(xù)改進(jìn)時，就更容易省去不必要的形式流程。這可以有效縮短交付時間、提高部署頻率、縮小部署規(guī)模，并帶來更安全的部署和更好的 MTTR。
?

變更失敗率

測試是 DevOps 中經(jīng)常被遺忘的部分。在沒有適當(dāng)測試的情況下，持續(xù)部署是一種比以前更快地將錯誤部署到生產(chǎn)環(huán)境的方法。
?

雖然我們對 MTTR 而非 MTBF 的關(guān)注表明我們接受故障的發(fā)生，但這并不意味著我們會在故障發(fā)生時感到高興。DevOps 是關(guān)于構(gòu)建質(zhì)量，通過小規(guī)模且頻繁的部署，讓部署過程保持平穩(wěn)。

但在測試環(huán)節(jié)，我們需要快速進(jìn)行檢查，因此需要投資于自動化單元測試、集成測試、試運行部署和冒煙測試。在這個過程中，著重點在于頻繁、快速、小規(guī)模的代碼審查，而不是流于形式的緩慢、批量審查。需要注意的是，盡管我們總是試圖減少部署失敗的可能性，與試圖減少部署失敗的總數(shù)并不相同，總是擔(dān)心部署失敗的總數(shù)是否增加會分散注意力。
?

請參考以下信息，考慮哪家公司提供更高質(zhì)量的產(chǎn)品：

B 公司的失敗頻率明顯更高。然而，它可能被用戶認(rèn)為是更可靠的服務(wù)。A 公司的停機(jī)時間大約是原來的 3 倍，這將為用戶帶來巨大影響和損失。
?

通過將對 MTTR（減少故障影響）的關(guān)注與提高部署可靠性（由變更故障率定義）的共同努力相結(jié)合，即便部署失敗的總數(shù)增加，仍然可以從根本上提高部署頻率，同時提高質(zhì)量。
?

參考鏈接：
https://www.devopsdigest.com/dora-metrics-the-predictive-link-between-devops-practice-and-business-outcomes