企業(yè)運維保障體系最佳實踐

1、 企業(yè)運維保障體系最佳實踐前言阿里巴巴全球運行指揮中心，GOC (Global Operations Center)保障阿里經(jīng)濟體的業(yè)務(wù)穩(wěn)定運行的核心團隊。我們負責了整個阿里巴巴全局生產(chǎn)系統(tǒng)的穩(wěn)定性。就像業(yè)界經(jīng)常提到谷歌的SRE，我們相當于阿里巴巴的SRE。今天我的分享分為四個部分：1、穩(wěn)定性現(xiàn)狀及挑戰(zhàn)2、運維保障體系介紹3、運行無間最佳實踐4、未來的發(fā)展及方向一、穩(wěn)定性現(xiàn)狀及挑戰(zhàn)提到阿里巴巴，不得不說剛剛過去的雙十一。在剛剛過去的雙十一，每秒訂單創(chuàng)建的峰值達到32.5萬筆，每秒支付峰值達到25.6萬筆。相比2016年的17.5萬筆和12.5萬筆提升近80%。相比去年的緊張狀態(tài)，我們今年收到的

2、普遍反饋是比較平穩(wěn)。同時，做為阿里巴巴雙十一備戰(zhàn)的一員，雙十一當天切身感受到，喝著茶就把今年的雙十一給過了的感覺。并且業(yè)務(wù)上也再創(chuàng)新高，達到了1682億，這是一個非常不容易的技術(shù)新高度。如上圖所示，阿里巴巴業(yè)務(wù)迅速擴展，對于穩(wěn)定性保障來說非常有挑戰(zhàn)性。從基礎(chǔ)架構(gòu)層面來看：我們需要保障IDC，網(wǎng)絡(luò)基礎(chǔ)設(shè)施，安全，阿里云、阿里通信和釘釘；從業(yè)務(wù)層面來看，我們需要保障天貓、淘寶、手淘、螞蟻金服、AE、飛豬、阿里媽媽、搜索；以及近期迅猛發(fā)展的新零售、大文娛業(yè)務(wù)，如盒馬鮮生，村淘、云零售、優(yōu)酷、阿里影業(yè)、阿里健康等。今年9月28日，新零售盒馬鮮生做了五城十店同開活動，一般來說開一家超市成本很高，而互聯(lián)網(wǎng)

3、的速度卻是，可以一下子開起來，當然盒馬鮮生不是就滿足于一天可以開10個店的速度，未來是百家店、千家的店的速度。10月份，阿里云馬來西亞區(qū)開服。用不到1年時間，完成數(shù)據(jù)中心的新建。并且馬來西亞數(shù)據(jù)中心，也剛好是馬老師E-WTP（Electronic World Trade Platform，電子世界貿(mào)易平臺）真實的落地，速度確實非?？臁?1月份，在雙十一活動上，有超過100萬臺天貓精靈智能音箱的售賣。人工智能業(yè)務(wù)的發(fā)展尚是如此迅猛，而我們也緊跟著業(yè)務(wù)在思考，人工智能算法的穩(wěn)定性應(yīng)該如何去衡量。從各個維度看，阿里當前的業(yè)務(wù)面很廣、層次很深，因此很難做統(tǒng)一的一致的運維保障方案。所以，問題就在于，在這

4、樣的情況下作為一個目標是要對接整個阿里經(jīng)濟體線上業(yè)務(wù)穩(wěn)定性的一個團隊來說，GOC應(yīng)該如何去做。昨天，魔泊云的副總裁Christ Chen在分享中提到，他在2001年經(jīng)歷了一個非常大的故障，原因是一個運維誤操作把一個DB搞掛了，而整個Cisco線上會議的服務(wù)也就掛了。當時間滑到16年后，2017年2月28日B廠也因為30分鐘無法通過WAP訪問的故障導(dǎo)致被約談；此外，AWS因一位工程師誤操作，導(dǎo)致整個美東一大片區(qū)域AWS不可訪問。隨著時間，業(yè)務(wù)復(fù)雜度一直在增加，但導(dǎo)致線上故障發(fā)生的原因往往沒怎么變。因此，需要我們在萬變之中找不變，找到運維保障的鑰匙。隨著越來越多的新技術(shù)，新業(yè)務(wù)不斷涌現(xiàn)，我想這會是

