基于实践总结运维支撑观念SRE

结合SRE理念的运维实践总结，给团队培训要点。导图从背景、运维职责、文化特质、可靠性、故障处理、轮值、上线/变更、支撑组织、文档几个方面作了介绍。

运维支撑理念

• 背景
  • 敏捷 vs 稳定
  • 研发 vs 运维
  • 项目数量 vs 人工开销
  • 总是客户或领导告诉我们发生故障？
  • 故障的复杂性，如何收敛？
  • 同样的故障只是换了事件和场景发生？
• 运维职责
  • 可用性改进
  • 延迟优化
  • 性能优化
  • 效率优化
  • 变更管理
  • 监控
  • 容量规划和管理
  • 紧急事务
  • 轮值
• 文化特质
  • 确保长期关注研发工作：Google 将 SRE 团队的运维工作限制在 50% 以内，剩余的时间花在研发项目上。你需要拥有上帝视角，才能更好的解决问题。
  • 天然排斥重复性、手工操作；以消除重复手工动作为荣。崇尚技术能力，快速开发替代手工操作。
  • 应急事件处理：**自愈是目标**，任何需要人工操作的事情都只会延长恢复时间。要牢记2句话： 1. **一个可以自动恢复的系统即使有更多的故障发生，也要比事事都需要人工干预的可用性更高。** 2. **一个缓慢的不断重启的实例要好过一个不重启一直泄露资源的实例。**
  • 以事后总结为荣，无论有没有触发告警
  • 对事不对人，不管是沟通、讨论，还是故障总结
  • 过多告警等于没有告警
  • 无效备用不如没有备用。这意味着什么？备用不是摆设，要演练
  • 运维开发也是开发，所以，开发里的方法论同样适合：不要重复造轮子。 在巨人的肩膀上，才有可能看的更高，所以不要重复造轮子，而是学会基于轮子去造车。
  • 有本营销学的书叫《hope is not a strategy》（希望不是一种策略），理性思考，主动改进。 任何工作都有科学性，运维也不例外。故障的容忍度、测试的深度、发布频率、金丝雀持续的时间等，这些决定不应该受办公室政治、不理智的恐惧、一厢情愿的希望所驱使。
  • 既然厌恶变更死路一条。拥抱风险，拥抱变化，适应敏捷。
  • 持续改进。
    • 把可靠性视作最基本的功能。
  • 思考从根本上解决问题，**「救火很重要，但是疲于一直救火，会阻止你去思考该如何从本质上去解决问题。」**， 扩容扩容扩容，重启重启重启
  • 如果系统正常运行中需要人工干预，应该将此视为一种bug。正常的定义会随系统进步而改变。
  • Cheng：如果有大量的监控结果需要主观判断分析原因和复杂响应，设计不佳，应重构，好的告警，应该能够直击问题，从而快速响应。
  • Cheng: 切记故障处理原则，**先抢通，再修复**
  • 拥有无指责的文化，专注于真正的根源并解决系统性的问题，或者“责备和羞耻”的文化，出错时人们会因此受到惩罚？出错时对问题个根因分析透彻，有建设性改善，应该鼓励，而不是指责。当然不包括低级人为因素的问题。
  • 痛苦的事情频繁做，故障演练不是走过场。
  • 好的运维要善于想象系统如何失效。
    • chaos工具
  • 注意：任何运维故障，运维的领导必须是第一个知道的人，如果他从别的人或者部门中知道这个故障，那么就很被动，而且是故障处理人失职表现。
• 可靠性
  • 把可靠性视作基本功能。
  • > Cheng: 不要在某些方面的可靠性上追求100%，不管是硬件的或者软件的，因为我们的资源是有限的。换个角度，应该思考，在合理SLO下，如何及时发现问题（监控系统和体系），发生故障后怎么办？ 当然有些系统除外，比如核电站控制系统，登月系统，导弹系统
  • 故障预算：故障预算的概念是思考问题方式的改变，有故障预算表示故障是不可避免的，故障是创新过程的一个部分。确保在保证SLO下的最大迭代速度。可靠性指标与投入呈指数分布关系，你需要思考的是，花费巨大的精力将系统变为 100% 可靠是否能为用户带来实质意义上的好处？
