SRE体系
2024-04-25 11:37:52 10 举报AI智能生成
SRE 技术管理体系
作者其他创作
大纲/内容
职责是通过软件工程来解决复杂运维问题
50%工作时间用于日常运维
50%工作时间用于开发工具解决问题
产品与研发: 专注于设计和构建软件系统
SRE: 专注于整个软件系统生命周期管理，包括从其设计到部署，历经不断改进，最后顺利下线
SRE 需要对问题特征有深入理解，系统性设计和实施解决方案，并抓住一段时间内的主要问题进行解决
SRE 需要在稳定性相关的方法论和实践方面不断迭代，自上而下设计，自下而上反馈，合理、可靠保障稳定性
SRE概念理解
用户价值持续交付
IaaS
PaaS
监控报警体系
自动化运维平台
基础设施建立
制订故障预案
容量压测
在线上模拟真实的故障，做线上应急演练，提前发现隐患
机房层面: 模拟断电的场景，看机房是否可以切换到双活或备用机房
网络层面: 模拟丢包或网卡流量打满
应用层面: 做一些故障注入，比如增加某个接口时延，直接返回错误异常，线程池跑满，甚至一个应用集群下线部分机器等
模拟故障发生场景，主动产生线上异常和故障
混沌工程是SRE稳定性体系建设的高级阶段，一定要是SRE体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才能考虑
混沌工程
运维手册沉淀
OnCall值班机制建设
Pre-MTBF无故障阶段
故障复盘
改进验收
Post-MTBF故障修复后
MTBF，Mean Time Between Failure，平均故障间隔时间
监控告警
舆情监控/业务反馈/客服反馈/用户反馈等
AIOPS
MTTI平均故障发现时间
日志分析
链路跟踪系统
逻辑推理
MTTK平均故障定位时间
容灾切换
服务限流
服务降级
版本回滚
MTTF平均故障修复时间
业务反馈/客服反馈/用户反馈
MTTV平均故障修复验证时间
稳定性的衡量标准
时间维度: 可用性=故障时间/周期内总时间
请求维度: 可用性=成功请求数/周期内总请求数
SRE采用粒度更加细致的请求维度
计算维护对象可用性的2种方式
操作系统层面: CPU使用率、load值、内存使用率、磁盘使用率、磁盘IO、网络IO等
应用运行层面: 端口存活状态、JVM的GC状况、请求返回的状态码、响应时延、QPS(属于容量指标)、TPS(容量)、连接数等
中间件层面: MySQL、Redis、MQ、分布式存储等组件的QPS/TPS/时延等
大数据层面: 大数据平台的批处理任务或流处理任务的吞吐率、及时率、准确率等
监控指标分类
问自己选择的指标能够直接标识这个系统实例是否稳定吗?
原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外
原则二：优先选择与用户体验强相关或用户可以明显感知的指标
Volume-容量指标
Availablity-可用性指标
Latency-时延指标
Errors-错误率指标
Tickets-人工介入次数指标
快速识别所维护对象的 SLI 指标的方法：VALET
如何选择适合的指标来衡量维护对象的稳定性
SLI(Service Level Indicator): 服务等级指标
稳定和创新(变更)的矛盾
SLO解决的问题
强依赖之间的核心应用，SLO要一致
如果某个核心应用错误预算消耗完，SLO没有达成，那整条链路原则上要全部暂停变更
设定原则
SLO1：99.95% (SLI为状态码成功率)
SLO2：90% (SLI为Latency <= 100ms的百分比)
SLO3：99% (SLI为Latency <= 300ms的百分比)
设定方法
合理设定SLO
在 SLO 落地实践时，我们通常就把 SLO 转化为错误预算，以此来推进稳定性目标达成
建议以4个自然周为一个统计周期
稳定性燃尽图
P0: 故障导致消耗错误预算的比例 > 50%
P1: 30% < 消耗的错误预算比例 <= 50%
P2: 20% < 消耗的错误预算比例 <= 30%
P3: 5% < 消耗的错误预算比例 <= 20%
P4: 消耗的错误预算比例 <= 5%
故障定级(量化管理)
原则2: 剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更
确定稳定性共识机制
基于错误预算进行告警
将SLO转化为Error Budget(错误预算)
1. SLO达成(Met)或未达成(Missed)
2. 人肉投入(Toil)程度高(High)或低(Low)
3. 用户满意度(Customer Satisfaction)高(High)或低(Low)
根据以上3个维度周期性的对SLO和错误预算进行合理的调整和优化
如何衡量 SLO 的有效性
SLO(Service Level Objective): 服务等级目标
向客户承诺一定程度的稳定性，未达到时需按照协议进行赔付
SLA(Service Level Agreement): 服务等级协议
维护对象分级分类(确定稳定性的主体)
主要方式: 监控和告警体系
辅助方式: 用户投诉、客服或业务反馈
如何发现
根据设定的SLO和错误预算，准确判断发生的问题是否是故障，并依据故障等级来决定响应时效
基于SLO(错误预算)的告警要及时响应
如何响应
确保关键角色在线: 关键角色主要指的是整个产品体系中的各个环节上能实际解决问题的人
建设方法
建设On-Call机制
故障发现
理念: 一切以恢复业务为最高优先级
故障处理不好的原因
故障指挥官(IC): 这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行
沟通引导(CL): 负责对内和对外的信息收集及通报
运维指挥(OL): 负责指挥或指导各种故障预案的执行和业务恢复
关键角色分工
反馈机制
故障处理(定位与修复)
目的: 从故障中学习和提升
故障认知: 故障是系统运行的常态，正常才是特殊状态
第一问：故障的根本原因有哪些？
第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？
第三问：当时如果我们做了什么，可以用更短的时间恢复业务？
黄金三问
要明确到底应该由谁来承担主要的改进职责
分段判定原则: 故障处理过程中出现的衍生故障要单独判定责任主体
让内部意识到稳定性和高可用一定是我们自己的责任，决不能依赖任何一个第三方
防止业务上云后，内部将大量的问题丢给外部云厂商去承担，导致内部员工失去对于稳定性的责任心
第三方厂商默认无责
如何明确故障的责任主体
关注的重点是鼓励改进，而不是处罚错误
落地改进
SRE是微服务与分布式架构的产物
云原生4要素: 微服务、容器、DevOps/SRE、持续交付
业务前台: 淘宝、天猫、支付宝...
业务中台: 用户中心、支付、商品、交易...
技术中台: 分布式架构、服务化、中间件、负载均衡、大数据、数据库...
基础设施: 服务器、网络、虚拟化...
技术架构举例
应用运维: 各种前台业务运维
技术保障: 工具平台开发、稳定性平台开发、监控告警体系建立
云平台: 数据库产品、消息队列产品、存储产品、虚拟化平台、容器平台
基础运维: 服务器管理、网络管理、DNS管理
组织架构举例
SRE组织架构
可控性
可观测
沉淀最佳实践
稳定性保障的3个抓手
SRE体系实践
职业：技术
0 条评论
回复 删除
下一页
