Podcast 數據自修: 服務故障時頻道主如何自救

2 12 月, 2020 By theringe podcast 0 Comments

Podcast 數據自修: 服務故障時頻道主如何自救

大家好，兩個月前我開始試著製作音樂 mashup，累積了一些勞作所以成立了一個 podcast 頻道「Newbie Homemade Mashup Lab」，在之前的文章我提到前綴網址的原理，並且指出頻道聽眾數據是有可能讓自己也保管一份用來將低風險，這次就以風險的角度切入，討論現在的前綴網址機制會衍生那些問題以及需要如何解決。

將大綱分成以下數個部分：

數據紀錄
podcast 的紀錄風險
解決方式與衍生議題探討
結語

1. 數據紀錄

站在行銷角度，業主或者頻道主持人這些角色會想要知道自己網站的客人何時造訪、經由什麼管道造訪、怎麼造訪等等這些詳細數據，一般的網站需要透過下 tracking 追蹤碼佈署一隻負責記錄上述資訊的程式。可以想像成將一些紅外線感應器或監視器(tracking 追蹤碼)放在商店(網站)中隱藏起來，雖然客戶來到商店不會看到這些機器，但這些機器就會默默開始記錄這些客戶的到店時間、店內動線等等。

坊間較有名的相關服務就是 Google Analytics，簡稱 GA，透過在網站的原始碼加入一串指定的 GA 程式碼(通常只要複製貼上)，這個網站就開始有紀錄客戶資訊的能力，這組 GA 程式碼會將這些客戶數據發送到 GA 的管理平台，業主或行銷人員就可以去管理平台觀看這些客戶的相關報表。

這個機制跟 podcast 體系的前綴碼機制有些共同點：

它們都是以第三方供應商的名義存在。
一個網站(頻道)允許多家第三方程式分別記錄客戶數據。
它們都可以記錄客戶的造訪時間、客戶來源地、透過什麼程式(瀏覽器)造訪這一類的基本資料。

既然討論到風險，就來檢視看看在這樣的架構下，如果第三方服務故障了會發生些什麼事。

以業主自己的網站(或者可以說商店)而言，受到波及的程度就如同這些紅外線感應器、監視器都壞掉了，雖然對於遭小偷等等的情境會很不方便，但基本上還是能夠維持營業狀態，並且可以在這段期間等待機器修復；稍微細心一點的業主甚至會同時準備兩套不同廠牌的監視器，確保在其中一套故障時，另一套可以繼續正常執行。

2. podcast 的紀錄風險

這些第三方供應商通常因為名氣很大(例如 Google / AWS)，使得一般的業主在導入它們時從來就沒有想過會有故障的可能，事實上大名鼎鼎的 AWS 就曾在美國時間 2020/11/25 無預警當機，造成各大商家分別都有不少損失，而這次的當機也讓 podcast 生態系浮現出潛在受災戶的現象。

若您擁有自己的 podcast 頻道且剛好使用 chartable 這間前綴碼服務的話，回想一下 2020/11/25 那天的聽眾造訪數據是否異常的少？不只這樣，繼續回想一下，那一天的頻道是不是根本就無法聽任何一集的內容？

這個原因與 podcast 生態系對於聽眾數據的「記錄方式」有關，可以拿剛才商店這個具象化的例子繼續描述：一個沒有任何第三方前綴碼的頻道就是一間單純的商店，老闆一樣可以用自己的器材記錄自訪客人的數據，此時若導入了某家第三方前綴碼服務，就相當於在商店外蓋了一層類似監獄的圍牆，客人出入都要通過這個圍牆的哨兵，由哨兵負責開關門以及紀錄客人的各種資訊；此時若要再導入另一家第三方前綴碼服務，則又會在更外層再度建造一道圍牆以及配置一名哨兵。

上個段落提到 podcast 雖然跟一般網站的紀錄機制有些共同點，但它本身卻有著異於一般網站的致命缺點：任何一個第三方網站故障都會導致整個頻道故障。

繼續拿城牆與商店的例子做討論，一間商店(podcast 頻道)導入了兩道外圍城牆(前綴碼)，其中一道城牆壞了(第三方服務故障)，哨兵無法替客戶開門進入下一層或者進入商店，最後客人無法購物，業主也就沒有生意(無法收聽)。

這個問題的原因就出在「記錄方式」，以一般網站而言，客戶使用瀏覽器連線到購物網買東西，瀏覽器之所以可以一邊利用程式碼紀錄他的個人資料一邊把網站內容呈現給他，是因為在這個過程中，造訪網址中的「域名」並沒有改變；而 podcast 生態系中，聽眾點擊播放了一個 EP，播放軟體必須要先到達第一間前綴碼服務，讓它記錄自己的資訊後在放行到下一家服務，直到最後的服務就是這個 EP 本身，在這其中如果任何一個環節中斷了，聽眾就會無法收聽。

我們繼續拿我自己頻道中的某一集收聽網址作範例，詳細請參考「Podcast 數據自修: 前綴網址原理」。

https://podcast.mohohan.com/track/chtbl.com/track/99CED3/track.fstry.me/p/fbnmxysm/rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736
Newbie Homemade Mashup Lab 其中一集的實際收聽網址

我們就用黃色標示出「域名」。

https://podcast.mohohan.com/track/chtbl.com/track/99CED3/track.fstry.me/p/fbnmxysm/rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736

