講師：freyli

?

項目歷程簡介

?

在介紹控制后臺部分之前，先簡單回顧下項目的時間線：

?

10月25日，意向、調研、策劃、溝通

11月24日，第一次技術初審

12月7日，互動形態框架確定，時間軸初現

12月15日，互動需求初步敲定，明確操控后臺需求

12月26日，客戶端封版，第一次演習

1月，后臺開發迭代，周度演習。

2月12日/15日，預熱。

2月14日/16日，進場聯排。

2月18日，實戰。

?

我們前面互動策劃的時間花的比較多，因為涉及多方磨合。確定互動后，為了確保覆蓋量，客戶端開發的節奏超快，兩周內搞定這個大版本。后臺部分工作量巨大，但開發同學在一個月內加班加點搞定了后臺系統的改造，最后抗住了峰值，確保項目呈現。整體節奏是比較緊張的。

?

春晚控制后臺的關鍵任務

?

春晚控制后臺主要解決當晚和現場直播時間點相關的一些變更操作，比如節目單正在播放、紅包切合口播時間下發之類。

?

相比面向用戶端的互動策劃來說，控制后臺部分酷值就下降很多，需求來的比較直接，主要是解決業務如何更好的實現的問題，確保技術實現和人員操作都簡單可靠。互動形態給控制后臺提出的關鍵任務有一下幾項：

?

1場景切換

?

• 整個春晚互動，要求在不同時間段出現不同的互動類型。

• 場景變更的時間點要嚴格匹配主持人的口播。

?

2節目組拜年

?

節目組拜年的互動形式是看春晚時候，搖一搖，可以出現當前節目演員的拜年頁面。

?

• 要求與節目強關聯，某個節目出現的時候，對應的節目組拜年也要跟著變換。

• 一旦節目順序調整或者節目刪減，節目組拜年的素材也要相應變化。

• 一個節目和拜年素材是否一一對應？

• 素材需要提前推送，但是頁面上展示的節目名稱可能會有調整。

?

3節目單&正在播放

?

節目單是在互動策劃的后臺加入的一個很小的功能，起初只是打算搖出一個頁面，展示當晚的節目單，后來大家覺得要做實時展現，這樣實時的體驗更強。

?

• 和節目組拜年需求很相似，能否捆綁？

• 對于串場的節目在節目單上如何展現

• 節目單會展示整個節目隊列，刪減的節目如何處理

?

4紅包倒計時

?

?

最初倒計時的用途只是在互動頁面頂部展示距離搶紅包時間還有多久，目的是把平時的人流量積累到搶紅包的高峰時段。但在2月17日的時候，后臺開發同學仔細反復地review整個系統的設計，發現最重要的搶紅包時刻的開啟是風險最大的點，一旦切換操作因某些意外因

?

?

素導致失敗，將會導致整場互動功虧一簣。經評估后，我們把開啟紅包場景的方案調整為倒計時歸零就自動開啟，設定的時間段到期后自動結束。新的方案消除了高峰時刻無法開啟紅包場景的風險，但相比之下也帶來了新的難點。

?

• 原需求：僅用于互動頁面頂部展示距離搶紅包的倒計時，為高峰時刻積攢人流量。

• 臨危受命新使命：倒計時歸零，就開啟紅包。內心的感覺—>“火箭發射的倒計時指令”

• 新使命帶來的問題：如何給出最準確的倒計時？

?

5素材管理

?

節目組拜年的H5頁面、節目單、還有頁面上展示贊助商權益的贊助商logo素材，都需要提前上傳，維護關聯關系。

?

需求梳理和功能呈現

?

1、接著前一步的關鍵任務，我們很快梳理出了控制后臺的功能框架，主要兩部分：

?

素材管理：

?

• 節目組拜年素材

• 節目單

• 贊助商

?

現場控制：

?

• 粗時間軸——場景切換

• 細時間軸——節目單、節目組拜年的切換

• 節目單順序調整

• 倒計時

• 緊急頁面——用于時間軸切錯后的補救。開啟緊急頁面狀態后，會關閉和時間相關的互動，調整完畢后，可以關閉緊急頁面，恢復正常狀態。

?

