DevOps 從理論到實踐

什麼是 DevOps

DevOps 是一個流行詞

現在 DevOps 已經成爲一個流行詞，不少公司都在說本身在作 DevOps，可是每一個人、每家公司理解的 DevOps 又不盡相同，從 DevOps 誕生的第一天起，如何定義 DevOps 就是一個爭論不休的話題。

這裏有一篇文章，筆者認爲基本詮釋了 DevOps 的定義：DevOps 是什麼不是什麼

若是你沒有耐心把這篇文章看完，維基百科還給出了一個太長不讀版：

概括成三點：

DevOps 是一種強調溝通與協做的軟件交付過程。它包括產品管理，軟件開發及運營等各個方面。

DevOps 自動化軟件集成，測試，部署以及基礎設施的變動。

它的目標是創建一種文化和環境，使得軟件的構建、測試、交付更快，更頻繁，更可靠。

DevOps 的由來

這裏我想多提一句的是持續交付和 DevOps 的關係和差異，參照維基百科 對 DevOps 和持續交付的區別進行解釋，DevOps 涵蓋的範圍比持續交付更寬，它包含了文化，強調團隊協做和自動化；而持續交付側重於頻繁、快速 地執行交付流程，二者相輔相成，卻又有所區別。

DevOps 理論框架
由於 DevOps 源自草根，缺少自上而下的理論支撐，因此如何定義 DevOps 成了 DevOps 社區裏面的一個大難題。

一些 DevOps 從業者，紛紛設定本身的 DevOps 框架。其中比較有名的框架有Damon Edwards 所定義並被 Jez Humble（持續交付做者之一） 所修訂的CALMS，和 Gene Kim 所定義的 The Three Ways。

The Three Ways

• The First Way： System Thinking （系統思考：強調全局優化，避免局部優化）
• The Second Way： Amplify Feedback Loops （通過放大的反饋迴路：建立從開發過程下游至上游的反饋環）
• The Third Way： Culture of Continual Experimentation And Learning（持續作試驗和學習的文化：持續作試驗，承擔風險、從失敗中學習；經過反覆實踐來達到精通）

CLAMS

• Culture –文化：公司各個角色一塊兒擔當業務變化，實現有效協做和溝通；創建包括運維在內的跨職能協做文化,具備共同目標的一體化團隊。這是DevOps運動的根本
• Automation – 自動化：在價值鏈中儘可能除去手工步驟；自動化一切能夠自動化的步驟，下降部署和發佈的難度
• Lean – 精益：運用精益原則更頻繁地交付價值；以精益的方式小步快跑，對過程與技術進行持續改善
• Metrics – 度量：度量並使用數據來優化交付週期；經過創建有效的監控與度量手段來得到反饋,推進產品和團隊的持續改進, 支持業務決策
• Sharing – 分享：分享成功和失敗的經驗來相互學習。

爲何要實踐 DevOps

---

• 更短的交付週期，生產環境部署頻率愈來愈快，簡化生產部署流程，且自動化不停機部署
• 更高的價值，造成特性提出到運營數據、用戶反饋驗證的實驗性交付閉環，基於實際用戶反饋調整計劃和需求
• 更好的質量保障，在代碼檢查，功能和非功能驗證，以及部署各方面創建較完善的質量保障體系，尤爲是自動化測試集
• 更高績效的團隊，包含業務，開發測試，和運維職能在內的一體化團隊，以產品交付爲共同目標緊密協做，共同承擔責任

DevOps 在技術領域的實踐

---

DevOps運做包括文化（全功能，自運維）和技術（自動化，度量反饋）兩方面，而技術能力的改進主要關注如下六個領域：

內建質量體系
經過持續代碼評審，靜態分析，自動化測試，自動部署驗證等手段構成一套有效的質量保障體系。

主要實踐包括：

• TDD：測試驅動開發的思想，保證代碼質量和不偏離業務需求的技術實現
• 結對編程和代碼審查，依靠團隊的自治性讓團隊成員互相監督和審查代碼質量
• 自動化測試，高自動化，且高頻率運行的測試，保證測試用例質量的同時保證了交付軟件的質量

持續部署
經過自動化的構建，部署過程快速頻繁地將軟件交付給用戶，提升吞吐量；同時保障過程的安全，平滑，可視。