• 监控系统
  • 一个监控系统应该只有三类输出：**紧急警报、工单、日志**
  • 记住：> Cheng: 监控的目的不是产生稳定监控量，告警过多/告警风暴=没有告警
  • > Cheng: 最大化的降低误报率，假阳性 - 是一种无谓的开销，去毛刺 **对于那种多次发出报警但是没有人响应的报警，删除它或许不是一件坏事情**
  • > **Cheng：如果有大量的监控结果需要主观判断分析和复杂响应，设计不佳，应重构，好的告警，应该能够直击问题，从而快速响应。**
  • 四个黄金指标：延迟、流量、错误/失败、饱和度。业务方向的监控常常是必要的
• 故障处理
  • 关于故障的几个观念
    • 事物总要坏，故障总要发生
    • **系统正常，只是该系统无数异常情况下的一种特例。
    • 在我们故障处理过程中，我常常问的第一句话是，影响了多少用户。 - 用户是那个给业务带来增长和收入的因素，所以为什么要首要的是恢复业务，及时止损。 - 关系到响应等级。
    • > Cheng: MTTF,MTTR,MTBF所以我们可以看到 MTBF = MTTF + MTTR，因为MTTR通常远小于MTTF，所以MTBF近似等于MTTF；因此我们平时常用的衡量指标就是MTBF和MTTR。 衡量稳定性的指标明确了，那我们稳定性的目标也就明确了：提高MTBF、降低MTTRF、重点是MTTR，初次，我说故障发现时间也很重要，MTTD(discovery)，阶段性每次关注，也许以后不用关注
    • 故障排障过程被定义为反复采取假设-排除手段的过程。大致就是通过观察系统的监测指标和日志信息了解系统目前的状态。再结合我们对于系统构建的原理、运行机制，以及失败模型的了解，提出失败原因。不轻易下结论，用事实佐证。
    • **高等级故障，你的第一反应可能是立即开始故障排查过程，试图尽快找出问题根源，这是错误的！不要这样做。 定位问题的过程中，最重要的不是排障，是如何尽最大可能让系统恢复服务。** 定位问题时，应及时**保存问题现场**，比如服务器日志，以便以后进行根因分析。
    • **关注最近一次变更**
  • 事后总结
    • 故障复盘的核心：从故障中学习和提升！**拥抱故障，卓越运维**
    • 故障复盘的教训：故障根因往往不止一个，聚焦引起故障原因都是哪些，是否都有改进空间。
    • 总结的条件
      • - 二级及以上故障 - 数据丢失 - on-call需要人工介入的回滚、流量切换等 - 解决耗时过长的 - 监控问题（人工发现，而非告警发现）
    • 故障**复盘**三问
      • 1）第一问：故障原因有哪些？
      • 2）第二问：我们做什么，怎么做才能确保下次不会出现类似故障？
      • 3）第三问：当时如果我们做了什么，可以用更短的时间恢复业务？（这点非常重要）。
    • 故障判定的三原则
      • 1）健壮性原则：每个组件自身要具备一定自愈和高可用能力，而非全部由下游依赖方兜底；
      • 2）三方默认无责：**对内谁受影响谁改进，对外推进第三方改进**(稳定性要做到相对自我可控，而不是完全依赖外部)；
      • 3）分段判定原则：对于原因较复杂或链路较长的故障，建议分段评估，不同段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。
    • 注意事项：对事不对人，不允许出现互相指责和埋怨甩锅。故障复盘的核心是找到原因并加以改进，落地优化。
  • 故障报告
    • CG：确定了一个问题根源时，应该将系统**问题位置，如何定位，如何修复，如何防止，待办事项**总结下来。 - 基本信息：发生时间，跟踪人等 - 事故影响 - 根因分析 - 触发条件 - 解决方案 - 待办事项 - 经验教训 - 做的好的 - 需要改进的 - 时间线 - 标注出发现时间
      • > Cheng： 做的好的？做的不好的？ - 监控是不是发现、及时、到位？误告警？ - 应急响应有没有发挥作用？有没有可以完善的地方？ - 指挥调度有没有问题？ - 远程不可访问了怎么办？带外访问通道？
  • 响应机制
    • 如果事前没有对可能发生的紧急事故进行演习，事故发生时，一切管理理念都不起作用。 > Cheng：紧急事件必定是不常发生，不常处理之事，必不擅长。所以要建立应急流程，并不断演练熟悉。 把chaos融入故障演练中。
    • 职责
      • - 事件总控人：组织，协调 - 事件处理团队：执行，解决，由实际处理人组成 - 发言人：向相关方发布故障处理进展，确保相关方都知道事故处理进展 - 规划负责人：为处理团队提供支撑工作？bug记录、职责交接安排、处理过程特殊操作的记录等
    • 通知中心：受到事故影响的部门或者负责人需要实时跟事故总控负责人联系 **实时事故状态文档**：确保关联的每个人知道事故的进展【示例】，事故总控人最重要的职责就是维护事故的实时文档。最好可以多人同时编辑。关注共享范围扩大化。
    • > Cheng：以上职责至少需要，总控、处理团队、发言人；总控和发言人可以合设。我们以前要求高等级故障集中处理，鼓励面对面集中处理（war room），考虑到跨团队和故障发生时间等因素，看起来是有难度的，至少确保以上职责人员紧密连线、信息共享、及时跟进。可以“拉群”讨论处理，IRC。 思考：**故障演习**时，如何团队贯穿，内外部？
  • 建立跟踪故障
    • - 每次 on-call 轮值发生的报警次数是多少 - 上个季度中可操作的报警和不可执行的报警的比例是多少 - 哪个消耗的人工最多等 - 能够对历史数据进行定量的分析，找出可优化的方向，这些是将来可改进的基本点 。 以上最好能够从系统直接统计。
