[关闭]
@Rays 2017-09-30T01:12:42.000000Z 字数 3536 阅读 1407

与Sanjeev Sharma的问答:DevOpsDays新西兰大会的主题演讲

文化&方法 DevOps


摘要: Raf Gemmail采访了IBM的Sanjeev Sharma,采访内容涉及他将在DevOpsDays新西兰大会闭幕式上的主题演讲,演讲内容涉及从阿波罗13号事件中我们所能学到的DevOps和SRE经验教训。

作者: Rafiq Gemmail

正文:

Sanjeev Sharma是IBM DevOps采用部门的CTO。他将于十月在DevOpsDays新西兰大会上做闭幕式主题演讲,题目是“当DevOps遇上SRE:从阿波罗十三到Google
SRE
”(When DevOps Met SRE: From Apollo 13 to Google SRE)。Sharma以不幸的阿波罗计划为例说明了事故响应,并将探讨DevOps和SRE(Site Reliability Engineering,站点可靠性工程)实践之间的交叉情况。

Sharma是一位DevOps领域的作家、活跃的评论人士和思想引领者。Sharma近期推出了他的最新力作《采用DevOps的战术手册:在各种速度IT企业中采用DevOps的指南》(The DevOps Adoption Playbook: A Guide to Adopting DevOps in a Multi-Speed IT Enterprise),书中给出了一些基于经验和观察的“比赛”和“比赛计划”,用于企业中场景敏感的DevOps采用。

InfoQ采访了Sanjeev Sharma,内容涉及DevOps、阿波罗十三的SRE以及他的新书。

InfoQ:能为我们介绍一下您当前的职责,以及感兴趣的领域吗?

Sanjeev Sharma:和许多IBM的杰出工程师一样,我也有多个头衔。我的主要角色是IBM DevOps采用部门的CTO。在此角色下,我负责领导全球范围的技术销售和采用社区,意在实现跨IBM工具和服务投资组合的DevOps投资。我个人是与一些IBM的最大客户一起工作,帮助客户驱动DevOps在企业中的采用,解决在过程、技术和文化这三个领域中的采用。

我的第二个角色是IBM的全球云技术实践领导者。在此角色下,我领导IBM的全球云架构社区,担当社区成员的“工会领导”,对用于云采用的架构解决方案、平台和架构提供方向和指引。我个人关注的是“首个”(FOAK,First Of A Kind)和复杂的解决方案,这些解决方案适用于我们的客户,实现将他们的应用迁移到云上。

我感兴趣的主要领域是微服务和容器。随着云原生应用的广泛采用,整个游戏场正在发生变化。我们正从大型单体应用迁移到由微服务构成的应用,这些应用将运行在容器中,甚至是作为无服务器功能。如何开发、测试、部署、运行和管理这些服务(或者甚至是微服务),这是我越来越关注的问题。

InfoQ: 作为该领域的思想引领者,对您而言,DevOps意味着什么?

Sharma: 我对DevOps的看法非常简单。在我看来,DevOps就是应用精益原则做出行动,将来自于业务的需求部署为运行在生产环境中的代码,并以最高效和最有效的方式向客户交付业务价值。DevOps从这些运行在生产环境中的代码获得反馈,持续地改进我们交付给生产环境的内容以及交付方式。反馈是用于改进下面三个领域:

(1)我们刚刚交付的代码。它们是否按期望发挥功能并执行?

(2)我们交付代码的环境。环境是否按期望发挥功能并执行?

(3)我们交付代码和环境的过程。对于下一次交付循环,我们如何使过程更精益,更高效?

我喜欢这个定义,因为它是技术可感知的,也是过程可感知的。DevOps并不是一种方法,也不是对企业中一个角色的工作描述。它就是我们所做的事情!

InfoQ:能向我们透露一下您将在DevOpsDays大会上的演讲内容吗?

Sharma: 这个演讲源于一位客户向我请教DevOps和SRE间的差别。当时我被难住了,所以告诉她我需要稍后才能回答。因此,我一回家就着手去做,查看了我能找到的所有关于SRE的文档资料,力图将其适配到我头脑中的DevOps模型。然后我做了自己认为是最好的事情,即写了一系列的博客,解释了我对DevOps和SRE间交叉点的理解。

InfoQ:从阿波罗十三事件中,我们能了解哪些关于DevOps和SRE的经验教训?

