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

2023年中，我们发现了提升系统可靠性的机会。时间快进到2025年1月，客户影响时长已从峰值降低了90%，并且持续呈下降趋势。我们在Slack实施“部署安全计划”已有一年半，该计划旨在改进我们的部署方式，提升安全文化，并保持变革速度以满足业务需求。

问题定义

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

在此案例中，分析揭示了两个关键趋势：

Slack对我们的客户而言已变得更为关键，这提升了客户对整个产品以及每个公司所依赖的特定功能的可靠性期望。
绝大多数（73%）面向客户的事件是由Slack主动发起的变更（特别是代码部署）所触发的。

我们在Slack大量且频繁地使用事件管理流程，以确保根据影响和严重程度对所有类型和规模的问题都能做出有力且快速的响应。其中一部分事件会影响客户，许多事件的影响程度因客户使用的产品功能而异。由变更触发的事件发生在各种不同的系统和部署流程中。

最后，我们还收到了客户反馈，称中断在持续约10分钟后会变得更具破坏性——之前他们可能将此视为“小故障”——而随着2025年Agentforce的引入，这种影响将进一步降低。

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

过去，我们应对可靠性的方法常常局限于单个部署系统或服务。这导致了拖慢我们创新步伐的手动变更流程。变更所需的时间和精力增加不仅打击了工程团队的士气，还阻碍了我们快速实现业务目标的能力。

这促使我们为最高优先级服务的所有部署方法设定了一些初步的“北极星”目标：

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

这些初步的北极星目标后来发展并扩展成了一份《部署安全宣言》，现在适用于Slack所有的部署系统与流程。这些目标鼓励实施自动化系统改进、安全护栏和文化变革。

度量指标

计划的实施是为了引发变革，而变革必须被衡量。选择一个虽不完美但能作为近似参照的度量指标，一直是我们持续讨论的话题。

北极星目标可以用来衡量工程工作的成效，但并非对最终目标的直接衡量：即提升客户对Slack可靠性体验的感受。我们需要的是一个能够合理（尽管不完美）地近似反映客户感受的度量指标。我们拥有设计这样一个指标的内部数据。

部署安全度量指标： 因高严重性和选定的中严重性变更触发事件所造成的客户影响时长。

“选定”是什么意思？这似乎相当模糊。我们发现，事件数据集并不完全符合我们的需求。Slack的严重性级别传达的是当前或即将发生的客户影响，而非通常需要仔细事后分析才能确定的最终影响。这意味着我们需要根据相关的客户影响级别来筛选中严重性事件。

关于使用何种度量指标的持续讨论，涉及以下三者之间半松散的关联：客户感受 <-> 计划度量指标 <-> 项目度量指标

它们相互关联，但很难针对特定项目确定其能在多大程度上推动顶层指标。计划度量指标能在多大程度上反映个体客户的体验？这种关联对于偏好使用硬数据获得更具体反馈循环的工程师来说尤其困难——例如，“我的工作或理念在多大程度上改变了客户的感受？”

设计部署安全度量指标的重要标准：

衡量结果
理解所衡量的是什么（真实情况 vs. 近似参照）
衡量方法的一致性，尤其是主观部分
持续验证衡量结果与客户感受是否匹配，由直接与客户对话的领导者负责

投资哪些项目？

在计划启动之初，我们面临的两个最大未知数是：鉴于事件来源多样，预测哪些项目最有可能成功；以及每个项目何时能产生效果。事件数据是滞后数据，意味着我们需要经过一段时间才能知道结果。除此之外，客户当下正在经历着痛苦。

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

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

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

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

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

用一个季度的时间，设计并实现自动化的指标监控。
再用一个季度，通过自动告警和手动回滚操作来确认客户影响与指标的对齐情况。
投资于自动化部署和回滚。
证明许多自动回滚的成功，将客户影响保持在10分钟以下。
进一步投资，监控更多指标，并优化手动回滚流程。
投资于手动前端回滚能力。
受ReleaseBot和AWS Pipelines部署系统的启发，进一步投资于Slack的集中式部署编排系统，旨在将基于指标的部署和自动化修复统一应用到Slack Bedrock/Kubernetes之外的许多其他部署系统中。
达成成功标准：Web应用后端、前端以及部分基础设施部署现在明显更安全，并呈现出季度性的持续改进。

