【51CTO.com快譯】Mike Loukides以圖書形式發表O'Reilly Media出版的《DevOps是什么?》長文時，他取了一個后來眾所周知的副標題：基礎架構即代碼。那篇文章只有20頁，提出了幾個要點：

1. 基礎架構進入到代碼。運行該軟件的云端系統由代碼創建。
2. 運維角色將進入到團隊。
3. 監控進入到平臺。我們通過代碼創建的用于服務軟件的虛擬機將包括內置監控。

8年后，也許是時候問一下這些預測是否屬實、我們學到了什么以及接下來會發生什么。

基礎架構即代碼

Loukides的文章舉了幾個有名的例子，比如Netflix的ChaosMonkey，它們是完成基礎架構工作的成熟的計算機程序。當時最流行的想法是，運維人員將成為正宗的計算機程序員，用Python或Ruby編寫程序來設置將運行應用程序代碼的一系列虛擬機。客戶需要管理資源、規模擴展和可用性等。

事實證明，這很難編寫，調試起來就更難了，而且幾乎不可能繼續運行。

業界確實從幾個方面作出了有力的回應。

首先在2013年的Python大會上，Solomon Hykes和Sebastien Pahl推出了Docker，這是面向Linux系統的輕量級虛擬化工具。一年后，谷歌開源了Kubernetes。Kubernetes和Docker引入了傳統“基礎架構即代碼”之間的一大區別：它們與其說是受代碼驅動，還不如說是受配置和命令驅動。

這方面的流行術語是聲明性DevOps。簡而言之，你無需編寫常規的經典代碼告訴計算機“如何”創建服務器，而是創建一個配置文件來告訴計算機那是“什么”并運行命令。用Kubernetes的術語來說，這是一個清單文件，而不是來自命令行的一系列Kubectl命令，或更糟糕的是運行kubectl命令的Python程序，在無限的“while”循環中運行，試圖監控系統并采取糾正措施。顧問兼培訓師Bob Reselman表示，清單文件將創建可重用的資產，該資產更易于審計和控制。

雖然“基礎架構即代碼”沒有接管軟件的所有方面，但對于促使微服務崛起起到了至關重要的作用，團隊常常可以自行運行微服務。

運維進入到團隊

至少對于微服務而言，可以說運維現在是軟件開發團隊的一部分。也就是說，對于新服務而言，我看到團隊支持他們創建的服務。這倒不是說我接觸的每家組織都如此，而是這些變化并非無處不在。

另一個創新是全新的工作類別，即軟件可靠性工程師或SRE。SRE負責系統可用性、延遲、性能、緊急響應和容量等。他們監控大量網站和服務，并采取糾正措施。這是某種“DevOps”工作，原因是它把軟件開發的嚴謹性帶到了運維。我個人感到有點難過，因為我們發明了一種全新的工作類別，而不是開發團隊和運維團隊協同工作。它似乎確實適用于存在可擴展性問題的大公司。人數較少的小組只是把運維這塊扔給了團隊。

監控進入到平臺

電話與路由器、Web服務器、微服務、數據庫直至物聯網設備之間的許多環節可能會出岔子。Kubernetes方面尚未出現的一件事就是支持我們一直希望的監控。云托管公司確實提供了出色的儀表板，便于查看服務器的運行狀況，但跟蹤消息(這是可觀察性的一部分)是大多數小組要自行計劃的事情。

這可能屬于下一步。

下一步是什么

雖然Windows容器確實管用，至少從理論上來說適用于一款特定的操作系統，但我還沒有看到哪家公司實際使用它。Kubernetes仍然主要是面向Linux系統的解決方案，尤其是面向Web服務器，可能還面向數據庫服務器。眼下，專職工程師將只好習慣于在異構操作環境下工作，在這種環境下傳統運維人員將繼續發揮作用。

然后是監控。有一些軟件包和開源系統(比如Istio)可以檢測云系統，并自動創建監控系統和審計跟蹤。我看到的問題是，它們需要大量的CPU/Member，這在云端意味著大量費用。它們還可能使網絡需求大致翻番。我多次看到一家公司花數萬乃至數十萬美元加上數年的工程師人力來實施一套監控系統，但由于系統需求實際上影響了生產，到頭來只好關閉監控系統。

原文標題：How DevOps has evolved since 2012，作者：Matthew Heusser

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】