前言

這是讀“SRE Google運維解密”有感第二篇，第一篇參見

這本書最近又讀了幾章，結合自己的經歷，有些地方真的能感同身受，有些地方也驚歎SRE充滿辯證的思想，總之SRE是好一本好書，會給你很大的啟發。

充滿辯證的思想

本書主要是講通過SRE思想進行運維體系的構建，除了技術層面以外，我更關注SRE內在充滿辯證的思想。

一個辯證的思想是凡事都有兩面性，這個道理很簡單，大家一聽就說“對啊，這不是廢話麼”，可是面對具體問題的時候，有時候往往做不到這一點。

服務太穩定不好

“什麼？我有沒有聽錯”，一直以來運維人員所追求的不就是穩定的服務麼？可是谷歌認為“在內部程式質量沒有達到一定標準，服務太穩定會產生盲目的依賴”

它舉了一個例子，谷歌的chubby鎖服務，它是一個基礎服務，做為基礎元件很多上層服務依賴於它，但是工程師們認為它還是有缺陷，有問題隱患，而在一段時間內它的表現還異常穩定，這樣就給呼叫方一種錯覺，這個服務很好，越來越多的服務依賴於它。
於是，谷歌幹了一件“不可思議”的事情，對chubby計劃內停止服務，捅破這種穩定的假象，讓呼叫方感受到“原來沒有那麼穩定”，這樣減少了對chubby的過度依賴。
這就是一種辯證的思想，我們一直以來都想追求絕對的穩定，沒有辯證的看穩定的系統有好處，也會有壞處，它會被外界過度依賴，大家用的很開心，可是這個系統如果還有隱患，造成了穩定的假象，一旦出了問題，可能就是大地震。

瑣事也有好處

工作中的瑣事是指那麼“無聊”，“無效率”，“流程化”的事情，很多人都很抵觸，認為它把你的時間碎片化了，使工作沒有效率。 SRE有很大篇幅討論了瑣事(toil)的問題，它認為瑣事也有好處，比如可以適當的減壓，因為做起來不用過多的思考，可以做為創造性工作的一種調劑，從中也能發現需要優化的問題。

當然SRE還是在儘量減少瑣事，它的壞處還是多於好處。

少即是多

谷歌追求一種簡單，有效的解決方案，比如監控項不是越多越好，它列出監控的4個黃金指標

• 延遲
• 流量
• 錯誤
• 飽和度

通過這四個指標，基本可涵蓋大部分問題，設定監控項的時候，我們往往生怕漏掉某個專案，設定非常詳細的監控策略，這些監控項不一定真的有意義，反而會帶來大量的干擾報警。

在程式碼層面也遵循少即是多的原則，無用的程式碼，大量冗餘的註釋都要刪除掉，提供簡單的api入口，我們常常為了以後的擴充套件性，預先加入很多冗餘功能程式碼，谷歌反其道而行，鼓勵程式碼的精簡。

每一行程式碼都是負擔，所有程式碼都必須有存在的目的，軟體工程少就是多！

自動化的壞處

“什麼？我沒有聽錯？自動化會有壞處“，是的，谷歌認為運維自動化是有壞處的。
在運維領域，自動化運維是很多公司的目標，我們認為運維自動化，減少人力，規範操作流程，我們恨不得完全自動化早一天到來，怎麼還能有壞處？

自動化的壞處在於，對於一個運維工程師來講，操作變成黑盒了，他不用明白一個指令碼的原理，只要執行就好了，對於他來講是一件很開心的事，可是帶來的副作用是他對於線上的熟悉程度越來越少，他只會執行這個指令碼，那麼這個指令碼一旦出問題，因為缺少對線上環境的瞭解，無法很快進行修復。

體會到了自動化帶來的負面作用，谷歌希望使用自洽的方案解決問題，這樣才誕生了Borg系統。

故障演習

谷歌會定期舉行故障演習，而且他們是真的在線上演練。
書中的一個例子是隨機的關閉一個數據庫例項，看看會有什麼問題，然後真的出現了一些問題，影響了業務的訪問，通過這次演習他們發現了流程的問題，問題及時修復，避免了隱患。
所以谷歌的思想是:

你是希望系統在星期六凌晨2點，公司大部分同事還在參加黑森林中的團建時出現故障，還是希望和最可靠和最聰明的同事一起仔細監控著他們上週詳細評審過的測試時出現故障呢？

結語

SRE不僅是一些運維的方法論，它的辯證看問題的思想值得我們學習。
先寫這麼多，我得去搬磚了。