作為谷廠出品的神書《SRE Google運(yùn)維解密》, 筆者早有耳聞并斷斷續(xù)續(xù)閱讀過部分內(nèi)容，最近終于靜心品閱了一遍(作為拖延癥患者, 寫完此文與閱讀完原書已間隔約半年)，里面的很多理念確實(shí)值得細(xì)細(xì)品味(部分章節(jié)沒有實(shí)際操作空間添坊，快讀略過)铅协。
5月底恰逢IT內(nèi)部調(diào)整組織架構(gòu)剧浸，其中一個(gè)開發(fā)運(yùn)營團(tuán)隊(duì)順手更名為了SRE，不求完美COPY谷歌文化冶伞，但求走出符合自己特色的站點(diǎn)可靠工程文化。試運(yùn)行一段時(shí)間后步氏，我想應(yīng)該會(huì)再回頭重溫一下這本書响禽，一定會(huì)有不同的理解。
個(gè)人理解SRE三個(gè)字母荚醒，S+R是一塊內(nèi)容芋类，E是另一塊。本文不會(huì)講太多關(guān)于E即工程化的內(nèi)容界阁，而重點(diǎn)說說“站點(diǎn)可靠”需要做什么侯繁。

先拋個(gè)很多人都說好但可能沒思考過為什么的問題：
Gmail到底好在哪里宾肺？

這個(gè)牛逼的郵件客戶端2004年愚人節(jié)橫空出世雾狈，
優(yōu)點(diǎn)很多：界面簡潔，容量超大玖媚，免費(fèi)安全精续，基于谷歌主業(yè)實(shí)現(xiàn)的優(yōu)秀搜索坝锰、標(biāo)簽分類等等功能，
最重要的是順帶激活了之前半死不活的Javascript語言重付，而今前端工程師如此火爆真的要感謝下谷歌當(dāng)時(shí)的翻牌顷级。
既然本文談的是Reliability, 那大家就可以考慮下,
如何能讓用戶量超過10億+, 免費(fèi)用戶15G容量上限，如此海量郵件數(shù)據(jù)和系統(tǒng)的高可靠确垫，
結(jié)合下文讀者自己去思考下應(yīng)該怎么做弓颈。

What is SRE

那么，最近大火的SRE到底是個(gè)什么崗位? 首先要說SRE概念的流行很大一部分原因是源自Google的最佳實(shí)踐删掀，才導(dǎo)致業(yè)界的各種跟風(fēng)翔冀。其實(shí)甚至SRE這個(gè)名詞的發(fā)明人Ben Treynor 也從來沒有給它公布過一個(gè)清晰的定義。
https://landing.google.com/sre/#sre
我先把Google官方 SRE 網(wǎng)頁翻譯部分節(jié)選讓大家有個(gè)直觀感覺披泪。

基本上發(fā)生在纤子，當(dāng)你要求一個(gè)軟件工程師設(shè)計(jì)一個(gè)運(yùn)維功能的時(shí)候。(牛人說話需要細(xì)細(xì)揣摩)
-- Ben Treynor Sloss, founder of Google SRE

當(dāng)你把運(yùn)維視作一個(gè)軟件問題的時(shí)候，SRE就是你所需要的控硼。我們的任務(wù)是保護(hù)泽论、提供支持和推進(jìn)藏在所有公有服務(wù)背后的軟件和系統(tǒng)，永遠(yuǎn)警惕關(guān)注它們的可用性卡乾、延遲翼悴、性能和容量。
我們是一種在業(yè)界任何他處還沒發(fā)現(xiàn)的復(fù)合型工種幔妨。類似于傳統(tǒng)的運(yùn)維團(tuán)隊(duì)鹦赎，我們需要保證重要的、核心盈利的系統(tǒng)運(yùn)行正常(up and running) 误堡，不管面對龍卷風(fēng)古话、帶寬中斷或者配置錯(cuò)誤。又不同于傳統(tǒng)運(yùn)維團(tuán)隊(duì)埂伦，我們把軟件所為第一生產(chǎn)力工具煞额，以此管理、維護(hù)和關(guān)注我們的應(yīng)用系統(tǒng)沾谜；為了達(dá)到這個(gè)目標(biāo)膊毁，我們必須擁有源碼級別的訪問權(quán)限和道德權(quán)威(moral authority), 方可修復(fù)、擴(kuò)展和分布式化代碼使其不僅僅可工作基跑，甚至更加健壯地面對互聯(lián)網(wǎng)的各種異常行為婚温，然后可以開發(fā)我們自己全球規(guī)模(planet-scale)的平臺。作為SRE, 從細(xì)粒度的磁盤驅(qū)動(dòng)器IO調(diào)度媳否，到跨大洲級別的多系統(tǒng)&海量用戶服務(wù)能力的宏觀規(guī)劃栅螟，我們可以無縫切換。

