转载

以规模化方式推动DevOps工作中的经验与教训

我有幸第一次与Ticketmaster公司的Victor Gajendran面对面进行交流，而他也将第一次出席今年1月21日与22日在加利福尼亚州帕萨迪纳召开的SCaLE 14x大会。在此次大会上，他将同与会者们共同探讨他的企业如何运用开源机制，以及如何推动各小型团队成为大型整体项目中的重要组成部分。

我知道，人们肯定期待着您能聊聊企业运营当中所使用的各类免费或者开源技术方案。关于这一议题，您有什么愿意同我们分享的？

事实上，Ticketmaster公司已经拥有近40年的发展历程，而且其间一直在努力构建适合自己的技术堆栈。我们曾经使用过一系列技术成果，从VAX模拟器到现代Docker容器可谓不一而足。公平地讲，我们绝对算得上是一家以开源为基础的企业。我们的首选云基础设施大部分基于Xen，剩余的小部分负载则由OpenStack负责实现。我们的首选操作系统是Linux。我们的软件交付平台则包含有大量开源技术成果，例如Git、Jenkins、Rundeck以及Docker等等。

使用免费及开源工具的决策是近些年才制定的，还是说Ticketmaster从很久之前就一直是开源项目的坚定拥护者？

Ticketmaster公司绝对是开源项目的一位坚定拥护者，而且这种指导思路已经持续了很多年。我们坚信规模庞大的开源社区能够带来超越各方案供应商的技术问题解决速度。我甚至坚定地认为，正是这种基于开源机制的理念才能够让我们具备能够在票务行业当中保持领先的出色敏捷性。

当您做出决定计划迈上DevOps道路时，您选择了怎样的具体执行方式？雇用一部分在DevOps环境方面拥有实践经验的新成员，还是对现有员工进行针对性培训？

两种都有。我们的技术团队拥有超过1000名成员。尽管我们仍在不断引入新的技术人才，但我们同时也会投入大量资源帮助现有工程师进一步成长，因为他们正是能够确保Ticketmaster公司不会再度犯下以往曾经出现过的各类错误的中坚力量。

对于那些未来有计划逐步采纳DevOps机制的企业，您能否为他们总结出一项最为重要的实施原则？

创建出一套学习文化，确保每位员工都能够在推进技术界限时都能够以诚实的态度坦言自己犯下的错误且不致以此为耻。

您是如何引导自己将大型任务拆分成众多小规模任务的？这项工作似乎颇具挑战！

我们会践行自身所做出的承诺原则。举例来说，Ticketmaster公司的一大目标在于以粉丝们喜爱的方式享受娱乐内容。技术部门会将这样一种承诺“翻译”成具体工作内容，包括构建相关应用程序以帮助粉丝更轻松地查找并购买赛事及表演门票。现在，TechOps部门则进一步将任务进行拆分，即“进一步提升应用程序的可访问性与可用性，这样粉丝们就能够更积极地使用我们的应用程序。”接下来，各独立团队会进一步对任务进行拆分，或者将业务承诺“翻译”为子承诺。这些子承诺既与规模庞大的“超级”承诺相契合，同时又同该团队内部的交付框架相适应。这种分散化方式不仅能够帮助我们充分发挥各团队的具体作用，同时还调整了整家企业的业务执行方式。

那么谁来负责将任务拆分成更小规模的子任务？这类工作在推行过程中有没有遭遇过阻力，或者由于拆分结果不够科学而导致几个部门间反复踢皮球？

每个层级的领导者们负责进行任务拆分工作。高层管理团队与各层级的领导者们会将高级业务承诺“翻译”成与各个具体部门相关的承诺，同时认真考虑其实际可行性。通过确保每位成员都能够与业务/公司总体发展目标的这种适应性与契合性，我们的员工将拥有极为可观的工作动力。不要误会，整个推进过程当然也存在着抵触情绪。然而，由于我们采取了科学的实现方式，因此所有问题都具备可管理性。