Sharma: SRE的一个核心方面是事故响应和管理。记得电影《阿波罗十三》记录了(一定程度上以戏剧化方式表现了)阿波罗十三事故,电影大量聚焦于任务控制地面工程师的响应情况,这挽救回了宇航员的生命。对于我而言,这些工程师就是真正的英雄。就此而言,如果我们分解了地面工程师对事故检伤分类的方式,分解了应被解决的挑战,并按优先级开发出解决每个挑战的响应,我们就会意识到,这些工程师的方法与当前的SRE团队的响应方式并没有多少差别。事故响应依然是了解状况、检伤分类和实时响应。方法的核心依然是一样的,无论是在空间任务中,还是在运行一个通过云技术分享表情符号的应用。

InfoQ: 采纳DevOps的企业将从投资于SRE实践中受益,对此您是怎么看的?

Sharma:迁移到云原生应用的企业必须要在SRE上投资。对于用户可用性和响应性的期望,以及业务所期望的SLO(Service Level Objective,服务水平目标),它们只能由SRE实践和专门的团队交付。我们不再讨论如何管理运行静态应用集的上百台服务器。我们讨论的是成百上千的容器,它们在规模上弹性可变,服务于动态数量的微服务,并都用新版本持续更新,这都要归功于持续交付。如果没有DevOps和SRE实践到位,所有这些不能被运行和管理。

InfoQ: 考虑到并非所有的产品都是性命攸关的,如果我们过于关注反脆弱和容错设计,而无视价值或场景风险,这会存在哪些危险?

Sharma: 对于IT企业,“反脆弱”(Antifragility)是一个新领域。从“传统快速恢复(Resilience)”转到“反脆弱”系统需付出一些基本的代价。当然,我们需要理解业务需求和业务期望的SLO,以验证反脆弱系统的需求。这就是说,由云服务提供者提供的云服务本身,在本质上应该总是反脆弱的,无论云服务提供者是外部云服务提供商还是内部IT部门。这正是云服务定义的根本所在。它不能宕机,也不能无响应。

InfoQ: 您能向我们介绍一下新书的内容吗?

Sharma: 《采用DevOps的战术手册》对我而言是一个激情项目。该书是对我作为IBM全球DevOps技术领导的四年中的所有谈话、讨论和经验教训的提纯(是一本超过400页的内容提纯)。我已经与全球近百位客户交流,学习到并分享了很多DevOps相关内容,以及如何大规模采用DevOps。该书将所有这些讨论和经验教训形成文字,使大家可以阅读并从中学习。

InfoQ: 在不同类型和规模企业中,这些采用模式的扩展情况如何?

Sharma:我们必须认识到,即便是在单一企业中,IT组织也既不是同质的,也不是单体的,甚至在同一部门中也有变化,这是根据实践者和团队的成熟度、技术栈、过程和文化的差异而有所不同的。这使得比“两个披萨”团队更大规模的DevOps采用成为一个挑战。这就是为什么在采用一个方法时不存在一套实践的原因。

采纳适合的实践具有一整套的方法,我在书中称它们为“比赛”(Play),因为它类似于体育运动中的比赛。在体育比赛中,运动员如何处理下一步依赖于多个因素,例如,对手是谁,是赢是输,攻击还是防守,场上的队友,队友的竞技状态,赛场情况等。这决定了比赛将如何进行。同样,团队和企业的领导需要决定执行哪个DevOps“比赛”,其中应考虑当前的“比赛条件”和顺序情况。我的书正是帮助人们去做这些事情。这就是为什么我称其为“战术手册”(Playbook),它类似于教练用于体育团队的战术手册。当然,书中充斥了对体育运动的类比。

InfoQ: 对DevOpsDays新西兰大会,您最期待的是什么?

Sharma: 这是我首次来新西兰!我听说这里的酒不错……

严肃一点,我十分期待能遇上新的朋友,并和一些有意思的人打交道。这是我在参加此类活动中最喜欢的事情。我期待能从各位演讲者、组织者,更重要的是从参与者中学习。因此,如果有InfoQ读者也参会的话,可在会议间歇联系我。我们可以聊聊我们是如何采纳DevOps的,我们有哪些经验教训,我们的工作中有哪些新的东西和有意思的内容。我非常喜欢听到这些。

DevOpsDayz新西兰大会将于10月3日至4日期间在奥克兰市举行。大会期间,Sharma等多位国际和本地演讲者将就文化和技术话题展开分享。

查看英文原文: Q&A with Sanjeev Sharma on His DevOpsDays NZ Keynote

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注