昨晚我差点破防，蘑菇视频的稳定性问题我终于定位到原因了

昨晚真是差点破防——整整一个晚上的排查让我把蘑菇视频那起间歇性掉线、卡顿和 5xx 激增的问题定位清楚了。把过程和落地的解决方案写出来，一方面给自己做个记录，另一方面也希望正在被类似症状折磨的人能少走弯路。

发生了什么

• 时间点：晚高峰开始后（18:30–20:30），用户反馈视频播放卡顿、刷新失败率飙升，监控里 502/504、后端超时、转码 worker 重启次数明显上升。
• 表现：前端重连频繁、媒体资源加载超时、点播生成的播放列表偶发缺段。
• 初步排查：CDN 和前端没有大范围异常，错误集中在转码/分发链路的边缘服务和上传处理部分。

复现与定位思路（我就是按这个顺序排的）

1. 复现压力测试：模拟 200–500 并发上传 + 播放请求，观察指标和日志的联动。
2. 读日志与追踪链路：查看转码进程（ffmpeg/segmenter）崩溃日志、Nginx error_log、应用层异常堆栈，结合分布式 trace 定位延迟点。
3. 系统层面核查：检查 open file count、inode 使用、OOM、CPU 与 I/O 等，确认是否有资源耗尽或短时爆发。
4. 小范围回滚与增量变更测试：回滚最近 2 周对上传模块的改动，验证症状是否消失。

关键发现（抓到了那个“怪病根”）

• 在上传模块里有一次不太明显的改动：把临时分片写入逻辑改成了“追加 + 延迟清理”的模式，期望减少重试时的 I/O。但是这段逻辑在异常路径没有保证文件描述符一定被 close，遇到高并发重试时会产生文件描述符泄漏。
• 同时，HLS 分片器在并发高时会创建大量短寿命小文件，原本系统对 open file 的限制偏保守（ulimit 和容器内限制都偏低），两者叠加导致进程很容易 hit EMFILE，出现系统级返回 502/503。
• 另一个放大因素是上传端的重试策略：在网络抖动时采用指数回退但没有全局并发控制，导致瞬时并发数翻倍，进一步触发了上述资源耗尽问题。

修复措施（立刻上线的与中长期的） 短期（紧急补丁）

• 回滚上传逻辑到安全实现，确保所有异常分支里有显式 close() / cleanup。
• 在关键服务进程里增加文件描述符保护：在上传/分片入口处用信号量限流（max open files per worker），避免单个进程耗尽系统资源。
• 临时提升容器/主机的 ulimit 到合理值（作为缓冲），并重启受影响服务以释放泄漏的 fd。

中长期（稳健与可观测性提升）

• 把上传与分片处理改成 RAII 风格（或 try-finally）保证资源释放，增加单元测试覆盖“失败/重试”分支。
• 在上传与转码链路加入 backpressure：中央队列/令牌桶限制全局并发上传数，避免客户端重试洪峰造成幂等故障。
• 增加监控指标：open file count、inode 使用率、每个 worker 的文件打开增长速率、短时重试率。把这些做成告警阈值，和 5xx/延迟一起作为 SLO 监控。
• 优化 HLS 分片策略：合理调整 segment 时长与切片合并策略，减少短文件数量与元数据操作频次。
• 走 Canary 和灰度发布路径，先在 5% 机器上验证修复效果，观察 24 小时后再全量。

效果与数据（上线后的变化）

• 502/504 请求率从高峰期的 6.2% 降到 0.4%。
• 平均 CPU 峰值回落，转码进程重启次数归零。
• 用户端播放成功率在受影响的区域提升了约 11%，相关客服工单数明显下降。

我学到了什么（几点经验）

• 小改动的“异常路径”细节能一夜把系统拖垮；凡是和资源（fd、内存、线程）相关的修改，务必把失败路径写成第一优先级。
• 可观测性要跟随系统复杂度同步升级。没有对应的告警和指标，问题一出现就是盲打。
• 灰度、限流、熔断这些防护措施不是多此一举，而是系统面对真实网络波动时的免疫力。

如果你也遇到类似问题，先看三样东西：open file/inode 使用、异常分支的资源释放、重试策略是否有全局限流。把这三点作为排查起点，能省很多时间。

给自己点个赞：虽然差点破防，但把根因钉住、把修复打到生产并看到指标回稳，那种从“糟糕”到“稳定”的落差，爽得很。下一步会把这次经历写成内部故障回顾文档，防止同类问题再犯。