部署安全：减少变更对客户的影响

2023年中，我们识别了提升可靠性的机会。到2025年1月，客户影响时间从峰值减少了90%并持续下降。经过一年半的部署安全计划，我们改进了部署方式，提升了安全文化，同时保持业务所需的变更速度。

问题定义

随着业务发展，系统需求不断变化——无论是客户期望变化、负载规模增长还是业务需求响应。

分析显示两个关键趋势：

• Slack对客户变得更加关键，提高了对整个产品可靠性和各公司依赖特定功能的期望
• 面向客户的事故中，越来越多（73%）由Slack自身变更触发，特别是代码部署

我们频繁使用事故管理流程确保对各种问题做出快速响应。部分事故会影响客户，影响程度因使用功能而异。变更触发的事故出现在各种系统和部署流程中。

客户反馈显示，超过10分钟的中断会变得更具破坏性——他们称之为"小故障"——这一情况将随着2025年Agentforce的推出而改善。

所有这些都发生在拥有数百个内部服务和多种部署系统与实践的软件工程环境中。

过去，我们的可靠性方法常专注于单个部署系统或服务，导致手动变更流程拖慢创新速度。变更所需的时间和精力增加不仅影响工程士气，也阻碍快速实现业务目标。

初始目标

我们为最重要服务设定了跨所有部署方法的"北极星"目标：

减少部署影响时间

• 10分钟内自动检测和修复
• 20分钟内手动检测和修复

降低影响严重性

• 在达到10%集群前检测问题部署

保持Slack的开发速度

这些初始目标最终发展成适用于所有Slack部署系统和流程的部署安全宣言，鼓励实施自动化系统改进、安全防护栏和文化变革。

度量指标

项目需要引发变革，而变革必须被衡量。选择不完美的类比指标一直是持续讨论的话题。

北极星目标可以衡量工程努力，但不能直接衡量最终目标：改善客户对Slack可靠性的感受。我们需要一个能合理类比客户感受的指标。

部署安全指标： 高严重性和选定中等严重性变更触发事故造成的客户影响小时数。

“选定"意味着什么？我们发现事故数据集不完全匹配需求。Slack的严重级别传达当前或即将发生的客户影响，而非最终影响（通常需要事后分析）。这意味着我们需要基于相关客户影响水平过滤中等严重性事故。

投资策略

项目开始时最大的未知是预测哪些项目最可能成功，以及每个项目何时产生效果。事故数据是滞后数据，我们知道结果会有时间延迟，而客户当时正在经历问题。

这影响了我们的投资策略：

• 初期广泛投资并偏向行动
• 首先关注已知痛点领域
• 基于结果对项目或模式进一步投资
• 减少对影响最小领域的投资
• 设定灵活的短期路线图，可根据结果调整

目标引导我们寻找能影响以下方面的项目：

• 在部署流程中更早发现问题
• 改进自动修复时间
• 改进手动修复时间
• 通过设计隔离边界降低问题严重性

实施案例

我们将Webapp后端确定为变更触发事故的最大来源。以下是对Webapp后端部署的投资流程示例：

• 一季度：工程自动指标监控
• 另一季度：通过自动警报和手动回滚确认客户影响对齐
• 投资自动部署和回滚
• 通过多次自动回滚将客户影响控制在10分钟内证明成功
• 进一步投资监控额外指标和手动回滚优化
• 投资手动前端回滚能力
• 对齐进一步投资到Slack集中部署编排系统，受ReleaseBot和AWS Pipelines启发，将基于指标的部署与自动修复统一扩展到Slack Bedrock/Kubernetes之外的许多其他部署系统
• 达成成功标准：Webapp后端、前端和部分基础设施部署现在显著更安全，并显示季度持续改进

这种尝试、发现成功，然后迭代+复制到其他系统的模式持续为我们服务良好。

成果

客户影响按季度与渐进目标对比

请注意：我们内部"影响"指标跟踪比Slack状态网站上可能符合的中断要更细粒度和敏感。

柱状图讲述了非线性进展的故事和使用基于等待事故发生的滞后指标的困难。

工作第一个季度后我们已经看到改进，但除了与工程团队沟通项目外尚未部署任何变更。项目开始交付变更后，我们在2024年2月至4月间经历了影响峰值。这有效吗？

基于Webapp后端指标部署警报与手动修复的早期结果，我们仍有信心工作会产生预期影响——否则2024年的影响峰值会更高。我们需要的是自动而非手动修复。一旦引入自动回滚，我们观察到结果的显著改善。我们持续经历3-6个月的滞后期来观察每个项目的全面影响。

经验教训

这个项目需要持续学习和迭代。我们学到了许多重要经验：

确保优先级和对齐

• 每4-6周执行审查确保持续对齐并在需要时寻求支持
• 公司/工程目标中的高优先级（OKR、V2MOM等）
• 执行领导层的坚实支持

对滞后指标保持耐心

• 使用工作交付后延迟数月的测量需要耐心
• 收集指标了解改进是否至少运行良好
• 相信你基于当时信息做出了最佳决策，并在结果确认后灵活调整路径

人们会延迟采用实践直到熟悉

• 他们担心遵循未知路径会使问题恶化
• 提供直接培训（必要时多次）帮助团队熟悉新工具
• 持续改进手动回滚工具响应事故经验
• 经常使用工具，不仅为罕见的最坏情况

直接接触工程团队至关重要

• 部署安全项目团队直接与个别团队接触，了解他们的系统和流程
• 并非所有团队和系统都相同

保持顶级指标尽可能一致

• 选择指标，保持一致，基于结果验证进行改进
• 很容易在讨论最佳指标上浪费时间

保持与工程人员的一致、直接沟通

• 这是我们正在改进的领域
• 管理层理解优先级和结果并很好对齐，但普通工程人员并不总是清楚

未来展望

信任是Salesforce和Slack的首要价值。由于可靠性是信任的关键部分，我们打算持续投资Slack的部署安全。

• 基于自动指标的部署和修复改进以保持积极趋势
• 在所有Slack部署中更一致地使用部署安全流程，减轻意外或不频繁的客户影响峰值
• 改变项目范围，包括将剩余手动部署流程迁移到使用部署安全流程的基于代码的部署

该领域一些持续项目的例子包括：

• 集中部署编排工具扩展到其他基础设施部署模式：EC2、Terraform等
• 前端自动回滚
• 指标质量改进——我们是否为每个系统/服务设置了正确的指标？
• 基于AI的指标异常检测
• AI生成的预生产测试进一步推广

致谢

感谢部署安全团队所有成员，以及承担大大小小部署安全项目以改善客户产品体验的众多团队。