DevOps 与站点可靠性工程 (SRE)

DevOps 还是 SRE？这是本周的讨论主题。在本期节目中，我采访了 Josh Duffney，探讨了 DevOps 和站点可靠性工程 (SRE) 之间的区别。

以下是我们在本期节目中讨论的资源：

• 什么是站点可靠性工程？
• SRE 以及将运维视为软件问题的价值
• 网站可靠性工作手册
• DevOps团队类型
• DevOps 反类型
• 团队拓扑结构：组织业务和技术团队以实现快速流程
• 云系统管理实践：大型分布式系统的设计与运维

Josh Duffney 是一位拥有十年系统管理和工程经验的 DevOps 工程师。他是 Pluralsight 的作者，撰写了多门关于自动化和基础设施开发的课程，并在 duffney.io 上开设博客。Josh 积极参与 PowerShell 和 DevOps 社区，乐于分享知识，更重要的是，他喜欢向业内人士学习。工作之余，Josh 奉行数字极简主义，努力在数字世界中寻求平衡。此外，他还喜欢举重和练习巴西柔术。

完整文字稿

Mike Pfeiffer：
大家好！我是Mike Pfeiffer，我和Josh Duffney正在LinkedIn上直播。希望大家今天过得愉快。看来今天有很多朋友在线。今天，我和Josh要聊聊DevOps和SRE的区别。这可是最近的热门话题，对吧，Josh？

乔什·达夫尼：
没错，这是个棘手的问题。

迈克·普费弗：
是啊，没错。让我想想。我先跟乔伊斯、维韦克和杰夫·特鲁曼打个招呼，嘿，你们好啊。艾哈迈德，很高兴见到你，我的朋友。好了，乔什，咱们来聊聊DevOps和SRE的区别吧。这是个经常被提及的问题。现在很多人都在申请这些新职位，各种职位层出不穷。你肯定经历过这个过程。在我们深入探讨之前，能不能先介绍一下你的背景，你是谁，你做什么工作？所有正在观看直播的朋友们，请在评论区留言提问，我们会在这里解答。

Josh Duffney：
当然。我从事IT运维工作已经10年了，过去三年我一直担任DevOps工程师，或者至少头衔是DevOps工程师。因此，过去几年我的工作重点主要是将DevOps原则和实践应用于运维，包括基础设施代码和发布管道工程等方面。

迈克·普费弗：
是的，所以在这种模式下，就是从传统的技术专家或传统的系统管理员角色进行某种转型，对吧？我认为这有点像你早期所做的。

乔什·达夫尼：
是的。

Mike Pfeiffer：
然后说到 DevOps 之类的东西，我相信你一路以来一直在浏览招聘网站，了解其中的区别，以及人们在寻找什么，所以也许我们可以把它分解开来，谈谈 SRE 是什么，它与 DevOps 有什么区别，以及为什么人们甚至不应该关注它。

Josh Duffney：
当然，没错。我的意思是，就我的经验而言……我想首先要注意的是，DevOps 和 SRE，或者至少是 DevOps，对很多公司来说都是一个演进的过程，所以即使职位名称相同，组织结构或组织设计也会因公司而异，比如“我们需要一个 IT 管理员，你们负责后端系统”。事情并没有那么简单明了。很多组织在 DevOps 或 SRE 中都采用了不同的模式和反模式，所以你需要多问问题，弄清楚他们处于这个演进过程的哪个阶段，并意识到每个地方的情况都不一样。更好的做法是，更关注不同职位所需的技能和技术。

Mike Pfeiffer：
这确实不错。我想稍后再谈这个，不过现在我可以看到大家的评论了。那么，大家好！Gregor Suddy来了。他是摩根大通的第一位SRE（站点可靠性工程师）。这很有意思，因为SRE的起源实际上来自谷歌。对吧？我这周早些​​时候在LinkedIn上分享了一个谷歌的视频，讲解了SRE和DevOps的区别。顺着这个话题往下看，你会发现2003年谷歌招了一个人，他当时就像是SRE的负责人。让我想想，他叫什么名字？Ben Trainer，现在他是谷歌工程团队的核心人物之一。他们算是SRE概念的先驱，所以听说Gregor曾在摩根大通担任SRE，这很有意思。真酷。

Mike Pfeiffer：
Apu，Condi，你好吗？Adeo，你好啊！也祝你新年快乐。Minoge，很高兴见到你。Paul，太棒了。好的，Josh，说到DevOps和SRE的招聘市场，我今天早上注意到的一件事是……有点讽刺的是，我没看LinkedIn上的职位，而是去了indeed.com，结果发现，标题里带“SRE”的职位只有1925个，而DevOps的却有25000个。

