随着公司业务的不断扩张，用户流量不断提升，研发体系的规模和复杂性也随之增加，线上服务的稳定性也越来越重要，因此有必要搭建一个提供安全、高效、基于生产环境的故障演练系统，为线上服务保驾护航。 关于故障演练的建设理念，业界已经有了非常多的文章，但是涉及到具体的技术实现方面与落地，很少介绍。本文将基于故障演练系统，从设计到落地整个实践过程，来详细介绍下故障演练系统是具体如何设计，以及如何落地的。 对于容器级别的故障，我司已经有了较为成熟的产品混沌实验平台，但是针对我们电商事业部（主要语言为 Java），依旧有不少痛点问题无法避免，例如在实验时想对特殊用户产生故障行为，针对自动化测试平台的请求产生故障行为，在使用 RPC 组件调用下游时可以针对具体请求产生故障行为等，基于此我们研发了基于 Java 场景的故障演练平台。
高仿真用户行为模拟可以使业务质量保障更加充分，优秀的程序设计也绝不会忽略功能在不同软硬件设备上的适配表现。所以，测试通常会引入兼容性测试、网络模拟测试、虚拟机测试等。这样不可避免的，会用到大量公共测试资源，如 机器设备（手机/主机等）、特征账号、虚拟资产......团队越庞大，资源越多，资源管理的难度就会越高，面临的异常问题也会越多。 伽利略曾提出一个“规模法则”，表达了如下观点：世间万事万物，都不能按照简单的线性关系放大。一个常见的例子就是，一颗树的长大，随着它越长越高，所关系到的体积和树干的承重力都是呈超线性关系增长的。团队里资源管理也是一样的，随着业务扩张，资源量增加，面临的问题和考验也是呈超线性关系增长的。 一些团队在规模较小的时候，使用手动管理的方式进行资源管理，但随着业务扩张，资源量达到一定程度的时候，手动进行资源管理就越发步履维艰。
B站游戏中心是一个游戏分发平台，它提供游戏下载、游戏评测、游戏攻略和游戏活动等相关内容，用户可以在这里找到各种优秀的游戏作品，预约测试，下载资源，以及参与游戏社区的互动。
笔者前段时间的工作中，某业务因为一行闭包错误使用的代码，引起了一次“血案”。闭包是一个函数及其相关的引用环境，可以捕获和记住函数定义时的状态信息并在函数执行时使用。 看一个例子：生活中我们在快餐店点餐时都会有点餐的号码，一般从1开始计数，每次顾客点餐时编号都会增加1，当两个顾客同时点餐的时候为了避免他们可能会得到相同的编号，就可以使用到闭包。Go语言提供了对闭包的支持，上述例子可以看到它在某些场景下是有作用的，但如果不小心，还是会踩坑的哦～ 本文会从golang闭包的基础知识、常见踩坑指南等方向解析，如果你也遇到过相同的问题为之困惑，欢迎阅读本文，跟我一起重新认识闭包正确使用姿势～
随着虚拟开播在B站等平台的火爆，越来越多的用户和主播对虚拟直播产生了浓厚的兴趣。3D写实风格的虚拟人不仅视觉效果出众，还能提供沉浸式的直播体验，为用户带来全新的观看感受。如抖音推出的3D超写实虚拟主播令颜欢，出道一周粉丝就突破了60万，全网视频播放量破亿，直播间更是突破了百万人次的场观水平。3D写实风格的虚拟人有望成为未来虚拟直播领域的市场趋势。
当我们在面对一些用户反馈的运行问题时，如白屏，页面加载时间过长，页面卡顿等等，如果能够知道客户端的哪些行为导致了问题的出现，那么在定位解决问题上一定会变得事半功倍。 如客户端白屏可能是某个静态资源挂了，页面加载时间过长可能是静态资源的cdn托管服务不稳定，页面卡顿可能是长耗时的js调用导致阻塞了主线程，为了帮助开发快速收集问题出现时客户端所发生的上下文信息
Monorepo 和 Bazel 给我们带了很多优势，比如快速、正确、易扩展、易协作等。虽然 Bazel 早期版本对于 iOS 开发并不太友好，甚至让一些团队产生了放弃使用 Bazel 的想法；但 Bazel 本身极其优秀的扩展性，使得社区对其一直抱有极高的热情，开发出了许多优秀的 Rules，促使社区和 Bazel 本身一直向前进化，如今的 Bazel 已不同往日，一些早期令人诟病的问题也被一一解决。目前我们正在使用 Bazel 6.1.2 版本，且即将紧跟官方的脚步更新到 6.3.0 版本。今天我们就来聊聊我们哔哩哔哩近一年（主要是Bazel 5.0.0 版本以后）所应用的一些新特性、新 rules 以及在自建 rules 方面的探索。
根据2022年第四季度的财报数据显示，B站在跨年晚会期间的直播人气峰值达到了3.3亿。直播业务对于B站来说是一个重要的增长点，而道具投喂（赠送礼物，后面统称为道具投喂，礼物统称为道具）在直播业务中扮演着重要的角色。在本文中，我们将介绍如何确保直播道具相关系统的高可用性，以实现99.99%的稳定性目标。文章将分为三个部分，分别是道具面板，道具投喂和多活。