5、一個新的階段，這個階段是一個非常不容易達到的技術(shù)廣度，而在該技術(shù)廣度上，無論是人工智能算法、還是大規(guī)模基礎(chǔ)設(shè)施，穩(wěn)定性運維保障都已經(jīng)成為一個很難的課題。當雙11辦到了第9年的今天，天貓雙十一已經(jīng)成為了互聯(lián)網(wǎng)的一個超級工程，“超級工程”是一個新的概念。除了大家熟悉的下單、支付這樣的一些場景外，這個超級工程里面還包含了很多新技術(shù)，包括客服、搜索，推薦，廣告，庫存，物流等等。而這些是所有阿里工程師每天不斷創(chuàng)新突破的力量，這是非常不容易的技術(shù)速度。這里面為大家介紹2個點，正好是我們團隊做的。一個是Changefree系統(tǒng)，基于機器智能的changefree保證線上變更有跡可循。它通過對變更數(shù)據(jù)進行全文

6、檢索加自定義規(guī)則引擎，輔以機器學(xué)習的手段來自動統(tǒng)計分類，快速定位故障。這些是官方的表述，但是同比故障的恢復(fù)時間我們能夠檢驗得出來，可以提升65%，這是個非常難得的事情。另一個是時間序列的異常檢測算法，基于智能基線的時間序列異常檢測算法具有自動學(xué)習、自動化監(jiān)控業(yè)務(wù)和預(yù)警的能力，有了它，業(yè)務(wù)指標監(jiān)控的準確率從傳統(tǒng)監(jiān)控策略的40%左右提升到80%。這2個光榮的上了我們新技術(shù)的榜，卻是是很難的點。講完了現(xiàn)狀和挑戰(zhàn)之后，我想帶大家一起回過頭思考一下。當我們站在這樣的一個技術(shù)高度、廣度以及速度的時候，線上業(yè)務(wù)的穩(wěn)定性、連續(xù)性以及運維保障方案有沒有不同。當出現(xiàn)故障的時候，或者頻繁出現(xiàn)故障的時候，如何保障用戶

7、的使用不受影響或者受影響的程度可以降到最低。二、運維保障體系介紹我們阿里巴巴的運維保障體系也不是憑空起高樓，也是慢慢迭代出來的，主要學(xué)習這兩個體系：一個是ITIL ，一個是業(yè)務(wù)連續(xù)性管理，也就是BCM，ISO 22301。我們的運維保障體系，也是脫胎于此。ITIL側(cè)重于流程和服務(wù)，能很好地建立服務(wù)目錄，但在深度使用過程發(fā)現(xiàn)略冗長，不太適合互聯(lián)網(wǎng)的精益迭代。GOC最初剛成立的時候，主要是用ITIL，但是隨著業(yè)務(wù)穩(wěn)定性訴求的不斷的更新以及優(yōu)化和不斷增長的時候，需要自建的訴求就自然而然來了?？偟膩碚f，我們希望流程可以再輕便、高效一點，服務(wù)之間不再是孤島，希望服務(wù)之間是為了同一個目標，比如：故障快速恢

8、復(fù)。通過這樣一個簡單的目標，我們能夠去把服務(wù)/產(chǎn)品打通，打透。業(yè)務(wù)連續(xù)性管理，提到業(yè)務(wù)連續(xù)性管理，往往會同災(zāi)難恢復(fù)一起講，英文稱為BC&DR（Business Continuity and Disaster Recovery）。一般提到BCM，經(jīng)常會舉2013年東南亞海嘯的案例，海嘯發(fā)生后，某某銀行受到了嚴重影響，從結(jié)果看，一周內(nèi)能否恢復(fù)營業(yè)，若恢復(fù)，說明基本不受影響；但如果1個月才能恢復(fù)營業(yè)，說明他很有可能需要長達3-5個月的時間來停業(yè)整頓；如果2個月還不能恢復(fù)，那這個銀行距離倒閉的時間就不遠了。傳統(tǒng)行業(yè)對于業(yè)務(wù)連續(xù)性的訴求，在互聯(lián)網(wǎng)行業(yè)，往往更苛刻，可能10到15分鐘，這個業(yè)務(wù)就很難了。B

