C. Google SRE 实践

最新推荐文章于 2023-05-04 08:31:39 发布

micklongen

最新推荐文章于 2023-05-04 08:31:39 发布

阅读量729

点赞数

分类专栏： Google SRE运维解密文章标签： SRE 运维

本文链接：https://blog.csdn.net/micklongen/article/details/89739597

版权

Google SRE运维解密专栏收录该内容

9 篇文章 4 订阅

订阅专栏

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倍推进。与此同时，还要考虑到变更部署的地域性分布。
创建一个构建和测试环境
- 区分项目的重要性，确定测试的优先级
- 良好的测试基础设施
测试大规模使用的工具
针对灾难的测试
发布到生产环境
集成
- 多种类型的测试工具互相验证，有些类型只负责报错，不做修复
生产环境探针
- 已知的错误请求
- 已知的正确请求，可以针对生产重放
- 已知的正确请求，不可以针对生产重放