「Goolge SRE 解密」

SRE就是让一个软件工程师来主导设计一个新型运维团队的结果

概念

SRE: Site Reliability Engineering，SRE是一门工程科学，旨在帮助组织在其基础设施和应用系统中可持续的达成预设的可靠性目标。

前提：

1. 故障是不可避免的，建立错误预算，要以工程视角来理解运维
2. 所有问题都是软件问题、都能用程序来解决，研发软件解决运维问题
3. SLO的引入
4. 团队人员兼具开发和运维能力，

DevOps文化

DevOps是一套有关运维和产品开发之间全生命周期协作的广泛原则。

1. 运维构建自动化的变更流水线，运维搭桥、开发走路
2. CI/CD工具链：
   1. 持续交付
   2. 持续集成

原则

SRE是一个工作角色，一组有效的实践以及激励这些实践的信念。

1. 做好运维工作，需要采用软件工程的方法来实现
2. SRE不试图为所有东西提供100%的可用性，接受故障、拥抱故障、解决故障
3. SRE反对任何不必要的人力接入，要尽可能减少手工操作，运维的时间投入不得超过50%
4. 通过降低失败成本而提升服务效能，SRE并不一定带来可靠性提升，更注重改进改进的速度
5. 与开发共享所有权
   1. SRE倾向关注生产问题而非业务逻辑
   2. SRE关注服务的可用性、延迟、性能、效率、变更、监控、应急响应和容量规划
   3. SRE团队和开发团队应该对技术栈有个一致的观点(前端、后端、库、存储、内核和物理机)

核心职责

体现SRE价值

1. 可用性优化(MTTR)
2. 延迟优化
3. 性能优化
4. 效率优化
5. 变更管理
6. 监控
7. 应急响应
8. 容量规划与管理

影响SRE效果的常见问题

1. 人员误操作
2. 雪崩效应
3. 未经充分、完成测试的版本发布
4. 基础设施故障以及定期升级维护

服务质量目标

服务质量术语

1. 服务质量指标 SLI
2. 服务质量目标 SLO
   1. 基于数据驱动做出的事关可靠性决策的关键要素，是SRE工程的核心
   2. 选择一个合理的SLO是非常复杂的过程
   3. 一个好的SLO应该是SMART的、应该是具体、有时限且可衡量的
      1. Specific：特有的，能明确表达其具体含义
      2. Measurable：可测量，有具体数值
      3. Achievalbe：可达成，不是无法完成的目标
      4. Relevant：要反应到用户体验相关
      5. Timebound：要尽量只覆盖系统负载较重的时间段，以免被平均值稀释
3. 服务质量协议 SLA

在实践中如何确定指标

1. 选择指标时的注意事项
   1. 基于用户对系统体验的真实需求确定有效指标
   2. 指标一般以四五个为最佳
2. 服务分类及其关键指标
   1. 前端
   2. 存储
   3. 大数据
   4. 所有系统都应该关心正确性
3. 指标的收集与汇总
   1. 借助监控系统收集数据
   2. 小心汇总，大部分指标应该以“分布”而非平均值来定义
4. 指标的标准化
   1. 常见SLI标准化
   2. 使用常见标准

如何在实践中为指标确立目标

1. 目标的定义
   1. SLO应指明度量方法、有效条件
   2. 关键指标上可以指定多个SLO
   3. 不同类型用户设立不同的SLO
   4. 不追求100%达成，以避免影响创新和部署速度
2. 目标的选择
   1. 确立SLO不是单纯的技术活动，涉及产品和业务层面的决策
   2. 关于目标选择需要讨论的方向
      1. 不满足于当前系统状态
      2. 保持简单
      3. 避免绝对值
      4. SLO越少越好
      5. 不要追求完美
3. 控制手段
   1. 监控并量度系统的SLI
   2. 比较SLI和SLO，以决定是否需要执行操作
   3. 决定执行何种操作以满足目标
4. 帮助用户建立正确的预期
   1. 留出安全区
   2. SLO留余地

减少琐事

何为琐事

1. 琐事特指运维中手动性、重复性、可被自动化、战术性、没有持续价值的工作
2. 琐事与服务数量呈线性关系

什么算工程工作

1. 工程工作是符合长期战略，会对我们服务进行长久性改善的工作
2. 工程工作通常有创新型和创造性，着重通过通用设计来解决问题
3. 典型的SRE活动
   1. 软件工程：编写或者修改代码
   2. 系统工程：配置生产环境或者系统文档以及架构、设计和生产环境的咨询工作
   3. 流程负担：同运维服务间接相关的行政工作

琐事越少越好

