谷歌 SRE 圣经被迫重写：AI 时代，硬技能在塌陷，第一性原理在升值

2016 年，一本蓝色封面的书砸进了整个技术行业，把“运维”这两个字从地下室拽进了工程学科的殿堂。

在它之前，运维在大多数组织里是一个成本中心，是一群被凌晨告警叫醒的人，是开发团队眼中“拖慢发布速度的那帮人”，是一门靠师傅带徒弟、靠口口相传、靠个人英雄主义在机房里临场发挥的手艺。系统出了故障，运维的默认答案就是：“加人、加班、加流程”。

第一版《SRE》做的第一件事，就是用一套冷峻的工程语言，正式宣告了传统运维时代的终结。 它向全行业抛出了一个不可辩驳的等式：SRE 等于用软件工程师的标准来设计运维团队。

《SRE》这本书将日常运维的时间被硬性封顶在 50%，剩下的必须投入工程工作。这揭示了运维（Ops）的本质是一个软件工程问题，不该靠加人来扛故障，而应该靠写代码来消灭故障。从这本书出版那天起，SRE 不再只是一个谷歌内部的岗位名称，它成了一个新学科的名字，催生了全球范围内这一全新岗位的普及，重塑了无数科技公司的组织架构和招聘标准。

这本书不仅让 SRE 走向更广泛的技术行业，更给整个行业发放了一套通用的“工程语言”和黄金法则。在该书出版之前，

第一版《SRE》给这套哲学浇了钢筋混凝土。微软官方文档后来用一句话精准总结了这种关系：“SRE 类实现

例如，错误预算彻底改变了“追求 100% 绝对稳定”的错误执念，用数学量化了“系统稳定性”与“业务迭代速度”之间的博弈，解决了开发与运维之间长达数十年的矛盾。在任何一家公司的可靠性评审会上听到的“这个季度的错误预算还剩多少”，这句话的源头就藏在这本书里。它不仅仅是被阅读，还被翻译、被拆解、被贩卖、被模仿。

出版几个月后，该书其中的一位作者 Niall 在都柏林办公室被一家咨询公司的六个人堵住，他们拿着文件夹，花了一个小时逐条盘问书中细节，准备包装成咨询服务卖给客户。Forrester 甚至发文《SRE 一书中可以立即应用到你组织的 19 个要点》。一本谷歌内部手册，在不到一年里变成了全球咨询业的商品目录。这就是“黄金法则”的实际含义：它成了别人拿来卖钱、拿来照抄、拿来当标准的东西。

此外，它更是直接推动了这本书出版的时间点，恰好撞上了整个行业的基础设施大迁移。企业数字业务规模急剧扩张，IT 从“地下室里的事情”变成业务的关键组成部分，系统停机开始实实在在地烧钱。

可以说，第一版不仅是一本书，它是现代互联网运维的“开山鼻祖”和“范式转移之作”。

但十年后，这本书被它的作者们亲手推翻了。

不是修订，而是重写。今年 10 月，谷歌发布了该书的第二版。作者团队明确表示，第一版已经过时了。过时的原因远比“技术栈更新”更麻烦：第一版默认的那个世界——工程师亲手触碰代码、亲手调试基础设施、在故障现场用肌肉记忆做判断的世界——正在被两层力量同时侵蚀。

第一层是基础设施与平台工程的全面重构。第一版描述的是“每个团队自己搭建、运行基础设施”的时代。十年后，大量运维工作被下沉到平台层，内部开发者平台接管了 provisioning、部署、可观测性配置。静态仪表盘和手动查日志被

第二层是 AI 的双向重塑。谷歌官方把 SRE 与 AI 的关系拆成两个方向：

“为 AI 做 SRE”：AI 系统本身正在给可靠性工程带来新的挑战，大规模

“用 AI 做 SRE”：AI 也开始参与生产系统的故障诊断和处理，而且已经不再停留于概念验证阶段。Google SRE 团队已经在用

这也是第二版重写的理由。SRE 赖以生存的两个底层假设，同时崩塌了。