乔什·达夫尼：
是啊，比例差距相当大。

迈克·普费弗：
差别很小，对吧？

乔什·达夫尼：
有一点点。

迈克·普费弗：
所以，我想最大的问题是，它们之间有什么区别？

Josh Duffney：
就我观察，SRE 通常更成熟，它是一种更成熟的实现方式或组织架构。在我接触过和工作过的地方，SRE 通常是一个嵌入式团队，由工程师组成，或者拥有自己的独立部门，规模通常很小，他们更专注于系统监控。他们拥有非常扎实的软件工程背景，而 DevOps 则是一个更宽泛的概念，涵盖了许多不同的技能组合。所以，你可以是云工程师，可以是自动化工程师，也可以是做过一些基础设施工作的开发人员。因此，DevOps 涵盖了更多，我不知道该怎么形容，一些更基础的支柱。它没有那么具体。这有点像谷歌视频里说的，SRE 是 DevOps 的一个具体实现，因此，SRE 的范围和目标通常更成熟一些。

Mike Pfeiffer：
我跟很多人交流后也得出了类似的结论。我的意思是，现在谈论这些还为时尚早。人们在谈论这两个概念时经常提到，它们虽然起源于不同的时期，但发展时间大致相同。不过，我们各自独立发展，所以两者之间并没有重叠，也不是说它们同时出现，双方都在互相交流。对吧？从不同的讨论中，我还了解到，正如你所说，SRE（站点可靠性工程师）通常是指那些具备软件工程背景的人员，对吧？他们需要对计算机科学有深入的理解，才能构建应用程序。对吗？

乔什·达夫尼：
没错。

Mike Pfeiffer：
酷。那么，评论区有什么问题吗？哦，Chris Miller，你好！新年快乐，兄弟。很高兴见到你。Jeff Truman 说 SRE 侧重运维。DevOps 则同时支持开发和运维。是的。所以，我想这也取决于你身处何地，对吧？在某些地方，SRE 可能更侧重开发。

乔什·达夫尼：
是的。

迈克·普费弗：
这要看情况。另外，还有一点就是，人们通常所说的“DevOps工程师”到底是什么意思？很多人对这个术语的真正含义感到困惑。你觉得这重要吗？它到底意味着什么？人们真的应该纠结于这个标签吗？

Josh Duffney：
就我个人经验而言，我会把这些技能或倾向大致归类。例如，对于DevOps工程师来说，发布工程是他们关注的重点之一。大多数情况下，你需要知道如何构建CI或CD系统，以及如何通过发布管道处理变更。因此，发布工程是DevOps中非常重要的一个方面。很多DevOps工程师，其实只是把发布工程重新包装了一下，然后又加入了一些运维方面的知识，比如基础设施即代码。

Josh Duffney：
根据我的经验，DevOps 通常更侧重于运维，DevOps 工程师不需要知道如何编写或调试应用程序中的任何代码，而 SRE 则需要能够进入应用程序内部，查看内存转储之类的东西，从那个层面调试应用程序，并且比虚拟机的开关机更密切地进行监控。

Josh Duffney：
而且，就我的经验而言，SRE 团队的重点确实在于监控。他们通常是负责运行平台的团队，所以他们不仅负责监控，还拥有更具体的平台知识，例如 RabbitMQ 和 Retis。一些来自传统系统和管理领域的运维人员并不具备这些平台的特定技能。SRE 团队更专注于应用程序监控和基础设施堆栈监控。

Mike Pfeiffer：
是的。Jeff Truman 在评论里提到了，对吧？他说：“那么，抱歉，这到底是什么意思？网站可靠性工程师（SRE）？是开发人员还是运维人员，还是两者兼具？” 我觉得这个问题很有意思。这周我听了一个采访，当时我刚分享了谷歌的那篇文章，看到反响这么热烈，也了解了大家的兴趣和困惑。我听了 Pivotal 的一个 15 分钟播客，采访对象是谷歌的一位员工，他其实……他为我之前提到的那位 Ben Trainer 工作。我不确定我有没有记下他的名字。哦，对了，是谷歌的 Dave Rensin，谷歌的高级工程总监。他说的很有意思，SRE 的世界里，机器为你工作，而不是你为机器工作。

Mike Pfeiffer：
我的意思是，如果你现在是一名运维人员，你很可能经常在半夜或周末接到短信、电话或寻呼，然后立刻赶去救火，对吧？而谷歌正在努力做的，以及他们在SRE团队所做的，就像你早上到办公室，发现出了问题，但系统和服务本身仍然在运行。所以，我认为这显然有点模棱两可，但我认为这是一个很有意思的视角，对吧？他们承认系统肯定会出现故障，然后围绕这个概念进行工程设计。这样一来，我们就不会手忙脚乱、焦头烂额了。更像是：“嘿，系统肯定会出问题。但我们能够排查故障，因为我们已经制定了所有这些实践。”

