行稳致远！五问金融企业SRE稳定性建设核心秘密_高效运维社区

陈刚高效运维社区 华佑高级咨询师，超过20年IT职位生涯，聚焦于技术运营及运维全领域。工作遍及电信，日本软件开发企业，美国电商公司，国内头部金融企业，10年以上运维团队管理经验。使用Python，Js，Go，Java等语言开发过各种IT应用。技术领域涵盖持续交付流水线，技术运营，K8s容器化集群技术转型和AI项目运维。已出版多本持续交付类书籍，GOPS 2018全球运维大会（2018深圳站）专题讲师。 一问：影响稳定性的罪魁祸首有哪些？ 01 二问：稳定性建设从哪里切入？ 02 三问：SLO如何与可观测能力打通？ 03 四问：SRE实践中如何协同故障应急？ 04 五问：如何系统化建设SRE稳定性能力？ 05 一问：影响稳定性的罪魁祸首有哪些？ 1-2当代IT系统的典型特征 大规模、分布式-------------------- 高频变更---------------- 从传统的单体式系统架构向分布式架构演进，系统规模快速增长 大量新业务上线，各种和业务相关的线上促销活动，都带来了高频的变更需求 技术栈复杂---------------- 大流量、高并发---------------- 随着开源工具发展，各种操作系统、应用中间件，虚拟化平台等领域新技术导出不穷 随着移动互联网的飞速发展，用户体量扩张，高并发压力增大 1-3影响稳定性的主要因素 没有变更就没有伤害 生产变更，容量不足，解决故障的快慢 SRE的经验表明,大概70%的生产事故由某种部署的变更而触发 变更风险 容量风险 最为常见的也是频率多就是变更带来的故障，日常变更多导致了各种各样的故障。 流量突然增加导致的故障。相对较少，但是影响是全局的，比如重大一些活动，微博的一些热点事情，都是容量和流量的变化导致的故障和影响。 基础设施，比如网络/IDC/DNS等等这些的故障，这种故障一般非常少，但是影响是非常重大的。 基础设施风险 1-3-1变更与发布控制 1-3-2容量管理实践 1-3-3基础设施高可用 二问：稳定性建设从哪里切入？ 2-1 SLO的VALET模型 SLA：服务等级协议 SLI：服务等级指标 SLO：服务等级目标 Service Level Agreement Service Level Indicator Service Level Object 达到或没有达到SLO之后的后果，商业承诺 该服务某项服务质量的具体量化指标 该服务的某个SLI的目标值或目标范围 可用性>99.99%（可用性）90分位RT < 100ms（延迟） 涉及后果、例如处罚赔偿SLA= SLO +后果 量化指标：可用性、延迟、容量等 黄金指标：Latency（请求延迟）、Traffic（流量）、Errors（请求错误率）、Saturation（资源利用率） 选择合适的SLI，设定对应的SLO •Volume容量（流量）：我的服务可以处理多少业务量？•Availability可用性：我需要时可以启动服务吗？•Latency延迟：使用该服务时，服务是否快速响应？•Error错误：使用该服务时是否抛出了错误？•Ticket故障单：服务是否需要人工干预才能完成我的请求？ 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 2-2-1 SLO的引入 2-2-2 SLO的运营 2-2-3 SLO的实时告警 采用多窗口多燃烧率（MWMB），它在告警及时性、告警重置恢复时间、误报、漏报都做了较好权衡 三问：SLO如何与可观测能力打通？ 3-1可观测数据MELT 3-3可观测体系应用场景 3-4可观测数据管理设计 解耦实时和历史数据管理 统一MELT数据生命周期管理 将实时数据管理和历史数据管理解耦。这种解耦保持了快速的接收率、对最近数据的低查询延迟，并将存储和访问历史数据的成本降至最低。 独特的实时和历史数据管理策略应在基于数据年龄的统一数据生命周期中进行管理。这样做可以抽象数据从实时存储到历史存储的移动，并降低在任意时间段透明访问所有数据的成本和复杂性。 为MELT数据查询提供单一接口 提供云原生分布式部署 可观测性查询通常需要来自不同MELT类型的数据。单个查询接口抽象了MELT数据的单个存储和处理需求，降低了编写这些查询的复杂性，并为跨存储策略的优化提供了机会。这一原理适用于类Polystore的可插拔存储引擎体系结构。 由于读写的高度突发性，系统的各层在设计上应该是分布式的和弹性的，这样系统就可以随着工作负载的变化而扩展。 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 四问：SRE实践中如何协同故障应急？ 4-1故障应急流程 4-2故障应急6把刀 重启是最廉价的服务恢复手段，其本质是初始化，从健康的初始状态重新来一遍。 回滚的本质是回到上一个稳定的版本、健康的状态。扩容的本质是短暂提高系统的资源池，不能作为常态，需要不断优化架构及代码。 切流最常见的是机房和运营商的切换。 降级解释一下就是降低标准来服务，故障期间可以用它来保命。 限流是辅助招式，可以和其他任何招式做排列组合，也可单独使用。 4-3-1故障应急协同机制A 什么样的问题需要通告？1，对业务有一定影响 2，基础设施，服务，平台一定程度不可用是否需要指挥官介入？1，故障复杂，单人短期无法解决什么时候需要进行故障进展同步？1，关键性发现2，关键性处理：回滚，扩容等3，影响范围扩大，需要进行升级处理4，业务恢复 五问：如何系统化建设SRE稳定性能力？ 5-1 SRE的范围 职责 保障基础设施的稳定性和可扩展性 方法 通过操作类事务积累问题经验，通过编码等方式提升问题的解决效率 工作内容 日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等 5-2 SRE的组织文化 高度合作 共同信念 SRE能够使组织在运营方面的关切保持一致。只有在产品运营、产品开发和产品管理之间建立起高度的合作，这才有可能实现。管理人员与软件交付组织进行协作，支持采用SRE作为主要的运营方式。这对于实现标准化，从而达到规模经济，以及为SRE的投资正名都是必要的。 SRE使用SLO来量化可靠性。一旦相应的错误预算耗尽，拥有服务的团队就要接受如何提升可靠性的培训。此外，待命人员也要被训练成高效的待命人员，这包括在停机时迅速采取行动以减少错误预算的消耗。停机后的事后分析会被视为组织的一个学习良机。 鼓励交流 共担风险 产品运营、产品开发和产品管理在SLI和SLO方面达成一致，SLI很好地从用户角度表述了服务可靠性，而SLO则代表了良好可靠性用户体验的阈值，以及在规定的SLO内运行服务所需的待命设置。这样会形成一个共同的决策，以判定何时在可用性上进行投资，何时在新特性上进行投资，以交付最大的价值。因此，投资的风险是共担的。 在组织内，SLO和SLA的定义是公开的，每个服务的SLO和SLA遵守情况的数据也是公开的。这会促成团队之间就依赖服务的可靠性，产生数据驱动的可靠性对话。SRE实践社区（communityofpractice，CoP）会在团队间交叉传播SRE的最佳实践，并在组织内举办关于可靠性的午餐学习会议。 接纳新颖的想法 失败时追根溯源 从正在进行的产品运营、停机和事后分析中获得新的见解，这会促成新可靠性特性的及时实施，并根据错误预算消耗率优先安排相关的工作。 停机后的事后分析会对发生的事情进行无责审查，以便于产生有用的学习成果，并在整个组织内传播。 病态型文化是以权力为导向的官僚型文化是以规则为导向的生机型文化则是以绩效为导向的 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 5-3 SRE的能力要求 协作 项目跟进、事故复盘、变更管理、平台运营、预算核算 技术支持 系统迁移、业务改造、技术推广、基础架构技术支持、应急响应、故障处理、成本优化 SRE实践 运行风限控制、服务分类分级、质量效能、巡检、预案建设及优化、容灾、容量管理、报警治理、SLO运营等 架构能力 高可用、多活、灾备、弹性伸缩、全链路、活动保障等 组织调整 轮岗、值班、OnCall等 5-4 SRE建设思路 5-5信通院SRE标准能力框架 Thanks DevOps时代社区荣誉出品