這個網址「目前」的「域名」是「podcast.mohohan.com」，所謂「域名」，可以理解成「供應商/廠商/單位」，「域名」是不帶「https://」符號的，也不帶任何「/」符號，最簡單從網址取得域名的方式為「由左至右，從第一個 // 往下算，直到之後看到的第一個 / 符號之前的所有東西」。

既然「域名」是一個「單位」，那顯然代表這個 EP 一開始其實根本不是在我頻道的 Hosting 也就是 SoundOn 這個單位做管理的，它是在「podcast.mohohan.com」這個單位，而這個名字怎麼看都不像 SoundOn。

依照「Podcast 數據自修: 前綴網址原理」的描述，聽眾點擊播放了這個 EP，之後會跳轉的網址會變成這樣。

https://chtbl.com/track/99CED3/track.fstry.me/p/fbnmxysm/rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736

這時候，網址「目前」的「域名」就變成了「chtbl.com」，代表目前聽眾又被另一個單位接管了，這個單位就叫做 chartable，此時還無法聽到 EP 內容，如果它不幸如同 2020/11/25 那樣的故障了，那麼聽眾點擊播放之後就會在這邊中斷，聽眾什麼也聽不到也不會有任何提示。

若 chartable 服務一切成正常的話，接著網址又變成這樣。

https://track.fstry.me/p/fbnmxysm/rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736

這時候，網址「目前」的「域名」就變成了「track.fstry.me」，代表目前聽眾又被另一個單位接管，這個單位就叫做 Firstory，此時也還是還無法聽到 EP 內容。

無論如何，若 Firstory 服務一切成正常的話，接著網址又變成這樣。

https://rss.soundon.fm/rssf/3ef665f1-1091-42de-bedd-7ab16c84fbc6/feedurl/d4d9c8c5-8421-424c-b097-105d3f037ce8/rssFileVip.mp3?timestamp=1605844818736

這時候，這個網址「目前」的「域名」就變成了「rss.soundon.fm」，代表聽眾終於被 Hosting 接管了，此時終於可以聽到 EP 內容。

事實上，剛才的每一層接管單位都會有故障的風險，我們原先將數據分散放置於多個單位是為了保證它們都會有其他安全備份，但這些備份又引來了其他的風險，似乎又背離了初衷。

3. 解決方式與衍生議題探討

關於這個問題我其實沒有想到絕對完善的解決方式，僅在這邊提出相對降低風險的方法。

I: 第三方的超級前綴服務：

這個前綴碼無法跟其他的前綴調換順序，永遠要擺在第一個，代表單集 EP 的最初接管單位一定是這個超級前綴，它的工作除了記錄聽眾數據、放行至下一單位之外，還需要預先分析網址中包含的所有剩餘單位，預先偵測這些單位當下是否故障，若某單位的服務已故障，超級前綴就要在放行前，將網址的剩餘部分去除問題單位的段落。

它的好處是除了自己本身的服務外，若其他第三方服務故障了，最終也不會影響聽眾的收聽體驗，不過如果超級前綴服務本身故障的情況下就會受到影響。

II: Hosting 方的前綴監控：

雖然以頻道主持人的權限，可以做到超級前綴這樣的機制，但如果每個頻道主持人都要製作一套這樣的機制不免覺得浪費資源，Hosting 端或許日後會提出統整的第三方服務監控機制，由它們定期主動監測各大第三方服務的狀態，當發覺某些服務故障了，Hosting 就會主動更新所有使用該第三方服務旗下頻道收聽連結的網址，去除有問題的那一段落，等待日後再度監測該單位恢復正常狀態後，再把這些段落添加回來。

它的好處是可以在所有第三方服務都故障的情況下依然正常運行，相對於超級前綴似乎是更有效率的辦法，不過大多數的頻道都會以 RSS 名義在各大主流平台上架，例如 Apple Podcast，主流平台只會「定期但非即時」的向 Hosting 抓取頻道的 EP 連結，有可能造成 Hosting 已移除某頻道問題單位的網址但 Apple Podcast 尚未來到 Hosting 更新這些網址，導致聽眾還是無法聽到 EP，在這個情況下，似乎超級前綴就間接可以解決這種問題了。

III: 超級前綴標準化 + Hosting 方的前綴監控與 Shuffle：

我覺得超級前綴在實作上面簡單快速，日後或者現在其實就可能有部分供應商已經在著手進行了，當每一個供應商所製作的前綴碼都符合超級前綴標準的話，前綴碼就可以恢復任意調換順序的特色。

有了這樣的性質，Hosting 方依然可以進行前綴服務監控機制，當某前綴服務故障了，Hosting 一樣主動更新所有使用該第三方服務旗下頻道收聽連結的網址，去除有問題的那一段落，若還是很不幸主流平台在這段時間還沒有更新 RSS，那起碼可以保證「更新前的舊 EP 網址」中「有問題的前綴服務」會被最前面的超級前綴偵測並過濾掉，在這種機制下，剩餘的風險情境就是剛才「有問題的前綴服務」剛好就放在網址的最前面，不過這種情境的發生機率實在太低了。

儘管如此，我們還是可以想像一下如果剛才的超特殊案例還是發生了，有沒有什麼方法可以繼續降低這樣的事件機率，我自己提出的方法就是前綴 Shuffle，Hosting 一段時間就會固定將所有旗下頻道中的所有 EP 按照有綁定的前綴服務，進行順序上的隨機調整，這樣至少可以保證相同的頻道中，如果某個 EP 不幸發生剛才的最糟事件之後，其他 EP 或許還可以聽。