從官方定義可以提煉出幾個(gè)基本關(guān)鍵字：關(guān)注高可用篱竭，高可靠力图，性能，必備系統(tǒng)和軟件開發(fā)能力掺逼，全棧能力和優(yōu)秀的學(xué)習(xí)能力吃媒。
寫到這，突然感覺這些也是架構(gòu)師的必備技能呢...
如同敏捷中經(jīng)常提到的擁抱變化吕喘，SRE其中一個(gè)指導(dǎo)思想叫“擁抱風(fēng)險(xiǎn)”赘那，這樣才能驅(qū)動(dòng)SRE不斷的創(chuàng)新和快速試錯(cuò)，因?yàn)轱L(fēng)險(xiǎn)就像BUG永遠(yuǎn)消滅不了氯质，基于一個(gè)可信的“風(fēng)險(xiǎn)容忍度”指標(biāo)募舟，SRE可以通過管理風(fēng)險(xiǎn)來提高系統(tǒng)可靠程度。

很多人可能要問了闻察，SRE跟DevOps到底有什么區(qū)別么拱礁？別是 Google 自己炒的一個(gè)概念吧琢锋？其實(shí)兩者還是有區(qū)別的，不然筆者也不會(huì)真的架設(shè)了SRE和DevOps這兩個(gè)團(tuán)隊(duì)了觅彰。

有篇英文的對比文章, 部分觀點(diǎn)筆者并不贊同吩蔑，讀者有興趣可以去閱讀一下（https://devops.com/sre-vs-devops-false-distinction/）

個(gè)人總結(jié)的區(qū)別如下：
DevOps 更多是一種理念钮热，用于幫助IT組織架構(gòu)以敏捷的角度進(jìn)行調(diào)整和演進(jìn)的方法論填抬，在開發(fā)和運(yùn)維團(tuán)隊(duì)中架設(shè)起一個(gè)健康的合作橋梁。字面其實(shí)就可以看出來隧期，很多時(shí)候飒责，Dev想要保證盡快的發(fā)布和快速迭代，Ops只想確保線上的穩(wěn)定仆潮，否則出問題電話爆掉的是Ops宏蛉，所以O(shè)ps會(huì)盡可能的要求放慢節(jié)奏...這也算是DevOps的由來吧。DevOps主要關(guān)注ITIL性置、ITSM拾并、Agile、持續(xù)交付CD等方面鹏浅。上方英文作者提到DevOps發(fā)現(xiàn)生產(chǎn)故障只是拋出而不是修復(fù)嗅义，且偏保守，這個(gè)筆者完全不贊同隐砸，DevOps必須具備處理生產(chǎn)故障的能力之碗。目前筆者的DevOps團(tuán)隊(duì)偏向于基礎(chǔ)系統(tǒng)(虛擬化、網(wǎng)絡(luò)季希、數(shù)據(jù)庫)褪那、持續(xù)交付工具等的自動(dòng)化開發(fā)運(yùn)維。
SRE 的定位相對更加的具體式塌，就是
a) 面向生產(chǎn)環(huán)境進(jìn)行可靠性需求的自我發(fā)現(xiàn)
b) 應(yīng)用自動(dòng)化運(yùn)維的軟件工程實(shí)現(xiàn)
c) 一切影響可靠性的行為通報(bào)和推進(jìn)修復(fù)
d) 架構(gòu)師視野博敬，參與新項(xiàng)目的線上方案可靠性評估
目前筆者的SRE團(tuán)隊(duì)更偏向于線上應(yīng)用的全鏈路監(jiān)控、技術(shù)/業(yè)務(wù)數(shù)據(jù)收集峰尝、運(yùn)維軟件研發(fā)偏窝、自動(dòng)化排障修復(fù)和架構(gòu)設(shè)計(jì)方案評審等。

