一直以来，面向运营使用的活动平台，在运营使用过程中会偶发出现一些疑难问题，比如运营对某个组件功能的使用有疑问，或者线上的活动表现不符合预期，运营期望产研协助排查。面对这些场景，活动平台维护了一个千人以上的产研运“救火群”，运营有问题会在群里提问，当周研发值班会负责关注群里的问题，并作出响应回答，同时为了了解每周问题情况，值班需要手动记录每周问题excel。
云网络是IT和CT融合的产物。云网络并不是要重建一张新的网络来取代现有的网络基础设施，而是在现有网络基础上通过网络虚拟化等技术重构。前面讲到，云计算驱动云网络的诞生，云网络其实是CT（Communication Technology，通信技术）与IT（ InformationTechnology，信息技术，这里主要是云计算）融合的产物。其次，云网络其实一种是网络服务，也是一张面向企业租户和应用的虚拟网络。最后，云网络是数字经济的连接，连接计算、存储、数据库等等，也连接企业/IDC/总部/分支/IoT终端/个人移动端等等。云网络和传统网络的最大区别是云网络具备共享/弹性/自助服务/按需等云的特征[1] 在云计算时代，云网络是基石，企业上云，网络先行，在企业上云的过程中，根据业务特性利用云网络的能力来构建业务的数据链路，为云上业务的数据传输提供安全可靠的保障是一项不可或缺的能力，在使用云服务的时候，经常会遇到云网络的问题，如何规划好云网络以及使用云网络产品，是本文重点介绍的部分。
随着企业规模的扩大和技术日趋复杂，对生产环境的稳定性需求日益凸显，尤其对于大型互联网企业而言，稳定性的重要性不可忽视。在这一背景下，变更管理显得尤为关键，因为变更通常是导致线上故障的首要因素。据谷歌SRE统计，高达70%的生产事故与线上服务的变更直接相关。因此，防控住变更带来的风险将有助于从源头上杜绝大部分潜在风险，确保企业生产环境的可靠性和稳定性。 本文将基于当下变更管控的困局，引入变更的核心概念定义，然后围绕变更管控的逻辑思考，进而解答变更管控为何要做、如何去做和怎么来做这三个核心问题。最后为大家介绍B站目前的变更管控平台实践情况，期望可以为读者提供一个全新的变更管控思路和启示。
RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的RTC技术一般指的是WebRTC技术。 WebRTC是一个由Google发起的实时通讯解决方案，其中包含视频音频采集，编解码，数据传输，音视频展示等功能，我们可以通过技术快速地构建出一个音视频通讯应用，在不借助中间媒介的情况下，建立点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。虽然其名为WebRTC，但不光支持Web，还可以通过编译C++代码达到全平台的互通。 在 B站的直播业务中，有多个互动类型的业务，比如：视频连线、PK、语聊房、语音连麦等。这类业务都有实时性的要求，底层都采用了WebRTC技术。
作为国内领先的在线视频平台，哔哩哔哩（以下简称“B站”）正经历着业务体量和用户规模的快速增长。随着访问量的持续增长和业务复杂程度的增加，在相对有限的服务器资源下如何优化在线服务性能和提高资源利用率，成为了工程研发团队面临的重要挑战之一。 本文将以笔者所在的商业技术中心为例，重点讨论效果广告引擎的在线推理部分。文章将分享笔者在实际工作中遇到的挑战及相应的优化方案。首先，将介绍项目背景和当前系统的运行状况；接着，将详细探讨性能指标量化、服务调用、CPU计算、内存治理及网络IO等方面的优化策略；最后，将总结对性能优化的一些思考，并展望未来性能优化的方向。本文的目的是回顾并总结当前在线服务性能优化的工作，同时也希望这些经验能为其他研发人员在处理类似问题时提供参考和启发。
在文章的开头，我们可以先来了解一下直播业务的大致业务架构。将直播业务简单分为两大类场景"看播"、"开播"，前者主要面向C端观看用户，后者主要面向B端开播主播。主播通过"开播工具"的开播产品功能，经由"开播平台"完成一系列开播动作，最后将媒体信息采集推送到多媒体服务器，C端观看用户就可以从CDN看到直播的视频流内容。 从数据流向来讲，"开播"场景是产生数据和触发关键事件的源头。这些数据或事件会涉及多个领域，如安全合规信息、房间信息、主播信息、开播场次信息、安全审计信息、多媒体信息等。 打个不太准确的比喻。开播系统对于直播平台的重要性，等同于订单系统对于交易平台的重要性。开播工具作为播端功能入口，直接面向官方开播工具（直播姬、粉版大加号、三方工具如OBS开播）的用户以及内部平台方的用户（其他业务线、产品&运营），对开播体验负责。开播平台在其中的职责，是向开播工具和其他平台方提供开播相关的平台化业务能力，如开关播、开通直播间、切换分区等。
云原生，以容器、不可变基础设施、声明式API等核心技术，实现了业务与硬件及底层架构的分离，使业务实例具备了可移植性、环境一致性，极大地提升了运维效率，降低了线上运维操作的稳定性风险，同时又基于微服务、分布式技术解决了传统架构的单点可靠性问题，提升了业务稳定性和开发效率。近年来，越来越多的应用完成容器化、微服务化改造，并逐步将发布、运维流程迁移到PaaS，这在释放了云原生红利的同时也不可避免的引入了更高的系统复杂度，对生产环境的稳定性也提出了更高的要求。 生产环境的稳定性，是各个互联网行业相关公司都关注的，尤其是对于大型互联网公司来说，稳定性就显得更为重要。以B站为例，从诱发稳定性问题的原因分析来看，2022年至今变更及编码问题所占据的比例，在70%以上，问题的诱因也多种多样，譬如缺少稳定性相关必要的可观测指标、灰度观察过程缺失、故障处理机制不完善等等。同时，随着业务体量的不断增大，组织划分与团队协作关系也变得日益复杂，加剧了沟通成本，也间接导致了变更问题难以管控。 对于稳定性来说，业界的一个共识是：防控住变更风险，稳定性问题就解决了一半以上。
接口反爬，或者说更广义的接口安全，一直以来都是网站和app绕不开的基础问题。尤其是平台的规模扩大，各种功能性的接口包含的信息量越来越多，这也让各种目的的脚本爬虫有了获利的空间和爬取数据的动力。
