讲师：freyli
在介绍控制后台部分之前，先简单回顾下项目的时间线：
10月25日，意向、调研、策划、沟通
11月24日，第一次技术初审
12月7日，互动形态框架确定，时间轴初现
12月15日，互动需求初步敲定，明确操控后台需求
12月26日，客户端封版，第一次演习
1月，后台开发迭代，周度演习。
2月12日/15日，预热。
2月14日/16日，进场联排。
2月18日，实战。
我们前面互动策划的时间花的比较多，因为涉及多方磨合。确定互动后，为了确保覆盖量，客户端开发的节奏超快，两周内搞定这个大版本。后台部分工作量巨大，但开发同学在一个月内加班加点搞定了后台系统的改造，最后抗住了峰值，确保项目呈现。整体节奏是比较紧张的。
春晚控制后台主要解决当晚和现场直播时间点相关的一些变更操作，比如节目单正在播放、红包切合口播时间下发之类。
相比面向用户端的互动策划来说，控制后台部分酷值就下降很多，需求来的比较直接，主要是解决业务如何更好的实现的问题，确保技术实现和人员操作都简单可靠。互动形态给控制后台提出的关键任务有一下几项：
整个春晚互动，要求在不同时间段出现不同的互动类型。
场景变更的时间点要严格匹配主持人的口播。
节目组拜年的互动形式是看春晚时候，摇一摇，可以出现当前节目演员的拜年页面。
要求与节目强关联，某个节目出现的时候，对应的节目组拜年也要跟着变换。
一旦节目顺序调整或者节目删减，节目组拜年的素材也要相应变化。
一个节目和拜年素材是否一一对应？
素材需要提前推送，但是页面上展示的节目名称可能会有调整。
节目单是在互动策划的后台加入的一个很小的功能，起初只是打算摇出一个页面，展示当晚的节目单，后来大家觉得要做实时展现，这样实时的体验更强。
和节目组拜年需求很相似，能否捆绑？
对于串场的节目在节目单上如何展现
节目单会展示整个节目队列，删减的节目如何处理
最初倒计时的用途只是在互动页面顶部展示距离抢红包时间还有多久，目的是把平时的人流量积累到抢红包的高峰时段。但在2月17日的时候，后台开发同学仔细反复地review整个系统的设计，发现最重要的抢红包时刻的开启是风险最大的点，一旦切换操作因某些意外因
素导致失败，将会导致整场互动功亏一篑。经评估后，我们把开启红包场景的方案调整为倒计时归零就自动开启，设定的时间段到期后自动结束。新的方案消除了高峰时刻无法开启红包场景的风险，但相比之下也带来了新的难点。
原需求：仅用于互动页面顶部展示距离抢红包的倒计时，为高峰时刻积攒人流量。
临危受命新使命：倒计时归零，就开启红包。内心的感觉—>“火箭发射的倒计时指令”
新使命带来的问题：如何给出最准确的倒计时？
节目组拜年的H5页面、节目单、还有页面上展示赞助商权益的赞助商logo素材，都需要提前上传，维护关联关系。
1、接着前一步的关键任务，我们很快梳理出了控制后台的功能框架，主要两部分：
素材管理：
节目组拜年素材
节目单
赞助商
现场控制：
粗时间轴——场景切换
细时间轴——节目单、节目组拜年的切换
节目单顺序调整
倒计时
紧急页面——用于时间轴切错后的补救。开启紧急页面状态后，会关闭和时间相关的互动，调整完毕后，可以关闭紧急页面，恢复正常状态。
在此基础上，为了确保多人同时操作后台不出错，还增加了版本控制等高级功能。当晚也是通过变更操作的版本号，和广州后台同事核对验证每一次的变更操作。
2、对于前面任务梳理环节提出的问题，我们也敲定了解决方案。
节目组拜年和节目单：
节目组拜年和节目单绑定，二者必须一一对应。
通过细时间轴切换确保二者和节目播放时间的强关联。
每一个节目对应一个H5素材。如果一个节目里面有多个明星，需拍摄多套素材，就通过H5页面实现多套图片和语音素材的随机轮播逻辑，对于后台系统而言，还是一个H5素材。如果某些节目没收集到明星拜年素材，就使用春晚主持人拍摄的素材来补位。
节目组拜年素材上的文字部分做成js配置文件，放到服务端，如果有更新，可以在摇的时候，在线拉取最新的文案内容，大小仅几KB，量级很轻。
节目单上节目删减。后台在调整节目顺序的基础上，增加了禁用节目的功能，一旦禁用，就不展示在节目单上。
红包倒计时开启抢红包的新方案产生的问题：
在后台系统设计层面，没办法优化。只能通过提前研究彩排节目，仔细估算节目时间点，来确保当晚直播时，可以快速响应节目时间的变化，下发最精准的红包时刻。
春晚的互动策划其实算不上完美，从10月底开始，我们持续做了两个多月，一直在变更磨合。如果用做饭来类比的话，春晚互动项目最后给我最大的感觉是像在做飞机餐，这其中要权衡的太多，用户、电视台广告部、导演组、技术层面超高并发下如何确保不挂和最优的体验等等。从最初开始以纯用户视角去自由策划的自命题作文、渐渐演变成迎合导演组口味的命题作文，再往后我们试着提推荐的方案去引导导演组接受。好在大家都很投入的去把这个事情做好，最后呈现出来的，也算是一份完美的飞机餐。
正常情况下，电视的直播，会故意晚30秒左右，确保一旦出现问题，可以有时间在直播源头做调整。这种模式下，我们可以根据现场播放的精确的时间，提前30秒的时间下发最精确的时间。但15年的春晚，采用了0延迟直播的模式，所以只能靠估算。我们倒计时估算的原则是可以早，但不可晚。因为一旦电视上，主持人说开始抢的时候，还没发摇出红包的话，体验就比较差，但如果提前出现，用户可以理解为自己的延迟，相比之下好一些。所以这个地方，我们把估算的时间点有意提早一些。
在当晚直播的时候，我们拿到了节目的串联单，列了每个节目表演的时长、开始时间、结束时间。每个节目下场的时候，我们会估算新的延迟，推算新的倒计时时间点。在10:20左右，红包时刻前最后一个语言类节目结束，我们终于敲定了最后的倒计时时间，最后红包在我们预料的时间点内下发，还算比较完美。
由于电视台侧的配合原因，采集节目组拜年开始的比较晚，基本是从14号白天才开始采集素材。晚上10点半结束原始素材的采集。14号连夜，经过“图片和语言素材制作—>H5开发生成页面—>测试验证页面—>H5页面打包—>上传至后台—>同步到客户端后台—>资源校验—>推送”这么一系列的工作流程，在15日下午，终于完成了全部65个素材的推送工作。背后是相关的设计、开发、构建、测试、后台多部门同学的彻夜不眠。当然，这只是春晚项目一个小功能环节的缩影。
在文章的最后，要向参与项目支持的开发、测试、设计还有产品等同学表达谢意，这是一个多部门联动的超大项目，所有人的齐心协力协同作战才确保了项目的完美呈现。希望以后还有机会，大家可以一起做的更好！
