Sling Media, Inc. 簡介

Sling Media 是2004年有一對兄弟 Blake Krikorian 和 Jason Krikorian 創立在加州。二位都是死忠的舊金山巨人球迷。在美國球賽轉播有地域限制，在地球隊的比賽只能在當地域轉播。比如舊金山巨人隊的比賽只能在北加州收看，在南加是道奇的市場就無法收看。當然這是在還有 MLB.tv 還沒有成立之前。這對兄弟想在出差時還可以看自家球隊的比賽，決定自己研發一個可以把自家第四台訊號透過 Internet 來收看的裝置。一年後打造出Slingbox，成為早期IP (Internet Protocol) 影音串流的先鋒。Slingbox 更在2007獲得 Technology Emmy Award (科技艾美奬)。在2010年趕上 iPhone 和 Android 的潮流釋出 Slingbox Apps 在二大智慧手機陣營，讓使用者可以在行動裝置上觀賞自己專有的影音媒體。

Slingbox 有二個重要的技術，除了在機上盒的硬體技術之外。我簡單的在下面介紹一下。

Place Shifting (地點轉換)

當然就是影音訊號可以不再限制於定點。只要透過網路，就可以達成串流。串流的技術有分 IP point-to-point (IP 點對點), UDP (User Datagram Protocol) point-to-point 還有 cloud relay (雲端中繼轉播)。當然我們都知道防火牆和網路提供商會阻擋一些通訊協定。還有一些埠口也不會全部支援。理想的影音串流是通過 UDP 來達到快又穩定的結果。但是 UDP 不容易支援，所以如果UDP連線無法建立，就會切換到用 TCP 連線。通常 TCP 連線在大部份的情況下都會成功。要不然進去路由器的管理畫面把埠口 5001 或 5201打開應該就沒題了。如果 TCP 和 UDP 都不行的情況下，最後的手法就是雲端中繼轉播 Relay 了。要講詳細須要花很多篇幅，簡單來說就是家裡的 Slingbox 和行動裝置連線到雲端服務器的中繼點。影音資料上傳到雲端，用戶端再下載來看。透過一個中繼點來完成連線。但這方法要耗雲端計算的時間，也就是花費，當然Sling方面不不建議囉。

Time Shifting (時間轉換)

早期看電視時都不能倒轉或暫停。所以都要趁廣告時再去拿碗爆米花或倒杯飲料。但如果看 Slingbox 時，它會有 Buffering 緩衝功能。一方面可以保持連線穩定，再來也可以把影音資料做暫存來達到倒轉和暫停的功能。當然這樣你的節目就不是即時的，但使用者不會錯過任一個精彩畫面。即使是類比第四台訊號還沒有支援暫停功能時。你可不想錯過一個關鍵的全壘打吧。

IT Project Manager

當然我接觸 Slingbox 也是因為想看台灣的節目。我早早就放了一台 Slingbox Pro HD 在台灣老家。在早期第四台還不是全面數位的時代，可以直接把第四台的 coaxial cable 插到Slingbox後的埠就設定完就可以直接觀看了。在2008年時這科技實在是太酷了。那時在電腦上就可以在紐約直接看台灣的第四台，還可以轉台。我記得在去紐澤西拜訪親戚的路上還可以在荷蘭隧道後在車上看台灣新聞。當然我是專心開車囉。

Sling 很好心的讓我從紐約搬到我夢想中的科技重鎮—矽谷，還支付了我一筆不小的搬家費還有暫時棲身的旅館費。我終於成為了真正的科技人員。辨公室有濃縮咖啡機和自己打汽泡的炭酸飲料製造機。大樓還有內建健身房。一切都像在科技網站上看到的。星期五下午還有 Happy Hour, 大家輪流帶不同的酒跟大家分享。我最記得的是我上司的抽屜有一罐三多利的響威士忌我們喝了好一陣子才解決。還有星期五中午同事都會聚餐，三點多去附近的好事多買起士和零嘴，大約四點就開喝了。有時喝到快六點還不能立即開車回家，要等酒退一下或請共乘的同事代駕。同事也都很合作，很友善，也很幫忙。