• 轮值
  • on-call度量
    • - 每个工程师呼叫响应数量
    • - 每个工程师被呼叫时间间隔
    • - 非工作时间接收量
      • - 团队每周>1，负载过高
  • - 应该解决的问题
    • - on-call团队成员如何轮转？
    • - 每次轮转持续多久？
    • - 某个工程师没响应会发生什么？
    • - 某个工程师无法胜任怎么办？
    • - 同时有几个工程师处于on-call状态？
    • - 多名on-call工程师如何分工？
    • - 如何处理不可预见的事故？
    • 这些问题我们又没思考过？
  • - 目标：
    • - 一个成功的事故响应系统的目标很简单 ：先于客户影响前发现事故，最理想的情况是发现并修复它，即自愈。
    • - so，必须有监控和告警
  • - 故障发生停止一切手头故障项目其他工作，该策略强迫我们停止对该服务的任何新工作，直到我们修复导致该事故发生的根本原因或提出相应的减缓措施。 - 拉灯
  • - on-call手册
• 上线&变更
  • 上线是运维支撑工作的缘起
  • 上线节奏，理论上讲测试系统和运维方案做的足够好，可以随时发布。 考虑到现状（代码质量、环境配置、测试深度、运维方案、发布时间等限制），不得不让这个节奏保持适度。 但，总体上我比较倾向于尽量快的发布，这可以促进反馈调整加速，可以用发布失败预算来做调节器。
  • - 好的发布流程，需要反复实践来提升速度和可靠性。 - 谁来组织发布？研发？运维？很多公司由SRE或研发人员兼。 大的软件公司，LCE（launch coordination engineering）发布协调工程师干这个事，这个挺清晰： - 审核，gate，提供发布可靠性的建议 - 协调 - 跟进，发布过程的所有技术问题 - 反馈 - 总结最佳实践，给SRE和开发提供发布培训 我们是支撑兼了这个角色，支撑为什么可以牵头组织上线？ - 审核、协调、跟进、反馈都是可以的，但程度较浅。理念要有 - 支撑是第三方，跳出运维和研发。 - 流程就是流程，支撑不深入运维和研发细节，有利于客观的执行流程。 - 支撑是内外桥梁，熟悉应用本身和常见故障的处理，上线后可以更好的做UAT。 - LCE，经验/跨职能的视角/客观性，流程考虑可靠性，往往和效率矛盾，不断优化发布流程。
  • 变更管理必须思考的关键问题： - 灰度方案？用户影响最小化 - 问题检测？第一时间捕获失败 - 回退方案？预设失败怎么办 - 其次才是其他非功能性特性，安全、容量、效率、利用率、性能。。 分析发布的每一步，问可能故障&备用方案。
• 支撑组织
  • - 建立一线、二线甚至三线支撑团队，一线一般为7x24小时值班的人员； - 二线一般是资深工程师，或者是对应的应用开发/测试同学； - 三线一般是主管或者是外部的厂家，如涉及硬件、IDC机房等相关服务方
• 文档
  • 文档标准
    • 何为好的文档
  • 内容
  • 建立运维手册，playbook