劉 鑫

（河南廣播電視臺(tái)，河南 鄭州 450008）

0 引言

交互化生產(chǎn)管理云平臺(tái)是河南廣播電視臺(tái)順應(yīng)當(dāng)前融合媒體的發(fā)展趨勢(shì)，在原有制播云系統(tǒng)的基礎(chǔ)上，整合臺(tái)內(nèi)技術(shù)資源打造建設(shè)的全媒體節(jié)目生產(chǎn)管理系統(tǒng)。目前該系統(tǒng)已經(jīng)運(yùn)行多年，臺(tái)內(nèi)包括新聞（四部一頻道）、衛(wèi)星頻道、都市頻道、電視劇頻道、歡騰購(gòu)物頻道、國(guó)學(xué)頻道以及輪播頻道在內(nèi)的多個(gè)欄目逐步上線實(shí)現(xiàn)送播，相關(guān)節(jié)目的新媒融合生產(chǎn)和發(fā)布也已逐步展開(kāi)。交互化云平臺(tái)采用完整三層云架構(gòu)技術(shù)體系，在四年多的實(shí)際運(yùn)行維護(hù)過(guò)程中，體現(xiàn)了云計(jì)算在彈性擴(kuò)展、業(yè)務(wù)靈活部署等方面的優(yōu)勢(shì)，但同時(shí)也給運(yùn)維工作帶來(lái)了新的挑戰(zhàn)。

1 交互化云平臺(tái)架構(gòu)介紹

1.1 三層架構(gòu)設(shè)計(jì)標(biāo)準(zhǔn)

按照國(guó)家廣播電視總局《廣播電視臺(tái)融合媒體建設(shè)技術(shù)白皮書(shū)》的要求，廣電媒體云平臺(tái)要按照基礎(chǔ)設(shè)施即服務(wù)（Infrastructure as a Service，Iaas）、平臺(tái)即服務(wù)（Platform as a Service，PaaS）、軟件即服務(wù)（Software as a Service，SAAS）三層云架構(gòu)建設(shè)。其中，IaaS 層為基礎(chǔ)資源層，提供系統(tǒng)所需的所有硬件資源，包含計(jì)算資源、存儲(chǔ)資源、網(wǎng)絡(luò)資源以及安全資源等。PaaS 層為平臺(tái)層，通過(guò)云管平臺(tái)中間件調(diào)用IaaS 層的資源，同時(shí)為其上層應(yīng)用提供媒體資源管理、用戶數(shù)據(jù)管理、內(nèi)容生產(chǎn)能力、內(nèi)容分發(fā)能力以及公共服務(wù)等平臺(tái)支撐服務(wù)，并提供統(tǒng)一的接口標(biāo)準(zhǔn)給其上層應(yīng)用。SaaS 層通過(guò)統(tǒng)一的接口調(diào)用PaaS 層提供的支撐服務(wù)，并為用戶提供各種媒體融合生產(chǎn)所需的應(yīng)用服務(wù)。

1.2 交互化混合云平臺(tái)架構(gòu)

河南廣播電視臺(tái)交互化云平臺(tái)的建設(shè)遵循了三層媒體云的架構(gòu)，并采用混合云構(gòu)架，使用統(tǒng)一的PaaS 管理系統(tǒng)，利用云管中間件成功將分布于私有云（臺(tái)內(nèi)業(yè)務(wù)生產(chǎn)云）和專(zhuān)屬云（租用大象融媒云部分資源）的設(shè)備資源統(tǒng)一管理，實(shí)現(xiàn)了統(tǒng)一的云資源調(diào)度管理系統(tǒng)，形成橫跨不同IaaS 平臺(tái)的混合云構(gòu)架。PaaS 平臺(tái)對(duì)內(nèi)容生產(chǎn)系統(tǒng)和內(nèi)容分發(fā)系統(tǒng)進(jìn)行統(tǒng)一的虛機(jī)管理、實(shí)例管理、資源彈性管理、負(fù)載均衡、存儲(chǔ)管理、文件管理、應(yīng)用管理、消息隊(duì)列以及智能工作引擎等，并根據(jù)應(yīng)用系統(tǒng)的需求，實(shí)現(xiàn)不同環(huán)境條件下的SaaS 層各應(yīng)用系統(tǒng)協(xié)調(diào)工作[1]。

