C. Google SRE 实践
概述
服务可靠度层级模型
产品设计
软件开发
容量规划
测试 + 发布
事后总结和问题根源分析
应急事件处理
监控
监控（10）
组件
接口
时间序列信息操作语言
服务端：基本上每个集群一个实例，不同实例之间的数据是互通的
时间序列数据的存储
规则计算：数据汇总
报警
监控系统的分片机制
收集层：运算和汇总，每个集群部署一个或者两个（避免单点故障）
全局层：计算层和展示层
客户端：应用程序的监控埋点
白盒测试：主要是应用自己收集自己的测试数据
黑盒测试
配置文件
自动化测试工具，测试配置文件是否正确
模板管理
将某一个代码类库暴露的所有监控信息模板化
HTTP服务器类库
内存分配器类库
存储系统客户端类库
通用RPC框架
等等
将单实例监控数据按级汇总到全局范围的模型
等等
应急事件处理（11 ～ 14）
on - call 轮值
生产系统中的维护需求响应时间，跟业务需要的可靠性有关
直接面向最终用户的服务或者时间爱呢非常紧迫的服务：5分钟
非敏感业务：30分钟
主副on-call机制
机制一：副on-call处理主on-call没有响应的事情
机制二：主on-call处理生产系统紧急情况，副on-call负责处理其他非紧急的生产环境变更需求
机制
每12个小时最多只能处理2个紧急事件
排查故障
理论
反复采用假设 - 排除 手段的过程
步骤
故障报告
定位
合理判断一个问题的严重程度
检查
诊断
测试/修复，有可能失败
治愈
注意点
在遇到一个大型问题是，首先要做的是尽最大可能让系统恢复，而不是立即开始故障排查过程
比如说将用户流量从问题集群导向其他还在正常工作的集群
将流量抛弃以避免连锁过载问题
关闭系统的某些功能以降低负载
等等
紧急事件响应
紧急故障管理
角色
事故总控
事务处理团队
发言人
规划负责人
措施/机制
划分优先级：控制影响范围，恢复服务，同时为根源调查保存现场
事前准备：事先和所有事故处理参与者一起准备一套流程
信任：充分相信每个事故参与者，分配职责后让他们自主行动
反思：在事故处理过程中主意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受，应该寻求更多的帮助
考虑替代方案：周期性地重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要或者更紧急的事情
联系：平时不断地使用这项流程，知道习惯成自然
换位思考：上次你是事故总控负责人吗？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。
什么时候对外宣布事故
是否需要引入第二个团队来帮助处理问题？
这次事故是否正在影响最终用户？
集中分析一小时后，这个问题是否依然没有得到解决？
运维压力
量化运维压力：比如说 每天工单数量 < 5，每次轮值报警实践 < 3等
降低报警数：一个异常可能触发多条报警，可以合理地分组报警信息
极端情况下：停止支持某个服务，或者和研发团队共同分担
机制
保证每个工程师每个季度至少参与on-call一次，最好两次
每年举办一次持续数天的全公司灾难恢复演习，针对理论行和实际性的灾难进行演练
事后总结和问题根源分析（15，16）
事后总结报告：对事不对人
重点关注如何定位造成这次事件的根本问题，而不是职责某个人或者团队的错误或者不恰当的举动。
报告评审
关键的灾难数据是否已经被收集并保存起来了？
本次事故的影响评估是否完整？
造成事故的根源问题是否足够深入？
文档中记录的任务优先级是否合理，能够及时解决了根源问题？
这次事故处理的过程是否共享给了所有相关部门？
建立事后总结文化
本月最佳事后总结
Google + 事后总结小组
事后总结阅读俱乐部
命运之轮：将某一篇事后总结的场景再现，一批工程师负责扮演这篇文档中提到的各种角色
收集关于时候总结有效性的反馈
挑战：投入产出比的质疑
首先进行几轮完整的和成功的事后总结，证明它们的价值。
确保对有效的书面总结提供奖励和庆祝。不光通过前面提到的公开渠道，也应该在团队或个人的绩效中体现
鼓励公司高级管理层认可和参与其中。
跟踪故障
聚合：将多条报警聚合成一个单独的故障，或许能够有效解决这个问题
加标签：对故障做标签（不同团队对标签要求不一样，比如说有些团队只需要标注到 network 就行了，有些团队可能需要更加细化，比如说network:switch 或者 network:cable）
分析
每周/每月/每季度 的故障数量和每次故障的报警数量
对比团队/服务 以及按时间分析趋势和模式。跨团队的数据统计
需要语义分析的技术：找到更广泛的问题，而不仅仅是简单的计数，比如说 寻找基础设施中造成故障最多的一部分。通过跨团队收集，可以从中找出系统性的问题。
测试（17）
测试类型
传统测试
单元测试
集成测试
mock测试
系统测试
冒烟测试：如果该测试不通过，那么其他更昂贵的测试可以不用进行了
性能测试：性能测试可以保证随着时间推移系统性能不会下降，或者资源要求不会升高
回归测试：保证之前的Bug不会重现
生产测试
配置测试：针对配置文件的测试
压力测试
数据库容量满到什么程度，才会导致写请求失败
向某应用每秒发送多少个请求，将导致应用过载并导致请求处理失败。
金丝雀测试：灰度发布
指数型升级部署：先部署1台，然后部署2台，然后部署4台等等
以0.1%的用户流量服务器容量开始，同时按24小时增长10倍推进。与此同时，还要考虑到变更部署的地域性分布。
创建一个构建和测试环境
区分项目的重要性， 确定测试的优先级
良好的测试基础设施
测试大规模使用的工具
针对灾难的测试
发布到生产环境
集成
多种类型的测试工具互相验证，有些类型只负责报错，不做修复
生产环境探针
已知的错误请求
已知的正确请求，可以针对生产重放
已知的正确请求，不可以针对生产重放
其他
容量规划（18 ～ 22）
软件开发（23 ～ 25）
数据的备份和恢复（26）
产品发布（27）