HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

Connon MacRae 访谈:Ticketmaster 的运维模型及 DevOps 采纳

  • 2017-11-22
  • 本文字数:3611 字

    阅读完需:约 12 分钟

本文要点

  • 并不存在通用的 DevOps 模式,会有多种操作模型共存,其中包括嵌入运维团队成员、以运维人员为中心化对开发团队提供顾问、以运维平台组向开发团队提供内部服务。
  • 文化转型是采纳 DevOps 中的主要挑战,应转向一种允许团队失败并重视学习的文化。
  • 经切实严格测试的代码审查流程,可对(合规性)问题做出更快的响应,并且更安全。
  • 对于自己构建并运行服务的自治团队,事件管理(Incident Management)愈发复杂。提供好的可视升级工具是至关重要的。
  • 虽然容器和 Kubernetes 提供了特具价值的抽象与功能,但需要大量的投资和关注。

在近期的 WinOps 2017 伦敦大会上,Ticketmaster 公司的技术运维负责人 Connon MacRae 做了一个具有深度的主题演讲,题目是“Ticketmaster 的DevOps 演进之路”( Evolution of Ticketmaster’s journey to DevOps )。

InfoQ 联系了 MacRae,以了解 Ticketmaster 在采用 DevOps 中面临的挑战和取得的成功,及对于 Ticketmaster 这样一个全球化、多时区并全天候提供服务的企业,企业的十四种不同的核心票务产品的合规性和运营情况。对话中还探讨了 Ticketmaster 的技术成熟度模型工具,以及如何使用该模型避免相互责备并促成积极变化。

InfoQ:您能简单介绍一下自己吗?您的工作情况,以及是什么将您引入到 DevOps 中?

Connon MacRae:我在 Ticketmaster 负责国际技术运维团队,其中包括公司的产品和应用支持、系统和网络以及数据中心。我们的主要关注点是力图使产品和工程团队更为自治,并拥有自己的产品。归结起来,我的兴趣和技术与产品团队中的同事一样,即必须在自身的生态系统中做出更频繁但更可持续的改进,为用户和粉丝构建最好的购票体验。这是我们的业务所必需做到的。我的职责是促成这一点的实现。

InfoQ:Ticketmaster 是如何开始采纳 DevOps 的?你们采取的第一步是什么?为什么?

MacRae: Ticketmaster 已采纳 DevOps 多年,这使得我们能以必要的步伐交付新功能和改进。当前,我们正努力创建一种“产品,项目和技术”模型,实现三者间更紧密的合作。

InfoQ:Ticketmaster 现在处于 DevOps 转型的哪一个阶段?

MacRae: 这取决于不同的团队。一些团队的进展很快。如果团队是工作于 AWS 上的,那么这些团队早已具有一系列的工具,对 DevOps 更友好。一些工程团队已是非常自治的,但可能依然缺失对运维的理解。问题取决于团队所使用的技术栈。考虑到在正常运行时间和重要性上的要求,有一些组依然具有运维层,但是我们已尽力将这些团队置于同一领导层下,让它们齐头并进,减少相互冲突,向同一目标看齐。各个团队的 DevOps 转型进展不一。

InfoQ:转型中依然面临着哪些主要挑战?

MacRae: 一个主要挑战是文化上的。在将人们聚在一起并理解驱动冲突的致因的过程中,同理心可能是最重要的。通常团队“缺乏对自身无知之处的认识”,因此我们依然能看到团队的模式会因“阻碍者”而迟迟推出。这是一件困难的事情,因为在“技术”中充斥了大量聪明的人,这些人并非总是能了解自身的盲点所在。技术运维必须依靠自身,虽然我们希望人们开展合作。推行小组学习的过程可能会令人沮丧,但最终重要的是使得团队可以自由地犯一些小错误。在运维背景下,我很难看到允许犯错误的情况。但如果想要建立一种信任和学习的文化,这是很重要的。

InfoQ: 在您的演讲中提到,十五年前 SOX 和 PCI 等规则的引入,导致了一种“谷仓式”(Silo)工程结构。那么您是如何在保持兼容的同时,演进到一种更为协作的模式的?

