最近读完了《SRE：Google运维解密》这本书，这是一本关于运维的经典之作，由Google的SRE团队撰写，详细介绍了Google是如何做运维的，如何保证大规模系统的高可用和高性能。

这本书的英文原名是《Site Reliability Engineering》，简称SRE，中文翻译为《SRE：Google运维解密》，由O'Reilly出版，作者是Google的多位SRE工程师，主编是Ben Treynor Sloss、Niall Murphy、David Beyer、Chris Jones和Jennifer Petoff。这本书在运维领域非常有名，被很多人奉为运维的圣经，也是SRE这个岗位和理念的开山之作。

读完之后，收获很大，颠覆了我之前对运维的很多认知，也让我对运维这个岗位有了全新的认识。今天来聊聊这本书讲了什么，以及我最大的几个收获，关于SRE是什么，关于运维的理念，关于如何保证系统的高可用，希望能给做运维或者对运维感兴趣的朋友一些参考。

一、先说说SRE是什么

在聊书的内容之前，先说说SRE是什么，给不太了解的朋友一个背景。

SRE，全称是Site Reliability Engineering，翻译为站点可靠性工程，或者网站可靠性工程，是Google首创的一个岗位和理念。简单来说，SRE就是用软件工程的方法来做运维，把运维的问题，当成软件问题来解决，用代码和自动化，来保证系统的可靠性。

传统的运维，更多的是手工操作，运维工程师手动部署、手动扩容、手动排障，重复性的工作很多，效率低，也容易出错。而SRE的理念是，运维不应该是手工的、重复的，而应该是自动化的、工程化的，能用代码解决的问题，就不要用手工操作，能自动化的事情，就不要人工做。

SRE工程师，一般都有软件开发的背景，会写代码，能开发工具和系统，来自动化运维工作，同时也懂系统和网络，能排查和解决运维问题。他们的核心目标，是保证系统的可靠性，同时提高运维的效率，减少人工操作。

Google在2003年左右就开始有SRE这个岗位了，经过十几年的发展，已经形成了一套完整的理念和方法论，《SRE：Google运维解密》这本书，就是对这套理念和方法论的系统总结，也是第一本系统介绍SRE的书。

二、这本书讲了什么

这本书很厚，有五百多页，内容非常丰富，涵盖了SRE的各个方面，我把它的主要内容，分成几个部分来介绍。

第一部分：介绍SRE的理念和原则

书的第一部分，主要介绍SRE的基本理念和原则，包括：

  • SRE是什么，和传统运维有什么区别
  • SRE的核心目标，是保证系统的可靠性
  • 错误预算（Error Budget）的概念，如何在可靠性和研发速度之间平衡
  • SRE团队的组织和职责，SRE和开发团队的分工和协作
  • SRE的工作内容，包括值班、排障、项目开发等

这一部分，是全书的基础，讲清楚了SRE的理念和原则，后面的内容，都是围绕这些理念展开的。

第二部分：原理

书的第二部分，讲SRE的原理，包括：

  • 服务等级目标（SLO）和服务等级协议（SLA），如何定义和衡量系统的可靠性
  • 减少故障的影响，如何设计系统，让故障的影响最小化
  • 监控系统，如何构建有效的监控，及时发现问题
  • 值班和排障，如何高效地处理故障，减少故障的影响时间
  • 变更管理，如何安全地做变更，减少变更导致的故障

这一部分，讲的是保证系统可靠性的核心原理，是SRE工作的理论基础。

第三部分：实践

书的第三部分，讲SRE的具体实践，包括：

  • 自动化，如何用自动化减少人工操作，提高效率
  • 发布工程，如何构建安全、可靠的发布流程
  • 简单化，为什么简单的系统更可靠，如何保持系统的简单
  • 成本和性能，如何在可靠性、性能和成本之间平衡
  • 数据处理系统的SRE，如何运维大数据系统

这一部分，讲的是SRE在实际工作中的具体做法和工具，非常实用。

第四部分：管理

书的第四部分，讲SRE团队的管理，包括：

  • 如何组建和管理SRE团队
  • SRE的沟通和协作，如何和开发团队、产品团队协作
  • SRE的培训和成长，如何培养SRE工程师
  • SRE的未来发展方向

这一部分，更多的是给管理者看的，讲如何建设和管理一个高效的SRE团队。

总的来说，这本书内容非常全面，从理念到原理，从实践到管理，都讲得很透彻，而且都是Google的真实经验，有很多实际的案例和数据，非常有说服力，也非常值得学习。

三、我最大的收获一：运维不是救火，而是工程

读完这本书，我最大的收获之一，就是对运维这个岗位的认知，发生了根本性的改变。

以前我对运维的认知，就是运维是"救火队"，系统出了问题，运维工程师冲上去修，平时就是部署、扩容、监控，做一些重复性的、手工的工作，技术含量不高，也不受重视。

