Slack部署安全实践：如何通过技术革新将故障影响降低90%

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

问题定义

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

分析显示了两大关键趋势：

1. Slack对我们的客户而言变得更加关键，客户对整个产品以及公司所依赖的特定功能的可靠性期望不断提高。
2. 绝大多数的客户侧事件（73%）是由Slack自身的变更触发的，特别是代码部署。

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

此外，我们还收到了客户的反馈：中断在大约10分钟后会变得更具破坏性——他们可能会将此视为“小故障”——并且随着2025年Agentforce的引入，这种影响将继续减少。

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

过去，我们提高可靠性的方法往往专注于个别的部署系统或服务。这导致了手动的变更流程，拖慢了我们的创新步伐。变更所需的时间和精力增加，不仅降低了工程团队的士气，也阻碍了我们迅速实现业务目标的能力。

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

• 减少部署造成的影响时间
  • 在10分钟内实现自动检测与修复
  • 在20分钟内实现手动检测与修复
• 降低影响的严重程度
  • 在影响到10%的服务器之前检测出有问题的部署
• 保持Slack的开发速度

这些初步的北极星目标后来演变为一个适用于所有Slack部署系统和流程的《部署安全宣言》。这些目标鼓励实施自动化系统改进、安全护栏和文化变革。

度量标准

实施计划是为了引发变革，而变革必须被衡量。选择一个作为近似替代的度量标准一直是一个持续的讨论话题。

北极星目标可以针对工程工作进行衡量，但它们并非对最终目标（即改善客户对Slack可靠性体验的感受）的直接衡量。我们需要的是一个能合理（尽管不完美）地反映客户感受的度量标准。我们有内部数据来设计这样的度量标准。

部署安全度量标准： 由高严重性和选定的中严重性变更触发事件导致的客户影响时长。

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

关于使用何种度量标准的持续讨论，涉及以下三者之间半松散的联系： 客户感受 <-> 计划度量标准 <-> 项目度量标准 它们都相互关联，但对于一个特定项目，很难知道它将如何推动顶层度量标准。计划度量标准能在多大程度上反映单个客户的体验？这种流程对于偏好有硬数据的、更具体的反馈循环的工程师来说尤其困难——例如，“我的工作或概念在多大程度上改变了客户感受？”

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

• 衡量结果
• 理解所衡量的内容（真实 vs. 类比）
• 衡量的一致性，尤其是主观部分
• 持续验证衡量结果与客户感受的匹配度，由直接与客户对话的领导者进行

投资哪些项目？

在计划开始时，我们面临的两个最大未知数是：预测哪些项目在给定多种事件来源的情况下最有可能成功，以及每个项目何时会产生影响。事件数据是一个滞后数据集，这意味着我们需要经过一段时间才能知道结果。除此之外，客户当时正经历着痛苦。

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

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

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

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

我们将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生成的预生产测试。

致谢

非常感谢过去一年半里所有部署安全团队的成员：Dave Harrington, Sam Bailey, Sreedevi Rai, Petr Pchelko, Harrison Page, Vani Anantha, Matt Jennings, Nathan Steele, Sriganesh Krishnan。 同时，衷心感谢众多无法一一列举的团队，他们承担了或大或小的部署安全项目，以改善我们客户的产品体验。