第一版教的那些黄金法则：SLO、错误预算、toil 消灭，全部建立在“系统行为是可被度量、可被预测、被人工工程化控制的”这一前提上。但现在，对传统系统，SRE 不再亲手操作；对 AI 系统，代码根本不按确定性规则运行。AI 更像一个黑箱里的同事，有时候能力超神，有时候胡说八道，而你必须在生产环境中和它共事，还要保证用户不遭殃。Niall 在播客里的那句“

Google 在第二版里反复强调：技术变了，但文化没变，无责复盘、心理安全感依然是根基。但真正致命的问题在于：当你的日常变成审核 AI 的提案，当 30% 的故障判断被机器接管，你对系统的“体感”从哪里来？ 第一版 SRE 文化的绝对核心，是“你亲手碰过、被凌晨三点的告警烧过，所以你真懂系统”。错误预算之所以有分量，是因为按下“停止发布”的那个人，曾经在故障中感受过切肤之痛。如今，这个根基正在被抽走。

播客里 Christoph 的发言值得留意。他说第一版忠实地体现了副标题：“谷歌如何运行生产系统”，但它没有说清楚，这只是一种做法。第二版引入了 Spotify、Microsoft、Etsy、Disney、Waymo 的视角，展示它们如何采用 SRE、哪些做法有效、哪些没有。这个转向本身就是一个信号：SRE 正在从“谷歌怎么做”变成“你在你的环境里，在 AI 介入之后，还能抓住什么不变的东西”。

如果你在运维、平台工程、或者任何需要对生产系统可靠性负责的岗位上，不妨听听这期播客对话。这段对话并非给出了 AI 时代的答案，作者们自己也在焦虑十年后这本书会不会显得荒唐。第二版书诚实地呈现了一个正在发生的断裂：一本终结了传统运维时代、定义了行业语言、托住了云原生爆发的书，被它的作者们亲手宣告需要重写，而重写它的理由，恰恰是他们还无法完全看清的东西。

Betsy 在播客里说了，想成为 SRE 的人，她的建议仍然是“从第一版开始”。但如果你想知道 DevOps 和云原生走到 2026 年之后，当 AI 开始接管操作、当平台工程把 SRE 从机房里拽出来，那套曾经让运维变成一门工程学科的东西还剩下什么？第二版的书籍和这期对话，是目前的起点。

以下是访谈内容，InfoQ 在不改变原意的前提下进行了编辑整理。

David Blank-Edelman：大家好，欢迎收听 Prodcast。我是今天的客座主持人 David Blank-Edelman。今天，我们要聊一部在我们这个领域具有开创性意义的著作。虽然参加这次讨论的人可能不太愿意承认这一点，但《SRE》这本书确实帮助推动了整个领域的发展，也成功地让更多人认识了 SRE。

而且，我们还有一个令人兴奋的消息：今天我们还会重点讨论即将问世的第二版。我想先从这本书的起点聊起。Niall，当初怎么会想到要写这样一本书？等聊到第二版时，我还想再问问你这个问题，听听你当时有哪些不同的考虑。

Niall Richard Murphy：第一版的想法在正式立项前几年就已出现。随着 Google 内部 SRE 实践不断发展，工程师们意识到，这套知识和工作方法已经复杂到值得系统整理成书。经过约一年半到两年的编写，第一版于 2016 年出版。

David Blank-Edelman：Christof，你认为为什么第一版会受到如此广泛的欢迎？在你看来，这本书究竟提供了什么价值，能够让这么多人从中受益？

Christof Leng：我认为，这与当时的时代背景有很大关系。那段时间，很多公司的数字化业务都在快速扩张。IT 系统不再只是发生在地下机房里的事情，而是逐渐成为企业运营的关键组成部分。人们开始意识到，一旦系统宕机，就会真正影响业务。

于是，大家需要弄清楚几个问题：面对规模越来越大的系统，我们该怎么办？面对各种系统相互交互带来的复杂性，我们该怎么办？又该如何以可持续的方式管理这些系统？很多公司开始尝试采用书中的实践方法，而结果表明，它确实在很多公司中发挥了作用。

David Blank-Edelman：我想，读者从这本书中看到的应该不只是 Google 的经验，也看到了自己的处境。这其实是一个很值得探讨的问题：这本书解释了 Google 是如何取得成功的，但其中的方法似乎也适用于其他公司。

