【摘要】本文結合作者實際運維經驗及最新監測技術、運維管理理念，詳細介紹了中央人民廣播電臺（以下簡稱“中央電臺”）制播系統集中監測平臺設計思路，并以在設計中遇到的問題實例加以說明。
【關鍵詞】 集中監測 系統事件關聯故障快速定位 業務建模
1引言
中央電臺制播系統由多業務系統組成，各業務系統即獨立又有聯系，目前各業務系統均由自己的監測軟件對系統運行狀態進行監測，這些監測系統為日常的業務運行工作提供了有效的技術檢測數據，但是隨著制播信息系統改造，流程化制播運用，各系統之間聯系程度越來越緊密，這種分立式單獨監測方式，無法將系統事件進行關聯，無法快速定位故障點，導致維護人員精力分散處理事故慢，不能滿足目前運維需求，需建立集中監測平臺改變運維模式，提高業務系統運維關聯性，滿足運維管理需求。
2設計目標
本設計最終目標是通過制定統一的安全策略，采用合適的安全技術措施和進行制度化的運維管理，建立一體化的集中監測平臺，最終實現基礎網絡、業務流程狀態、終端設備狀態的集中監測及運行維護的流程化管理，加強系統故障與性能、服務與流程的管理融合，實現網絡管理、運維管理和服務管理一體化。
3系統架構設計和功能設計
3.1部署設計
集中監測平臺部署設計充分考慮到制播網絡安全等級保護的要求，利用防火墻及網絡策略隔離出安全區域“安全運維管理區”，所有與制播系統業務無關的功能系統均放置在此區域，包括：集中監測、運維管理、安全管理等。
圖1集中監測平臺部署架構圖
3.2邏輯架構設計
設計基于信息系統標準規范，建立與第三方標準接口，整合基礎設備管理，應用管理，端到端應用流分析，業務服務管理，業務流程管理等，消除信息系統運維斷點，使各模塊之間信息互通，以業務的視角實現整體信息系統運維管理，最終幫助信息中心建立完備的信息系統運維系統，實現流程化、自動化和規范化管理。
圖2制播系統集中監測平臺邏輯架構圖
集中監測平臺采用分層、模塊化設計，每一層次的模塊設計分開，且模塊之間的松耦合。層與層之間的溝通是通過API接口。
集中監測平臺為能達到高性能、低成本，則采用B/S架構。同時提供與第三方接口（包括安全管理中心、云計算、虛擬化等），與第三方集成可以在以下三方面實現：
數據：直接利用其它系統的接口，采集性能監控數據，采集后進行數據的分析及匯總，統一產生告警事件并生成歷史數據報表。
事件：接收或者讀取第三方系統產生的故障告警事件，進行統一的故障事件展現和處理（報警發送等）。
界面：實現管理員的單點登錄
3.3技術架構設計
集中監測平臺采用分步式布置，整個技術架構分為四層：第一層：被采集層，主要由被監控設備及應用系統組成；第二層：采集層，主要通過采集器對被采集層設備信息進行采集。采集方式采用標準協議，采集數據進行壓縮、加密，保證傳輸安全性；第三層：匯聚處理層，負責下發監測策略，并匯總和篩選從采集層采集的監測數據信息，寫進數據庫，以便于展現層從數據庫選擇調用；第四層：展現層，將需要展示的信息通過圖形化的方式實時統一展示，同時可以融合其它監測產品，并統一登錄。
通過以上部署方式即可實現對制播網信息系統資源的統一監測及運維服務。各系統管理員可以根據實際情況利用權限設定管理信息系統資源和運維工作范疇。
圖3制播系統集中監測平臺技術架構圖
監測方式可以選擇代理和無代理方式，這兩種方式可以根據系統運行情況進行選擇。
防火墻策略根據實際情況及安全等保規定，進行策略設計。
3.4安全設計
本項目集中監測平臺部屬在經過安全等級保護等級的制播網內，因此需要遵守相關安全規定，包括原國家廣播電影電視總局《總局廣播電視安全播出管理規定-總局令62號》、原國家廣播電影電視總局《廣播電臺數字化網絡化建設白皮書（2007）》原國家廣播電影電視總局《廣播電視相關信息系統安全等級保護基本要求》進行安全設計。
例如：在制播網內，利用防火墻劃分出安全區域“安全運維管理區”，一切和制播系統業務無關的系統均部屬在此區域，集中監測平臺部屬在此區域；采集信息傳輸方式采用點對點，傳輸協議采用標準協議，傳輸數據加密；網絡層面采用劃分單獨vlan并在防火墻設置訪問策略；用戶層面采用登錄限制，包括登錄時間限制、登錄次數限制，并記錄所有管理人員的認證和操作日志等。
3.5功能設計實現原理
圖4制播系統集中監測平臺功能圖
5.4.1統一事件告警設計
設計支持多種事件收集方式，包括代理和無代理方式的事件收集機制，對系統收集到的各類系統事件和應用事件進行壓縮、關聯、過濾等分析處理，并可統一進行展現，及時幫助系統管理員能夠準確確定故障位置，快速處理問題。在統一事件告警設計中考慮到監測的種類包含基礎架構、服務器、應用、業務、腳本等多種內容，各自監測后產生的報警信息則需要一個統一的實時告警平臺可以直觀的將所有監測內容的告警信息囊括進來。
5.4.2統一策略管理設計
策略管理設計中，可以給設備、基礎應用等每個資源設置獨立策略，也可以對相同資源進行統一策略設置，這些策略的設置閾值和事件報警相統一，節省了管理維護成本
5.4.3運維流程管理設計
設計結合信息系統ITIL體系框架，建立以CMDB為中心的運維流程管理，主要實現以下目標：
1.強化主動監測
充分利用監測系統監測大數據的分析能力，主動及時的發現問題，并主動將監測信息推送給運維人員，使維護人員從“救火員”轉變為“消防員”，解決被動服務的局面。
2.幫助定位故障
故障定位是這次設計中的關鍵一點，快速的定位故障點，不但減輕維護人員工作量，還減少了恢復系統使用時間，提高維護效率。
3.規范運維管理
參照信息系統ITIL規范和相關信息系統標準，結合中央臺的實際運維經驗，規范運維管理。運維管理要流程化，規范化，更要電子化，給運維人員制定合理的運維制度提高工作效率。
4.共享運維經驗
維護人員的運維經驗是很寶貴的，合理的把運維人員的好的工作經驗進行總結和歸納，并以知識庫的方式共享給各系統維護人員，實現維護經驗的共享和交流。
5.提供統計分析
通過各種報表可以從各方面詳細的反映系統一段時間運行狀態，性能使用情況及維護人員工作情況等。
6.全面直觀展現
通過統一展示模塊,使運維人員能快速了解到系統資源的運行狀態、性能使用情況、服務工單情況等。
5.4.4統一運行展現設計
設計本系統與其他第三方管理系統實現統一認證統一登錄機制，并對整合后的內容進行統一展現，打造個人工作平臺。
圖5制播系統集中監測平臺統一運行展現設計圖
5.4.5運維統計分析設計
在運維過程中，每天處理多少故障，處理結果怎樣，每月維護人員處理故障多少、系統運行狀態趨勢如何，怎么去避免不必要的問題處理等，都需要大數據分析，運維統計分析模塊即可統一展現出信息系統資源性能報告、趨勢報告、故障報告，運維團隊工作報告，并可自動進行實時分析、歷史分析，例如總體運行狀態一覽表、設備運行故障報表、性能報表、關鍵鏈路流量報表等。同時為便于管理員掌握各業務系統和基礎網絡的運行情況，可以提供監測目標的存活率數據，并通過圖表及表格的方式以日期分類統計。
5.4.6業務流程管理設計
制播系統流程化，故障出現時多種多樣，但表現會出現在每個流程節點，因此我設計將復雜異構的信息系統資源通過業務建模的過程形成層次化管理視圖，同時完善監控采集規則，把信息管理和業務所涉及的對象和要素、以及它們的屬性、行為和彼此關系關聯起來，業務建模強調以整體的方式來理解、設計和構架業務服務系統。通過業務關聯管理，系統管理員可以輕松的建立各業務系統綜合信息模型，隨時了解到業務的運行狀態。
圖6制播流程圖
例如制播流程建模，制作、發送、一審、二審、三審、制作接口、播出接口、分發
其它流程：媒資到制作流程、媒資內部流程、水印流程等。
每一個業務節點均有關聯要素支撐，例如：“發送”節點，則由編輯器、webservice、數據庫、操作系統、服務器、網絡關聯要素組成，任一要素有故障均可在“發送”節點上報告出來，并顯示故障點，以此系統管理員能快速定位故障。
當然在設計調研的時候遇到一些問題，例如：在發播流程中，由制作的首節點生成并記錄GUID，該GUID在所有的業務系統中保證唯一。當制作向播出發起服務調用時，制作將該GUID組織在接口文件中并進行發送，播出收到后未對其進行識別、存儲及后續使用，而是再次生成了播出系統內使用的唯一ID。解決思路：
1、制作系統
1）在與播出系統集成的方式上不需做任何改變。
2）僅需要在與集中監測平臺集成時，按統一監測平臺的接口規范組織向集中監測平臺發送消息，消息中使用GUID作為業務流程實例的唯一標示。
2、播出系統（同樣適用于媒資系統）
1）在接收到制作的調用時，要持久化（要保證程序異常中止后依然可以再次重新處理，所以一定要持久化）記錄播出自己創建的ID與制作發來的GUID間的關系。制作與播出在進行調用時，播出在調用結束后要告知制作是否調用成功，這種告知也是在GUID的基礎上進行告知，所以與本次報告可合并實施。
2）在與統一監控平臺集成時，按統一監控平臺的接口規范組織向統一監控平臺發送消息，消息中使用GUID（根據記錄的關系進行查找）。
3、集中監測平臺
1）對業務系統發送的消息進行接收及后續與監控相關的處理。
4結束語
綜上所述，集中監測平臺設計已經較好的滿足中央電臺制播系統集中監測需求，但在實際使用中，特別是系統故障關聯和業務流程建模需要不斷的和現有業務系統磨合，總結經驗再對監測平臺進行科學的、合理的微調，以致集中監測平臺更加趨于完善。
參考文獻：
【1】韓曉光 系統運維全面解析：技術、管理與實踐 電子工業出版社 2015年11月