1.3 交互化云平臺(tái)運(yùn)維實(shí)例

三層架構(gòu)的云平臺(tái)系統(tǒng)在河南廣播電視臺(tái)是首次使用。與傳統(tǒng)IT 架構(gòu)不同，大量的分布式、云計(jì)算、虛擬化等技術(shù)的應(yīng)用使得整個(gè)架構(gòu)更為復(fù)雜。因此，對(duì)云平臺(tái)的運(yùn)維是一個(gè)經(jīng)驗(yàn)積累的過(guò)程。運(yùn)維人員在運(yùn)維過(guò)程中不可避免地遇到了許多問(wèn)題。通過(guò)對(duì)問(wèn)題的分析解決和經(jīng)驗(yàn)總結(jié)，運(yùn)維人員在完善整個(gè)系統(tǒng)運(yùn)維工作的同時(shí)，也對(duì)云平臺(tái)運(yùn)維工作有了新的認(rèn)識(shí)和理解。下面通過(guò)列舉幾個(gè)實(shí)際運(yùn)維中的實(shí)例來(lái)總結(jié)云平臺(tái)運(yùn)維工作的經(jīng)驗(yàn)。

1.3.1 云平臺(tái)結(jié)構(gòu)復(fù)雜度高導(dǎo)致運(yùn)維負(fù)擔(dān)加重

云平臺(tái)復(fù)雜的結(jié)構(gòu)導(dǎo)致復(fù)雜的流程，內(nèi)容的生產(chǎn)與分發(fā)經(jīng)過(guò)的節(jié)點(diǎn)較之以往更多。對(duì)于沒(méi)有相關(guān)運(yùn)維經(jīng)驗(yàn)的運(yùn)維人員，對(duì)系統(tǒng)架構(gòu)和整體業(yè)務(wù)流程的理解和掌握就更為困難。當(dāng)業(yè)務(wù)出現(xiàn)問(wèn)題，在沒(méi)有系統(tǒng)的智能化運(yùn)維監(jiān)控軟件輔助的情況下，運(yùn)維人員很難精準(zhǔn)定位問(wèn)題，往往需要反復(fù)查看各個(gè)相關(guān)環(huán)節(jié)才能找到問(wèn)題所在。

以臺(tái)內(nèi)新聞?lì)l道節(jié)目整備失敗為例。在此案例中，故障現(xiàn)象是制作系統(tǒng)送播節(jié)目提交流程后，整備系統(tǒng)未收到，通過(guò)制作系統(tǒng)查看接口日志，發(fā)現(xiàn)整備系統(tǒng)有反饋入庫(kù)報(bào)錯(cuò)。而實(shí)際的節(jié)目送播流程包括制作系統(tǒng)的內(nèi)部制作流程、制作系統(tǒng)素材在PaaS 平臺(tái)注冊(cè)環(huán)節(jié)、制作系統(tǒng)與整備系統(tǒng)的元數(shù)據(jù)交互環(huán)節(jié)、整備系統(tǒng)對(duì)PaaS 平臺(tái)的素材共享請(qǐng)求環(huán)節(jié)以及整備系統(tǒng)的入庫(kù)和反饋制作環(huán)節(jié)。這么多環(huán)節(jié)中的任何一個(gè)環(huán)節(jié)出問(wèn)題，都有可能導(dǎo)致節(jié)目在整備系統(tǒng)入庫(kù)時(shí)報(bào)錯(cuò)。因此，問(wèn)題的定位十分復(fù)雜，需要制作系統(tǒng)、整備系統(tǒng)及PaaS 平臺(tái)三方一起逐個(gè)環(huán)節(jié)定位查找故障原因。雖然最終準(zhǔn)確定位為整備接口服務(wù)器與整備數(shù)據(jù)庫(kù)通信故障并成功解決了問(wèn)題，但消耗了大量的時(shí)間和人力。因此需要在系統(tǒng)內(nèi)部署智能化運(yùn)維監(jiān)控軟件來(lái)解決此類(lèi)問(wèn)題。

