短视频媒体处理系统应急响应自动化实践

字节跳动技术团队

于 2023-03-22 12:00:29 发布

阅读量3.4k

点赞数 1

文章标签：音视频媒体自动化运维

本文链接：https://blog.csdn.net/ByteDanceTech/article/details/129722567

版权

文章描述了一个多媒体处理PaaS平台，用于视频转码和内容分发。为解决大量微服务和复杂依赖带来的监控和故障排查难题，平台引入了自动化工作流，包括Metrics查询、分析和错误排查，以减少MTTR，提高应急响应速度。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

动手点关注

干货不迷路

背景

每天在世界各地都有海量用户在短视频 App 上分享充满创意的视频或是生活中的精彩故事。

由于使用者所在的环境不可控（高铁、电梯等弱网环境），若直接播放原始画质的视频，可能导致观看影片的过程中出现卡顿甚至无法播放的情形，导致观影感受不佳。为了让不同网络条件的使用者，都能顺畅地观看这些视频，每一条视频的发布，都需要经过转码的过程，生成不同档位的视频，即使用户在网络不好的环境中，也能提供适合档位的视频，让使用者有顺畅的观影体验。

针对视频转码的场景，目前业界通用的解决方案大多为原始视频上传到物件储存后，通过事件触发媒体处理过程，当中可能涉及使用工作流系统做媒体处理任务的调度或是编排，处理完成的视频存档至物件储存后再透过内容分发网络（Content Delivery Network，CDN）分发给观影者。

图 1：媒体处理系统在 AWS 公有云上的业界通用解决方案

[来源]https://aws.amazon.com/media-services

在业界通用的公有云解决方案中，对开发者而言需要整合公有云上各个子系统，来完成视频转码的生命周期，以及管理虚拟机计算资源，这需要较大的认知成本以及对各种云服务的学习成本，对开发者来说是比较大的负担。

在字节，视频架构团队经过长年的技术积累，在视频这个领域已经形成了一个内部多媒体处理 PaaS 平台。用户通过上传系统上传视频到物件储存中，接着会触发媒体处理平台的任务编排系统，下发转码、生成动图、封面照等任务到具有海量资源的计算资源池，最后透过内容分发网络分发给观影者。多媒体处理 PaaS 平台主要由两大子系统构成，工作流系统与计算平台，并提供多租户的接入方式，用以支撑字节整个生态系的视频处理需求。

计算平台主要提供了一个大型的计算资源池，将各种异构资源（CPU、GPU）封装起来，让团队内媒体处理专业的开发者无需关注计算资源整合相关工作，可以专注于开发具有各种原子能力的无伺服器函数，提供转码、生成封面照、生成动图等丰富功能。工作流系统则提供了任务编排的能力，能够定义视频上传后需要执行各种媒体处理任务的先后顺序，并将任务下发到计算平台利用大型的计算资源池来完成媒体处理的工作。

透过这两大子系统提供的基础能力，可以大大减少开发者的负担以及提高功能迭代的速度。

图 2：视频架构团队媒体处理系统解决方案

技术框架 1.0

这么庞大的一个线上系统，如何保持它的稳定性，并且在线上有任何异常情况时，能够准确、快速地处理问题，减少对用户的影响就显得特别重要。针对部署在世界各地的多媒体处理 PaaS 平台都会定义服务水准指标 (SLI)，并以此为基础定义服务水准目标 (SLO)，并配置针对 SLO 的适当报警规则。

图 3：应急响应流程

如图 3 所示，当服务发生异常，例如：5分钟内请求正确率低于 99.9% 时，触发报警，并发送 Webhook 消息给团队内研发的应急响应中心平台，平台会将当下的值班人员创立一个告警处理群组，并把后续相关的报警信息都聚合到群组中，随后就由 SRE 开始介入处理。当前流程在创建告警处理群组之后，主要仰赖 SRE 去自主搜集与应急事件相关的异常指标，缺乏自动化工具提前做讯息的汇总，可能导致整体事故处理流程需要花费较多时间先梳理目前异常的指标才能做事故止损操作。

当前的痛点

微服务及依赖数量多

在团队中，服务的开发大部分走的是微服务架构，并且作为一个内部的 PaaS 平台，势必得提供全球跨区域的服务因此在服务本身以及基础设施方面，需要有多区域以及多机房的部署。目前只看单一区域媒体处理任务调度的微服务就有 30 个，此外还需考虑相关的基础设施的监控，如：数据库、缓存、分布式锁以及消息队列等......