網站可靠性的工作手冊

The Site Reliability Workbook, Practical Ways to Implement SRE

產品開發團隊 和 維運團隊 彼此之間是有鴻溝的， 兩者在設計架構上也會因為立場不同而有不同見解。

根據經驗，Google 認為最重要的功能（傳統上是產品開發團隊負責）是可用性（傳統上是維運團隊負責）， 而這個功能遍及所有線上產品。 在設計之初缺乏可用性的考量相當於用更高的營運成本去設計更少的功能， 相反的，考量可用性下持續設計、迭代產品，最終透過低營運成本達到穩健且可擴充的產品， 這種設計方式，稱為 非抽象大型系統設計（Non-Abstract Large System Design）。

SRE（Site Reliability Engineering）就是兩團隊的橋樑，也是實踐非抽象大型系統設計的基礎。 SRE 不一定是一個團隊，也可以是一種深入在開發團隊和維運團隊的文化。

什麼文化？以下將從各個面向去探討：

• 勞動力，先去辨識勞動力，然後進行指標，最後減低勞動力。
• 處理舊有系統，透過擱置、包裝、擴充、替換、撤除、託管去處理。
• 簡化系統，透過辨識、預防和處理來簡化系統多個面向。
• 待命小組，分配 on-call 權責、工時的輪替，自動化的必要。
• 災難管理，緊急事件時的責任劃分，並且常態且實際的訓練。
• 事後析誤文化，如何讓企業在災難發生後，學習到最多？
• 負載管理，好的負載管理機制通常是複合型的，但建構後，又有哪些維運上的建議呢？
• 非抽象大型系統設計，讓開發者設計系統架構時能有個依據去建立穩健而又高擴充的系統。
• 資料管線設計，資料管線幫助整合資料，其設計和線上系統有異曲同工之妙。
• 設定檔的最佳實踐，好的服務設定方式，會減少緊急情況的發生。
• 金絲雀部署，部署工程也是確保服務穩定的重要工具。

什麼是維運

對我來說維運是困難的，但是必須要先釐清什麼是維運。

維持運作，不僅僅是功能出錯了修修補補，或者依賴套件版本更新， 更多的是你要去面對很多難以抉擇的選擇，例如：

• 服務流量上升了，從一台變成兩台之後，我要怎麼知道流量總量，500 的比例等等；
• 外部依賴從相同資料中心，搬遷到雲端，觀察到的 P99 潛時拉高了，該怎麼處理；
• 每天固定某一時段，500 比例會升高，我該怎麼追蹤問題？

這些都是需要花時間，靜下來好好思考，摸索可能的原因和方案，和各個團隊溝通暸解， 最終的手段甚至只是個妥協方案，這些都再再考驗維運人員的智慧和經驗。

真正有效的工作方式，不是鐵人三項或馬拉松，比誰堅持的時間長，而是短跑，當機會來臨的時候衝刺，平時注意身體健康和休息。

— Naval Ravikant