这是接入层架构，用户通过 DNS 或降级 HTTP DNS 访问 CDN，CDN 通过机房边缘 POP 点汇聚流量到机房，机房有不同可用区(逻辑概念)，每个可用区主要是 SLB 和 API GW。

常见的故障有几种：

• 服务调用有 P2C 算法，服务A调用服务B，服务B会返回自己节点的 CPU 使用率情况，服务A基于这次响应的 RT（包括服务B每个节点 CPU 使用率/成功率来选择一个最优的节点），虽然服务B不同节点 CPU 算力不一，但最终 CPU 使用率是一样的；

• 熔断，服务B故障时，服务A做一个熔断；

• 降级的场景有两种：

• 一是可用区的降级，当服务B在某可用区故障，服务A调用B可以通过服务发现组件降级到其他可用区；另外是做多活的时候，服务在本可用区没有做部署的情况下降级到其他可用区；

• 内容质量降级，服务B故障服务A可以访问本地缓存/降级服务。在我们场景里，如果播放地址失败会降级到灾备播放地址。B站首页APP推荐可能是动态的，推荐系统故障也会降级给用户热门视频。

• 限流有两种，一种是微服务框架侧全局限流，它在框架层面的拦截器，B站内部主要是 Golang，使用 Kratos框架，基于框架做了分布式限流。第二部分是动态限流，不需要预先配置，基于 Google 的 TCP BBR 算法来实现的，会自动分析每个容器节点 CPU 使用率/成功 QPS 等来自适应做一个保护。

那有了高可用能力，B站就不炸了吗？2021.7.13故障，B站/微博/知乎全网热搜，我们做一下复盘。

2021.7.13 晚 10:52，用户反馈B站无法使用，内部大量服务、域名接入层报警不可用。
10:57分，Oncall 同学发现 SLB 故障。
11:17，内网登陆也受影响，17分核心成员才陆续进入内网系统。
11:23分，读多活业务基本恢复。多活机房 SLB 容量过载，多活机房服务层正常/接入层挂了（容量涨了4倍左右）。
11点之后流量逐渐下降，重启恢复。当时直播业务也做了多活，首页接口没做多机房流量分发（所以没有恢复）。
11:17分登陆分析问题，开始怀疑是 SLB 组件问题，联系最近在SLB层面做了三次引擎 Lua 层的变更，也没有恢复。

1:00左右，新建 SLB 全部完成，开始做业务流量切换。
1:40左右，业务已经全部切到新集群，核心业务全部恢复。

• 用户的链路和办公网链路未彻底隔离，11:17分才陆续进入内网系统，有些办公网后台直接放在公网对用户访问，办公网放到公网也会用到公网 SLB（没有彻底隔离）。
• 多活未按预期立即生效。多活机房SLB流量过来，只支持读，不支持写。
• 人力不足。故障止损和排查无法并行。1点左右新建，后面才尝试做故障排查。组件故障预案不完善、处理耗时久（集群的创建、配置的下发、公网 IP 配置花了接近1个小时）。
• 复杂事故影响面积大，故障定位成本高。

同时也看到，多活是机房级故障时容灾止损最快方案！

1. 多活基架能力不足。机房与业务多活定位关系混乱，流量调度层面不支持精细基于用户特征做流量分片。

2. 切量强依赖 CDN 平台，多活的接入层/用户流量调度分发层是在 CDN 层面实现，并没有做一个多活统一管控平台。

3. 多活元信息也缺乏平台管理，比如哪个业务做了多活（多活是同城双活/异地容灾），业务有哪些规则支持多活。

• Gzone 服务（全局共享服务），可以在用户间共享数据，一个可用区写/其他可用区读（数据强一致性）。B站场景里，视频播放/番剧/影视/稿件信息/直播间信息数据都是平台型数据，这种数据在用户间共享不需要做单元化。
• Rzone 单元化业务（用户流水型数据），多可用区分片写/读，用户维数据在B站里就是社区类场景（评论/弹幕/动态等适合单元化的场景）。
• Czone 和 Gzone 有点类似，Czone 所有可用区都可以写/读（非单元化），介于 Gzone 和 Rzone 之间的，这种场景需要业务接受一定数据延迟和不一致。

对机房进行梳理，当时上海有很多机房（都在一个地域内，机房定位比较混乱）。梳理后将上海的4个机房划成两个逻辑可用区，同城双活（Gzone 类型服务）部署在上海；把江苏可用区作为 Rzone 单元化服务部署模拟异地；我们又规划华北/华南的可用区，来做单元化、Czone 服务部署（30ms-40ms网络延迟）。

