我很高兴第一次与Ticketmaster的VictorGajendran面对面会面，他将于今年1月21日和22日在加利福尼亚SCaLE14x首次亮相在加利福尼亚州帕萨迪纳举行的会议。在这次会议上，他将与与会者讨论他的公司如何使用开源机制，以及如何推动小团队成为更大的整体项目的重要组成部分。我知道人们期待您谈论您用于经营业务的各种免费或开源技术解决方案。关于这个话题，您想与我们分享什么？事实上，Ticketmaster已有近40年的发展历史，一直在努力打造适合自己的技术栈。我们使用了一系列技术，从VAX仿真器到现代Docker容器。公平地说，我们绝对是一家基于开源的企业。我们最新的云基础设施大部分是基于Xen的，剩下的一小部分负载由OpenStack实现。我们首选的操作系统是Linux。我们的软件交付平台包含大量开源技术成果，如Git、Jenkins、Rundeck、Docker等。使用免费和开源工具的决定是最近几年做出的，还是Ticketmaster长期以来一直是开源项目的坚定支持者？Ticketmaster绝对是开源项目的坚定支持者，这种指导理念也延续了很多年。我们坚信，一个大规模的开源社区可以带来超越各种解决方案提供商的技术问题解决速度。我什至坚信，正是这种基于开源机制的理念，让我们拥有了出类拔萃的敏捷性，从而在票务行业保持领先地位。当您决定走上DevOps道路时，您是如何选择执行它的？雇用一部分在DevOps环境中具有实践经验的新成员，还是对现有员工进行有针对性的培训？两者都可用。我们的技术团队有1000多名成员。在我们仍在引进新的技术人才的同时，我们也投入了大量资源来帮助我们现有的工程师进一步发展，因为他们是确保Ticketmaster不会重蹈过去覆辙的支柱.对于那些计划在未来逐步采用DevOps机制的公司，您能总结出对他们来说最重要的实施原则之一吗？营造一种学习文化，确保每个员工都能诚实地面对他们在突破技术界限时所犯的错误，并且不会为此感到羞耻。你如何引导自己将大任务分解成许多小任务？这个工作看起来很有挑战性！我们将践行我们作出的承诺原则。例如，Ticketmaster的目标之一是以粉丝喜欢的方式享受娱乐内容。技术部门将这一承诺转化为具体工作，包括构建应用程序以帮助粉丝更轻松地查找和购买活动和演出的门票。现在，TechOps部门正在进一步拆分任务，即“进一步提高应用的可访问性和易用性，让粉丝更积极地使用我们的应用。”接下来，每个独立团队将任务进一步拆分，或将业务承诺“翻译”为子承诺。这些子承诺既适合更大的“超级”承诺，也适合团队内的交付框架。这种分散的方法不仅可以帮助我们利用每个团队的特定角色，还可以调整整个企业的业务执行方式。那么谁负责将任??务拆分成更小的子任务呢？您在开展此类工作的过程中是否遇到过阻力，或因拆分结果不科学而在多个部门间反复踢球？各级领导负责任务分工。高层管理团队和各级领导将高层业务承诺“转化”为与具体部门相关的承诺，同时认真考虑其实际可行性。通过确保每个成员能够适应和契合企业/公司的整体发展目标，我们的员工将有相当大的工作动力。不要误会我的意思，在整个推动过程中当然会有阻力。但是，由于我们的科学实施，所有问题都是可控的。您认为Ticketmaster系统面临的最大挑战是什么具体问题？它是规模。当涉及到规模时，即使是最好的问题解决方案也会崩溃。我们希望能够使用开源解决方案以令人满意的敏捷性来解决业务进步所面临的挑战。但是，我们还必须确保它能够继续全面运行。这一挑战让我们保持警惕，并激励我们不断审视自己并改进我们的流程。原标题：经验教训（艰难的方式）大规模开展DevOps