9、CM有一個特征，其實它原先畫了很多，我們理解BCM是設(shè)計一套針對不頻發(fā)，但確是大災(zāi)難的場景下，如何保證業(yè)務(wù)的連續(xù)性。其實對于互聯(lián)網(wǎng)行業(yè)來說，需求多，變更快，故障是非常頻繁的事情，影響面對于業(yè)務(wù)來說也很大，所以我們希望在BCM里面，加入一些持續(xù)優(yōu)化的因素，而這個ITIL里面是有的。我們把這兩個東西結(jié)合一起。阿里巴巴的運維保障體系，說白了很簡單。這是精減版的草圖，簡單來說就是全生命周期圍繞故障，形成體系閉環(huán)，持續(xù)改進以及快速的產(chǎn)品支撐落地。1、故障防范。當公司沒開的時候，比如我們明天準備開淘寶了，這時我們可以很輕松地坐在一起，把規(guī)范定出來，故障防范的約束定出來。但是很多時候業(yè)務(wù)起來了，我們還沒有及

10、時介入，所以說故障的閉環(huán)很可能是業(yè)務(wù)的已經(jīng)在做或者穩(wěn)定性做的不太好的時候，GOC再切入進去。在故障防范的階段，GOC重點關(guān)注3個點：一個是數(shù)據(jù)運營；一個是平臺管控；一個是日常演練。首先，看看數(shù)據(jù)運營。在阿里經(jīng)濟體所有業(yè)務(wù)中，無論是相似業(yè)務(wù)還是完全不同業(yè)務(wù)的穩(wěn)定性情況，可以簡單比較下各個BU穩(wěn)定性的情況，可以給出一份穩(wěn)定性建議報告。當具體到某個BU、某條業(yè)務(wù)線的時候，我們可以具體分析他們的穩(wěn)定性情況：與去年同比故障數(shù)有無增減；故障中多少比例是監(jiān)控發(fā)現(xiàn)的，還是等用戶打爆投訴電話后，才慢慢上來處理的；有多少比例的故障是人為失誤、變更等形式導(dǎo)致的。此外，是平臺管控。核心產(chǎn)品是ChangeFree，他是

11、阿里巴巴做變更管控非常好的平臺，基于數(shù)據(jù)運營。現(xiàn)在很多故障剛剛發(fā)生的時候，變更人還不知道什么情況的時候，幾分鐘時間就已經(jīng)發(fā)生過一個故障，但通過快速回滾恢復(fù)掉了。這中間有兩個點：第一個點，看變更能否發(fā)到線上，期間會有一系列的管控，通過很嚴格的變更紅線來衡量線上變更。第二個點，看變更到線上后是否符合預(yù)期，這是非常關(guān)鍵的點。符合預(yù)期不是說是否符合變更人的預(yù)期，而是指他是否符合不影響線上業(yè)務(wù)的預(yù)期，這是客戶最在乎的，也是我們GOC最關(guān)注的。比如某團隊做了一個非核心的邊緣變更，但這個變更通過幾層鏈路的傳導(dǎo)，可能會傳到電商交易的核心鏈路，那么整個交易就會被阻塞掉，阿里發(fā)生過這樣的案例。當出現(xiàn)這種情況，你會

