部署安全：减少变更对客户的影响
Slack 工程团队 | 2025年10月7日
2023年中，我们发现了提升系统可靠性的机会。到了2025年1月，因故障导致的客户影响时长已从峰值下降了90%，并且持续呈下降趋势。这就是Slack“部署安全计划”一年半以来的成果：我们改进了部署方式，提升了安全文化，并持续满足业务变化的速率。
问题定义
随着业务发展，无论是客户期望的变化、负载与规模的扩大还是对业务需求的响应，系统需求都会随之改变。 分析显示了两大关键趋势：
- Slack对我们的客户而言变得愈加关键，他们对产品整体及公司所依赖的特定功能的可靠性期望越来越高。
- 绝大多数（73%）面向客户的事件是由Slack内部的变更触发的，特别是代码部署。
我们在Slack大量且频繁地使用事件管理流程，以确保能根据影响和严重性对各种问题做出强有力且迅速的响应。其中一部分事件会影响客户，许多事件的影响程度因客户使用的产品功能而异。由变更触发的事件发生在各种各样的系统和部署流程中。 此外，我们还收到客户反馈，中断在大约10分钟后会变得更具破坏性——他们会将其视为一次“小故障”——而随着2025年Agentforce的引入，这种情况将继续减少。 所有这些都发生在一个拥有数百个内部服务和许多不同部署系统与实践的软件工程环境中。 过去，我们提升可靠性的方法常常集中在单个部署系统或服务上。这导致了手动的变更流程，拖慢了创新的步伐。变更所需时间和精力的增加不仅打击了工程团队的士气，也阻碍了我们快速满足业务目标的能力。 这促使我们为最高优先级服务的所有部署方法设定了一些初步的“北极星”目标：
- 减少部署带来的影响时长
- 10分钟内自动检测与修复
- 20分钟内手动检测与修复
- 降低影响的严重性
- 在影响到10%的服务器集群前，检测出有问题的部署
- 保持Slack的开发速度
这些初步的北极星目标后来演变为一个适用于Slack所有部署系统和流程的《部署安全宣言》。 这些目标鼓励实施自动化的系统改进、安全护栏和文化变革。
度量指标
计划的推行是为了引发改变，而改变必须被衡量。选择一个作为不完美替代物的度量指标，一直是持续讨论的话题。 北极星目标可以针对工程工作进行衡量，但并非对最终目标（提升客户对Slack可靠性的体验感受）的直接度量。我们需要的是一个能合理（尽管不完美）替代客户感受的指标。我们拥有内部数据来设计这样的指标。 部署安全度量指标： 由高严重性和选定的中严重性变更触发事件所造成的客户影响时长。 “选定”是什么意思？这似乎相当模糊。我们发现事件数据集并不完全符合我们的需求。Slack的严重性级别传达的是当前或即将发生的客户影响，而非最终影响（后者通常需要仔细的事后分析）。这意味着我们需要根据相关的客户影响水平来筛选中严重性事件。 关于使用何种指标的持续讨论，涉及以下三者之间半松散的联系： 客户感受 <-> 计划指标 <-> 项目指标 它们之间相互关联，但很难确定一个具体项目能在多大程度上推动顶层指标。计划指标在多大程度上反映了个体客户的体验？对于更偏好硬数据和具体反馈循环的工程师来说，这种流程尤其困难——即“我的工作或概念变更对客户感受有多大影响？” 设计部署安全指标的重要标准：
- 衡量结果
- 理解所衡量的是什么（真实度量与替代度量）
- 测量的一致性，尤其是主观部分
- 不断验证度量结果与客户感受是否匹配，并让直接与客户对话的领导者参与
投资哪些项目？
计划开始时，我们面临的两个最大未知数是：鉴于事件的多重来源，预测哪些项目最有可能成功，以及每个项目何时能产生影响。事件数据是滞后数据，这意味着我们知道结果会有时间延迟。除此之外，客户当时正在承受痛苦。 这影响了我们的投资策略：
- 初期广泛投资，并偏向于行动
- 首先聚焦已知痛点领域
- 根据结果对项目或模式进行进一步投资
- 减少对影响最小领域的投资
- 制定灵活的短期路线图，并可根据结果进行调整
我们的目标指引我们寻找能影响以下一个或多个方面的项目：
- 在部署流程中更早地检测到问题
- 缩短自动修复时间
- 缩短手动修复时间
- 通过设计隔离边界（爆炸半径控制）来降低问题严重性
我们将Web应用后端归因为变更触发事件的最大来源。以下是为解决Web应用后端部署问题的一个投资流程示例：
- 花费一个季度的工作时间来设计自动指标监控
- 再用一个季度，通过自动警报和手动回滚操作来确认客户影响的对齐情况
- 投资于自动部署和回滚
- 通过多次自动回滚将客户影响控制在10分钟以内来证明成功
- 进一步投资以监控更多指标，并投资于手动回滚优化
- 投资于手动前端回滚能力
- 受到ReleaseBot和AWS Pipelines部署系统的启发，进一步将投资对准Slack的集中式部署编排系统，以统一基于指标的部署与自动修复的使用，并将其从Slack Bedrock / Kubernetes扩展到许多其他部署系统
- 达成成功标准：Web应用后端、前端以及部分基础设施部署现在显著更安全，并显示出持续的季度环比改进
这种尝试、发现成功、然后迭代并将模式复制到其他系统的模式持续为我们带来良好效果。 项目众多，无法一一列举，有些更成功（例如，更快的移动应用问题检测），有些则影响不那么明显。在某些情况下，由于自动化比手动修复改进更成功，我们减少了影响。需要特别指出的是，未达到预期影响的项目并非失败，它们是通过指导投资和了解哪些领域更有价值来促成我们成功的关键输入。并非所有项目都会有同样的影响力，这是有意为之的设计。
成果
客户影响时长（按季度）与渐进目标对比 请注意：我们内部对“影响”的指标跟踪比Slack状态网站上可能显示的中断要细致和敏感得多。 上面的柱状图相当清楚地说明了非线性进展的历程，以及使用基于等待事件发生的滞后指标所带来的困难。 在第一季度工作结束后，我们已经看到了改善，但除了与工程团队沟通该计划外，尚未部署任何变更。一旦项目开始交付变更，我们便在2024年2月至4月间经历了影响的高峰季度。这计划起作用了吗？ 基于Web应用后端基于指标的部署警报（配合手动修复）的早期结果，我们仍然相信我们正在进行的工作将产生预期的影响——否则2024年的影响高峰会更高。我们需要的是自动修复而非手动修复。一旦引入自动回滚，我们观察到了结果的显著改善。我们持续经历着3-6个月的滞后期来观察每个项目的全面影响。 随着时间的推移，目标数值也在不断调整。由于该指标需要滞后的事件数据，目标是根据上一季度交付工作所预期的潜在结果来设定的。这与期望工作一交付就能立即衡量结果明显不同。 我们已再次降低了2025年的目标数值，并期望客户影响更低，重点是通过部署系统的一致性来缓解偶发性尖峰的风险。
经验教训
这个计划需要持续学习和迭代。我们学到了许多重要的经验，每一条对计划的成功都至关重要：
- 确保优先级排序和对齐
- 每4-6周进行一次高管评审，以确保持续对齐并在需要时寻求支持
- 在公司/工程目标（OKR、V2MOM等）中保持高优先级
- 获得高管层的坚实支持，包括积极的项目协调、鼓励和客户反馈
- 对滞后指标保持耐心，并相信即使某些项目未成功，流程也是正确的
- 使用一个从工作交付到度量有数月延迟的指标需要耐心。
- 在等待完整结果的同时，收集指标以了解改进是否至少运行良好（例如，问题检测）。
- 相信你已根据当时掌握的信息做出了最佳决策，并且一旦结果确认，有能力灵活调整路径。
- 人们会推迟采用一项实践，直到他们熟悉或感到舒适为止
- 他们担心遵循未知的路径会使问题变得更糟，即使被保证这是更好的、被推荐的。
- 向多个团队提供直接培训（必要时多次），帮助他们熟悉新工具——“只管回滚！”
- 根据事件期间的经验，持续改进手动回滚工具。
- 经常使用这些工具，而不仅仅是为了应对偶发的最坏情况。事件处理压力很大，我们发现，如果不经常使用来建立熟练度、信心和舒适度，流程和工具就无法成为常规。这就好比一开始就没有构建这个工具/能力。
- 直接接触工程团队至关重要
- 部署安全计划团队直接与单个团队接触，以了解他们的系统和流程，提供改进指导，并鼓励创新和优先级排序。
- 并非所有团队和系统都相同。有些团队很清楚他们的痛点并有想法，另一些则希望改进但需要额外资源。
- 尽可能保持顶层指标的一致性
- 选择一个指标，保持一致，并根据结果验证进行改进。
- 很容易把时间浪费在争论最佳指标上（不存在完美的指标）。
- 保持与工程人员持续、直接的沟通
- 这是我们正在努力改进的一个领域。
- 管理层理解优先级排序和结果，并且作为一个群体保持一致。然而，对于普通工程人员来说，情况并不总是清晰，这揭示了一个更好地对齐的机会。
展望未来
信任是Salesforce和Slack的#1价值观。由于可靠性是信任的关键组成部分，我们打算持续投资Slack的部署安全。
- 改进基于指标的自动部署与修复，以保持积极趋势
- 在Slack的所有部署中更一致地使用部署安全流程，以缓解意外或偶发的客户影响尖峰
- 扩大计划范围，将剩余的手动部署流程迁移到使用部署安全流程的基于代码的部署
该领域正在进行的一些项目示例包括：
- 将集中式部署编排工具扩展到其他基础设施部署模式：EC2、Terraform等等
- 前端的自动回滚
- 指标质量改进——我们是否为每个系统/服务设置了正确的指标？
- 基于AI的指标异常检测
- 进一步推广AI生成的预生产测试
致谢
衷心感谢部署安全团队在过去一年半中的所有成员。 并向众多无法一一列举的团队致以万分感谢，他们承担了或大或小的部署安全项目，以改善我们客户的产品体验。