迈克·普费弗：
好的，酷。所以，各种各样的评论都有。那我们回到正题，稍微讨论一下这些问题。这真是一次有趣的对话。显然，这是一个很大的概念，对吧？理查德·泰勒，你好啊，很高兴见到你。他说：“我觉得我们可能太执着于头衔了。” 是的，伙计，我也这么认为。就我个人而言，我先说说我的看法，然后让乔什说说他的想法。对我来说，尤其是我现在是自由职业者，但之前为别人工作了15年，如果我要推销什么东西，我必须了解客户真正想要的是什么。就像我之前说的，当你在indeed.com上看到成千上万个DevOps相关的职位时，你的工作就是弄清楚市场需要什么，然后创造价值。在我看来，人们用什么并不重要，重要的是找到如何创造价值的方法。我不在乎你怎么称呼它，随便你怎么叫。我要做的是通过为系统创造价值来弥合差距，而不是纠结于职位名称。你觉得呢，乔希？

乔什·达夫尼：
这是我最喜欢的一句播客名言，好像是2015年左右，是杰弗里·哈克说的吗？他说：“头衔无关紧要，但它们确实很重要。” 原因在于，头衔无关紧要，因为它们不应该妨碍你做任何事；但它们确实很重要，比如你的薪水、LinkedIn个人资料的搜索排名和关键词、权威性和认可度，它们确实具有一定的意义。所以，你必须取长补短。我认为，当人们真正比较这两者时，他们其实是在问：我的技能与这些头衔是否匹配？我最适合哪个职位？我的不足之处在哪里？因此，你必须了解每个职位的不同需求，而这取决于组织，因为这并非一成不变。你明白吗？

乔什·达夫尼：
组织在不断发展，也在不断理解，而且每个组织底层的技术栈也不尽相同。所以，你需要提升到一个更高的层次，理解你需要掌握的实践方法，比如基础设施即代码（IaC）和一些软件工程知识。你需要熟练掌握一些基础脚本语言，比如 Bash、Python 或 PowerShell。如果你能将这些概念抽象化，就能开始发现差距。这其实……虽然无关紧要，但又很重要，因为它能帮助你找到需要提升的地方。

迈克·普费弗：
是的，没错。我想回答一个问题。这里有很多非常好的问题。我想先回答一下金伯利·梅迪纳的问题。但我确实想提一点。对我来说，如果你要在 Netflix、LinkedIn、亚马逊或其他公司工作，那么 SRE 的含义显然与拥有 500 个用户的政府机构或中小企业有所不同。有时，人力资源部门、招聘人员甚至招聘经理都不清楚他们真正需要什么，所以他们只是试图使用一个笼统的术语。因此，你需要自己弄清楚他们所说的这个职位名称到底是什么意思，我认为这是其中的一个因素。金伯利说……她有一个非常好的问题。她说：“我最近看到很多规则都同时被列入这两个类别，那么这些工具在这两个类别之间是如何重叠的呢？” 乔希，你怎么看？

Josh Duffney：
我觉得这些工具完全重合。我的意思是，同样的工具……所以，基础设施就是代码。他们很可能也会用同样的工具来做你的 DevOps GRS3，这可能取决于公司现有的工具。他们会用 Shaft 还是 Ants Bowl？他们会用 Terraform 吗？因为他们在云端，所以想做到云平台无关？很多原则也重合。是的，这确实是个好问题，因为重合的地方太多了，很难区分两者。我也见过这种情况，招聘信息上写着“DevOps 工程师 [ORO3 00:13:02]”，实际上他们用同样的职位描述同时发布了这两个职位，所以连公司自己都搞不清楚。他们只是想尽可能多地招人。

迈克·普费弗：
我喜欢大家在评论区里用星号来表示喜欢格雷戈尔的评论，因为没有表情符号。这太棒了。天哪，问题太多了，我都应接不暇。直播间里有95个人。非常感谢大家的到来。保罗，你好吗？杰夫，谢谢你回答保罗的问题。内瓦尔，你好吗？佩德罗，很高兴见到你。凯文，你好吗？谢谢你们在聊天室里回答问题。这真是太好了。乔什，我们直播前聊到一本书，我知道你很喜欢这本书。你给我发了一些书中的图表，我知道你觉得这些图表很有价值。那么，我们来简单聊聊吧，因为我觉得现在还早，对吧？所以，我们既要弄清楚人们使用这些术语的含义，也要努力发展自己的事业，对吧？

