CI/CD和DevOps 的過去和未來
本文由 DevOps時代高翻院整理髮布
十年前，DevOps 的理念在 Andrew Shafer 和 Patrick Debois 兩位先驅的腦海中醞釀。一年之後，他們將其正式命名為「DevOps」。光陰荏苒，今年是 DevOps 誕生的十周年，本文將回顧 DevOps 的歷程，並且展望 DevOps 的未來。
本文內容會盡量和某些 IT 廠商、商業產品或開源產品等等無關。我們會專註討論 DevOps、CI/CD 的歷史，探究這些理念的發展形態，並嘗試預測這一領域美好未來。
脫胎于敏捷運動的 「DevOps」
在 2008 年的多倫多敏捷峰會上，Andrew Shafer 的一番發言為 DevOps 運動點燃了星星之火。
在 IT 技術的世界裡，十年前的活動已經稱得上是「遠古事件」，但不得不說，DevOps 的理念最初是脫胎于敏捷運動，或者至少是在敏捷運動的討論範圍內的。
2001 年發布的敏捷宣言雖然缺少細節，但在以下幾個方面表達了清晰的態度：
1、「持續交付高質量的軟體」；
2、「高頻率交付可用軟體」；
3、「掌控變化，使其成為一種競爭優勢」。
由此，DevOps 理念和CI/CD 實踐，與敏捷的思想真可謂是「琴瑟和鳴」了。
從「手工工作」到「程序化工作」
DevOps 的一個核心理念是：不僅要將業務邏輯程序化，還要將支撐 IT 運行的基礎設施程序化。這一理念幾乎為所有 IT 從業人員打開了想像空間。
持續集成本質上是手工測試和源碼管理的「程序化」。
可編程的基礎設施以及自帶 API 的雲資源是手工安裝和配置的「程序化」。
持續交付和部署是手工發布的「程序化」。
沒有以上這幾方面的程序化，DevOps 思想和敏捷理念中的其他美好願景都無從談起。「程序化」帶來了以下兩大好處。
縮減交付時間。軟體的測試、伺服器搭建和應用部署都要耗費很多時間。把這些工作寫成程序，重複使用，將極大地提高效率，減少軟體交付時間。
規避風險。將工作程序化之後，即便沒有做到最快、最敏捷，也可以減少變更風險，從而提高軟體交付質量。因為：
自動化測試能更早、更快地發現 Bug；
程序化的基礎設施管理能避免配置錯誤；
自動化回滾能夠迅速處理失敗的發布；
以上幾個方面在自動化之後都可以避免人為失誤。
另外，圍繞軟體交付和基礎設施的程序化還加強了開發人員與運維人員之間的溝通和理解。雖然這並非 DevOps 的首要目標，但確實是 DevOps 帶來的巨大利好。來自 Flickr 的工程師 John Allspaw 和 Paul Hammond 在 2009 年的 PPT 就充分說明了這一點。
基於「程序化一切」的理念還催生出了一系列的產品和服務：Heroku，Cloud Foundry，AWS Beanstalk，TravisCI，Jenkins，CodeShip，Bamboo，Puppet，Ansible，Terraform，等等等等。他們當中有託管服務，也有 SaaS；有開源的，也有商業化的。百花齊放，百家爭鳴。
從「程序化」到「效果驗證」
作為 DevOps 實踐的第一股浪潮，「程序化」實現了敏捷宣言中「持續化」、「高頻率」和「軟體可用性」等等願景。然而，要想實現第三個願景：「掌控變化，使其成為一種競爭優勢」，則明顯複雜得多。哪些變化是對我們有利的，哪些是不利的？我們的客戶想要的到底是什麼？
這些問題一直是營銷人員，用戶體驗設計和產品經理關心的話題。他們經常使用的工具有 A/B 測試、多變數測試、受眾測試和短期實驗性功能測試等等。這些方法的常用邏輯是：「我們也不知道用戶的真實需求，那我們就用實驗的方法來挖掘吧」。
這種驗證效果的思想現在也滲透進了研發領域，而且現在正是時候。在以前，開發人員、架構師和運維人員往往更傾向於預測事情的發展，而不太願意因勢利導。我們願意預測未來，設計程序和基礎設施的時候也傾向於盡量解決「未來的問題」，還美其名曰具有「針對性」和「預見性」地解決問題。
醒醒吧。我相信你肯定也做過這種類似的預測，最後發現事態的發展和你估計的差遠了。
對於工作模式、工具和服務的驗證
摒棄「預測」和「估計」的工作方式已經大有裨益了，但我們當然不會止步於此。在過去的幾年間，眾多新模式、新技術、新工具和新服務湧現出來，幫助工程師從「未知」向「已知」邁進。
1. 藍 / 綠部署
「效果驗證」的始祖是「藍綠部署」法。這種方法簡單粗暴，但也廣泛流行。甚至可以說藍綠部署法在 DevOps 出現之前就已經被廣泛採納了。
在藍綠部署法中，工程師會創建兩套完全一樣的環境，並且在兩套環境之前設置一個能指向任一環境的開關。在部署應用時，只需將應用部署在其中一套環境中，然後將流量引導至該環境即可；這樣另一套環境便可以作為備用，以便在出現問題時快速回滾。
2. 金絲雀發布（灰度發布）
「金絲雀發布」是比藍綠髮布更加溫和的方式。二者原理相同，但金絲雀發布的粒度更細。應用了金絲雀發布策略後，工程師可以在不影響生產環境的情況下進行一些實驗。
金絲雀發布策略對放置在前端的引流組件提出了較高要求：引流組件要能夠將一部分的流量分流到新版本的應用，而不能像藍綠部署一樣「一刀切」。
到目前為止，金絲雀發布還屬於一種模式。具體的實現方式需要讀者自行探索。不過，現在市面上也有支持這種發布模式的產品。Vamp.io 便可以依據瀏覽器 UA，設備種類或者用戶所在的地理位置來進行分流。AWS 也在 API 網關服務中提供了金絲雀發布分流服務。
3. A/B 測試
「A/B 測試」是具備統計框架的金絲雀發布。在分流的功能上，A/B 測試和金絲雀發布大體類似，但 A/B 測試引入了「達成目標」的思想。這樣一來，運營人員便可以了解到一個不同的應用版本，或者一個新版本到底有沒有幫我們達成業務目標，以及在多大程度上幫助我們達成目標。
提供 A/B 測試功能的廠商有 Optimizely，Visual Website Optimizer（VWO），Google Optimze；Unbounce，Mailchimp 和 Kissmetrics 等服務中也將 A/B 測試作為一種功能叫付給了用戶。也有一些公司自己構建了 A/B 測試系統，如 Pinterest 和 Booking 等。
不過，上面的產品和服務都把精力專註在了前端展示層（網頁或者郵件等等）。也就是說，用上面的產品，僅僅能測試一些視覺上、或者文字上的效果。如果想要測試應用中的其他部分，現在市面上也有一些可供選擇的產品。
Optimizely X Full Stack 服務就是一套完整的 A/B 測試解決方案，涵蓋了多個開發語言和運行環境。在開源世界，Facebook 開發的 Planout，Intuit 開發的 Wasabi 和 Wix 開發的Petri 也同樣值得關注。
4. 功能開關
「功能開關」在更大意義上是一種平行於以上兩種模式的模式。功能開關模式集合了金絲雀發布和 A/B 測試的某些特性，將其整合為一種基於「開關」的模式。這種「開關」可以隨時開啟和關閉應用中的某些功能，可以作用在所有用戶身上，也可以作用在目標用戶身上。
功能開關的主要優勢在於，它將功能交付與應用發布這兩件事情剝離開來，二者不必同時發生。提供功能開關服務的有 LaunchDarkly 和 Split.io；開源方案有 Java 的 Togglz 和 Ruby 的 Flipper。
5. 影子流量
「影子流量」也被稱為「暗流量」，是在不直接影響用戶的前提下，將一部分流量從生產環境負載中剝離，並引導至某個測試環境的做法。
這種做法多在後端服務中使用，可以在壓力測試，甚至是可用性測試中使用。在編寫本文時，似乎沒有什麼產品或者服務提供影子流量模式；如果希望實現這種模式，完全需要自己定製。開源的中間件項目 「Istio」（與 Kubernets 相關）和 「GoReplay」 也還處在初級階段。
如果要實現影子流量模式，考慮到客戶響應和加密等因素，工程師們必須要考慮網路流量上的一些棘手問題。不過，若把這種模式集成進 Kubernets 等統一的 IT 平台後，其潛力和未來也值得期許。
向「效果驗證平台」邁進
當「驗證模式」在 IT 架構的各個層面廣泛普及後，驗證的粒度變得越來越精細，驗證模式應用的範圍也越來越廣泛。由此也引發了一整套新問題。
如何處理效果驗證時產生的數據？數據分析團隊可不是每家公司都有的。
如何改造 IT 基礎設施，使其能夠滿足以上的實驗模式？要知道，高效的實驗模式很可能需要快速調配計算資源，還可能要調配不同的計算資源。
如何將「效果驗證」規模化，又能保證管理人員進行清晰、有序的管理？
以上這些問題在很大程度上又變成了自動化的問題，因此落入了 DevOps 實踐的範疇。當前，已經有第一批解決這些問題的產品和服務湧現了出來。
1. 機器學習和人工智慧
有人已經開始嘗試使用機器學習和人工智慧技術來解讀 IT 環境產生的日誌和監控數據。雖然這種實踐還處在早期階段，但其前景非常值得期待。
模式識別、模式過濾以及預測分析等均為人們所熟知的數學問題。在 Signifal 和 Logz 提供的 DevOps 產品中我們已經能夠看見這些數學技術的應用。這兩款服務均致力於為用戶消除數據中的干擾因素，讓用戶得以在數據中掘金。
著名的開源搜索引擎 ElasticSearch 最近也添加了機器學習功能，向用戶交付了使用機器學習處理數據的能力。
另一方面，應用機器學習和人工智慧輔助進行應用部署、擴容、功能開關和效果驗證的實踐仍是一塊處女之地，尚未在業界開展。
2. 智能編排 2.0TM
Kubernetes、Docker Swarm 和 Mesosphere DC/OS 等容器平台精確地契合了 DevOps 的新模式。這些平台為用戶提供了可移植、可擴展、高效且統一的部署模式，並為其取了一個好聽的名字：「雲原生」。
此類容器平台成為了「效果驗證導向」的 IT 環境最理想的基礎設施，因為這些平台幾乎滿足了「效果驗證導向」的IT環境的所有要求：
基於（Docker）容器和相關技術的、程序化和標準化的計算環境、網路資源和存儲資源；
基於平台 API 開發的程序化部署流程；
基於中繼網路的智能路由、統一 API 網關、服務發現和服務網格。
向雲原生基礎設施變遷的大幕已徐徐拉開，基於雲原生的應用也逐漸湧現出來。
諸如 Istio 和 Vamp 的產品和框架將智能路由帶入了一個新階段：路由策略成為了動態的、可延展的應用屬性。搭配了監控的智能路由技術正在成為 A/B 測試和影子流量的基石，並且在 DC/OS 和 Kubernetes 平台中有所實現。
應用配載（Bin Packing）技術也在 Kubernetes 和 DC/OS 中有所體現。這種技術可以在物理主機上精確地調配應用進程，最大化利用計算資源，避免浪費。
將這種技術與 AWS Spot 實例結合，能將成本管理帶入一個新境界。利用這一點，成本管理便可以和更高層的業務目標綁定。
很多公司都有規範 IT 成本的成本管理。此外，由於降低了成本，智能編排也有助於企業以更低的代價驗證新產品、拓展新業務。
TAG:DevOps時代 |