英国税务局（HMRC Digital）的 DevOps 之旅

2016 年在伦敦举办的 DevOps 企业峰会上，最吸引大家眼球的莫过于英国皇家税收与关税局 (HMRC) 英国税务海关总署的 DevOps 和持续交付实践案例，在案例中他们逐步将部门的官僚文化改变为快速交付的数字税务服务。InfoQ 采访了其中的演讲者之一 Lyndsay Prewer，深入了解了他们的历程，以及目前的情况和最大的挑战。

InfoQ：能否详细介绍下您目前的职位？

Prewer：我是 Delivery Lead 的交付代表（Delivery Lead），目前在 HMRC Digital 工作。我带领一个产品团队，负责使 HMRC 数字服务更易于访问并提升其安全性。所以我经常跨部门协调工作，帮助他们通过小的常规增量，逐步提高交付服务的质量。

InfoQ：你第一次知道 DevOps 是在什么时候？

Prewer：担任这个职务之前，我在帮助一个私营部门提高交付频率，从每年一次提高到每周 n 次。首先建立持续交付的文化就是个大工程，然而这还远远不够。开发和运维是两个团队，有分别的 leader，这严重影响了下一步的进度。那时我第一次听说了 DevOps，还读了《Phoenix Project》这本书。我们的结论是营造一种 DevOps 的文化是实现持续交付的关键，但后来证明这也是一件很棘手的事情。

InfoQ：HMRC Digital 是如何开始 DevOps 的？第一步做了什么？为什么这么做？

Prewer：HMRC 之前外包了所有的 IT 业务，导致交付过程非常繁重，试想一下：繁琐的文档，超长的交付周期，很少的发布和周期性的变更冻结。后来成立了 HMRC Digital 部门，最开始只是一个很小的团队，负责交付小规模的 IT 解决方案。HMRC 缺乏这方面的专家和文化，所以需要从其他公司引进专家来帮助他们。HMRC 提供业务知识和方向，政府数字服务提供了一个专注于用户需求的框架（帮助绕过官僚的繁文缛节），Equal Experts 以及其他的咨询团队凭借他们在敏捷、精益和 DevOps 的经验，提供技术和专业知识，进行解决方案的迭代设计，构建和交付。

InfoQ：这是一个基层的行为，还是需要自上而下对 DevOps 的理解？

Prewer：HMRC 知道需要改变，但并不知道如何改变。专家们也都知道只有证明了新的方式能够带来价值，才能顺利地进行组织的改变。所以团队最初通过敏捷、精益和 DevOps 的实践，将一些小的变化应用到了生产环境。第一个线上的税收信用恢复服务，就是一个很好的案例，这个项目只用 8 周就完成了。这个服务让大部分用户都可以在线上更新他们的税收信用，免去了电话和纸质渠道带来的不便和费用。这些小的尝试，也坚定了 HMRC 继续对 Digital 部门进行投资的信心。

PaaS 平台的构建让这个团队获得了重要的成长，通过 DevOps 的特性，产品团队拥有了自治权。当一个新的产品团队来到这个平台时，他们马上就能获益于平台的自动构建和部署流程。而且，他们构建的服务还能充分利用平台提供的授权、审计、监控和报警等功能。这样一来，构建服务的团队也负责保证这个服务在生产环境中的运行，符合亚马逊的“you build, you run it”的原则。

InfoQ：目前 HMRC Digital 在 DevOps 方面有哪些进展？其中包含了组织的变化吗？

Prewer：每年的 12 月到 1 月 31 日（提交自行纳税申报的截止日期），HMRC 的线上流量都会激增，为了应对每年的流量高峰，HMRC 添加了另一个云服务商。第二个服务商在 2015 年 10 月被选定，12 月投入使用，力争对产品团队和他们的服务造成最小的影响。基础设施变更的顺利过渡，得益于 HMRC Digital 的 PaaS 平台和产品团队的自治。50 个产品团队中，只有 2 个 WebOps 团队在维护着这个平台。WebOps 专注于平台的基础设施建设，让其它产品团队能够将精力都放在核心业务上。

InfoQ：HMRC Digital 是否有计划在整个集团内推广 DevOps？

Prewer：HMRC Digital 的 PaaS 中集成了强大的监控和报警工具（ELK、Sensu 和 PagerDuty），不被使用的话这些工具没有任何意义。但教会这 50 个产品团队去正确的配置和使用这些工具并不容易，需要首先解决以下问题：

1. 服务目录，为各个列出微服务的地图；
2. 为每个团队和他们的微服务自动启动监控和报警工具；
3. 定期更新内部的博客，讲述各个团队的案例，展示他们是如何使用这些工具支撑自己的业务和最终用户的。
   前两步需要团队去访问提前定义好的 kibana 面板和 grafana 面板，查看自己的微服务，当然他们也可以创建自己的面板。

而且，一旦达到了某个给定的错误阀值，微服务的报警就可以自动发送给对应的团队。每个微服务都可以自定义阀值，所以这些工具可以灵活地满足不同团队的需求。

InfoQ：在推进 DevOps 的过程中，HMRC 还遇到了哪些文化或技术上的挑战？

Prewer：HMRC Digital 每天要有数次生产环境的部署，平台上运行着 300 多个微服务。然而 HMRC 的遗留系统还保持着几个月的发布周期，峰值业务时会变更冻结，还有冗长的端到端测试安排。

很多情况下我们不得不将数字服务推送到遗留的后端服务上，两种“文化的碰撞”必然会产生摩擦。过去三年来，摩擦已经越来越少。几个月的发布周期，也由于频繁的系统更新而变得越来越短，变更冻结也不再是常态，桩和契约的使用大大减少了端到端的测试需求。

InfoQ：在 2016 年 DevOps 使用情况报告中显示，在 DevOps 和持续交付的投资能够促进业务更快、更可靠的交付。你同意这种说法吗？

Prewer：我 100% 同意。从一开始，我们就以迭代的方式设计和交付了服务。我们尽量将最小的更新以最快的速度推进到生产环境，然后开始迭代。比如“Tax Account Router”的项目，这是在 2015 年 11 月被引进的一个微服务，为的是应对 2016 年 1 月的流量高峰。这个微服务的作用是将所有的自行纳税申报用户，根据他们的用户类型（比如业务、个人或机构），引流到正确的登录页面。

这个项目开始后的第六周，第一个版本被发布到了生产环境，然而这时的版本只是围绕被路由的用户数量简单地生成了指标。这让我们能不对真实用户产生任何影响的情况下，验证他们的行为。然后我们在节流阀之后加上了路由的功能，同样是为了保证验证造成的影响最小。这个例子展示了我们如何在每次发布时添加最小的更新，将风险和浪费最小化。我们能做到这样，得益于我们的构建和部署流程，它能让代码变更在几小时内发布到生产环境。这是一个和普通的实践和过程，并没有投机取巧或绕过某些过程。

InfoQ：HMRC Digital 的 DevOps 之旅中有哪些挑战和障碍？

Prewer：DevOps 让 HMRC Digital 能每天将更新发布到数字服务的生产环境中。这对于业务和用户都有很大的帮助，但是如何让 HMRC 其余的部门在服务有细微差别的情况下保持同步是一个巨大的挑战。

通过小而专的产品团队参与业务，以及开发和运营专家的帮助，HMRC Digital 在服务交付上已经有了很大的进步。下一步就是在整个 HMRC 组织中，提高集成和反馈的回路。

查看英文原文： DevOps Gov Adoption at HMRC Digital

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。