廣播電臺容災這件事，我們做了 20 年才搞明白
廣播電臺容災這件事，我們做了 20 年才搞明白
有一種事故，比靜默更難發現。
不是開天窗——開天窗你馬上就知道，監控報警、電話打過來、領導催。而是那種系統"看起來在跑"的狀態：播出機的程序活著，音訊矩陣有訊號，但實際上發射機那頭輸出的是三十分鐘前快取的一段音樂，迴圈播，沒人發現，直到上午來上班的第一個人開收音機才意識到昨晚出了事。
我們做廣播播控系統二十年，見過太多這種"靜默故障"。這篇文章，想把容災這件事從頭捋一遍——不是產品手冊，是真實踩坑的記錄。
磁帶年代：容災靠人
2005 年之前，大多數縣級臺的容災方案就是一盤備用磁帶和一個值班的播出員。
主機壞了？插磁帶。下午沒稿子？提前錄好推給下午的班。天氣預警？編輯手寫一張稿子送到播出間，主播現播。
這套方案有它的合理性：它簡單，可操作，失敗路徑清晰——出了問題就是人的問題，可以追責，可以覆盤，可以改流程。
但它有一個根本上的脆弱點：它依賴於"有人在場"。
凌晨兩點機器壞了，誰在？節假日呢？臺里人員精簡之後，值夜班的只剩一個人，他去了廁所這十分鐘，出事了怎麼辦？
磁帶年代的容災，本質上是人肉容災。在那個時代是夠用的，因為大家都這樣。
雙機互備的第一個十年：穩定性是頭等大事
2005 年到 2015 年，整個行業的主流方案是雙機熱備：主機跑播出，備機實時同步狀態，主機一旦掛掉，備機接管。
我們研發 MGR 的早期版本，核心目標只有一個：把主備切換時間壓到可接受的範圍內。
這聽起來不難，但實操裡有三個坑，我們反覆踩。
第一個坑：故障檢測的誤報。 早期版本用單一心跳包檢測主機狀態，一旦網路抖動、交換機負載高，心跳丟幾個包，備機就以為主機掛了，觸發切換。結果是：主機好好的，備機接管了，兩臺機器同時往發射機送訊號，輸出的是兩個時間偏移不一致的節目流混疊在一起。這個問題到監管那裡，就是重大播出事故。
我們後來改成三路監控冗餘判定——心跳、TCP 埠探活、音訊電平三者同時失常才觸發切換。單一通道失常視為網路抖動，不切換。
第二個坑：切換之後的狀態恢復。 備機接管的瞬間，它需要知道"現在應該播什麼"。如果切換依賴從網路共享讀取播單狀態，而主機崩潰的同時網路也受到了影響（現實中這很常見，斷電往往連交換機一起斷），備機就會卡在讀檔案的重試迴圈裡，期間同樣是靜默。
解法是：備機在本地預快取完整的播單狀態，每 60 秒重新整理一次，切換時從本地執行，不依賴任何網路操作。
第三個坑：主機恢復之後的搶佔競爭。 備機接管 4 分鐘後，主機 UPS 重啟，主機又活了，主機認為自己應該恢復播出，備機也在播出。兩臺機器打架，兩路訊號同時送到發射機。這個問題我們在某臺實際發生過，持續了 11 分鐘沒被發現，因為凌晨 2 點沒人在。
解法是確定性仲裁：雙主衝突時，硬體 ID 字典序較小的那臺讓步，退出主播角色。不優雅，但可預期。
一場機房水管爆裂，讓我們認識到單機房 HA 的邊界
2018 年，我們有一家合作的縣級臺遇到了一次非典型故障：機房裡的消防水管老化，深夜爆裂，機房泡水，主機和備機同時報廢。
雙機互備，再冗餘，也只是兩臺機器在同一個機房。一次機房級事故，就把所有冗餘一掃而空。
那次事故之後，我們開始認真對待跨機房同步這個方向。
單機房 HA 的本質是：防範單點硬體故障。它能解決 UPS 失效、硬碟壞道、主機板損壞這類問題。但它無法對抗：
- 機房物理損毀（水災、火災、供電線路事故）
- 全樓斷電超出 UPS 續航時間
- 自然災害導致的基礎設施中斷
這些不是小機率事件。在二十年的服務週期裡，我們合作的 500 多家電臺，遇到過兩次機房水患、一次機房小範圍起火（排線老化短路）、若干次市政供電中斷超過 6 小時。
省級臺機房起火那次：教會我們什麼是真正的容災
那次不是我們合作的電臺，是一家省級臺，我們是從行業交流中聽說的細節。
排線老化引發了小範圍火情，機房緊急斷電處置，播出中斷約 40 分鐘。恢復之後發現，因為主備兩套系統都在同一個機房，備機同樣受影響，並沒有完成自動接管。
事後那家臺重新規劃了架構：在另一棟樓的弱電機房放了一套獨立的備播系統，與主機房之間用光纖直連，實時同步播單和音訊素材，一旦主機房整體不可用，可以在人工介入的情況下 10 分鐘內切到備樓播出。
這個方案並不完美——還是需要人工介入，還是有 10 分鐘視窗——但它解決了"機房整體不可用"這個單機房 HA 無法覆蓋的場景。
KAVANA-DOG 在這個方向上的演進，就是把跨機房同步做進了標準流程。主備機之間的狀態同步，包括播單、配置、已合成的音訊索引，都走加密長連線實時同步；備機的 WAV9 音訊完整性校驗在接管前自動執行，防止"接管成功但播的是錯的"這種靜默錯誤。
具體的技術實現可以看 https://www.kavanafm.com/dog，我們在文件裡把狀態機和仲裁協議都寫得比較詳細。
春節閤家歡節目轉播中斷：一次軟體層面的容災考驗
這是一個很不一樣的故障模式。
某年除夕，一家地市臺在轉播上級臺的春節聯歡節目。轉播鏈路走的是衛星接收+本地播出機轉發。
深夜約 11 點，衛星接收端訊號突然中斷（後來查明是饋源積雪導致接收角度偏移）。播出機按照設定的邏輯，應該在訊號丟失超過 30 秒後自動切換到本地備用節目。
但實際上，那臺系統的"訊號丟失檢測"依賴的是音訊電平閾值判斷，而衛星接收鏈路雖然內容中斷，但底噪依然存在，電平並沒有掉到閾值以下。系統認為訊號正常，沒有觸發切換，播出機對外輸出的是無內容的白噪聲，持續了約 7 分鐘。
這次事故的教訓不是硬體冗餘，而是故障檢測的邏輯必須區分"有訊號"和"有有效內容"。我們在 DOG 的後續版本里加入了內容層檢測：不只看電平，還對音訊幀做語音活動檢測（VAD），靜默段和噪聲段區別對待。
AI 化之後：容災多了一個新維度
最近兩三年，AI 合成內容進入播出鏈路之後，容災有了新的複雜度。
傳統容災的物件是硬體和軟體——機器掛了、程序崩了。AI 化播出的容災還要多考慮一層：內容生成失敗。
LLM 介面超時、TTS 合成失敗、網路不通……在以前，這類問題最多是某條新聞沒有語音版，影響範圍有限。但如果 AI 合成是某檔節目唯一的內容來源，生成失敗就意味著那檔節目沒有內容可播。
我們目前的方案是分級降級：
- 一級：優先走本地 GPU TTS，RTF 0.07 以下，本地合成
- 二級：本地 GPU 不可用時，走阿里雲 CosyVoice 雲端 API
- 三級：雲端也不可用時，使用預生成的快取版本（每日定時生成備用版本存檔）
- 四級：快取也過期超過 24 小時，系統發出告警，播出員手動干預
這四級降級，保證了即使最壞情況下也有可用內容，而不是靜默。
https://www.kavanafm.com/mgr 裡對這套多級降級的配置有詳細說明，縣級臺可以根據自己的網路條件和硬體配置調整啟用哪幾級。
我們真正搞明白的那件事
二十年下來，容災這件事，我們真正搞明白的是：
容災不是一個功能，是一套設計哲學。
單點冗餘解決不了雙點同時失敗的問題。硬體冗餘解決不了內容層故障。軟體冗餘解決不了機房級事故。
真正的容災，是在每一個假設前面加一個問號：假設這個也掛了，系統怎麼辦？假設網路也斷了，本地還能跑多久？假設主備都失效，操作員在 10 分鐘內能做什麼？
把這些問題想清楚，然後逐層建立防線。不是花哨的架構圖，是可以在凌晨兩點沒人在的情況下撐過去的系統。
我們還在做，還在改。如果你的電臺也在考慮容災升級，歡迎來聊。https://www.kavanafm.com/dog 是容災相關的產品頁，https://www.kavanafm.com/mgr 是播出主控的完整方案，也可以直接聯絡我們的工程團隊。
KAVANA 由湖南聲廣科技有限公司開發，廣播電視節目製作經營許可證湘字第 00565 號，網路安全等級保護三級認證。技術文件與開放規範：github.com/kavanafm