12、發(fā)現(xiàn)，沒有很好的平臺支撐，你是很難找到引發(fā)這個故障的具體變更。因為從出問題的點往上回溯的時候往往是最難的，GOC通過大量實際案例，以及算法同學(xué)們的努力，我們現(xiàn)在能夠解決一些這樣的問題。日常演練我們提日常，經(jīng)常會有一個反問句，這個也是我在SRE讀到的，你到底是愿意圣誕節(jié)晚上和老婆、孩子看電視享受節(jié)日的時候，突然故障發(fā)生了，還是愿意在演練的時候，所有人都在一起，大家來模擬故障，故障一發(fā)生大家快速處理，我會選后者。演練很重要，而且需要頻繁做，要把他當作日常的事情來做。阿里巴巴這邊我們演練就是老板非常看中這個事情。我們2015年發(fā)生過一個527事件，影響特別不好，我們后來通過技術(shù)來避免這個問題，叫異地

13、多活和一鍵切換。但是這個工具是否每時每刻都是有效的，畢竟它的依賴很多，而且它所依賴的東西會因為一些需求的變化而更新。后來，大老板給我們出了一個難題，讓準備一個核按鈕，隨時都可以按，按一下一個機房就掛了，這是人為造成的而且事先不告訴你，這把我們GOC訓(xùn)練地很警惕。我們有值班體系，7*24小時值班，這樣大老板早上一時興起就按一下，一個機房掛了，GOC趕緊一鍵切換掉，然后業(yè)務(wù)恢復(fù)。期間也就1分鐘、2分鐘。若是交易掛了的話，1分鐘是幾百萬的損失，其實影響面是很大的，但是我們覺得在業(yè)務(wù)低峰期搞搞演練，讓大家一直保持對生產(chǎn)環(huán)境的警惕，是很有必要的。這個項目的代號叫虎虎虎。2、故障發(fā)現(xiàn)這個部分我也提3點：一

14、個是業(yè)務(wù)監(jiān)控。我相信不同團隊、不同公司會有不同的理解。甚至東西方也有很大的區(qū)別，在國外主要用service level agreement，在阿里巴巴主要從用戶視角來看業(yè)務(wù)，比如業(yè)務(wù)是否不可用，用戶體驗是否變差。如果有，那我們就劃出4級來，然后告訴你這是風險非常高的級別，那么你必須要做好限流，必須做好降級，必須做好容災(zāi)。這樣做，逼著你時刻在關(guān)鍵的功能點或接口上做好日志記錄或者做好鏈路信息上報，從而形成業(yè)務(wù)日志監(jiān)控。業(yè)務(wù)監(jiān)控是監(jiān)控的一種，但核心跟用戶體驗息息相關(guān)的故障等級定義相關(guān)聯(lián)。這在阿里巴巴特別有用。例如交易下跌10%，這是2010年定的，已經(jīng)七年了，一旦發(fā)生交易下跌10%，系統(tǒng)穩(wěn)定性偏低的

15、團隊會比較緊張，怕是自己導(dǎo)致的，盡快響應(yīng)并恢復(fù)，否則時間久了，就會發(fā)酵成更大的問題。大家都認同業(yè)務(wù)監(jiān)控的重要性，也是我們能夠集中力量去恢復(fù)很多復(fù)雜故障的一個很好的點。全維度監(jiān)控，就是說從各個維度上，比如IDC、網(wǎng)絡(luò)、應(yīng)用、系統(tǒng)和業(yè)務(wù)層面。業(yè)務(wù)層面我們也分，不是所有的接口都是很致命的接口，有時候我們也會降級。比如雙十一時，會把購物車里面否已收貨的狀態(tài)接口降級掉，你就暫時看不了，但是不會影響你下單和支付。最后智能監(jiān)控，核心是為了解決報警不準的問題，一般來說，新上的業(yè)務(wù)，該業(yè)務(wù)點很關(guān)鍵，但是量不大且經(jīng)常抖動，這時候，設(shè)置告警閾值會很痛苦。GOC主要通過智能監(jiān)控來解決這個問題，通過算法計算基線，然后自