【吐槽】最近 DevOps 又開始跟敏捷境析、精益綁定輸出了很多新概念囚枪，且有愈演愈烈之勢。新瓶裝舊酒筆者并不反對劳淆，但是在你把邊界界定清楚链沼，職責(zé)劃分清楚之前，能不能別在“糊涂”外面再包裝一層“忽悠”沛鸵？看到此類文章括勺，筆者都免不了吐槽一番...

如何理解站點(diǎn)可靠

先澄清下缆八，“站點(diǎn)可靠”絕對不是問百度搜出一堆網(wǎng)站，不知道哪個(gè)是可靠的疾捍，導(dǎo)致都不敢點(diǎn)進(jìn)去奈辰。這里的“可靠”指的是系統(tǒng)在特定的時(shí)間跨度內(nèi)執(zhí)行系統(tǒng)功能返回期望結(jié)果的可能性，也就是說“可靠”是個(gè)可度量值乱豆，一般通過下面兩個(gè)基本的公式來計(jì)算：

失敗平均時(shí)間 = 可正確服務(wù)的總時(shí)長 / 失敗次數(shù)
失敗率 = 失敗次數(shù) / 可正確服務(wù)的總時(shí)長*

通過公式很容易得知要提高可靠性奖恰，只要盡可能的減少失敗次數(shù)，縮短失敗時(shí)長宛裕。但這兩點(diǎn)說起來簡單瑟啃，做起來卻只能通過不斷實(shí)踐和摸索來實(shí)現(xiàn)了。
那具體到底應(yīng)該如何做呢揩尸？開發(fā)工程師把應(yīng)用的穩(wěn)定性蛹屿、并發(fā)和性能優(yōu)化到極致是不是就是高可靠了呢？這當(dāng)然可以作為提高可靠性的手段之一岩榆，但線上環(huán)境千差萬別错负，基于某些特定條件的本地優(yōu)化很多時(shí)候只可能淪為紙上談兵。下文將羅列一些常見的提高可靠性的一些手段供大家參考(也是目前米么團(tuán)隊(duì)的一些經(jīng)驗(yàn)之談)勇边。

小貼士：Reliability vs Availability
很多人們會(huì)將可靠性和可用性混淆犹撒，其實(shí)這是兩個(gè)完全不同的概念，上文解釋過可靠性和計(jì)算公式粥诫。而可用性更多是一個(gè)衡量可用時(shí)間的運(yùn)維參數(shù)油航，計(jì)算公式是：
=正常運(yùn)行時(shí)長 / 總時(shí)長(正常運(yùn)行+故障停機(jī))

分布式監(jiān)控

有人要說了我們要提高系統(tǒng)可靠性，最優(yōu)的方法肯定是“事前”就想到一些隱患并做好預(yù)防或補(bǔ)救措施怀浆，而不是通過監(jiān)控這種明顯“事后”錯(cuò)誤去實(shí)現(xiàn)谊囚。首先要說這種理解是片面的，監(jiān)控也可以做到預(yù)警执赡，做到“事前”（事故發(fā)生前）镰踏，其次并不是所有故障都可以提前就想透的，最后監(jiān)控確實(shí)是在軟件系統(tǒng)不夠成熟的情況下沙合，相對容易實(shí)施和實(shí)現(xiàn)的一種提高可靠性的手段奠伪。
只要是搞互聯(lián)網(wǎng)應(yīng)用，分布式首懈、微服務(wù)這些概念就鐵定繞不開绊率，而與它們綁定的監(jiān)控也就更具挑戰(zhàn)性。為什么要監(jiān)控究履？監(jiān)控什么滤否？怎么監(jiān)控？監(jiān)控目標(biāo)是什么最仑？

- 監(jiān)控什么藐俺？

• 基礎(chǔ)資源(如虛機(jī)/帶寬/磁盤/DB/Redis等)的健康檢查

