《SRE Google运维解密》读书笔记（01）

一、SRE组织信息

• 2003年开始组建，7名软件工程师组成。到2016年，约1000余人。
• 招聘：50%-60%是标准的软件工程师；40%-50%是满足软件工程师85%-99%技能，同时具备一定程度其他技术能力的工程师。如：Google是熟悉UNIX系统内部细节和1-3层网络知识。
• 工作配比：传统运维工作上限50%，如：工单处理、手工操作；必须将50%的精力花在真实的开发工作上。必须不断度量每个团队的工作时间分配。

二、SRE方法论——主要是前2项

1、确保长期关注研发工作

• 确保50%传统运维工作上限落实。超出部分可暂时转移给开发团队分担。
• 8-12小时on-call期间最多只处理2个紧急事件，确保紧急事件跟进投入和事后报告质量。

2、在保障服务SLO的前提下最大化迭代速度

• 错误预算：1-可靠性目标。如：一个产品可靠性目标是4个9，那么错误预算就是0.01%。
• SRE团队可以与开发团队通过错误预算形成目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。

3、监控系统

• 这部分书里讲得非常传统。主要就是讲输出Alert、Ticket、Log。其实这里是很大一部分运维自动化工作的起点。

4、应急事件处理

• 重温几个名词：可靠性、MTTF（平均失败时间）、MTTR（平均恢复时间）。评价一个团队将系统恢复到正常情况最有效指标是MTTR。
• 承载手段和优先级：自动恢复工具>playbook>船到桥头自然直。
• 运维手册是人工处理的关键手段，同时要通过灾难恢复演习培训团队成员。

5、变更管理

• 70%的生产事故由变更触发。
• 变更管理的最佳实践是自动化。
• 自动化要完成：1）渐进式发布；2）迅速准确检测问题发生；3）安全迅速回退。

6、需求预测和容量规划

• 自然增长需求预测模型，类似于配置手册，说明不同容量规模下，应该提供的资源配置，以及对应的计算方法；
• 非自然增长的需求来源的统计。这一点通常系统化考虑得较少。例如：新功能上线、商业推广等特殊活动；
• 周期性压力测试。主要目的是为了基线校准和检验。通常大伙懒癌发作，默默地无视了。

7、资源部署

8、效率和性能

最后这两章实在看不出要说什么，其实都是第6点衍生出来要做的2件重要的事，可能是想重点提一下吧。

思考

这章的理念拿到电信行业的运维上，关键障碍还是运维人员能力转型的问题。不同于互联网产业，运营商本身积累了大量的传统运维能力模型的员工。哪怕外包给第三方的运营商，这些提供管理服务的厂商也同样是以传统运维能力模型为主。运营商外包只是降低风险和改良成本的有限优化手段。根本上的运维组织能力模型决定了运营商做devops，在能力基础上存在巨大的GAP。既没有软件产品研发经验，也没有对应的人员和管理团队，有的是传统运维人员存量（对于有着完善员工保障体系的国家来说，甚至是包袱）。那么，如果devops是业务敏捷的必经之路，运营商应该怎么办？后面咱们跟着这本书一点点来讨论。