16、動預(yù)測異常，而報警可以只設(shè)一個相對于預(yù)測基線的水位有沒有下跌即可，非常方便，而且準確。這可以幫我們省掉很多問題，因為業(yè)務(wù)根據(jù)其特性在某些情況下往往會有較大的波動，比如10點鐘聚劃算有活動，肯定會往上漲，中午大家都在吃飯的時候，支付寶肯定會漲，淘寶會跌，周末的量比周一到周五的量大。這種東西你配一個死的閾值很難搞定，智能監(jiān)控是比較好的，我們這邊使用范圍很廣。3、應(yīng)急響應(yīng)為什么會有這個智能，GOC做了非常有挑戰(zhàn)的事情，做724小時應(yīng)急。一個互聯(lián)網(wǎng)公司不該設(shè)這樣一個傳統(tǒng)的職位。大家小區(qū)里面門衛(wèi)是724小時的，我們就相當于是阿里巴巴這些生產(chǎn)系統(tǒng)門衛(wèi)。真的是7*24小時去支持我們線上的故障。當然解決這個問

17、題，我們也想了一個辦法，其實這個也是我們從一些前輩的公司學(xué)到的，谷歌公司他們也是這么做的。他們分公司特別多，總是可以找人換過來，google的SRE是可以實現(xiàn)日出而作，日落而息，總是有另外一個時區(qū)的同事能夠接替上。我們現(xiàn)在還不夠，大概做到了3個地方，硅谷、北京和杭州。未來我們也希望能夠在中東或者歐洲建立起來這樣一個團隊。能夠真正讓GOC也實現(xiàn)日出而作、日落而息的7*24小時。4、快速恢復(fù)快速恢復(fù)是最重要的事情。我們前面做的不管是故障發(fā)現(xiàn)還是應(yīng)急響應(yīng)，最終的目標是快速恢復(fù)。快速恢復(fù)有一個誤區(qū)，不是說故障恢復(fù)了你就恢復(fù)了，你故障可以不恢復(fù)，你業(yè)務(wù)先恢復(fù)就好了。這里面有一個思路，就是隔離。隔掉就好了

18、，我不受影響，我的冗余能撐住現(xiàn)在的量，讓用戶不再受影響。那個故障，該哪個團隊去查原因去搞就行了。還有一個是一鍵恢復(fù)。例如異地多活，因為平時又不能切，切一下那十幾秒中還是會有交易影響的，必須等到真的發(fā)現(xiàn)單機房出現(xiàn)問題的時候，大量報警涌出來時，你果斷切掉就好了。所以這個點，我們現(xiàn)在也不能做到完全的智能或者故障自愈的方式，還是通過一鍵的方式來搞定的，當然非常方便，點一下就好了。5、故障定位這里面有兩個點，一個是初因定位，一個是根因定位，這兩個一直在打架。初因定位對于我們來講，最淺層的話故障就兩種可能，要么是容量不夠，要么就是有變更。這里面的變更是指非常廣義的變更，我們對于變更的定義也是集團通行的，叫

19、做生產(chǎn)環(huán)境上的一切操作都屬于變更。包括你從跳板機登陸生產(chǎn)機的操作，也屬于變更。這是很嚴格的，很多開發(fā)不理解，有的開發(fā)會說，發(fā)布才算變更，像配置，打一個日志，殺個進程那就是個日常操作為什么是變更，會有這樣的爭論。我們這邊要求一定是這樣子的，我們發(fā)生過這樣的案例。以前比較早的時期，我們很厲害的一個B大師，有一次有一個很復(fù)雜的故障，影響面還挺大的，他就在那查了好久，最后才發(fā)現(xiàn)是有一個同學(xué)在線上改了一臺機器GVM的參數(shù)，直接是在上面改的，那個參數(shù)有了問題后，就會連鎖反應(yīng)，會影響到上下游的很多東西，用戶會一直交易上會有問題。這東西根本沒辦法查，你查的時候總是會去從可能性方面去查，從網(wǎng)絡(luò)、上下游、鏈路、哪

