SRE的概念随着谷歌的这本书可谓普及开来了，个人接触到SRE的概念是在阿里做应用运维，当时还没有中文版，大家都在陆续去看英文版的书，后来到网易做应用运维，运维总监还专门组织过会议学习并思考如何实践这本书介绍的谷歌经验。最近就接着博客汇总一下之前零星的思考。
提纲挈领 SRE这本书单框架非常清晰，五个部分：
1 概览 SRE的职责范围和方法论 重点
2 指导思想 对于方法论的深入细化
3 具体实践 谷歌的具体实践
4 管理 运维工作的管理
5 结束语 其他行业的实践
就个人读书建议，重点关注1、2、4 这三章核心观念和方法论；第三部分有时间可以不按顺序跳着看。
读书笔记我打算针对第1，2，4部分 进行汇总
读书笔记 第一部分：
1 SRE职责范畴：
SRE团队需要承担以下几类职责：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划和管理。
白下说：对谷歌给出的职责做一下进一步归纳：
1 可用性稳定性提升：推动建设产品的高可用体系，包括但不限于：高可用架构方案设计、自动熔断降级策略、紧急故障预案等。
2 监控：包括但不限于：自动化监控覆盖/处理、快速故障定位、报警优化等
3 容量规划和管理： 包括数据库、中间件容量水位监控；核心应用性能压测等。
4 效率优化：自动化工具的开发，流程优化等
5 成本优化：资源利用率等管理
6 性能优化：推动产品服务性能相关的优化活动
7 日常事务/变更管理：产品日常运维需求处理和变更管理，包括日常值班、发布管理等
8 紧急事务处理：应急响应机制建设对于产品方有直接价值：
1 可用性稳定性提升
2 成本优化
3 性能优化对于运维方有直接价值：
1 监控
2 效率优化
3 容量规划和管理常常被忽略却占了较大时间的：
1 日常事务/变更管理 做日常
2 紧急事务处理 救火队
2 SRE核心方法论
1 确保长期关注研发工作。
2 在保障服务SLO的前提下最大化迭代速度
3 监控系统
4 应急事件处理
5 变更管理
6 需求预测和容量规划
7 资源部署
8 效率与性能
白下说：
1 谷歌要求50%的精力花在研发项目上
这个其实就是SRE最重要的内，应为SRE的E就是软件工程师的意义，而不是简单的工程师。
有些人理解为，只要需要有50%的时间在coding中。
有意思的是我问了一个研发人员，我问你们真正coding的时间能达到50%吗，他说并不能保障。那么这里可以中国化一下谷歌的要求————SRE需要将不少于50%的精力投放到处理日常事务和紧急处理事务的时间上。 一句话不要让日常占据你超过一半的时间。
2 SLO问题在第二部分详细叙述第二条方法论的重要在于，要平衡可用率和迭代速度，不要因为追求过高的稳定性和可用性而降低了迭代速度，这里迭代指什么———— 发布、变更都应该算在其中。参考我的另一篇文章：【什么，又是流程有问题？】https://www.cnblogs.com/hzluyang/p/9220532.html
3 监控和应急事件处理：
谷歌经验自动化不依赖人的接入才是高效的，这其实也在效率优化的内涵
4 容量规划：
SRE需要主导资源部署和容量规划的过程
容量规划三要素
- 必须要有准确的预测自然增长的预测模型
- 规划中必须有准确的非自然增长的需求来源统计
- 必须有周期性压力测试
5 效率与性能：
业务总体资源使用情况由三个要素驱动：用户需求、可用容量和软件的资源使用效率
性能提升就相当于提升了容量，并且还提高了资源使用效率