• 應(yīng)用系統(tǒng)的健康檢查炊甲，不能僅僅是靜態(tài)頁面，最好有應(yīng)用正常啟動(dòng)后才能訪問的ping接口

• 業(yè)務(wù)指標(biāo)項(xiàng)統(tǒng)計(jì)

• 微服務(wù)調(diào)用鏈上的響應(yīng)時(shí)間欲芹，異常統(tǒng)計(jì)等

• 安全相關(guān)(如惡意頻繁請求IP)的數(shù)據(jù)統(tǒng)計(jì)

• 業(yè)務(wù)/技術(shù)指標(biāo)的長期趨勢

- 怎么監(jiān)控卿啡？

這里說的“怎么”監(jiān)控不是問怎么實(shí)現(xiàn)，具體方案本來就可能千人千面菱父。這里問的是監(jiān)控的指導(dǎo)思想是什么颈娜，怎么去遵照才算比較好的監(jiān)控。
比如健康檢查類的接口或者日志收集的Agent滞伟，務(wù)必要評估清楚這些額外進(jìn)程會(huì)對核心的應(yīng)用系統(tǒng)正常運(yùn)轉(zhuǎn)的影響范圍和影響程度揭鳞；

• 所有需要通過埋點(diǎn)實(shí)現(xiàn)監(jiān)控的基礎(chǔ)組件要求能異步就堅(jiān)決不能同步，對埋點(diǎn)應(yīng)用的性能影響降低到最邪鹉巍；

• 對實(shí)時(shí)性要求特別高的指標(biāo)項(xiàng)(比如接口響應(yīng)時(shí)間称开，某些核心業(yè)務(wù)指標(biāo)等), 能夠做到準(zhǔn)實(shí)時(shí)到實(shí)時(shí)的統(tǒng)計(jì)告警亩钟；對監(jiān)控服務(wù)端的數(shù)據(jù)處理和并發(fā)能力提出了特別嚴(yán)苛的要求；

• 監(jiān)控端必須有豐富的UI展示和報(bào)表輸出鳖轰，因?yàn)楸O(jiān)控還有一項(xiàng)重要目的就是可以用于線上排障(What is down & Why it's down)清酥，若監(jiān)控信息都清晰的渲染在頁面上，不管是人工排障還是自動(dòng)化排障(提供API)蕴侣，都是有絕佳益處的焰轻；

• 針對長期/一個(gè)時(shí)間窗口內(nèi)的數(shù)據(jù)能夠預(yù)見大部分指標(biāo)項(xiàng)的波動(dòng)指數(shù)和趨勢，并據(jù)此不斷調(diào)整預(yù)警的區(qū)間參數(shù)昆雀，這就可以做到我們說的“事前”發(fā)現(xiàn)可能故障辱志。

• 如何監(jiān)控我們的監(jiān)控系統(tǒng)保證高可用呢？筆者也不能說目前自己在用的是萬能方案狞膘，只能說相對靠譜揩懒。可以引入另一個(gè)監(jiān)控系統(tǒng)來做個(gè)環(huán)形監(jiān)控挽封，比如CAT做應(yīng)用監(jiān)控已球，Zabbix做基礎(chǔ)資源監(jiān)控，它倆完全可以做一個(gè)互相之間的監(jiān)控辅愿，兩個(gè)都掛的可能性應(yīng)該小很多了吧智亮？

• 監(jiān)控后的告警數(shù)量一定要保證規(guī)模，過多的告警等于沒有告警点待，應(yīng)該做到只要是告警就應(yīng)該有清晰的處理和修復(fù)機(jī)制去規(guī)范阔蛉。

- 監(jiān)控目標(biāo)？

報(bào)告老師亦鳞，監(jiān)控的目標(biāo)是“告警”馍忽。
答錯(cuò)棒坏，坐下。

監(jiān)控的結(jié)果展現(xiàn)形式之一是“告警”遭笋，但絕不是監(jiān)控的目標(biāo)坝冕。目標(biāo)當(dāng)然是保證站點(diǎn)高可靠咯！所以我們監(jiān)控了那么多的指標(biāo)瓦呼，通過告警這個(gè)手段通知到相關(guān)干系人喂窟；其他的目標(biāo)上一章節(jié)也穿插的提到過的“排障定位”，“預(yù)警”央串，“統(tǒng)計(jì)報(bào)表”磨澡。而真正要提高可靠性，關(guān)鍵是拿到監(jiān)控?cái)?shù)據(jù)后的工作：

