作者 | Matt Saunders
译者 | 平川
策划 | Tina
团队沟通平台 Slack 的一位工程师写了一篇文章，讲述了他们如何克服部署恐惧，并成功地实现了一个机器人来监控部署过程。
Slack 高级软件工程师 Sean McIlroy 记录了他们如何从由一群开发人员轮流监控其 Webapp 部署，转变为使用机器人每天部署 150 个变更。McIlroy 在一篇博文中详细解释了赋予 ReleaseBot 关键角色的原因和逻辑。他描述了一个看似可怕的责任委派如何最终归结为一个检测图表峰值的数学问题。
工程师在将变更部署到像 Slack 这样的大型平台时会面临一系列独特的挑战，因为大多数服务都是在一个名为“The Webapp”的单体应用上运行，每周变更达数百次。Slack 采用了持续交付的部署理念，旨在根据反馈快速迭代，并将开发人员的工作快速交付给客户。然而，管理一个经常使用的变更流（平均每天 150 次左右）需要谨慎权衡，既要避免使系统不堪重负，又要将错误风险降至最低。
传统上，Slack 依赖于部署指挥官（DC），即负责在轮班期间执行部署步骤的人。但是，DC 的轮转性质和系统复杂性的日益增加对于信心和专门知识的构建构成了挑战。因此，发布工程团队试图通过为 DC 提供更清晰的决策指导来解决这个问题。
这就是开发 ReleaseBot 的初衷。ReleaseBot 是一个具备异常检测和监控功能的自动部署系统。从手动部署到自动部署的过渡是一个渐进的过程。最开始的时候，ReleaseBot 与 DC 一起操作，并逐步证明了它的可靠性和效率。它可以比人更快地捕获问题，且提供了更高的一致性。虽然起初，人们对自动化部署可能带来的风险感到担忧，但 ReleaseBot 的性能超出了预期，使人们对其自主处理部署的能力充满了信心。
ReleaseBot 的有效性在于它的异常检测机制，特别是使用了 z 分数（z-score）。Z 分数量化了数据点与平均值的偏差，能够识别指示潜在问题的统计异常值。如果应用程序在部署后的表现与之前的表现不同，就会触发问题的“高置信度”信号，并通知工程师可能存在需要干预的问题。实际上，这是一种检测图形峰值的数学技术。高置信度信号由与历史数据的显著偏差触发，可立即引起注意，而低置信度信号通常由静态阈值控制，可作为补充预警。
Slack 发送给团队的通知其严重程度根据高置信度信号的频率和范围来确定，并用白、蓝、红构成的三色标尺来表示信号的紧急程度。Slack 还使用静态阈值通知作为低置信度预警，但也会把它们作为 ReleaseBot 的输入来计算动态阈值。动态阈值考虑了部署时组件的正常负载和性能。ReleaseBot 会使用历史数据来区分部署期间的异常峰值和预期波动。这种方法使得 Slack 可以过滤掉常规变化，同时标记出需要干预的真正异常。
