SRE体系
2024-04-25 11:37:52 11 举报AI智能生成
SRE 技术管理体系
作者其他创作
大纲/内容
SRE概念理解
SRE是Site Reliability Engineer的缩写, 直译为站点可靠性工程师
职责是通过软件工程来解决复杂运维问题
50%工作时间用于日常运维
50%工作时间用于开发工具解决问题
实践方式: SRE工程师和开发工程师轮岗, 即通过操作类事务积累问题经验，通过编码等方式提升问题的解决效率
SRE是一套保障服务稳定的体系化的方法, 也是一个体系化工程，它需要协同多个部门、多项技术, 形成一套稳定性体系, 让体系发挥力量, 告别只依靠单一技术来保障服务稳定的思维
SRE要认清这样一个事实前提: 100%稳定的系统是不存在的, 系统是肯定要出故障的, SRE要做的就是将故障的发生频率(提升MTBF)和影响程度(提高故障处理效率/降低MTTR)控制在合理的范围内
项目生命周期中，设计和构建软件系统的时间精力占比，通常是少于系统上线之后的维护管理, 需要考虑两种类型的角色
产品与研发: 专注于设计和构建软件系统
SRE: 专注于整个软件系统生命周期管理，包括从其设计到部署，历经不断改进，最后顺利下线
SRE 需要对问题特征有深入理解，系统性设计和实施解决方案，并抓住一段时间内的主要问题进行解决
SRE 需要在稳定性相关的方法论和实践方面不断迭代，自上而下设计，自下而上反馈，合理、可靠保障稳定性
稳定性的衡量标准
MTBF，Mean Time Between Failure，平均故障间隔时间
Pre-MTBF无故障阶段
用户价值持续交付
基础设施建立
IaaS
PaaS
监控报警体系
自动化运维平台
制订故障预案
容量压测
通过压测得到维护对象的QPS和TPS, 帮助设定容量目标
验证极端场景下, 限流/降级/熔断策略是否可以生效, 注意可能会被动的导致线上故障
混沌工程
在线上模拟真实的故障，做线上应急演练，提前发现隐患
模拟故障发生场景，主动产生线上异常和故障
机房层面: 模拟断电的场景，看机房是否可以切换到双活或备用机房
网络层面: 模拟丢包或网卡流量打满
硬件和系统层面: 故意把一块磁盘写满, 把 CPU 跑满, 把一台服务器重启等
应用层面: 做一些故障注入，比如增加某个接口时延，直接返回错误异常，线程池跑满，甚至一个应用集群下线部分机器等
混沌工程是SRE稳定性体系建设的高级阶段，一定要是SRE体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才能考虑
定期做故障演习: 选择凌晨, 业务量相对较小的情况下做演练
运维手册沉淀
OnCall值班机制建设
Post-MTBF故障修复后
故障复盘
改进验收
运维手册沉淀
MTTR，Mean Time To Repair, 平均故障修复时间
MTTI平均故障发现时间
监控告警
舆情监控/业务反馈/客服反馈/用户反馈等
AIOPS
MTTK平均故障定位时间
日志分析
链路跟踪系统
逻辑推理
MTTF平均故障修复时间
容灾切换
服务限流
服务降级
版本回滚
MTTV平均故障修复验证时间
日志分析
业务反馈/客服反馈/用户反馈
维护对象分级分类(确定稳定性的主体)
计算维护对象可用性的2种方式
时间维度: 可用性=故障时间/周期内总时间
请求维度: 可用性=成功请求数/周期内总请求数
SRE采用粒度更加细致的请求维度
SLI(Service Level Indicator): 服务等级指标
监控指标分类
操作系统层面: CPU使用率、load值、内存使用率、磁盘使用率、磁盘IO、网络IO等
应用运行层面: 端口存活状态、JVM的GC状况、请求返回的状态码、响应时延、QPS(属于容量指标)、TPS(容量)、连接数等
中间件层面: MySQL、Redis、MQ、分布式存储等组件的QPS/TPS/时延等
大数据层面: 大数据平台的批处理任务或流处理任务的吞吐率、及时率、准确率等
业务层面: 以电商为例, 有在线用户数、新注册用户数、下单数、交易数、支付数、成功率等
如何选择适合的指标来衡量维护对象的稳定性
问自己选择的指标能够直接标识这个系统实例是否稳定吗?
原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外
原则二：优先选择与用户体验强相关或用户可以明显感知的指标
快速识别所维护对象的 SLI 指标的方法：VALET
Volume-容量指标
Availablity-可用性指标
Latency-时延指标
Errors-错误率指标
Tickets-人工介入次数指标
SLO(Service Level Objective): 服务等级目标
SLO是SLI应达到的目标、SLO是建立稳定性标准化的基础、SLO是稳定性保障的共识机制, 可消除周边团队的误解
SLO解决的问题
成本和收益的矛盾, 要平衡成本和收益, 而不是一味的追求几个9, 得不偿失
科学的运维: 有了SLO, 就有了可量化的标准, 不用总怕出现故障, 只要故障在SLO范围内就是可接受的, 节省出精力用在更重要的事情上
稳定和创新(变更)的矛盾
合理设定SLO
设定原则
区分哪些是核心应用，哪些是非核心应用, 核心应用的 SLO要更严格，非核心应用要放宽
不应该以消灭故障为目的, 要接受故障的发生, 确保故障在SLO标准的范围内，高于这个标准会浪费人力和成本，低于这个标准就需要进行优化
强依赖之间的核心应用，SLO要一致
核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段, 避免由非核心应用的异常而导致核心应用SLO不达标
如果某个核心应用错误预算消耗完，SLO没有达成，那整条链路原则上要全部暂停变更
设定方法
SLO1：99.95% (SLI为状态码成功率)
SLO2：90% (SLI为Latency <= 100ms的百分比)
SLO3：99% (SLI为Latency <= 300ms的百分比)
Availability = SLO1 & SLO2 & SLO3, 只有三个SLI均达到其设定的SLO, 系统的稳定性才算达标
将SLO转化为Error Budget(错误预算)
可类比驾照记分制, 最大的作用就是提示你还有多少次犯错的机会
在 SLO 落地实践时，我们通常就把 SLO 转化为错误预算，以此来推进稳定性目标达成
通过SLO反向推导出错误预算(错误次数), 对于推广等特殊场景, 应合理放大错误预算值
建议以4个自然周为一个统计周期
稳定性燃尽图
故障定级(量化管理)
P0: 故障导致消耗错误预算的比例 > 50%
P1: 30% < 消耗的错误预算比例 <= 50%
P2: 20% < 消耗的错误预算比例 <= 30%
P3: 5% < 消耗的错误预算比例 <= 20%
P4: 消耗的错误预算比例 <= 5%
确定稳定性共识机制
建立稳定性共识机制一定要自上而下，至少要从技术 VP 或 CTO角色去推行, 自上而下推进周边团队或利益方达成共识
原则1: 剩余预算充足或未消耗完之前(也就是SLO达标的状态下)，其他团队或领导需要对故障的发生有容忍度, 不要因为出现故障就认为系统不稳定
原则2: 剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更
基于错误预算进行告警
也就是只关注对稳定性造成影响的告警, 有效做到告警收敛
当单次问题/故障消耗的错误预算达到 10% 或 20% 等某一阈值时，就意味着问题非常严重了, 要及时响应
如何衡量 SLO 的有效性
1. SLO达成(Met)或未达成(Missed)
2. 人肉投入(Toil)程度高(High)或低(Low)
3. 用户满意度(Customer Satisfaction)高(High)或低(Low)
根据以上3个维度周期性的对SLO和错误预算进行合理的调整和优化
SLA(Service Level Agreement): 服务等级协议
向客户承诺一定程度的稳定性，未达到时需按照协议进行赔付
故障发现
如何发现
主要方式: 监控和告警体系
辅助方式: 用户投诉、客服或业务反馈
如何响应
根据设定的SLO和错误预算，准确判断发生的问题是否是故障，并依据故障等级来决定响应时效
基于SLO(错误预算)的告警要及时响应
建设On-Call机制
目的: 及时发现故障, 并且在发现故障后能尽快进入故障处理的状态, 就是尽量缩短MTTI
建设方法
确保关键角色在线: 关键角色主要指的是整个产品体系中的各个环节上能实际解决问题的人
建立应急小组: 将各个环节的关键角色(或技术leader)拉到一个群, 有问题及时同步
OnCall名单: 每周更新轮班, 包括云厂商的OnCall名单
故障处理(定位与修复)
理念: 一切以恢复业务为最高优先级
故障处理不好的原因
故障隔离手段缺失, 比如没有有效的限流、降级和熔断等技术手段
关键角色缺失, 且没有决策、反馈和通报机制
缺乏故障演习, 导致故障隔离技术不生效和团队配合不默契
关键角色分工
故障指挥官(IC): 这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行
沟通引导(CL): 负责对内和对外的信息收集及通报
运维指挥(OL): 负责指挥或指导各种故障预案的执行和业务恢复
故障处理人员(IR): 参与到故障处理中的各类人员, 比如网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等
反馈机制
要求以团队为单位, 每隔 10～15 分钟做一次反馈
没有进展也是进展，也要及时反馈, 因为主管人员可能会根据反馈的情况做有损的服务降级决策等
故障处理过程中, 信息同步的及时和透明也非常关键，并且一些安抚措施也必须要快速执行到位
故障复盘
目的: 从故障中学习和提升
故障认知: 故障是系统运行的常态，正常才是特殊状态
黄金三问
第一问：故障的根本原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
注意: 具体开复盘会的时候，就是紧扣着这三问来进行的, 除此之外不允许出现相互指责和埋怨的情况，如果出现，会议主持者要及时控制并打断
落地改进
要明确到底应该由谁来承担主要的改进职责
如何明确故障的责任主体
健壮性原则: 服务自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等, 不具备此能力的相关方进行改进
分段判定原则: 故障处理过程中出现的衍生故障要单独判定责任主体
第三方厂商默认无责
让内部意识到稳定性和高可用一定是我们自己的责任，决不能依赖任何一个第三方
防止业务上云后，内部将大量的问题丢给外部云厂商去承担，导致内部员工失去对于稳定性的责任心
关注的重点是鼓励改进，而不是处罚错误
SRE组织架构
SRE是微服务与分布式架构的产物
云原生4要素: 微服务、容器、DevOps/SRE、持续交付
组织架构要与技术架构相匹配, 技术上如果朝着分布式和微服务架构的方向演进，必然会产生出类似的组织模式
技术架构举例
业务前台: 淘宝、天猫、支付宝...
业务中台: 用户中心、支付、商品、交易...
技术中台: 分布式架构、服务化、中间件、负载均衡、大数据、数据库...
基础设施: 服务器、网络、虚拟化...
组织架构举例
应用运维: 各种前台业务运维
技术保障: 工具平台开发、稳定性平台开发、监控告警体系建立
云平台: 数据库产品、消息队列产品、存储产品、虚拟化平台、容器平台
基础运维: 服务器管理、网络管理、DNS管理
稳定性保障的3个抓手
可控性
发布管理: 重点解决发布导致的人为稳定性问题, 包括发布前重要变更评审和发布中变更动作管理等
操作管理: 重点解决黑盒操作导致的人为稳定性问题, 包括统一集群操作入口、集群操作权限管理、集群操作审计等
设计评审: 重点解决软件系统设计阶段应用稳定性保障最佳实践, 包括集群方案评审和重要功能设计评审等
可观测
监控: 重点解决软件系统运行态的感知能力, 包括监控收集/可视化系统的搭建和维护等
日志: 重点解决软件系统的问题可排查能力, 包括日志收集/存储/查询/分析系统的搭建和维护等
巡检: 重点解决软件系统功能是否正常的主动探测能力, 包括巡检服务的搭建、通用巡检逻辑的开发维护等
告警: 重点解决异常的及时触达需求, 包括告警系统的搭建、告警配置管理、告警途径管理、告警分析、告警收敛等
沉淀最佳实践
从历史问题和业界最佳实践方面抽象出意识、流程、规范、工具，在系统设计之初就融入其中,
并在系统整个生命周期中加以使用，比如通过模板固化最佳实践
并在系统整个生命周期中加以使用，比如通过模板固化最佳实践
职业：技术
0 条评论
下一页
