与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