• 故障重復(fù)出現(xiàn)质和，應(yīng)該如何推動(dòng)系統(tǒng)負(fù)責(zé)人去盡早修復(fù)稳摄？而不是任由告警發(fā)霉。

• 預(yù)警的基線區(qū)間是基于什么計(jì)算出來的饲宿？隨著數(shù)據(jù)量的累計(jì)厦酬，如何不斷更新這些預(yù)警值？

• 監(jiān)控到的一些常見異常如何正反饋到各團(tuán)隊(duì)瘫想，更新他們的checklist仗阅，確保不重復(fù)犯錯(cuò)；

• 第一次需要人工介入排障和處理的故障国夜，第二次以及日后類似故障如何通過技術(shù)手段做到自動(dòng)識別和自動(dòng)修復(fù)减噪？

智能告警

我們已經(jīng)收集了很多監(jiān)控指標(biāo)數(shù)據(jù)了，告警是水到渠成的事车吹。就告警本身而言是沒有難度筹裕，但是如何告，何時(shí)告礼搁，告的內(nèi)容詳細(xì)到什么程度饶碘。這些和上面的監(jiān)控描述的基本一致。這里重點(diǎn)提下“智能”的告警馒吴。

- 告警規(guī)則的設(shè)計(jì)

一條通用的告警規(guī)則可以抽象為這么幾個(gè)要素：

EffectTime - 規(guī)則生效的時(shí)間窗口
Interval - 數(shù)據(jù)統(tǒng)計(jì)的時(shí)間窗口
Variables - 規(guī)則對應(yīng)的變量
Expression - 邏輯表達(dá)式(與或非)
Level - 告警級別

舉個(gè)例子：常規(guī)工作時(shí)間(EffectTime=9:00 - 18:00) 1分鐘(Interval=1min)內(nèi)的異常數(shù)量(Variable=ExpCnt)不能超過5個(gè)(Expression=ExpCnt < 5)扎运，超過就嚴(yán)重告警(Level=Critical)
當(dāng)然示例基本是最簡單的一種告警規(guī)則了，要做好較好的規(guī)則解析饮戳，就需要完善的規(guī)則解析器豪治，甚至可以做出一個(gè)UI友好的界面，供運(yùn)維人員以所見即所得的方式拖曳生成一個(gè)告警規(guī)則扯罐，并自動(dòng)上線负拟，這個(gè)終極目標(biāo)也是我們目前努力的方向。

很多時(shí)候的規(guī)則并不是基于特別具體的變量歹河，而是基于各種時(shí)間窗口的對比掩浙，比如今天9點(diǎn)的訂單數(shù)花吟，昨天9點(diǎn)的訂單數(shù)和前一周9點(diǎn)的訂單平均數(shù)進(jìn)行比較，才能做出一個(gè)告警判斷厨姚。當(dāng)然這些也可以抽象為一個(gè)一個(gè)的變量衅澈，但是對于變量的設(shè)計(jì)需要更加的細(xì)致。

其實(shí)Google Borgmon對于告警還有一個(gè)時(shí)間窗口的概念谬墙，叫做“最小持續(xù)時(shí)間值”(筆者命名為滑動(dòng)時(shí)間窗口 SlidingTimeWindow, 下文還會(huì)提到)今布，用作當(dāng)警報(bào)持續(xù)時(shí)間超過這個(gè)值的時(shí)候才會(huì)發(fā)送警報(bào)，這樣不會(huì)觸發(fā)太多的報(bào)警拭抬。而實(shí)現(xiàn)相同功能的這個(gè)值在點(diǎn)評CAT中配置名叫 SuspendTime, 完全是從另一個(gè)角度考慮的部默，也就是當(dāng)前報(bào)警觸發(fā)后，CAT就會(huì)暫停/掛起一段時(shí)間后造虎，再繼續(xù)匯總這個(gè)時(shí)間窗口內(nèi)的告警信息進(jìn)行報(bào)警傅蹂。所以說，你看累奈，同一個(gè)事情理解和設(shè)計(jì)角度不同贬派，卻實(shí)現(xiàn)了同樣的功能，怎么理解都很順暢澎媒，這就是架構(gòu)設(shè)計(jì)的美妙之處。

