揭開 17LIVE SRE 神秘面紗
前言
17 app 的服務遍及全球，它是如何一直提供穩定服務並呈現給使用者的好的品質？其實，背後有著一支勁旅，他們隨時洞察系統狀況，找出問題並針對新發現的問題制定應變措施，或是讓出錯的系統不影響使用者的產品使用體驗；平時則是做好監控與風險管理，時時準備好備用的系統以備不時之需。這些有著如此扎實維運基本功的工程師，透過經歷過無數次的練習以及危機處理，即使現在出現嚴重的錯誤也知道怎麼樣繼續提供服務給使用者。他們就是 17LIVE 的 SRE（Site Reliability Engineering）團隊。
什麼是 SRE
SRE 一詞來自於 Google 的網站可靠性工程師，此職位在 Google 是「崇高」的。他們設計具備高可伸縮性和高可靠性的系統、決定是否可以發佈該產品、為大型任務、服務器和其他人員開發管理系統工具、提供基本服務與計劃系統架構。
SRE 是一個以研發工程師的角度，使用軟體工具來解決運作方面重複性高的問題，降低人工操作產生的錯誤率，並透過監控與維護機器來確保服務正常運作。SRE 的工作內容如同自己照顧小孩，我們小心翼翼地確保著維運方面任何的事物。
17LIVE SRE 團隊現況
17LIVE 的 SRE 是個什麼樣的職務？以 17 來說，SRE 是由軟體工程師來負責維運工作的規劃以及執行、確保正式環境的服務可使用性、根據 17 app 的使用量來彈性增加機器並確保機器保持在優質的運作效能。
正因為每天晚上很多人使用 17 app，加上公司也不斷擴張業務，帶來更多新的使用者使用直播服務。工程團隊除了追求打造良好的使用體驗，並且提供流暢的影音內容之外，最大的挑戰就是如何不讓服務中斷，這同時也是 SRE 團隊的其中一個追求的目標。
SRE 團隊是 17 app 的強力後盾，在維運方面，SRE 已經實作出可大規模部署的腳本、容易和基礎設施整合的工具、完成服務全數容器化、維運分佈式叢集系統上的服務。同時也協助前後端、資料等團隊自製的系統，配置良好的基礎設施與資料庫，使他們的維運步上正軌。
目前絕大多數的服務都是使用 GCP 並容器化佈署在 Kubernetes 上，SRE 也間接促進工程師在 Docker 上進行程式開發，讓工程師習得基礎的 Docker 操作能力。
目前只有 4人的 SRE 團隊依舊需要更多有開發能力且對維運有興趣的人員，而這些人員一樣被期望著能有足夠的技術能力快速開發出軟體工具來取代手工操作。
團隊核心價值
過往，維運人員都關在機房做自己的事，所以不一定能理解公司其他部門的事情。
17 的 SRE 緣起於 Google SRE 在一場工作坊中所講述的理念與其落實的心得，因此在公司內部成立了 SRE 部門，希望維運人員可以跳脫工作上的隔閡，積極地與公司不同人的交流，不再只負責管理機器；透過參與公司的大小事，進而成為公司的一個重要角色。
降低穀倉效應
我們先來談談一般企業最常遇到的問題：穀倉效應。
穀倉效應是指企業內部因缺少溝通，部門間各自為政，只有垂直的指揮系統，沒有水平的協同機制，就像一個個的穀倉，各自擁有獨立的進出系統，但缺少了穀倉與穀倉之間的溝通和互動 — MBA 智庫百科
當組織發展到一定規模時，部門主管會開始將職責拆解並明確定義工作內容，並且訂定該職位的 KPI。一個人只需要完成他在此公司該負責的任務以及 KPI，但從維運人員的角度以及工作內容來看，通常為了應付軟體正常運作的事務就疲於奔命，就不會特別花時間去了解別人在做什麼。
為了解決穀倉效應，17 透過平常的 peer review 做起，定期進行 1 on 1。透過 peer review 獲得的資訊撰寫文件來留下紀錄，使知識得以分享、提升同事間互相幫忙，同時每個文件都會有行動項目以利執行。對於我們來說，花費大量時間設立任何東西，都比不上持續促進人員互動與獲得回饋來得重要的。我們相信人員與互動重於流程與工具。
接受失敗並認為是正常的
17 在建立接受失敗的環境下了很多苦工，我們要建立具有安全感的環境讓人願意坦然面對失敗並且願意從中學習。透過撰寫事後檢討報告（postmortem）來面對失敗及做經驗學習。SRE 的事後檢討報告內容簡短扼要，主要涵蓋四個元素：狀況總結、肇因爲何、發生問題的時間線、如何避免再次發生此錯誤。在問題發生時，我們就事論事解決問題並且學習。例如我們發現系統超出負載太多次，在解決這樣的問題之後，就撰寫事後檢討報吿並作經驗分享，讓其他工程師知道如果再次發生相同的情況可以採取什麼措施。另外寫事後檢討報吿的好處是，我們可以從中獲得經驗並且思考新的解決方案，例如後面篇幅會提到的工作自動化，就是一種利用創新的方式解決問題的肇因。
實施漸進式變革
系統轉型失敗的案例多不勝數，很多失敗的因素在於一下子變動內容過大，以及相對應的教育訓練都不足夠或不到位。
以 17 的工程團隊為例，我們現在每位工程師每天平均提交一次，每次提交的準則是完成實作一部分的功能就提交，這樣做的目的是要降低除錯的難度。假設整個團隊一天只提交一次，這個提交肯定會有很多同時異動的檔案，當要修正問題時，第一時間很難知道是哪裡出了問題，在修改程式碼的工作上肯定會曠日費時。
在測試方面，17 透過整合系統確保每個提交都是能與現有的系統整合並且能上準備環境進行 e2e 測試。過程中一旦單元測試或整合測試失敗，我們就會馬上知道這個提交有誤，即可針對這個提交的內容做集中且快速的修正，這樣的好處是不會等到很後面才產生程式無法整合的風險。
17 的發佈軟體流程也做了改變，從以前一週發佈一次新功能，不斷微調發佈流程，到現在每天都能發佈一次，改變的原因也是一樣。如果一週只發佈一次，做好的軟體功能不見得能被市場接受外，如果出現系統性的問題，即使退回先前的軟體版本，也要花很多的時間除錯。
利用工具和自動化
17 自動化的核心觀念是要把所有能自動化的事情都自動化，例如上線一個新的功能的流程操作方式不怎麼會變動，我們就把上線新功能的流程透過撰寫 shell script 達成自動化。
自動化的威力在於可以把繁雜且不斷重複的人工作業交給電腦執行。以前上線的流程是從開發環境手動把做好的功能放到測試環境，待測試完成再手動放到準備環境做更多的測試，最後部署到正式環境；現在我們自動化了包括測試、部署、發佈等重複性高的工作，現在 SRE 上班時只要把準備環境的程式碼進行 e2e 測試後，就可以透過下指令來執行繁複的流程，將新功能部署到正式環境。
從上可知，17 現在很多測試與部署的任務都自動化，因為重複性的高的工作其實不值得用一個工程師的人力去重複做同樣的事情。再者，對於維運工程師來說，履歷上寫著為公司自動化了什麼東西，會比為公司做了哪些以事務還要加分。
量測任何東西
公司為了穩定提供直播服務，以及給使用者良好的產品體驗，我們透過許多工具以及設立許多指標進行監控與量測。我們分了四個層級進行不同的量測，分別是 cluster 層級、系統層級、應用程式層級、以及程式碼層級。
在 cluster 層級，我們最主要檢測所有的服務是否正常，以及 cluster 系統間有沒有異常的狀況，例如可能被駭客攻擊、DDoS 攻擊或者是有異常的資料存取狀況，此時我們可透過這些指標來發現問題與做出應對。
系統層級則是量測了系統的狀況，例如監測 CPU 的運作狀況，記憶體的使用狀況，以及硬體設備的溫度等。
應用程式層級是量測應用程式，量測的部分涵蓋：有沒有異常的終止、或是 app 本身運作出現其他問題。
在程式碼層級，產品團隊直接量測程式碼的品質好壞，例如看 bug 的數量有沒有異常的增加，以及測試碼達到的覆蓋率有多高。
團隊工作內容
日常工作流程
我們每一季會設定季目標，目標裡面會有很多要實現的工作內容，像是實作工具達成工作自動化，或是改善某些現有的工作流程，而每個人都會負責一到兩個工作內容。為了讓季目標更容易達成，SRE 團隊會在一個月前就密切討論並安排工作內容，提前討論的好處是提高每個人主動去想要怎麼實作的動力。當季目標設立完成並開始執行的時候，我們會用一個 17 SRE 團隊自己命名為 Circuit 的方式來執行我們的流程，一個 Circuit 為期兩週。這個流程類似 Scrum，但不一樣的地方在於開發工作不會在一個 scrum 週期內結束，不可預期的因素非常多，例如軟體版本升級沒有如官方文件寫得如此順利，同時工作內容也不一定能被分解的非常細，並可在兩週內完成。回顧改善方面，我們會在每兩週的 sync 會議上，讓每個 SRE 工程師自評進度是快的還是慢的，並且從中思考如何調整。
平時 SRE 也會面對到臨時產生的需求單，SRE 團隊建立一需求表單來蒐集各部門提出的內容。在團隊接到需求後，會區分這些臨時需求的大小，並以複雜度分為三種：第一種是如果這個需求需要同時 SRE 跟後端工程師來實作的話，我們會按排一個 SRE 跟著後端工程師實作需求；第二種則是偏向顧問的角色，例如對於資料庫的調整，一般後端工程師熟悉開立資料表或是對資料表做讀寫等操作，而 SRE 會站在穩定性的角度協助後端工程師做資料庫的效能調校，或是協助做正式環境的資料內容修改，又或者可能某個功能團隊有新的系統需求，此時 SRE 會從系統架構的穩定性，與該團隊討論怎麼做，使架構符合長遠的系統規劃；最後一種需求是開權限，也是最常見的需求，這類型的工作內容都很小但是重複性高，我們就安排時間將流程自動化或是設計成一種工具。以新增 MySQL 操作權限為例，過往 SRE 每次登入資料庫來輸入 CREATE 跟 GRANT 指令來新增權限，再把相關資訊貼給人，而完成自動化後，現在 SRE 只要下一個指令，就會自動產生帳號密碼，並且透過 slackbot 傳送給人。
最後，除了SRE 團隊之外還有 Backend 我們有 8人輪流值班維護系統正常運作，每人一次值班一個禮拜，負責值班的人當周主要有兩個工作內容：每日切版與上版新功能，以及故障發生時的第一線排查。背後的原因是：負責上版的同仁，多半對當天上版的內容比較熟悉；萬一出了問題，也比較容易第一時間排解。
如何處理緊急問題
當系統中斷的時候，我們第一時間並不會去找肇因，而是先用應急措施讓系統恢復正常運作為最大目標。同一時間該位 SRE 會盡可能留下證據，例如機器損毀的話，我們會新增另外一台機器來換掉壞掉的機器，同時把機器損毀的證據留下來。
先應變解決問題之後，我們會在事後再去找問題的肇因。事情發生的當下並不會有心情去慢慢抽絲剝繭找問題，例如系統在凌晨出問題時，SRE 可能剛醒來打開電腦螢幕試著解決問題，就不會去想問題在哪邊，一切都等到事發過後才有餘裕去找問題。
如何找到並解決肇因
在問題解決後，隔天到公司上班的時候，SRE 團隊會一起去審視發生的問題，思考要怎麼解決發生的問題。
一般來說，會發生問題通常分成兩種，基礎設施出現問題，或是 app 出現問題。以判斷是否基礎設施出現問題來說，我們會透過度量指標去找出異常的部分。透過平時大量收集的指標建立監控的 dashboard 來形成很完整的監控體系，我們可以從中利用不同的指標圖來找到一些異常的特徵，進而找出問題的肇因，例如 MySQL outage 時，就可以從我們的監控系統中某幾張圖表中看到讀資料庫的頻率突然持續好幾分鐘的高峰，造成整體讀取資料的速度變慢，這時我們就可以根據這些資訊去優化系統。如果異常的特徵可以重現整個過程，在除錯方面是如虎添翼。無法找到異常的特徵時，會繼續往下挖掘，判斷是不是 app 出現問題，此時會從有配合實作穩定性程式的後端工程師，以後端工程師的角度那邊去找肇因。
最後，我們會將這些問題發生的原因以及解決方式寫成 postmortem ，同時附上要如何改善，或是未來遇到相同情況要如何解決。如果是缺乏度量的指標，我們的 postmortem 就會總結出資料不足的狀況，原因是當時缺少某些關建資料使問題更嚴重，要加更多的指標來提早發現問題，或是可以更深入地找到問題，在發生問題前就可以透過自動化或是人工處理它。
團隊願景
放眼未來，SRE 團隊希望達到兩個願景：提升開發工作的工時佔比到 50% 以上，以及轉型為 GRE (Group Reliability Engineering) 部門。
工具及自動化
目前 SRE 團隊還是花費較多時間在維運的任務上，所以希望未來能將一半以上的工作時間用在開發工具，幫助維運或是加快工作速度。
在自動化方面，17 的 SRE 團隊一直有著目標，例如期望未來可以做到當系統偵測到某個雲端有問題，就把系統自動切換到另外一個雲端，避免一個雲端無法提供服務時，造成我們所有的服務都不能使用。
GRE(Group Reliability Engineering)
目前 SRE 部門致力於以 17 為核心進行全集團的 SRE 轉型成為 GRE。GRE 是 Group Reliability Engineering 的縮寫。建立 GRE 的目的在於希望這個職位能夠促進集團各公司間的 SRE 互助以及變強，例如 17 Media、MeMe直播或是 HandsUP 等各公司的 SRE 能夠彼此分享遇到的問題的解決辦法、技能方面的經驗學習並傳承等。同時，我們把所有的 SRE 部門集合起來就可以有更大的力量與服務供應商議價。
結論
可能很多人會問，我要怎麼開始 SRE 的旅程，我想自己架 CI/CD，或在 side project 使用 Kubernetes、 Docker。但是開始上手後，發現機器永遠只會一台，如果要多台，又很難模擬，為了幫助克服常見的障礙，以下是 17LIVE SRE 團隊公開練功升等的幾個作法。
首先，如果你對於操作軟體很有興趣，或是習慣這樣的學習方式，但我們也很清楚，若非有大型的系統或是產品，一般人很難去學習或實踐網站可靠性工程的方法論。一般我們會透過網路上的 lab 來學習，例如使用 qwiklab，如果對於 Kubernetes有興趣，可以透過 AWS 或 GCP 免費額度來嘗試 ，或是用 minikube 在本機上架 Kubernetes 集群也行，務必要能融會貫通，因為一定會遇到不能使用特定的工具的情況。
我們非常推薦 Google 的兩本 SRE 書籍：網站可靠性工程、The Site Reliability Workbook 讓你閱讀，但這些最終是 Google 的最佳實務經驗，不見得適合套用在所有的公司，以及公司文化，可以當一個標竿學習，知道這家公司怎麼做到的。
還有一個作法，就是 17LIVE SRE 團隊持續徵才中，在 17LIVE 你可以遇到頂尖好手，加速您上手 SRE 相關技能，這是一個多元化 app 的壯大旅程，歡迎加入我們！
