[[186769]]

Jez Humble，【持續(xù)交付】和【精益企業(yè)】兩本書的作者，作為持續(xù)交付方面的***專家，在其多次分享中有很多的真知灼見。本文對(duì)他的觀點(diǎn)做一個(gè)整理，和大家分享之：

1. DevOps不是一個(gè)目標(biāo)，而是一個(gè)沒有終點(diǎn)的持續(xù)改進(jìn)過程

這個(gè)想法是想建立一種持續(xù)改進(jìn)的文化，讓所有人參與改進(jìn)的文化。

2. IT性能指標(biāo)不能等同于IT性能因素

根據(jù)2014年P(guān)uppet Labs所做的DevOps 報(bào)告所闡述的那樣，IT有四個(gè)指標(biāo)：

• Lead time for changes(變更前置期)
• Release frequency(發(fā)布頻率)
• Time to restore service(故障恢復(fù)時(shí)長)
• Change fail rate(變更失敗率)

影響IT性能指標(biāo)背后的TOP5的因素有：

• Peer-reviewed change approval process(結(jié)對(duì)變更審批過程)
• Version control everything(版本控制一切)
• Proactive monitoring(主動(dòng)式監(jiān)控)
• High-trust organizational culture(高度信任的組織文化)
• A win-win relationship between dev and ops(Dev和Ops之間的雙贏關(guān)系)

3. 指標(biāo)必須持續(xù)優(yōu)化和改進(jìn)

DevOps應(yīng)該避免一直使用相同的指標(biāo)來度量，Jez說“你應(yīng)該不斷改進(jìn)你的指標(biāo)體系”，因?yàn)?ldquo;每次你如何度量它，這個(gè)會(huì)改變你的行為”。這點(diǎn)非常重要，人們總是找到方式和方法以便達(dá)到指標(biāo)，這就是所謂的度量/指標(biāo)驅(qū)動(dòng)。然后可悲的是，通常管理者把指標(biāo)作為一個(gè)硬性管理工具，把它與業(yè)績考核放在了一起，這樣指標(biāo)就失去了意義。如若這樣，人們總是能找到方法讓這些指標(biāo)看起來很好看，而這樣的話，則不是真正的幫助企業(yè)達(dá)成目標(biāo)了。

在《精益數(shù)據(jù)分析》這本書中，也詳細(xì)給出了關(guān)于數(shù)據(jù)分析的觀點(diǎn)，不同的指標(biāo)帶來的行為以及結(jié)果是不同的。

4. 你可以在吞吐率和穩(wěn)定性之間取得平衡

Jez講到，2014年P(guān)uppet Labs DevOps 報(bào)告把IT質(zhì)量分解成兩個(gè)維度：吞吐率(包含變更和發(fā)布的前置期)和穩(wěn)定性(包含故障恢復(fù)時(shí)間和變更失敗率)。

在這兩個(gè)方面之間，不是零和關(guān)系。“如果你的方式正確”，他說，“他們是可協(xié)調(diào)的”，事實(shí)上，高性能IT組織，在這兩個(gè)方面都表現(xiàn)得比低性能IT組織要好。當(dāng)然這背后又涉及到很多因素，有架構(gòu)的、有平臺(tái)、有組織、有文化、有基礎(chǔ)設(shè)施的敏捷性等等因素。

吞吐率這個(gè)指標(biāo)，大家都非常容易理解，和我們平時(shí)在壓力測(cè)試中衡量的指標(biāo)類似。穩(wěn)定性代表的是一種業(yè)務(wù)服務(wù)的狀態(tài)，許多時(shí)候大家通過降低變更的頻率來確保穩(wěn)定性，更甚至于是引入負(fù)責(zé)的變更審批流程來獲得穩(wěn)定性。這點(diǎn)在高度敏捷IT的今天，顯然這種做法違背了IT作為核心能力的支撐作用，其次也降低了企業(yè)應(yīng)對(duì)外界需求變化的能力。

5. 不要采用外部變更審批流(和國外情況相關(guān))

Jez把外部審批流程比著是“風(fēng)險(xiǎn)管理中心”。因?yàn)橥獠康拇a審查者根部不了解代碼的情況，這種類型的Review降低了交付能力，并且也不能提高穩(wěn)定性。

相反，一個(gè)結(jié)對(duì)審批過程提高吞吐率，且不影響穩(wěn)定性，Jez說到，因?yàn)殚_發(fā)者最了解其代碼的輸出和輸入。

6. 緊急變更流程是一個(gè)可怕的想法

顯然，緊急變更流程是想繞過測(cè)試過程，這是一個(gè)非?？膳碌南敕?，Jez說到。你已經(jīng)有線上的問題或者你沒有用緊急流程修復(fù)它，而是想在沒有測(cè)試的情況下發(fā)起變更，這點(diǎn)只會(huì)讓情況變得更糟，而不是更好。“你應(yīng)該用正常的流程取代緊急情況”Jez說到“這才是正確的解決方式”。

