访谈 Stuart Davidson：Skyscanner 的持续交付推广

看新闻很累？看技术新闻更累？试试下载 InfoQ 手机客户端，每天上下班路上听新闻，有趣还有料！

Stuart Davidson 是 Skyscanner 的一名工程管理者，他在 QConLondon 2018 上发表了一篇演讲，讲到他的组织已经从被动的运营模式，转变为授权给开发人员的团队。Davidson 讲述了他们自己的故事，他们从CTO 那里得到了一个宏伟的目标以及相应的支持，他们开启了一段让他们的小团队每天能交付一万次的旅程，现在，他们的组织已经拥有600 多名遍布全世界的技术人员，而且还是不断增长。它们采取了一种具有小的增量和文化改变的迭代方式，最终形成了一个由授权团队拥有的容器化平台。

Davidson 负责 Skyscanner 的开发机制和部署及编排团队，他分享说，他最初是一个小团队的成员，他们整天忙于被动地交付一些次要的增量，比如开发团队要求的特定的持续集成增强。该公司的领导层认识到，强大的部署管道将带来战略利益，他们设定了一个目标，要求创建一个能够每天部署 1 万次变更的平台。Davidson 将其解释为一种觉醒，因为他们意识到了当时所设计的平台永远不会达到这种能力。

Davidson 解释说，他的团队发现必须意识到他们实际上是“战略障碍”，才能成为公司的“战略促进者”。团队设立了提供持续集成的管道，“所有产品都必须经由它”。Davidson 称之为“Jenkins 悖论”，他将其描述为可重复构建、基础设施和健壮性之间的矛盾，同时却还鼓励探索和创新，使用新的和不熟悉的工具。

他们解决这些挑战的方法是将他们的持续基础设施迁移到一个容器原生工具 Drone 上，它分层管理构建和由开发小组提供的持续集成环境。这使得小团队对他们的构建、测试和运行时基础设施有更大的自主权。他解释说，让团队对自己的可重复的管道负责，这在小组中很受欢迎，于是大家通过培训来提升技能：

由于工程师们也看到了这种收益，所以大家都着了魔似地在用。这些半自治的小队可以建造他们想要的管道。他们非常喜欢它…我们一不留神就在容器里对每个小队都进行了训练。每个团队中至少有一个人知道如何管理他们的 Dockerfile，因为他们需要它来控制他们的构建环境。所以我们想，让我们把它应用到生产环境中吧。

Skyscanner 首先在生产环境中使用的是 AWS 的 ECS 容器服务，因为它是“最便宜、最简单、最容易访问的容器调度程序”。虽然他们现在正迁移到托管的 Kubernetes，但 Davidson 怀疑，就算 Kubernetes 那时已经是 AWS 的商店，那么当初如果选择 Kubernetes 能否取得今天的成功呢。他指出，技术性问题可以推迟处理，团队应该考虑“如果采取迭代步骤，解决方案是否尽可能地简单”。在谈到他们如何迭代递增时，他说:

不要投资太多。这是一个前提。不要让自己动不动就先付出了六个月的努力。试着找些简单快捷的方法。从中吸取教训, 然后尝试找出你下一步的工作要点是什么。

Davidson 还说，工具的实验应该与为实现持续交付而进行的文化转变保持平衡，他说:

如果您想尝试一些工具，寻找一个健壮的并且能够运行下去的工具，您就不必担心它的运维。因为你总会找到办法的，问题总会有办法来解决。你会有文化上的转变。

Skyscanner 的部署解决方案迅速发展为团队能够做具备集成监控和可观察的蓝绿部署。Davidson 告诉观众，他们能够“接受一个想法就将其投入生产，并在 30 分钟内对其进行监控和提醒。”他指出，他们采取的步骤“只是我们已经拥有的想法的小规模迭代”。

Davidson 还谈到了通过执行小型部署可降低风险，使团队更加安全，尽管他们对测试还有所顾虑:

每一个进入 GitLab 的变更都以蓝绿方式持续部署。这不太让人放心，因为虽然我们的测试还不错，但可能还没那么好。通过持续部署我们发现，如果你看看风险方程式，被部署的变更非常非常小…所以如果有问题，很容易找到问题的根源。