但这本书告诉我，真正的运维，不是救火，而是工程。SRE的理念，是把运维当成一个工程问题来解决，用软件工程的方法，来保证系统的可靠性。运维工程师不应该是被动地救火，而应该是主动地建设，通过架构设计、自动化、监控、流程优化，从根本上减少故障，提高系统的可靠性。

在Google，SRE工程师大部分时间不是在做手工的运维操作，而是在写代码，开发工具和系统，自动化运维工作，优化系统架构，提高系统的可靠性。他们的目标是，通过工程手段，让系统不需要人工干预，就能稳定运行，即使出了问题，也能自动恢复，把人从重复的、手工的劳动中解放出来。

这个理念，对我触动很大。以前我们做运维，总是在救火，出了问题就去修，修完了又等下一个问题，永远在被动地应对，很累，也没有成就感。但SRE的理念是，不要只救火，要从根本上解决问题，通过自动化和工程化，让系统更可靠，减少故障，也减少人工操作。

而且，SRE非常重视研发能力，SRE工程师必须会写代码，能开发工具和系统，这和传统运维只需要会操作、会排障不一样。这也意味着，运维这个岗位，正在变得越来越技术化，越来越工程化，对工程师的要求也越来越高。

这个认知的改变，让我对运维这个岗位，有了新的认识，也有了新的方向。运维不是低技术含量的重复劳动，而是可以很有技术含量，很有挑战性，也很有价值的工作。

四、我最大的收获二：错误预算，在可靠性和速度之间平衡

第二个收获，是错误预算（Error Budget）的概念，这个概念非常巧妙，也非常实用，解决了一个长期存在的矛盾：研发团队想快速发布新功能，运维团队想保证系统稳定，两者之间总是有冲突。

传统的做法是，运维团队为了稳定，会尽量减少发布，限制变更，这就拖慢了研发的速度，研发团队很不满意，觉得运维太保守，阻碍了创新。而研发团队为了快，又会频繁发布，不重视质量，导致故障频发，运维团队很头疼。

Google的做法是，引入错误预算的概念，来平衡可靠性和研发速度。

什么是错误预算呢？简单来说，就是先定义服务的可靠性目标，也就是SLO（服务等级目标），比如，要求系统的可用性是99.9%，也就是说，允许有0.1%的时间不可用，这0.1%的不可用时间，就是错误预算。

比如，一个月有30天，共43200分钟，0.1%就是43.2分钟，也就是说，这个月，系统最多可以有43.2分钟的不可用时间，这就是这个月的错误预算。

有了错误预算之后，研发团队和运维团队，就有了一个共同的衡量标准。如果系统的故障时间，没有超过错误预算，说明系统的可靠性是达标的，研发团队可以放心地发布新功能，加快迭代速度，因为还有预算可以用。如果故障时间超过了错误预算，说明系统的可靠性不达标，这时候，研发团队就要停下来，优先做稳定性建设，减少发布，修复问题，直到可靠性恢复到目标范围内。

这个机制，非常巧妙地解决了研发和运维的矛盾。不再是运维单方面地限制发布，而是根据系统的实际可靠性，来决定发布的速度，可靠性好，就可以快一点，可靠性差，就慢一点，先做稳定性。双方有了共同的目标和标准，就不再是对立的，而是协作的。

而且，错误预算也让大家对故障有了更理性的认识，不再是追求100%的可用，因为100%可用是不可能的，成本也极高，而是接受一定的故障，在可接受的范围内，尽可能快地迭代。这比盲目追求绝对稳定，要理性得多，也实用得多。

这个概念，我觉得非常有价值，不仅适用于运维，也适用于很多需要平衡质量和速度的场景，值得我们学习和借鉴。

五、我最大的收获三：监控不是越多越好，而是要有效

第三个收获，是关于监控的理念。以前我觉得，监控就是要监控得越多越好，指标越多，告警越多，就越安全，越能及时发现问题。但这本书告诉我，监控不是越多越好，而是要有效，过多的、无效的监控，反而会造成告警疲劳，让真正重要的告警被淹没。

Google的监控理念，是监控应该有明确的目的，每一个监控指标，每一个告警，都应该是有用的，能指导行动的。他们把监控分成了四个层次：

  • 告警（Pages）：需要人工立即处理的，必须通知到人，比如系统不可用，数据丢失等。
  • 工单（Tickets）：需要人工处理，但不紧急，可以在工作时间处理的，比如磁盘快满了，证书快过期了。
  • 日志（Logging）：用于事后排查和审计，不需要实时通知，比如详细的请求日志，操作日志。
  • 仪表盘（Dashboards）：用于观察系统的整体状态，趋势分析，不需要告警，比如QPS趋势，响应时间趋势。

