B站出圈背后，谁来为业务创新和系统稳定护航

　　云原生的应用创新经验，正在被行业上下游不断提起和讨论，其实践也正从行业先锋、先进应用企业开始走向千行百业。

　　文|徐鑫

　　编|任晓渔

　　AI孙燕姿在B站火了。

　　最近几年，B站时常有新的内容形态和话题破圈。跨年晚会、数字人、虚拟直播、大型赛事，各种新内容消费场景带来了用户规模的快速扩张。数据显示，B站月均活跃用户数从2019年Q4的1.16亿增长到了2022年Q4的3.26亿。伴随着用户和内容破圈，B站的平台系统复杂性也快速增加。

　　这对云上的运维、稳定性及成本管理都提出了新的要求。B站在云上系统稳定和高可用系统的治理有不少实践。以云上的系统稳定为例，B站已经建成了完备的SRE(站点可靠性工程)质量运营体系，SRE质量运营团队在云上扫雷，积累了保障B站安全稳定运营的丰富经验。

　　日前，在全球云原生交流平台“创原会”组织的走进B站的活动上，这些经验也分享给了来自不同行业、关注云原生应用的与会者们。

　　新一波技术浪潮来势汹涌，内容平台云上业务创新迎来了新机遇，也给确定性运维提供了新的可能性。前端的业务汹涌创新背后，都离不开先进的平台底层架构的支撑。早已完成云原生改造的企业们已经享受到了红利，在降本增效的大背景下，这些企业已经开始探讨更深一层的成本和性能平衡问题。

　　01

　　谁在为平台保驾护航

　　B站技术团队没有浪费任何一次风险处理经验。

　　2021年发生过一次故障处理事件，处理过程被他们视作一次经典的案例，现在已经被盘出了包浆。不仅在内部学习，B站技术团队将它整理制作成了复盘文章和视频，讲述从发现到协同SRE质量运营团队及相关技术人员解决问题的过程。如同打怪一般，挖掘平台稳定运营的风险点并排除风险，引了数百万人阅读和围观。

　　这一出圈的过程，某种程度是当下互联网平台普遍面临系统稳定性考验的缩影。

　　随着互联网逐渐渗透到更广泛人群，国内主要平台用户体量已达到了惊人的数字。软件系统越来越复杂，业务变更速度快，往往更容易导致质量问题。一旦出现故障，损失也颇为严重。有机构统计，一小时的宕机可给IT企业带来损失超过100万元。

　　实际上各大平台做了不少努力，来提升系统稳定性。例如，大企业内部都建了非常多的平台，包括工程平台、压测平台、容量预估平台、变更管理平台等来同步信息。通常，企业内也有非常多人力来保证系统稳定，比如多数公司里都有测试、运维和研发等多个团队来配合作业。但这些平台普遍存在信息孤岛问题，而故障和稳定性是有时间跨度的周期问题。许多企业缺乏从整个质量周期层面来管理和应对风险及故障。

　　在创原会组织的技术分享会上，B站SRE体系负责人刘昊向与会人士介绍，B站十分关注云上的应用程序可靠、可用和安全，专门设立了SRE质量管理团队来监控和管理故障的事前、事中和事后的流程。

　　刘昊认为，要从故障预防、故障发现、故障定位、故障恢复、故障改进的全生命周期来关注和运营故障，企业也需要通过平台化能力去提升故障发现效率、降低故障恢复的时长，最终能够深挖故障价值，并确保改进措施能够有效落实。

　　B站做了非常多细节工作来确保这套理念的落地。例如，针对故障事前、事中、事后，做了事件运营中心。这个中心收敛了上游的各种报警系统、客诉系统、舆情系统、变更系统，通过人工上报和自动上报结合的方式监测各类系统内的报警信息。

　　一旦有事件发生，首先接入到风险预警体系，最后才判断是不是故障。风险预警相当于扫雷，基于统一的事件识别来挖掘各类风险，要把潜在风险挖出来，管控风险，提升效率，还要让风险的一些指标可度量。

　　有些没兜住的预警会产生故障。其中非常重要的工作是，让需要知道故障信息的人士得到该知道的信息。B站有两套体系可以完成组织、业务和人的匹配，既可以通过组织架构找到与业务相关的人，也能通过内部的投诉系统把职责、业务、团队关联在一起。匹配完成后，质量运营体系还会再做一些冗余事件聚类降噪，使各类故障信息就能通告到各个关注方。

　　为了让已经发生过的故障产生价值，他们还设置了非常详细的，包含了定性问题和定量问题，来提升复盘文档的价值。

　　那份出圈的2021年故障复盘，B站的技术团队现在还在反刍。刘昊向与会的创原会成员们解释，这一过程有助于企业内形成对故障处理的肌肉记忆，让新进入团队的新人能够学习企业技术架构模式及协同方式，从而规避类似的故障。“外面热搜都炸了，新来的研发还在慢吞吞看代码的BUG，团队已经形成了SOP(标准作业流程)，但他可能完全想不到去看SOP。”他的比喻引发现场人士会心一笑。

