ITV 公司是英国的一家制片和传媒公司， Tom Clark 是该公司的通用平台主管，他在刚刚过去的 2016 年伦敦企业级 DevOps 峰会上发表了演讲，着重讲述了他们的云平台如何作为媒介传播 DevOps 实践、在整个企业中的工作方式，以及如何围绕它产生“聪明且友好”的工程师团队。
InfoQ 对 Clark 进行了深度采访，期间谈到 ITV 的 DevOps 是如何开始实施、现在的情况以及曾经面临的主要挑战。
InfoQ：可否请您更多和我们介绍下当前的角色？
Tom Clark：我负责管理公司整个平台工程师团队，他们会开发和运营“通用平台”，该平台中部署了我们现代化改造项目中所开发的所有应用程序。
InfoQ：您最早什么时候听说 DevOps，如何听说的？
Clark：我第一次听到这个词是在 2010 年，当时我加入了最初的伦敦 DevOps 邮件组。然而，我最早体验到 DevOps 的好处是在 2007 年，当时我在一家名为 Trutap 的公司做开发。在那里，开发者和系统管理员的座位相邻，意味着我们可以互相学习对方领域的知识——那种方式的生产力相当高。
InfoQ：在您的公司中是如何开始实施 DevOps 的？第一步是什么？为什么？
Clark：那需要回溯到 2012 年，我们为三星电视开发 ITV 播放器（我们的 VOD 平台，现在叫做 Hub）的一个版本。因为那是最小化可行产品（MVP），所以我的同事 Robert Taylor 认为是试验 DevOps/ 产品团队方法的理想机会，而不是像之前一样使用功能筒仓方式。
InfoQ：那更大程度上是一次自底向上的活动？还是说 DevOps 需要自顶向下的理解？
Clark：肯定是自底向上的。Rob 是正面思维的志愿者，他有想法并且对在线部门的技术控制有信心，所以要试试。结果非常成功，这让我们有信心在其他部门实施。这给了我们更多证据，帮助 CTO 下定决心，认为这对于其他技术部门也是正确的方法。
InfoQ：在您的组织中，当前都开始了哪些 DevOps 措施？它们是否影响组织产生了变化？
Clark：ITV 当前正在进行一项宏伟的现代化改造项目，要把几乎所有遗留的业务系统都重新开发一次（这里我所谓的遗留，是指用 COBOL 语言编写运行在大型机上的系统）。项目着重要从瀑布式切换到敏捷，且通过长期存在的“产品”而不是短期的项目来开发。
ITV 分为五个主要部门：工作室、商业、广播、在线和共享服务，每个部门都有专门的技术团队。现代化改造项目会影响所有部门，直到现在，他们一直都在使用瀑布式交付，因此我们确实要把它们带上敏捷的“旅程”，当变更在几天或者几周内交付，而不是花费几个月甚至几年时，那么即便他们发现特性发生变化的时候，也不会感到奇怪。
InfoQ：你是否见证了一些文化冲击，比方说来自于风险管控和安全团队？
Clark：令我惊奇的是，没有！我们的变革团队把自动化、持续集成、持续交付等视为降低风险提升信噪比的方式，让他们可以更专注于“真正的”风险。对于我们的安全团队也是一样。因为我们所有的工作都自动化、受到监管和跟踪，这让他们对平台很有信心，意味着可以专注于最需要的工作。当然也还有一些业务领域并不是完全适应持续部署，但我们正在逐步缩短他们的发布间隔，以证明那对于数据很安全。
InfoQ：在你的组织中，当开始实施 DevOps 的时候，还会面临哪些其他文化或者技术上的挑战？
Clark：我们在每个产品团队中都安排了一名平台工程师，这给团队带了了很大好处，但和拥有一个中心化共享团队相比，这会花费更多资源。这需要一些努力来说服他人，而结果证明了一切。
InfoQ：在你的组织迄今为止的 DevOps 旅程中，最大的成功和失败是什么？
Clark：让我想到的最新的成功是，一个新的产品团队能够在八周内完成“从 0 到 beta”，也就是把可以工作的产品交付到业务用户的手中。之前这可能需要一年的时间。
到现在为止，我们运气不错，还没有经历任何大型失败……
InfoQ：在两个案例中，你认为哪些因素最为重要？
Clark：成功由很多因素决定。协作是关键——业务人员非常清楚他们希望在最小化可行产品中实现什么，我们就按需交付，不做多余工作。从平台的角度，它得益于我们的核心团队开发的通用平台“toolkit”，而我们安排的工程师每天都在使用这个平台。他们会重用一些标准的“基本体”来构建平台，让我们得到了更好的一致性和更高的质量。
之所以到现在为止还没有出现重大失败，我认为原因在于我们更喜欢迭代式的变更，而不是大型变更，而且我们喜欢“从大处思考，小处着手”。我们还认为自己是“快速的跟随者”，而不是新技术的急先锋。
InfoQ：“2016 年 DevOps 状态报告”中声称，在 DevOps 和持续交付实践上的投资会更快、更可靠地交付业务价值。你是否同意？如果同意的话，在你的组织里面是否遇到过一些具体的例子来支持这种说法？
Clark：必须同意！上面“从 0 到 beta”的示例已经明显地说明了收益，本质上来说，手动的过程难以扩展——只能是通过自动化 / 持续集成 / 持续交付，我们才能够安全地完成所需要的大量变更，从而交付现代化改造项目。
InfoQ：你搜集了什么类型的数据或者反馈来验证通过 DevOps 转型所获得的价值（或者降低的浪费）？
Clark：我会经常和我所支持的产品所有者（我视他们为客户）会面，以确保我们尽其所能来帮助他们高效交付。
一般来说，每个人都对我们所做的感到很高兴，但我想要开始搜集数据资料，来验证从采用 DevOps 开始到底改变了多少事情。
InfoQ：在 ITV 的 DevOps 旅程中，接下来会有什么挑战和阻碍呢？
Clark：找到优秀人才一直是挑战。我总是说要雇佣拥有两种品质的人：“聪明”——适应变化的能力；“友好”——融入团队的能力。找到拥有一种品质的人还比较容易，但想要找到同时拥有两种品质的就非常困难。此外钱也不够了，我们列出的项目已经花掉了所有预算，但还在继续列举。
评论