- 批量告警的篩選

一般的監(jiān)控平臺(比如CAT波桩，PinPoint) 后面都會(huì)再掛一個(gè)告警平臺戒努，用來做告警渠道的對接。這個(gè)告警平臺絕對不是簡單的報(bào)文拼裝后的報(bào)警镐躲，它的職能邊界還包括:
在 SlidingTimeWindow 內(nèi)進(jìn)行各類告警的優(yōu)先級排序储玫，如果量比較大，可以抑制某些低級別的告警萤皂，保證嚴(yán)重告警不會(huì)被淹沒

在 SlidingTimeWindow 內(nèi)的大量告警進(jìn)行合并和排重撒穷，節(jié)約網(wǎng)絡(luò)帶寬，更加可以讓報(bào)警接收人迅速關(guān)注到明確的信息裆熙；

上面兩條篩選都必須基于警告的一些屬性和標(biāo)簽進(jìn)行過濾端礼，那么警告的屬性需要盡可能的攜帶一些必要參數(shù)，比如應(yīng)用名入录，業(yè)務(wù)功能模塊等等蛤奥。

- 告警信息如何描述

這個(gè)筆者就不舉例來說了，無非其一是讓報(bào)警接收人可以一眼通過標(biāo)題或簡述大約看懂這是一個(gè)什么告警和什么嚴(yán)重級別的告警僚稿，其二告警的詳細(xì)描述盡量攜帶讓人可以盡快定位或找到排障線索信息凡桥，并添加一些外鏈可以讓人一鍵跳轉(zhuǎn)到具體的數(shù)據(jù)展示頁面，這樣我覺得就差不多了蚀同。

自動(dòng)排障和修復(fù)

自動(dòng)排障目前筆者團(tuán)隊(duì)已經(jīng)可以將日志缅刽、數(shù)據(jù)庫啊掏、監(jiān)控?cái)?shù)據(jù)等各類數(shù)據(jù)源融合起來，做出一個(gè)匯總的報(bào)告衰猛，并給出一些初步的故障可能根源和建議修復(fù)方案等迟蜜，人工只要介入一下即可。
而自動(dòng)修復(fù)暫時(shí)限定在某些業(yè)務(wù)場景腕侄，比如通過用戶的手機(jī)號在數(shù)倉內(nèi)找到所有的動(dòng)作軌跡小泉，來確定該用戶的問題是卡在哪一步，然后調(diào)用驗(yàn)證過的數(shù)據(jù)修復(fù)功能模塊自動(dòng)修復(fù)數(shù)據(jù)冕杠，進(jìn)而讓用戶繼續(xù)進(jìn)行下去微姊。
這個(gè)話題太大，而且需要大量故障知識庫的總結(jié)才能梳理出根源和方案分预，否則自動(dòng)修復(fù)再引入一些BUG兢交，那就真的尷尬了。本文不再展開笼痹。

發(fā)布協(xié)調(diào)師

Google內(nèi)部是有設(shè)置發(fā)布協(xié)調(diào)師這個(gè)崗位的（LCE, Launch Coordination Engineering）配喳，實(shí)際上米么IT雖然沒有明確的架設(shè)這個(gè)崗位，但由PMO的項(xiàng)目經(jīng)理們兼任了這項(xiàng)職能凳干。比如有個(gè)大版本的上線涉及到10多個(gè)微服務(wù)晴裹，服務(wù)之間的依賴關(guān)系，上線順序都特別的關(guān)鍵救赐。每逢這種時(shí)候都會(huì)安排一個(gè)大版本上線規(guī)劃會(huì)涧团，集合所有服務(wù)的負(fù)責(zé)人，將變更部分的依賴關(guān)系梳理清楚经磅，最終生成一份上線計(jì)劃提交給運(yùn)維團(tuán)隊(duì)泌绣。