20、有發(fā)布。查了好幾個小時發(fā)現(xiàn)是這個東西的時候，這種事情找到它是很高興的，但找到之后我們的反思總結(jié)出來東西，其實可能就是紅線的事情。生產(chǎn)環(huán)境要敬畏生產(chǎn)，嚴格把控。最近也有人在犯，發(fā)生變更的時候，他違規(guī)操作出了故障。他說要凌晨1點半變更，然后夜深人靜時候，他就1點20選擇了變更，提前了10分鐘。這里面也有一個點，就是我們能不能更智能判斷他到底是在故障應(yīng)急，還是違反了他自己聲稱的時間窗口的方式去做，但是他做了，最后我們給他的結(jié)果也是不太好，因為確實違反了紅線。這里核心的道理就是生產(chǎn)環(huán)境你要敬畏，你說了什么時候做就什么時候做，畢竟我們不是消費者，我們是拿著工資的開發(fā)或運維同學(xué)，我們要對公司生產(chǎn)經(jīng)營活動負

21、責。根因就是指上下游鏈路。6、故障復(fù)盤故障復(fù)盤也有是兩個，總結(jié)沉淀和措施改進。這個ITIL里面也有，我們這里面其實基本上是一樣的，組織一個故障約會，我們?nèi)グ褜?dǎo)致這個故障的前因后果按照時間序列列出來，再有就是列好所有故障改進的Action。故障改進，也是我們很看重的事情。我們會看故障改進的及時完成率，而不是看他的完成率。因為當我們發(fā)生了一個故障，出現(xiàn)了改進措施的時候，這個改進措施會影響故障的再次發(fā)生，如果你及時的把他改掉了，那么這個故障再發(fā)生的概率就會降低很多。如果你不改掉，第二天很有可能還會再發(fā)生這個故障。這個風險我們覺得是非常嚴格的事，所以我們對于每一個同學(xué)的改進措施，也是非常嚴格非常高要求

22、的去運營這個事情。我們也欣喜的可以看到，阿里云有很多團隊，每次故障之后他們能夠及時核對和檢查改進措施是否已完成。我們盡可能把線上的風險發(fā)現(xiàn)了，就把它消滅掉。把真正的潛在的風險留出足夠的buffer。7、演練驗收演練驗收有一個悖論，有時會問開發(fā)，優(yōu)化措施完成沒，每次都說落地了沒問題了，然后故障又以同樣的原因再次發(fā)生了，然后解釋說當時搞改進的時候沒有考慮到有這個case，這是意外情況，但是之前故障的那個場景考慮到了，不會再發(fā)生了。出現(xiàn)這樣的情況，就應(yīng)該嘗試去推動演練驗收，跟進具體改進措施的結(jié)果是不是能達到我們描述的預(yù)期。阿里巴巴演練做了很多，比如說我們做發(fā)布的時候會有灰度，演練的時候在線上隔離環(huán)境

23、中造出來一套和線上類似環(huán)境，但其實走的是演練的量而不是正常用戶的量，然后灰度時候我們一部分會引入一些特定用戶量進來。這里核心的點是，要具備隔離環(huán)境的能力，要具備演練的機制，真真切切的把線上的Action能夠盡快落地到演練里面，然后把他日?；饋?。我們只有日常演練，反復(fù)演練，才能故障發(fā)生時心里有底。其實演練做法很簡單，比如接口有做限流，那我給接口再多打一點量；比如說的接口健壯性沒有問題，那我就給你摘掉一個或者摘掉下游的一個DB什么的。通過阿里巴巴的演練系統(tǒng)，可以很快地落地，并且形成閉環(huán)，對于業(yè)務(wù)團隊是非常寶貴的經(jīng)驗。三、運行無間最佳實踐基于運維保障體系，我們摸索除了一個最佳實踐。這個圖還是比較復(fù)

