DevOps 文字培训

如何在生产环境中实现低风险的 DevOps 代码部署？

在许多 IT 组织中，生产部署麻烦且压力很大。为了避免出问题，组织往往尽量减少生产部署的频率。结果是，组织不可避免地要处理更大批次的部署，从而引发更大的问题。这种恶性循环不断加剧，遗憾的是，它反映了许多最大型组织的现状，包括以软件和技术为核心业务的组织。

DevOps 团队内置控制和风险缓解机制

在典型 IT 组织中，开发团队构建软件，运维团队负责部署。DevOps 方法则将控制和风险缓解从其他独立团队转移到你自己有能力自主开展工作的团队，依靠团队内部的自动化部署和同行评审流程。

所有生产与非生产环境都是资产，与 DevOps 团队开发的软件同样重要。因此，团队遵循三项重要原则：

1. 确保所有环境的操作系统、组件、接口、补丁级别、其他依赖项以及自有软件与配置保持一致。
2. 修复破坏环境一致性的障碍是首要任务。
3. 在所有环境中使用相同的部署方法，将生产部署演练变成日常工作和习惯。

内置自助式部署机制

自动化自助部署机制遵循以下模式。

1. 编写代码并提交到主干。
2. 构建可部署的软件包。
3. 验证可部署的软件包、依赖项及配置是否就绪。
4. 验证环境是否就绪。
5. 运行自动化测试。
6. 记录所有验证结果和自动化测试结果，以备审计并满足合规要求。
7. 将软件包部署到目标环境。
8. 在目标环境中运行自动化测试，验证部署。
9. 监控目标环境的系统、性能和活动指标。
10. 快速提供反馈，出现问题时修正或回滚部署。

部署和发布是不同的操作

通过自动化自助部署机制将代码部署到非生产和生产环境后，DevOps 团队就可以每天向系统部署。并非每一次部署都算是向团队服务的客户发布功能或提供收益，因此 DevOps 团队需要设计应用和/或环境的架构，使发布无需变更代码或进行相关后续部署。

蓝绿部署模式

自动化部署的一大挑战是切换本身，即将软件从最终测试阶段转入实际生产。通常需要快速完成切换，以尽量减少停机时间。蓝绿部署方法通过建立两个尽可能相同的生产环境来做到这一点。任意时刻都有一个环境在线，这里以蓝环境为例。准备软件的新版本时，在绿环境中进行最终测试。软件在绿环境中正常工作后，切换路由器，让所有传入请求转到绿环境，蓝环境则进入空闲状态。

金丝雀部署模式
（又称暗发布）

过去，煤矿中经常使用金丝雀作为预警手段。矿井中的甲烷或二氧化碳等有毒气体会在影响矿工前让鸟儿死亡。鸟儿表现出不适，就是矿井条件不安全的信号。

受采矿业使用金丝雀的做法启发，金丝雀部署是一种先向部分用户或服务器推出版本的模式。先将变更部署到少量服务器，经过测试后再推广到其余服务器。金丝雀部署能提供早期预警，减少停机影响：如果金丝雀部署失败，其余服务器不会受到影响。

Facebook、Google 及许多领先科技巨头使用一种名为“暗发布”的金丝雀部署模式。它们先向小部分用户逐步发布并测试新功能，然后才向所有人发布。这使它们可以了解你喜欢还是讨厌这项功能，并评估其对系统性能的影响。Facebook 将其暗发布工具称为“Gatekeeper”，因为它控制用户对各项新功能的访问。

之所以叫暗发布，是因为发布这些功能通常不会对外宣传，而是先悄悄推出给 1% 的用户，然后扩大到 5%、30%，依此类推。有时，新功能暗发布几天后，你就再也见不到它了。这可能是因为它的表现不佳，也可能是公司只想收集初步反馈来指导开发。

集群免疫系统发布模式

此发布模式是金丝雀部署模式的扩展。它要求性能和软件活动监控系统与你的发布流程紧密集成。

在上图所示的金丝雀部署模式中，橙色服务器上的初始部署完成后，监控系统会记录所有系统、性能和软件活动指标。如果问题增多并超出设定阈值，监控系统会发出预警，从而自动回滚橙色服务器上安装的代码。

如果橙色服务器上的自动化测试和监控系统都给出良好结果，DevOps 团队就能更有信心将代码部署到其余所有蓝色服务器集群。概括而言，集群免疫系统发布模式为 DevOps 团队提供了：

• 为测试自动化可能遗漏的问题提供额外保障。
• 快速反馈生产问题并自动执行回滚。

功能开关

可以使用功能开关启用或停用应用功能。因此，一旦某项功能所需的全部代码已部署到生产系统，只需打开开关即可发布这项功能。功能开关通常是运行时系统配置文件或系统配置数据库中的设置。

如果金丝雀部署导致错误或不理想的用户体验，功能开关允许 DevOps 团队关闭功能。若系统遇到扩展困难，也可以禁用资源占用高但相对不太重要的功能。即使系统无法在所有功能同时运行的情况下顺利扩展，也仍能确保客户从软件最关键的功能获得最佳吞吐量。例如，在电商门户中，可以暂时关闭查看发票的功能开关，为结账流程腾出更多 CPU 和内存资源。

此外，在面向服务的架构中，DevOps 团队可以部署不同版本的服务，而无需立即启用它们。部署完新功能或服务流程所需的全部新版本服务后，再打开这些服务的开关，启用新的服务流程。

设计支持更安全发布的架构

没有一种完美架构能适用于所有规模的所有软件产品与服务。

初创组织刚构建 IT 平台时，通常首选单体架构，以便尽快、尽可能低成本地进入市场并验证商业论证。单体架构的问题在于，功能上可区分的各个方面（核心功能、辅助功能、用户与系统接口及集成）彼此交织，未形成架构上相互独立的组件。Amazon、Google、Facebook 和 Ebay 等许多大型组织在发展过程中不得不放弃单体架构，以便快速扩展，并以低风险方式发布、拓展面向客户的功能。接下来，它们转向面向服务（或微服务）的架构，并采用绞杀者应用模式。

通过绞杀者应用模式实现低风险微服务迁移

完全替换一个复杂系统可能是项庞大的工程。通常需要逐步迁移到新系统，同时保留旧系统处理尚未迁移的功能。然而，运行同一个应用的两个不同版本，意味着客户端必须知道特定功能位于哪里。每次迁移一个功能或服务，都需要更新客户端，让它指向新的位置。

绞杀者应用模式使用新应用和服务逐步替换特定功能。创建一个外观层，拦截发往后端遗留系统的请求。外观层将请求路由到遗留应用或新服务。现有功能可以逐步迁移到新系统，使用者可以继续使用同一个接口，感受不到迁移。

Ebay 是最早使用绞杀者应用模式，将遗留单体架构迁移为微服务的组织之一。他们开始时只是把应用放到 Ebay 生态中定义明确的通用 API 后面，这样无需在一次迁移中重写全部现有代码。他们把工程部门重组为由 6 至 10 名工程师组成的小团队。如今，一支最多 10 人的团队就能负责拍卖平台的通用 API，这是全球使用最频繁的拍卖 API。

总结

在大多数 IT 部门，团队无须负责构建能够适应未来、可扩展且更安全的部署模式和相关架构。然而，构建能让团队更快、更安全地部署的架构与应用功能，是成功实施 DevOps 的一项重要前提。

只有让团队能够每天更快地进行低风险部署，你和团队才能享受持续部署与顺畅发布带来的好处。