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)
C. Google SRE 实践
猜你喜欢
转载自blog.csdn.net/micklongen/article/details/89739597
今日推荐
周排行