部署安全：降低变更对客户的影响

2023年中期，我们发现了一些提升可靠性的机会。快进到2025年1月，客户受影响时长已从峰值减少了90%，并持续呈下降趋势。Slack的“部署安全”项目已开展一年半，它改进了我们的部署方式，提升了安全文化，并保持了满足业务需求的变更速度。

定义问题

随着业务发展，系统需求也在不断变化，这可能源于客户期望、负载规模的变化或对业务需求的响应。本案例分析揭示了两个关键趋势：

Slack对我们的客户而言变得越发关键，这使得客户对整个产品以及其公司所依赖的特定功能的可靠性期望也随之提高。
绝大多数（73%）面向客户的事件是由Slack自身的变更触发的，尤其是代码部署。

在Slack，我们大量且频繁地使用事件管理流程，以确保能根据影响和严重性对所有问题做出强有力和快速的响应。其中一部分事件对客户造成了影响，许多事件的影响程度因客户使用的产品功能而异。由变更触发的事件广泛存在于各种系统和部署流程中。最后，我们还收到了客户的反馈：中断在大约10分钟后会变得更加具有破坏性——他们原本可能将其视为“小故障”——而随着2025年Agentforce的推出，这种情况有望持续减少。所有这一切都发生在一个拥有数百个内部服务和多种不同部署系统与实践的软件工程环境中。过去，我们对可靠性的方法常常局限于个别的部署系统或服务。这导致了手动变更流程，拖慢了我们的创新步伐。变更所需的时间和精力增加，不仅打击了工程团队的士气，也阻碍了我们快速实现业务目标的能力。这促使我们为最重要的服务，跨所有部署方式设定了一些初步的“北极星”目标：

减少部署造成的影响时长
- 10分钟内实现自动检测与修复
- 20分钟内实现手动检测与修复
降低影响的严重性
- 在问题部署达到10%的集群规模前将其检测出来
保持Slack的开发速度

最初的北极星目标已经演变并扩展为一份“部署安全宣言”，现在适用于Slack所有的部署系统和流程。这些目标鼓励实施自动化系统改进、安全护栏和文化变革。

度量指标

项目旨在引发变革，而变革必须被度量。选择一个作为不完美替代品的度量指标，一直是持续讨论的话题。北极星目标可以根据工程努力来衡量，但它们并非最终目标——提升客户对Slack可靠性体验的感受——的直接度量。我们需要的是一个能合理（尽管不完美）替代客户感受的指标。我们拥有设计此类指标的内部数据。 部署安全指标：

由高严重性和部分中等严重性变更触发事件导致的客户受影响时长。

“部分”是什么意思？这似乎相当模糊。我们发现事件数据集并不完全符合我们的需求。Slack的严重性级别传达的是当前或即将发生的客户影响，而非通常需要事后仔细分析的最终影响。这意味着我们需要根据相关的客户影响级别来筛选中等严重性事件。关于使用何种指标的持续讨论，涉及到以下三者之间半松散的关联：

客户感受 <-> 项目指标 <-> 工程指标

它们相互关联，但对于一个具体的工程项目，很难知道它会对顶线指标产生多大影响。项目指标在多大程度上反映了个体客户体验？这种关联对于更喜欢用硬数据获得具体反馈循环的工程师来说尤其困难——即“我的工作或概念在多大程度上改变了客户感受？” 设计部署安全指标的重要标准：

度量结果
理解所度量的内容（实际值 vs 替代值）
保持度量的一致性，尤其是主观部分
持续验证度量指标是否与客户感受相符，并与直接与客户对话的领导者沟通

投资哪些项目？

项目开始时，我们面临的最大未知数是：鉴于事件来源众多，预测哪些项目最有可能成功，以及每个项目何时能产生效果。事件数据是一种滞后数据集，这意味着我们需要延迟一段时间才能知道结果。除此之外，客户当时正承受着痛苦。这影响了我们的投资策略：

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

我们的目标指引我们去寻找能够影响以下一个或多个方面的项目：

在部署流程中更早地检测到问题
缩短自动修复时间
缩短手动修复时间
通过设计隔离边界（爆炸半径控制）来降低问题严重性

我们将Webapp后端归因为变更触发事件的最大来源。以下是为解决Webapp后端部署问题的一个示例投资流程：