这个分层非常重要，不是所有的异常都需要告警，只有需要立即人工处理的，才应该告警，其他的，可以用工单、日志、仪表盘来处理。如果什么都告警，告警太多了，人就会麻木，产生告警疲劳，真正重要的告警来了，反而可能被忽略，这是非常危险的。

而且，Google强调，告警应该是"症状驱动"的，而不是"原因驱动"的。也就是说，告警应该监控用户能感受到的症状，比如系统不可用、响应慢、错误率高，而不是监控内部的原因，比如CPU高、内存高、某个进程挂了。因为用户不关心你的CPU高不高，只关心系统能不能用，快不快。而且，症状是有限的，原因是无限的，监控症状，比监控原因，更有效，也更精简。

这个理念，对我启发很大。以前我们做监控，总是想把所有能监控的都监控上，CPU、内存、磁盘、网络、进程，什么都告警，结果告警满天飞，每天收到一大堆告警，大部分都是没用的，慢慢就不看了，真正出问题的时候，反而没注意到。

读了这本书之后，我才明白，监控的目的，是发现需要处理的问题，而不是收集所有的数据。有效的监控，应该是精简的、有层次的、能指导行动的，告警要少而精，每一个告警都应该是重要的，需要处理的，这样才能保证告警的有效性，也才能在故障发生时，及时发现和处理。

六、我最大的收获四：故障是不可避免的，关键是快速恢复

第四个收获，是对故障的态度。以前我们总觉得，故障是不好的，是失败，要尽量避免，出了故障就要追责，要处罚。但这本书告诉我，在大规模的复杂系统中，故障是不可避免的，无论你怎么做，都不可能完全消除故障，我们能做的，是减少故障的发生，更重要的是，在故障发生时，能快速恢复，减少故障的影响。

Google的理念是，接受故障的存在，不追求零故障，而是追求快速恢复。他们会做很多故障演练，比如"混沌工程"，故意在系统中注入故障，测试系统的容错能力和恢复能力，确保系统在真实故障发生时，能快速恢复。

而且，Google对故障的态度非常开放，出了故障，不会一味地追责和处罚，而是做无指责的故障复盘，重点不是追究谁的责任，而是找到问题的根本原因，改进系统，避免类似的故障再次发生。他们会写详细的故障复盘报告，记录故障的发生、处理、原因、改进措施，分享给整个团队，让所有人都能从故障中学习。

这个态度，我觉得非常重要。很多团队，出了故障，第一反应是追责，是谁的错，要处罚谁，结果大家都害怕故障，出了问题就隐瞒，就推诿，反而不利于问题的解决，也不利于团队的成长。

而Google的做法是，把故障当成学习的机会，无指责复盘，重点是改进系统，而不是处罚个人。这样，团队就不会害怕故障，出了问题会积极面对，主动分享，共同改进，系统也会越来越可靠。

而且，快速恢复的能力，比追求零故障更重要，也更现实。因为复杂系统的故障，是不可能完全避免的，你能做的，是在故障发生时，能快速发现、快速定位、快速恢复，把影响降到最低。这比花巨大的成本去追求不可能的零故障，要务实得多，也有效得多。

这个理念，不仅适用于运维，也适用于很多其他领域，接受不完美，接受错误和失败，重点是从中学习，快速改进，这是一种非常成熟和理性的态度。

七、我最大的收获五：自动化是SRE的核心

第五个收获，是对自动化的重视。在Google，自动化是SRE的核心，SRE工程师的大部分时间，都花在自动化上，能用自动化解决的问题，就绝对不用手工操作。

为什么这么重视自动化？因为手工操作有几个问题：

  • 效率低，手工操作慢，尤其是大规模的操作，比如扩容几百台机器，手工根本做不过来。
  • 容易出错，人不是机器，总会有疏忽的时候，手工操作多了，迟早会出错，而且一旦出错，可能就是大问题。
  • 不可重复，手工操作依赖人的经验和状态，不同的人操作，结果可能不一样，同一个人，不同时间操作，结果也可能不一样。
  • 不可扩展，随着系统规模的扩大，手工操作的成本会线性增长，最终会成为瓶颈。

而自动化，就能解决这些问题，自动化操作快、准确、可重复、可扩展，能大大提高运维的效率和可靠性。

Google的SRE，有一个原则，就是如果一个手工操作，需要做超过一次，就应该考虑自动化。他们开发了大量的自动化工具和系统，比如自动化部署、自动化扩容、自动化故障恢复、自动化测试等，把大部分运维工作都自动化了，人工只需要做决策和处理异常情况。

而且，Google强调，自动化不是一蹴而就的，是逐步演进的。最开始是手工操作，然后是用脚本自动化，然后是更智能的、自服务的自动化系统，最后是完全自治的、不需要人工干预的系统。这个过程，是逐步完善的，不需要一步到位，但要有自动化的意识，不断地把重复的工作自动化。