迈克·普费弗：
我们经常谈到这一点，你现在的工作要求你做什么，以及他们分配给你的任务，可能并不利于你未来五到十年的职业发展，所以规划好自己的职业生涯始终是你的责任，你在这方面做得很好。我很想听听你最近在读的哪本书与此相关，也想听听你对那些着眼于长远职业规划而非仅仅关注眼前工作的人们有什么建议。

Josh Duffney：
是的。这本书叫《团队拓扑结构》。我想你指的是这本书，里面有一些非常棒的图表。他们是DevOps拓扑结构的创建者，所以……我会把这些图表发给Mike，这样我们之后就可以把它们添加到DevOps反模式和最佳实践的链接里。这本书总结了组织普遍采用的一些模式。其实我一开始很不想读这本书，因为它讲的是组织设计，而我作为一个个人贡献者，觉得它对我没什么价值。但事实并非如此，了解一些组织设计的基础知识，以及全球各地的团队是如何发展他们的DevOps实践的，确实让我对如何在组织内部倡导变革有了更好的思考，也让我知道如果想离开公司应该寻找什么。因此，它为你提供了一个很好的框架，让你可以询问有关你所申请的特定组织的情况，例如他们正处于怎样的发展阶段，采用什么样的模式。他们是否处于一种反模式，只是将系统管理重新包装成 DevOps，而你目前的工作和那份工作之间实际上没有任何区别？是的。

Mike Pfeiffer：
是的。评论区里有个问题我觉得很重要，Kevin Sapp 问道：“在如今的就业市场，DevOps 相关认证还重要吗？比如微软、AWS、GCP 的认证。” 我绝对会说，认证的重要性是百分之百！认证比以往任何时候都更加重要。在我看来，认证一直都很重要，因为它能让你深入了解技术的方方面面，并迫使你验证自己的技能。有些认证更注重实践操作，对吧？但我认为，尤其是在过去 12 到 18 个月里，五年前，我们的客户从来不会问“你们的工程师有没有认证”。而现在，他们都会问，所有客户都会问，这让我觉得很神奇，以前可不是这样的。所以，市场需要有认证的人才，而我们所有人……如果你是为了找工作而购买认证，你就是在和一群实力强劲的求职者竞争，你必须拿出自己最好的一面。把自己包装成一个拥有认证资格的人，这非常重要。你怎么看，乔希？你很看重各种认证，对吧？

乔什·达夫尼：
嗯，是的，我刚拿到AZ103认证。我很开心，这样就能顺利度过2019年的最后一个月了。说来也巧，我还有……谢谢。我准备写一篇博文，借用了我之前分享的那句名言，标题是《认证无关紧要，但它们绝对重要》，这篇文章正是我对“认证的利弊是什么？”这个问题的看法。我认为认证绝对重要，原因有很多。最主要的一点是，它能激励你不断进步。所以，我先退一步说说。很多企业还没有真正理解云计算。他们不了解自己的云战略，也没有全面投入其中，而云计算又在不断发展变化，他们还在努力寻找自己的定位，以及如何应用云计算，因此犯了很多错误。

乔什·达夫尼：
所以，认证能让你作为个人提前了解相关技术栈，从而更好地指导你公司或未来雇主的技术决策。所以，我认为现在比以往任何时候都更加重要，迈克，你说得对，因为技术发展日新月异。在日常工作中，你没有时间去了解最新的技术发展趋势，去探索云技术的最佳实现方案和最佳应用案例，而认证则为你提供了一个框架，让你无需自学就能掌握这些知识。

迈克·普费弗：
没错。

乔什·达夫尼：
有些框架相当松散，你很难弄明白。你需要一些指导原则才能学习这项技术。

迈克·普费弗：
是啊。我的意思是，你得参与进来。我觉得这才是关键所在。也许如果你执意不考证，那就只能通过疯狂地参与开源项目来参与进来。你的简历上必须有一些东西能让我在看的时候眼前一亮。我为什么要聘用你而不是其他人？对吧？认证是其中的一部分。你知道吗？有时候你在合作伙伴公司工作，你必须有认证，这样合作伙伴才能维持他们在公司内部的认证。但实际上，至少有一家公司正在推出SRE认证。我想是DevOps Institute正在开发一个，或者至少是一个课程，但我除此之外没见过其他SRE认证。乔希，你见过吗？我知道有很多DevOps认证。

乔什·达夫尼：
不，我没有。是的。

Mike Pfeiffer：
是的。我觉得现在还处于非常早期的阶段。市面上已经有不少相关的书籍了，对吧？比如 O'Reilly 出版的那本，或者至少谷歌的人也写过几本关于 SRE 的书，对吧？