1.3.2 PaaS 層故障

PaaS 層數(shù)據(jù)庫(kù)等相關(guān)業(yè)務(wù)有可能成為系統(tǒng)單點(diǎn)故障點(diǎn)，PaaS層故障有可能導(dǎo)致整個(gè)系統(tǒng)的癱瘓。交互化云平臺(tái)使用一個(gè)PaaS 平臺(tái)對(duì)各個(gè)相關(guān)子系統(tǒng)進(jìn)行統(tǒng)一管理，各個(gè)子系統(tǒng)的素材使用、業(yè)務(wù)流程等都需要經(jīng)過(guò)PaaS 層。當(dāng)PaaS 層的相關(guān)服務(wù)出現(xiàn)問(wèn)題，就有可能影響到所有注冊(cè)在其上的子系統(tǒng)的業(yè)務(wù)。

以2019 年上半年頻繁出現(xiàn)的PaaS 層數(shù)據(jù)庫(kù)故障為例。交互化云的PaaS 層主數(shù)據(jù)庫(kù)為Mango數(shù)據(jù)庫(kù)，為了保障數(shù)據(jù)安全，數(shù)據(jù)庫(kù)設(shè)計(jì)為每節(jié)點(diǎn)3 切片的3 節(jié)點(diǎn)結(jié)構(gòu)。在實(shí)際運(yùn)行中，由于第一次使用Mango 數(shù)據(jù)庫(kù)，技術(shù)人員缺乏運(yùn)維經(jīng)驗(yàn)，就出現(xiàn)了數(shù)次由于其中一個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的某一切片不同步而導(dǎo)致整個(gè)數(shù)據(jù)庫(kù)停止對(duì)外服務(wù)，從而導(dǎo)致整個(gè)PaaS 層功能失效，最直觀的表現(xiàn)就是所有系統(tǒng)都無(wú)法在PaaS 上注冊(cè)素材，從而造成節(jié)目無(wú)法正常送播。

積累了一定的運(yùn)維經(jīng)驗(yàn)與系統(tǒng)優(yōu)化后，這種情況會(huì)得到解決。但也反映出PaaS 層容易成為系統(tǒng)的單一故障點(diǎn)的隱患存在。PaaS 層一旦出現(xiàn)故障，就有可能導(dǎo)致整個(gè)系統(tǒng)的癱瘓。如果可以分別在內(nèi)容生產(chǎn)系統(tǒng)和內(nèi)容分發(fā)系統(tǒng)各自建立媒體專(zhuān)業(yè)PaaS 管理平臺(tái)，則會(huì)有效地解決此類(lèi)問(wèn)題，但勢(shì)必帶來(lái)更高的成本。

1.3.3 統(tǒng)一的存儲(chǔ)與素材管理帶來(lái)的問(wèn)題

PaaS 層對(duì)注冊(cè)在其上的各子系統(tǒng)的素材進(jìn)行統(tǒng)一管理，共用統(tǒng)一的存儲(chǔ)，節(jié)省了素材遷移的時(shí)間，提高了生產(chǎn)效率。但與此同時(shí)，由于不同的業(yè)務(wù)需要對(duì)存儲(chǔ)性能、容量、保存時(shí)間等要求都不同，因此統(tǒng)一管理會(huì)帶來(lái)存儲(chǔ)沖突，也會(huì)帶來(lái)過(guò)多的無(wú)用存儲(chǔ)占用。