这个理念，对我影响很大。以前我们做运维，很多工作都是手工的，虽然也写一些脚本，但没有系统地做自动化，很多重复性的工作，还是在手工做，效率低，也容易出错。读了这本书之后，我开始有意识地把重复性的工作自动化，写脚本，做工具，虽然花了一些时间，但长期来看，大大提高了效率，也减少了出错。

我觉得，自动化不仅是运维的核心，也是整个IT行业的趋势，随着系统越来越复杂，规模越来越大，手工操作已经跟不上了，自动化是必然的选择。作为技术人员，我们应该有自动化的意识，不断地把重复的工作自动化，把自己从重复劳动中解放出来，去做更有价值的事情。

八、这本书的一些不足

当然，这本书也不是完美的，也有一些不足。

首先，这本书是Google的经验总结，Google的规模和技术实力，是大多数公司比不了的，他们的很多做法，比如大规模的自动化系统、专门的SRE团队、完善的基础设施，小公司可能学不来，也不需要完全照搬。我们读这本书，应该学习它的理念和方法，而不是照搬具体的做法，要根据自己公司的实际情况，灵活运用。

其次，这本书比较厚，内容很多，有些部分比较理论化，读起来可能有点枯燥，需要耐心。而且，有些内容比较深入，需要有一定的运维和系统基础，才能完全理解，初学者可能会觉得有点难。

第三，这本书出版于2016年，到现在已经几年了，技术发展很快，有些内容可能有点过时了，比如一些具体的工具和技术，现在可能有了更好的选择。但它的核心理念和方法论，是不过时的，仍然有很高的参考价值。

总的来说，这些不足，不影响这本书的价值，它仍然是运维领域的经典之作，值得每一个做运维或者对运维感兴趣的人读一读。

九、给想读这本书的朋友的建议

最后，给想读这本书的朋友一些建议：

1. 不要追求一次读完，慢慢读，反复读

这本书很厚，内容很多，一次读完会很吃力，也消化不了。建议慢慢读，分章节读，读完一部分，思考一下，结合自己的工作实践，想想哪些可以借鉴，哪些可以改进。有些经典的章节，比如错误预算、监控、故障复盘，可以反复读，每次读都会有新的收获。

2. 结合自己的工作实践来读

不要把这本书当成纯理论的书来读，要结合自己的工作实践，边读边想，我们现在的运维，有哪些问题，哪些可以用SRE的理念来改进。比如，我们的监控是不是太乱了，是不是可以按照SRE的方法来优化；我们的发布是不是太危险了，是不是可以引入错误预算的概念；我们的故障复盘是不是在追责，是不是可以改成无指责复盘。这样结合实践来读，收获会大得多。

3. 学习理念，不要照搬做法

Google的做法，是基于他们的规模和技术实力的，我们不需要完全照搬，要学习他们的理念和方法，根据自己公司的实际情况，灵活运用。小公司有小公司的做法，不需要像Google那样，建庞大的SRE团队，开发复杂的自动化系统，但SRE的核心理念，比如重视可靠性、自动化、监控、故障复盘，是任何规模的团队都可以学习和借鉴的。

4. 不仅运维要读，开发和产品也应该读

这本书虽然是讲运维的，但它的理念，不仅适用于运维，也适用于开发和产品。错误预算的概念，开发和产品应该了解，这样才能理解为什么有时候要放慢发布速度，先做稳定性；监控和故障的理念，开发也应该了解，这样才能写出更可靠的代码，设计更可靠的系统。所以，不仅运维要读，开发和产品也应该读一读，这样大家才能有共同的语言和理念，更好地协作。

十、写在最后

《SRE：Google运维解密》这本书，是我读过的最好的运维书籍，没有之一。它不仅讲了运维的具体做法，更重要的是，它传递了一种理念，一种用工程的方法做运维的理念，一种重视可靠性、重视自动化、重视学习和改进的文化。

读完这本书，我对运维这个岗位，有了全新的认识，也对自己的工作，有了新的方向和目标。运维不是救火，不是重复劳动，而是可以很工程化、很技术化、很有价值的工作。我们可以用代码和自动化，把系统建设得更可靠，把自己从重复劳动中解放出来，做更有价值的事情。

当然，SRE的理念，不是读一本书就能掌握的，需要在工作中不断实践，不断改进，慢慢积累。但至少，这本书给了我们一个方向，一套方法论，让我们知道，好的运维应该是什么样的，应该往哪个方向努力。

最后，推荐每一个做运维，或者对运维感兴趣的朋友，都读一读这本书，相信你一定会有收获。也希望我们都能从这本书中学习，把SRE的理念运用到自己的工作中，把系统建设得更可靠，把工作做得更高效，也让自己成为更优秀的工程师。