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

原创

于 2023-03-22 12:00:29 发布 · 3.5k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#音视频 #媒体 #自动化 #运维

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

动手点关注

干货不迷路

背景

每天在世界各地都有海量用户在短视频 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 个，此外还需考虑相关的基础设施的监控，如：数据库、缓存、分布式锁以及消息队列等......

图 4：数量庞大的微服务监控仪表板

因此，即使制作了如上图全局视角的监控仪表板，但在应急事件发生的当下就能迅速的定位如此庞大的服务拓扑中的异常点，仍然是一个具有挑战的任务。

不同指标比较基准不同

对于应急事件发生时，通常可以分为以下两种情况：基础设施异常、突发流量。

第一个例子：数据库基础设施。通常在正常运作下的查询延迟都会处于一个固定的水平，例如 10ms 。延迟上升分为：整体数据库延迟上升（可能是当下负载高），部分实例延迟上升（可能是部门网段有抖动）。

图 5：数据库延迟异常指标

第二个例子，突发流量。作为一个内部的 PaaS 平台，势必是提供了多租户的功能以服务字节内诸多团队的需求，且当租户数量达到一个量级，逐个租户去了解他们何时有活动或是有突发流量已经是不太合乎经济效益的事情，以下方的例子为例，可以看到指标呈现以天为周期的规律分布，但可以看到红框处紫色的指标较昨天明显得更多，这称之为昨日同比上升。

图 6：流量指标同比上升

错误排查涉及不同内部系统

第三个例子，涉及依赖系统的错误。以下图为例，红框处的错误量明显比过去半小时要高得多，这称之为环比上升。针对这种情况则需要到内部的 PaaS 平台去查询详细的错误码以及对应的错误日志。

图 7：依赖系统错误指标环比上升

目标

以上三种情况，以现有的监控以及排查手段，在应急事件发生时，整个排查的过程需要比对多个仪表板甚至是不停地在仪表板上切换不同的查询时间段来比较指标的正常性，更甚者需要打开其他内部系统来查找日志，这都大大延长了定位问题以及做应急处理的决策时间。

因此如果能够把上面的排查工作做一定程度的自动化，那就能大大提高 SRE 成员在值班时对照值班手册 SOP（标准作业流程）来排查的速度，并能减少值班的辛苦感受。

量化指标

平均修复时间（Mean time to repair，MTTR）包含了发现故障（Identify）、故障定位止损（Know）以及故障恢复（Fix）的整体时间。导入自动化排查工具的主要目的是减少故障定位止损的时间，目前系统都有设定针对 SLO 目标的告警发生以及恢复时间的数据统计，因此决定以 MTTR 这个指标来作为这次自动化系统导入的成果量化指标。