2-4 武安闯-SRE实践：从SLO工程到GOC体系建设

SRE实践：从SLO工程到GOC体系建设 哔哩哗哩SRE负责人/武安闯 SRE实践： 从SLO工程到GOC体系建设 武安闯哔哩哔哩／SRE负责人 对SRE高可用架构、技术风险体系建设、质量运营和组织转型有刻的建设实践和思考主导B站SRE转型、高可用架构、故障快恢、SLO工程、容量管理体系、多活容灾等专项从0到1带领B站运维向SRE转型，建设站可靠性体系当前专注SRE可靠性体系规划建设和落地实践 01SLO工程方法论 目录 SLO实践整体框架 SLO度量实践与运营 03 SLO度量、告警治理、风险发现与协同、安全变更 SLO价值之再升级：GOC建设故障定义、发现、协同、定位、快恢、风险跟进 04 SLO工程方法论 SLO：指定了服务可靠性的目标水平，是做出可靠性决策的关键数据，是SRE实践的核心 工程缺，时间投入到重要服务的核心问题上SLO品做出工作优先级非宇和可靠性相关工作的关划工作按照SLO来开展，确保SLO是合理的没有SLO，就没有SRE Gdevops全球敏捷运维峰会北京站 SLI：服务质量指标 总体思路 SLI规范 SLI实现 对用户重要的服务能力的评估，与其测量方式无关C 好的事件数量除以总事件数量 SLI具体的测量方法 成动的请求数/总请求数（成功率）接方结果数/接忘结果总数，包括邮正带陆级的慢结果请求延退小于100ms的成功请求数/总请求数良好分钟数／总分钟数 例：可用性 移动端埋点上报SLB, API GW Metrics服务Metrics服务日志 单个SLI规范可具有多个SLI实现 质量（能否捕获用户体验)漂盖范由（能否捕获所有用户体验）实现成本 SLO：服务质量目标 错误预算策略 错误预算 SLO 错误预算策略：服务在给定时间段内消耗全部的错误预算时必须采取的具体操作 SLO定义原则： 错误预算：100%-SLO 在SLO日标内，某个时间留口所允许的错误请求数量或不可用时间：SLO：99.9%，每时刻允许0.1%的请求错误/每月充许x个错误SLO：99.9%，每个月允许43分钟服务完全不可用错误预算对风险识别、可靠性决策至关重要 保持简单易理解，避免绝对的目标，如100%，SLO精简，3-5个即可·不追求完美，逐渐优化 开发团以专注于可靠性需求，直到系统处于SLO范国内功能选代推退，可靠性bug放在首位：冻结生产的变更，直到有预算来恢豆变更 既可由错误预算策略驱动也可由问题/故障驱动效果优先，不拘泥于形式 SLO商口：年．半年，季度、月 滚动商口与用户体验更接近口历窗口与业务计划和项目T行更加照意世结合在一起获得所有利益相关者同意 Gdevops全球敏捷运维峰会北京站 SLO告警 消耗速率 多消耗率告警（长短窗口） 错误预算多窗口 短窗口发现严重问题长窗口发现低速流血问题1小时消耗月度2%的预算消耗：紧急报誉30g*2%=14.4h：14.4小时的客口14.4h/h=14.4：14.4倍消耗速率 相对于SLO，服务消耗错误预算的速度 %666:01S 年留口的错误预算是：526min月窗口的错误预算是：43.8min，526分钟平刚到年，每时每刻充许0.1%的错误率1个月持续0.1%错误率正好可以消托完该月窗口内的所有错误预算 基准错误率=1-SLO·消耗速率=错误率/基准错误率 案例：99.9%可用率的SLO.30d离口的错误预基准错误率：0.1%，比时消耗迪率为1 6小时消耗月度5%的预算消耗：紧急报警 C6V9E49E=%5+POE：36h/6h=6:6倍的耗速率 3天内消耗月度10%的预算消耗：故障工单 ·30d*10%=3d;3天的离口3d/3d=：1倍率 总结：SLO实施流程 SLO定义 避免艳对，保持简单，逐渐优化，3-5个SLO即可全年可用性>=99.99%99%的请求=200m5，90的请求100m5可以在不同的时间商口上定文SLO比如一个月或一个季度获得关键的利益相关者认可和批准 基于SLO，得出时间窗口内的允许错误预算时问内错误预算消耗殆尽，制定错误预算执行策略如：开发团以专注于可靠性问题，冻结生产系统的变更 SLI规范与实现 SLO报务 仪表盘和报表 可用性报警准确率最高多消耗率（错误率/SLO基准错误率）报警多时间窗口 SLO达成情况SLI趋势图、仪表盘、错误预算消耗SLI季度，年度运营报表 Gdevops全球敏捷运维峰会北京站 SLO整体实践框架 03SLO度量实践与运营 SLO度量、SLO报表、告警因果治理、风险协同、安全变更仅供学习不得转载 传统运营VSSLO驱动 传统方式：运营区动 新型方式：SLO驱动 SRE/研发：设胃SL、治理SLI标标准化SU实规：Metrics.ecode.HTTPCode统一数据采集。清理、计算。聚合、展示.SLO告警，企微推送、公开透明、轻协同 技术支持/NOC：梳理业务场量（功能API)确定实现方式：应用Metrics，口志，DB等自定变数据采费，清理、计单、聚合，展示NOC町盘、故障通告、应急响应 ，场量覆盖度率，运营驱动，成本高，效率低·人力消耗高，近业务远技术，易被忽悠 由内面外度量服务能力·润案服务一切不可用·技术驱动，业务全覆盖，效率高、成本低 Gdevops全球敏捷运维峰会北京站 可用性统计：请求Vs时间 请求成功率：SLI=1－Emor/Total 可用时间：SLI=1-UnavailableTime/TotalTime 计算简单 定义错误：ErrorCode治理统计Error、统ilTotal 什么是UnavailableTime：每分钟错误率>20%or30%？tilErrorTime, TotalTime 块点 铁点 请求量易受用户和锥路影响，如重试放大：数据抖动大 可用时问内不代表用户功能一定没异常，可能只是错误率低低于错误率算可用，精确度低，故障召回率低报警能力单一：基于时间拉度报警，无多消托率报警 优点 数据真实，下跌一定代表服务不可用：用户功能失不可用错误一定会披召回报管能力丰富：可实匙SRE的多消耗率报警 优点 时问维度结果用户更易理解更贴近传统故障时问的统计方式 Gdevops全球敏捷运维峰会北京站 SLI指标治理：错误治理 精准识别错误是度量可用性的前置条件 SLBClient视角：HTTP5xx ，服务内部错误：500服务不可用：502·网络超时、服务无响应：504限流：503 应用Server视角：ecode-5xx 服务内部误：-500：强依赖超时错误：-504，限流：-509 Client视角 ①塔断下游服务@下游服务网略不可达@下游务响应超时下游服务返回错误 应用Client视角：ecode-5xx ，网不可达应用无响应、响应超时：-504+熔断：-500+下游返回错误5xx，-5xx：降级本速传 Server视角 息服务返回错设 Gdevops全球敏捷运维峰会北京站 可用性SLI：多SLI实现 部分服务只提供内网调用，不过负载均衡 无法通过负载均衡一条Metrics计算到的可用性来覆盖业务全部故障场景Ops 覆盖故障场景 SLBHTTP5xx：应用访问超时。容器OOM、进程Panic等不可用，会在SLB则上报错误指标，HTTP/gRPCServer-5xx：应用HTTPCode200,但因依就下游服务、读取DB、CACHE失败等系统错误时，会在应用Metrics测上报业务Code错误指标 Gdevops全球敏捷运维峰会北京站 业务指标SLI 技术指标发现服务所有不可用问题 业务指标补位核心场景（逻辑）异常 基能标：谢表，网络。大书/送礼耗时/减成现率业务KPI智后PVUW.PCU ，用户切馨掉登录，最后发现足APP上误跟登录·用户充值失政。排查后发现是业务逻任BUG 业务指标度量方法 大数据流式实时计算 APP：基础指标、业务技术指标、业务KPI指标服务端：业务KPI指标，评论、登录、动态等 激据库Binlog订阅 直播营收、消费·电商订单·用户支付 Gdevops全球敏捷运维峰会 北京站 多对象、多SLI多SLI实现 Gdevops全球敏捷运维峰会北京站 运营：SLO报表 1.错误预算消耗报表 3.SLO详情报表 5.不达标业务日报/周报 2.错误预算燃尽图 6.综合排名、公榜 Gdevops全球敏捷运维峰会北京站 运营：告警因果治理 SLO告警是果，其他告警是因 SLO报整一旦触发就代表服务能力低于预期，影响服务功能或用户体验 SLO报警中最核心的是可用率报警，一旦触发就代表服务故障 SLO报警降噪思路 ，研发关注的告营：服务SIO受损和常见透国（依频错误。中问件异带。饱和度）应用SLO指标发现对下层【中问件、追竹】依效错借误下层告智对研发透明研发可技需订阅下层告誉 SLO报警实践 按业务等级分梯度设置SLO和报警条件 紧急商口发现严重事故：10分钟平均可用率99.9%月一分钟错误量>10 非紧急窗口发现低速流血问题：1天平均可用率SLO ·消耗速率=1 ，1天以1倍消速率消韩了1天商口的错误预算时发出故障工单 Gdevops全球敏捷运维峰会北京站 运营：风险发现与协同 传统的告警分发 IM造知：订订、企业微信邮件、短信、电话 人品放大，接警平低通道夏用，大量偿音无法协同，信息照冠 运营：安全变更 实时SLO：可用率，错误、QPS，延迟 SLO数据扩展到上层平台 SLO数据随处可见 ·容器平台：服务发布、变更·多活管控平台：多活切流·混沌平台，稳态检测 04SLO价值之再升级：GOC建设 故障定义发现、应急协同、定界定位、快恢、风险跟 GOC建设框架 应急响应中心 阿里GOC:Global Operations Center 故障发现，道告故障同步、升级、协同对外同步，PR.GR复盘总结、定设责、待办跟进 监控+接术支持转型升级 目标：安全生产 防止能预见的问版快速恢复不能巧防的问题不再重复已发生的问版 能力：故障快恢1-5-10 Gdevops全球敏捷运维峰会北京站 故障定义发现 故障面向结果，定位面向根因 业务KPI：产品核心的写场景，量的波动 ，订单量，在效人数，进房量，弹总量核心场景SLO：产品核心场景的读，可用率波动：视期详情页，评论列表，直插房间等可用率严重下跌 SLO风险+用户反馈：服务抖动的轻微问题召回 微博奥情： ·B站崩了# Gdevops全球敏捷运维峰会北京站 故障应急协同 故障发生时：同步、响应 故障中：止损、定位、同步 故障后：复盘总结、待办执行 故障进展同步故障详情，新人熟悉故障根因推荐、定位止损预案关联，执行 事故定级定损，复盘总结待办催办，待办验收：故障演练，根因&应急&止损&待办验证 故障预定级，明确应急等级·确定故障范围，下钻铅误详情·自动故障通告·干系人拉群同步·初因定位 Gdevops全球敏捷运维峰会北京站 故障定界定位 业务可用性概览：错误定界 SLO根因分析：根因定位 全网业务可用性大盘：故障定界 业务指标的波动服务模块的SLO波动·异常卡点击下钻根因分析 SLO大盘，饱和度变更分析，上下游拓扑依赖服务，依赖组件SLO根因推荐，链路诊断定位直接原因，可执行止损预案 ·核心业务编排上榜·故障域一目了然·故障快速定界异常卡点击下钻 Gdevops全球敏捷运维峰会北京站 Gdevops 全球敏捷运维峰会 THANK YOU !