在开发新项目或需求的过程中，前端开发通常需要经历一个物料收集阶段。这一阶段的核心目标是寻找是否已存在可复用的组件，这些组件可能以 npm 包、UMD 组件或 SVG 图标的形式存在。然而，在收集这些物料时，我们常面临以下挑战：如何判断公司内部是否有推荐的公共基础库来实现特定功能（例如唤端）？当了解到某个组件可能满足当前需求时，如何快速找到该组件的使用文档 ？此前，前端开发人员多通过咨询同事或查阅过往相似功能代码来确定所需组件，这种方式效率较低。对于组件相关文档，若为 npm 包，虽可通过公司内部搭建的 cnpm 系统搜索查阅 readme 文档，但 UMD 组件的文档却分散于各个 info 文档中，检索极为不便。
自1965年戈登·摩尔提出摩尔定律以来，半导体行业持续推动芯片技术的革新，IDC（互联网数据中心）为平衡成本效益和多样化需求，逐渐形成了包含Intel、AMD、ARM等多种架构的混合部署模式。早期IDC往往通过小集群分别管理，这种方式虽然简单，但随着硬件代际和架构的增多，资源隔离问题日益凸显，不同集群间的计算资源无法共享，导致资源利用困难、运营成本上升。为解决这一问题，业界开始采用资源合池技术。该技术通过虚拟化、容器化和智能调度系统，将不同架构、不同代次的硬件资源抽象成统一的资源池，打破物理集群的界限，实现计算、存储和网络资源的全局共享。这种方式不仅提高了资源利用率，还降低了管理复杂度，使IDC能够更灵活地应对动态负载，支持弹性扩展，最大化数据中心的整体计算能力。
最近在哔哩哔哩，我们开发了一种改进的 BBR 拥塞控制算法，需要在真实环境中进行测试。该算法本身以内核模块的形式存在，因此将其安装到服务器上不是问题。然而，在快节奏的迭代过程中，我们遇到了一系列问题，最终发现了一个内核错误。本文将带您了解我们解决问题的整个过程，从拥塞控制算法热交换到内核错误修复。下方列出了本文所处的实验环境，可以帮助您复现实验。
本篇为KMP技术的技术及实践系列文章的第三篇。在这篇文章中我们以一个实际业务视角，总结我们在使用 KMP 的 Share Logic 和 Share UI 两种模式在三端落地的经验与 infra 工程建设的互补。
随着B站业务的快速发展，用户规模和内容生态不断扩展，平台的技术架构也在不断演进。伴随着这一增长，服务器数量呈现出爆发式增长，支撑起了海量用户请求和复杂的业务场景。然而，随着机器规模的持续扩大，服务器故障管理面临的挑战也愈发严峻。人工处理效率低：传统的人工故障排查和修复方式难以应对如此庞大的服务器规模。工具链分散：由于硬件故障的多样性，不同硬件需要不同的工具，导致运维团队需要频繁切换工具，增加了排查的复杂性和时间成本。在这样的背景下，如何高效地进行服务器故障管理，成为保障平台稳定性和提升用户体验的关键课题。本文将详细介绍我们在服务器故障管理中的实践与探索。