你们当初写这本书时，是否已经意识到，Google 的经验也能在其他组织中发挥作用？那么，其他公司是如何借鉴这些经验的？你们当时观察到的情况是什么？

Christof Leng：我认为，第一版确实有一些内容非常具有 Google 的特点。在我看来，真正成功引入 SRE 的公司，并没有完全照搬 Google 的做法，而是根据自身情况进行了调整。每个组织都有不同的文化和需求，不可能与 Google 完全一样，这其实是件好事。我认为，书中的许多原则具有普遍适用性，其他公司完全可以结合自身的实际情况加以应用。

David Blank-Edelman：David，你先来说说？

David Huska：我在 Google Cloud SRE 团队工作时，主要负责帮助一些大型客户将系统迁移到 Google Cloud（GCP），第一版 SRE 书也恰好在那时出版。当时，云计算已经出现了一段时间，而且正在越来越普及。在与客户合作的过程中，我们逐渐意识到一个问题：这些企业往往拥有规模庞大、运行多年的老旧系统，而系统原有的可靠性问题，并不会因为迁移到云上就自动消失。

第一版出版的时候，SRE 的理念和实践开始受到广泛关注。很多公司希望效仿 Google，认为既然 Google 是这么做的，自己也应该照着做。但正如 Christof 刚才提到的，由于种种原因，直接照搬往往行不通。接下来的几年，我们与这些大型企业开展了大量合作，也积累了不少经验。这些合作有时像技术咨询，有时又像是在为客户提供情绪疏导，因为我们经常需要回答这样一个问题：“为什么这套方法在我们这里行不通？”

与此同时，这些经历也不断印证了 SRE 的许多基本判断。有些问题几乎就像物理定律一样，无论在哪家公司，都会遇到类似的挑战。客户也非常希望了解 Google 是如何应对这些挑战的。毕竟，Google 一直被视为可靠性工程领域的典范，他们希望借鉴这些经验。其中不少方法确实有效，而且直到今天仍然适用。

不过，走进其他企业，观察这些方法在不同环境下的应用效果，也让我们有了许多新的认识。这些企业拥有非常优秀的工程师，他们也十分了解自己的业务，但 Google 的方法并不总能与他们的实际情况完全匹配。客户的反馈促使我们重新审视这些实践：哪些经验具有普遍性，哪些做法需要根据具体环境作出调整？这些问题也成为我们后来总结经验、完善方法时的重要方向。

Niall Richard Murphy：我简单补充一下。第一版出版几个月后的一次经历，让我第一次意识到，这本书或许也适用于 Google 之外的企业。

当时，我正在 Google 都柏林办公室工作，突然接到前台通知，说有人来找我。我有些意外，因为事先并没有约人。下楼后才发现，来访的是一家咨询公司的六名员工。我把他们带进会议室，几个人随即拿出文件夹，里面准备了大量列有问题要点的资料。接下来一个小时，他们围绕书中的内容向我提出了许多非常细致的问题。直到谈话快结束时，我才恍然大悟，原来他们是想深入了解书中的各种细节，再把这些经验作为咨询服务提供给自己的客户。

当然，十年后的我已经不像当时那么天真了。但那次经历确实让我意识到，这些咨询公司可能会把 SRE 的方法带给更多企业，涉及不同的行业，以及对技术有着不同需求的组织。又过了一段时间，我逐渐意识到，SRE 正在走向主流。

当然，Google 与其他企业之间存在许多差异，比如组织规模、可用资源，包括资金和 CPU 等计算资源。这些差异很容易让人觉得，Google 的经验未必适用于其他公司。但咨询公司却认为，书中有大量方法可以直接应用到其他组织。

我记得 Forrester 曾发表过一篇文章，标题大致是《SRE 一书中可以立即应用于企业的 19 条经验》。看到这样的文章，我更加确信，这本书对 Google 之外的企业同样具有价值。当然，初创公司可能是一种比较特殊的组织类型，我能够理解这种看法，甚至在一定程度上也认同。但对于大多数企业及其日常工作来说，书中确实有许多值得借鉴的方法。

