我与云栖

梦康 2022-12-31 10:33:08 402

来公司马上7个年头了,没想到一直都断断续续在支线支撑某大会的工作。从最初边缘支持到所有线上系统的支持。

最初只是将直播供应商的回放视频从他们的 OSS 迁移到我们的 OSS 中,然后做 CDN 加速展示在网页中。到后来协助我组的同事带领一家供应商公司开发线上系统。我参与度很低,压力也很小。只记得大会期间需要参与护航,其实就是出差过去逛展了。

直到2020年,疫情原因,大会前半年,需要一场大规模的线上峰会。并行场次100+ 并且都是录播转直播。本以为一切很简单,准备工作我自认为做的非常好了,想了很多管理后台工具来监控线上的情况。

  1. 对每日直播梳理一个进程表(类似于甘特图),可以安排人更好的监管直播,在哪些时刻去关注哪个直播的启停状态;
  2. 对直播进行编排,9个成一组,一组分为一主一备;
  3. 购买了电脑支架,申请电脑、会议室用于监控。

但当我开始执行直播演练时,遇到了无数的问题,10场直播是没问题的,但是100场就有问题了。

  1. 办公室带宽不够;
  2. 接口调用的限流,不得不让我一次直播测试的启动就需要耗费20分钟;
  3. 直播流的并行数也到达了上限;
  4. 导播台数量也到达了阈值;
  5. 云导播台节目单 bug 在这么多导播台并发切换的场景下,总是会失败一小部分,通宵达旦弄了三天,但是都得不到对应部门人的响应和支持,直达大会结束这个 bug 也没能解决。

虽然大会顺利结束,我的兜底方案很成功,这个事情我时常会反复想起:

当年我的想法是,云产品这么垃圾,响应这么慢,我自己买几十台台ecs自己部署ffmpeg来推流也行。用完销毁就行,何必受这种有力使不出的气呢。

现在看这种什么事都想闭门造车的作法太不好,太危险。

去年我会想,先跟业务部门反馈,云产品部门不配合,有bug,需要外部采购。外部调研做的不够,内部不支持,其实不就是因为在内部合作不赚钱,不是大客户吗,如果我们花钱外采,肯定事半功倍,这又何方呢?而且他们更加专注和垂直。这是非常严重的一次方向错误的坚持和自己挑战

风险上报,申请资金,花钱请求外部公司解决风险,求稳。

现在我可能会多想一点,作为我的一二三级主管都在当时沟通群里,看到对面没有时间投入配合,应该主动的去拉通,而不是一直让我们最前线的人去施压,基本等于无效工作。