SRE.md

[TOC]

SRE

什么是SRE

• SRE（Site Reliability Engineering，站点可靠性/稳定性工程师）。
• 与普通的开发工程师（Dev）、传统的运维工程师（Ops）不同，SRE更接近两者的结合，也就是2008年末提出的一个概念：DevOps。
• SRE模型是Google对Dev+Ops模型的一种实践和拓展。是一种对系统稳定性、高可用、团队持续迭代和持续建设的体系化解决方案。

心态和态度

谁适合做稳定性

• 业务团队挑选和培养最适合做稳定性的人的原则：
  • 不要用过于"老实"的人
    • 主动承担，对报警、工单、线上问题、风险主动响应，不怕吃苦。
    • 遇到问题与我无关、边界感太强的人，难以做好稳定性工作。
  • 原则上不要选择新人
    • 新人不熟悉业务，不了解上下游，容易导致线上风险无法被快速发现、故障应急无法迅速组织。
  • 不要用过于"老实"的人
    • “老实”：不去主动想优化的办法，不主动出头解决问题，但是很能吃苦，任劳任怨，也很能忍耐系统的腐烂和低效。
    • 无法主动提高系统稳定性，有的时候反而会给系统稳定性造成伤害（稳定性就像大堤，不主动升级，就早晚会腐烂）。

业务团队如何支持稳定性SRE人员

• 给资源
  • 稳定性是全团队的事情，需要能够调用团队一切资源参与。
• 给空间
  • 对于业务团队，一定要留给做稳定性的人足够的思考和上升空间，将稳定性与团队的技术架构升级、业务项目结合起来，共同推动。
  • 晋升困难，主要是因为在技术深度和业务价值两个方面，很容易被挑战。大公司已经建立SRE专门的晋升体系。
• 区分责任
  • 出现故障时，区分清楚责任，是稳定性工作没有做到位，还是单纯的业务变化。

开发和SRE的区别

• 传统的开发人员更多的倾向于是“bug/错误”，SRE倾向于是一种“风险/故障”。两者处理问题的方法不一样：
  • 开发：了解业务 -> 定位问题 -> 排查问题 -> 解决问题
  • SRE：了解业务归属 -> 快速定位问题范围 -> 协调相关人投入排查 -> 评估影响面 -> 决策恢复手段

SRE心态

• SRE不是打杂，不是背锅的。除了“做好”不出问题这条基线，还要做到下面3方面：

疑惑1：做好了是应该的，出了问题就要负责任

及时、快速的响应（第一要务）

• 遇到报警、工单、线上问题，能够第一时间冲上去，不要去问是不是自己的，而是要问这个事情的影响是什么，有没有坑，有没有需要优化的风险？这是对自己负责。
• 让你的老板第一时间了解风险的发生，一个好的团队leader，一定是对质量、稳定性和风险非常敏感的leader，所以，你要将风险第一时间反馈。这是对老板负责。
• 反馈技巧：
  • 尽快告知当前告警已经有人接手，是谁接手的，表明问题有人在处理了（这一步叫“响应”）。
  • 组织人员，快速定位问题，告知问题初步定位原因。（这一步叫“定位”）
  • 初步影响范围是什么？给出大致数据。（这一步方便后面做决策）
  • 有哪些需要老板、产品、业务方决策的？你的建议是什么？（这一步很关键，很多时候是：两害相权取其轻，你的评估和建议，直接影响老板的决策）
  • 当前进展如何，是否已经止血？（这一步是“恢复”，要给出“进展”，让决策者和业务方了解情况）
• 作为SRE，风险和进展的及时组织和通报。如果你响应了，没有同步出来是开发者（Dev）的思维。

把机制建立好，切实落地

• “稳定性从来不只是稳定性负责人的事情”，是一个团队每一个人的事情。
• 不需要一个人扛下所有的“英雄”行为。
• 落地一套稳定性机制体系
  • 稳定性意识
  • 报警响应机制
  • 日常值班机制
  • 复盘机制
  • 故障演练机制
  • 故障奖惩机制
  • 大促保障机制
• 报警要更加准确和完善，减少误报和漏报；产出自动化机器人；建立值班制度，让每人都参与进来，既让大家熟悉业务，也提高了稳定性意识。