MacRae: 我们仍然在推进中,所以这是一个正在进行中的工作。如果一个可靠的并经过严格测试的流水线中具有代码审核(其中包括对基础架构代码的审核),那么我们就已勾选上了很多选项,并且可以更快地迭代。这意味着我们可以通过更快速地解决问题而提高安全性。与操作和开发团队共享 DEV/QA 的所有权,意味着任何对安全或性能的担心都会很快发生,并且在环境发生变化的情况下,我们将工程团队所面临的挑战也暴露给了运维团队。现在,工具链可用意味着共享变得更加容易。对于合规性而言,这是一个重大的改进,尤其是在自动化意味着生产访问很少甚至是没有的情况下。如果日志记录和仪表显示(Instrumentation)就可以为我们提供所需的全部洞察力,那么为什么还需要工具链?在容器环境下,除非是要查看处理状态和数据,否则不再需要 RDP 或 SSH 到系统,这时情况会更复杂一些。

InfoQ: Ticketmaster 提供全球范围的服务。您是如何构建随时轮换机制,以应对全球 24 小时可用的?

MacRae: 事实上,这非常复杂,但是在旧模型中就要简单得多。我们曾有多个全球范围内运作的团队,但是现在正在转向自治团队,这些自治团队会建立、运行和拥有自己产品。这意味着,我们需要使用一种中心化的工具去管理我们的服务目录。这就是如何运行和触发事件管理流程的关键所在。此外,好的工具也是关键因素,它可以处理升级,并提高可见性。其它一些有用的工具包括 Splunk、Grafana、OpenTSDB,以及广为采用的 ELK 栈。我们也开始使用类似于 Prometheus 的工具,还有一些商业工具。

InfoQ: Ticketmaster 通过收购其它国家已有的票务解决方案而实现全球扩张。您如何确保在保持工程部门的一致性和知识共享的同时,使收购的解决方案能够在当地市场发展?

MacRae: 不同的产品支持不同功能。虽然有时会存在着一些重叠,但是没关系。偶尔我们会快速地弃用一种技术,并且查看已有的团队是否支持我们的核心技术栈。我们的中心代码库是共享的,我们正在步入一种独立的、相互解耦的服务形态,这种服务并非是由市场驱动的,而是由能力驱动的。这意味着我们可以更快地迭代并开发我们的产品。有一点非常重要,那就是我们尝试并促进开放式协作。我们具有一个全球性的 git 实例,它提供了团队合作的场所,并提供了与其它团队项目的交流。

InfoQ: 您也提到,你们正在转向平台模式。您能解释一下,Ticketmaster 是如何定义平台的?哪些技术和流程上的改进正在实现中?

MacRae: 由于我们具有多种不同的技术栈,因此我们正为标准化设定一个很低的门槛。我们已经使用了 Terraform 和 GitLab。是否使用 Chef 或 Docker,进而是否使用一些内部库,这取决于正在运行的技术栈。我们在确定团队的关键浪费点或痛点的过程中,主要关注的是共享服务,但这还是一个相当新的事物。如何确定工程团队的适合摩擦程度,可能是一件非常棘手的事情,尽管我们在不断探讨什么是适合的。我们非常热衷于容器技术和 kubernetes,因为这些技术提升了抽象和能力,但它们也需要大量的投资和一些关注。

InfoQ:您还提到了企业所具有的异构环境和解决方案。从团队的结构和技能上看,您是如何应对运营方面的问题的?

MacRae: 通常情况下,结构拆分要基于提供功能的产品。我们将合适人员与适合这些产品的正确技能相结合。随着时间的推移,我们已经看到操作系统逐步瘦身,运行应用程序所需的时间变得更少。我们的确有一些技术栈使用了完整的技术组合,诚实地讲,虽然这种做法下运行也是很健康的,但可能会是一个挑战。但是我们已不再将 Cygwin 置于 Windows 平台上。这是一件好事。

InfoQ:Ticketmaster 是否提出了“构建者就是运维者”这样一个内部口号?如果是这样的话,传统运维在该 Ticketmaster 新方法中起到了什么样的作用?

MacRae: 当然,不同的团队处于不同的所有者状态。这的确取决于各个团队的成熟度和技术时代。我们当前有三种模式:

  1. 将运维团队成员嵌入到各个组中。
  2. 运维为设计、新项目和上线到生产过程提供咨询。
  3. 将具有运维思维的团队成员加入到平台组中,提供内部服务。

InfoQ: Microsoft 正转向采用 Linux 和开源技术,这是否有助于简化基础架构和平台管理?你们使用了什么方式?