在此基礎上，為了確保多人同時操作后臺不出錯，還增加了版本控制等高級功能。當晚也是通過變更操作的版本號，和廣州后臺同事核對驗證每一次的變更操作。

?

2、對于前面任務梳理環節提出的問題，我們也敲定了解決方案。

?

節目組拜年和節目單：

?

• 節目組拜年和節目單綁定，二者必須一一對應。

• 通過細時間軸切換確保二者和節目播放時間的強關聯。

• 每一個節目對應一個H5素材。如果一個節目里面有多個明星，需拍攝多套素材，就通過H5頁面實現多套圖片和語音素材的隨機輪播邏輯，對于后臺系統而言，還是一個H5素材。如果某些節目沒收集到明星拜年素材，就使用春晚主持人拍攝的素材來補位。

• 節目組拜年素材上的文字部分做成js配置文件，放到服務端，如果有更新，可以在搖的時候，在線拉取最新的文案內容，大小僅幾KB，量級很輕。

• 節目單上節目刪減。后臺在調整節目順序的基礎上，增加了禁用節目的功能，一旦禁用，就不展示在節目單上。

?

紅包倒計時開啟搶紅包的新方案產生的問題：

?

在后臺系統設計層面，沒辦法優化。只能通過提前研究彩排節目，仔細估算節目時間點，來確保當晚直播時，可以快速響應節目時間的變化，下發最精準的紅包時刻。

?

感悟和現場小故事

?

1飛機餐

?

春晚的互動策劃其實算不上完美，從10月底開始，我們持續做了兩個多月，一直在變更磨合。如果用做飯來類比的話，春晚互動項目最后給我最大的感覺是像在做飛機餐，這其中要權衡的太多，用戶、電視臺廣告部、導演組、技術層面超高并發下如何確保不掛和最優的體驗等等。從最初開始以純用戶視角去自由策劃的自命題作文、漸漸演變成迎合導演組口味的命題作文，再往后我們試著提推薦的方案去引導導演組接受。好在大家都很投入的去把這個事情做好，最后呈現出來的，也算是一份完美的飛機餐。

?

2紅包倒計時的估算——能早不能晚

?

正常情況下，電視的直播，會故意晚30秒左右，確保一旦出現問題，可以有時間在直播源頭做調整。這種模式下，我們可以根據現場播放的精確的時間，提前30秒的時間下發最精確的時間。但15年的春晚，采用了0延遲直播的模式，所以只能靠估算。我們倒計時估算的原則是可以早，但不可晚。因為一旦電視上，主持人說開始搶的時候，還沒發搖出紅包的話，體驗就比較差，但如果提前出現，用戶可以理解為自己的延遲，相比之下好一些。所以這個地方，我們把估算的時間點有意提早一些。

?

在當晚直播的時候，我們拿到了節目的串聯單，列了每個節目表演的時長、開始時間、結束時間。每個節目下場的時候，我們會估算新的延遲，推算新的倒計時時間點。在10:20左右，紅包時刻前最后一個語言類節目結束，我們終于敲定了最后的倒計時時間，最后紅包在我們預料的時間點內下發，還算比較完美。

?

3素材推送——背后設計、開發、測試的徹夜不眠

?

由于電視臺側的配合原因，采集節目組拜年開始的比較晚，基本是從14號白天才開始采集素材。晚上10點半結束原始素材的采集。14號連夜，經過“圖片和語言素材制作—>H5開發生成頁面—>測試驗證頁面—>H5頁面打包—>上傳至后臺—>同步到客戶端后臺—>資源校驗—>推送”這么一系列的工作流程，在15日下午，終于完成了全部65個素材的推送工作。背后是相關的設計、開發、構建、測試、后臺多部門同學的徹夜不眠。當然，這只是春晚項目一個小功能環節的縮影。

?

4致謝

?

在文章的最后，要向參與項目支持的開發、測試、設計還有產品等同學表達謝意，這是一個多部門聯動的超大項目，所有人的齊心協力協同作戰才確保了項目的完美呈現。希望以后還有機會，大家可以一起做的更好！

原文here

轉載于:https://www.cnblogs.com/ytkah/articles/4422699.html

總結

以上是生活随笔為你收集整理的【100亿次的挑战】之春晚控制后台故事分享的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。