我有机会与 Ticketmaster 的 Victor Gajendran 进行了交谈，他将首次参加（并在会上发言）SCaLE 14x，今年的 SCaLE 14x 将于 1 月 21 日和 22 日在加利福尼亚州帕萨迪纳举行。他将向与会者介绍他的公司如何使用开源，以及如何让您的小团队成为庞大而高效的整体的一部分。
了解更多关于他的演讲 DevOps 大规模实践经验教训（惨痛教训） 的信息，请参阅本次访谈。
我知道人们会很乐意听到您正在使用的免费或开源技术。您能告诉我们些什么？
Ticketmaster 成立 40 年的事实反映在其技术堆栈中。我们使用各种技术，从 VAX 模拟器到现代 Docker 容器。可以公平地说，我们是一家基于开源的公司。我们的主要云基础设施主要是 Xen，还有一些 OpenStack。我们的主要操作系统是 Linux。我们的软件交付平台充满了开源技术，如 Git、Jenkins、Rundeck、Docker 等。
使用免费和开源工具的决定是相对较新的，还是您会说 Ticketmaster 是早期的采用者？
Ticketmaster 绝对是开源技术的早期采用者，而且已经很长时间了。我们真诚地相信，庞大的开源社区可以比任何单个组织更快地解决技术问题。我甚至敢说，这种基于开源的理念赋予了我们成为票务行业领导者所需的敏捷性。
当您决定开始 DevOps 之旅时，您是引进了在 DevOps 环境中具有经验的新人，还是专注于支持对现有人员的培训？
两者都有。我们的技术组织拥有 1000 多名员工。在我们继续引进新的和现有的人才的同时，我们也在大力投资于我们现有的工程师，因为他们是那些可以确保我们不会重蹈 Ticketmaster 过去犯过的错误的人。
您会给明天即将开始 DevOps 之旅的另一家公司提供哪一条最重要的建议？
创建一个学习文化，让每个人都感到可以安全地犯下诚实的新错误，同时他们也在突破技术的界限。
你们是如何训练自己将大型任务分解为较小任务的？这听起来很有挑战性！
我们实践承诺原则。例如，Ticketmaster 的目标之一是让粉丝以他们想要的方式获得娱乐。技术组织会将此转化为构建能够增强粉丝能力的应用的承诺。现在，TechOps 组织会将其分解为：“使应用程序可访问且高度可用，以便通过我们的应用程序增强粉丝的能力。”然后，各个团队会将此业务承诺进一步分解或转化为与其“超级”承诺相符的子承诺，但该子承诺可在该团队的范围内交付。这种分散式方法不仅帮助我们增强了团队的能力，而且还协调了整个组织。
谁负责将任务重新安排成较小的块？当事情被移动时，是否有任何抵制或阻力？
各个级别的领导者都负责。高级领导团队和各个级别的领导者将高层业务承诺转化为与其团队相关的承诺，同时牢记现实的约束。通过确保每个人都感受到与企业/公司更大目标的联系，我们的员工非常有动力。不要误会我的意思——确实有阻力。然而，由于我们采取的方法，它是可控的。
您认为 Ticketmaster 系统中最独特的挑战是什么？
规模。即使是非常完善的问题，也不能保证在我们的规模下也能奏效。我们希望在通过开源解决方案解决业务挑战方面非常敏捷。但是，我们必须以某种方式确保它在完全扩展后能够工作。这个挑战一直在让我们保持饥饿感和警惕性。
评论已关闭。