事实上，这也是我当初想写第一版的原因之一。在此之前，我长期处于开发与运维严格分离的传统工作模式中。整个职业生涯大约有 75% 的时间从事运维工作，另外 25% 从事开发工作。但我逐渐意识到，开发和运维并不一定要这样分开。

而 Google 特别擅长的一件事，就是从

David Blank-Edelman：David，我想接着你刚才提到的内容再问一个问题，正好也聊聊即将出版的第二版。经过这么多年的实践和反思，现在回头看第一版，你们觉得有哪些地方当初理解得不够准确，或者处理得不够完善？又有哪些内容，是你们希望在第二版中补充或修正的？

毕竟，人都会犯错，至少我自己是这样。而 SRE 一直强调从失败中学习，所以我很好奇，你们从第一版中吸取了哪些经验？如果你们能够挥动魔杖回到过去，重新审视第一版，会有哪些地方让你们觉得：“第二版必须补上这个缺口”，或者“这里需要纠正一下之前的说法”？

David Huska：我认为，第一版很多观点在当时是成立的，也符合我们那时的写作定位，也就是介绍 Google 如何运行生产系统。只是经过这些年的发展，许多技术和实践已经发生变化，书中的部分内容也逐渐过时了。

十年前，我们强调的是 SRE 文化，以及开发团队自行构建和运行基础设施的工作模式。如今，很多原本由开发人员承担的基础设施工作，已经下沉到平台层，由统一的平台来提供支持。这并不意味着当年的做法是错误的。那确实是 Google 当时运行系统的方式，而且取得了很好的效果。只是后来，我们发现许多公司读了第一版之后，也开始模仿 Google 的做法。

所以，也许我可以换个角度回答你的问题：第一版推动了哪些实践，而现在回头看，我们希望 Google 之外的公司当初能够采用不同的方法？这样的例子确实有一些。比如，十年前的环境相对简单，我们拥有充足的闲置计算资源，可以采用 N+1 冗余配置，在发生故障时利用预留的计算能力完成故障切换。当时，我们使用的虚拟机环境也相对统一，并在此基础上推动了

平均故障恢复时间（Mean Time to Resolution，

不过，在我看来，第二版最重要的进步，是我们认识到 Google 并不是唯一能够成功实践 SRE 的公司。其他组织同样积累了丰富的经验，也探索出了许多行之有效的解决方案。因此，我们努力将这些经验纳入第二版，不仅邀请其他公司的工程师亲自介绍他们的实践，也分享 Google 如何借鉴这些经验，以及我们自身的工作方式发生了哪些变化。同时，第二版也开始面向第一版未能充分覆盖的其他读者群体。

Betsy Beyer：我们后来意识到，第一版遗漏了一项非常重要的内容。当时，我们已经习惯了 Google 的企业文化，默认人员管理、团队协作以及

David Blank-Edelman：根据我的经验，出版第二版的时候，通常不可能无限增加篇幅，因此，要加入新内容，就必须删减一部分旧内容。刚才 David 提到了平台工程，Betsy 也谈到了组织和文化方面的内容。那么，为了给这些新内容腾出空间，第二版具体删掉了哪些东西？

David Huska：第一版包含的大量技术细节，比如负载均衡、分布式 Cron 等，这些内容在当时都很有价值。但如今，其中大部分技术已经商品化，即使是尚未商品化的部分，借助 LLM 等代码生成工具，实现起来也比过去容易得多，成本也大幅降低。因此，我们曾讨论过是否还有必要保留这些内容。最终，我们决定把更多篇幅留给第一版中相对欠缺的组织文化内容，比如团队成员如何协作、人与人之间如何互动，以及如何证明自己工作的价值。

借用作家 David Foster Wallace 的一个比喻，这些东西就像我们生活其中的水。因为早已习以为常，我们反而很难意识到它们的存在，也就没有在第一版中充分介绍。当然，有些内容我们当时已经意识到了，甚至写成了章节，但最终受篇幅等因素限制，还是不得不删去。所以，第二版减少了大量具体的技术细节，转而增加了更多关于组织、人员协作和文化的讨论。

Christof Leng：第一版很好地体现了它的副标题——“Google 如何运行生产系统”，但没有明确告诉读者，这只是实践 SRE 的一种方式，并不是唯一的方法。