有點離題了，只是小介紹矽谷小公司工作的風格。其實這一年也是我技術能力大躍進的一年。一開始我幾乎聽不懂一些技術字眼。什麼 memcache, mongo DB, splunk 分析的術語，我以前在紐約從來沒用接觸過。還有雲端 AWS 的東西也是剛碰到。那時會用 AWS 的真的還算很屌的。大家都搶著把東西放到雲端上。很多我現在的 Linux 系統管理基礎都是在那時打下的。我之前在紐約還覺得自己是技術底的，一來矽谷立刻被打槍。還好我上司很細心的指導，同事也花很多時間在白板上詳細解說，我才能在短時間內上手。

在 Sling Media 待了不是很長的時間。約一年左右就去水果公司當顧問挑戰 mobile app 開發了。現在想起來還有點小後悔。下面例一下我在 Sling Media 時的貢獻:

遷移資料中心

後台服務的部份在一開始的時候全部都架在 Sunnyvale 資料中心二排伺服器主機上。當時有 VMWare 己經算是很先進了。也有一些著重效能的服務是建在真立的主機上。全部都是跑在Linux 上。我在這一陣子學會超多 Linux 指令。有時在管理員不在時，緊急時還要登入把當掉的程序重新啟動。那時候的方針是不開放管理員權限給軟體工程師。當然是因為有軟體在還沒完全測試完就部署到正式環境裡了。我相信這樣的事現在還會出現。不管有沒有 QA Automation 還是 CI。

當然遷移資料中心一事我是有點經驗了。就把服務一個個轉移，網路的設定和切換要計劃仔細。但在我去公司前，他們己經嚐試過轉移但是失敗把網路連線回愎做為收場。為了這個案子，我還第一次去了中西部 Wyoming 州的 Cheyenne 新資料中心拜碼頭。經過了多個月的重長計議，溝通，人力資源的分配，我也做了張很仔細的戰略表。在系統切換之日一條條的執行後終於成功了。但切換後，我感覺到公司有意把我移去外州。我就開始尋覓新的工作機會了。

完成一百萬以上連線測試

如果我沒有記錯，在 2011 年的美式足球超級盃比賽前，網路工程師和架構師想確定新的分散架構能不能挺住一百萬以上的同時連線壓力測試。意思就是在超級盃當天，能不能讓一百萬個使用著保持連線穩定來遠端觀看超級盃。想想要讓影音串流這樣佔流量的服務來同時供給一百萬個連線，現在也只有 YouTube 或 Netflix 這類的服務有能力吧。當然也不是單純的添購網路設備就可以簡單解決的問題。

我和二位工程師和架構師合作，訂立了完整的專案計劃成功的被總公司批準來測試。因為要模擬一百萬個連線是要在短時間內在 AWS 上自動生成一定數量的服務器，再產生一定數量的連線才能完成的。測一次需要花上不少錢。最後成功後就順利的導入營運中。二個同事還申請了專利，我也在現在都還跟他們保持連繫。

產品釋出和後端服務的營運

平常的時候就是支援軟體的更新和營運的穩定了。這可就累人了。有時候第一線的同事睡死或沒接電話時，又是大狀況時，電話就會打過來了。我有一次半夜三點還打到  Wyoming 的大上司那報告壞情況。作戰中心就要成立必須在最短的時間讓系統回愎。

當然如果這事在現在都講求系統自我修復，程式版本回歸自動化或整個雲端中心切換的今日。這樣的營運模式就只能當作痛苦的回憶了。

新產品測試和研發支援

除了支援正式營運環境，Sling IT 也支持另外二個測試環境來供軟體開發團隊測試和開發。這些服務器都是駕在虛擬環境裡。被搞壞了再回復就好了。但有時候有些新的更新或軟體套件和依附的套件不一定會完全支援。所以平時也是有很多從開發團隊的需求。有時候資源不夠，就要請開發團隊等，或關掉一些沒在用的服務器。但很多時候開發團隊會沒辨法等會抱怨我們在延誤軟體開發的時程。這時就是我會出現做協調。有時候也會夾在架構的爭吵中。幸好我這在調解方面還算在行，最後都可以找到平衡點。