以制作系統(tǒng)和分發(fā)系統(tǒng)為例。制作系統(tǒng)對(duì)存儲(chǔ)的要求是高帶寬和高IOPS（每秒進(jìn)行讀寫(xiě)操作的次數(shù)）來(lái)滿足多個(gè)終端的實(shí)時(shí)讀寫(xiě)，而素材的實(shí)時(shí)性使得其對(duì)存儲(chǔ)容量沒(méi)有過(guò)多要求；而以媒資為例的分發(fā)系統(tǒng)對(duì)存儲(chǔ)的要求就是大容量，要能夠永久保存大量的節(jié)目與素材，而對(duì)存儲(chǔ)的實(shí)時(shí)帶寬和IOPS 則沒(méi)有太高要求。因此，讓制作系統(tǒng)和分發(fā)系統(tǒng)共用同一存儲(chǔ)，就會(huì)導(dǎo)致二者對(duì)存儲(chǔ)性能要求的沖突。大量的媒資等分發(fā)素材的長(zhǎng)時(shí)間保存，也會(huì)不斷擠占制作空間。

同時(shí)，統(tǒng)一的素材管理使得存儲(chǔ)管理策略變得更加復(fù)雜。一份素材文件往往被不同的子系統(tǒng)所共享引用，只有當(dāng)所有人都解除共享之后該素材才會(huì)被徹底刪除。實(shí)際運(yùn)維過(guò)程中，有很多實(shí)際上已經(jīng)無(wú)用的素材由于某個(gè)引用的用戶沒(méi)有解除綁定而無(wú)法刪除，造成存儲(chǔ)空間的白白占用。目前，交互化云系統(tǒng)的共享存儲(chǔ)空間已經(jīng)占用過(guò)半，由于無(wú)法準(zhǔn)確地確定哪些素材是所有系統(tǒng)都不再用的，因此無(wú)法進(jìn)行空間清理。

如果將內(nèi)容生產(chǎn)系統(tǒng)和內(nèi)容分發(fā)系統(tǒng)的存儲(chǔ)分開(kāi)管理，就可以有效地解決此類(lèi)問(wèn)題。

1.3.4 基于虛擬機(jī)技術(shù)的云平臺(tái)在實(shí)際運(yùn)維中顯露的問(wèn)題

虛擬化和云計(jì)算的應(yīng)用確實(shí)給運(yùn)維工作帶來(lái)了便利。交互化云平臺(tái)使用了基于Openstack 的服務(wù)器虛擬化技術(shù)以及Citrix 桌面虛擬化技術(shù)等，這些虛擬機(jī)的使用使得業(yè)務(wù)的部署更加靈活，對(duì)虛擬機(jī)的維護(hù)也更加方便[2]。

然而，即使虛擬機(jī)技術(shù)相對(duì)于傳統(tǒng)物理機(jī)十分便利，但實(shí)際使用中，其自身也存在一些問(wèn)題。虛擬機(jī)技術(shù)屬于系統(tǒng)虛擬化，每個(gè)虛機(jī)都要配備完整的虛擬硬件資源和單獨(dú)的操作系統(tǒng)，因此在系統(tǒng)級(jí)的虛擬機(jī)運(yùn)行時(shí)，其對(duì)硬件資源的開(kāi)銷(xiāo)還是比較大的。在更輕量級(jí)的Docker 等容器技術(shù)逐漸成熟后，虛擬機(jī)技術(shù)的這種資源開(kāi)銷(xiāo)大的弊端就更加凸顯。比如交互化云平臺(tái)的虛擬化存儲(chǔ)空間占滿問(wèn)題。系統(tǒng)建設(shè)時(shí)，為整個(gè)云平臺(tái)的虛擬化專(zhuān)門(mén)配置了大容量的存儲(chǔ)空間以供虛機(jī)使用，但隨著系統(tǒng)的運(yùn)行，所需的虛機(jī)增多，而每臺(tái)虛機(jī)都要求配置相應(yīng)的專(zhuān)屬存儲(chǔ)空間，導(dǎo)致整個(gè)虛擬化存儲(chǔ)空間被占滿，從而無(wú)法繼續(xù)創(chuàng)建新的虛機(jī)，只得再采購(gòu)新的存儲(chǔ)硬件以增加空間。同樣的問(wèn)題還會(huì)影響到CPU、內(nèi)存等計(jì)算資源，只不過(guò)在本系統(tǒng)中問(wèn)題表現(xiàn)還不明顯。