　　与会者们也好奇，SRE质量运营团队在组织内的角色定位和价值如何度量。一位同样在内容平台的技术人员发出灵魂拷问，“SRE是否必须为公司所有业务的故障背锅，有SRE，故障次数一定要下降吗?”

　　刘昊对此毫不犹疑，在他看来，如果正确认知了SRE的角色，就很难成背锅侠。“SRE要背的指标是，如果系统内实际有20个风险点，SRE只挖出了2个风险点，剩下的18个没能和业务方一起挖出来。这就是SRE的错。”另外，他认为，如果质量运营体系实现了全面覆盖，但故障增多，SRE要能提供数据分析出薄弱环节，让技术团队知道系统的薄弱点,才能投入技术和人力资源去改善。

　　快速的业务变化和系统变动下，SRE体系正扮演B站站点可靠性工程层面的白帽子角色，排除故障，保障云上系统安全稳定。

　　02

　　业务创新红利来自云原生改造

　　B站业务蓬勃创新的出圈过程中，除了扫雷的站点可靠性工程白帽子们存在，还有非常多幕后角色在细分技术战场发挥作用。

　　AIGC爆火，加速了各大内容平台的创新速度。B站也有不少AIGC相关产品来丰富内容生态。例如，去年3月开始，B站正式推出了虚拟直播专区，主播可以自定义长什么样，自由选择身材和衣服配套，定制自己的虚拟角色，虚拟玩法。

　　高校的研究也给内容平台的AIGC热潮加了一把火。最近开源社区有人使用浙江大学教授赵洲团队推出的AIGC相关的生成式语音模型DiffSinger，这款产品很快在B站获百万浏览量。赵洲介绍，此前他们的产品AudioGPT没有办法跟用户进行交互，有了ChatGPT之后他们调用了它的框架，帮助自己的产品理解用户的意图。

　　小红书音视频架构的负责人陈靖感受到了这股趋势。他判断，2022年开始内容生产明显进入了智能时代。在创原会的分享上，陈靖坦言，过去曾感觉AIGC内容并不那么靠谱，但随着大模型实现智能涌现，他认为，AIGC将给创作者提供启发，赋能创作链路，内容创作领域也会出现智能化浪潮。

　　除了业务本身，大模型给智能运维也带来一些新的可能性，但这还在探索之中。创原会副理事长、华为云Marketing部长董理斌与华为云的一些工程师交流时发现，在售后维护场景下，工程师们已经利用AI开发了一些类似知识问答的系统，助力可靠性运维。这类系统可以在网络出现故障后，根据过去的经验给出处理建议。当下工程师们也在思考，基于大模型能否利用网络上各种各样的历史数据，能否加速模型的积累，推动知识类产品从过去的知识问答发展到自动处理和操作。

　　刘昊同样认为智能运维是未来的发展方向，他也判断仍需时间才能落地，问题出在智能运维场景下，喂给模型的高水平的SOP语料比较缺乏。不过在单点运维场景，AI技术已在B站实际场景中发挥作用，例如，底层资源维护层面，大数据场景下的磁盘故障预测，可通过AI手段实现。

　　无论是面向用户的业务场景创新，还是企业内的各类新兴服务尝试，离不开底层技术的支撑，其中既包括新的云上的技术方案使用，也包括底层架构的云原生化改造。

　　以B站的虚拟直播为例，这个新场景出现后，不少开通虚拟直播的主播已经顺利完成了吸粉和商业化进程。实际上，用户能体验到虚拟直播丝滑、低延时和高质量的内容体验，与B站此前在现象级直播事件中打造出的边缘分布式方案分不开。

　　通常情况下，直播需要保证过程里的稳定性、降低时延，同时有伸缩性且成本较低。比如B站的英雄联盟S12全球总决赛直播，为期35天，91场赛事，直播间实时人气突破3.1亿。流量洪峰的考验下，B站联合华为云共同建设了B站的分布式直播方案，消除了之前统一转码源站的单点故障，增强了直播过程中的稳定性、安全性，同时依托中心云平台上的海量弹性资源池，按需调度，更好地提升了用户的互动体验。

　　除了极限场景里磨练出来的方案，B站当下的业务创新还离不开一个底层角色——经过云原生化改造的平台架构。

　　B站在2017年下半年开始了以Kubernetes引领的底层架构的云原生改造。刘昊告诉数智前线，在C端消费者感知层面，当时传统架构模式的劣势尚不明显，但是技术团队已经发现了一些典型问题。例如，在缓存上容器时，用其他的方案做缓存服务的PaaS化。配置热更新后，容器没有办法原地生效。但如果重启又会影响业务进行，而在Kubernetes架构下能很方便完成更新，实现容器快速扩容。同时，内部平台的接口丰富度和底层操作系统层的适配度，经过云原生化改造后也大大提升。

　　2019年开始，B站就尝到了红利。随着用户群体开始破圈，内部应用数量也飙升。刘昊记得，内部应用一开始只有1000个，从2019年下半年快速增长，到当下已经有2万多个应用，几年内十倍增长。服务增长通常会带来软件开发的管理成本上升，保障团队的管理成本也飙升。

