在云计算迁移浪潮的推动下，持续交付的广泛采用和微服务的兴起，软件开发团队很可能会比五年前前进得更快。但要做到这一点，这些团队需要控制好自己的速度和节奏，而不是每次发布都要等着有人签字或者启动服务器提交工单。 　　

　　

　　公司仍然需要在基础设施、工具和平台上工作的团队，但他们的工作方法必须改变，以免成为瓶颈。这些团队需要意识到，他们真正的功能是让产品团队能够交付商业价值。在这个领域的投资会有回报，因为它可以加快许多其他团队的速度，使产品团队的工程师可以专注于解决业务问题，并为组织提供价值。 　　

　　

　　我在《金融时报》担任了四年的技术总监，领导了几个专注于工程能力建设的团队。在这篇文章中，我将谈谈我们的团队是如何建立的，以及我们在真正推动其他团队建立工程能力的过程中发现的一些重要的事情。 　　

　　

工程能力建设组

《金融时报》产品和技术团队分为几个小组。每个小组都有明确的重点领域。工程能力建设团队由所有开发工具以支持英国《金融时报》工程师的团队组成。 　　 　　

　　这个组里很多团队负责围绕关键供应商的能力提供一层工具链和文档，涉及AWS或Fastly等工具；团队需要与关键供应商密切合作，并对他们提供的产品以及如何更好地利用它们有深刻的理解。 　　

　　

　　然后，有些团队在特定领域有专长，比如网络安全或者web组件设计。 　　

　　

　　其他团队负责运维和平台管理——我们希望工程团队是解决他们系统遇到的大问题的更佳人选，但这些团队会做导流，帮助管理事件，给我们支持的操作系统打补丁支持EC2实例等。并提出改变实例类型或缩小规模的建议，等等。 　　

　　

　　最后，我们还有一个致力于工程洞察力的团队：创建我们所有系统、团队、主机、源代码库和其他信息的图表，并为我们的工程师提供关于他们需要改进/添加更多扫描的文档的洞察力等。 　　

　　

原则

我们定义了一套原则，帮助我们确保为客户构建有价值的工程能力。这些原则很自然地围绕特定的关注点进行分组。 　　 　　

　　在我看来，最重要的是。 　　

>人们可以在没有昂贵的协调成本的前提下使用它吗？

一般来说，工程师应该能够解决他们自己的问题。

这意味着，比如说有人想建立一个 DNS 条目，首先他们应该能够很容易地发现有什么工具链可以帮助自己。这些工具链应该是可以发现的。

然后，工程师需要做的常规事项应该被记录成文档。总有一些人需要做一些复杂的事情，对此我们的团队有几个 slack 频道和支持这些频道的人手――但对于那 80%的简单事务来说，文档就应该足够了。最近，我们将工程师的文档合并到了一个 "技术中心（Tech Hub）"。如果你去那里搜索 DNS 关键字，应该就能找到你需要的东西。

这张截图显示了目前技术中心上的高层技术主题和专门针对 DNS 的子主题。

我们希望各种事务都是自服务的。不应该有东西来阻止工程师随时使用这一功能；他们不需要等待工单或 PR 的签署。

负责 DNS 的团队最近做了一个变更，就是在我们的 github 仓库中添加了一个机器人来处理 DNS 变更，这样简单的变更就可以被自动批准。

当然，你必须在这里平衡风险――仍然会有一些领域需要我们施加一些控制，比如说那些一旦就出错会让 FT 面临成本、风险或安全问题的领域。这就引出了另一组原则。

我们是否在指导人们做正确的事情？

各种能力用起来都应该没有后顾之忧；默认配置应该是安全的，而且我们应该保护工程师，让他们不去犯很容易避免的错误。

能力也应该是安全和合规的――我们将确保这些共享能力是最新的，并且符合我们自己的政策。

最后，我们需要考虑哪些因素会让人们在采用能力时感到安心。

团队使用它时会有风险吗？

能力需要有人负责和提供支持，尽量减少升级、迁移和维护的影响，并提供持续多年的保障。

