GMTC深圳站本周日开幕,14大专题全部上线,完整日程>> 了解详情
写点什么

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:18802
用户头像

发布了 381 篇内容, 共 101.7 次阅读, 收获喜欢 233 次。

关注

评论

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

测试技术

牛鬼蛇神VS魑魅魍魉

Instana:如何评价可观察性方案?

行人23

Flutter安卓项目第一次启动失败解决方案

人生如梦

flutter

管理笔记 [9]:组织与督导,管理者的两个宝

俊毅

28天写作

实例详解Linux下ulimit每个参数

运维研习社

Linux ulimit linux系统资源管理 open file

做出赋能其他人的产品是技术牛人最好的证明

刘华Kenneth

敏捷 平台

Kafka.03 - Message 介绍

insight

kafka 2月春节不断更

翻译:《实用的Python编程》02_02_Containers

codists

Python 人工智能 容器 后端 数据结构与算法

第十三周 数据应用二 作业 「架构师训练营 3 期」

feiyun123

一文搞懂Linux下Ulimit资源限制

运维研习社

Linux linux命令 ulimit

关于Linux系统中Message中的Session日志详解

运维研习社

Centos 7

【STM32】CubeMX+HAL 输出PWM

AXYZdong

硬件 stm32 2月春节不断更

2021年目标,我打算这样去实现

谙忆

为行动而读书-《麦肯锡精英高效阅读法》读书笔记

代码技艺

读书笔记

Dart 后台开发 Aqueduct 插入数据 获取数据API

人生如梦

flutter dart

你好,2021~

数据社

程序员 2021年展望

为什么做这样一个产品之容量评估篇

数列科技杨德华

28天写作

Nginx如何监控各server的流量

运维研习社

nginx Prometheus zabbix upstream

抓包带你详解TCP的11种状态

运维研习社

三次握手 四次挥手 TCP/IP 抓包

Jenkins通过OpenSSH实现Windows下的CI/CD

运维研习社

jenkins CI/CD Windows Server 2012 R2

Nginx加密套件配置不当,造成SSL无法建立连接

运维研习社

nginx zabbix SSL证书 证书监控

面试官一上来就问我Chrome底层原理和HTTP协议(万字长文)

魔王哪吒

前端 后端 chorme 28天写作 2月春节不断更

学习 Java 语言,你必须知道的 Java 简史

白色蜗牛

Java spring 程序员

BOE(京东方)全面发力8K 成为央视8K超高清技术合作伙伴

爱极客侠

如何解决Nginx实现动静分离或反向代理时资源路径不匹配

运维研习社

nginx 反向代理 动静分离

创业公司人力资源体系建设的几点思考

一笑

人力资源 28天写作

牛启新春|优质文章人气大挑战

InfoQ写作平台官方

活动专区

京东方“8K+5G”技术助力牛年春晚 开启超高清视频直播时代

爱极客侠

Dart 后台开发 Aqueduct集成Swagger客户端

人生如梦

flutter dart

说说规则引擎

张老蔫

28天写作

IO 模型知多少 | 理论篇

圣杰

io

2021星空论坛:破局创新,论道数字化转型

2021星空论坛:破局创新,论道数字化转型

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