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

武安闯哔哩哔哩/ SRE负责人 •对SRE高可用架构、技术风险体系建设、质量运营和组织转型有深刻的建设实践和思考•主导B站SRE转型、高可用架构、故障快恢、SLO工程、容量管理体系、多活容灾等专项•从0到1带领B站运维向SRE转型，建设B站可靠性体系•当前专注SRE可靠性体系规划建设和落地实践 什么是SRE传统运维与Google SRE的区别 01 目录Content SRE转型的保驾护航人、组织、制度为SRE转型保驾护航 02 SRE可靠性框架 03 高可用架构、技术风险、质量运营 可靠性工程实践 04 多活容灾、SLO、故障快恢1-5-10 01 什么是SRE 传统运维与Google SRE的区别 什么是SRE SRE •⽹站可靠性⼯程师•SRE最早是由Google提出•⽤软件⼯程的思维和⽅法论，通过设计和⾃动化来取代⼈⼯操作•解决的问题•团队⼤⼩与系统负载成线性增⻓•研发变更效率与运维服务稳定性的⽭盾 团队特点 •50%-60%是标准的软件⼯程师•40%-50%基本满⾜软件⼯程师标准，但具备⼀定的其他技能（Unix内部细节和⽹络知识）•SRE团队把50%的精⼒⽤于开发⼯作•SRE成功的关键在于对⼯程的关注 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 SRE讲了什么 SRE基础认知 团队管理和⼯作模式 •SRE团队转型、SRE参与模型、协作沟通•SRE琐事优化、中断管理 拥抱⼯程、拥抱开发 •重视⼯程、运维⾃动化•50%⼈⼒参与开发 SLO⼯程•SLI度量、SLO⼯程、报警、运营 SRE⽇常Oncall ⾼可⽤ •关注系统⾼可⽤能⼒和架构设计 故障⽣命周期管理 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 SRE与传统运维&DevOPS的区别 ⽤软件⼯程的思维和⽅法论，通过设计和⾃动化来取代⼈⼯操作 •SRE团队把50%的精⼒⽤于开发⼯作•SRE成功的关键在于对⼯程的关注 被动质量、变更效率 OPS 资源交付、配置变更异常处理、问题排查运维标准化、监控告警被动响应，应急事务处理 工程、质量、效率 •可⽤性•延迟•性能•效率•变更管理•监控•应急响应•容量规划 •SRE实现了DevOps描述的⼀些哲学•⽐“DevOps⼯程师”更接近于这个⼯作或⻆⾊的定义•SRE类实现了DevOps接⼝ DevOPS CI/CD研发交付效率CMDB、变更、中间件运维变更效率堡垒机、作业、审批⼯具建设⽇志、监控、告警可观测 DevOps是⼀套松散的实践，指南和⽂化，旨在打破IT开发，运维，⽹络和安全⽅⾯的孤⽴ 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 SRE转型中保驾护航 人、组织、制度为SRE转型保驾护航 琐事优化—给SRE转型的时间 没有时间，转型SRE就是异想天开 与维护服务相关的，重复的、可预测的、持续 •⼿动性•重复性•可以被⾃动化•⾮技术性•没有持续的价值•与服务同步增⻓ 琐事类型 •流程/⼯单•问询、沟通中断•服务迁移、变更•压缩成本和容量规划•问题/故障排查处理 Oncall轮值 ⼯程+BP+部分Oncall轮岗 全员Oncall轮岗 ⼯程+BP+云原⽣架构+技术⽀持 ⼯程稳步迭代、专项持续推进重运维业务专项BP，其他业务Oncall•更多⼈⼒转型⼯程开发vs依旧较多的中断 中断和Oncall左移技术⽀持，SRE全员转型SRE只专注开发运营与可靠性⼯程•标准化Oncall和中断，SOP技术⽀持承接•更专业和全职的技术运营 释放⼈⼒转型⼯程开发和治理 •⼯程轮岗导致⼯程效率低下•专项事宜难推动•技术差异性⼤，全员Oncall不深⼊ 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 人员能力模型升级 日 常 变 更 答 疑 ：变 更 、 资 源 配 置 、 报 警 、 工 单 、平 台 答 疑 基础技能 SRE升级 串 联 协 作 ：项 目 跟 进 、 问 题 复 盘 、 平 台 运 营 、 预算 基本运维能⼒：Linux、中间件、微服务、云原⽣K8S⽹络、TCP/IP、OS、内核 ⾼可⽤架构、技术⻛险专项⼯具、平台开发运营 技 术 支 持 ：业 务 迁 移/重 构 、 业 务 改 造 、 中 间 件 推广 、 基 架 技 术 运 营 、 应 急 响 应&故 障 处 理 、 成 本 优化 合作共赢 成⻓潜⼒ 项⽬管理团队协作同理⼼/情商 学习能⼒、好奇⼼逆向思维责任⼼/担当 稳 定 性 实 践 ：服 务 分 级 、 质 量 运 营 、 巡 检 风 控 、预 案 建 设 、 多 活 容 灾 、 容 量 管 理 、 报 警 治 理 等 稳 定 性 体 系 ：多 活&高 可 用 、 容 量 管 理&弹 性 伸 缩 、活 动 保 障 、 服 务 分 级& S LO运 营 、 研 发 轮 岗 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 团队/组织支持 开发转型 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 B站SRE转型历程 应⽤、系统架构、⾼可⽤ 架构、⻛险、运营 •应⽤运维职责拆分•关注应⽤、组件稳定性•关注系统架构•事故总结、复盘⽂化•开始了解SRE、业务 •⾼ 可 ⽤ 架 构 ： 多 活 容 灾 综 合 实 践•技 术 ⻛ 险 体 系 ：S L O、 变 更 、 混沌 、 容 量 、 故 障 快 恢 、A I O P S等•质 量 运 营 ：O n c a l l值 班 、 ⻛ 险 运营 、 ⽣ 产 专 项 、 质 量 运 营 中 ⼼ 转型、可靠性、⼯程 交付、配置、效率 •琐 事 优 化 、 平 台 服 务 化 、O n c a l l轮 岗 、业 务B P•开 发 转 型 ， 关 注 ⼯ 程 ，S R E⽅ 法 论 探索 、 实 践 、 总 结 、反 思•S L O、应 ⽤ 架 构 、容 量 、 多 活 、故 障管 理 、 混 沌 ⼯ 程 、 活 动 重 保 等•稳 定 性 框 架 初 步 完 善 •资 源 交 付 、 环 境 初 始 化•服 务 发 布 、 配 置 变 更•监 控 采 集 、 报 警 处 理•运 维 标 准 化•D e v o p s平 台 化 SRE可靠性框架 高可用架构、技术风险、质量运营 SRE可靠性框架 系统架构 SLO •中间件/组件架构&⾼可⽤、容灾预案、切换演练、端到端全链路容错 •业务&场景&服务、中间件、基础设施All in SLO•基于SLO的全⽹业务质量体系、⻛险识别与升级协同 微服务架构 安全变更 •注册发现调⽤、超时重试、依赖降级、限流熔断、隔离调度、中间件/组件依赖容错•服务运⾏时规范、观测能⼒ •流程制度、变更红线、分级发布、变更刹⻋混沌⼯程：⻛险挖掘、⻛险验证容量管理：容量分析预测、弹性伸缩、降本 基础设施架构 故障快恢（1-5-10） •公有云、IDC、混合云、⽹络、专线、服务器 •故障发现、应急协同、定界处置、故障快恢、⻛险预防AIOps：根因推荐、⽆阈值告警、异常检测可观测：Metric/Log/Trace故障定界能⼒ 多活容灾综合实践 质量运营体系 •同城双活、异地多活、单元化 NOC值班：SREOncall、舆情客诉、应急响应、调度决策⻛险运营：⻛险挖掘、⻛险处理、业务覆盖、改进落地⽣产专项：质量周会、SLO专项、活动重保、项⽬协同质量运营平台：⻛险中⼼、协同升级、值班管理、数据运营 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 实践心得 在组织的⽀持下团队从运维转型升级到SRE从被动运维到主动的可靠性⼯程开展个⼈能⼒模型转变提升，多重⻆⾊⽀持研发 以SLO为核⼼抓质量体系建设、报警治理和⻛险运营以GOC体系1-5-10要求为⽬标建设故障快恢能⼒ 关注服务流量层的南北向和东⻄向⾼可⽤容错能⼒深⼊应⽤架构、系统架构，跟研发⼀起提升架构可靠性容量故障不可忽视，HPA必不可少，降本增效也要兼顾 所有保障能⼒都在活动重保中综合体现和验证从SRE中来，⾛出SRE的框架，形成⾃⼰的体系 04 可靠性工程实践 多活容灾、SLO、故障快恢1-5-10 多活容灾架构 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 多活管控与治理 SLO工程 SLO：指定了服务可靠性的⽬标⽔平，是做出可靠性决策的关键数据，是SRE实践的核⼼ •⼯程师稀缺，时间投⼊到重要服务的核⼼问题上•SLO是做出⼯作优先级排序和可靠性相关⼯作的关键•⼯作按照SLO来开展，确保SLO是合理的•没有SLO，就没有SRE 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 SLO工程实践 2 0 2 3 D e v O p s国 际 峰 会暨B i z D e v O p s企 业 峰 会·北 京 站 故障快恢1-5-10实践 ⽬标：安全⽣产 •防⽌能预⻅的问题•快速恢复不能预防的问题•不再重复已发⽣的问题 哔哩哔哩技术公众号 Thanks DevOps时代社区荣誉出品