MacRae: 我们考虑了自动化、测试和可重复性。这种技术转变可归结为,通过使用 git,chef,packer,terraform 等工具,去启用以“基础架构即代码”(infrastructure as code)作为模板、工具或咨询。这也扼杀了与操作系统间的幼稚对话。这有时会很有趣,但最终并不是很有建设性。现在我们可以真正地找到正确的工具。

InfoQ:您能否简要介绍一下 Ticketmaster 的技术成熟度模型?该模型能带来哪些好处?

MacRae: 团队根据测试、仪表显示、容灾等功能对自身开展评估。架构团队成员与工程团队在共同审查这些数据后,将这些数据输入。然后,团队可以优先处理产品团队提出的任何问题。这种做法的目标是形成一种积极的工具,而非坚持要去惩罚某一个团队。在企业内部公开结果是非常重要的,这将提升诚实度。让同事们对你的诚实度而不是结果做出评判。实际上,该模型只是让我们能够获取数据,而这些数据有助于我们做出更好的决策。

受访者简介

Connon MacRae 是一名长期供职于 Ticketmaster 的资深员工。他曾以临时工的身份在英国伦敦电话中心售票。很幸运,通过得到帮助和自身的努力,目前他在 Ticketmaster 领导国际团队的技术运营小组。

查看英文原文: Q&A with Connon MacRae on DevOps Adoption and Operational Models at Ticketmaster

2017-11-22 17:181223
用户头像

发布了 391 篇内容, 共 135.2 次阅读, 收获喜欢 256 次。

关注

评论

发布
暂无评论
发现更多内容

NFTScan 获 Google Cloud 战略支持!

NFT Research

Google Cloud NFT\ NFTScan

用这个方法给苹果电脑清理app垃圾,让电脑快如闪电

阿拉灯神丁

CleanMyMac Mac 系统 苹果软件 杀毒软件

保姆级教程:Redis主从复制原理及集群搭建

小曾同学.com

redis主从 redis哨兵集群 redis 底层原理 redis主从集群 redis数据同步原理

“码”力全开!高效开发就靠这款神器

ZEGO即构

UI 自定义组件 即构UIkits UIKits

小狐狸MetaMask:探索以太坊世界的必备工具

dappweb

#区块链#

告别繁琐,一键同步!聚道云助力企业人力资源大升级

聚道云软件连接器

案例分享

降本增效下的自动化测试实践

老张

软件测试 研发效能 自动化测试 质量保障

对象业务的追加写接口

不在线第一只蜗牛

对象 业务开发

研发提效:想快速定制一个OLAP应用?你可以这么做!

京东零售技术

架构 后端 研发提效 企业号 6 月 PK 榜

你还不懂区块链就out了

区块链开发团队DappNetWork

生成式 AI 码力全开,动手搭建未来商城

亚马逊云科技 (Amazon Web Services)

Serverless

1688批量自动下单接口丨1688代采系统丨1688跨境代采系统

tbapi

1688批量采购 1688代购系统

扫码报名活动时,如何避免重复报名?

草料二维码

二维码 活动报名 草料二维码

Python高频面试题解析公开课

测吧(北京)科技有限公司

测试

RESTful API 设计原则:优化您的接口设计

Liam

后端 Rest API APi设计 REST API

利用Python调用KimiGPT API接口

我再BUG界嘎嘎乱杀

Python 后端 开发语言 GPT

面试官:说说Netty对象池的实现原理?

王磊

Java

发挥财务规划隐藏的超能力,实现企业业务与财务的协作

智达方通

企业管理 全面预算管理 财务管理 财务规划

Stable diffusion采样器详解

程序那些事

程序那些事 Stable Diffusion

用Python打造你的微博热搜追踪器

我再BUG界嘎嘎乱杀

Python 后端 开发语言

Python 中有没有所谓的 main 函数?为什么?

EquatorCoco

Python 开发语言

仓库数据同步难题如何轻松破解?

聚道云软件连接器

案例分享

软件测试公开课 | Python高频面试题解析公开课

测试人

软件测试

斯坦福 AI 团队被曝抄袭中国大模型开源成果;Zoom 创始人谈视频会议未来丨 RTE 开发者日报 Vol.218

声网

Connon MacRae访谈:Ticketmaster的运维模型及DevOps采纳_DevOps & 平台工程_Manuel Pais_InfoQ精选文章