主动走到最前线

• SRE不是后勤保障，SRE需要冲锋陷阵：
  • 梳理。主动梳理团队的业务时序、核心链路流程、流量地图、依赖风险，通过这个过程明确链路风险，流量水位，时序冗余；
  • 治理。主动组织风险治理，将梳理出来的风险，以专项的形式治理掉，防患于未然。
  • 演练。把风险化成攻击，在没有故障时制造一些可控的故障点，通过演练来提高大家响应的能力和对风险点的认知。
  • 值班。不能仅仅为了值班而值班，值班不止是解决问题，还要能够发现风险，发现问题之后，推动上下游解决，减少值班中的重复问题，才是目标。
  • 报警。除了前面说过的主动响应之外，还要经常做报警保险和机制调整，保证报警的准确度和大家对报警的敏感度。同时也要做到不疏忽任何一个点，因为疏忽的点，就可能导致问题

疑惑2：稳定性总是做擦屁股的工作

• 稳定性是有前瞻性的，稳定性是有价值的。
• 走到系统的前面，看到系统的方向，做的是探索性工作：
  • 不能只做当下，要看到未来的风险，善于总结
    • 在系统健康时、出现隐患时发现问题；在系统发生问题时快速解决问题。
  • 自动化、系统化、数据化
    • 常常思考产品和系统哪里有问题，如何优化，如何体系化？
    • 常常思考有没有更好的办法，有没有提高效率的办法？
    • 常常思考如何让稳定性本身更加有价值，有意义？
    • 自动化
      • 自动是指能够系统能够对一些异常自动恢复、自动运维。包括兜底、容灾。包括智能化、机器人和规则判断。
      • 自助是让你的客户自己动手，通过提供机器人，自动识别订单类型，自动排查订单状态和节点，自动告知服务规则特征，自动匹配问题类型给出排查结果或排查过程等。
      • Google SRE设置了一个50%的上限值，要求SRE人员最多只在手工处理上花费50%的时间，其他时间都用来编码或者自动化处理。
    • 系统化
      • 通过监控体系、链路风险、演练体系发现问题。
    • 数据化
      • 数据驱动：包括日志标准化和错误码标准化，能够对日志和错误码反馈的情况进行量化。
      • 数据对账：包括上下游对账、业务对账，能够通过对账，保障域内数据校准。
      • 轨迹跟踪：包括变更轨迹和数据轨迹，目标是实现数据的可跟踪，和变更的可回溯、可回滚。
      • 数据化运营：主要是将稳定性的指标量化，比如工单解决时间、工单数、报警数、报警响应时间、故障风险数、代码CR量，变更灰度时长等，通过量化指标，驱动团队同学建立量化意识，并且能给老板一份量化数据。

疑惑3：稳定性似乎总是新人的垃圾场

• 对于稳定性新人，一定要优先考虑如何响应问题，而不是如何解决问题。
• 稳定性从来都不是简单的，他的关键，是要做细，这需要细心和耐心。
• 稳定性不是一个人的事情，要团结团队内的同学，上下游的同学。
• 3张图
  • 系统间依赖图（也包括业务时序，熟悉业务流程）
  • 流量地图（知道上下游系统，团队内系统的流量关系和流量水位，也同时把控系统架构）
  • 系统保障图（知道稳定性保障的步骤和打法）
• 3张表
  • 机器资源表（做到占用多少资源，了然于胸，团队需要时能拿得出来）
  • 异常场景应急表（出现问题时知道怎么应对，演练知道哪里容易出问题）
  • 业务近30日单量表（知道哪些业务影响大，哪些业务是重点）

监控

• SRE人员的一双敏锐的“眼睛”——无论是要快速响应，还是要发现风险，都能快速发现问题，这就是“监控”。

监控的5个维度

• 监控的核心目标，是快速发现“异常”。

监控大盘