我们应该能够提供透明的使用率和成本洞察，这样团队就能理解他们的设计和架构选择对成本会有怎样的影响。我们发现，分享这些信息让团队更有可能采取行动来降低他们的成本。

团队的自主权

FT 的团队有很多自主权，这些权力也有自己的边界。一般来说，当你想做出对你的团队之外有影响的改变时就会触及边界，例如，当你想引入一个新工具，但原本已经有些东西能用，或者我们作为一个部门可以从单一的方法中获得很多好处时，你就不能自己做决定了。

例如，如果你想使用来自 AWS 的另一种数据存储，这不是问题；但如果你想引入一家新的云供应商，你就必须为额外的成本和复杂性提出理由。同样，如果你想在不同的位置开始发布日志，就会影响人们在同一个位置查看一个事件的所有日志的能力，这种能力在发生事件时可能很重要。

有时，团队需要一些目前还没有解决方案的东西，然后他们通常可以尝试一些选项。对于一家全新的供应商，团队需要经历一个包含多个步骤的采购流程――但团队在做评估时经历的流程可以短很多，只要他们不打算做一些危险的事情，比如将 PII 数据发送给供应商即可。

团队确实会使用他们的自主权。他们会自主决定自己用到的架构、库和框架。大约五年前，随着金融时报开始采用微服务、转移到公有云，并开始发展一种“你构建，你运营”的文化，金融时报不同团队的行事方式变得大大多样化了。

自那以后，公司内部有了更多的整合过程，因为很多团队意识到他们可以复制现成的模式来节省时间和精力。例如，一旦一个团队成功地使用 CircleCI 来构建服务，其他团队也很容易采用这种方式。一段时间后，中央工程能力建设团队接管了与 CircleCI 的关系。这种寻找新工具的过程可以是非常强大的――你已经知道人们想要采用它了!

移动边界

有时，我们确实需要改变团队自主权的边界。

几年前，我们为技术提案引入了一个相当轻的流程。任何影响到一个以上的小组或引入重大变化的事情，都应该用模板格式写成文档，内容包括需求、影响、成本和替代方案。文档中的替代方案必须包含“什么都不做”的情况，这样我们就能了解这种情况下会发生的事情。举个例子，几年前，我们需要转移到一家新的 DNS 供应商，因为我们现有的供应商 Dyn 即将寿终正寝。在这种情况下，“什么都不做”是不可行的――而在文档中说明这一点还是有意义的。

这些文档会发出去征求意见，然后被带到一个叫做技术管理小组的会议上等待批准。这个会议对所有人开放，我们鼓励大家参加会议来旁听和学习。会议开始在线上举办后，我们发现参会者经常达到 40 到 50 人。

如果你要做出贡献，你应该事先读过提案并给出反馈。我们的目的是让会议更多关注最后的细节和沟通；所有关于共识的工作都要提前完成。拿 DNS 提案来说，DNS 团队预先评估了几个备选方案，重点是如何减少变更对其他团队的影响。他们还在文档里阐述了新方法将如何通过 github 仓库中的基础设施即代码，让团队转向一个更加精简的 DNS 变更流程。他们在会议前与每个开发小组都做了交流，所以在审查时，他们对方法和时间表都有了承诺。

我不认为每一项重大变化都会自动提交给技术管理小组，但很多东西都是通过这种方式讨论的，你可以在一年后回去了解我们为什么要做出某项决定，因为所有文档都被链接到了一个 github 仓库。

挑战：衡量我们对工程生产力的影响

我发现我们往往很难通过观察诸如完成的工单等指标来衡量工程生产力。例如，当我们评估从一个冲刺到另一个冲刺的速度时，我从来没有发现任何明确的趋势！而且，我们很容易评估完成的工作量，但评估工作所提供的价值就不是一回事了；快速构建错误的东西并不是什么好事情。

在我看来，DORA 或 Accelerate指标对企业来说是一个非常好的入门评估标准。如果你在这些方面表现低下或中等，那么建立 CI/CD 管道和优化小变更的发布速度将给你带来巨大好处。

