這是讀「sre google運維解密」有感第二篇,第一篇參見
這本書最近又讀了幾章,結合自己的經歷,有些地方真的能感同身受,有些地方也驚嘆sre充滿辯證的思想,總之sre是好一本好書,會給你很大的啟發。
本書主要是講通過sre思想進行運維體系的構建,除了技術層面以外,我更關注sre內在充滿辯證的思想。
乙個辯證的思想是凡事都有兩面性,這個道理很簡單,大家一聽就說「對啊,這不是廢話麼」,可是面對具體問題的時候,有時候往往做不到這一點。
「什麼?我有沒有聽錯」,一直以來運維人員所追求的不就是穩定的服務麼?可是谷歌認為「在內部程式質量沒有達到一定標準,服務太穩定會產生盲目的依賴」
它舉了乙個例子,谷歌的chubby鎖服務,它是乙個基礎服務,做為基礎元件很多上層服務依賴於它,但是工程師們認為它還是有缺陷,有問題隱患,而在一段時間內它的表現還異常穩定,這樣就給呼叫方一種錯覺,這個服務很好,越來越多的服務依賴於它。
於是,谷歌幹了一件「不可思議」的事情,對chubby計畫內停止服務,捅破這種穩定的假象,讓呼叫方感受到「原來沒有那麼穩定」,這樣減少了對chubby的過度依賴。
這就是一種辯證的思想,我們一直以來都想追求絕對的穩定,沒有辯證的看穩定的系統有好處,也會有壞處,它會被外界過度依賴,大家用的很開心,可是這個系統如果還有隱患,造成了穩定的假象,一旦出了問題,可能就是大**。
工作中的瑣事是指那麼「無聊」,「無效率」,「流程化」的事情,很多人都很牴觸,認為它把你的時間碎片化了,使工作沒有效率。 sre有很大篇幅討論了瑣事(toil)的問題,它認為瑣事也有好處,比如可以適當的減壓,因為做起來不用過多的思考,可以做為創造性工作的一種調劑,從中也能發現需要優化的問題。
當然sre還是在儘量減少瑣事,它的壞處還是多於好處。
谷歌追求一種簡單,有效的解決方案,比如監控項不是越多越好,它列出監控的4個**指標
通過這四個指標,基本可涵蓋大部分問題,設定監控項的時候,我們往往生怕漏掉某個專案,設定非常詳細的監控策略,這些監控項不一定真的有意義,反而會帶來大量的干擾報警。
在**層面也遵循少即是多的原則,無用的**,大量冗餘的注釋都要刪除掉,提供簡單的api入口,我們常常為了以後的擴充套件性,預先加入很多冗餘功能**,谷歌反其道而行,鼓勵**的精簡。
每一行**都是負擔,所有**都必須有存在的目的,軟體工程少就是多!「什麼?我沒有聽錯?自動化會有壞處「,是的,谷歌認為運維自動化是有壞處的。
在運維領域,自動化運維是很多公司的目標,我們認為運維自動化,減少人力,規範操作流程,我們恨不得完全自動化早一天到來,怎麼還能有壞處?
自動化的壞處在於,對於乙個運維工程師來講,操作變成黑盒了,他不用明白乙個指令碼的原理,只要執行就好了,對於他來講是一件很開心的事,可是帶來的***是他對於線上的熟悉程度越來越少,他只會執行這個指令碼,那麼這個指令碼一旦出問題,因為缺少對線上環境的了解,無法很快進行修復。
體會到了自動化帶來的負面作用,谷歌希望使用自洽的方案解決問題,這樣才誕生了borg系統。
。書中的乙個例子是隨機的關閉乙個資料庫例項,看看會有什麼問題,然後真的出現了一些問題,影響了業務的訪問,通過這次演習他們發現了流程的問題,問題及時修復,避免了隱患。
所以谷歌的思想是:
你是希望系統在星期六凌晨2點,公司大部分同事還在參加黑森林中的團建時出現故障,還是希望和最可靠和最聰明的同事一起仔細監控著他們上週詳細評審過的測試時出現故障呢?sre不僅是一些運維的方**,它的辯證看問題的思想值得我們學習。
先寫這麼多,我得去搬磚了。
SRE Google運維解密 心得
在乙個執行的系統中,出現風險是不可能避免的,而運維工程師的存著便是控制並解決風險。書中提到構建百分百可靠的服務是不可取的,因為乙個服務面向使用者的不止是可靠,還有創新。當可靠性達到一定的數量級後,再花費大量的成本在可靠性上而忽略服務的創新,這種方式得不償失。書中還提到可用性為多少個 9 這個概念 上...
SRE Google運維解密 第一章
研發 dev 與運維 ops 分離導致的問題 直接成本 隨著產品及專案增多,相應人員線性增加。間接成本 研發與運維團隊背景各異,技術能力與工具使用習慣存在差距,工作目標不同 研發與運維團隊對產品可靠程度要求不同,具體執行某項操作的危險程度評估與技術防範措施不同。以上逐漸演變成目標與方向上的分歧及形成...
運維管理 IT運維與IT運維管理是有技術區別的
說到it運維技術,可能大家都會很熟悉,包括 網路運維,資料庫運維,linux運維,window運維,桌面運維,基礎架構運維,資訊系統運維,erp系統運維。技術是包含了多種多樣。那麼運維管理就是對上面這些技術進行管理嗎?是也不是。他們之間有著本質的區別。it運維技術,很多時候是指基於產品或者技術本身的...