在【持續(xù)交付】的原則中，有一句話提到“只有流水線才可以變更生產(chǎn)環(huán)境，防止配置漂移”，這一點(diǎn)更多是為了變更的安全考慮，不希望直接對(duì)生產(chǎn)環(huán)境變更。而這個(gè)“緊急”情況下的快速發(fā)布，必須要通過平臺(tái)來解決，這樣才能真正避免緊急發(fā)生。

7. 持續(xù)交付需要開發(fā)者每日的提交代碼(***每天兩次)

“DevOps是一種實(shí)踐，而非工具，”Jez說到。持續(xù)交付的關(guān)鍵是要重構(gòu)過去的做法，所有的代碼必須可以獨(dú)立部署，并且在提交主干之前被很好的測(cè)試，該集成能力且不應(yīng)該付出高昂的代價(jià)。“這不是說需要一個(gè)工具，而恰恰是一種思維，確保軟件一種可用的思維”。這就要求開發(fā)者必須把大的特性做小，增量變更來達(dá)成。

另一方面，如果每個(gè)人都在特性分支上開發(fā)，到***，他們必須去對(duì)分支進(jìn)行集成，這對(duì)測(cè)試提出了非常高的要求，讓系統(tǒng)集成測(cè)試的復(fù)雜變得異常復(fù)雜。

“從主干開發(fā)，從主干發(fā)布”，這是 一種高效的模式。通常來說，這種方式很難達(dá)成，這個(gè)和系統(tǒng)架構(gòu)和需求的拆分有很大的關(guān)系。一方面我們需要把大的系統(tǒng)做小(微服務(wù)系統(tǒng))，同時(shí)把Usestory也要拆小，變成一個(gè)個(gè)小的需求，這樣才能達(dá)到主干開發(fā)的模式。

8. 在主干中遺留壞的代碼是一種自私行為

如果你不能夠在很短的時(shí)間內(nèi)讓這部分代碼工作，那么你就應(yīng)該回滾到變更前的狀態(tài)。任何變更需要版本控制，如果代碼運(yùn)行異常(分為編譯、打包、審查、測(cè)試異常)，此時(shí)研發(fā)者都應(yīng)該需要理解修復(fù)他。

9. 質(zhì)量不僅僅是軟件測(cè)試者的責(zé)任

每個(gè)人都應(yīng)該為質(zhì)量負(fù)責(zé)。測(cè)試者只是讓質(zhì)量問題透明化，以確保軟件可以工作，但測(cè)試本身并不能增加質(zhì)量。

這就意味著測(cè)試不是應(yīng)該在研發(fā)完成之后開始，而是一個(gè)開發(fā)過程的關(guān)鍵部分，在每一個(gè)階段、任何時(shí)候。記住，這些測(cè)試用例的設(shè)計(jì)僅僅是為了確保代碼是否可以部署，“如果經(jīng)過大量的測(cè)試，你仍然對(duì)接下來的部署還深感焦慮，”Jez說，“那就意味著你的測(cè)試工作并沒有做得足夠好”。

內(nèi)建質(zhì)量同樣是一種思維模式，Deming也講過“不要依賴大量的檢查手段來提升質(zhì)量，而是在一開始就要把質(zhì)量的意識(shí)和要求內(nèi)建到產(chǎn)品中”。這就意味著從項(xiàng)目一開始，你應(yīng)該去考慮影響質(zhì)量的方方面面，如良好的代碼習(xí)慣、標(biāo)準(zhǔn)化的代碼結(jié)構(gòu)、標(biāo)準(zhǔn)化的服務(wù)訪問協(xié)議、使用標(biāo)準(zhǔn)的服務(wù)組件等等，同時(shí)在這個(gè)過程中，引入高效的自動(dòng)化測(cè)試工具來提升質(zhì)量。

10. 少即是多

研究表明，為了成功一個(gè)關(guān)鍵指標(biāo)，而采用的種種手段和方法，通常其中的1/3才是有效的，余下的則沒有那么明顯。這讓我想起騰訊性能哥分享的自動(dòng)測(cè)試的案例，“對(duì)于一個(gè)龐大的系統(tǒng)來說，有幾萬個(gè)測(cè)試用例。如果每次修改都觸發(fā)全回歸，一方面代價(jià)高昂且不說，論效果來說，其實(shí)并不是很高。通常采用的是用例收斂的方法，用小部分的用例來回歸變更”。

特別進(jìn)入到一個(gè)企業(yè)中，如果要實(shí)施DevOps，此時(shí)“doing less”是***的策略。一定不要貪大求全，逐步改進(jìn)。

“用戶不知道他們想要什么，而一旦你為了他們提供了什么，用戶就知道他們不想要什么”,在這個(gè)點(diǎn)上，需要基于最小可行產(chǎn)品，迭代式改進(jìn)，確保商業(yè)目標(biāo)的最終達(dá)成。

【本文是51CTO專欄作者“王津銀”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)注明出處】

戳這里，看該作者更多好文