24、雜，我簡單的講一下，它是分三層。但其中最核心的，最重要的是產(chǎn)品支撐。不管我們用任何體系也好，用BCM，還是用ITIL，其核心點在于我們要有一套趁手的能夠管理好生產(chǎn)環(huán)境的平臺。我們的平臺主要有，故障管理平臺（OPM），應(yīng)急響應(yīng)平臺（OPM），容災(zāi)演練平臺（ODE），變更管理平臺（OCM），運行分析平臺（ODA），數(shù)據(jù)質(zhì)量平臺（ODQ）等。第二個持續(xù)改進，就是運行管理域體系的那7個流程，防范、發(fā)現(xiàn)、響應(yīng)、恢復(fù)、定位、復(fù)盤和驗收。這里面，我又簡單的分了三類，第一個防范層面做好規(guī)范建設(shè)。靜態(tài)去看每個公司都會認為自己做的是最好的，我們也認為做的最好。但在真正跑的過程中出了故障，發(fā)現(xiàn)規(guī)范里面有漏洞，那就要

25、回來形成一個故障的閉環(huán)。在規(guī)范建設(shè)里面，我們沒有做多深的理論，但一定要保證夠快夠權(quán)威。當業(yè)務(wù)發(fā)展上到新臺階時，或者出現(xiàn)新的問題時，你一定要把他盡快地放到規(guī)范里面去。比如說某一天突然間我們發(fā)現(xiàn)盒馬鮮生有個交易故障，當然那個故障處理的很快，15分鐘就恢復(fù)了。但我們以前沒有想到的問題是，業(yè)務(wù)不答應(yīng)，門店員工不答應(yīng)，而且情緒激動，拍圖發(fā)過來說，你看這十幾分鐘時間，多少手推車被扔這了，這里面還有活蹦亂跳的魚和生鮮，我現(xiàn)在要怎么把這些全都收回去，因為交易有問題，顧客等不了就不買了。這其實講一個研發(fā)的體感，研發(fā)有很多確實沒有體驗過線下業(yè)務(wù)，淘寶、手淘與盒馬鮮生在支付場景最大的區(qū)別是，盒馬鮮生線下的用戶更易怒

26、。手淘支付失敗了十幾分鐘，大不了手機切到微信、微博吐吐槽，過十幾分鐘切回來再買也可以接收，對于交易故障的容忍度還是比較寬容，但是在盒馬鮮生門店，你拎著幾條魚或者大龍蝦，在那排隊等了十分鐘，基本就不會再等了，直接把東西扔在那里走人，換做是我也會是這樣，因為消費場景不一樣。這里面背后工程師對于穩(wěn)定性、以及交易的體感上確實理解不深，后來盒馬穩(wěn)定性小組就定了一個很簡單的規(guī)范，盒馬門店是早9點到晚10營業(yè)，營業(yè)期間一切變更停掉，晚10點后到第二天早上9點前合規(guī)的變更是可以做的，一條樸素的規(guī)范，解掉了很大的問題。其實這個里面的三塊部分我們還是講一下運行無間這個詞。運行無間是指把運行管理域體系里面的產(chǎn)品和服

27、務(wù)做一個打通，不要拘泥于這個是變更管理服務(wù)，這個是故障管理服務(wù)，其實我們希望是打通的，當故障發(fā)現(xiàn)的時候，你是先去恢復(fù)他，還是說如果你可以更趁手的找出來這里正在有一個變更發(fā)布，你回滾那個變更。實踐證明，當監(jiān)控報警出來的時候，同時把變更信息推出來的時候，把變更回滾掉對更快的挽回業(yè)務(wù)有非常大時間的縮短。故障發(fā)生，然后我們通過監(jiān)控發(fā)現(xiàn)這個故障，然后迅速的把這個故障的業(yè)務(wù)指標所對應(yīng)的接口，那個接口所對應(yīng)的后面的應(yīng)用，上下游畫個圈，所有相關(guān)聯(lián)的變更在最近15分鐘內(nèi)的故障全都列出來（15分鐘是一個黃金的線，我們統(tǒng)計過90%的變更導(dǎo)致故障，15分鐘內(nèi)一定會導(dǎo)致這個故障，只有10%的變更要一兩天或者兩三天通過一