• DCDN 支持用户 Mid、设备ID来做一致性 Hash，同时支持多机房动态权重。DCDN 是基于 Nginx 来构建的，后来重新开发支持多机房的动态权重。

• 服务原来的多活是不支持写的，没在多活机房做本地化部署和写链路感觉。核心链路一定要在本地写，微服务框架支持写感知，弱依赖服务回到主机房。

• 存储层面最早多活没有 Proxy 组件，需要业务自己决定哪个机房读/写（管理成本特别高）。我们后来统一做 Proxy 做业务接入管理。

• KV 存储原本不支持机房部署或者容灾切换，之后也做了改造优化。包括 TIDB 也支持多机房容灾切换。

• GZS 通过 GZS 来管理业务多活元信息、多活定义、切量编排/可视化。

• 多活规则元信息获取方式优化
• 平台多活和同城双活切量演练
• 多活编排、接入流程优化
• 审批、巡检、可观测能力加强

实际多活编排和切量流程是，编排先选择业务（评论/弹幕/播放）、选择业务类型（同城双活/单元化）、编排接入层规则。

数据库层编排是 KV、DB，要把多活各个维度资源编排出来，业务就可以发起切量。

业务和业务域。业务域（直播/电商/社区），业务域下会有业务(社区有评论/弹幕/点赞等），切量编排是对流量编排或存储编排。

切量完成之后触发审批。审批之后是巡检，巡检主要为三部分：

• 容量巡检，CPU/MEM；连接池，流量切到另一个机房，流量可能会翻倍；还有数据库/缓存连接池能否扛得住；限流，微服务框架也有很多限流配置，限流能否扛住。
• 延时巡检，主要做存储层面的巡检，现在是同城双活，延迟基本上没啥问题。
• 隔离巡检，存储有没有跨业务混用？比如评论的业务是否用一个动态/弹幕 DB、KV。
• 可观测，巡检指标可观测，连接池、限流是怎么变化的？业务多活流量规则，流量切换是否符合预期？是否把流量从1:1切到1:0；业务涉及核心应用SLO 指标。

容量管理之前，SRE 要想一个问题，要管什么容量？

对 SRE 来讲，容量管理的核心应该是应用。

容量管理做出之后谁关注？

不同角色关注是不一样的，比如研发/SRE/平台/预算团队等等。

目标收益是做之前要想清楚的。这里是每个角色对容量管理的预期：

遇到一些痛点，当 Request 分配完，Used 特别低时，资源池没有资源可调度，SRE找研发按应用维度调整超卖率，对研发来讲想抢占资源，这个服务是稳定的，不想把资源释放出来，就导致共识很差，效率很低，收益特别小。后来把VPA改成平台维度。

右边是K8s与VPA联动的架构图，上面是 VPA 管理平台：策略管理/数据运营/黑名单/预警。

活动开始前做活动了解

容量预估

压测&演练

• 第一轮：现有资源下压业务瓶颈；

• 第二轮：资源就绪后按照之前的预估人数做容量压测；

• 第三轮：所有优化和保障方案上线后压测演练。

演练层面两部分：

复盘清单

活动清单检查

技保能力&预案

现场重保&复盘

前面讲的是稳定性保障、高可用，服务可用性怎么度量？

我们先看一下 Google 的定义：

SLO 为服务可靠性设立了一个目标级别，它是可靠性决策的关键因素，是 SRE 实践的核心。

Google 甚至说没有 SLO 就没有SRE。为了使采用基于 SLO 的错误预算的可靠性工程方法，服务利益相关方认可 SLO，甚至服务可以达到 SLO。

这是实践 SLO 的流程，首先创建业务&定级&定SLO；然后创建应用&定级；之后创建接口&定级&算SLI指标；最后基于接口聚合到业务上。

这种模型没有运转下去。

我们的反思：

• 分级模型太理想，定级成本非常高；
• 各种元信息关联不及时，数据准确率低；
• 开始做 SLO 计算只算公网服务，也只算了在接入层（SLB层）指标，单条 Metrics 没办法覆盖所有业务场景；
• 部分内网服务不对外，导致没有 SLI 数据；
• SLI 数据除了当报表外，也没人看

新的模式：

• 分级模型优化
• SLI模型优化
• SLO报警治理

SRE 培养有四方面：