[[256891]]

2018年對于DevOps社區來說無疑是重要的一年。Kubernetes成為第一個從云原生計算基金會(簡稱CNCF)畢業的項目;Pivotal公司完成了首輪公開募股;HashiCorp以19億美元成為獨角獸公司;VMware以近6億美元價碼收購Heptio等等。這一系列事件的出現，再次強調了DevOps浪潮的重要意義。

去年1月，我們發布的微服務發展趨勢預測涵蓋了Service Meshes、事件驅動型架構、容器原生安全、GraphQL以及混沌工程等議題。雖然這些技術越來越受到歡迎，但我們在隨后的這一年中也觀察到了其它一些新興趨勢：1)測試自動化;2)持續部署/驗證(簡稱CD/CV);3)事件響應;4)云服務費用管理(簡稱CSEM);5)Kubernetes面向機器學習(簡稱ML)的擴展等。

1. 方興未艾的測試自動化

從傳統角度講，由個人設計的測試用例主要用于確定軟件是否能夠在不同情況下正確運行。在通常情況下，質量保證(簡稱QA)工程師負責創建并運行此類測試用例。但到現在，由于測試驅動開發的興盛，軟件工程師正在逐漸接過傳統QA團隊的測試職責。換言之，開發人員開始在整個持續集成(簡稱CI)流程中執行測試。很明顯，測試會給開發人員帶來新的負擔，進而降低其生產效率水平。

我們相信企業需要一種能夠自動設計、運行并報告結果的軟件測試解決方案。通過對接持續集成系統，實時檢查新代碼以及添加與人類工程師類似的注釋內容，這類解決方案需要有能力實現無摩擦介入。另外根據我們的觀察，這類測試解決方案還應通過用戶界面(簡稱UI)進行測試，以確保工程師能夠通過UI查找問題并減少漏報機率。

軟件測試自動化的實現將有助于減少修復錯誤所需要的資源。一旦自動化軟件識別出錯誤，其即可自動生成錯誤修復程序。簡單的錯誤可以通過自動補丁修復，而復雜的錯誤則可利用人工設計的模板或者“基于異常的修復”解決——這些修復機制會對代碼進行小幅更改，直到問題徹底消失。此外，推薦引擎能夠利用先前工程師修復的數據進行訓練，并在人工批準之前預先測試以提供明智的建議。

我們相信，軟件測試應該是人工智能技術的一大重要應用方向，能夠幫助業界顯著提高生產力、改善成本、覆蓋范圍與準確性。我們之前已經表達過對于機器學習支持型軟件測試方案的興奮之情，現在我們仍然堅信這將是一個巨大的市場(總價值約32億美元)，且正在逐步走向成熟。

2. 通過持續部署/驗證提高生產力

企業將繼續感受到軟件發布周期加速要求帶來的壓力。持續部署(簡稱CD)允許我們將測試完畢的代碼自動部署至生產環境當中。與持續交付這套用于確保代碼快速安全部署至生產環境的一整套設計實踐不同，持續部署僅關注其中與部署相關的管理任務，旨在為下一步工作提供堅實的基礎。

持續部署將取代DevOps工程師的手動操作。根據我們了解到的情況，在一部分金融機構當中，每十位DevOps員工中就有一位負責面向生產環境的軟件部署任務。假設持續部署軟件能夠幫助其擺脫這些繁瑣的工作，即意味著將全球DevOps員工的價值提升10%，我們認為這部分市場的總規模將接近20億美元。

持續驗證(簡稱CV)在持續部署之上進一步添加智能層。持續驗證負責從日志及APM當中收集事件數據，并應用機器學習技術以了解導致部署成功及失敗的相關因素。持續驗證應該具備人機循環組件，確保工程師能夠提供反饋以提高模型準確性，同時逐步建立起對系統的信任度。持續驗證通常能夠安全地對失敗部署進行回滾操作。我們相信未來的持續驗證方案將幫助持續部署成為多云環境內的智能控制點，提供預測功能，面向云、區域以及配置提供最佳洞察見解，并根據具體特征實施部署服務調整。

雖然目前已經存在諸多持續部署解決方案，但我們還是在下圖當中列出了其中最受歡迎的十四款。其中包括閉源與開源項目，以及由公有云服務供應商提供的托管服務。這一領域中最為著名的解決方案當數Spinnaker，這個開源項目目前已經在GitHub上得到超過5600顆星。

3. 恢復性事件響應

站點可靠性工程師(簡稱SRE)主要負責管理復雜分布式系統的響應工作，此類系統往往面對彈性方面的實際挑戰。根據谷歌公司發布的《站點可靠性工程》一書所言，站點可靠性工程師需要負責以自動化方式執行以往需要由系統管理員手動執行的流程。他們負責建立起面向“可用性、延遲、性能、效率、變更管理、監控、緊急響應以及服務的容量規劃方案”。很明顯，應急/事件響應亦是站點可靠性工程師份內的關鍵任務之一。

停機時間是一類具有重大財務影響的事件，因此加快問題解決速度變顯得非常重要。Gartner公司指出，由停機時間引起的平均營收損失高達每分鐘5.6萬美元。而像亞馬遜這樣的大型網絡資產持有方每分鐘停機事故可能帶來22萬美元損失。在服務停止運營的每分每秒，企業都在蒙受巨額經濟損失以及嚴重的品牌形象影響。

當服務發生故障時，擁有不同職能角色的響應團隊(包括事件指揮官)將收到警報，進而啟動一系列工作流程。事件指揮官負責維護一份涵蓋事件描述、狀況走向與修復結果的“事件狀態文件”。每一位團隊成員都應針對預先定義的模板化程序執行問題解決流程。一旦問題得到解決，團隊還應參與事后分析，從而了解事件情況并盡可能避免其再次發生。谷歌公司建議團隊應記錄“事件本身、相關影響、為了緩解或解決事件所采取的行動、引發事件的根本原因以及有助于防止事件再次發生的事后行動”等，這將成為重要的后續指導素材。

