沒想到一開賽就遇到週末，週末最適合配著書，喝個下午茶拉！那麼今天先來了解一下傳統開發部門跟維運部門，以及 SRE 的前世今生吧！這裡是今天讀的原文出處：Introduction，話不多說，我們開始囉！

產品在辛辛苦苦被開發出來之後，要怎麼樣才能提供給隔壁的親朋好友使用呢？沒錯！在古早以前，有一個專門的角色「系統管理員」來作部署這件事情。這個角色並不直接要求具備程式語言的能力，但需要熟悉一些工具以及軟體解決方案，以便維護系統。在兩個不同背景的協作下，會遇到哪些矛盾與衝突呢？

傳統開發團隊與維運團隊的矛盾之處

開發團隊：「隨時隨地發佈新功能，沒有任何阻攔」

維運團隊：「一旦一個東西在生產環境中正常工作了，就不要再進行任何改動。」

由於兩個部門使用的語境不同，對風險的定義也不一致。從開發團隊的角度出發，他們會希望能夠為使用者提供「更新潮、更好用的服務」，因此可能對於維運團隊設下嚴密地上線規定，而感到挫折；對於維運團隊的角度而言，他們追求的是「穩定」的服務，而開發團隊每一次新上線的服務都有可能造成系統不穩定的因素。

Google 的解決方案：SRE 團隊的組建

為了解決上述問題，Google 組建了 SRE 團隊。這個 SRE 團隊聘雇軟體工程師去創造系統以維護系統運行，替代傳統模型中的人工操作。以下是團體的組成：

• 50%～60% 是標準的工程師，就是那些能夠取得 Google 開發工程師 offer 的人。
• 40%～50% 則是一些基本滿足 Google 工程師標準（具備 85%～99% 所要求的技能），但是同時具有一定程度的其他技術能力 (UNIX 系統內部細節和 1～3 層網路知識等等) 的工程師。

而 SRE 模型成功的關鍵在於用技術能力來解決維運的問題。如果沒有持續的、工程化的解決方案，維運的壓力就會不斷增加，團隊也就需要更多的人來完成工作。

今日思考題

對於一個產品團隊而言，維運團隊是必需品嗎？還是有其他模式呢？能夠讓開發自行兼顧維運嗎？

在以前的團隊裡，大部分都是由幾個資深的後端工程師去把基礎建設、自動化流程搭建好（連工作流程都是自動化的，真的很幸福），再配合使用一些第三方服務，讓整個系統的可視性大大提升，在服務上線之後，每每遇到一些系統問題，也都能看著 Jira 工單一項一項解決，所以沒有特別感覺維運的重要性。

不過這次來到一個從零開始的產品團隊，就有體會到開發跟維運所看到的視角、需要的背景知識是大大地不同，同時也思考，如果在這種情況下，我要如何更有架構地去組建出一個高可用、容易觀測的系統，去識別在眾多的階段中，是哪幾段流程可以優化。

因此我認為維運是必須的，但是否要獨立出一個維運團隊是可以討論的，從團隊規模、團隊成員的背景才能決定出維運團隊的形狀（也有可能讓開發直接兼顧維運）。

復盤時間

今天稍微瞭解了兩個團隊的核心價值，以及 Google 是怎麼樣去避免這個問題的產生，同時來檢視一下自己的環境吧：

我現在所處的工作場域，開發跟維運是分開的兩個團隊。

日常的工作就是協助開發取得必要的資源、如果 Error Alert 有發通知，會先去檢視一下錯誤資訊，如果很明顯是開發上的 issue，便會通知該負責人處理；若是跟系統設計有關，就會研究一下要如何修復或改善。

除了上述與開發團隊協作的部分，我手邊也負責許多自動化流程，包含基礎建設的搭建、CI/CD Pipeline、各種排程與通知，改天也可以跟大家分享我對於 DX (Developer Experience) 的看法與實踐的一些心得（走遠了 XD

另外也研究如何在系統裡獲得更多可用的資訊，並想辦法可視化。像是 GCP 內的 Operation Suite，裡面有 Logging、Trace、Alert、Error Report、Profiler、Monitoring 等眾多好用的工具，不外乎都是希望能從「快速降低修復時間」，讓系統恢復成可用狀態，逐漸成為一個預防性系統。

綜上所述，雖然這些設施都還在積極搭建中，不過我十分認同也願意用技術能力，而非人工干預的方式，去解決複雜的維運問題。

後記

我發現好像沒辦法一篇文章一個章節誒 OAO，太多 OS 可以寫了 XD，今天就這樣拉～如果有什麼想跟我說的朋友可以在底下留言給我，或是寄信到 mbz8dqf5zg@privaterelay.appleid.com，如果我下班之後有空就會來回覆問題唷！感謝大家今天的收看，我們明天見！