• 在关键时期，在一张图上能够看到所有的关键指标。
• 大盘的key point应该是“直观简洁、指标核心、集中聚焦”。在大盘上，我认为要包括以下要素：
  • 最核心业务入口的qps、rt、错误数、成功率，从这个维度可以看到入口流量的大小和相应时间，成功率。这一点，是在知道入口的健康情况。
  • 错误码top N，这个维度可以看到系统运行过程中最核心的错误，快速直观定位问题原因（这个需要打通上下游错误码透传）。这一点，是在快速知晓问题出在哪里。
  • 按业务维度（业务身份、行业、仓储、地区等，根据实际需要决定）分类统计计算的单量、或分钟级下单数量，用于确定核心业务的单量趋势。这一点，只在知道自身业务的健康情况。
  • 核心下游依赖接口、tair、db的qps、rt、错误数、成功率，需要注意的是，这个一般比较多，建议只放最核心、量最大的几个。这一点，是在知道下游依赖的健康情况。
  • 其他影响系统稳定性的核心指标，如限单量，核心计数器等，根据各个团队的核心来决定。这一点，是在个性化定义关键影响点的监控情况。

避免监控信息爆炸

• 设置专门的唯一的钉钉报警群
• 报警留底：可以有地方可以查到历史报警
• 日常报警数量限制：报警数量不能太多

有效发现监控问题

• 像刷抖音一样刷监控群和值班群。

故障应急

系统可用性的定义

• 影响系统可用性的指标包括2个方面：MTTF（不出故障的时间）和MTTR（出故障后的恢复时间），所以，要提高系统可用性，要从2个方面入手：

  • 尽量增加无故障时间
  • 尽量缩短出故障后的恢复时间

• 不断的发现风险，治理风险，才能防止系统稳定性腐烂，才能增加无故障时间。

• 把功夫花在平时，防止出现故障时的慌张无助。平时的功夫，主要就是场景梳理和故障演练。

场景梳理

• 把可能出现故障的核心场景、表现、定位方法、应对策略梳理清楚，做到应对人员烂熟于心，为演练、故障应急提供脚本。

故障演练

• 演练对故障应急无比重要。
• 不要进行无场景演练
• 不要无意义的提速演练
  • 针对性的对业务进行演练
• 各个SRE同学，不管大的政策怎么样，还是要关注团队内部的场景本身：
  • 对于系统性故障注入（load、cpu、fullGC、线程池等），直接套用集团的mk注入即可。
  • 对于服务型故障注入（下游异常、超时，接口超时、限流），mk也有比较好的支持。
  • 对于订单异常型故障注入，要自主开发较好的错误订单生成工具，注入异常订单，触发故障报警。
  • 对于调度、积压型故障注入，要关注schedulex、异步消息的故障注入方式，同时防止积压阻塞正常订单影响真正的线上业务。

故障应急过程

• 冷静。作为SRE，首先不能慌，没有什么比尽快定位和止损更重要的事情。
• 拉电话会议同步给大家信息。记住，在出现故障时，没什么比电话会议更加高效的沟通方式了。
• 组织大家按照故障场景梳理的应对方案进行应对，如果没有在故障场景列表中，一定要组织最熟练的人员进行定位和恢复。
• 故障过程中，对外通信要跟团队和老板统一评估过再说；
• 处理故障过程中，要随时组织同学们进行影响数据捞取和评估，捞出来的数据，要优先跟老板、业务熟练的同学一起评估是否有错漏。
• 在处理完故障后，要及时组织复盘（不管GOC是不是统一组织复盘，内部都要更加深刻的复盘），复盘流程至少包括：详细的时间线，详细的原因，详细的定位和解决方案，后续action和改进措施，本次故障的处理结果。

与兄弟团队的关系

• 如果兄弟团队发生故障，一定注意：
  • 不能嘲笑别人，看笑话。
  • 不能当没事人，高高挂起，要检查自身。
  • 不能话说的太满，比如说我肯定没故障。

资源管控

• 作为一个SRE，在资源管控领域，一定要保证自己域有足够的机器，同时又不会浪费太多。
• 核心应用，应该控制load在1-1.5左右（日常峰值或A级活动场景下），控制核心应用在10个以内，非核心应用，应该控制load在1.5-2左右（日常峰值或A级活动场景下）。
• SRE要自己梳理一份资源表，表中一方面要明确有哪些资源，余量多少，另一方面要明确资源的当前水位、压力。
• 比如机器资源，要关注当前机器数、额度、load；再比如对数据库资源，要关注数据库的配置、空间、日常和峰值qps、单均访问量（创建一个订单，要读和写DB多少次，这一点很关键）。