《Google SRE 工作手册》阅读笔记
SRE 与 DevOps 的关系
站点可靠性工程师（SRE）是 Google 工程副总裁 Ben Treynor Sloss 创造的术语。DevOps 是一种理念和工作方法，SRE 是 DevOps 的实现，比 DevOps 更具体、更清晰。
DevOps 核心思想
- 运维和开发团队不应该独立，各自为政，需要打穿部门墙。
- 意外不可避免，缺少保障措施才是问题。重心应该放在如何从故障中恢复，而不是防范故障的发生。
- 每次变更要尽量小，变更次数要尽量多。不应该为了提高效率或者为了“降低”风险，把变更积攒起来一起做。应该用正确的方式面对变更的风险，比如将其拆分为规模更小、风险也更小的变更，拼接起来形成一个前向稳定的变更序列，并在实施过程中不断优化变更流程，实现变更管理方式的转型。
- 自动化工具固然非常重要，但工程师文化更重要，良好的文化可以解决糟糕工具造成的麻烦，反之不然。
- 统一的度量是不同部门之间沟通的基石。
SRE 核心思想
- 做好运维是一个软件开发问题。SRE 应该使用软件工程的方法来解决问题。
- 不企图提供 100% 的可用性。应该以服务质量目标（SLO）为准绳，任何设计不应该违反 SLO。
- 尽量减少琐事，琐事不是工作。在运维任务上多花一分钟，在项目上就少了一分钟。虽然合理的运维任务可以更好地为设计系统提供信息，但是项目工作才能提高服务的可靠性和扩展性。
- 确定自动化目标（哪些需要自动化，什么条件下的自动化，如何自动化）。团队成员在琐事上花费的时间不能超过 50%。
- 减少常规故障平均修复时间（MTTR），会提升开发人员的迭代速度。
- 理想情况下 SRE 和产品团队都应该对技术栈有整体的了解（包括前端、后端、存储、内核、物理机），SRE 需要和产品团队共享服务的所有权。
- 负责同一个服务的不同团队应该使用相同的工具，这样优化工具的成本越小，收益更大。