本文作者：王津銀（老王），優維科技創始人兼CEO，原騰訊、UC高階運維工程師。

Jez Humble

Jez Humble，《持續交付》和《精益企業》兩本書的作者，作為持續交付方面的頂級專家，在其多次分享中有很多的真知灼見。本文對齊的觀點做一個整理，和大家分享之：

1. DevOps不是一個目標，而是一個沒有終點的持續改進過程

這個想法是想建立一種持續改進的文化，讓所有人蔘與改進的文化。

2. IT效能指標不能等同於IT效能因素

根據2014年Puppet Labs所做的DevOps 報告所闡述的那樣，IT有四個指標：

1. Lead time for changes（變更前置期）
2. Release frequency（釋出頻率）
3. Time to restore service（故障恢復時長）
4. Change fail rate（變更失敗率）

影響IT效能指標背後的TOP5的因素有：

1. Peer-reviewed change approval process（結對變更審批過程）
2. Version control everything（版本控制一切）
3. Proactive monitoring（主動式監控）
4. High-trust organizational culture（高度信任的組織文化）
5. A win-win relationship between dev and ops（Dev和Ops之間的雙贏關係）

3. 指標必須持續優化和改進.

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

在《精益資料分析》這本書中，也詳細給出了關於資料分析的觀點，不同的指標帶來的行為以及結果是不同的。

4. 你可以在吞吐率和穩定性之間取得平衡

Jez講到，2014年Puppet Labs DevOps 報告把IT質量分解成兩個維度：吞吐率（包含變更和釋出的前置期）和穩定性（包含故障恢復時間和變更失敗率）。

在這兩個方面之間，不是零和關係。“如果你的方式正確”，他說，“他們是可協調的”，事實上，高效能IT組織，在這兩個方面都表現得比低效能IT組織要好。當然這背後又涉及到很多因素，有架構的、有平臺、有組織、有文化、有基礎設施的敏捷性等等因素。

吞吐率這個指標，大家都非常容易理解，和我們平時在壓力測試中衡量的指標類似。穩定性代表的是一種業務服務的狀態，許多時候大家通過降低變更的頻率來確保穩定性，更甚至於是引入負責的變更審批流程來獲得穩定性。這點在高度敏捷IT的今天，顯然這種做法違背了IT作為核心能力的支撐作用，其次也降低了企業應對外界需求變化的能力。

5. 不要採用外部變更審批流（和國外情況相關）

Jez把外部審批流程比著是“風險管理中心”。因為外部的程式碼審查者根部不瞭解程式碼的情況，這種型別的Review降低了交付能力，並且也不能提高穩定性。

相反，一個結對審批過程提高吞吐率，且不影響穩定性，Jez說到，因為開發者最瞭解其程式碼的輸出和輸入。

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

顯然，緊急變更流程是想繞過測試過程，這是一個非常可怕的想法，Jez說到。你已經有線上的問題或者你沒有用緊急流程修復它，而是想在沒有測試的情況下發起變更，這點只會讓情況變得更糟，而不是更好。“你應該用正常的流程取代緊急情況”Jez說到“這才是正確的解決方式”。

在【持續交付】的原則中，有一句話提到“只有流水線才可以變更生產環境，防止配置漂移”，這一點更多是為了變更的安全考慮，不希望直接對生產環境變更。而這個“緊急”情況下的快速釋出，必須要通過平臺來解決，這樣才能真正避免緊急發生。

7.持續交付需要開發者每日的提交程式碼（最好每天兩次）

“DevOps是一種實踐，而非工具，”Jez說到。持續交付的關鍵是要重構過去的做法，所有的程式碼必須可以獨立部署，並且在提交主幹之前被很好的測試，該整合能力且不應該付出高昂的代價。“這不是說需要一個工具，而恰恰是一種思維，確保軟體一種可用的思維”。這就要求開發者必須把大的特性做小，增量變更來達成。

另一方面，如果每個人都在特性分支上開發，到最後，他們必須去對分支進行整合，這對測試提出了非常高的要求，讓系統整合測試的複雜變得異常複雜。

“從主幹開發，從主幹釋出”，這是 一種高效的模式。通常來說，這種方式很難達成，這個和系統架構和需求的拆分有很大的關係。一方面我們需要把大的系統做小（微服務系統），同時把Usestory也要拆小，變成一個個小的需求，這樣才能達到主幹開發的模式。

8.在主幹中遺留壞的程式碼是一種自私行為

如果你不能夠在很短的時間內讓這部分程式碼工作，那麼你就應該回滾到變更前的狀態。任何變更需要版本控制，如果程式碼執行異常（分為編譯、打包、審查、測試異常），此時研發者都應該需要理解修復他。

9.質量不僅僅是軟體測試者的責任

每個人都應該為質量負責。測試者只是讓質量問題透明化，以確保軟體可以工作，但測試本身並不能增加質量。

這就意味著測試不是應該在研發完成之後開始，而是一個開發過程的關鍵部分，在每一個階段、任何時候。記住，這些測試用例的設計僅僅是為了確保程式碼是否可以部署，“如果經過大量的測試，你仍然對接下來的部署還深感焦慮，”Jez說，“那就意味著你的測試工作並沒有做得足夠好”。

內建質量同樣是一種思維模式，Deming也講過“不要依賴大量的檢查手段來提升質量，而是在一開始就要把質量的意識和要求內建到產品中”。這就意味著從專案一開始，你應該去考慮影響質量的方方面面，如良好的程式碼習慣、標準化的程式碼結構、標準化的服務訪問協議、使用標準的服務元件等等，同時在這個過程中，引入高效的自動化測試工具來提升質量。

10.少即是多

研究表明，為了成功一個關鍵指標，而採用的種種手段和方法，通常其中的1/3才是有效的，餘下的則沒有那麼明顯。這讓我想起騰訊效能哥分享的自動測試的案例，“對於一個龐大的系統來說，有幾萬個測試用例。如果每次修改都觸發全迴歸，一方面代價高昂且不說，論效果來說，其實並不是很高。通常採用的是用例收斂的方法，用小部分的用例來回歸變更”。

特別進入到一個企業中，如果要實施DevOps，此時“doing less”是最好的策略。一定不要貪大求全，逐步改進。

“使用者不知道他們想要什麼，而一旦你為了他們提供了什麼，使用者就知道他們不想要什麼”,在這個點上，需要基於最小可行產品，迭代式改進，確保商業目標的最終達成。

詳細見其分享【Enterprise DevOps】！