系統(tǒng)正常，只是該系統(tǒng)無數(shù)異常情況下的一種特例
          --- 摘錄自《SRE Google運維解密》

最近Google SRE很火，我們內(nèi)部給每個人都配了一本《SRE Google運維解密》，希望大家能熟讀，從中能取些經(jīng)。

SRE的的幾個核心方法論：
1）確保運維人員長期關(guān)注研發(fā)工作；
2）在保障服務(wù)SLO的前提下最大化迭代速度；
3）重視監(jiān)控系統(tǒng)；
4）應(yīng)急事件處理，重視運維手冊維護以及on-call機制；
5）變更管理自動化；
6）合理對需求進行預(yù)測和對容量進行相應(yīng)規(guī)劃。
看完第一章 SRE方法論后就知道google SRE并不是那么容易學(xué)習(xí)了。

SRE是另一個很火的概念devops在google的最佳實踐，結(jié)合google的特點進行了擴展。在SRE的幾個核心方法論中第一條最重要，是做好其他幾個方法論的前提和驅(qū)動力。一般運維(ops)和開發(fā)部門(dev)是獨立的兩個部門，這兩個部門有截然不同的目標述求，ops希望穩(wěn)定壓倒一切，系統(tǒng)上線后一百年不變才好；dev部門希望盡快完成業(yè)務(wù)部門提出的需求，巴不得隨時隨地變更上線。這個矛盾導(dǎo)致兩個部門“不對付”，是IT內(nèi)部不和諧聲音的來源，處理不當會產(chǎn)生嚴重的辦公室政治，對工作和團隊建設(shè)都嚴重不利。（這種情況可以參考運維界難得的一本小說《鳳凰項目-一個IT運維的傳奇故事》中關(guān)于運維部門和開發(fā)部門斗智斗勇、互黑的故事，和現(xiàn)實中碰到的真是一樣一樣的，說明ops和dev的矛盾和國別無關(guān)，人種無關(guān)）。

Devops希望的是dev和ops盡量的融合，一般是兩個部門盡量的融合，譬如，歸屬一個團隊、由同一人領(lǐng)導(dǎo)、集中辦公等等。google直接一步到位---dev和ops是一個人（合體了），并且SRE 至少50%精力用于花在真實的開發(fā)工作上。招聘時以開發(fā)人員的要求來招聘SRE，SRE的招聘要求原則上比普通業(yè)務(wù)開發(fā)人員還要高，既懂開發(fā)又要懂運維。這樣的好處是顯而易見的，一個人身上哪個地方疼只有自己最清楚，運維過程中的痛點開發(fā)人員是不知道的，運維人員提出來開發(fā)人員也不一定能切身體會，做一個完全好用的運維功能出來。

現(xiàn)在的開發(fā)更多的是業(yè)務(wù)開發(fā)，簡單點說是用一堆if/else邏輯驅(qū)動數(shù)據(jù)將業(yè)務(wù)邏輯實現(xiàn)出來，很多業(yè)務(wù)開發(fā)人員對系統(tǒng)的健壯性、可維護性根本不了解，也沒能力了解，開發(fā)過程中也不會考慮到（業(yè)務(wù)功能都做不完，哪還有空去考慮健壯性啊~）。這就需要運維開發(fā)人員補充進來，從系統(tǒng)的冗余、應(yīng)急、告警、監(jiān)控等多維度去給業(yè)務(wù)系統(tǒng)打補丁，提高系統(tǒng)的穩(wěn)定性。這部分工作現(xiàn)在很多場合下是欠缺的，因為不能直接產(chǎn)生價值也導(dǎo)致管理層重視不夠。

當運維人員有開發(fā)能力（如同一個木匠有了趁手的斧頭鋸子），并且能有一半以上的精力投入到運維功能的開發(fā)中，把業(yè)務(wù)系統(tǒng)再穿上一件運維功能（健壯性、可用性、可維護性方面）的鎧甲，那么不僅僅會提升系統(tǒng)的可用性，而且能夠更好的配合業(yè)務(wù)開發(fā)人員實行持續(xù)集成(CI)，持續(xù)部署（CD）這些高階玩法，否則系統(tǒng)本身已是弱不禁風(fēng)，怎么經(jīng)得起花樣翻新的折騰！

所以，想學(xué)習(xí)SRE，首先看看能否做到SRE核心方法論中的第一條，如果運維人員還是一些僅僅只會看看告警、查查SQL，那么很難學(xué)到SRE精髓。當然即使做不到，其他方面也可以參照學(xué)習(xí)，這本書上還是有很多其他值得借鑒的部分，譬如方法論的第二點，制定好SLO，根據(jù)SLO決定上線頻度（有理有據(jù)和開發(fā)爭取不給上線:)）；方法論第四點建立告警監(jiān)控的輪值制度等等。