1. 琐事多，意为不佳的系统设计
2. 提高可靠性、性能或者利用率会进一步消除琐事

琐事繁多是不是一定不好

1. 接受琐事，琐事是不可避免的
2. 琐事是低风险、低压力的，会给一些人带来满足感和快速胜利感
3. 琐事是有害的
   1. 职业停滞，带来士气低落
   2. 进展缓慢，促进摩擦、违反承诺

分布式监控

术语和定义

1. 监控:收集 处理 汇总并显示关于某个系统实时量化数据
2. 白盒监控:依靠系统内部暴露的性能指标进行监控,包括日志分析\http接口等进行监控
3. 黑盒监控:通过测试某种外部用户可见的系统行为进行监控
4. 监控面板
5. 告警
6. 根因

为什么要监控

1. 分析长期趋势
2. 跨时间范围的比较
3. 告警:在系统发生故障时通知管理员
4. 构建控制台页面(大屏显示)
5. 临时性的回溯分析(在线测试)

防止告警风暴

设置合理的告警预期

1. 使用简单和快速的监控系统配合高效的工具进行事后分析
   1. 避免任何魔法系统
   2. 坚持监控规则越简单越好
   3. 实验功能的监测要容忍错误率
2. 避免复杂的依赖关系
3. 持续优化监控系统
4. 告警系统的指导原则
   1. 发出紧急告警的组件需要非常简单而且可靠
   2. 产生告警的监控系统规则应该非常容易理解,同时代表一个清晰的故障场景

现象与原因

1. 监控系统应该解决两个问题
   1. 什么东西出故障了
   2. 为什么出故障
2. 什么东西出故障代表了现象
3. 为什么则代表了原因
4. 现象和原因的区分是构建信噪比高的监控系统时最重要的概念.

黑盒与白盒

黄金指标

1. 延迟
2. 流量
3. 错误
4. 饱和度

长尾问题

1. 平均值会掩盖异常尖峰
2. 请求按延迟分组计数,可以用来制作直方图

合适的精度

1. 系统的不同部分应该以不同的精度进行度量
2. 仔细设计度量指标的精度

简化,直到不能再简化

1. 复杂是没有止境的
2. 少即是多
   1. 最反映真实故障的规则应该是越简单越好,可预测性强,非常可靠
   2. 不常用的数据进行收集\汇总,不常用报警配置应当定时删除
   3. 没有被任何警报规则使用的信息应当定时删除
3. 保持系统相对独立,清晰简单,松耦合,使用持续很久不变的简单数据格式

长跑

1. 按季度进行紧急警报的频率统计,保证每个决策者都理解当前的运维压力以及系统健康状况
2. 设置一个可以实际达到的合理目标,保证监控系统可以支持快速的问题定位和检测

值班

职责以及轮值方式

1. 负责处理生产环境中即将或者正在发生的业务事故以及评审对生产系统的变更
2. 随时响应紧急问题
3. 由专门运维团队负责

工作机制

1. 接到报警，工程师必须确认ack
2. 必要时则需要升级
3. 需要有主on-call和副on-call,互为主副，互相值班，共同分担工作压力

工作平衡

1. 时间的平衡
   1. SRE团队50%的时间花在软件工程上，25%的时间来on-call，另外25%其他
   2. 假设每次on-call需要主副两名工程师，则SRE团队至少需要8名工程师；若每次轮值一周，则每个月需要轮值一次
   3. 避免夜间值班
2. 质量的平衡
   1. 当值工程师必须有足够的时间处理紧急事件和后续跟进工作
   2. 处理任何一个生产环境事件，包括事件根源分析、事件处理以及事后总结，至少6小时。因此每12小时轮值，最多只能产生两个紧急事件
   3. 超过上述标准，则必须采取修正措施
3. 补贴

安全感

1. 人类面临挑战的处理方式
   1. 直觉，自动化、快速
   2. 理性、专注、有意识进行认知活动
2. 保持当值工程师理性、专注
   1. 理性、专注时最好的方式
   2. 直觉很可能时错误的
      1. 直觉不基于明确数据支持
      2. 习惯性快速反应很可能导致灾难扩大
      3. 最理想方法时在足够数据支撑的事后按步骤解决问题，同时不停审视和验证所有假设

压力感

1. 当值工程师明确可寻求的外部帮助
2. 创建、维护和优化资源
   1. 清晰的问题升级路线
   2. 清晰定义的应急事件处理步骤
   3. 无指责、对事不对人的氛围
3. 处理复杂的、需要多个团队共同面对，或者经长时间不可恢复故障，应当启动正式应急事务流程
   1. 建立自动化平台
   2. 提供顺畅的职责交接流程和内部沟通渠道，专注解决问题
   3. 事后书写时间线和事件详细纪录

