C. Google SRE 实践

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