关于这本书的书名，Site Reliability Engineering: How Google Runs Production Systems，翻译成Google运维解密，我觉得有失偏颇。
SRE这个职位固然与运维紧密相关，但这本书其实更多的着眼于Google内部的IT基础设施和分布式系统服务的设计与实现。
当然，这些工作在Google内部是由SRE工程师来完成，但是在国内的互联网公司里，这部分工作大都还是由软件工程师或者是架构设计师来负责，所以，我认为这本书对国内的开发人员来说有更高的参考价值。
从软件工程师的角度，我从这本书里看到的更多有价值的是Google如何实现复杂系统，用什么样的方法来保障系统的稳定，以及有哪些辅助工具来快速查错。
所有的Google服务之间都使用RPC通信，Google内部的RPC框架名为Stubby，使用protocol buffer对数据进行编码。
与之对应的开源实现是gRPC和protobuf。
另外每个软件服务器都有一个内置的http服务，提供一些调试信息和统计信息，供在线调试、监控等使用。关于监控，还有更多的相关描述。
配置中心与功能开关是每个服务的基础要求。
Google的功能开关框架基本可归类为以下两类：
- 主要面向用户界面修改的
- 可以支持任意服务器和逻辑修改的
结合我自己的实际情况来看，虽然我们花了一年多时间建立起了一套还算比较完善的监控和报警平台，并且在多次事故分析过程中发挥出了作用，但是想要让整个团队达成业务监控的共识还是比较困难。
在没有具体要求的时候，开发人员很难有意思主动去为新增的业务代码添加监控指标。而只有在线上出现问题，发现缺少了关键监控信息和日志之后，才会想到要去补充。
在这本书里，到处都能看到有关监控的描述，以及通过监控来快速定位问题的案例。
在Google的任务管理系统Borg 2003年面世之后不久，工程师就创造了一个新的监控系统，Borgmon。
16年前Google就已经成熟的技术，我们今天依然还没能形成标准化。这其实也是国内技术领域的一个现状，技术落后太多。
监控系统应该解决两个问题：什么东西了故障了，以及为什么出故障。
这也是我在团队内部不断强调，希望与大家达成共识的一件事。
自动化的价值究竟是什么？ 没有几个人能像机器一样永远保持一致。
一致性的执行范围明确、步骤已知的程序----是自动化的首要价值。
自动化领域的工具也已经非常的成熟：ansible, puppet, chef等等。
将尽可能多的规范化操作自动化，是规模化运维的前提。
Google鼓励工程师们使用标准工具来自动化一些常见流程。
为了保障可靠性，我们应该尽量减少流程中的单点故障源，包括人在内。
CI/CD可以认为是自动化的一部分，同时也是大部分企业都在使用的标准化流程。
现在很少还有团队使用原始的手工构建方法，Jenkins或者Gitlab CI已经发展的相当成熟，各家云厂商也都有了商业的支持。
但是，能够做到什么样的程度还是有很大的差别。
只是用来打包，还是集成单元测试、代码检查，再或者是能够做到像Google那样“测试通过即发布"。
我们的目标当然也像是SRE所描述的：发布工程师开发工具，制定最佳实践，以便让产品研发团队可以自己掌控和执行自己的发布流程。
频繁的发布可以使得每个版本之间的变更减少，这种方式使得测试和调试变得简单。
同时，建立强测试文化。
将所有遇到的问题都进行测试案例化。如果每个Bug都变成了一个测试用例，这样用不了多久就会有一套完善的回归测试体系了。
Google还是版本控制系统的重度用户，除了管理代码外，还利用版本系统做一些其他的事情，例如存放配置文件等。
版本控制系统具有许多优势----跟踪历史、修改记录以及代码审核----也都适用于配置文件。
一套良好的测试基础设施，加一套持续构建系统，快速迭代就能跑起来了。
Google将发布定义为用户可见的应用程序代码更新，Google有时可以做到每周发布70次。
尽最大可能让系统恢复服务。
缓解系统问题应该是你的第一要务。
最高的优先级永远是将手头问题迅速解决。
如何检查问题：
- 在Google，监控系统记录了整个系统的监控指标，监控指标是找到问题所在的开始。
- 日志是另外一个无价之宝。
- 一些跟踪工具，例如Dapper，提供了非常有用的了解分布式系统工作情况的一种方式。
日志、监控与链路追踪，每一项的技术也都早已经成熟，并且也都有对应的开源实现或者云厂商的服务，如何落地才是问题。