这种先尝试、发现成功、然后迭代并将模式复制到其他系统的做法，一直让我们受益匪浅。

值得列出的项目太多，有些更成功（例如，更快的移动应用问题检测），而另一些则效果不那么明显。在某些情况下，由于自动化带来的成功超过了手动修复的改进，我们减少的影响较小。需要特别注意的是，那些未能达到预期效果的项目并非失败，它们是我们成功的关键输入，通过指导投资方向和理解哪些领域更有价值来发挥作用。并非所有项目都能产生同样大的影响，这本身就是设计的一部分。

成果

季度客户影响 vs. 渐进目标

请注意：我们内部对“影响”的指标跟踪比可能符合Slack状态站点条件的干扰要精细和敏感得多。

上面的柱状图清晰地讲述了非线性进展的故事，以及使用基于等待事件发生的滞后指标的困难。

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

我们仍然相信，基于早期Web应用后端基于指标的部署告警与手动修复的结果，我们所做的工作将产生预期效果——否则2024年的影响高峰会更高。我们需要的是自动修复，而非手动修复。一旦引入自动回滚，我们观察到了结果的显著改善。我们持续经历了3-6个月的滞后期，才能观察到每个项目的全部影响。

随着时间的推移，目标数字在不断调整。由于该指标需要滞后的事件数据，目标是根据上一季度交付的工作所预期的潜在结果来设定的。这与期望工作一交付就能立即衡量结果的做法明显不同。

我们已为2025年再次调低了目标数字，并期望客户影响进一步降低，重点是通过部署系统的一致性来缓解不频繁的影响峰值风险。

经验教训

这个计划需要持续学习和迭代。我们学到了许多重要的经验，每一项对于一个成功的计划都至关重要：

确保优先级排序与对齐

每4-6周进行一次高管评审，以确保持续对齐并在需要时寻求支持。
在公司/工程目标（OKR, V2MOM等）中保持高优先级。
获得高管领导层的坚实支持，包括积极的项目对齐、鼓励和客户反馈。

对滞后指标保持耐心，并坚信即使某些项目未成功，过程是正确的

使用从工作交付到度量有数月延迟的衡量标准需要耐心。
在等待完整结果的同时，收集指标以了解改进是否至少运行良好（例如，问题检测）。
相信你已根据当时掌握的信息做出了最佳决策，并具备在结果确认后改变路径的灵活性。

人们在熟悉或适应之前，会推迟采用新实践

他们担心遵循未知的路径会使问题恶化，即使被告知这样做更好且是推荐的。
为许多团队提供直接培训（必要时多次进行），帮助他们适应新工具——“直接回滚就行！”
根据事件处理经验，持续改进手动回滚工具。
经常使用这些工具，而不仅仅是为不常见的最坏情况做准备。事件处理压力很大，我们发现，如果不经常使用以建立熟练度、信心和舒适感，流程和工具就不会成为例行公事。这就像当初根本没有构建这个工具/能力一样。

直接与工程团队沟通至关重要

部署安全计划团队直接与各个团队接触，了解他们的系统和流程，提供改进指导，并鼓励创新和优先级排序。
并非所有团队和系统都一样。有些团队清楚地知道他们的痛点并有想法，另一些则希望改进但需要额外资源。

尽可能保持顶层指标的一致性

选择一个指标，保持一致，并根据结果验证进行优化。
很容易把时间浪费在争论最佳指标上（完美的指标并不存在）。

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

这是我们正在努力改进的领域。
管理层理解优先级和结果，并且作为一个团队很好地保持了一致。然而，对于普通工程人员来说，情况并不总是那么清晰，这揭示了一个需要更好对齐的机会。

展望未来

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

改进基于指标的自动化部署与修复，以保持积极的趋势。
在Slack的所有部署中，更一致地使用“安全部署”流程，以缓解意外或不频繁的客户影响峰值。
改变计划的范围，将剩余的手动部署流程迁移到使用“安全部署”流程的基于代码的部署。

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

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

致谢

衷心感谢部署安全团队在过去一年半中的所有成员。同时，也要向许多无法一一列举的团队致以最诚挚的谢意，感谢他们承接了各种规模的部署安全项目，以改善我们客户的产品体验。