[[256891]]

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

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

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

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

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

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

我們相信，軟件測試應(yīng)該是人工智能技術(shù)的一大重要應(yīng)用方向，能夠幫助業(yè)界顯著提高生產(chǎn)力、改善成本、覆蓋范圍與準確性。我們之前已經(jīng)表達過對于機器學(xué)習(xí)支持型軟件測試方案的興奮之情，現(xiàn)在我們?nèi)匀粓孕胚@將是一個巨大的市場(總價值約32億美元)，且正在逐步走向成熟。

2. 通過持續(xù)部署/驗證提高生產(chǎn)力

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

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

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

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

3. 恢復(fù)性事件響應(yīng)

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

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

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

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

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

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

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

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

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

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

5. Kubernetes面向機器學(xué)習(xí)的擴展

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

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

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