我們經常聽到站點可靠性工程團隊利用PagerDuty、Slack、Jira、谷歌文檔以及知識庫等載體進行事件響應處理。我們相信這些精確的解決方案能夠在端到端SaaS平臺中被綁定在一起，從而支撐起自動化修復行動并貫徹最佳實踐指導。這套統一的平臺還將加速平均恢復時間(簡稱MTTR)、協作與知識共享的實施速度。

我們已經確定了五種能夠提供現代事件響應功能的解決方案。這些集中式平臺不僅能夠分解職能角色并啟動工作流程，同時亦應說明事件的潛在影響、當前狀態、事件時間表以及超時后果。我們相信，這些平臺可以作為混沌工程的有力補充(混沌工程是一種彈性測試最佳實踐方案)。著眼于未來，這些平臺還有望將事件信息輸入至混沌工程解決方案(例如Gremlin)當中，從而告知應對哪些服務進行預防性測試。這類平臺的持續完善將顯著提高后端彈性水平，最終幫助運營工程師們更安心地享受晚間時光。

4. 云服務費用管理(簡稱CSEM)助力成本節約

時至今日，公有云成本管理已經成為少數不僅給工程與IT團隊帶來深刻影響，更在整個公司內得到高度關注的挑戰之一。大多數企業目前都采用混合云方法，但單純使用公有云方案的客戶正在快速增加。根據Gartner公司的統計，IaaS與PaaS全球收入將由2018年的462億美元增長至2018年的907億美元，年均復合增長率高達25%。Rightscale公司發布的報告亦指出，在接受調查的997名IT專業人員當中，有92%正在使用公有云，81%在使用多云策略。事實上，公有云確實能夠帶來一系列重要收益，包括安全性與可用性提升，降低運營及公共資源的支出與成本等等。隨著公有云的進一步普及以及采用度的快速提高，我們認為成本管理與預測能力的重要性將得到進一步凸顯。

由于種種原因的共同作用，云成本管理成為一項極具挑戰的工作。有不少團隊已經開始使用公有云服務，但監督機制還沒有跟上，于是把云方案強行變成了某種影子IT產物。這種治理缺失可能導致服務蔓延。面對來自上級的“快速行動”與績效要求壓力，開發人員可能會在個人評估過程中忽視成本問題。服務的廣度與頻繁的價格變化同樣使得云開支追蹤變得極為困難。一部分云賬單中包含超過10億條支出線，這意味著一般的企業幾乎不可能對其做出準確解析。面對這一系列挑戰，Gartner公司做出總結，表示“到2020年，將有80%的組織遭遇云IaaS預算超標的問題。”

在下圖當中，我們整理出十八種代表公有云與第三方服務的云服務費用管理解決方案選項。其中VMware拿出了CloudHealth，后者于2018年8月接受了虛擬巨頭5億美元的收購開價。Azure于2018年以5000萬到7000萬美元的價格買下Cloudyn，并將其產品重新命名為Azure Cost Management。2019年1月初，亞馬遜公司收購TSO Logic用以充實自家產品組合。2018年，Forrester公司發布的《云成本監控與優化》報告對九大供應商進行了分析，其中VMware CloudHealth與Rightscale占據領先位置。

盡管目前云成本管理解決方案的數量已經相當可觀，但成本控制仍是一個難以解決的痛點。運營人員經常向我們抱怨稱，云服務費用管理工具應該實現跨平臺結果規范化，并將云資源映射至特定的所有者及團隊處，以確保財務部門能夠將支出與特定產品或業務單位對應起來。Gartner公司表示，如果缺少這種有效的管理能力，云服務的綜合利用率很可能會長期低于35%。另外，此類解決方案還應確定出優化空間，例如由云服務費用管理工具識別過度配置或者長期空閑的資源。該軟件需要支持保留與競價實例、實例規模持續調整、退單、設置自定義折扣功能以及標記異常支出等等。此外，其還需要根據增加的流量、數據存儲要求以及服務利用率來預測特定時間段內的支出水平。隨著公有云資源使用量的不斷增加，我們預計成本管理與預測的重要性也將同步提升。

5. Kubernetes面向機器學習的擴展

Kubernetes正風靡整個DevOps世界，并已經成為當前容器領域的首選編排解決方案。其適用范圍不斷擴大，而我們也希望其能夠成為機器學習平臺堆棧中的組成部分。舉例來說，谷歌公司發布了開源Kuberflow，其通過向集群之內添加定制化資源定義(簡稱CRD)的方式擴展Kubernetes API，從而提高機器學習工作負載的執行優先級。在KubeCon西雅圖2018大會期間，Kubeflow成為最受關注的云原生項目之一。事實上，谷歌并非唯一一家做出探索的廠商。Lyft也在利用Kubernetes構建起自己的機器學習平臺。我們聽說，亦有其它獨角獸企業嘗試對Kubernetes進行標準化，從而將其作為機器學習與分析工作負載的處理平臺。

我們將在明年的這個時候繼續關注測試自動化、持續部署/持續驗證、事件響應、云服務費用管理以及Kubernetes面向機器學習的擴展等議題。如果您自己或者朋友供職于探索這些領域的開源項目或初創企業，也期待著您能夠結合自身體會談談看法。最后，期待看到您的評論，包括我們可能沒有談到的重要內容或者是您對于上述問題的不同觀點。感謝閱讀!

原文鏈接：https://medium.com/memory-leak/5-microservices-trends-to-watch-in-2019-fd2dbd33780d