运动：长期致力于安全实施全球变化的努力

随着工程组织的发展，问题及其解决方案变得更加复杂。现在可能需要一个下午才能完成的工作需要几个月的协调努力。该系统（包括技术和人员）比以往任何时候都更大，更复杂且更难更改。

我们可能希望偿还一些技术债务，或者进行架构更改以释放更好的客户体验，节省成本等。我们可以使用什么工具来协调许多人，使各组负责并最终取得成功？

运动是一项长期的工作，旨在在社会技术系统内安全地实施全球变化。

避免测量的措施或可能对测量有害的措施。例如：“我们应该改进代码的设计。”

许多战役的技术目标都很微不足道。我最喜欢的示例：请求超时值可能是配置文件中的一行。安全地将其更改为较低的值可能需要花费数月的时间。

每个运动都需要一个目标，可以用一个句子表达。目标应与指标分开。它可能包含也可能不包含实现细节。我通常建议它们包括一些实现的提示，以便可以将工作范围限制为一点。

“我们希望通过使所有作业成为幂等来提高后台流程的弹性和吞吐量。”

“我们希望通过限制Web请求可以花费的时间来改善客户体验和系统的弹性。”

“我们希望通过对所有查询实施超时来改善数据库的运行状况。”

如果目标有点过于开放，请考虑添加非目标，以保持精力集中。

在开始竞选之前，您需要建议很多人，这是一项宝贵的努力，而现在正是应对这种努力的时候。 “为什么要开展这项运动？”的清晰表达和“为什么现在？”是必须的。

专注于实现目标的好处。我们越能在客观事实中产生影响（例如“我们的系统对失败更有弹性”），而个人对技术的偏爱就越少（例如“我们使用Tech X但现在我们使用Tech Y”），则越好。

每个指标应能够分配给给定的团队或个人。一旦指标变为绿色，我们就应该已经实现了我们的目标。 1个

选择指标可能很困难。规则跳动不应该引起人们的注意，因为规则度量是绿色的，但是目标的意图会被遗漏。

指标需要递增，并根据需要进行细化。我们应该看到进度缓慢，而不是突然“好，我们完成了！”

应该有很多方法可以实现一个指标。在全局请求超时的示例中，我们可以通过减少数据库查询的总数，加快JSON的序列化，缓存，加载较少的数据等来解决超时问题。

指标应该易于理解并且可以通过几种不同的方式进行细分。在我们的请求阈值示例中，我们可能要同时显示“剩余端点数”和“端点总数”。

从定义上说，一个Campaign遍及整个组织并涉及许多团队。每个团队，任务，个人和下级组织都有不同的优先级和不同的担忧。

一个运动要想成功，就需要有关各方的全球参与。买入在不同的组织中看起来会有所不同，但通常是胡萝卜和棒子的混合体（选择做某事与被强迫做某事）。

“如果我们能够使工作成为幂等，则基础架构团队可以接管后台工作的职责，并将成本降低90％。”

“如果我们能够使所有请求花费不到2秒的时间，那么客户体验将得到改善，并且我们将能够降低成本。”

收益可能不足以令人信服，或者可能仍未达到某些团队的优先权门槛。如果许多团队没有发现足够令人信服的收益，那么您可能没有值得追求的竞选活动。

我们还需要走多远？我们可能需要在哪里投资更多？

大多数活动将在中心位置回答此类问题。 Speadsheets在这里工作正常。仪表板甚至更好。通常可以借助脚本自动填充或手动填充它们。无论是什么，它都应迅速回答以下几个问题：

哪些球队表现不错？ （我们应该跟这些团队进行跟进，以了解对他们有用的方法。）

哪些球队落后？ （我们应该跟这些团队进行跟进，看看他们是否需要更多帮助，资源等）。

这应该是被动可用的，但也应该以一定的节奏进行分发。每周，每月或每季度，每个参与人员都应在其收件箱中获取更新。

窗口是一种确定要完成的工作的优先级的方法，同时确保进度是永久的。它移动。它是可选的，但在大多数广告系列中很有用。

窗口通常定义两个阈值：“警告”和“不允许”。在要强制执行全局请求超时的广告系列中，以下是窗口在开始和演变过程中的外观：

目标是使Web请求的时间不超过5秒（99.9％的时间）。

窗口设置为警告：30秒，不允许：60秒。 60秒是我们的负载均衡器设置的当前限制以及今天存在的行为。

团队将处理介于警告和不允许之间的所有请求，直到窗口中没有更多为止。

活动的组织者提供默认的优先级排序方法。团队不必自己发展。

通过设置和强制执行“不允许”，我们确保进度是永久的。团队无法提出耗时超过给定时间的新请求。

团队会在未来发生变化之前被警告。他们可能会收到每周的电子邮件报告，异常情况或Slack消息，通知他们今天可以接受但将来不能接受的事情。

增量值已交付。如果我们出于任何原因停止该活动，则将保持持久的价值。

我在整个帖子中都使用了一个示例，但让我们看一下一起编译的特定示例。

我在一些组织中看到的一个问题是需要设置和/或减少Web请求可以花费的总时间。这种类型的事情很容易忽略，特别是在服务于具有高交换成本或委托代理问题的行业的应用程序中。 （高昂的转换成本或委托代理问题意味着性能的缓慢下降永远不会成为首要任务。）许多运动都采用“如果我们首先知道有此限制，那么这会容易得多。 ”

我们希望通过限制请求花费的时间来改善客户体验和系统的弹性。

我们最终希望在请求的第99个百分位数时达到2秒，而硬中断时间为5秒。

我们会更多地讨论此目标，为什么选择该目标，以及在此较长文档中的紧迫性。 （链接到令人信服的内容。）

从那里开始，我们希望将警告阈值增加15秒，或每次N / 2。

Jane和X团队将可以帮助团队将他们的要求传递到目标。 X团队还负责系统中的未拥有代码。 这篇文章概括了我在Gusto所做的越来越多的工作。 每个广告系列都有点不同，需要相应地进行调整。 希望此框架可以帮助您和您的团队进行复杂的技术更改，这些更改需要大规模的行为或过程更改。 特别感谢Toni Rib，Max Stoiber，Danny Zlobinsky，Kito Pastorino和Shayon Mukherjee阅读了本文的早期草稿并提供了反馈。 如果您有兴趣定期收到这样的博客文章，请加入数百名开发人员并订阅我的新闻通讯。