如果在系統(tǒng)里采用容器技術(shù)，可以節(jié)省系統(tǒng)資源開(kāi)銷(xiāo)。另外，也可以采用超融合架構(gòu)，則增加節(jié)點(diǎn)方式的硬件資源擴(kuò)展實(shí)現(xiàn)起來(lái)就會(huì)更加便捷。

2 云平臺(tái)建設(shè)與運(yùn)維建議

通過(guò)對(duì)交互化云平臺(tái)的運(yùn)維經(jīng)驗(yàn)的總結(jié)，結(jié)合實(shí)際應(yīng)用中遇到的問(wèn)題以及解決辦法，可以對(duì)云平臺(tái)的建設(shè)以及后續(xù)的運(yùn)維工作提供一些建議與幫助。

2.1 引進(jìn)先進(jìn)的云平臺(tái)運(yùn)維技術(shù)構(gòu)建完整的運(yùn)維體系

云平臺(tái)的運(yùn)維工作不能單靠人工完成，需要利用智能化的運(yùn)維工具，構(gòu)建自動(dòng)化的云平臺(tái)運(yùn)維體系，需要利用云管、網(wǎng)管、日志分析等智能化管理工具，同時(shí)搭建業(yè)務(wù)全流程的監(jiān)控平臺(tái)，在出現(xiàn)問(wèn)題時(shí)可以輔助運(yùn)維人員快速定位問(wèn)題并解決問(wèn)題。此外，在諸多云平臺(tái)運(yùn)維的討論中，DevOps 無(wú)疑是提及最多的概念。DevOps 將開(kāi)發(fā)和運(yùn)維兩個(gè)領(lǐng)域合并起來(lái)，實(shí)現(xiàn)從設(shè)計(jì)到編碼，然后從開(kāi)發(fā)環(huán)境部署到生產(chǎn)環(huán)境上，由開(kāi)發(fā)人員和運(yùn)維人員共同參與的迭代過(guò)程。這不僅提高了現(xiàn)場(chǎng)交付的效率，也能讓日常的運(yùn)維工作變得簡(jiǎn)單[3]。

2.2 內(nèi)容生產(chǎn)系統(tǒng)與內(nèi)容分發(fā)系統(tǒng)的隔離

對(duì)于廣播電視臺(tái)內(nèi)的節(jié)目生產(chǎn)來(lái)說(shuō)，由于內(nèi)容生產(chǎn)系統(tǒng)與內(nèi)容分發(fā)系統(tǒng)在業(yè)務(wù)范圍、存儲(chǔ)要求以及安全等級(jí)上的不同，用統(tǒng)一的PaaS 層管理也是造成上文所述問(wèn)題的一個(gè)原因。因此，在新建臺(tái)內(nèi)云平臺(tái)時(shí)，可以將內(nèi)容生產(chǎn)系統(tǒng)和內(nèi)容分發(fā)系統(tǒng)分開(kāi)建設(shè)。一種思路是將二者由IaaS 層硬件資源層面就完全隔離開(kāi)，建立各自的云平臺(tái)，形成臺(tái)內(nèi)兩朵云；另一種思路是，在需要將硬件資源集中在一起的情況下，可以在PaaS 這一層面將二者分開(kāi)管理，在統(tǒng)一的云管平臺(tái)上為制作云和分發(fā)云分別建立各自的PaaS 層，使其業(yè)務(wù)功能職責(zé)劃分更加清晰。同時(shí)，需要為兩個(gè)云分別配置更有針對(duì)性、更適合各自業(yè)務(wù)的存儲(chǔ)，將素材分開(kāi)管理，也能更好地實(shí)現(xiàn)應(yīng)用多分布。與之搭配系統(tǒng)中已經(jīng)成熟使用的大數(shù)據(jù)擺渡技術(shù)，也會(huì)使素材傳輸更加高效、便捷[4]。

2.3 建立健全云平臺(tái)的技術(shù)運(yùn)維管理模式

在針對(duì)媒體云平臺(tái)的運(yùn)行維護(hù)中，不能僅僅依靠技術(shù)支撐，還需要形成一套行之有效的運(yùn)維管理模式。借鑒通用IT 云平臺(tái)的管理模式，可以按照媒體業(yè)務(wù)分開(kāi)、分層管理，有助于管理更有針對(duì)性，劃分更明確；各個(gè)管理者之間不是各行其是，而是一個(gè)相輔相成的整體。各層之間的管理在宏觀上也是一個(gè)松耦合的整體，遇到問(wèn)題時(shí)協(xié)同解決。