用一个季度的时间来构建自动化的指标监控
再用一个季度，通过自动警报和手动回滚操作来确认客户影响的对齐情况
投资于自动化部署和回滚
通过多次自动回滚将客户影响控制在10分钟以内来证明成功
进一步投资以监控更多指标，并投资于手动回滚优化
投资于手动前端回滚能力
进一步的投资方向与Slack的集中式部署编排系统看齐，该系统受ReleaseBot和AWS Pipelines部署系统的启发，旨在将基于指标的部署与自动修复统一起来，从Slack Bedrock / Kubernetes扩展到许多其他部署系统
达到成功标准：Webapp后端、前端以及部分基础设施部署现在已显著更安全，并显示出季度环比持续改善。

这种先尝试、发现成功、然后迭代并将模式复制到其他系统的做法一直为我们带来良好效果。项目太多，无法一一列举，有些更成功（例如，更快的移动应用问题检测），有些则效果不太明显。在某些情况下，由于自动化改进比手动修复改进更成功，我们减少了影响。非常重要的是要注意，那些未能达到预期效果的项目并非失败，它们通过指导投资和帮助我们了解哪些领域更具价值，是我们成功的关键输入。并非所有项目都能产生同样大的影响，这是有意为之。

成果

按季度统计的客户影响与渐进目标对比 请注意：我们内部对“影响”的指标跟踪比可能在Slack状态网站上显示的故障要细致和敏感得多。上面的柱状图相当清晰地讲述了非线性进展的故事，以及使用基于等待事件发生的滞后指标所面临的困难。在第一季度的工作之后，我们已经看到了改善，但除了与工程团队沟通项目情况外，尚未部署任何变更。一旦项目开始交付变更，我们在2024年2月至4月期间迎来了影响的高峰季度。这方法有效吗？我们仍然有信心，基于早期Webapp后端基于指标的部署警报和手动修复的结果，我们正在进行的工作将产生预期效果——否则2024年的影响峰值会更高。我们需要的是自动化而非手动的修复。一旦引入了自动回滚，我们观察到了结果的显著改善。我们继续体验到每个项目需要3-6个月的滞后期才能观察到其全部影响。随着时间的推移，目标数值不断调整。由于该指标需要滞后的事件数据，目标是根据前一季度交付工作所预期的潜在结果设定的。这与期望工作一交付就能度量结果有着显著不同。我们在2025年再次降低了目标数值，并期望通过专注于通过部署系统一致性来降低偶发性峰值风险，以实现更低的客户影响。

经验教训

这个项目需要不断学习和迭代。我们学到了许多重要的经验教训。每一条对于一个成功的项目都至关重要：

确保优先级与对齐
- 每4-6周进行一次高管评审，以确保持续对齐并在需要时寻求支持
- 在公司/工程目标（OKR、V2MOM等）中设定高优先级
- 高管层的大力支持，包括积极的项目对齐、鼓励和客户反馈
对滞后指标保持耐心，并相信即使某些项目未成功，你的流程是正确的
- 使用一个从工作交付到度量结果延迟数月的方法需要耐心。
- 在等待最终结果的同时，收集指标以确认改进至少运行良好（例如，问题检测）。
- 相信你已经根据当时掌握的信息做出了最佳决策，并具备在结果确认后改变路径的敏捷性。
人们会推迟采用某项实践，直到他们熟悉或感到舒适为止
- 他们担心如果遵循未知的路径，即使被告知这更好且被推荐，也可能使问题恶化。
- 为多个团队提供直接培训（必要时多次），帮助他们熟悉新工具——“直接回滚就好！”
- 根据事件中的经验，持续改进手动回滚工具。
- 经常使用这些工具，而不仅仅是在罕见的极端情况下使用。处理事件压力很大，我们发现，如果不经常使用来建立流畅性、信心和舒适感，流程和工具就不会成为常规。这就好比当初根本没有构建这个工具/能力一样。
直接联系工程团队至关重要
- 部署安全项目团队直接与各个团队接触，了解他们的系统和流程，提供改进指导，并鼓励创新和优先级排序。
- 并非所有团队和系统都一样。有些团队非常清楚他们的痛点所在并已有想法，有些则希望改进但需要额外资源。
尽可能保持顶线指标的一致性
- 选定一个指标，保持一致，并根据结果验证进行优化
- 很容易在争论最佳指标上浪费时间（并不存在完美的指标）
与工程人员保持一致的直接沟通
- 这是我们正在努力改进的领域
- 管理层理解优先级和结果，并且作为一个团队很好地达成了对齐。然而，对于普通工程人员来说，情况并非总是清晰，这揭示了一个实现更好对齐的机会。

展望未来

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

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

该领域一些正在进行中的项目示例包括：

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

致谢

非常感谢部署安全团队在过去一年半中的所有成员，以及众多为改善客户产品体验而承担大大小小部署安全项目的团队。