相比软件最后的结果、架构设计，真实的设计过程，作者本身的思考的经历更有价值。实现功能永远只是短暂的存在，文档化的设计过程是无价之宝。
自省
SRE是工程师，SRE使用计算科学和软件工程手段设计和研发大型、分布式计算机软件系统。SRE并不是无止境的追求完美，当一个系统足够可靠时，SRE会把精力转向新功能或新产品的研发中。SRE的主要工作是运维在分布式集群管理系统上运行的具体业务服务。
从一切经历中不断学习，包括那些我们最意想不到的经历。
由于一个季度内的错误预算耗尽而停止发布新功能。
SRE团队要承担以下职责：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，紧急事务处理以及容量规划。
谷歌SRE方法论：1、确保长期关注研发；2、在保证服务SLO的前提下最大化迭代速度；3、监控系统；4、紧急事件处理；5、变更管理；6、需求预测和容量规划
错误预算：任何软件系统都不应该一味的追求100%的可靠性。
运维手册，操作手册，
70%的事故都是由变更引发的，变更最佳实践三点：采用渐进式发布，迅速而又准确的定位问题，变更遇到问题时能迅速的安全的回退。
会为一项服务设定一个季度的可用性指标，每周甚至每天进行跟踪。
服务质量：SLI SLO SLA 指标 目标 协议
选择合适的SLO是一个复杂的过程，若单个值不能确认，可用平均值来代替。
每个季度，故意安排一次可控的故障，找到对系统不合理的百分百不停机的依赖。
不是所有的监控指标都是SLI,选择合适的，要真正符合用户需求的。大部分指标应该是分布式，而不是平均值。
指标的标准化：汇总间隔、汇总范围、度量频率、包含哪些请求、数据如何获取、数据访问延时
我们应该从客户想要什么入手，而非我们目前能测量什么。
SLA的建议：不要仅以目前的状态为基础选择目标；保持简单；避免不切实际；SLO越少越好；不要追求完美；实际的SLO不要太高；用户宣传要保守，因为修改非常困难。
琐事特征：手动，重复性，战术性，可被自动化替代，没有持续性价值，和服务同步线性增长。
SRE处理琐事要控制在50%以内，其中包括轮值，最好两个月2周值班，一周正的，一周副的。（说明8个人最好）
SRE的工作内容：
软件工程：设计；系统工程：服务器配置；流程工作：会议，培训，招聘等；以及琐事。
一个10-12个人的SRE团队中，至少有1-2个人专门做监控。
监控系统应该解决两个问题：现象和原因。即什么东西出故障了，为什么出故障。
监控系统的4个黄金指标：延迟，流量，错误和饱和度。
规则越简单越好，没有用的数据需要删除。一季度删除一次。
监控系统增加规则时，应回答如下问题：
（1）该规则是否可以检测到目前不能检测到的，紧急的，可操作性的，并且即将发生的或者已经发生的用户可见故障。
（2）是否可以忽略这条报警，什么情况下会导致用户会忽略这条报警，该如何避免？
（3）这条报警是否确实显示了用户正在受到的影响，是否存在用户没有受到影响，也触发报警的情况？
（4）触发报警后，是否会触发某些操作？是要立即处理？还是可以推迟到第二天处理？该操作可以被自动化吗？操作的效果是长期的还是短期的？
（5）是否有其他人也收到了这样的报警？这些报警是否必要？
我们应该要构建一个良好的监控台页面，直接显示非紧急的异常情况。
为那些没有提供API的系统构建自己的API
自动化案例集：
创建用户账户；某个服务在集群中的上线、下线过程；软件或硬件的安装前准备和退役过程；新软件版本的发布；运行时配置的修改；依赖关系的修改。
最可用的工具通常是每天使用他们的人写的
集群上线自动化进化路线