特別說明：這里說的是“變更部分”的依賴關(guān)系，而不是微服務(wù)之間固有的依賴關(guān)系预厌。微服務(wù)之間固有的依賴關(guān)系我們確實(shí)可以通過調(diào)用鏈分析來做到阿迈，而每次上線對于變更部分的功能依賴會(huì)遠(yuǎn)少于固有關(guān)系依賴，這部分如何能夠做到盡量的智能評估轧叽，也是我們在攻關(guān)的一個(gè)環(huán)節(jié)苗沧。

大家不要小看這個(gè)協(xié)調(diào)的事情，并不是所有公司都做的好敏捷犹芹，并做到保證各服務(wù)接口可以兼容上線的崎页，很多時(shí)候發(fā)生一些不兼容的上線依賴，這種協(xié)調(diào)工作是非常有必要且重要的腰埂。其實(shí)Google賦予了LCE更重要的職能飒焦，因?yàn)長CE必須對各種系統(tǒng)之間的依賴和可能的隱患相比單個(gè)系統(tǒng)負(fù)責(zé)人有更清晰的認(rèn)識，意味著LCE可以從業(yè)務(wù)架構(gòu)師的角色中挑選人擔(dān)任，甚至LCE應(yīng)該參與各系統(tǒng)的架構(gòu)設(shè)計(jì)評審牺荠，這種專業(yè)意見由了解大部分系統(tǒng)架構(gòu)細(xì)節(jié)的人來給出翁巍，更加的有說服力。

數(shù)據(jù)完整性

- 備份還是恢復(fù)

這其實(shí)是個(gè)老生常談的問題休雌，就算有些老司機(jī)也會(huì)在備份這個(gè)概念上翻船灶壶。大家現(xiàn)在就去看一下自己的系統(tǒng)數(shù)據(jù)是否做好了備份，假設(shè)你確認(rèn)備份好了杈曲，是否就可以松一口氣了呢驰凛？實(shí)際上備份只是第一步，能從備份能恢復(fù)出數(shù)據(jù)來才是最終目的担扑。而不少工程師只是做到了備份恰响，等真的要用到這些數(shù)據(jù)做恢復(fù)的時(shí)候，發(fā)現(xiàn)有損壞或者各種抓瞎涌献，那備份的意義在哪里呢胚宦？

- 保障完整性的手段

Google SRE給出了24中數(shù)據(jù)完整性的事故組合, 如下圖，保障手段分三層：第一層是軟刪除燕垃，就是我們在數(shù)據(jù)庫表設(shè)計(jì)中常見的刪除字段枢劝，這樣可以保護(hù)數(shù)據(jù)不能被意外真的被物理刪除掉；第二層是備份和對應(yīng)的恢復(fù)機(jī)制卜壕；第三層是復(fù)制機(jī)制您旁，也就是冗余的概念，將備份再來一次冗余轴捎，提高安全性被冒。

知識庫和事后總結(jié)

其實(shí)知識庫和事后總結(jié)是所有工程師都應(yīng)該具備的基本素養(yǎng)，但是這點(diǎn)對于SRE的意義更加突出一些轮蜕，因?yàn)楹芏喾桨甘侵荒苁峭ㄟ^大量的故障記錄、歸類和總結(jié)中得出蝗锥。目前筆者團(tuán)隊(duì)記錄了大量的故障信息和總結(jié)跃洛，但是問題就出在故障的記錄和總結(jié)還沒有形成一個(gè)統(tǒng)一規(guī)范，導(dǎo)致進(jìn)行故障合并歸類的時(shí)候终议，出現(xiàn)極大的困難汇竭，當(dāng)然這個(gè)是一個(gè)逐步演進(jìn)的過程，是無法直接跨過去的穴张。如果你已經(jīng)具備大量的運(yùn)維經(jīng)驗(yàn)细燎，這些抽象提前做好也不是很難的問題。

結(jié) 語

本文借鑒了Google運(yùn)維解密一書中的部分觀點(diǎn)皂甘，并結(jié)合自己團(tuán)隊(duì)的一些實(shí)踐和思考玻驻，希望把站點(diǎn)可靠文化更加堅(jiān)實(shí)的做下去。現(xiàn)階段筆者也是跟團(tuán)隊(duì)一起在摸索，更多的新思路還希望大家一起加入探討璧瞬。