因此，第二版引入了更多来自其他公司的实践经验，包括 Spotify、Microsoft、Etsy、Disney 和 Waymo。这些公司都有各自的 SRE 实践方法和发展历程，可以分享它们是如何引入 SRE 的，哪些做法取得了成功，又遇到了哪些问题。我认为，这些经验对准备引入 SRE 的企业很有参考价值。毕竟，如果只看 Google 如今成熟的实践体系，而不了解它是如何一步步发展起来的，就很难判断哪些方法适合自己的组织。

Betsy Beyer：我想特别强调第二版的一个重要特点，这与我们刚才讨论的保留、删除和更新哪些内容直接相关。但实际上，第二版《SRE》是完全重新编写的，并不是在第一版的基础上简单修改和增删。

举个例子，第一版有一章专门讨论“简单性”（Simplicity）。简单性依然是 SRE 的一项基本原则，我们现在仍然认同它。而且，第一版关于简单性的那一章直到今天仍然非常有价值。

因此，我们实际上把第二版看成第一版的补充，而不是替代品。事实上，我们还在第二版的前言中，为不同类型的读者提供了阅读建议——当然，前提是有人愿意认真读前言。其中，对于那些希望成为 SRE 工程师的读者，我们的建议很明确：先从第一版读起。

David Blank-Edelman：我还想知道，第二版有没有提出一些与第一版截然不同，甚至有些“离经叛道”的观点？比如，你们会不会说：“

David Huska：在讨论 SLO 和错误预算时，确实经常会涉及教条和异端之争。这两个概念可能是第一版中影响最广泛的内容，也是我们与云客户合作时最常被问到的话题。

在 Google，我们把 SLO 和错误预算作为一种协调决策的机制。当系统运行出现问题时，它们可以帮助团队判断何时应该暂停发布、集中精力改善可靠性，以及何时可以继续推出新功能。如果所有人事先就这套机制达成共识，那么即使出现故障，团队也能按照既定方案作出决策。这套方法至今仍然具有指导意义。

但在实际应用中，我们发现，一些企业认为这套机制限制了他们自主权衡风险的空间。毕竟，每个组织的业务情况不同，需要自行决定能够承担多大的风险。因此，他们更倾向于借鉴其中的原则，而不是完全照搬 Google 的做法。

后来，我们发现，不只是 GCP 客户，许多读者也逐渐形成了类似的认识：只要组织内部的信息足够透明，能够充分理解自身的业务风险，就可以根据实际情况决定如何使用 SLO 和错误预算，而不必严格遵循某一套固定规则。

不过，第一版中有一项核心原则始终没有改变，那就是 SLO 的价值在于帮助团队了解用户的真实体验，以及用户真正关心什么。Niall 在第二版中很好地强调了这一点。因为在编写第二版时，大家对 SLO 确实提出了各种不同的意见，最后由 Niall 负责把这些观点整合成一套连贯的表述，他完成得非常出色。

正如 Betsy 刚才提到的，有些基本原则不会改变。至于如何根据 SLO 制定错误预算、何时暂停发布等具体做法，则存在不同的观点和取舍，也更容易引发所谓的教条与异端之争。我们自己的看法也在不断调整，而这些变化，很大程度上来自外界的反馈，以及其他组织在实践中积累的经验。

Niall Richard Murphy：我认为，第二版中关于 SLO 的章节有一个非常独特的地方：它专门包含了一个讨论“SLO 的弱点”的小节。更广泛地说，第二版在很多章节中都更加充分地考虑了各种不同的权衡。因此，我们在描述如何采用某种方法时，也提供了更加细致、更有层次的讨论。

当然，在这本书的讨论中，我们还必须谈谈大家最喜欢的两个元音字母。第二版有一章讨论 AI for SRE，还有一章讨论 SRE for AI。这是两个截然不同的主题。我就先说到这里。

David Blank-Edelman：太好了。我们肯定会在最后继续讨论这个话题。不过，在那之前，我想先来一轮快速问答。

David Blank-Edelman：从 Christof 开始吧。我想知道，在这本书中，除了你自己写的章节以外，你最喜欢、最推荐读者阅读的是哪一章？最好还能用一两句话解释一下值得关注的原因。