28、些特定的條件觸發(fā)之后導(dǎo)致故障），然后發(fā)給相關(guān)變更的同學(xué)，很有可能變更的同學(xué)第一時間是不知道有故障了，由于高強度的工作，不一定每個群都看，不一定每個信息都讀，我們是直接電話打到他，說親請立即回滾。讓他回滾掉，然后業(yè)務(wù)恢復(fù)。這個恢復(fù)速度，是比要去查出來原因等應(yīng)急隊長再調(diào)度一下組織救火要快很多。這里面很典型的，故障監(jiān)控以及變更的信息聯(lián)動的操作，然后這個東西其實進一步做，故障變更發(fā)現(xiàn)了之后，我們還是讓開發(fā)自己做的回滾。進一步去想故障能不能自愈，這類故障我們自己去操作回滾，而且回滾是安全的話。我們還有一個前置條件，任何變更如果你的回滾預(yù)案是不安全的，是不能回滾的變更，是不可能被審核通過的，任何回滾事件，

29、是建立在100%能夠回滾回去的，這時候我們就可以通過故障自愈的方式，很簡單的把他恢復(fù)掉?？焖俚某跻蚨ㄎ缓椭悄芨蚨ㄎ弧Ｖ悄芨蚨ㄎ?，是做智能基線算法的同一個團隊的同學(xué)做的。智能根因定位難點在于那個鏈條，我們有兩種，一種基于應(yīng)用的鏈路，一種基于業(yè)務(wù)指標的鏈路，這兩種分別有不同的優(yōu)化的效果。然后還有就是復(fù)盤，我們這邊人手不夠，可能你在做故障復(fù)盤的同時，又發(fā)生了一個故障讓，故障恢復(fù)后，你是先把這個復(fù)盤做完，還是接著做下一個呢，這樣的話人肯定是吃不消。我們提倡的是信息的自動采集，自助式的復(fù)盤。只要質(zhì)量達標，里面關(guān)鍵鏈路的信息從SRE的角度或GOC的角度來看，質(zhì)量是沒有問題，里面不會存在這種坑蒙拐騙的行

30、為就可以過的。自助式復(fù)盤，是比較好的能夠減輕業(yè)務(wù)大發(fā)展時對穩(wěn)定性訴求越來越高的點。常態(tài)化演練，通過這個東西把一些我們常見的ITIL服務(wù)的相互之間的打通，我們的確可以看到運行管理域的成本效率是有優(yōu)化的，這個東西的優(yōu)化可以帶來我們業(yè)務(wù)連續(xù)穩(wěn)定性的提升。最后一個是體系閉環(huán)，就是說我們做一個體系也好，不管是好體系還是壞體系，我們做的最佳實踐，最終還是要業(yè)務(wù)方買單的。而業(yè)務(wù)方還是一群易怒，不關(guān)心穩(wěn)定性這樣一群開發(fā)，你跟他談穩(wěn)定性時，過后很快就忘了。核心點是閉環(huán)一定閉到他們那邊，讓他感受到我們是一起戰(zhàn)斗的。在去年元旦節(jié)，大家都放假在家，凌晨兩三點時，發(fā)生了一個故障，我們GOC很快就響應(yīng)了，最后發(fā)現(xiàn)業(yè)務(wù)方起來4個非常高級別的專家，一線值班同學(xué)們都基本上沒看到，在放假凌晨的時候，大家是很難處理故障的。這里面希望跟大家講，穩(wěn)定性是要形成協(xié)同作戰(zhàn)、共擔共建的體系閉環(huán)，只有這樣才可以真正保障線上業(yè)務(wù)，一個故障恢復(fù)，肯定不是某一個團隊能夠做的好的，那個團隊做的再好，他周邊的不給力，一樣會受非常大的牽連。而且這個體系閉環(huán)里面會面臨一個發(fā)展，他不是一個靜態(tài)的閉環(huán)，不是說你搞定了淘寶就搞定了一切，你會發(fā)現(xiàn)淘寶孵化出天貓，天貓孵化出天貓社區(qū)小店，孵化出新零售