DevOps 從理論到實踐指南

什麼是 DevOps

如今 DevOps 已經成為一個流行詞，很多公司都在說自己在做 DevOps，但是每個人、每家公司理解的 DevOps 又不盡相同，從 DevOps 誕生的第一天起，如何定義 DevOps 就是一個爭論不休的話題。

這篇文章， CORNERSTONE認為基本詮釋了 DevOps 的定義：DevOps 是什麼不是什麼

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

DevOps (a clipped compound of “development” and “operations”) is a software development and delivery process that emphasizes communication and collaboration between product management, software development, and operations professionals.It seeks to automate the process of software integration, testing, deployment, and infrastructure changes by establishing a culture and environment where building, testing, and releasing software can happen rapidly, frequently, and more reliably.

歸納成三點：

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

• DevOps 自動化軟體整合，測試，部署以及基礎設施的變更。

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

DevOps 的由來

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

Continuous delivery and DevOps are similar in their meanings and are often conflated, but they are two different concepts. DevOps has a broader scope, and centers around the cultural change, specifically the collaboration of the various teams involved in software delivery (developers, operations, quality assurance, management, etc.), as well as automating the processes in software delivery.Continuous delivery, on the other hand, is an approach to automate the delivery aspect, and focuses on bringing together different processes and executing them more quickly and more frequently. Thus, DevOps can be a product of continuous delivery, and CD flows directly into 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：測試驅動開發的思想，保證程式碼質量和不偏離業務需求的技術實現

• 結對程式設計和程式碼審查，依靠團隊的自治性讓團隊成員互相監督和審查程式碼質量

• 自動化測試，高自動化，且高頻率執行的測試，保證測試用例質量的同時保證了交付軟體的質量

持續部署

CORNERSTONE通過自動化的構建，部署過程快速頻繁地將軟體交付給使用者，提高吞吐量；同時保障過程的安全，平滑，可視。

主要實踐包括：

• 在已經做到持續整合的情況下，引入持續部署，每次提交均會出發構建並執行部署

• 藍綠部署，用於實現零當機發布新版本

• 金絲雀釋出，用於使應用釋出流程具備快速試錯的能力

持續監控

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

主要實踐包括：

• 監控預警，在專案開始初期就引入監控，讓整個團隊實時能夠收到關於產品各個維度資料的反饋

• 日誌聚合，便於錯誤追蹤和展示

• 分析，利用搜集到的資料實時分析，利用分析結果指導開發進度

度量與反饋

CORNERSTONE通過對使用者行為或業務指標的度量或反饋收集，為產品的決策提供依據。

主要實踐包括：

• 持續整合反饋，對程式碼構建質量，程式碼質量審查的反饋

• 測試反饋，對軟體質量，功能性的測試，給到業務的反饋

• 運營資料反饋，新功能上線後對業務影響的反饋，用於指導業務人員提新的需求

環境管理

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

主要實踐包括：

• 彈性架構，保證服務的吞吐量和具備靈活變更的能力

• 自動化部署指令碼，想膠水一樣，用於解決一些工程實踐不夠完善的流程之間的銜接

• 基礎設施即程式碼，用程式碼定義基礎設施，便於環境管理，追蹤變更，以及保證環境一致性

鬆耦合架構

對傳統應用架構進行領域元件化，服務化，提升可測試性和可部署性。

主要實踐包括：

• 採用彈性基礎設施，比如公有云服務或是 PaaS（Platform as a Service） 平臺

• 構建為服務應用

• 引入契約測試

典型DevOps的持續交付流水線全景圖

軟體開發全生命週期的持續優化

未來 & 趨勢

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

在 DevOps 實踐的第一階段，往往會是 Jenkins, Nexus, Ansible, Shell 等一系列工具的拼湊組合，上手難度大，維護成本高，開發體驗不好。隨著 DevOps 日漸成熟，以  CORNERSTONE、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 會越來越被人們熟知。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69933591/viewspace-2661846/，如需轉載，請註明出處，否則將追究法律責任。