Christof Leng：对我个人来说，应该是关于 SRE 文化背景的那一章。因为它提供了很多背景知识，帮助读者理解在 SRE 领域怎样才能取得成功，以及为什么有时候你甚至还没有开始处理任何技术问题，就已经可能遭遇彻底的失败。

我认为，这一点经常被忽视。如果你完全忽略文化层面的问题，就很可能遇到大量麻烦，甚至根本不明白问题为什么会出现。所以，我认为我们有必要深入讨论这个主题，并且把它放在全书非常靠前的位置。

David Blank-Edelman：非常好。Betsy，轮到你了。这个问题对你来说可能有点难，因为你几乎参与了所有章节。即使选不出最喜欢的一章，至少能推荐一章吧？

Betsy Beyer：当然可以。有一章我个人非常喜欢，就是“自动化与工具”（Automation and Tooling）。这一章最大的优点，是提供了一套循序渐进的实践方法，从最基础的步骤开始，逐步深入。无论读者目前处于什么阶段，都能找到适合自己的起点，这一点很有价值。

此外，这一章还用了很长的篇幅讨论琐务（Toil）。这是 SRE 工作中一个非常重要的问题，书中不仅深入分析了琐务，还讨论了其中许多值得注意的细节，内容相当全面。

David Blank-Edelman：非常好。David，你会怎么选？

David Huska：我想我刚才已经回答过这个问题了。如果要推荐一章自己没有参与编写的内容，我会选“平台工程”（Platform Engineering）。这一章很好地展现了 SRE 从第一版到第二版的演变：我们当初提出了哪些建议，如今 Google 内部又是如何实践的，以及我们现在会向其他企业提出什么建议。它也很好地将软件工程与站点可靠性工程结合起来，体现了我们一直以来的初衷。

更重要的是，这一章说明，SRE 的基本原则并没有改变，改变的是我们解决问题的方式。这也是贯穿第二版的一个主题。随着技术工具、系统规模和商业环境不断变化，我们需要调整这些原则在实际工作中的应用方式，而不是抛弃原则本身。

如果可以再推荐一章，我还想介绍自己参与编写的“有价值的可靠性”（Valuable Reliability）。这一章体现了第二版的一种新思路：我们需要认识到，SRE 归根结底是一项业务职能，而不只是一门工程技术。SRE 的重要价值之一，是帮助企业在业务规模扩大的同时，避免运营成本以相同的比例增长，使企业能够持续经营和发展。但我们很容易只关注其中的技术问题，而忽略它对业务的实际价值。

“有价值的可靠性”这一章讨论的正是这个问题。如果企业只是因为 SRE 流行而投入资源，却始终把它视为运营成本，而不是一项竞争优势，那么到了下一轮预算审议，或者需要重新评估投入的时候，SRE 项目就可能面临被削减的风险。相反，如果组织内部能够充分理解 SRE 的价值，明确为什么需要投入可靠性建设，就能在此基础上形成共识。这也是我非常喜欢这一章的原因，它体现了第二版新增的一个重要视角。

David Blank-Edelman：最后，我们来聊聊那些即将统治人类的机器人吧。

关于 AI，我有很多问题想问。其中最让我好奇的是，你们是如何在这本书中讨论 AI 的？以我的经验，写 AI 就像用会逐渐消失的墨水写字，刚写下的内容可能转眼就已经过时，因为技术发展的速度实在太快了。

如今，几乎每位 SRE 都在思考 AI 将带来哪些变化。但对于一本纸质书来说，你们究竟该写些什么，才能让这些内容在出版后仍然具有参考价值，而不至于读者刚拿到书，里面的观点就已经过时？你们是如何解决这个问题的？

Betsy Beyer：我认为，我们通过“Tipping Point”（转折点）这一章，回应了 AI 将会如何影响 SRE 这个职业这个问题。围绕这个问题，目前存在大量焦虑和不确定性。我不能说我们已经明确回答了 AI 究竟会给 SRE 带来什么变化，但我认为，书中还是提出了一些很有参考价值的预测。

