《SRE Google运维解密》散文

SRE

• 《SRE Google运维解密》 读书笔记
• 引言：曾经，觉得写接口改Bug不好玩了，就此带着热情走进了运维世界，探索这奇妙的监控、容器、自动化…。幸得茅哥的引路，让自己在运维的世界越走越远。近些天，我确定了新的方向，再次燃起我眼睛里无限探索的渴望；今天结束或许就是自己人生中最后一个运维相关岗位的工作日。假使将来有时间，我将把这些年的运维笔记整理升华发布于此。

认识运维

• 软件的生命周期

  • 需求分析 需求分析工程师、产品经理
  • 软件设计 架构工程师
  • 程序编码 研发工程师
  • 软件测试 测试工程师
  • 运行维护 运维工程师

• 研发工程师和运维工程师的矛盾

  • 研发是由功能性需求（通常与业务需求直接相关）驱动的。渴望随时随地发布新功能，没有任何阻拦。
  • 运维是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。希望一个东西在生产环境中正常工作了，就不要再进行任何改动。

• 运维基本工作：发布、监控、日志、告警

• 运维职责

  • 保障业务系统的稳定性。
  • 加快业务对应用的迭代周期，提升IT对业务的支撑能力。
  • 给业务提供资源保障。
  • 减少费用支出。

• 运行维护是软件生命周期中持续时间最长的阶段，运维工程师是一个非常重要的角色。

认识SRE

• 什么是SRE

  • 站点可靠性工程师（ Site Reliable Engineer ）
  • SRE的职责是运维一个服务，该服务由相关的系统组件组成，为最终用户提供服务（可以是内部用户或者外部用户）。
  • SRE的终极责任是确保该服务可以正常运转。为达成这个目标，SRE需要完成以下一系列工作：开发监控系统，规划容量，处理紧急事件，确保事故根源被跟踪修复等。

• 什么是LCE

  • 发布协调工程师（ Launch Coodination Engineer ）
  • LCE的职责是建立发布新服务检查列表，建立发布流程，变更管理，保障在快速迭代下服务的可靠性。

• 研发工程师和SRE工程师

  • 研发工程师：设计，构建软件系统。
  • SRE：专注于整个软件系统的生命周期管理，从设计一直到部署。

• SRE的基本工作

  • 深度参与开发阶段工作，对应用程序的设计实现方式、依赖库、运行时的资源消耗都有严格的规约。
  • 强调对问题和故障的自动处理，而非人工干预。
  • 按照SRE的约定，开发人员自行负责程序上线部署更新，毕竟开发人员对自己的程序更熟悉，易于处理程序上线过程遇到的问题。

• 优化工作

  • 可用性改进
    • 百分之百的可用性是不现实的，需要达到这个目标的成本通常远超于所能获得的价值，设置容错率，既保证用户体验又不影响创新和部署的速度。 SLO
  • 延迟优化
  • 性能优化
  • 效率优化
    • 如果能够通过密切关注一个服务的容量配置策略，进而改进其资源利用率，这可以非常有效地降低系统的总成本。

• SRE终极目标

  • SRE团队应该倾向于将基本的运维工作全部消除，全力投入在研发任务上。
  • 目标是整个系统应该可以自主运行，可以自动修复问题。
  • 终极目标是推动整个系统趋向于无人化运行，而不仅仅是自动化某些人工流程。

避免琐事

• 琐事

  • 手动的，重复性的，可以被自动化的，战术上没有持久价值的工作。

• 如何避免琐事

  • 负责运维的整个服务的团队成员必须要有足够的时间编程，否则他们会被运维工作所淹没。
  • 任何的手工操作必须控制在百分之50的时间内，至少保留百分之50的时间用于自动化开发上。

工程化

• 工程工作

  • 符合长期战略的，会对你的服务进行长久性改善的工作。
  • 通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好。
  • 例如：编写优化自动化脚本；监控部署，系统参数调优，架构设计优化；自动化重复工作。

• 工程化

  • 使用软件工程的方法解决复杂的运维问题
  • 最简化
    • 法国诗人 Antoine de Saint Exupery 曾经写道：不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美。这个原则同样适用于软件的设计和构建。例如API的参数最少化。
  • 模块化

自动化

• 自动化的价值

  • 一致性
  • 平台性（可以理解为普遍性，广泛适用，符合成本收益）
  • 修复速度更快，行动速度更快
  • 节省时间

• 如果我们持续产生不可自动化的流程和解决方案，我们就继续需要人来进行系统维护，如果我们需要雇佣人来做这项工作，就像是用人类的鲜血、汗水和眼泪来养活机器。这就像一个没有特效但充满了愤怒的的系统管理员的Matrix世界。

  • 一位负责Google数据中心集群上线流程的SRE Joseph Bironas

• 演变：自动化、系统化、自治系统

  1. 没有自动化
  2. 外部脚本进行自动化
  3. 外部通用脚本进行自动化
  4. 系统内部脚本进行自动化
  5. 系统内部机制自动化

监控

• 监控的目的

  • 对真实问题进行报警
  • 临时性回溯分析（例如刚刚延迟大幅度增加，有什么其它的现象也发生了）
  • 优化，对比服务更新前后的状态变化，新的版本是否让软件运行得更快？
    • 例如观察某一个参数改变后产生的变化（跨时间范围的比较）
  • 分析长期趋势，进行容量调整。
  • 检查资源使用量随着时间的变化情况，制定合理的资源变化策略。

• 4个监控黄金指标

  • 延迟
    • 例如 站点平均响应时间等
  • 流量
    • 例如 每秒钟HTTP请求速率等
  • 错误
    • 例如 5XX返回码等
  • 饱和度
    • 例如 内存剩余量、CPU利用率等等

