部署安全：降低变更对客户的影响
2023年年中，我们发现了一些提升可靠性的机会。快进到2025年1月，客户影响时长已从峰值减少了90%，并持续呈下降趋势。Slack的“部署安全”计划已进行了一年半，改进了我们的部署方式，提升了安全文化，并持续保持变革速度以满足业务需求。
定义问题
随着业务发展，系统需求不断变化，这可能是由于客户期望、负载与规模的变化或对业务需求的响应。
分析显示了两大关键趋势：
- Slack对我们的客户变得更加关键，客户对整个产品及公司所依赖的特定功能的可靠性期望不断提高。
- 绝大多数（73%）面向客户的事件是由Slack自身的变更（特别是代码部署）触发的。
在Slack，我们大量并频繁地使用事件管理流程，以确保根据影响和严重性对所有类型和大小的故障做出强有力的快速响应。其中一部分事件会影响客户，许多事件的影响程度因客户使用的产品功能而异。由变更触发的事件广泛发生在各种系统和部署流程中。
最后，我们还收到了客户反馈，即中断在大约10分钟后会变得更具破坏性——他们原本可能将其视为“小故障”——并且随着2025年Agentforce的引入，这种影响将继续减少。
所有这些都发生在一个拥有数百个内部服务和多种不同部署系统与实践的软件工程环境中。
过去，我们的可靠性方法通常只针对单个部署系统或服务。这导致了手动变更流程，拖慢了我们的创新步伐。变更所需的时间和精力增加不仅降低了工程团队的士气，也阻碍了我们快速实现业务目标的能力。
这促使我们为所有最重要的服务设定了初步的跨部署方法的“北极星”目标：
- 减少部署造成的影响时长
- 10分钟内自动检测与修复
- 20分钟内手动检测与修复
- 降低影响严重性
- 在问题部署到达10%的实例群之前检测到
- 保持Slack的开发速度
这些初始的北极星目标后来演变成并扩展为一份《部署安全宣言》，现在适用于Slack所有的部署系统和流程。这些目标鼓励实施自动化系统改进、安全护栏和文化变革。
度量指标
计划是为了引发改变，而改变必须被衡量。选择一个不完美的类比指标一直是我们持续讨论的话题。
北极星目标可以针对工程工作进行衡量，但并非最终目标——提升客户对Slack可靠性体验的感受——的直接度量。我们需要的是一个能合理（尽管不完美）类比客户感受的指标。我们拥有设计这种指标的内部数据。
部署安全指标： 由高严重性和选定的中严重性变更触发事件造成的客户影响时长。
“选定的”是什么意思？这似乎相当模糊。我们发现事件数据集并不完全符合我们的需求。Slack的严重性级别传达的是当前或即将发生的客户影响，而非通常需要事后仔细分析的最终影响。这意味着我们需要根据相关的客户影响程度来过滤中严重性事件。
关于使用何种指标的持续讨论，涉及以下几个方面的半松散联系： 客户感受 <-> 计划指标 <-> 项目指标
它们相互关联，但很难知道一个特定项目能在多大程度上推动顶层指标。计划指标在多大程度上反映了单个客户的体验？对于更偏好有硬数据的、更具体的反馈循环的工程师来说，这种流动尤其困难——例如，“我的工作或概念在多大程度上改变了客户感受？”
设计部署安全指标的重要标准：
- 衡量结果
- 理解衡量内容（真实情况 vs. 类比）
- 衡量的一致性，特别是主观部分
- 持续验证衡量结果是否符合客户感受，由与客户直接沟通的领导者负责
投资哪些项目？
在计划开始时，我们面临的两个最大未知数是：预测哪些项目在存在多种事件来源的情况下最有可能成功，以及每个项目何时会产生影响。事件数据是一个滞后数据集，意味着我们需要时间延迟才能知道结果。除此之外，客户此刻正在经历痛苦。
这影响了我们的投资策略：
- 初期广泛投资并倾向于行动
- 首先关注已知的痛苦领域
- 根据结果进一步投资于项目或模式
- 减少对影响最小领域的投资
- 设定灵活的短期路线图，可根据结果调整
我们的目标引导我们寻找能影响以下一个或多个方面的项目：
- 在部署流程中更早地检测问题
- 改进自动修复时间
- 改进手动修复时间
- 通过设计隔离边界（控制爆炸半径）来降低问题严重性
我们将Webapp后端归因为变更触发事件的最大来源。以下是为解决Webapp后端部署而进行的投资流程示例：
- 花费一个季度来构建自动指标监控
- 另一个季度通过自动警报和手动回滚操作确认客户影响的对齐情况
- 投资于自动部署和回滚
- 通过多次自动回滚证明成功，将客户影响保持在10分钟以下
- 进一步投资监控更多指标，并投资于手动回滚优化
- 投资于手动前端回滚能力
- 基于ReleaseBot和AWS Pipelines部署系统的启发，将进一步投资与Slack的集中式部署编排系统对齐，以统一基于指标的部署和自动修复的使用，从Slack Bedrock / Kubernetes扩展到许多其他部署系统
- 达到成功标准：Webapp后端、前端以及部分基础设施部署现在显著更安全，并显示季度环比持续改进
这种尝试、找到成功，然后迭代并将模式复制到其他系统的做法持续为我们带来良好效果。
有太多的项目无法一一列举，有些更成功（例如，更快的移动应用问题检测），而其他项目的影响则不那么明显。在某些情况下，我们减少了影响是因为自动化改进比手动修复改进更成功。需要特别指出的是，没有达到预期影响的项目并非失败，它们通过引导投资和了解哪些领域更有价值，是我们成功的关键输入。并非所有项目都具有同等影响力，这本身就是设计的一部分。
成果
按季度统计的客户影响 vs 渐进目标 请注意：我们内部对“影响”的指标跟踪比可能符合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。 同时，也非常感谢无数参与了大大小小部署安全项目的团队，他们为改善客户的产品体验付出了努力。