　　但经过云原生化的改造后，开源社区有非常多的现成工具，B站可以直接使用现有的技术成果，避免了团队规模的指数级增长。先进的底层架构还方便他们把外部资源如华为云作为资源的备用池，一旦出现大型活动容量突增场景，可以快速接入外部资源，保障了应用的稳定可用。

　　03

　　深度用云时代的成本优化

　　完成了云化改造后，相关技术团队开始更深一步重视“协同”、“优化”等，其中云上的成本成本管理问题日益凸显。

　　小红书音视频架构部门负责人陈靖观察到，国内主流视频处理平台架构的演进经历了从单体服务自建机房，逐步到计算存储CDN云化，之后通过容器技术，实现了微服务架构，今天已经基本向Serverless云原生化演进。

　　这些变化是伴随着内容平台的业务挑战而来。过去十年里，内容发布数量飙升，用户对音视频的质量要求在提高，为了更好提供服务，平台也需要同步加速在内容平台的处理速度，并且要以相对低的成本完成。

　　“由于很早开始云服务，小红书得以将主要精力投入到业务研发，快速迭代升级，从业务速度、媒体质量和整体成本三个方面实现了平衡。”陈靖介绍。

　　陈靖团队内部关注到了一个案例。亚马逊的Prime Video是一个识别用户查看视频质量问题的应用，最初亚马逊的技术团队用了很多分布式组件来实现。后来这个服务的性能比较差，经过排查，他们发现Step Functions居然是瓶颈的所在。

　　亚马逊的技术人员很疑惑，很好的技术为什么在这个场景里会有瓶颈?他们把这个服务整个迁到单体，降低了90%的成本，整体伸缩性反而有提高。这使行业内开始讨论微服务的应用场景问题。

　　微服务能很快把应用架构搭起来，几周甚至几天验证出对客户的价值，这是单体的架构很难实现的。而经过微服务验证价值后，如果基于企业内节省资源，降低成本的考量，在特定业务场景里，就可以采用单体方案。

　　陈靖介绍，目前在小红书的业务场景里，技术团队会优先考虑使用微服务，但他们也发现，在一些公司里可能会存在这样的情况，技术团队希望通过微服务达到架构清晰、方便理解的效果，但最后却出现微服务开发越来越多，越迭代越复杂的情况。

　　如何避免过度使用微服务呢?以Prime Video为例，它只是一个大的业务架构里的监控用户视频质量的小功能，陈靖认为这并不是一个值得分拆的组件，用单体化的方式去实现难度并不大。

　　华为云容器服务首席架构师张琦从云上资源利用的角度来提供了另一种看法。张琦在自己接触的大量案例中发现，在经过容器化改造之后，业务拆分成很小的微服务，业务团队需要为每一个微服务申请资源。过程中，业务团队通常会给微服务运行需要的资源量留出余量。当每一个微服务都有它的buffer，加起来以后，整个的资源占用比单体的时候要多很多。从这个例子中可以看出云上资源管理和成本控制的必要性。一份调查显示，全球范围内超过90%的受访企业已经开始FinOps实践。

　　张琦介绍，在业界谈论得较多的FinOps解决方案中，都会提供了一个成本洞察和成本优化的大盘，可以给财务团队、运营支撑团队、IT团队等提供相应的决策参考。具体的方案上，会用各类技术手段，把此前公司内部业务的烟囱式的资源池作优化，统一调配，融合调度、混合部署，解决资源利用率的问题，华为云也基于云原生基础设施构建了相关的技术降本的解决方案，比如通过微服务和批量计算任务分时使用资源消减集群和节点资源碎片;提供队列、组、作业优先级、公平调度、资源预留等多种抽象，统一满足微服务、大数据、AI多业务调度需求;并在CPU、内存等多维度上为应用提供高优低优的自动控制，使资源分时复用，提升资源利用率;同时通过打通多集群资源池，为应用提供统一的资源视图，实现部署运行最优、服务流量治理最优。

　　他用一个客户的案例举例，该客户的应用部署在自己的集群里，大数据任务和其他业务服务混在一起，此前使用时会出现干扰。如果没有任何控制，会严重影响到业务运行的质量。通过一系列技术手段干预，整体提升了资源利用率，最后资源利用率提升到了40%多。

　　Gartner预测，到2025年，云原生平台将在超过95%的新数字计划中作为基础，而此前2021年的数据只有不到40%。随着广大的企业完成云原生的改造，企业的关注重心也在改变。

　　八年前，云原生技术兴起之际，产业上下共同的合力推动了开源生态的标准共建、技术开放、成果共享。后云原生时代，云原生企业的应用实践，云厂商的创新解决方案和开源技术社区的开放共创，正在推动技术生态的进一步完善。创原会这样的开放技术交流平台，汇集行业人士探讨新的技术应用和落地实践，正在推动云原生的最佳实践从先锋和先进应用企业走向千行百业。