• 注意：平均值、长尾值

• 简化，直到不能再简化

  • 一个季度内都没有使用到的指标可以评估是否删除掉
  • 这条告警是否可以通过自动化处理的方式解决
  • 收集的数据，却没有拿来 观察 或者 告警的可以评估是否删除掉

• 服务健康指标

  • 低级需求：能够正常对外提供服务。
  • 高级需求：SRE能够主动控制服务状态，而不是被动救火。

• 监控系统：数据收集、数据存储、数据可视化、告警、事故跟踪

发布工程

• 角色：

  • 统计发布速度…
  • 发布流程
    • 代码发布 和 配置发布 的解耦
    1. 发布
    2. 执行单元测试/压测/审查代码
    3. 编程成二进制文件
    4. 系统级集成测试部署
    5. 生产环境部署
    6. 生成改动列表报告

• 任何组织都需要根据自生情况，寻求适合自己的发布流程策略。

• 迭代与稳定

  • 定制SLO（服务目标水平），根据实际情况，进行调节
  • 如果研发迭代导致的时间超过了我们这个月需要达到的服务目标水平，则停止这个月份的发布
  • 敏捷性是建立在稳定性之上的

• 测试

  • 单元测试：某个函数、方法的测试
  • 集成测试：由多个单元测试组成
  • 系统测试
    • 冒烟测试：测试核心功能
    • 性能测试：
    • 回归测试：测试之前发生过的bug，保证它不会再次发生
  • 生产测试
    • 配置测试：保证生产环境的配置被正确地加载了
    • 压力测试
    • 金丝雀测试：升级部分部署节点，控制流量流入新版本和旧版本的比例

oncall

• 紧急事件

  • 东西早晚要坏的，这就是生活。
  • 故障演练，灾难恢复演习，假设可能的问题发生。

• 在进行oncall时，SRE需要动手运维系统，观察和调整系统的弱点，以及理解如何能大规模扩展这些系统。

• 根本性地解决问题：在每8～12小时的on-call期间，最多只处理2个紧急事件，这个准则保证on-call工程师有足够的时间根据紧急事件，正确地处理故障，恢复故障，撰写一份事后报告。

• 故障报告

  • 内容：事故发生，问题发现，解决的全过程，事故的根本原因，预防或者优化的解决方案。
  • 每份事故报告需要被他人审核。

• oncall-培训-例如维护 XXXXX 项目

  • 故障手册
  • 阅读并理解以下文档
    • 数据流程图（从客户端请求到结果返回）
    • 发布流程
    • 紧急情况的演练
  • 回答以下综合性问题
    • XXXXX 项目部署在哪个集群里，如何登入这个集群的生产环境
    • 有一条紧急告警”XXXXX 项目 5xx返回码数量1分钟内大于100条“，如何处理
    • 该项目的哪些方面可以简化或者自动化

团队管理

• 主动性SRE工作包括：软件自动化、架构设计咨询、发布流程协调等。

• 被动性SRE工作包括：在线调试、故障排除、处理on-call情况等等。

• 中断性工作会导致工程师的上下文切换（工作类型、工作环境的改变），犹如CPU需要为不同的线程计算进行切换。

• 计划性工作。

• 保持团队人员的多样性，系统工程师，软件工程师。注意团队成员间的沟通，防止认知偏差。

• 接手一个项目的运维，评审

  • 系统的体系结构和跨服务依赖
  • 指标的选择，度量，监控
  • 紧急事件处理
  • 容量规划
  • 变更管理
  • 性能：可用性、延迟和资源效率
  • SLO

• 牺牲工程实践而做琐事，会对SRE组织整体的发展造成损害。

K8S

• 为什么需要K8S

  • 将硬件和软件进行解耦
  • 业务团队运行软件服务时不需要担心硬件故障
  • 容器编排，自动重启，快速扩容，生命式管理服务，服务健康检查自动修复…

• 为什么需要request和limit

  • 一个缓慢的不断重启的Pod，要好过一个永远不重启一直泄露资源的Pod。

其它章节

• 负载均衡

  • 有质量的回复
  • 前端服务器负载均衡
  • 后端负载均衡
  • 应对过载
  • 处理连锁故障

• 分布式

  • 分布式共识机制

• 数据完整性

  • 交付一个恢复系统，而不是备份系统

当前问题

• 面临的挑战

  数据库瓶颈，顶配数据库空间仍然无法支撑业务发展。
  慢SQL数量爆发式增长，应用稳定性岌岌可危。
  # 全链路预警信息最多每天200+，系统隐患逐步暴雷。
  人工运维频率高，研发幸福感下降。
  长尾请求严重影响服务质量，5XX错误持续走高，影响客户体验。
  # 不一致性资源长期无法收敛，资损无法解决。 
  

1. 解决 创建用户，分配权限 琐事。

   • 自动化创建用户/权限分配系统
   • 核心是：通过调用jenkins、yearning等平台的接口，自动创建并且分配初始化权限。

2. 解决投放广告带来的流量激增

   • 广告系统对接K8S系统，当运营人员点击投放广告时；程序先自动触发Pod的扩容，当扩容完成后，再投广告，避免流量突增导致异常。

3. 网站崩了，为什么终端用户不能继续进行搜索游览商品（故障容忍度）

   • 当主库崩了，切换到从库，代码开启只读模式，web界面上方标注维护模式，用户只能进行不需要数据库insert和update操作的行为
   • 诺出现数据库insert和update操作的行为，则提示系统维护中，需要等待一段时间

4. 故障总结与新员工

   • 我们的故障总结不够详细
   • 如果我们的故障总结足够详细，那么在新员工进行on-call前，通过阅读之前的故障总结能获得一定的帮助。