本次的描述的主体是指发生在 2021 年 7 月 13 日晚上 23 点左右的，无响应时间持续约半小时左右，完全恢复时间约8小时的宕机事件。
本文内容是作者依据网上公开信息和个人在当时的体验综合分析而来，精确的时间线可能存在一定程度的错漏，仅代表作者本人的观点，如有雷同，纯属巧合。
事件还原
惭愧，当时就想写来着，结果一忙又忘了，刚刚才突然想起这回事儿，赶紧仔细回忆了下当晚的亲身经历，结合B站一位网友的总结，拉出了我自己感知到的时间线，下面我们先来还原一下整个过程：
- 22:40 上传服务 502 ，主站访问正常。
- 22:53 主站 502 。
- 23:01 主站 404 ，此时网友发现，豆瓣、A站也疑似挂掉。
- 23:05 有过短暂的恢复，很快又挂掉。
- 23:14 主站页面可以显示，但是视频仍然无法加载。
- 23:31 B站主站基本恢复，并且大部分视频已经可以正常播放，推荐功能还未回复，首页不符合日常习惯。
- 00:12 除了个人中心、投稿、直播等功能无法使用外，其余功能基本已经恢复。
- 00:31 第一次登入个人中心！可惜随后又出现 502 错误。
- 00:45 测试发现网页端点击评论区里的时间轴跳转链接不会跳转，可能是换了旧版本。
- 00:53 客户端依然显示数据格式错误，网页端依然 502 。
- 00:57 个人中心大部分功能已基本恢复，但是投稿管理、粉丝勋章、钱包管理等功能仍然无法使用。
- 02:20 B站官方号 哔哩哔哩弹幕网 发布公告：
昨晚，B站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。
耽误大家看视频了，对不起！ - 06:48 此时B站功能已经彻底全部恢复正常。本次服务器宕机事件结束。
迟来两个月的分析
事件分析
实际看来，紧张的处理集中在 22:40 到 23:14 ，后续的就属于已经走上正轨了，所以我们重点分析这段时间。
22:40 上传服务 502 ，主站访问正常。
根据实际宕机的情况来看，这个时间点应该是部分服务挂掉，这里应该就是官方公告所说的“机房故障”导致的。22:53 主站 502 。
服务逐步的挂（这种表现来看，可能是火灾？脑补服务器一片一片的被点着），主站服务也挂了，这时候主站也变现为 502。23:01 主站 404 ，此时网友发现，豆瓣、A站也疑似挂掉。
负载均衡也挂了，主站 404，同时间豆瓣和A站也挂掉了，网友戏称是B站宕机，巨大的流量降级压挂了友商，实际这个可能性不大，目前看来最靠谱的解释是，三家公司租用了同一家机房，一损俱损。23:05 有过短暂的恢复，很快又挂掉。
短时间的恢复又挂掉，如果机房的问题是物理损坏，那这里启动的应该是冷备，如果只是断电且无UPS或者UPS状态异常，那可能就是启动了原服务，之所以恢复又挂掉，合理的推测是缓存没有准备好，用户又在不断地刷新，人工DDOS，服务刚起来，整个又给打挂了。23:14 主站页面可以显示，但是视频仍然无法加载。
推测是重启之后又进行了一些流量重放来预热，再慢慢调整负载把真实流量放进来。
事件后看来十分打脸的分享
bilibili 的技术总监毛剑曾在腾讯云做过一次分享：bilibili技术总监毛剑：B站高可用架构实践，阐述了B站的高可用架构实践，为我们本次宕机分析提供了部分素材。
通过分享的内容我们可以抓住 bilibili 架构的几个关键词：多集群、多层负载均衡、分布式限流、超时控制、重试退避。
PS：根据分享中提到的架构和实际对B站规模的感知，分析B站应该是有四位数以上服务器的集群。
问题复盘
从毛剑的分享来看，bilibili 的高可用架构已经比较完善了，但是这次事件反映出一个很大的问题就是，有高可用，无容灾，他的所谓高可用都是在基础设施服务正常的前提下的，私以为直接归类到高性能也很合适，缺乏真正的高可用。遇到了这种针对硬件的物理不可抗力，在 bilibili 很明显是没有做异地多活和多机房的情况下，发生了停机半小时，无法正常提供服务接近八小时的严重事故。如果按八小时来算，今年别说4个9了，3个9都有点危险。
就 bilibili 事件来老生常谈一下业务系统高可用问题，当前实施高可用的经典方法依然是冗余，冗余越多，越能抵抗不可抗力。但是冗余往往代表着巨大的成本，系统可用性指数每增加一个9，需要的成本都是指数级的。
根据 bilibili 3 月 31 日发布的财报，2021 年依旧净亏损了 11.218 亿元人民币。
或许这才是 bilibili 此次宕机的真正元凶？
