前言II

Andrew Clay Shafer

当我发现人们正在写第二本SRE书时，我伸出手问我是否可以写几句话。第一本SRE书中的原则与我一直想像的DevOps非常吻合，并且即使在Google之外并非100％适用时，这些实践也很有见地。首次阅读第一本SRE书中的原则之后— 拥抱风险(第3章), 服务级别目标(第4章), 和减少琐事(第5章)—我想在屋顶上大声喊叫。“拥抱风险”之所以引起共鸣，是因为我多次使用类似的语言来帮助传统组织推动变革。第6章一直是一个隐含的DevOps目标，既可以让人们有更多的时间进行更有创意的高阶工作，又可以使他们变得更加人性化。但是我真的爱上了“服务水平目标(SLO)”。我喜欢这种语言和流程在运维注意事项和提供新功能之间建立了无懈可击的契约。SRE，SWE(软件工程师)和企业都同意，该服务必须具有最高价值，并且SRE解决方案量化了目标，以驱动行动和优先事项。该解决方案-将服务级别作为目标，当您低于目标时，优先考虑可靠性而不是功能-消除了运维和开发人员之间的经典冲突。这是一个简单而优雅的框架，它可以通过解决问题来解决问题。自那以后，我将这三章作为作业分配给几乎我遇到的每个人。他们就是那么好。每个人都应该知道。告诉你所有的朋友。我已经告诉了我所有的人。

我职业生涯的最后十年一直专注于帮助人们使用更好的工具和流程来交付软件。有时人们会说我为发明DevOps做出了贡献，但我只是可以从许多不同的组织和项目中借鉴和窃取成功的模式。当人们说“ DevOps”的发明人可以是是任何人，但特别是我发明的，我感到很尴尬。除了好奇心外，我不认为自己是专家。我理想化的DevOps总是仿制我可以从朋友那里提取或推断出的所有信息，而我的朋友恰巧正在建立互联网。我有进行幕后访问的特权适用于部署和运维世界上最令人难以置信的基础架构和应用程序的代表示例的人员。DevOps象征着通过互联网快速交付高可用性软件所需的紧急和现有优化的方面。从物理介质上交付的软件到服务即交付的软件的转变迫使工具和流程不断发展。这种演变提高了运维对价值链的贡献。如果系统关闭，则该软件没有价值。好消息是，您不必等待下一个封装盒子就可以更换软件。对于某些人来说，这也是个坏消息。我只是有机会和观点阐明了新方法最成功的方式来吸引听众。

2008年，在像现在这样使用DevOps一词之前，我曾经历过互联网泡沫破裂，研究生院的发展，以及作为开发人员的几笔由风险投资资助的过山车之旅-每天都在Google中寻找答案。我全职从事Puppet的工作，而被自动化改造IT组织的潜力所吸引。Puppet推动我解决了运维领域的问题。当时，Google使用Puppet来管理其公司Linux和OS X工作站，其规模足以推动Puppet服务器的功能。我们与Google保持着良好的合作关系，但是Google出于政策原因将其内部运营的某些细节保密。我知道这一点是因为我天生好奇，并一直在寻求更多信息。我一直都知道Google必须拥有出色的内部工具和流程，但是这些工具和流程的含义并不总是很明显。最终，我接受了问有关Borg的深层问题可能意味着当前的对话进行得并不顺利的事实。我很想知道有关Google如何完成所有工作的信息，但是当时根本不允许这样做。2008年的意义还包括第一次O’Reilly Velocity会议以及我遇见Patrick Debois的那一年。“ DevOps”还不是一个方法论，但快了。时间到了。世界已经准备好了。DevOps象征着一种新的方式，一种更好的方式。如果那时Site Reliability Engineering发布了，那么我相信组成的社区将团结起来悬挂“消除琐事”的旗帜，而DevOps一词可能从未存在过。尽管事实并非如此，但我知道第一本SRE本书亲自提高了我对可能性的理解，并且我已经仅凭SRE原理就为许多其他人提供了帮助。

