作者 Manuel Pais ，译者 周小璐 发布于 2016年8月31日
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个产品团队去正确的配置和使用这些工具并不容易，需要首先解决以下问题：
服务目录，为各个列出微服务的地图；
为每个团队和他们的微服务自动启动监控和报警工具；
定期更新内部的博客，讲述各个团队的案例，展示他们是如何使用这些工具支撑自己的业务和最终用户的。
前两步需要团队去访问提前定义好的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组织中，提高集成和反馈的回路。
===========华丽的分割线============
英国华人圈接受任何合法广告发布，我们免费服务的项目包括：征婚交友、招聘求职、二手交易、家政服务、房屋族谱、店面转让、物品求购、寻人启事、不良商家或个人曝光（后果自负）；
收费服务范围：代购宣传、商家产品宣传、公司推广或合作等；具体可联系小编微信：yg19820731咨询！
本公众号投稿邮箱：[email protected]
声明：
本订阅号登载图片出于更直观传递信息之目的，并不代表本网赞同其观点和对其真实性负责。如该图片涉及任何第三方合法权利，请及时与微信yg19820731联系。
欢迎大家参与评论，在每篇文章最底部的右边点击评论即可哦~
