目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
目前来看，UNIX 系统内部细节和1～3层网络知识是Google最看重的两类额外的技术能力。
我们可以认为DevOps是SRE核心理念的普适版，可以用于更广范围内的组织结构、管理结构和人员安排。同时，SRE是DevOps模型在Google的具体实践，带有一些特别的扩展。
一般来说，SRE团队要承担以下几类职责：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划与管理。
SRE 处理运维工作的一项准则是：在每8～12小时的on-call 轮值期间最多只处理两个紧急事件。这个准则保证了on-call工程师有足够的时间跟进紧急事件，这样SRE可以正确地处理故障、恢复服务，并且要撰写一份事后报告。
事后总结应该包括以下内容：事故发生、发现、解决的全过程，事故的根本原因，预防或者优化的解决方案。
一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需要用户执行某种操作时，才需要通知用户。
Google大量依赖白盒监控，黑盒监控用得虽然不多，但都是在关键地方使用。黑盒监控与白盒监控最简单的区别是：黑盒监控是面向现象的，代表了目前正在发生的—而非预测会发生的—问题，即“系统现在有故障”。白盒监控则大量依赖对系统内部信息的检测，如系统日志、抓取提供指标信息的HTTP节点等。白盒监控系统因此可以检测到即将发生的问题及那些重试所掩盖的问题等。
监控系统的4个黄金指标分别是延迟、流量、错误和饱和度（saturation）。
当修复某个运行在生产环境中的软件的Bug，而需要重新构建之前的一个发布版本时，一般来说是比较复杂的。Google按照之前的源代码版本，加入一些后来提交的改动来构建新的发布来解决这个问题，这种方式被称为摘樱桃（cherry picking）。
构建目标（二进制文件，以及对应的测试等）定义在Rapid的项目配置文件中。某个项目特有的功能开关，例如一些特有的构建标识符等，会由Rapid传递给Blaze。所有二进制文件都支持用一个命令显示自身的构建时间、构建源代码版本，以及构建标识符，这样我们就可以很容易地将一个二进制文件与构建过程对应起来。
所有的代码都默认提交到主分支上（mainline）。然而，大部分的项目都不会直接从主分支上进行直接发布。我们会基于主分支的某一个版本创建新分支，新分支的内容永远不会再合并入主分支。Bug修复先提交到主分支，再cherry picking到发布分支上。这种方式可以避免在第一次构建之后，再引入主分支上的其他的无关改动。利用这种分支与cherry picking的方法，可以明确每个发布版本中包含的全部改动。