Josh Duffney：
是的。有一本练习册，有一本实施指南，然后还有一本真正的、最早出版的SRE书籍。

迈克·普费弗：
那么他们在那些书中探讨了什么呢？是不是就像他们在谷歌的工作框架一样？他们探索的就是这个吗？

乔什·达夫尼：
是的。第一部分讲的是理念，然后是实践，我还没有深入研究过练习册，但我认为它更多的是如何应用这些理念和原则。

迈克·普费弗：
克里斯·米勒，你好啊，老兄。很高兴见到你。我认识克里斯·米勒……我都记不清了，应该快20年了吧。很高兴见到你，克里斯。他问我：“你推荐哪个云认证？” 我觉得这里面有很多变数。这取决于你做什么工作，以及你在哪里工作。我知道克里斯，至少在我认识你、我们以前一起工作的时候，你是个微软的铁杆粉丝。所以，当我考虑这类问题时，这本身就是一个需要考虑的因素。我的经验是什么？我想往哪个方向发展？也许我想尝试一些不同的东西。所以，如果你目前在做Windows服务器管理，那么Azure对你来说就是一个自然而然、轻松的选择，就像乔什那样，考个简单的103认证就行了。这真是个很棒的开始。即使是入门级的 900 级课程（基础知识课程），也能让你学到很多关于 Azure 平台的知识。

Mike Pfeiffer：
但是，你知道，如果你在一家非微软公司工作，Azure 仍然很棒；但如果你是 Linux 用户，那么如果你想进入微软环境，可能还需要学习一些东西。所以，这真的取决于你目前的情况和未来的发展方向。不过，任何专家级的认证，比如 Jeff 在聊天或评论中提到的 Easy 400，也就是微软的 DevOps 专家认证，都有先决条件。这个认证很难考。你可以考，但你必须先通过 Easy 103 或 Easy 203，也就是管理员或开发人员认证。

迈克·普费弗：
亚马逊实际上有自己的DevOps认证。有趣的是，早期他们要求一些先决条件，但客户抱怨太多，很多人都想直接考DevOps认证，所以他们取消了先决条件。现在你可以直接考了。这其实取决于你是否想从事DevOps相关的工作。我认为如果我们想继续从事相关工作，最终都会被卷入其中，因为现在一切都是虚拟化的。当然，有些人仍然在做硬件方面的工作，我们也在做很多混合部署，但我们现在身处的世界里，任何事都可以自动化，一切都可以用软件来定义。所以，将软件实践应用到所有这些方面将非常重要。就我个人而言，我的愿景是加倍投入这个概念，无论我们称之为DevOps还是SRE。我认为，如果你看看就业市场，就会发现DevOps是目前最受关注的领域。乔希，你觉得克里斯刚才问的关于如何开始考取证书的问题怎么样？你觉得我的回答到位吗？

乔什·达夫尼：
我觉得是的。这真的取决于你的背景。我的意思是，我自己也经历过类似的阶段。我拥有传统的微软背景，Windows 服务器管理，而且是 PowerShell 的忠实粉丝。出于各种原因，我选择了 AWS 这条路，并且遇到了一些困难。回想起来，原因在于我失去了职业生涯中逐渐形成的社群。社群成员不多了……我的意思是，虽然还有一些，但我能得到一些指导。所以，我会认真思考自己的技能，看看哪条路更适合自己。我认为，AWS 的入门课程，比如 103 或解决方案架构师，算是入门级课程之一，可以先走这条路。但现在我对两者都有所了解，可以在不同的云平台上灵活切换……Azure 对我来说更容易上手，主要是因为我有一个非常棒的 PowerShell 模块，我可以利用自己的 PowerShell 经验来加速学习 Azure。

Mike Pfeiffer：
是的。我觉得只要掌握了其中一项就足够了。这就像学习一门编程语言，然后横向过渡到一门类似的语言。就像一旦你完成了学习第一门语言的艰苦工作，学习另一门语言就会容易得多。我认为所有这些模式才是最重要的。你部署到的平台或你使用的技术相对来说没那么重要。模式，也就是思维方式，才是关键。所以，源代码控制，甚至多了解一些应用程序和应用程序开发方面的知识，即使你不是开发人员，我认为也很重要。但是持续集成/持续交付（CI/CD）以及所有那些东西，流水线、安全、所有自动化相关的东西，对吧？这些都是你应该开始关注的重要模式和实践。这些都很棒。好了，这里有很多评论。超过100人在直播。我想这比……我想我们从来没有超过100人，所以……

乔什·达夫尼：
关于认证，我只想简单说几句。

迈克·普费弗：
是的。

