Slack 工程团队发表了一篇博文，深入分析了他们近期对基于Chef的配置管理系统所做的改进，目的是在不干扰现有工作流程的情况下，使部署更安全、更有弹性。更新后的基础设施消除了单点故障，并在可用区之间引入了分阶段的环境感知型部署流程，降低了在资源配置和配置变更过程中发生大规模故障的风险。
以前，Slack 的 EC2 配置依赖于单一的共享 Chef 生产环境。尽管通过 cron 任务将集群中的 Chef 运行错开可以减少并发，但任何对中央环境的不良更改都可能立即传播到新配置的节点，尤其是在快速横向扩展期间，这会带来显著的可靠性风险。为解决这个问题，Slack 将单体的 Chef 生产环境拆分为多个独立的单元（如 prod-1 至 prod-6），每个单元绑定到特定的可用区。该策略可以确保配置变更每次仅影响一个相对比较小的节点子集，有效地限制了影响范围，从而可以实现更安全的故障检测与修复。
Slack 还调整了触发 Chef 运行的方式。由于分阶段环境不再兼容固定的 cron 计划，工程师构建了一个名为 Chef Summoner 的服务。Chef Summoner 在每个节点上运行，通过增强版Chef Librarian服务触发的 S3 事件监听信号，并且仅在有新工件可用时调度 Chef 运行。为了避免负载峰值和资源争用，该服务采用 splay value 使任务执行在相互隔离的节点上错开进行。如果没有检测到新工件，为了确保合规性，Chef Summoner 将至少每 12 小时运行一次，即使是在静默期也能保障运营安全。
新发布模型采用了面向分阶段环境的发布序列模式。首先，Slack 将新的 cookbook 更改推广到沙箱和开发环境，然后逐步推广到 prod-1（被视为金丝雀），再然后是剩余的生产分片。因为 prod-1 接收频繁的小范围更新，所以在问题影响集群的更大部分之前就能被及早发现。只有在成功通过早期阶段后，后续环境才会更新。这进一步降低了风险，并使运维团队能够在问题广泛传播之前捕捉和修复回归。
这些更改体现了 Slack EC2 配置平台的渐进式演变，既提高了安全性，又不需要对现有的 cookbook 或角色做破坏性的大幅修改。展望未来，Slack 计划推出一个新的 EC2 生态系统，名为 Shipyard，旨在支持服务级部署、指标驱动的发布和完全自动化的回滚，解决当前架构中仍然存在的限制，并使平台能为尚未迁移到容器化环境的团队提供更好的支持。
Slack 的方法展示了如何通过精心构建的部署管道和环境分割来减轻大型动态基础设施生态系统中的操作风险。结合分阶段的生产环境、信号驱动的运行和 cron 安全网等回退机制，该公司提高了基础设施的可靠性，而又没有对开发和运维团队造成重大干扰——其他大型组织在演变自己的配置管理策略时可能会发现这种模式具有指导意义。
Slack 的做法体现了整个行业向更安全的渐进式大规模基础设施变更方式转变的趋势。Netflix、Uber 和 GitHub 等公司通过金丝雀发布、分阶段部署和功能开关等机制，在真实生产流量环境下验证变更并限制更新的影响范围。Slack 将类似的渐进式交付原则应用于其基于 Chef 的基础设施，展示了如何在无需进行颠覆性平台变更的前提下，通过现代化传统配置管理系统来提升安全性和可靠性。
为了降低部署风险，许多大型工程组织都采用渐进式的方法来推广技术。例如，金丝雀部署首先将更改暴露给一小部分用户或工作负载，允许团队在扩展发布范围之前监控性能和错误率。这种策略在 LinkedIn 等公司被广泛使用，通常与功能标志（将代码部署与功能暴露解耦）搭配，使团队能够在不重新部署的情况下快速回滚。
其他公司，包括 Netflix、Uber、GitHub 和 Etsy，通过功能标志、蓝绿部署和不可变基础设施扩展了这种模型，整个环境在流量转移之前都经过验证。在云原生环境中，像Kubernetes和ArgoCD这样的工具支持分阶段发布和同步波（synchronization wave），可以防止突然的负载峰值并控制更改传播。
这些方法的共同原则与 Slack 的交错式 Chef 策略类似：限制影响范围，在小范围内观察行为，并逐步扩展更改。通过应用分层发布控制，团队在运营大规模基础设施时实现了速度和可靠性的平衡。
原文链接：