David Huska：有些事情我们还是能够确定的。作为 SRE，我们已经有多年运行机器学习系统的经验，现在也开始负责 AI 系统的运行。因此，对于其中一些问题，我们可以从基本原则出发进行讨论。这至少为我们提供了一个相对可靠的基础。

不过，你刚才提到的，确实是编写这本书时最让我头疼的问题。第一版已经出版了十年，而 AI 技术几乎每周都在变化。我们究竟该写些什么，才能保证十年后再回头看时，这些内容不会显得荒谬？为此，我们反复讨论了很久。

最终，我们还是决定回到第一性原理，重点讨论那些已经得到验证、能够确定成立的原则，以及为什么即使在 AI 时代，这些原则仍然适用。

我同意 Betsy 的看法，考虑到 AI 技术变化如此之快，我们最终还是很好地完成了这项工作。至于具体采用了什么方法，就先留一点悬念，等大家读了这本书就知道了。总的来说，这确实是一个很大的挑战，但我对最终呈现的内容非常满意。

Niall Richard Murphy：我想先提醒大家注意一个问题。相比今天参加讨论的其他一些人，我在日常工作中可能接触了更多 AI 领域的最新进展。比如，

为此，我们团队反复讨论和修改，仔细斟酌究竟应该从哪些角度来写。最终，我们延续了第一版的思路，尽量围绕那些具有长期价值的基本原则展开，而不是介绍某项具体技术或某个特定版本，比如 HTML5 入门教程之类的内容。毕竟，后者很容易随着技术发展而过时。

但要准确评价 AI 在 SRE、软件工程等领域究竟能发挥多大作用，还有一个难题。除了技术迭代太快，更重要的是大语言模型本身存在一些固有局限。它们可能产生幻觉、编造信息，也容易受到干扰而偏离任务。从某些方面看，AI 的认知能力甚至超过了人类，但在另一些方面，它又可能是一个远远无法满足要求的协作伙伴。

如何应对这种能力上的不稳定性，是我们必须解决的问题，尤其是在生产环境中。因为一项任务的准确率是 99.9% 还是 99.5%，看似只有很小的差距，却可能产生截然不同的结果。我们也尝试在书中提出一些应对这些问题的指导原则。

最后，我想作一个预测：今年结束之前，我认为全球每一位 SRE 都需要对 AI 建立起足够深入、基于实际了解的认识，即使他们还没有亲自使用 AI 工具。到了这个十年结束之前，我们则必须学会如何有效控制这些系统。

Christof Leng：AI 正在非常迅速地改变我们的行业。但科技行业一直都在发生变化，而这正是它如此令人兴奋的原因。所以，对于科技领域的任何一个主题来说，其实都不存在一个绝对合适的出书时间。但这并不意味着我们就不应该讨论这些事情。

我认为，真正重要的是写下一本书，与阅读这本书的人交流，然后大家一起学习。我们在书中重点做的一件事，就是努力找到那些我们已经知道是正确的核心原则。现在，每个人都在尝试弄清楚，应该如何在生产环境中使用 AI。没有人知道，两年、五年或者十年之后，这件事究竟会变成什么样。但这本书有一部分内容，专门讨论如何安全地在生产环境中采用 AI。也就是如何一步一步地引入 AI，在这个过程中逐渐建立信心，同时尽可能降低风险。我认为，这是一种非常符合 SRE 思维方式的做法。

David Blank-Edelman：我希望，在我们的第二次讨论中，还能继续深入这些话题。我个人特别感兴趣的一个问题是：过去这么多年，我一直在运维领域工作，我们基本上都是在尝试利用具有确定性的系统，获得确定性的结果。但现在，我们突然拥有了一种本身并不倾向于产生确定性结果的工具。所以，我非常期待我们能够继续讨论这个问题。

好了，今天的讨论就先到这里。感谢各位参加这场分为上下两部分的讨论中的第一部分。在接下来的节目中，有些嘉宾会再次回来，也会有新的嘉宾加入。非常感谢大家今天与我们分享有关这本即将出版的第二版《SRE》的讨论。

播客链接：

https://t.co/nkzVrTfQG0

声明：本文为 InfoQ 编译，不代表平台观点，也不构成投资建议，未经许可禁止转载。