在过去的五到十年里，FT 做出了很多改变――转向云计算、采用 DevOps、转向微服务架构――它们影响了我们在这些 DORA 指标上的得分。在此期间发生的重要变化包括启动一个新服务器所需的时间，以及从编写代码到上线所用的时间。这两方面的数字都从几个月变成了几分钟。

这意味着你可以快速测试你所做工作的价值。你可以做实验。这意味着我们不会花几个月的时间构建一个东西，结果发现我们的客户讨厌它，或者它没有产生我们预期的影响。几年前的一个例子――我们想提高对《金融时报》电影评论的参与度，这意味着我们希望人们阅读更多的电影评论或花更多的时间来阅读它们。我们很快就在列出所有评论的页面上添加了评论分数――同样，当我们发现它导致实际评论的阅读量减少时，很快就删除它了。

一旦你在这些指标上表现出色（FT 达成这一目标已经有好几年），你就必须找出其他可以衡量的东西来看到工程能力建设的影响。这对现在的团队来说是一个挑战：找出最能反映我们正在产生的影响的新指标。我们确实使用了一些定性指标，如开发人员调查和访谈，而且我们也一直在尝试用各种方式来衡量系统的健康状况。

我学到的主要经验

首先是沟通的重要性。

你应该尽量与人们谈论你正在做的事情和原因。这意味着你需要解释为什么要设置各种限制：无论是因为成本、复杂性还是风险。

第二，为团队提供洞察力是非常有价值的。

你要尽量让团队都看到各种信息，并用这些信息促使他们做事。我们发现，一旦我们能够向团队展示他们需要改进运营手册的哪些地方，他们就很有可能去做这件事。我们创建了一个带有服务可操作性分数的仪表板，所以团队可以看到他们的工作重点应该在哪里。

我们都有很多需求要赶。如果你的电子邮件或仪表板上有一个链接，可以准确地指向我需要去的地方，并准确地解释我需要做什么以及为什么，我就会更有可能去做这件事。

但最后，也是我认为最重要的一点是要关注解耦――不要让人们干等。要及时响应，要提供帮助。但同时，要通过自动化和完善的文档来进一步解耦，你就不会在无聊的任务上花费那么多时间了。

我对正在考虑如何构建组织的人们的建议

我认为每个组织都必须至少提供一些中心化的工程服务。问题是你应该把它做到什么程度。

对我来说，这取决于你的出发点是什么。对于《金融时报》来说，将每个人都转移到一个标准化的黄金路径上是一项艰巨的任务。考虑到金融时报的情况，为公司所使用的那些主要技术建立几条黄金路径是不错的方案――例如，一条路径用于将节点应用部署到 Heroku，另一条则为使用 AWS lambdas 和 DynamoDB、S3 和 SQS 等标准 AWS 资源的无服务器打造。这些黄金路径中的许多步骤在各个路径中都是通用的：例如使用相同的源控制、相同的 DNS 提供商和相同的 CDN。

对于一个拥有一套更标准技术的组织来说，我会看看痛点在哪里：问问工程师他们都遇到了哪些痛点，哪些阻碍他们的因素。我敢打赌，一个中心化团队可以创造出的影响比让这些工程师分散在各个特性团队中会更大。

但最重要的是要确保提供这些中心化服务的团队明白，他们的作用是让其他团队能够：快速响应，让事情自服务和自动化，撰写真正完善的文档，并与其他工程师交谈，使他们建立的东西对这些工程师和组织产生最积极的影响。

作者简介：

Sarah Wells 从事开发工作达 20 年之久，在咨询、金融服务和媒体领域领导交付团队。使用基于微服务的架构构建 FT 的内容和元数据发布平台，使她对可操作性、可观察性和 DevOps 产生了浓厚的兴趣，在 2018 年初，她接管了金融时报的运维和可靠性职责。最近，Wells 转而接管工程能力建设，将平台和安全工程加入其中。她在金融时报领导了一组团队，为其他工程师建立工具和服务。Wells 在 2021 年底离开 FT，在决定她的下一步行动之前，她正在休息一段时间。可以通过 @sarahjwells 联系 Wells。

原文链接：

How the Financial Times Approaches Engineering Enablement