避免压力

1. 如何面对运维压力过大
   1. 错误的监控配置
      1. 狼来了
      2. 告警聚合
   2. 非SRE团队影响
      1. 和业务、运营团队设立共同的目标
      2. 极端情况，SRE团队可以选择停止支持某个业务，将其移交开发团队on-call，直到系统可以达到稳定性目标
      3. 超长时间不能实现稳定性目标情况下，应当将全部告警信息转交开发团队处理
2. 如何面对运维压力不足
   1. 长时间不处理生产环境会导致自信心问题，会在下一次问题发生时爆发影响
   2. 控制SRE团队大小，保证每个工程师每个季度至少参与on-call一次，最好两次，保证团队成员有足够的生产环境操作经验。

故障排查

概念

1. 反复采用假设-排除手段的过程
2. 通用流程

故障排查时运维岗位的关键技能

1. 故障排查过程时一个可以习得的技能，也是一个可以传授的技能
2. 新手不能有效进行故障排查的原因
   1. 对通用的故障排查过程理解有限
   2. 对故障发生系统不够了解
3. 对系统内部运行的了解往往限制了SRE处理系统问题的有效性，对系统设计方式和构建原理的知识是不可或缺的

造成低效的故障排查过程的原因

1. 对系统不够了解导致的定位、检查和诊断环节
2. 常见陷阱
   1. 关注了错误的系统现象或者错误的理解了系统现象的含义
   2. 不能正确修改系统的配置信息、输入信息或者系统运行环境
   3. 将问题归结为极不可能的因素
   4. 试图解决巧合的问题
3. 相关性不等于因果关系

故障报告

1. 每个系统故障都起源于一份故障报告
2. 有效的故障报告应该写清预期是什么，实际结果是什么，以及如何重现
3. 应当采用一致的格式，存储在一个可以搜索的系统中，例如bug记录系统
4. 使用定制表单或者小型web收集信息程序，同时自动发送和传递错误报告
5. 使用服务分析工具或者服务修复工具

故障鉴别与分类

1. 收到故障报告就要弄清楚如何处理它
2. 评估问题严重性需要运用良好的工程判断力并保持冷静
3. 恢复第一、排障第二
   1. 缓解系统问题是第一要务
   2. 如果有可能导致不可恢复的数据损坏，停止整个系统要比让系统继续运行更好
   3. 快速应对问题时扔应该及时保存问题现场，如服务日志等

检查验证系统状态

1. 监控系统记录的整个系统的监控指标时找出问题所在的关键
2. 日志则是另一个关键
   1. 日志应该清晰记录每个操作的信息和对应的系统状态
   2. 文本日志对实时调试非常有用
   3. 在日志中支持多级记录很重要，尤其时可以在线动态调整日志级别
3. 请求跟踪系统

诊断

1. 对系统设计的详细了解时针对目前系统出现的问题提出合理猜想的关键依赖
2. 没有领域知识情况下的通用手段
   1. 简化和缩略
      1. 检查各组件的链接或者中间传输的数据
         1. 将已知测试数据输入系统，检查是否能够正确输出
         2. 使用配套的测试用例
      2. 问题分解
         1. 多层系统中，从系统的一端开始，逐个检查每个组件直到系统底层
         2. 使用二分法确认问题所在，重复进行
   2. What Where Why
   3. 关注最后一个修改
   4. 有针对性的诊断

测试和修复

1. 建立相对较短的可能原因列表
2. 通过具体试验，确认和推翻所列假设
3. 没有预期效果
   1. 一个明确的负面结果可以给某些最难的设计问题画上句号
   2. 收集负面结果可以帮助其他人选择新的试验
   3. 公布负面结果
   4. 要对没有提到失败的设计文档、性能评估文档和短文保持怀疑
4. 治愈
   1. 生产环境中重现原因而明确证明故障原因时很困难的
      1. 有可能多种因素导致了问题
      2. 或许不再出现问题
   2. 应该将问题的定位、修复、如何防止再次发生记录下来，称为验尸报告

紧急事件响应

Things break,that’s life

1. 应对紧急事件的方式反映了一个组织的特质
2. 恰当的应急措施能力来自于平日的实战训练
3. 公司需要建立和维护一套完备的训练和演习流程
4. 确保当系统出现问题时，能有训练有素的专业人士严格按照灾难应急流程镇静及时正确的处理问题

常见紧急事故

1. 测试导致的紧急事故

2. 变更导致的经济事故

3. 流程导致的紧急事故

解决方案