主要實踐包括：

• 在已經作到持續集成的狀況下，引入持續部署，每次提交均會出發構建並執行部署
• 藍綠部署，用於實現零宕機發布新版本
• 金絲雀發佈，用於使應用發佈流程具有快速試錯的能力

持續監控
持續對運行環境在系統，應用層面進行監控，及時發現風險或問題，保障系統運行的穩定性。

主要實踐包括：

• 監控預警，在項目開始初期就引入監控，讓整個團隊實時可以收到關於產品各個維度數據的反饋
• 日誌聚合，便於錯誤追蹤和展現
• 分析，利用搜集到的數據實時分析，利用分析結果指導開發進度

度量與反饋
經過對用戶行爲或業務指標的度量或反饋收集，爲產品的決策提供依據。

主要實踐包括：

• 持續集成反饋，對代碼構建質量，代碼質量審查的反饋
• 測試反饋，對軟件質量，功能性的測試，給到業務的反饋
• 運營數據反饋，新功能上線後對業務影響的反饋，用於指導業務人員提新的需求

環境管理
經過對服務器環境的定義，自動化創建和配置、更新等提升基礎設施管理的效率，一致性，並更有效利用資源，可伸縮的架構，保證服務的健壯性。

主要實踐包括：

• 彈性架構，保證服務的吞吐量和具有靈活變動的能力
• 自動化部署腳本，想膠水同樣，用於解決一些工程實踐不夠完善的流程之間的銜接
• 基礎設施即代碼，用代碼定義基礎設施，便於環境管理，追蹤變動，以及保證環境一致性

鬆耦合架構
對傳統應用架構進行領域組件化，服務化，提高可測試性和可部署性。

主要實踐包括：

• 採用彈性基礎設施，好比公有云服務或是 PaaS（Platform as a Service） 平臺
• 構建爲服務應用
• 引入契約測試

將來 & 趨勢

---

• DevOps 話語權愈來愈多被平臺廠商掌握

在 DevOps 實踐的第一階段，每每會是 Jenkins, Nexus, Ansible, Shell 等一系列工具的拼湊組合，上手難度大，維護成本高，開發體驗很差。隨着 DevOps 日漸成熟，以 AWS、Pivotal、RedHat 爲表明的一些公司分別退出本身的 「DevOps產品」，或是一套完整的工具鏈，或者直接整合到一個 PaaS 平臺，甚至一些產品直接將「敏捷」，「精益」的概念也整合到產品中，直接能夠把一家公司的所有業務放到平臺上，這和最近大熱的「數字化平臺戰略」也是相吻合的。

無論怎樣，這些平臺廠商一邊賣本身的產品一邊從新定義着 DevOps，隨着平臺的完善，DevOps 已經變得愈來愈不重要，我一直以爲最好的 DevOps 團隊應該是「潤物細無聲」的，就是一個團隊不用提 DevOps，整個團隊很天然地就能關注到業務價值的交付，且能有序地按照高質量，高效率的要求去作，平臺或許能幫助咱們作到這一點。

• 容器化 & 微服務仍然是 DevOps 應用和發展的主要領域

容器化、微服務自然適合小而全的功能團隊，且一個個自治的服務也很複合 DevOps 端到端交付團隊的設計，近年隨着容器化技術（Docker）的發展，容器管理（Kubernetes）的日漸成熟（據悉，github 已經將它們的一部分產品環境灰度發佈到了 kubernetes 上，京東也將他們的服務百分之六十採用了 kubernetes 管理），DevOps 和微服務成爲了相輔相成的兩個趨勢。

• 安全成爲推進 DevOps 全面發展的重要力量

安全是 DevOps 永遠繞不開的話題，也每每是新技術在傳統行業（例如金融和電信）應用中的最大阻礙。一方面，組織結構的轉型迫使企業要打破原先的部門牆，這意味着不少原先的控制流程再也不適用。另外一方面，因爲大量的 DevOps 技術來源於開源社區，缺少強大技術實力的企業在應用相關技術時難免會有所擔心。

DevOps 全局優化的特色與安全社區提出的 「Build Security In」也特別吻合，加之愈來愈多安全易用的工具涌現，DevOpsSec 會愈來愈被人們熟知。