2017 DevOps 現狀調查報告（官方中文版） 

http://www.idcos.com/download/devops-report

讀書總結：

如今 DevOps 實踐已深入人心，成為一種企業文化。幫助企業提高應用部署效率、保證系統的質量與安全、快速適應市場。

DevOps 有助於提升 IT 效能，幫助企業提高生產率、增加利潤、擴大市場份額。

高效的領導該如何影響技術實踐及流程的改善，從而提升 IT 及組織的效能？

自動化是企業的核心競爭力。

綜述：

1. 良好的建設性溝通能力、善於鼓勵與啟發及個人魅力，這些領導特質與 IT 的效能有密切關係。高效能團隊其領導層均具備上述特質。相反低效能團隊的領導層則缺乏這些方面的能力。

2. 不同效能團隊的釋出頻率，釋出延遲等指標上的差距在縮減。但低效能團隊的故障恢復時間及釋出失敗率卻有所上升。其原因是隨著釋出頻率的提升，對構建的質量控制放鬆了。

3. 高效能團隊在配置管理、測試、釋出和審批流程等的自動化程度上，明顯優於其他團隊；進而高效能團隊有更多的時間用於創新及快速響應市場。

4. 為達成 IT 的高效能，請採用鬆耦合服務架構，即服務可以獨立開發與部署；以及鬆耦合的團隊，隨時準備進行變更。達成上述變化需要傳統企業進行巨大投入。鬆耦合架構的好處是： 更高的業績，質量和穩定性。

5. 精益產品管理實踐幫助團隊交付符合市場需求的產品，以及更短的交付週期。快速交付讓研發團隊與客戶的聯絡更緊密。 其結果是，整個組織的盈利水平，生產率和市場份額的提升。

領導力：

領導力對企業有重大影響。好的管理者能夠帶領團隊釋出高質量程式碼、構建高質量系統、在產品研發中應用精益原則。上述能力對企業的盈利能力、生產率和市場份額有直接影響。對不以盈利作為衡量標準的組織和政府機構而言，領導能力的高低關係到客戶滿意度、組織效率及組織願景的達成。

領導力如何幫助企業提升效能是 DevOps 實踐中很容易被忽視的地方。領導力在如下任務中是必不可少的：

- 營造與鼓勵互相信任的文化氛圍

- 通過技術手段提升生產效率，縮減部署延遲， 提升可靠性

- 支援團隊創新，更快更好的釋出產品

- 打破部門界限，認同組織願景

DevOps 社群內部對管理層往往缺乏認同，例如，中層管理者有時會阻礙提升 IT 與組織效率方面的變革。一個經常被問到的問題是，如何能讓管理層支援我們進行變革和改進？ 所有人都同意管理層的支援是成功實踐DevOps 的必要條件。大規模變革所需要的預算與流程必須經過管理層的批准。變革中若遇到障礙，團隊需要管理層的支援和鼓勵。管理層負責設定組織的基調與文化。

領導力的五個象限：

但是好的領導力並不等同於 DevOps 的成功。在領導力排名前 10% 的組織中，DevOps 的成效有好有壞。因為DevOps 的成功不僅僅取決於領導力，而是包含合理的組織架構、好的技術實踐、遵循精益管理原則等等諸多因素。

中等效能團隊的實施自動化過程中的陣痛：

中等效能團隊實施自動化過程中的重做與手工操作的增加只是暫時現象。通過實施自動化，團隊收到實際成效的同時，也遇到大量的技術債，妨礙 DevOps 和自動化的推進。我們建議團隊不要追求對自動化過程的過度控制，而是逐步從審批委員會形態轉為研發週期中常見的程式碼評審及測試自動化等技術手段。最終變更審批委員會這一組織形態會消失，被更快同時也是更可靠的審批流程取而代之。技術債的消解完成後，團隊就可以在自動化和 DevOps 的實踐中更進一步了。

DevOps技術實踐：

DevOps 幫助更快的部署軟體、提升團隊效率、保持組織的競爭優勢。打算實施 DevOps 的組織往往從購買相應的 DevOps 軟體開始，但更重要的則是遵循 DevOps相關的技術實踐。我們的問卷報告深入考察了這些技術實踐，包括版本控制、持續整合、基於主幹的開發模式、及自動化等。今年的問卷增加了系統構架及組織結構方面的實踐內容，包括他們對軟體研發及部署效率的影響。