在DevOps运动的早期，我们有意识地避免编纂惯例，因为一切都在迅速发展，我们不想为DevOps的发展设定限制。另外，我们明确地不希望任何人“把控” DevOps。当我在2010年撰写有关DevOps的文章时，我提出了三个不同的观点。首先，开发人员和运维部门可以并且应该一起工作。其次，系统管理将越来越像软件开发。最后，与全球实践社区共享可以加速并增加我们的集体能力。大约在同一时间，我的朋友达蒙·爱德华(Damon Edward)和约翰·威利斯(John Willis)为文化，自动化，度量和共享创建了缩写CAMS。Jez Humble later通过添加精益持续改进，将该首字母缩写词扩展为CALMS。这些词在上下文中可能意味着什么，这本书应该是一本完整的书，但是我在这里提到它们是因为*Site Reliability Engineerin *明确引用了Culture，Automation，Metrics和Sharing以及有关Google不断改进之路的轶事。通过出版第一本SRE书籍，Google与全球社区分享了他们的原则和实践。现在，我将DevOps定义为“优化人员绩效以及使用软件以及人员来实践运维软件”。我不想在任何人的嘴上说些什么，但这似乎也是描述SRE的好方法。

最终，当我看到DevOps以及Google的SRE时，从理论上和实践上我都知道它们是最先进的实现之一。良好的IT运维始终取决于良好的工程设计，而使用软件解决运维问题始终是DevOps的核心。站点可靠性工程使工程方面更加明确。当我听到有人说“ SRE vs DevOps”时，我感到非常畏缩。对我来说，它们在时间和空间上是密不可分的，就像标签所描述的那样，它们通过软件为现代基础设施提供了社会技术系统。我认为DevOps是一组宽松的通用原则，而SRE是高级的显式实现。一个类似的比喻是敏捷与极限编程(XP)之间的关系。的确，XP是敏捷的，可以说是敏捷中最好的，但是并非所有组织都有能力或愿意采用XP。

有人说“软件正在吞噬世界”，我知道为什么会这样，但是仅“软件”并不是正确的框架。如果没有与高速网络连接的计算硬件的普遍存在，我们认为“软件”的大部分功能将无法实现。这是不可否认的真理。我认为在这次有关技术的对话中，许多人未察觉到的是人类。技术的存在是由于人类的存在，并希望人类能够“为之”，但是，如果您更深入地了解，您还会意识到我们所依赖的软件(并且可能认为是理所当然的)在很大程度上取决于人类。我们依靠软件，但是软件也依靠我们。这是一个不完美的硬件的互连系统，软件和人类依靠自己来构建未来。可靠性正在蚕食世界。但是，可靠性不仅与技术有关，而且与人有关。人与技术形成一个单一的技术社会系统。让Google与其他行业共享SRE的一个不错的特色是，关于大规模运行所有流程工作的任何借口都是无效的。Google为可靠性和规模设定了最高标准。关于为什么有人不能直接采用Google SRE做法可能存在有效的论点，但指导原则仍应适用。当我着眼于构建未来的可能性以及利用软件转变人类体验的雄心壮志时，我看到了许多雄心勃勃的项目，这些项目实际上将所有内容都连接到了互联网。我的数学认为，成功的项目将发现自己正在摄取难以置信的数据并将其编入索引。很少(如果有的话)会超过Google的规模，但有些会与Google创办SRE时的规模相同，并且会需要解决同样的可靠性问题。我认为，在这些情况下，采用看起来像SRE的工具和过程不是可选的，而是必然的-尽管由于SRE的原理和实践适用于各种规模，所以不必等待那场危机。

SRE通常是按照Google的运作方式来构架的，但这错过了更大的前景：SRE实际上支持软件工程，但也可以改变体系结构，安全性，治理和合规性。当我们利用SRE专注于提供服务平台时，所有其他这些注意事项都将得到一流的重视，但是这种情况发生的地点和方式可能完全不同。就像SRE(并希望DevOps)将越来越多的负担转移到软件工程上一样，现代体系结构和安全性实践也从幻灯片，检查表开始发展，并希望通过运行代码实现正确的行为。在不重新审视其他方面的情况下采用SRE原则和实践的组织将失去巨大的改进机会，并且如果没有将相关责任人转化为盟友，他们也可能会遇到内部抵制。

我总是很喜欢学习。我直接阅读了第一本SRE书中的每个字。我喜欢这种语言。我喜欢轶事。我喜欢更多地了解Google的看法。但是对我来说，问题始终是：“我将改变哪种行为？”

学习不是在收集信息。学习正在改变行为。在某些学科中，这很容易确定甚至量化。当您可以播放歌曲时，您已经学会了播放新歌曲。就好比国际象棋比赛中与实力较强的玩家对抗会更好。像DevOps一样，站点可靠性工程不仅应该更改标题，还应该进行明确的行为更改，重点放在结果和明显的可靠性上。《网站可靠性工作手册》承诺从Google列举的Google原则和实践向更多上下文行动和行为迈进。网站的可靠性适合所有人，但可靠性并非来自于读书。这是拥抱风险并消除琐事的方法。