引言：本文作者ben treynor sloss，google 運維團隊的高階副總裁，sre 名稱的發明者，在這裡提供了他對sre 的定義。大家都知道， 計算機軟體系統離開人通常是無法自主執行的。那麼，究竟應該如何去運維乙個日趨複雜的大型分布式計算系統呢？僱傭系統管理員（sysadmin）運維複雜的計算機系統，是行業內一直以來的普遍做法。而google 的解決之道是——sre。本文選自《sre：google運維解密》。
sre 團隊通過僱傭軟體工程師，創造軟體系統來維護系統執行以替代傳統模型中的人工操作。
sre 究竟是如何在google 起源的呢？ 其實我的答案非常簡單：sre 就是讓軟體工程師來設計乙個新型運維團隊的結果。當我在2003 年加入google 的時候，我的任務就是領導乙個由7 名軟體工程師組成的「生產環境維護組」。當時，我的整個職業生涯都專注於軟體工程，所以很自然，我按照自己最習慣的工作方式和管理方式來組建了這個團隊。
時過境遷，當年的7 人團隊已經成長為公司內部1000 餘人的sre 團隊，但是sre 團隊的指導理念和工作方式還是基本保持了我最初的想法。
sre 方**中的主要模組，就是sre 團隊的構成。每個sre 團隊裡基本上有兩類工程師。
第一類，團隊中 50%~60% 是標準的軟體工程師，具體來講，就是那些能夠正常通過google 軟體工程師招聘流程的人。第二類，其他40%~50% 則是一些基本滿足google軟體工程師標準（具備85%~99% 所要求的技能），但是同時具有一定程度的其他技術能力的工程師。 目前來看， unix 系統內部細節和1~3 層網路知識是google 最看重的兩類額外的技術能力。
除此之外， 所有的sre 團隊成員都必須非常願意、也非常相信用軟體工程方法可以解決複雜的運維問題。google 一直密切關注這兩類候選人在招聘通過之後在sre 團隊中的表現，但是到目前為止還沒有發現他們在工作上和成績上的顯著差異。事實上，由於兩類工程師技術背景互補，sre 團隊經常能夠尋找到全新的、高效的解決問題的方法。
按照這個標準來招聘和管理sre 團隊，我們很快發現sre 團隊成員具有如下特點：
(a) 對重複性、手工性的操作有天然的排斥感。
(b) 有足夠的技術能力快速開發出軟體系統以替代手工操作。
同時，sre 團隊和產品研發部門在學術和工作背景上非常相似。因此，從本質上來說，sre 就是在用軟體工程的思維和方**完成以前由系統管理員團隊手動完成的任務。這些sre 傾向於通過設計、構建自動化工具來取代人工操作。
sre 模型成功的關鍵在於對工程的關注。如果沒有持續的、工程化的解決方案，運維的壓力就會不斷增加，團隊也就需要更多的人來完成工作。傳統的ops 團隊的大小基本與所服務的產品負載呈線性同步增長。如果乙個產品非常成功，使用者流量越來越大，就需要更多的團隊成員來重複進行同樣的事情。
為了避免這一點，負責運維這個服務的團隊必須有足夠的時間程式設計，否則他們就會被運維工作所淹沒。因此，google 為整個sre 團隊所做的所有傳統運維工作設立了乙個50% 的上限值。傳統運維工作包括：工單處理、手工操作等。設立這樣乙個上限值確保了sre 團隊有足夠的時間改進所維護的服務，將其變得更穩定和更易於維護。這個上限值並不是目標值。隨著時間推移，sre 團隊應該傾向於將基本的運維工作全部消除，全力投入在研發任務上。因為整個系統應該可以自主執行，可以自動修復問題。我們的終極目標是推動整個系統趨向於無人化執行，而不僅僅是自動化某些人工流程。當然，在實際執行中，服務規模的不斷擴張和新功能的上線已經讓sre 夠忙了！
google 的經驗法則是，sre 團隊必須將50% 的精力花在真實的開發工作上。那麼我們是如何確保每個團隊都是這樣做的呢？首先，我們必須不斷地度量每個團隊的工作時間分配。依靠這個資料，sre 管理層會對在開發工作上投入時間不夠的團隊進行調整。通常，管理層會要求該團隊將一些常見的運維工作交還給產品研發部門操作，或者從產品研發部門抽調人力參與團隊輪值值班工作。此外，還可以停止該sre 團隊的一切新增運維工作。只有管理層主動維護每個sre 團隊的工作平衡，我們才能保障他們有足夠的時間和精力去進行真正有創造性的、自主的研發工作，同時，這也保障了sre 團隊有足夠的運維經驗，從而讓他們設計出切實解決問題的系統。
我們發現 google sre 模型在運維大規模複雜系統時有很多優勢。由於sre 在調整google 系統的過程中常常直接參與開發、修改**，sre 文化在公司內部基本代表了一種快速、創新、擁抱變化的文化。實踐證明，sre 團隊執行、維護、改進乙個複雜系統所需要的成員數量與系統部署規模呈非線性增長。而運維同樣的系統，用傳統的系統管理員模型維護則需要更多數量的人。最後，sre 模型不僅消除了傳統模型中研發團隊和運維團隊的衝突焦點，反而促進了整個產品部門水平的整體提高。因為sre 團隊和研發團隊之間的成員可以自由流動，整個產品部門的人員都有機會學習和參與大規模運維部署活動，從中獲得平時難以獲得的寶貴知識。普通的開發人員有多少機會能將自己的程式同時跑在100 萬個cpu 的分布式系統上呢？
雖然sre 模型帶來了一些優勢，但也存在一些問題。google 面對的乙個永續性的難題就是如何招聘合適的sre。首先sre 要和產品研發部門招聘傳統的軟體開發工程師競爭。
其次，由於sre 要求同時具備多項技能，市場上具有相關從業背景和經驗的人就更少了。由於sre 模型也比較新，行業內關於如何建立和維護sre 團隊的相關資訊並不多。最後，sre 團隊建立之後，由於sre 模型中為了提高可靠性需要採取一些與常規做法違背的做法，所以需要強有力的管理層支援才能推行下去。例如：由於乙個季度內的錯誤預算耗盡而停止發布新功能的決定，可能需要管理層的支援才能讓產品研發部門重視起來。
本文選自《sre：google運維解密》，點此鏈結可在博文視點官網檢視此書。
SRE之道 創造軟體系統來維護系統執行
引言 本文作者ben treynor sloss，google 運維團隊的高階副總裁，sre 名稱的發明者，在這裡提供了他對sre 的定義。本文選自 sre google運維解密 大家都知道，計算機軟體系統離開人通常是無法自主執行的。那麼，究竟應該如何去運維乙個日趨複雜的大型分布式計算系統呢？僱傭系...
軟體維護 重灌系統？
上次手機壞了，開不了機，拿到客服中心去看了一下，說是要做軟體維護。做了軟體維護之後，我存的東西全丟了，號碼，簡訊什麼都沒有了！就跟剛出廠一樣，後來我就在想，其實手機所謂的軟體維護是不是就跟電腦所謂的 重灌系統 一回事呢？當你的電腦系統崩潰了進不了系統後，就要重灌系統了，不過電腦的重灌系統不一定會丟失...
規範日誌來提公升系統可維護性
在系統中日誌大體可以分為兩類，一類是流水日誌，另一類是錯誤日誌，對於前一類由於在業務上會有需求，所以設計系統時一般都會考慮，但關於錯誤記錄內容很多情況下都不會納入設計範圍，這樣導致我們開發出來的系統可維護性很差，錯誤日誌幾乎沒有參考 甚至誤導維護人員。怎樣才能輸出良好的日誌資訊呢？我想可以從下面幾點...