1. 系统不但一定会出问题，而且会议人们无法想到的方式出问题
2. 所有问题都有对应的解决方案
3. 如果找不到方法，那就寻求帮助，做你需要做的一切事情，但是要快
4. 最高优先级永远时将手头问题迅速解决掉
5. 一定要写事后报告
6. 向过去学习，而不是重复它
   1. 为事故保留记录
      1. 历史就是让后人能够学习到其他人曾经犯的错误并从中汲取经验和教训
      2. 一定要诚实、一定要事无巨细
      3. 公布和维护事后报告
   2. 提出那些大的，甚至不可能的问题
      1. 停电了如何、水淹机房了如何、IDC下线了如何
      2. 面对这些问题，如何处理、找谁联系、谁来付钱、对应计划是什么
   3. 鼓励主动测试
      1. 面对失败，理论和实践是两个完全不同的邻域，直到系统真的失败，你并不真的了解它
      2. 在所有人手齐备的情况下，经过评审后，主动测试了解系统间的依赖，发现弱项并动手加固，显然优于将故障留到仅有值班人员的时候。

事后复盘

原因

1. 事故难以避免
2. 要修复根源性问题，如果没有一种方法从已发送事故中学习，那么事故就可以循环往复
3. 随着规模和复杂度增加，事故可能成倍增长，最终导致没有足够资源处理

复盘哲学

1. 书写事后总结不是一种惩罚措施，而是全公司的一次学习机会
2. 合格的事后总结的基本标准
   1. 用户可见的宕机时间或者服务质量降级程度达到一定标准
   2. 任何类型的数据丢失
   3. on-call工程师需要人工介入，包括回滚、切换用户流量
   4. 问题解决耗时超过一定时限
   5. 由人工发现的故障，而非监控或者告警系统
3. 对事不对人
   1. 关注如何定位事故根本原因，而非指责个人或者团队的错误或者不当举动
   2. 善意处理参与事件处理的人
   3. 逻辑性讨论事故处理过程中的错误
   4. 不能fix某个人，但可以改善系统和流程，以便做出正确的判断
4. 不能把事后总结当成例行公事，而要当成系统变得更可靠的机会

协作和知识共享

1. 事后总结可以基于模板或者协作工具
   1. 实时协作可以让写作过程更快的收集数据和想法
   2. 开放的评论系统，让大家参与进来，提高对事故处理细节的覆盖程度
   3. 邮件通知
2. 书写事后总结的过程还包括正式的评审和发布过程
   1. 首先内部发布并由资深工程师来评估完整性
      1. 最佳实践：所有的事后总结都需要评审
      2. 未经评审的事后总结还不如不写，鼓励定期举行评审会议
   2. 评审条件
      1. 关键的灾难数据是否以及被收集保持？
      2. 本次事故的影响评估是否完整
      3. 造成事故的根源问题是否跟踪深入
      4. 文档中记录的任务优先级是否合理，能否及时解决根源问题
      5. 这次事故的处理过程是否共享给了所有相关部门
   3. 更大范围内部传阅或者发送邮件列表

建立事故复盘的文化

1. 高级管理层主动参与协作和评审环节
2. 管理层负责建立对事不对人的氛围,具体过程需要由工程师自主驱动
3. 集体学习活动
   1. 本月最佳事后总结\每周一次新闻邮件\共享有趣并高质量事后总结
   2. 事后总结小组
   3. 事后总结阅读俱乐部
   4. 命运之轮:场景再现,一批工程师负责扮演其中的角色,并邀请当事人参与
4. 复盘的阻力来源于对投入产出比的质疑
   1. 逐渐引入事后总结流程,证明他们的价值,同时帮助确定具体书写事后总结的条件
   2. 确保对书面总结提供奖励和庆祝,要体现到个人绩效考核中
   3. 鼓励公司高级管理层任何和参与其中

跟踪故障

1. 为什么要跟踪故障
   1. 系统性的从过去发生的问题中学习是服务运维的必要手段，但事故复盘并不能覆盖所有场景
   2. 提高可靠性的唯一可靠方法是为系统可靠性建立基线并不断跟踪其改变
   3. 被动收集监控系统发出的所有告警信息，同时提供标记、分组和数据分析功能
2. 聚合
   1. 单独故障可能触发多个告警
   2. 由于虚假报警和漏报告警的存在，报警总量几乎无法减少
   3. 告警信息聚合可以有效消除重复告警
3. 加标签
4. 分析
   1. 系统性、周期性、广泛性的告警历史数据会给SRE团队带来莫大的好处
   2. 底层的分析高考计数和基本的汇总统计报告
   3. 按照团队、服务、时间分析趋势和模式
   4. 要对告警信息进行语义分析