ITV公司的通用平台主管Tom Clark介绍了公司在2012年开始实施DevOps的过程，包括最初的小规模试验及其带来的成功，以及如何将DevOps推广到整个企业。他还分享了在这一过程中遇到的文化和技术挑战，并讨论了DevOps对公司的影响。
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：找到优秀人才一直是挑战。我总是说要雇佣拥有两种品质的人：“聪明”——适应变化的能力；“友好”——融入团队的能力。找到拥有一种品质的人还比较容易，但想要找到同时拥有两种品质的就非常困难。此外钱也不够了，我们列出的项目已经花掉了所有预算，但还在继续列举。
\
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
