在告警方面，基于成功率和失败率的统计，进行实时告警。一出现错误码，微信立即可以收到提醒，提醒说是什么原因导致这次告警，完全全自动。

　　成本优化

　　上线一个月之后，一个坏消息一个好消息。好消息是播放量涨了 4 倍，坏消息是带宽涨了 6 倍，带宽优化是每个做视频的人必须要面临的问题！

　　我们也分析这个过程中的原因，发现因为改为边下边播之后用户观看视频的意愿比较强，用户有挑选心理，不是每个视频都去看，看了一下之后不喜欢就划走了，之前下载的那部分其实是浪费的。

　　如果之前不做限速的话，一点开视频就疯狂地下数据，带宽有多大就下多少的数据，这样浪费很严重。我们采取的第一个策略是进行流量控制。在高峰期播放到第 10 秒时，预下载 N 秒数据，下载到 N 秒就停下来。然后，可以做多级限速。一开始不限速，下载到合适时机做 1 倍码率限速。高峰期时预加载的数据会少一些，防止高峰期时带宽占用明显，这是初级的策略。最终我们也有码率切换的策略。这对用户的观看体验影响比较大，这也是之前必备的一个策略。

　　上线这个策略之后，对带宽的优化还是比较明显的。在高峰期时从 18：00 到凌晨 1 点带宽下降 25.4%，这个是我们不断灰度最终确定的值。这个值会影响播放缓冲，因为数据少的话必定会卡顿，在卡顿之间和流量之间取了一个最优值，最终是 25.4%。

　　但这样肯定是不够的，因为流量涨的还是很明显的，我们想到 H.265，压缩率相对于 H.264 提升了 30%-50%，但它的复杂度也是呈指数级上升。复杂度导致它的编解码耗时更长，占用资源也更长。如果把 H.265 用在客户端上的话，可能要评估一些点，比如说在编码上面，现在手机上没有做 H.265 硬件支持的，相对于 H.264 的耗时 3-7 倍，之前耗时可能是 10 分钟，而现在可能需要到 70 分钟左右。

　　解码的硬件支持 H.265 的也很少，耗时差不多是一样的。解码是可行的，你可以采用软解的方式，这个带来的问题是 CPU 占用非常高，可能之前 H.264 占 20% 的 CPU，H.265 占 70%、80% 左右，带来的问题是发热和耗电。

　　结论，解码是可行的，但是编码不用考虑，在移动客户端不可行的情况下，那编码就要放在后台来做了。

　　为了解决如何在我们手机上能够解码的问题，对手机的解码能力做一次评估。我在合适的时机做一次大规模的浮点数运算，将数据上传到后台服务器进行云适配。如果当前的指数满足 H.265 条件的话，可以给你下载 H.265 视频给你播放。从而保证软件解码柔性可用，针对视频源规格按机型适配降级，保证用户视频播放体验。

　　经过评估之后，判断当前机型更适合 360P 还是 480P 等等，保证如果手机不适合 H.265 就不会给你的手机下发 H.265 视频的。

　　经过我们的统计，外网上有 94% 的手机还是支持 H.265 解码的。支持 1080P 手机的解码占 46%。

　　编码只能在后台做，如果在视频后台进行全面编码的话，是不现实的。因为编码复杂度呈指数级上升，直播，拿后台服务器进行编码也是不可行的。我们的做法是只用热点视频进行后台转码，不是所有视频都去编码，对观看量在 TOP N 的视频进行编码，只需要编码少量的视频就可以带来流量优化效果，因为 TOP N 就占了全网 80-90% 的流量，只对少量的视频进行解码，让 90% 的视频享受转码的优势。