2.4 容器等新技術(shù)在媒體云中的應(yīng)用

上文提到虛擬機(jī)技術(shù)在系統(tǒng)開(kāi)銷(xiāo)上的問(wèn)題，并且引入了Docker 等容器技術(shù)。與虛擬機(jī)的系統(tǒng)級(jí)虛擬化不同，容器技術(shù)屬于應(yīng)用級(jí)虛擬化，容器化應(yīng)用時(shí)使用的資源都是宿主機(jī)系統(tǒng)提供的，僅僅是在資源的使用上做了某種程度的隔離與限制。比起虛擬機(jī)，容器擁有更高的資源使用效率，實(shí)例規(guī)模更小、創(chuàng)建和遷移速度也更快。這意味著，相比于虛擬機(jī)，容器在相同的硬件設(shè)備當(dāng)中可以部署數(shù)量更多的容器實(shí)例。將容器技術(shù)引用到媒體云中，不僅可以解決硬件資源開(kāi)銷(xiāo)問(wèn)題，還可以使應(yīng)用部署更加快速和便捷，使整個(gè)系統(tǒng)更有彈性[5]。

然而，容器技術(shù)雖好，但也不能立刻就在媒體云中廣泛應(yīng)用，還要看是否適合媒體云的業(yè)務(wù)類(lèi)型。就目前來(lái)看，媒體云中確實(shí)有一些業(yè)務(wù)可以采用容器技術(shù)，比如轉(zhuǎn)碼能力、技審服務(wù)以及新媒體應(yīng)用等模塊。但對(duì)于目前媒體云的核心制作等業(yè)務(wù)特別是需要保障安全制播的業(yè)務(wù)，還不適合采用容器技術(shù)。由于容器是應(yīng)用級(jí)別的虛擬化，各個(gè)應(yīng)用進(jìn)程之間的隔離程度不高，容器應(yīng)用之間可能會(huì)相互影響，因此其安全性和穩(wěn)定性方面還有待加強(qiáng)。

不過(guò)，以Docker 為代表的容器技術(shù)，甚至是應(yīng)用Docker Overlay Network 和Kubernetes 等技術(shù)實(shí)現(xiàn)的容器云以及基于微服務(wù)架構(gòu)和Docker 容器技術(shù)的PaaS 云平臺(tái)等，都是業(yè)界云平臺(tái)的發(fā)展方向，并且已經(jīng)在其他領(lǐng)域廣泛應(yīng)用。技術(shù)人員可以先嘗試將容器技術(shù)引入媒體云平臺(tái)，取代一些系統(tǒng)內(nèi)輕量級(jí)的應(yīng)用。

3 結(jié)語(yǔ)

在交互化云平臺(tái)的實(shí)際運(yùn)維過(guò)程中遇到的問(wèn)題，或多或少都因?qū)π录夹g(shù)和新系統(tǒng)缺乏運(yùn)維經(jīng)驗(yàn)導(dǎo)致，相信經(jīng)過(guò)一定時(shí)間的積累，這些問(wèn)題會(huì)得到改善與解決。與此同時(shí)，新技術(shù)的發(fā)展與應(yīng)用，勢(shì)必會(huì)給現(xiàn)有的云平臺(tái)運(yùn)維工作帶來(lái)模式上的改變和效率上的提高，也能很好地解決現(xiàn)有系統(tǒng)的一些問(wèn)題。對(duì)于新的云平臺(tái)技術(shù)以及運(yùn)維技術(shù)，技術(shù)人員應(yīng)該大膽地將其引入現(xiàn)有的云平臺(tái)業(yè)務(wù)，通過(guò)對(duì)這些新技術(shù)的實(shí)際應(yīng)用來(lái)進(jìn)行更深入的了解，以便未來(lái)進(jìn)行更深層次的應(yīng)用。