【100亿次的挑战】之春晚控制后台故事分享
講師:freyli
?
項目歷程簡介?
在介紹控制后臺部分之前,先簡單回顧下項目的時間線:
?
10月25日,意向、調(diào)研、策劃、溝通
11月24日,第一次技術(shù)初審
12月7日,互動形態(tài)框架確定,時間軸初現(xiàn)
12月15日,互動需求初步敲定,明確操控后臺需求
12月26日,客戶端封版,第一次演習
1月,后臺開發(fā)迭代,周度演習。
2月12日/15日,預熱。
2月14日/16日,進場聯(lián)排。
2月18日,實戰(zhàn)。
?
我們前面互動策劃的時間花的比較多,因為涉及多方磨合。確定互動后,為了確保覆蓋量,客戶端開發(fā)的節(jié)奏超快,兩周內(nèi)搞定這個大版本。后臺部分工作量巨大,但開發(fā)同學在一個月內(nèi)加班加點搞定了后臺系統(tǒng)的改造,最后抗住了峰值,確保項目呈現(xiàn)。整體節(jié)奏是比較緊張的。
?
春晚控制后臺的關鍵任務?
春晚控制后臺主要解決當晚和現(xiàn)場直播時間點相關的一些變更操作,比如節(jié)目單正在播放、紅包切合口播時間下發(fā)之類。
?
相比面向用戶端的互動策劃來說,控制后臺部分酷值就下降很多,需求來的比較直接,主要是解決業(yè)務如何更好的實現(xiàn)的問題,確保技術(shù)實現(xiàn)和人員操作都簡單可靠。互動形態(tài)給控制后臺提出的關鍵任務有一下幾項:
?
1場景切換?
-
整個春晚互動,要求在不同時間段出現(xiàn)不同的互動類型。
-
場景變更的時間點要嚴格匹配主持人的口播。
?
2節(jié)目組拜年?
節(jié)目組拜年的互動形式是看春晚時候,搖一搖,可以出現(xiàn)當前節(jié)目演員的拜年頁面。
?
-
要求與節(jié)目強關聯(lián),某個節(jié)目出現(xiàn)的時候,對應的節(jié)目組拜年也要跟著變換。
-
一旦節(jié)目順序調(diào)整或者節(jié)目刪減,節(jié)目組拜年的素材也要相應變化。
-
一個節(jié)目和拜年素材是否一一對應?
-
素材需要提前推送,但是頁面上展示的節(jié)目名稱可能會有調(diào)整。
?
3節(jié)目單&正在播放?
節(jié)目單是在互動策劃的后臺加入的一個很小的功能,起初只是打算搖出一個頁面,展示當晚的節(jié)目單,后來大家覺得要做實時展現(xiàn),這樣實時的體驗更強。
?
-
和節(jié)目組拜年需求很相似,能否捆綁?
-
對于串場的節(jié)目在節(jié)目單上如何展現(xiàn)
-
節(jié)目單會展示整個節(jié)目隊列,刪減的節(jié)目如何處理
?
4紅包倒計時?
?
最初倒計時的用途只是在互動頁面頂部展示距離搶紅包時間還有多久,目的是把平時的人流量積累到搶紅包的高峰時段。但在2月17日的時候,后臺開發(fā)同學仔細反復地review整個系統(tǒng)的設計,發(fā)現(xiàn)最重要的搶紅包時刻的開啟是風險最大的點,一旦切換操作因某些意外因
?
?
素導致失敗,將會導致整場互動功虧一簣。經(jīng)評估后,我們把開啟紅包場景的方案調(diào)整為倒計時歸零就自動開啟,設定的時間段到期后自動結(jié)束。新的方案消除了高峰時刻無法開啟紅包場景的風險,但相比之下也帶來了新的難點。
?
-
原需求:僅用于互動頁面頂部展示距離搶紅包的倒計時,為高峰時刻積攢人流量。
-
臨危受命新使命:倒計時歸零,就開啟紅包。內(nèi)心的感覺—>“火箭發(fā)射的倒計時指令”
-
新使命帶來的問題:如何給出最準確的倒計時?
?
5素材管理?
節(jié)目組拜年的H5頁面、節(jié)目單、還有頁面上展示贊助商權(quán)益的贊助商logo素材,都需要提前上傳,維護關聯(lián)關系。
?
需求梳理和功能呈現(xiàn)?
1、接著前一步的關鍵任務,我們很快梳理出了控制后臺的功能框架,主要兩部分:
?
素材管理:
?
-
節(jié)目組拜年素材
-
節(jié)目單
-
贊助商
?
現(xiàn)場控制:
?
-
粗時間軸——場景切換
-
細時間軸——節(jié)目單、節(jié)目組拜年的切換
-
節(jié)目單順序調(diào)整
-
倒計時
-
緊急頁面——用于時間軸切錯后的補救。開啟緊急頁面狀態(tài)后,會關閉和時間相關的互動,調(diào)整完畢后,可以關閉緊急頁面,恢復正常狀態(tài)。
?
在此基礎上,為了確保多人同時操作后臺不出錯,還增加了版本控制等高級功能。當晚也是通過變更操作的版本號,和廣州后臺同事核對驗證每一次的變更操作。
?
2、對于前面任務梳理環(huán)節(jié)提出的問題,我們也敲定了解決方案。
?
節(jié)目組拜年和節(jié)目單:
?
-
節(jié)目組拜年和節(jié)目單綁定,二者必須一一對應。
-
通過細時間軸切換確保二者和節(jié)目播放時間的強關聯(lián)。
-
每一個節(jié)目對應一個H5素材。如果一個節(jié)目里面有多個明星,需拍攝多套素材,就通過H5頁面實現(xiàn)多套圖片和語音素材的隨機輪播邏輯,對于后臺系統(tǒng)而言,還是一個H5素材。如果某些節(jié)目沒收集到明星拜年素材,就使用春晚主持人拍攝的素材來補位。
-
節(jié)目組拜年素材上的文字部分做成js配置文件,放到服務端,如果有更新,可以在搖的時候,在線拉取最新的文案內(nèi)容,大小僅幾KB,量級很輕。
-
節(jié)目單上節(jié)目刪減。后臺在調(diào)整節(jié)目順序的基礎上,增加了禁用節(jié)目的功能,一旦禁用,就不展示在節(jié)目單上。
?
紅包倒計時開啟搶紅包的新方案產(chǎn)生的問題:
?
在后臺系統(tǒng)設計層面,沒辦法優(yōu)化。只能通過提前研究彩排節(jié)目,仔細估算節(jié)目時間點,來確保當晚直播時,可以快速響應節(jié)目時間的變化,下發(fā)最精準的紅包時刻。
?
感悟和現(xiàn)場小故事?
1飛機餐?
春晚的互動策劃其實算不上完美,從10月底開始,我們持續(xù)做了兩個多月,一直在變更磨合。如果用做飯來類比的話,春晚互動項目最后給我最大的感覺是像在做飛機餐,這其中要權(quán)衡的太多,用戶、電視臺廣告部、導演組、技術(shù)層面超高并發(fā)下如何確保不掛和最優(yōu)的體驗等等。從最初開始以純用戶視角去自由策劃的自命題作文、漸漸演變成迎合導演組口味的命題作文,再往后我們試著提推薦的方案去引導導演組接受。好在大家都很投入的去把這個事情做好,最后呈現(xiàn)出來的,也算是一份完美的飛機餐。
?
2紅包倒計時的估算——能早不能晚?
正常情況下,電視的直播,會故意晚30秒左右,確保一旦出現(xiàn)問題,可以有時間在直播源頭做調(diào)整。這種模式下,我們可以根據(jù)現(xiàn)場播放的精確的時間,提前30秒的時間下發(fā)最精確的時間。但15年的春晚,采用了0延遲直播的模式,所以只能靠估算。我們倒計時估算的原則是可以早,但不可晚。因為一旦電視上,主持人說開始搶的時候,還沒發(fā)搖出紅包的話,體驗就比較差,但如果提前出現(xiàn),用戶可以理解為自己的延遲,相比之下好一些。所以這個地方,我們把估算的時間點有意提早一些。
?
在當晚直播的時候,我們拿到了節(jié)目的串聯(lián)單,列了每個節(jié)目表演的時長、開始時間、結(jié)束時間。每個節(jié)目下場的時候,我們會估算新的延遲,推算新的倒計時時間點。在10:20左右,紅包時刻前最后一個語言類節(jié)目結(jié)束,我們終于敲定了最后的倒計時時間,最后紅包在我們預料的時間點內(nèi)下發(fā),還算比較完美。
?
3素材推送——背后設計、開發(fā)、測試的徹夜不眠?
由于電視臺側(cè)的配合原因,采集節(jié)目組拜年開始的比較晚,基本是從14號白天才開始采集素材。晚上10點半結(jié)束原始素材的采集。14號連夜,經(jīng)過“圖片和語言素材制作—>H5開發(fā)生成頁面—>測試驗證頁面—>H5頁面打包—>上傳至后臺—>同步到客戶端后臺—>資源校驗—>推送”這么一系列的工作流程,在15日下午,終于完成了全部65個素材的推送工作。背后是相關的設計、開發(fā)、構(gòu)建、測試、后臺多部門同學的徹夜不眠。當然,這只是春晚項目一個小功能環(huán)節(jié)的縮影。
?
4致謝?
在文章的最后,要向參與項目支持的開發(fā)、測試、設計還有產(chǎn)品等同學表達謝意,這是一個多部門聯(lián)動的超大項目,所有人的齊心協(xié)力協(xié)同作戰(zhàn)才確保了項目的完美呈現(xiàn)。希望以后還有機會,大家可以一起做的更好!
原文here
轉(zhuǎn)載于:https://www.cnblogs.com/ytkah/articles/4422699.html
總結(jié)
以上是生活随笔為你收集整理的【100亿次的挑战】之春晚控制后台故事分享的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: memcached 使用 java_ja
- 下一篇: 秋叶一键重装系统连接服务器失败,秋叶一键