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.0 TM

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 成本的成本管理。此外，由于降低了成本，智能编排也有助于企业以更低的代价验证新产品、拓展新业务。