持續交付：

成功實施持續交付的技術實踐包括： 完備的程式碼控制、持續整合、基於主幹的開發，在研發中引入安全合規、實施測試與部署自動化。當然，測試自動化最為關鍵。

持續交付成功的關鍵（其重要性超過自動化測試與部署），在於團隊是否做到如下幾點：

- 實施大規模變更不需要來自團隊之外的人審批

- 實施大規模變更不依賴於其他團隊所負責系統的 變更，也不會給其他團隊增加額外的工作量

- 不需要與其他團隊進行細節上的溝通

- 按需變更，不依賴其他服務的更新，也不影響依 賴本服務的系統

- 可無須整合測試環境完成大部分測試

- 在業務時間完成部署，不影響業務連續性

基於主幹的開發：

報告考察了基於主幹的開發模式對持續交付的影響。研究表明高效能團隊選擇工作在小的程式碼分支並及時合併到主分支，而不是保留眾多的特性分支。如下實踐有助於提升軟體交付效率：

- 每天將程式碼合併到主分支（Trunk 或 Master）

- 縮短分支及 fork 的存活週期（短於一天）

- 只維護少於三個活躍分支

無需引入程式碼鎖定期的團隊具有更高的釋出效率（上述列舉的實踐有助於避免程式碼鎖定）。

雖然基於主幹的開發有提升軟體部署效率，部分習慣採用“Github 推薦開發流程”的開發人員對此表示懷疑。“Github推薦開發流程”建議基於分支進行開發，只是週期性的合併到主幹。工作在短的分支，並每天合併到主幹是持續釋出的最佳實踐之一。基於分支的開發，在分支壽命足夠短的情況下，也是高效的。問題是“短”具體指的是多長時間？

今年的問卷我們專門分析了採用主幹開發策略和分支開發策略的效率區別。考察點包括分支或 fork 在被合併到 master 之前的存活時間，分支合併的時間開銷，以及不同效能組織分支策略的區別，以下是我們的發現：

- 高效能團隊具有較短的合併耗時和分支存活時間，均為數小時

- 低效能團隊具有較長的合併耗時和分支存活時間，為數天

該問卷揭示高效能團隊具有較短的分支存活時間與分支合併耗時。歷年問卷都揭示了同樣的最佳實踐：避免分支的存活週期超過一天。如果分支合併和整合的耗時超過一天，這就是告警資訊，提醒團隊重新審視系統架構與分支策略。

收集客戶反饋：

敏捷方法的目標之一是將客戶需求貫穿於整個研發週期中，甚至產品還在早期設計階段。這使得研發團隊能夠獲取重要的客戶反饋並應用到設計中。如果研發團隊不允許根據所收集到的客戶反饋更新規範或需求，或者這樣變更需要通過外部審批，團隊的創新力會被極大的消減。

工具類專案和戰略類專案的區分：

理解工具類專案和戰略類專案的分別，並區別對待。Martin Fowler 提出的區分原則是：其功能是否為組織核心競爭力。如果答案是否定的，可以考慮購買市面上的商業軟體而不是自行開發。一個經常犯的錯誤是將工具類需求誤以為是戰略需求，化大力氣開發或訂製，而不是主動調整自己的業務流程去適應成熟的商用系統。

錯誤的將工具類需求視為戰略需求會導致嚴重後果，包括花費大量精力訂製類一個難以維護，測試，升級改造的黑箱系統，該系統無法納入到自動測試，自動釋出和維護的服務生命週期中，而自動化是 DevOps 實踐的核心。與其對商用系統進行耗費巨大定製，不如調整自身的業務流程去適應系統，將其作為業務流程優化的一部分。在許多情況下，這比定製的代價小很多。任何情況下，定期重新審視企業流程都是有益的。

上述實踐可能與研發組織不輕易接受第三方開發軟體的傳統相違，許多工程師都認為：我們做得更好。但是，貫徹這一實踐能夠讓精力和智慧都集中在創造具有競爭力的產品上，讓企業立於不敗之地。