Davidson 谈到了他们如何在蓝绿部署中添加一个类金丝雀的暂停，使用 StackOverflow 的开源监控工具 Bosun 对一个具有系统和业务指标的时间序列数据库执行查询，用来评估发布的健康状况。Davidson 解释说，小团队可以定义一个明确的首次上线百分比，针对接受的模式予以分析，如果证明不成功，该部署就会自动回滚。Davidson 说:

我们还可以查询 OpenTSDB，看看我们的航班销售是否下降了。事实上，我们更倾向于如果突然出现暴跌就回滚。可能是电视上出现了一些好东西，大家不再关注 Skyscanner，导致我们意外回滚了，但我们认为这种情况是没关系的。在这种事情上我们还是想保守些。

在演示的时候，Davidson 表示，Skyscanner 上一个月在多个区域一共为 456 个不同的服务共计部署了 3733 次。他说他的团队的目标是让小组成员能够专注于为旅行者提供价值：

我们的目标是成为一个力量倍增器。对于在 Skyscanner 工作的每一位工程师，我们都试图让他们在一天内能够做更多的事情。我们尽可能以最大的努力，令一个工程师就能尽可能快地、可靠地把他们的资源投入生产。这样，他们就可以专注于我们给旅行者提供的产品和功能了。

InfoQ 采访了 Davidson ，以了解关于这段扩展持续集成之旅的更多内容。

InfoQ: 在接受最初的挑战之后，管理采取了什么支持形式，以达到每天 10K 的部署?

Stuart Davidson: 布莱恩遵守了他的诺言，并尽可能多地向人提起我们的部署工具 Slingshot , 我们甚至把它呈现给了董事会。

我的经理（Ryan Crawford）和我的工程主管（Paul Gillespie）围绕着工程领导力、获得反馈和挑战认知做了大量的工作，并召集了一群有影响力的人，这些人应该对把这些工具和做法推销给公司其他人有所帮助。

但还并不仅仅是自上而下的支持，我们还得到了一个雄心勃勃的部落工程领导 Dave Garcia 的大力支持，他看到了我们所做的一切，并坚定不移地让他的直接预订团队成为了该产品的早期采用者。他们总是给我们反馈，帮助我们更好地规划下一步的工作。

结果，我们的 Slack 通道可忙坏了，工程师们会通过它互相帮助解决问题，交换这个系统的使用案例，它几乎成了病毒，因为小团队在新工作上一用这个系统就会爱上它，随后把它移植他们的现有系统上。整个企业的工程师们所呈现出的积极态度和韧劲代表它取得了真正的成功。

InfoQ：Skyscanner 的产品开发和业务敏捷性是如何应对快速交付小变更的?

Davidson: 实事上有趣的是，的确有一些很小的变更，它们真正关注的是数据驱动的实验。然而，这些微小的变更能让我们有信心做出 Skyscanner 运营方式上的更大的改变。

我们很快就在特定区域建立了新的垂直领域，来看看我们会有什么样的吸引力。我们创建的内容页面或页面关注的是特定的事件，比如冠军联赛或板球——这些不再需要 6 个月时间的规划和硬件申请。

针对一个想法，可以在一个下午内就生产上线最初版本，然后团队可以在他们所做的第一版上快速安全地迭代。

InfoQ：你的一个重要经验就是要认识到赋予团队能力，让他们有能力帮助自己。在实践中这是如何实现的呢?

Davidson: 这实际上比在 Skyscanner 内部听到的还更容易些，因为我们的工程组织促进了小团队的自治——即实际为那些好奇的早期采用者清除了障碍，让他们得以尝试并向我们提供反馈。这么做有一个负作用，那就是一些小团队最后很难迁过来，但是到那时，迁移的用户体验通常都有完备的文档支撑了，甚至可能都是自动化的了。

例如，我们在开始时就做了很多工作，从开始讲解一些概念的教程，然后最终有了完备的产品服务，从头开尾都可以脱离工程师了。这种体验往往会让人很快就能上手，而且它还能让大家都参与进来，并与公司里的其他人进行交流。

在接下来的几个月里，将会在 InfoQ 上提供关于 Davidson 访谈的幻灯片和录像。

查看英文原文： Q&A With Stuart Davidson on Scaling CD at Skyscanner