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