武安闯-B站 SRE 转型历程与可靠性工程实践

B站SRE转型历程与可靠性工程实践 武安闯哔哩哔哩/SRE负责人 •对SRE高可用架构、技术风险体系建设、质量运营和组织转型有深 刻的建设实践和思考 •主导B站SRE转型、高可用架构、故障快恢、SLO工程、容量管理体系、多活容灾等专项 •从0到1带领B站运维向SRE转型，建设B站可靠性体系 •当前专注SRE可靠性体系规划建设和落地实践 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 Content 目录 01什么是SRE 传统运维与GoogleSRE的区别 02SRE转型的保驾护航 人、组织、制度为SRE转型保驾护航 03SRE可靠性框架 高可用架构、技术风险、质量运营 04可靠性工程实践 多活容灾、SLO、故障快恢1-5-10 01 什么是SRE 传统运维与GoogleSRE的区别 什么是SRE 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 SRE •⽹站可靠性⼯程师 •SRE最早是由Google提出 •⽤软件⼯程的思维和⽅法论，通过设计和⾃动化来取代⼈⼯操作 •解决的问题 •团队⼤⼩与系统负载成线性增⻓ •研发变更效率与运维服务稳定性的⽭盾 团队特点 •50%-60%是标准的软件⼯程师 •40%-50%基本满⾜软件⼯程师标准，但具备⼀定的其他技能 （Unix内部细节和⽹络知识） •SRE团队把50%的精⼒⽤于开发⼯作 •SRE成功的关键在于对⼯程的关注 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 SRE讲了什么 SRE基础认知 团队管理和⼯作模式 •SRE团队转型、SRE参与模型、协作沟通 •SRE琐事优化、中断管理 拥抱⼯程、拥抱开发 •重视⼯程、运维⾃动化 •50%⼈⼒参与开发 SLO⼯程 •SLI度量、SLO⼯程、报警、运营 SRE⽇常Oncall ⾼可⽤ •关注系统⾼可⽤能⼒和架构设计 故障⽣命周期管理 OPS 资源交付、配置变更异常处理、问题排查运维标准化、监控告警 被动响应，应急事务处理 被动质量、变更效率 ⽤软件⼯程的思维和⽅法论，通过设计和⾃动化来取代⼈⼯操作 •SRE团队把50%的精⼒⽤于开发⼯作 •SRE成功的关键在于对⼯程的关注 DevOPS CI/CD研发交付效率 CMDB、变更、中间件运维变更效率堡垒机、作业、审批⼯具建设 ⽇志、监控、告警可观测 效率提升、⼯具平台 将DevOps看作⼀种哲学和⼯作⽅法 •SRE实现了DevOps描述的⼀些哲学 •⽐“DevOps⼯程师”更接近于这个⼯作或⻆⾊的定义 •SRE类实现了DevOps接⼝ CA(L)MS •⽂化（Culture） •⾃动化（Automation） •精益（Lean） •测量（Measurement） •分享（Sharing） DevOps是⼀套松散的实践，指南和⽂化，旨在打破IT开发，运维，⽹络和安全⽅⾯的孤⽴ SRE 平台工程 工程、质量、效率 •可⽤性 •延迟 •性能 •效率 •变更管理 •监控 •应急响应 •容量规划 SRE与传统运维&DevOPS的区别 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 02 SRE转型中保驾护航 人、组织、制度为SRE转型保驾护航 没有时间，转型SRE就是异想天开 A B C 初 级 琐事识别、⾃动化、平台化 与维护服务相关的，重复的、可预测的、持续的任务流 •⼿动性 •重复性 •可以被⾃动化 •⾮技术性 •没有持续的价值 •与服务同步增⻓ 琐事类型 •流程/⼯单 •问询、沟通中断 •服务迁移、变更 •压缩成本和容量规划 •问题/故障排查处理 有事才有琐事 琐事永远存在 ⽆法彻底消失 100%的SLO不存在 中级源头消除、SLO、Oncall轮值 寻求平衡 ⾼级 ⼈效提升（能⼒、时间）、 组织转移（NOC/技术⽀持） 50%时间开发 琐事优化—给SRE转型的时间 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 全员Oncall轮岗⼯程+BP+部分Oncall轮岗⼯程+BP+云原⽣架构+技术⽀持 全员SRE ⼯程SRE BPSRE OncallSRE ⼯程SRE BPSRE 云原⽣架构 技术⽀持 ... 主站Oncall 直播Oncall ⼯程轮岗 全职 ⼯程 推荐搜索 ... 主站Oncall 直播Oncall 全职 ⼯程 推荐搜索 架构优化 ⻛险跟进质量运营Oncall 释放⼈⼒转型⼯程开发和治理 •⼯程轮岗导致⼯程效率低下 •专项事宜难推动 •技术差异性⼤，全员Oncall不深⼊ ⼯程稳步迭代、专项持续推进 重运维业务专项BP，其他业务Oncall •更多⼈⼒转型⼯程开发vs依旧较多的中断 中断和Oncall左移技术⽀持，SRE全员转型SRE只专注开发运营与可靠性⼯程 •标准化Oncall和中断，SOP技术⽀持承接 •更专业和全职的技术运营 Oncall轮值 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 > 日常变更答疑：变更、资源配置、报警、工单、平台答疑 > 串联协作：项目跟进、问题复盘、平台运营、预算 > 技术支持：业务迁移/重构、业务改造、中间件推广、基架技术运营、应急响应&故障处理、成本优化 > 稳定性实践：服务分级、质量运营、巡检风控、预案建设、多活容灾、容量管理、报警治理等 > 稳定性体系：多活&高可用、容量管理&弹性伸缩、活动保障、服务分级&SLO运营、研发轮岗 基础技能 基本运维能⼒：Linux、中间件、微服务、云原⽣K8S 合作共赢 项⽬管理 成⻓潜⼒ 学习能⼒、好奇⼼ ⽹络、TCP/IP、OS、内核 团队协作同理⼼/情商 SRE升级 ⾼可⽤架构、技术⻛险专项 ⼯具、平台开发运营 逆向思维责任⼼/担当 人员能力模型升级 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 •⼈员Title和组织名字的转变 •从上往下的SRE转型传达 •职级能⼒模型定义 组织与文化 •团队认可SRE⽂化，SRE⽅法论传导 SRE职级序列 •清晰的SRE发展成⻓路线 开发转型 •团队强制开发转型⽬标 •导师帮带，能⼒达标后，参与SRE平台开发实践 •平台能⼒提升SRE⼯作效率、业务可靠性 •技术分享会，SRE⽅法论专题分享 分享与培训 •圆桌会议，平等交流、充分沟通、相互学习 •SRE稳定性建设、OS和⽹络基础知识、技术架构、故障定位等 团队/组织支持 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 2015-2016 •开始了解SRE、业务 2019-2021 营、⽣产专项、质量运营中⼼ 交付、配置、效率 应⽤运维 转型、可靠性、⼯程 SRE综合实践 运维初建 应⽤、系统架构、⾼可⽤ •应⽤运维职责拆分 •关注应⽤、组件稳定性 •关注系统架构 •事故总结、复盘⽂化 SRE转型 架构、⻛险、运营 •⾼可⽤架构：多活容灾综合实践 •技术⻛险体系：SLO、变更、混沌、容量、故障快恢、AIOPS等 •质量运营：Oncall值班、⻛险运 •资源交付、环境初始化 •服务发布、配置变更 •监控采集、报警处理 •运维标准化 •Devops平台化 2017-2018 •琐事优化、平台服务化、Oncall轮岗、业务BP •开发转型，关注⼯程，SRE⽅法论探 索、实践、总结、反思 •SLO、应⽤架构、容量、多活、故障管理、混沌⼯程、活动重保等 •稳定性框架初步完善 2022-⾄今 B站SRE转型历程 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 03 SRE可靠性框架 高可用架构、技术风险、质量运营 SRE可靠性框架 系统架构 高可用架构体系 技术风险体系 SLO •中间件/组件架构&⾼可⽤、容灾预案、切换演练、端 到端全链路容错 微服务架构 •注册发现调⽤、超时重试、依赖降级、限流熔断、隔离调度、中间件/组件依赖容错 •服务运⾏时规范、观测能⼒ 基础设施架构 •公有云、IDC、混合云、⽹络、专线、服务器 质量运营体系 多活容灾综合实践 •同城双活、异地多活、单元化 NOC值班：SREOncall、舆情客诉、应急响应、调度决策 ⻛险运营：⻛险挖掘、⻛险处理、业务覆盖、改进落地 ⽣产专项：质量周会、SLO专项、活动重保、项⽬协同 质量运营平台：⻛险中⼼、协同升级、值班管理、数据运营 •业务&场景&服务、中间件、基础设施AllinSLO •基于SLO的全⽹业务质量体系、⻛险识别与升级协同 安全变更 •流程制度、变更红线、分级发布、变更刹⻋ 混沌⼯程：⻛险挖掘、⻛险验证 容量管理：容量分析预测、弹性伸缩、降本 故障快恢（1-5-10） •故障发现、应急协同、定界处置、故障快恢、⻛险预防 AIOps：根因推荐、⽆阈值告警、异常检测可观测：Metric/Log/Trace故障定界能⼒ 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 实践心得 在组织的⽀持下团队从运维转型升级到SRE SRE⽀持 ⽣产专项 ⻛险运营 NOC值班 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 服务器 ⽹络/专线 多活改造、管控中⼼、切量演练、闭环治理 综合实践：同城双活、异地多活、单元化 混合云 公有云/IDC 基础设施架构 注册发现调⽤超时重试依赖降级限流熔断隔离调度 中间件/组件依赖容错 微服务架构 系统架构 组件⾼可⽤容灾预案切换演练端到端链路容错 从被动运维到主动的可靠性⼯程开展 个⼈能⼒模型转变提升，多重⻆⾊⽀持研发 以SLO为核⼼抓质量体系建设、报警治理和⻛险运营以GOC体系1-5-10要求为⽬标建设故障快恢能⼒ SRE ⽅法论转型 SLO 故障应急 开发能 ⼒转型 中间件/组件架构 ⾼可⽤容灾预案切换演练 端到端全链路容错 中间件/组件架构 ⾼可⽤容灾预案切换演练 端到端全链路容错 混沌⼯程 容量管理 可观测/AIOPS 安全变更 关注服务流量层的南北向和东⻄向⾼可⽤容错能⼒ 深⼊应⽤架构、系统架构，跟研发⼀起提升架构可靠性容量故障不可忽视，HPA必不可少，降本增效也要兼顾 拥抱⼯程拥抱开发 组织⽀持 SRE团队转型 团队过载管理 所有保障能⼒都在活动重保中综合体现和验证从SRE中来，⾛出SRE的框架，形成⾃⼰的体系 04 可靠性工程实践 多活容灾、SLO、故障快恢1-5-10 多活容灾架构 DCDN ⽤户调度⽤户调度 上海可⽤区1 上海可⽤区2 管控(I SLB 中⼼nvoker) SLB Service 读 Cache Cache APIGW APIGW Service 读 服务 发现 删除/更新 删除/更新 MQ Job Job MQ Proxy ⽀持 双向 Proxy 同步 读/写读 GZDB/KV Binlog Canal Canal GZDB/KV 同步 Binlog 写 单向 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 多活元信息 多活巡检 •流量配⽐是否符合预期 •资源容量是否有⻛险 多活编排 •跨可⽤区的不合理依赖 故障预案 管控 多活切量 有效性验证 •流量切换到单可⽤区 •单可⽤服务能⼒验证 •专线⽹络故障注⼊ 多活管控与治理 2023DevOps国际峰会暨BizDevOps企业峰会·北京站 预检查 治理 故障演练 •单业务故障、业务域故障、可⽤区故障 •验证多活切换、降级能⼒和预案 切量中观测 别忘记了员⼯⻔禁链路和管控后台！ 量化指标 可⽤性、延迟、容量等 可⽤性>99.99%（可⽤性）90分位RT<100ms（延迟） 涉及后果、例如处罚赔偿SLA=SLO+后果 ServiceLevelIndicator该服务某项服务质量的具体量化指标 ServiceLevelObject 该服务的某个SLI的⽬标值或 ⽬标范围 Ser