[[186769]]

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

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

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

2. IT性能指標不能等同于IT性能因素

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

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

影響IT性能指標背后的TOP5的因素有：

• Peer-reviewed change approval process(結對變更審批過程)
• Version control everything(版本控制一切)
• Proactive monitoring(主動式監控)
• High-trust organizational culture(高度信任的組織文化)
• 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”是***的策略。一定不要貪大求全，逐步改進。

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

【本文是51CTO專欄作者“王津銀”的原創稿件，轉載請注明出處】

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