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

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