Josh Duffney：
我通过 Easy 103 认证的最大好处是它增强了我对云的信心，现在我花了很多时间在我使用的开发环境中进行实验。我需要做很多开发工作，现在都在 Azure 上。所以，真正的好处在于它帮我克服了对云的不适应，现在我知道我可以把账单控制在一定范围内，而且我用的是自己的账户。它帮我克服了很多不适应的心理障碍，让我更习惯使用云服务。现在，我在这套技术栈上的实验将会呈爆炸式增长，而且我会更加自信，因为我花时间准备了考试，我理解自己在做什么，我不再害怕部署资源，也不再担心它会花费我 100 美元之类的。

Mike Pfeiffer：
是的，当然。我非常感谢Jeff Truman在评论区辛勤工作，帮助大家并积极参与讨论。谢谢你，Jeff，兄弟。真的非常感谢。Henry说：“嘿，Mike和Josh，看来除了Josh之前提到的那些书之外，好像没有其他地方可以学习SRE了。对吧？Josh，除了那些书之外，你还见过其他什么资源吗？”

Josh Duffney：
这本书有点隐蔽。它是我最喜欢的书，我想应该是《云与系统管理实践》（The Practice of Cloud and System Administration）。我总是念错他的姓氏，我都不想尝试了。但这本书实际上借鉴了很多SRE方面的知识。这两本书有很多重叠之处，所以通常都能找到一些相似之处，只是换了个名字而已。它指的不是具体的SRE实现，而是很多从SRE中借鉴来的模式和实践，这些模式和实践在DevOps相关的各种论坛中都有出现。比如，《DevOps的影响》（The Effect of DevOps）这本书。它主要用的是一些关键词，但其中很多实践都是相同的。

迈克·普费弗：
是啊，没错。彼得在评论里说，他越来越欣赏认证，因为它能展现求职者持续学习、提升技能的意愿。彼得，这正是我之前提到的，我很高兴你提到这一点，因为我经常招聘合同工，而且之前在AWS工作的时候，面试的人实在太多了，简直烦死了。招聘工作一直都在进行。对吧？所以从这个角度来看，你总是会考虑这个人更擅长什么，对吧？我认为，积极参与、承担工作之外的事情，即使很辛苦，需要额外付出，但这确实是你的责任。

迈克·普费弗：
你得像经营生意一样对待你的职业生涯，否则你的工作可能随时变动，你就丢了。如果你之前对职业生涯毫无规划，那你就完蛋了。对吧？彼得，我喜欢你刚才说的这一点。尼克，科利尔来了。怎么样，伙计？[听不清 00:26:18]，朋友。他说了什么？“嘿，很想听听你对跨团队自动化的看法。” 你见过很多客户各自为政地进行自动化，缺乏足够的跨团队自动化来使 DevOps 实践有效。是的。你知道，我认为我们目前合作的客户还处于非常早期的阶段，所以我先让乔希回答这个问题，然后我再补充。乔希，请讲。

Josh Duffney：
他一针见血地指出了我目前所在公司很多运维团队面临的最大争议点。那就是，我们如何协作？《团队拓扑》这本书提供了一个非常好的框架。它讨论了不同的沟通模式，以及协作方式，而这通常是我们的默认做法。我们被告知要过度沟通。沟通成本很高，所以书中还介绍了一种叫做“X即服务”的模式。因此，我们正在努力定义自动化流程与其他运维团队之间的接口，并尝试通过更好的接口来更好地使用这些资源，这些共享的自动化组件，而这个接口就是“X即服务”。

Josh Duffney：
所以，就我们而言，我们将 Ansible playbook 抽象成一个角色，这个角色可以被我们部署自动化的方式以及你们的方式所使用，但我们仍然使用相同的几个 RS 共享自动化，因此你必须更多地思考如何使我编写的内容更容易被其他团队理解和使用，你必须在这一点上转变为书中所说的赋能团队，了解他们的需求，并弄清楚如何在两者之间创建一个清晰的自动化接口，这个接口不需要协作，也不需要你解释脚本或你的 Wiki 页面。

Mike Pfeiffer：
是的。Nick也补充了一些内容，他说他在Gene Kim最近出版的《独角兽项目》一书中也谈到了这一点。Nick说，跨团队协作是这本书的重点。他和他的团队讨论过这个问题，这也是他提出这个话题的原因之一。我打算从更高的层面来谈谈。我认为这一切都归结于领导力和企业文化。公司的领导层必须通过企业文化和运作方式来促进跨团队协作。你不能只是在自己的团队内部倡导跨团队协作，这必须是自上而下的。我遇到过很多这样的情况：客户联系人，也就是领导或高管，他们只想购买DevOps或SRE，对吧？

