本文提供了一系列諷刺的建議竞滓，揭示了在實施 DORA 指標(biāo)時可能遇到的陷阱和誤區(qū)。如果讀者能夠反其道而行之簸呈，就可能會在使用 DORA 指標(biāo)的過程中掌握軟件工程的卓越實踐。原文: How (Not) to Implement DORA Metrics
免責(zé)聲明：很多時候析显，團(tuán)隊都懷著最美好的愿望試圖改進(jìn)工作。然而签赃，如果團(tuán)隊不遵循數(shù)據(jù)驅(qū)動方法谷异，那么大多數(shù)努力都是無用的。問題在于锦聊，由于我們所構(gòu)建的系統(tǒng)具有復(fù)雜的非線性性質(zhì)歹嘹，那么 HiPPO、"最大聲原則"孔庭、"專家意見"或"直覺"等方法通常都會失敗尺上。
本文代表了作者多年來在多家公司和多個團(tuán)隊中的錯誤改進(jìn)經(jīng)驗材蛛，所有提到的情況都基于真實事件，只不過通過略微夸張的簡要概括來呈現(xiàn)怎抛。
場景設(shè)定：領(lǐng)導(dǎo)層決定改變卑吭。出于某種原因，決定從你開始马绝。
領(lǐng)導(dǎo)層在你的目標(biāo)上加了一個奇怪的詞："DORA"豆赏，并希望你把團(tuán)隊的軟件交付績效提高一倍甚至兩倍。這是什么意思富稻？你的戰(zhàn)略是什么掷邦？下面有幾條（錯誤的）建議，告訴你如何度過難關(guān)椭赋。但首先...
關(guān)于 DORA 的"真相"
DevOps 研究與評估（DORA耙饰，DevOps Research and Assessment）是一個正在運(yùn)行的研究項目，任務(wù)是告訴我們應(yīng)該如何正確開發(fā)軟件纹份，以及應(yīng)該向管理層展示哪些數(shù)字才能讓他們滿意。
但站在 DORA 背后的人沒有告訴我們的是廷痘，他們是極限編程和持續(xù)交付的隱秘支持者蔓涧，他們想推廣這些理念，卻不知道如何推廣笋额。
您是否試過向持懷疑態(tài)度的管理層解釋為什么要投資于測試自動化或解決技術(shù)債務(wù)問題元暴？要解釋測試驅(qū)動開發(fā)（TDD）、結(jié)對編程和部署自動化等方法為何有效更是難上加難兄猩。
起初茉盏，他們試圖寫書，在博客上推廣簡潔代碼枢冤、重構(gòu)等鸠姨。每個人都讀這些書，但沒人真正使用⊙驼妫現(xiàn)在讶迁，他們又找到了一種方法--DORA 模型。如果你開始使用核蘸，很快就會做這些事情巍糯。
為了讓研究看起來更扎實，他們運(yùn)用統(tǒng)計方法找到了人們使用的不同能力與所謂的組織績效之間的相關(guān)性客扎。他們堅持認(rèn)為祟峦，如果提高了這些能力，也就提高了交付績效和組織績效徙鱼。這種進(jìn)步應(yīng)該通過以下指標(biāo)來衡量：
- 部署頻率（DF宅楞，Deployment frequency）：組織多長時間將代碼部署到生產(chǎn)環(huán)境一次？
- 變更前置時間（LTFC，Lead time for changes）：從提交代碼到代碼投入生產(chǎn)運(yùn)行需要多長時間咱筛？
- 變更失敗率（CFR搓幌，Change failure rate）：有多大比例的生產(chǎn)變更會導(dǎo)致服務(wù)質(zhì)量下降并需要補(bǔ)救？
- 恢復(fù)時間（TTR迅箩，Time to restore）：當(dāng)發(fā)生影響用戶的服務(wù)事故或缺陷時溉愁，一般需要多長時間恢復(fù)服務(wù)？
是否覺得服務(wù)部署頻率對公司股票價格的影響并不明顯饲趋？是的......不是只有你一個會這么想拐揭。但事實就是這樣，不過別緊張奕塑，畢竟我們不是在學(xué)習(xí)造飛機(jī)堂污。
"生產(chǎn)力是使公司更接近其目標(biāo)的行為。使公司更接近其目標(biāo)的每一個行動都是富有成效的龄砰。每一個不能使公司更接近其目標(biāo)的行動都不具有生產(chǎn)力"盟猖。
不知何故，DORA 的衡量標(biāo)準(zhǔn)發(fā)揮了作用换棚。作為工程組織式镐，它們讓我們對目標(biāo)有了很好的認(rèn)識。沒有目標(biāo)固蚤，我們所做的一切努力都是無用功娘汞。
那么，既然你對領(lǐng)導(dǎo)層的意圖有了更多了解夕玩，該如何避免實施 DORA 指標(biāo)呢你弦？我的意思是，它們并沒有那么有用燎孟，不是嗎禽作？
以下是我關(guān)于如何不執(zhí)行 DORA 指標(biāo)的指南。
技巧 #1. 說你沒有時間
作為工程經(jīng)理缤弦，你最重要的責(zé)任之一就是團(tuán)隊績效领迈。如果業(yè)績長期很低，那么很不幸碍沐，除了你之外狸捅，沒有人應(yīng)該受到責(zé)備。因此累提，從長遠(yuǎn)來看尘喝，改進(jìn)措施應(yīng)該是你的首要關(guān)注點(diǎn)。
然而在短期內(nèi)斋陪，可能會有關(guān)鍵任務(wù)朽褪。找件事情置吓，一個可以歸結(jié)為公司必須做的任務(wù)，等等缔赠。態(tài)度要非常積極衍锚，支持但要堅定。說你支持度量標(biāo)準(zhǔn)嗤堰、DORA戴质、海豚、熊貓......不管是啥踢匣。不幸的是告匠，你和團(tuán)隊現(xiàn)在沒有時間。
好在如果你堅持這樣做离唬，就會積累越來越多的緊急任務(wù)后专。因此，很快你就不會再為找不到任務(wù)而煩惱了输莺。
領(lǐng)導(dǎo)可能會讓你休息戚哎，今年就把你忘了。畢竟嫂用，他們可以專注于其他團(tuán)隊建瘫。否則，這一輪你就輸了尸折。
技巧 #2. 等待所有工具準(zhǔn)備就緒
DORA 吞吐量指標(biāo)（DF 和 LTFC）非常簡單养晋，易于收集旷太。市場上有很多相關(guān)工具，甚至咖啡機(jī)都有可能為你收集所有指標(biāo)访递。當(dāng)然粒梦，可能需要采取一些措施來實現(xiàn)這一點(diǎn)亮航。
DF 可從 Harness 等部署工具中獲取。MR/commit 數(shù)據(jù)在 Gitlab 等工具中匀们。需要將它們整合在一起缴淋，或者提取數(shù)據(jù)并在 Excel 表中手動連接。
你甚至可以手動操作泄朴。事實上重抖，開始收集 DORA 指標(biāo)時最好不要使用任何工具。這樣你將獲得更多理解和實踐經(jīng)驗祖灰。
不過钟沛，你還是可以試試這一招。如果沒有開箱即用的工具局扶，建議等待恨统。畢竟叁扫，你還有很多其他緊急任務(wù)要做。
技巧 #3. 永遠(yuǎn)不要改進(jìn)代碼
每個專業(yè)軟件工程師都應(yīng)該能夠在第一次嘗試時就寫出 100% 正確的代碼畜埋。對嗎莫绣？
即使你在一個月后都無法識別自己的代碼，也千萬不要為了讓代碼更簡單而多此一舉悠鞍。請記住对室，任何簡化代碼的嘗試都會導(dǎo)致下一次有人試圖修改代碼時縮短 LTFC。
一個好主意是狞玛，改進(jìn)代碼時一定要征得產(chǎn)品經(jīng)理的同意软驰。他怎么知道你是否需要改進(jìn)代碼以使其更具可維護(hù)性？這難道不是你作為軟件工程師的職業(yè)責(zé)任之一嗎心肪？這可能會讓他非常困惑锭亏，并給你一個逃避的借口。
技巧 #4. 推動大量發(fā)布
要想每天多次按需部署到生產(chǎn)環(huán)境中硬鞍，就需要不同的思維方式慧瘤。
一種方法是一次性實現(xiàn)一個功能。開發(fā)一個功能固该，在幾周內(nèi)完成锅减，推送一個 10,000 行的大型 MR 供代碼審查，等待有膽量的人來審查伐坏，獲得 LGTM怔匣，部署到 QA 環(huán)境，執(zhí)行必要的測試桦沉，修復(fù)缺陷每瞒，最后推送到生產(chǎn)環(huán)境。
DORA 方法假定了一種不同的工作方式纯露。開發(fā)人員應(yīng)該分批交付任務(wù)剿骨。這意味著我們需要進(jìn)行多次快速迭代：在一天左右的時間內(nèi)編寫修改代碼，推送一個小的 MR埠褪，對其進(jìn)行審核浓利，將其部署到 QA 和生產(chǎn)部門（隱藏在特性標(biāo)志下或通過抽象分支），并對其進(jìn)行測試钞速。
當(dāng)功能準(zhǔn)備就緒時贷掖，在 QA 環(huán)境中（甚至在生產(chǎn)環(huán)境中）開啟該功能并進(jìn)行端到端測試。當(dāng)我們對功能的質(zhì)量感到滿意時渴语，就會通過設(shè)置特性標(biāo)志為客戶啟用該功能羽资。DORA 指標(biāo)更傾向于這種"持續(xù)交付"方法，因為在這種情況下遵班，DF 和 LTFC 要好得多屠升。
所以潮改，一定要推動大型版本的發(fā)布。你可以說腹暖，對你來說汇在，一次性開發(fā)出整個史詩，然后一次性進(jìn)入 QA 階段會更有效率脏答。假設(shè)如果將功能拆分成許多小故事糕殉，所需的時間將是原來的兩倍。
請記住殖告，"持續(xù)交付"需要高度自動化和優(yōu)秀的工程文化阿蝶，如單元測試、重構(gòu)黄绩、童子軍規(guī)則等羡洁，所以要盡可能阻止它。
技巧 #5. 總是歸咎于人為因素
愛德華-戴明曾經(jīng)說過："一個糟糕的系統(tǒng)每次都會打敗一個優(yōu)秀的人"Walt88 Ch4爽丹。大多數(shù)改進(jìn)機(jī)會都在于系統(tǒng)如何運(yùn)作--規(guī)則筑煮、策略、協(xié)議粤蝎、習(xí)慣等真仲。
"一個壞的系統(tǒng)每次都會打敗一個好的人"[E.Deming]
只要我們敢于分析過去的工作，通常就能獲得這些數(shù)據(jù)初澎。最簡單的方法就是分析 LTFC 統(tǒng)計數(shù)據(jù)秸应，找出最主要的制約因素。很可能會發(fā)現(xiàn)部署花費(fèi)了太多時間碑宴。因此灸眼，可以實施部署自動化來加以改進(jìn)。
很多時候墓懂，瓶頸在于異步代碼審查。另一個好辦法是分析任務(wù)的周期時間（從團(tuán)隊開始開發(fā)到部署到生產(chǎn)之間的時間）霉囚，甚至不需要分析所有任務(wù)捕仔，只考慮每個月的異常值就會給我們帶來很多啟發(fā)。
下面是我們?nèi)绾卫眠@一優(yōu)勢的一些建議盈罐。
首先榜跌，永遠(yuǎn)不要做回顧總結(jié)≈逊啵或者盡量讓回顧總結(jié)無用武之地钓葫。每隔一周安排一個小時，不要事先進(jìn)行任何分析（LTFC 統(tǒng)計票顾、異常任務(wù)分析等）础浮，不跟進(jìn)帆调。
其次，避免進(jìn)行根因分析和以數(shù)據(jù)為導(dǎo)向的決策豆同。只選最顯而易見的番刊，不做深入研究。對于任何問題影锈，你總能找到"眾所周知的解決方案--簡潔芹务、合理、錯誤"H.L. Mencken鸭廷。如果發(fā)生了生產(chǎn)事故枣抱，建議實施端到端測試。如果發(fā)布很痛苦辆床，那就決定減少發(fā)布頻率佳晶。
"人類的每一個問題總有一個眾所周知的解決方案--簡潔、合理佛吓、錯誤"[H.L. Mencken]宵晚。
第三，任何根因分析都要盡量歸結(jié)為人為因素维雇。有人造成了這種情況淤刃，對嗎？
技巧 #6. 只推廣端到端測試策略
查看任何回歸缺陷事件吱型，開始根因分析逸贾，讓每個人都同意，如果有端到端測試涵蓋這個確切場景津滞，那就會在部署到生產(chǎn)之前就發(fā)現(xiàn)這個錯誤铝侵。這是一個很難被擊敗的堅實論據(jù)，因此通常都能奏效触徐，而且這實際上是正確的咪鲜。
"好的想法往往會在實踐中失敗，而在測試領(lǐng)域撞鹉，有一個普遍存在的好想法往往會在實踐中失敗疟丙，那就是圍繞端到端測試建立的測試策略"。[Wack]
訣竅在于端到端測試既慢又脆弱鸟雏。因此享郊，如果你試圖用端到端測試覆蓋所有可能的情況，那么很快你的團(tuán)隊就會被拖垮孝鹊。每次部署都要花費(fèi)數(shù)小時炊琉，每個人都會不惜一切代價批量部署或避免部署。DF 和 LTFC 將會下降又活，不過這正是我們所需要的苔咪，不是嗎锰悼？
但也有一些注意事項。
首先悼泌，確保測試在共享的 QA 環(huán)境上運(yùn)行松捉。用它的團(tuán)隊越多越好，這樣你甚至不用太費(fèi)心馆里，就能讓測試變得不穩(wěn)定隘世。
其次，建議在端到端測試中包含盡可能多的不同服務(wù)鸠踪，最好是來自不同團(tuán)隊的服務(wù)丙者，或者最好是來自不同公司的服務(wù)。盡管每個團(tuán)隊肯定都工作得很好营密，而且他們很少破壞測試械媒，但如果有許多團(tuán)隊參與其中，就會增加脆弱性评汰。
第三纷捞，拒絕任何用低級測試（尤其是單元測試）替代高級測試的嘗試。想象一下你有兩個組件被去，一個組件通過外部 API 接受用戶請求主儡，進(jìn)行一些處理后調(diào)用第二個組件。第二個組件處理請求并返回響應(yīng)惨缆。
假設(shè)這些組件中有 10 個可能的執(zhí)行路徑糜值。這意味著要測試整個系統(tǒng)，需要編寫 10x10=100 個測試坯墨。你可以用第一個組件的 10 個單元測試寂汇、第二個組件的 10 個單元測試和幾個"集成"測試來代替。但這樣會減少測試的數(shù)量和執(zhí)行時間捣染，并提高穩(wěn)定性骄瓣！因此，請避免這樣做耍攘。
技巧 #7. 追求 100% 的可靠性
質(zhì)量的含義各不相同榕栏。可用性少漆、延遲和耐用性等被稱為可靠性指標(biāo)。SRE 一書指出硼被，試圖達(dá)到 100% 的可靠性是沒有意義的示损。首先，到了一定程度后嚷硫，用戶就不會在意了检访，因為可靠性對他們來說已經(jīng)足夠好了始鱼。其次，極端可靠性是有代價的脆贵。每多一個"9"医清，就需要付出成倍的努力。
干擾任何采用基于風(fēng)險的可靠性方法的嘗試卖氨。完全不要從客戶角度來定義 SLO会烙，或盡可能嚴(yán)格定義 SLO，始終以 99.99+% 為目標(biāo)筒捺。
即使產(chǎn)品對延遲的要求較寬松柏腻，也要添加分布式緩存以優(yōu)化延遲。堅持在 QA 環(huán)境和生產(chǎn)環(huán)境中使用金絲雀系吭，并在每個步驟中進(jìn)行手動驗證五嫂。假裝這樣做是為了提高可用性（不收集任何統(tǒng)計數(shù)據(jù)也沒關(guān)系），并可以將增加更改系統(tǒng)的難度肯尺。人們會嘗試批量部署沃缘，以減少部署的頻率。
技巧 #8. 忽略文檔
R.Martin 認(rèn)為则吟，任何專業(yè)人士都應(yīng)對自己的職業(yè)生涯負(fù)全責(zé)槐臀。你應(yīng)該了解本行業(yè)的所有基礎(chǔ)知識和最新進(jìn)展。雇主是根據(jù)工作時間來支付工資的逾滥，而不是根據(jù)你學(xué)習(xí)基礎(chǔ)知識的時間來支付工資峰档。然而，許多雇主確實關(guān)心這一點(diǎn)寨昙，并盡可能幫助員工成長讥巡。這是一種恩惠，而不是一種義務(wù)CleanCoder舔哪。
所以欢顷，要盡可能動。他們雇用了你捉蚤，對嗎抬驴？現(xiàn)在他們應(yīng)該關(guān)心你的學(xué)習(xí)之路了。與其閱讀和學(xué)習(xí)新技術(shù)缆巧、新方法或新概念布持，不如坐下來放松一下，直到在工作中需要為止陕悬。掌握的知識越少越好题暖。
尤其要避免閱讀以下書籍：
- E.Goldratt 的 目標(biāo)（超級不推薦）
- Gene Kim 的 鳳凰項目、獨(dú)角獸項目、DevOps 手冊
- N. Forsgren 的 加速
- D. Reinertsen 的 The Principles of Product Development Flow
- D.Andersen 和 A. Zheglov 合著的 Fit for purpose
- M. Kleppman 撰寫的 數(shù)據(jù)密集型應(yīng)用系統(tǒng)設(shè)計
- M.Fowler 的 重構(gòu)
- R. Martin的 簡潔代碼胧卤、簡潔架構(gòu)唯绍、程序員的職業(yè)素養(yǎng)
- M. Skelton 的 高效能團(tuán)隊模式
- K. Leopold 的 實用看板
- D. Vacanti 所著的 可操作的敏捷可預(yù)測性指標(biāo)
就是這樣！這就能最好的避免執(zhí)行 DORA 指標(biāo)枝誊。
當(dāng)然况芒，如果你選擇忽略上述提示，或者采取與提示完全相反的做法叶撒，那么可能會發(fā)現(xiàn)自己正走在利用 DORA 指標(biāo)掌握卓越軟件工程的道路上绝骚。
你好，我是俞凡痊乾，在Motorola做過研發(fā)皮壁，現(xiàn)在在Mavenir做技術(shù)工作，對通信哪审、網(wǎng)絡(luò)蛾魄、后端架構(gòu)、云原生湿滓、DevOps滴须、CICD、區(qū)塊鏈叽奥、AI等技術(shù)始終保持著濃厚的興趣扔水，平時喜歡閱讀、思考朝氓，相信持續(xù)學(xué)習(xí)魔市、終身成長，歡迎一起交流學(xué)習(xí)赵哲。為了方便大家以后能第一時間看到文章待德，請朋友們關(guān)注公眾號"DeepNoMind"，并設(shè)個星標(biāo)吧枫夺，如果能一鍵三連(轉(zhuǎn)發(fā)将宪、點(diǎn)贊、在看)橡庞，則能給我?guī)砀嗟闹С趾蛣恿咸常钗页掷m(xù)寫下去，和大家共同成長進(jìn)步扒最！
本文由mdnice多平臺發(fā)布