Mike Pfeiffer：
所以，我还没遇到过任何把SRE（站点可靠性工程）纳入考虑范围的客户，但你应该明白我的意思。这就像你不能直接买现成的东西。无论你做什么，都会遇到很多困难，你必须努力争取。这对人们来说是一个很大的改变，说实话，大家都在努力适应。如果你不是Netflix、亚马逊或微软这样的公司，那就很难了。你知道吗？这需要付出很多努力。好了，我们再回答几个问题。非常感谢大家的参与。这太棒了。Josh，直播间里有116个人。

乔什·达夫尼：
那太酷了。

迈克·普费弗：
乔什，你这是要让互联网瘫痪啊，伙计。

乔什·达夫尼：
不太可能。

Mike Pfeiffer：
好吧，也许115个人让我们有点太兴奋了，不过，我们来看看。这里有几个问题。Mohammad说：“我觉得DevOps的角色更侧重于单个服务，而SRE则更广泛。”好的，明白了。SRE可以管理两个或多个服务，等等等等。还有什么问题吗？哦，对了，停下来，合作，倾听。太棒了。好极了。Josh，你觉得对于那些……或者说，无论是SRE还是DevOps的人来说，除了我们讨论过的内容之外，还有哪些资源可以供大家参考？

Josh Duffney：
我不知道。这确实是个好问题。如果你正在寻找认证考试，我可以把你之前学习的内容分享给你。我会把它放到你的电子报里，因为我从中受益匪浅。所以，一定要订阅Mike的电子报，里面有很多很棒的内容，包括各种工具链，一定要关注他提到的工具。比如几周前提到的Terraform。它包含很多社区内容，所以了解这些工具链或技术对相关岗位非常有帮助。如果你还没深入研究过……如果你想从事DevOps工作，但又不了解发布管道，我强烈建议你读一读Steve Murawski和Michael Green合著的《发布管道》（The Release Pipeline）白皮书。它能为你提供一个很好的框架和思维模型，帮助你理解持续集成（CI）和持续部署（CD）的各个组成部分。

Josh Duffney：
这两本书都是独立的，你可以在谷歌和亚马逊上找到，分别是持续集成和持续部署，你可以阅读一下。所以，如果你想进入DevOps领域，我建议你先熟悉一下软件工程，从这两本书的流水线角度来看。然后，基础设施即代码对于有运维背景的人来说是一个很好的基础，它能帮助你理解如何将自动化基础设施代码与软件工程结合起来。

Mike Pfeiffer：
酷。Gregor 说：“我当初提出 SRE 这个角色的时候，有人问我，为什么我们需要 SRE？” 他想知道，如果放在今天，你会如何回答这个问题？

Josh Duffney：
我们为什么需要SRE？我认为是为了提升应用程序的稳定性。但如果你想提升整个环境或所有系统的稳定性，那就容易出问题，因为首先必须针对特定应用程序进行优化。如果让我来推销SRE，我会这么说。

迈克·普费弗：
这个说得好。我喜欢。不过，我想补充一点，当你和别人交流时，我会问一些谷歌的人在我们之前提到的其他播客里也提到过的问题，比如当你和潜在的SRE或DevOps候选人交谈时，你问他们上次因为手动操作而感到沮丧，以至于决定将其自动化是什么时候，他们可能会说：“哦，我还没遇到过这种情况”，或者“我花了六个月才搞定”。他们可能并不适合这份工作，因为我们需要的是能够提前思考如何提高系统稳定性的人。这种“如何提前解决问题”的思维方式，才能让你更好地融入公司文化。对吧？

Mike Pfeiffer：
所以，我认为对于那些刚接触这方面的人来说，积极参与实践，无论是开源项目还是考取认证（这些都非常重要），都能让你显得对行业发展充满热情，对吧？他们不会只局限于自己的工作，而是会关注整个行业动态。这正是我希望加入团队的那种人。太棒了。非常感谢，Gregor。Josh，Kieffer 有一个非常重要的问题。他说：“如果你是一名初级云工程师或初级 DevOps 工程师，应该寻找什么样的职位？”

乔什·达夫尼：
一个值得寻找的职位？

迈克·普费弗：
是的。所以，他基本上是在说，如果他担任的是初级职位，他应该关注哪些方面才能晋升到下一个薪级？

Josh Duffney：
很好。我会继续寻找自动化的机会。就像你刚才说的，这确实给了我一个更好的答案，或者说一个更好的SRE问题的答案思路，那就是始终致力于减少人工操作。这是SRE的一个概念，你希望人工操作的比例……基本上就是运维工作和手动操作的比例……工程工作和手动操作的比例达到50/50，或者低于50%。因此，展现你减少人工操作的能力，将是你作为初级工程师所能获得的最佳成就证明。

乔什·达夫尼：
除此之外，我们之前讨论过的认证途径、如何入门以及如何提升自身技能，无论是你目前使用的工具链，都非常重要。但一定要把这些减少工作量的成就记录下来，因为当你申请晋升或换工作时，这些成就将成为你最有力的谈资。人们想听的就是你如何解决这个问题，如何彻底摆脱它，以及如何让它不再需要你点击那个按钮。即使你编写了一个脚本，你又做了什么让它自动帮你点击按钮呢？

迈克·普费弗：
是的，我在亚马逊工作的时候，沃纳·沃格尔是亚马逊的首席技术官，对吧？他现在还在亚马逊。我以前经常听他讲话，因为他经常周游世界做演讲。我想他现在仍然会这样做，但他八九年前的一句话让他名声大噪，那就是“万事皆有故障”。我记得AWS最早推出的云认证之一就是架构认证。它的核心在于消除单点故障等等。但我认为这件事的另一个重要方面是接受故障的存在。我们大多数人都太执着于追求完美了。完美是不可能实现的，也不现实，谷歌的人也表达过类似的观点。

迈克·普费弗：
戴夫·伦森，就是我之前在播客里提到的谷歌的那位。他是谷歌的高级工程经理之一，我听过他的一期节目。他当时在谈论谷歌的错误预算，对吧？他们的预算政策是，允许一定数量的故障，然后就认为这是正常的。对吧？他说：“如果因为没有出现故障而导致预算超支，那就不好。这其实是个问题，因为你过度设计了解决方案，投入了更多的资金、人力和资源。所以，接受并坦然面对故障，意识到‘我们必须围绕这个进行设计，并且知道它迟早会失败。我们该如何降低失败的风险？’这个概念很有意思。”

Mike Pfeiffer：
所以我认为这种心态对大家来说很重要，对吧？就是要坦然接受失败。我们来看看还有没有其他问题。Kevin Sapp 说：“公司内部的云 DevOps 和 SRE 团队之间通常会有矛盾吗？因为他们使用的工具类似。” 在我看来，公司内部肯定存在矛盾，百分之百。这在我看来是必然的。Josh，你怎么看？

乔什·达夫尼：
我觉得这完全取决于他们各自的位置。所以，我完全可以理解，如果你的DevOps团队在运维阵营，而SRE团队是从开发部门自然而然发展出来的，那么肯定会有冲突。在我目前的公司，我们有SRO（站点可靠性运维人员），而不是工程师，所以他们非常专注于……我们基本上把很多工作都划分成了功能孤岛。他们主要负责管理我们的监控平台，在这方面拥有丰富的经验。而我们这边则负责基础设施即代码。所以，当我们尝试使用相同的工具时，肯定会有一些冲突，因为这些接口并不清晰。所以，我完全理解这一点。我也完全理解。

迈克·普费弗：
是啊，我也经常看到这种情况，大家都很抗拒改变，不想做下一步该做的事，尤其是有其他团队威胁到你的时间的时候，对吧？他们想改变一切，如果真那样，我就得被迫去做这些事，所以我也一直在抗争。但话说回来，这必须自上而下地改变。这是文化问题。不过我整点有个电话要接，得赶紧准备一下，所以我想就此结束今天的采访。乔希，在结束之前，你还有什么想说的吗？

乔什·达夫尼：
嗯，我建议大家在申请职位之前，一定要仔细阅读职位描述，找出自身的不足之处。我过去六到八个月的时间里，就是四处了解各种信息，找出自己的知识盲点。我知道我担任DevOps工程师已经有一段时间了，但我的知识盲点确实存在，其中之一就是云计算。所以我很高兴自己做了这项探索。因此，认真评估自己的技能，并在面试中仔细阅读职位描述，就能清楚地看到自己在相关领域的不足，然后制定计划来弥补这些不足。

Mike Pfeiffer：
说得太好了，Josh。我喜欢这个观点，因为你可以从招聘信息中收集到大量信息。如果你足够细心，就能知道事情的发展方向。如果你愿意花时间阅读和研究，那就绝对没问题。Josh，说得真棒。感谢大家。非常感谢大家的参与。这次活动太棒了。现在有超过120人在线。有很多精彩的评论。感谢大家回答问题、互相帮助，特别是Jeff Truman。谢谢。也感谢大家抽出时间。Josh，非常感谢你。

乔什·达夫尼：
谢谢，[串音 00:38:41]。

迈克·普费弗：
我们很快就会安排另一场直播。

乔什·达夫尼：
好的，谢谢。

本期节目最初发布于 CloudSkills.io。如需查看原文，请参阅第 58 集：DevOps 与站点可靠性工程 (SRE) 的比较。