本文根據 GOPS2017·上海站演講《阿里巴巴運維保障體系的一種最佳實踐》整理髮布

前言

阿里巴巴全球執行指揮中心，GOC (Global Operations Center)保障阿里經濟體的業務穩定執行的核心團隊。我們負責了整個阿里巴巴全域性生產系統的穩定性。就像業界經常提到谷歌的SRE，我們相當於阿里巴巴的SRE。

今天我的分享分為四個部分：

1、穩定性現狀及挑戰
2、運維保障體系介紹
3、執行無間最佳實踐
4、未來的發展及方向

一、穩定性現狀及挑戰

提到阿里巴巴，不得不說剛剛過去的雙十一。在剛剛過去的雙十一，每秒訂單建立的峰值達到32.5萬筆，每秒支付峰值達到25.6萬筆。相比2016年的17.5萬筆和12.5萬筆提升近80%。相比去年的緊張狀態，我們今年收到的普遍反饋是比較平穩。

同時，做為阿里巴巴雙十一備戰的一員，雙十一當天切身感受到，喝著茶就把今年的雙十一給過了的感覺。並且業務上也再創新高，達到了1682億，這是一個非常不容易的技術新高度。

如上圖所示，阿里巴巴業務迅速擴充套件，對於穩定性保障來說非常有挑戰性。從基礎架構層面來看：我們需要保障IDC，網路基礎設施，安全，阿里雲、阿里通訊和釘釘；從業務層面來看，我們需要保障天貓、淘寶、手淘、螞蟻金服、AE、飛豬、阿里媽媽、搜尋；以及近期迅猛發展的新零售、大文娛業務，如盒馬鮮生，村淘、雲零售、優酷、阿里影業、阿里健康等。

今年9月28日，新零售盒馬鮮生做了五城十店同開活動，一般來說開一家超市成本很高，而網際網路的速度卻是，可以一下子開起來，當然盒馬鮮生不是就滿足於一天可以開10個店的速度，未來是百家店、千家的店的速度。

10月份，阿里雲馬來西亞區開服。用不到1年時間，完成資料中心的新建。並且馬來西亞資料中心，也剛好是馬老師E-WTP（Electronic World Trade Platform，電子世界貿易平臺）真實的落地，速度確實非常快。

11月份，在雙十一活動上，有超過100萬臺天貓精靈智慧音箱的售賣。人工智慧業務的發展尚是如此迅猛，而我們也緊跟著業務在思考，人工智慧演算法的穩定性應該如何去衡量。

從各個維度看，阿里當前的業務面很廣、層次很深，因此很難做統一的一致的運維保障方案。所以，問題就在於，在這樣的情況下作為一個目標是要對接整個阿里經濟體線上業務穩定性的一個團隊來說，GOC應該如何去做。

昨天，魔泊雲的副總裁Christ Chen在分享中提到，他在2001年經歷了一個非常大的故障，原因是一個運維誤操作把一個DB搞掛了，而整個Cisco線上會議的服務也就掛了。當時間滑到16年後，2017年2月28日B廠也因為30分鐘無法通過WAP訪問的故障導致被約談；此外，AWS因一位工程師誤操作，導致整個美東一大片區域AWS不可訪問。

隨著時間，業務複雜度一直在增加，但導致線上故障發生的原因往往沒怎麼變。因此，需要我們在萬變之中找不變，找到運維保障的鑰匙。

隨著越來越多的新技術，新業務不斷湧現，我想這會是一個新的階段，這個階段是一個非常不容易達到的技術廣度，而在該技術廣度上，無論是人工智慧演算法、還是大規模基礎設施，穩定性運維保障都已經成為一個很難的課題。

當雙11辦到了第9年的今天，天貓雙十一已經成為了網際網路的一個超級工程，“超級工程”是一個新的概念。除了大家熟悉的下單、支付這樣的一些場景外，這個超級工程裡面還包含了很多新技術，包括客服、搜尋，推薦，廣告，庫存，物流等等。而這些是所有阿里工程師每天不斷創新突破的力量，這是非常不容易的技術速度。

這裡面為大家介紹2個點，正好是我們團隊做的。一個是Changefree系統，基於機器智慧的changefree保證線上變更有跡可循。它通過對變更資料進行全文檢索加自定義規則引擎，輔以機器學習的手段來自動統計分類，快速定位故障。這些是官方的表述，但是同比故障的恢復時間我們能夠檢驗得出來，可以提升65%，這是個非常難得的事情。

另一個是時間序列的異常檢測演算法，基於智慧基線的時間序列異常檢測演算法具有自動學習、自動化監控業務和預警的能力，有了它，業務指標監控的準確率從傳統監控策略的40%左右提升到80%。這2個光榮的上了我們新技術的榜，卻是是很難的點。

講完了現狀和挑戰之後，我想帶大家一起回過頭思考一下。當我們站在這樣的一個技術高度、廣度以及速度的時候，線上業務的穩定性、連續性以及運維保障方案有沒有不同。當出現故障的時候，或者頻繁出現故障的時候，如何保障使用者的使用不受影響或者受影響的程度可以降到最低。

二、運維保障體系介紹

我們阿里巴巴的運維保障體系也不是憑空起高樓，也是慢慢迭代出來的，主要學習這兩個體系：一個是ITIL ，一個是業務連續性管理，也就是BCM，ISO 22301。我們的運維保障體系，也是脫胎於此。

ITIL側重於流程和服務，能很好地建立服務目錄，但在深度使用過程發現略冗長，不太適合網際網路的精益迭代。GOC最初剛成立的時候，主要是用ITIL，但是隨著業務穩定性訴求的不斷的更新以及優化和不斷增長的時候，需要自建的訴求就自然而然來了。

總的來說，我們希望流程可以再輕便、高效一點，服務之間不再是孤島，希望服務之間是為了同一個目標，比如：故障快速恢復。通過這樣一個簡單的目標，我們能夠去把服務/產品打通，打透。

業務連續性管理，提到業務連續性管理，往往會同災難恢復一起講，英文稱為BC&DR（Business Continuity and Disaster Recovery）。一般提到BCM，經常會舉2013年東南亞海嘯的案例，海嘯發生後，某某銀行受到了嚴重影響，從結果看，一週內能否恢復營業，若恢復，說明基本不受影響；但如果1個月才能恢復營業，說明他很有可能需要長達3-5個月的時間來停業整頓；如果2個月還不能恢復，那這個銀行距離倒閉的時間就不遠了。

傳統行業對於業務連續性的訴求，在網際網路行業，往往更苛刻，可能10到15分鐘，這個業務就很難了。BCM有一個特徵，其實它原先畫了很多，我們理解BCM是設計一套針對不頻發，但確是大災難的場景下，如何保證業務的連續性。

其實對於網際網路行業來說，需求多，變更快，故障是非常頻繁的事情，影響面對於業務來說也很大，所以我們希望在BCM裡面，加入一些持續優化的因素，而這個ITIL裡面是有的。我們把這兩個東西結合一起。

阿里巴巴的運維保障體系，說白了很簡單。這是精減版的草圖，簡單來說就是全生命週期圍繞故障，形成體系閉環，持續改進以及快速的產品支撐落地。

1.故障防範

當公司沒開的時候，比如我們明天準備開淘寶了，這時我們可以很輕鬆地坐在一起，把規範定出來，故障防範的約束定出來。但是很多時候業務起來了，我們還沒有及時介入，所以說故障的閉環很可能是業務的已經在做或者穩定性做的不太好的時候，GOC再切入進去。

在故障防範的階段，GOC重點關注3個點：一個是資料運營；一個是平臺管控；一個是日常演練。

首先，看看資料運營。在阿里經濟體所有業務中，無論是相似業務還是完全不同業務的穩定性情況，可以簡單比較下各個BU穩定性的情況，可以給出一份穩定性建議報告。當具體到某個BU、某條業務線的時候，我們可以具體分析他們的穩定性情況：與去年同比故障數有無增減；故障中多少比例是監控發現的，還是等使用者打爆投訴電話後，才慢慢上來處理的；有多少比例的故障是人為失誤、變更等形式導致的。

此外，是平臺管控。核心產品是ChangeFree，他是阿里巴巴做變更管控非常好的平臺，基於資料運營。現在很多故障剛剛發生的時候，變更人還不知道什麼情況的時候，幾分鐘時間就已經發生過一個故障，但通過快速回滾恢復掉了。

這中間有兩個點：

第一個點，看變更能否發到線上，期間會有一系列的管控，通過很嚴格的變更紅線來衡量線上變更。

第二個點，看變更到線上後是否符合預期，這是非常關鍵的點。符合預期不是說是否符合變更人的預期，而是指他是否符合不影響線上業務的預期，這是客戶最在乎的，也是我們GOC最關注的。

比如某團隊做了一個非核心的邊緣變更，但這個變更通過幾層鏈路的傳導，可能會傳到電商交易的核心鏈路，那麼整個交易就會被阻塞掉，阿里發生過這樣的案例。

當出現這種情況，你會發現，沒有很好的平臺支撐，你是很難找到引發這個故障的具體變更。因為從出問題的點往上回溯的時候往往是最難的，GOC通過大量實際案例，以及演算法同學們的努力，我們現在能夠解決一些這樣的問題。

日常演練我們提日常，經常會有一個反問句，這個也是我在SRE讀到的，你到底是願意聖誕節晚上和老婆、孩子看電視享受節日的時候，突然故障發生了，還是願意在演練的時候，所有人都在一起，大家來模擬故障，故障一發生大家快速處理，我會選後者。演練很重要，而且需要頻繁做，要把他當作日常的事情來做。阿里巴巴這邊我們演練就是老闆非常看中這個事情。

我們2015年發生過一個527事件，影響特別不好，我們後來通過技術來避免這個問題，叫異地多活和一鍵切換。但是這個工具是否每時每刻都是有效的，畢竟它的依賴很多，而且它所依賴的東西會因為一些需求的變化而更新。

後來，大老闆給我們出了一個難題，讓準備一個核按鈕，隨時都可以按，按一下一個機房就掛了，這是人為造成的而且事先不告訴你，這把我們GOC訓練地很警惕。

我們有值班體系，7*24小時值班，這樣大老闆早上一時興起就按一下，一個機房掛了，GOC趕緊一鍵切換掉，然後業務恢復。期間也就1分鐘、2分鐘。若是交易掛了的話，1分鐘是幾百萬的損失，其實影響面是很大的，但是我們覺得在業務低峰期搞搞演練，讓大家一直保持對生產環境的警惕，是很有必要的。這個專案的代號叫虎虎虎。

2.故障發現

這個部分我也提3點：一個是業務監控。我相信不同團隊、不同公司會有不同的理解。甚至東西方也有很大的區別，在國外主要用service level agreement，在阿里巴巴主要從使用者視角來看業務，比如業務是否不可用，使用者體驗是否變差。

如果有，那我們就劃出4級來，然後告訴你這是風險非常高的級別，那麼你必須要做好限流，必須做好降級，必須做好容災。這樣做，逼著你時刻在關鍵的功能點或介面上做好日誌記錄或者做好鏈路資訊上報，從而形成業務日誌監控。

業務監控是監控的一種，但核心跟使用者體驗息息相關的故障等級定義相關聯。這在阿里巴巴特別有用。例如交易下跌10%，這是2010年定的，已經七年了，一旦發生交易下跌10%，系統穩定性偏低的團隊會比較緊張，怕是自己導致的，儘快響應並恢復，否則時間久了，就會發酵成更大的問題。大家都認同業務監控的重要性，也是我們能夠集中力量去恢復很多複雜故障的一個很好的點。

全維度監控，就是說從各個維度上，比如IDC、網路、應用、系統和業務層面。業務層面我們也分，不是所有的介面都是很致命的介面，有時候我們也會降級。比如雙十一時，會把購物車裡面否已收貨的狀態介面降級掉，你就暫時看不了，但是不會影響你下單和支付。

最後智慧監控，核心是為了解決報警不準的問題，一般來說，新上的業務，該業務點很關鍵，但是量不大且經常抖動，這時候，設定告警閾值會很痛苦。GOC主要通過智慧監控來解決這個問題，通過演算法計算基線，然後自動預測異常，而報警可以只設一個相對於預測基線的水位有沒有下跌即可，非常方便，而且準確。這可以幫我們省掉很多問題，因為業務根據其特性在某些情況下往往會有較大的波動，比如10點鐘聚划算有活動，肯定會往上漲，中午大家都在吃飯的時候，支付寶肯定會漲，淘寶會跌，週末的量比周一到週五的量大。這種東西你配一個死的閾值很難搞定，智慧監控是比較好的，我們這邊使用範圍很廣。

3.應急響應

為什麼會有這個智慧，GOC做了非常有挑戰的事情，做724小時應急。一個網際網路公司不該設這樣一個傳統的職位。大家小區裡面門衛是724小時的，我們就相當於是阿里巴巴這些生產系統門衛。真的是7*24小時去支援我們線上的故障。

當然解決這個問題，我們也想了一個辦法，其實這個也是我們從一些前輩的公司學到的，谷歌公司他們也是這麼做的。他們分公司特別多，總是可以找人換過來，google的SRE是可以實現日出而作，日落而息，總是有另外一個時區的同事能夠接替上。

我們現在還不夠，大概做到了3個地方，矽谷、北京和杭州。未來我們也希望能夠在中東或者歐洲建立起來這樣一個團隊。能夠真正讓GOC也實現日出而作、日落而息的7*24小時。

4.快速恢復

快速恢復是最重要的事情。我們前面做的不管是故障發現還是應急響應，最終的目標是快速恢復。快速恢復有一個誤區，不是說故障恢復了你就恢復了，你故障可以不恢復，你業務先恢復就好了。

這裡面有一個思路，就是隔離。隔掉就好了，我不受影響，我的冗餘能撐住現在的量，讓使用者不再受影響。那個故障，該哪個團隊去查原因去搞就行了。還有一個是一鍵恢復。例如異地多活，因為平時又不能切，切一下那十幾秒中還是會有交易影響的，必須等到真的發現單機房出現問題的時候，大量報警湧出來時，你果斷切掉就好了。

所以這個點，我們現在也不能做到完全的智慧或者故障自愈的方式，還是通過一鍵的方式來搞定的，當然非常方便，點一下就好了。

5.故障定位

這裡面有兩個點，一個是初因定位，一個是根因定位，這兩個一直在打架。

初因定位對於我們來講，最淺層的話故障就兩種可能，要麼是容量不夠，要麼就是有變更。這裡面的變更是指非常廣義的變更，我們對於變更的定義也是集團通行的，叫做生產環境上的一切操作都屬於變更。包括你從跳板機登陸生產機的操作，也屬於變更。

這是很嚴格的，很多開發不理解，有的開發會說，釋出才算變更，像配置，打一個日誌，殺個程序那就是個日常操作為什麼是變更，會有這樣的爭論。

我們這邊要求一定是這樣子的，我們發生過這樣的案例。以前比較早的時期，我們很厲害的一個B大師，有一次有一個很複雜的故障，影響面還挺大的，他就在那查了好久，最後才發現是有一個同學在線上改了一臺機器GVM的引數，直接是在上面改的，那個引數有了問題後，就會連鎖反應，會影響到上下游的很多東西，使用者會一直交易上會有問題。

這東西根本沒辦法查，你查的時候總是會去從可能性方面去查，從網路、上下游、鏈路、哪有釋出。查了好幾個小時發現是這個東西的時候，這種事情找到它是很高興的，但找到之後我們的反思總結出來東西，其實可能就是紅線的事情。

生產環境要敬畏生產，嚴格把控。最近也有人在犯，發生變更的時候，他違規操作出了故障。他說要凌晨1點半變更，然後夜深人靜時候，他就1點20選擇了變更，提前了10分鐘。

這裡面也有一個點，就是我們能不能更智慧判斷他到底是在故障應急，還是違反了他自己聲稱的時間視窗的方式去做，但是他做了，最後我們給他的結果也是不太好，因為確實違反了紅線。

這裡核心的道理就是生產環境你要敬畏，你說了什麼時候做就什麼時候做，畢竟我們不是消費者，我們是拿著工資的開發或運維同學，我們要對公司生產經營活動負責。

根因就是指上下游鏈路。

6.故障覆盤

故障覆盤也有是兩個，總結沉澱和措施改進。這個ITIL裡面也有，我們這裡面其實基本上是一樣的，組織一個故障約會，我們去把導致這個故障的前因後果按照時間序列列出來，再有就是列好所有故障改進的Action。

故障改進，也是我們很看重的事情。我們會看故障改進的及時完成率，而不是看他的完成率。因為當我們發生了一個故障，出現了改進措施的時候，這個改進措施會影響故障的再次發生，如果你及時的把他改掉了，那麼這個故障再發生的概率就會降低很多。

如果你不改掉，第二天很有可能還會再發生這個故障。這個風險我們覺得是非常嚴格的事，所以我們對於每一個同學的改進措施，也是非常嚴格非常高要求的去運營這個事情。

我們也欣喜的可以看到，阿里雲有很多團隊，每次故障之後他們能夠及時核對和檢查改進措施是否已完成。我們儘可能把線上的風險發現了，就把它消滅掉。把真正的潛在的風險留出足夠的buffer。

7.演練驗收

演練驗收有一個悖論，有時會問開發，優化措施完成沒，每次都說落地了沒問題了，然後故障又以同樣的原因再次發生了，然後解釋說當時搞改進的時候沒有考慮到有這個case，這是意外情況，但是之前故障的那個場景考慮到了，不會再發生了。

出現這樣的情況，就應該嘗試去推動演練驗收，跟進具體改進措施的結果是不是能達到我們描述的預期。阿里巴巴演練做了很多，比如說我們做釋出的時候會有灰度，演練的時候在線上隔離環境中造出來一套和線上類似環境，但其實走的是演練的量而不是正常使用者的量，然後灰度時候我們一部分會引入一些特定使用者量進來。

這裡核心的點是，要具備隔離環境的能力，要具備演練的機制，真真切切的把線上的Action能夠儘快落地到演練裡面，然後把他日常化起來。我們只有日常演練，反覆演練，才能故障發生時心裡有底。

其實演練做法很簡單，比如介面有做限流，那我給介面再多打一點量；比如說的介面健壯性沒有問題，那我就給你摘掉一個或者摘掉下游的一個DB什麼的。通過阿里巴巴的演練系統，可以很快地落地，並且形成閉環，對於業務團隊是非常寶貴的經驗。

三、執行無間最佳實踐

基於運維保障體系，我們摸索除了一個最佳實踐。這個圖還是比較複雜，我簡單的講一下，它是分三層。但其中最核心的，最重要的是產品支撐。不管我們用任何體系也好，用BCM，還是用ITIL，其核心點在於我們要有一套趁手的能夠管理好生產環境的平臺。我們的平臺主要有，故障管理平臺（OPM），應急響應平臺（OPM），容災演練平臺（ODE），變更管理平臺（OCM），執行分析平臺（ODA），資料質量平臺（ODQ）等。

第二個持續改進，就是執行管理域體系的那7個流程，防範、發現、響應、恢復、定位、覆盤和驗收。

這裡面，我又簡單的分了三類，第一個防範層面做好規範建設。靜態去看每個公司都會認為自己做的是最好的，我們也認為做的最好。但在真正跑的過程中出了故障，發現規範裡面有漏洞，那就要回來形成一個故障的閉環。

在規範建設裡面，我們沒有做多深的理論，但一定要保證夠快夠權威。當業務發展上到新臺階時，或者出現新的問題時，你一定要把他儘快地放到規範裡面去。

比如說某一天突然間我們發現盒馬鮮生有個交易故障，當然那個故障處理的很快，15分鐘就恢復了。但我們以前沒有想到的問題是，業務不答應，門店員工不答應，而且情緒激動，拍圖發過來說，你看這十幾分鍾時間，多少手推車被扔這了，這裡面還有活蹦亂跳的魚和生鮮，我現在要怎麼把這些全都收回去，因為交易有問題，顧客等不了就不買了。

這其實講一個研發的體感，研發有很多確實沒有體驗過線下業務，淘寶、手淘與盒馬鮮生在支付場景最大的區別是，盒馬鮮生線下的使用者更易怒。手淘支付失敗了十幾分鍾，大不了手機切到微信、微博吐吐槽，過十幾分鍾切回來再買也可以接收，對於交易故障的容忍度還是比較寬容，但是在盒馬鮮生門店，你拎著幾條魚或者大龍蝦，在那排隊等了十分鐘，基本就不會再等了，直接把東西扔在那裡走人，換做是我也會是這樣，因為消費場景不一樣。

這裡面背後工程師對於穩定性、以及交易的體感上確實理解不深，後來盒馬穩定性小組就定了一個很簡單的規範，盒馬門店是早9點到晚10營業，營業期間一切變更停掉，晚10點後到第二天早上9點前合規的變更是可以做的，一條樸素的規範，解掉了很大的問題。

其實這個裡面的三塊部分我們還是講一下執行無間這個詞。執行無間是指把執行管理域體系裡面的產品和服務做一個打通，不要拘泥於這個是變更管理服務，這個是故障管理服務，其實我們希望是打通的，當故障發現的時候，你是先去恢復他，還是說如果你可以更趁手的找出來這裡正在有一個變更釋出，你回滾那個變更。

實踐證明，當監控報警出來的時候，同時把變更資訊推出來的時候，把變更回滾掉對更快的挽回業務有非常大時間的縮短。

故障發生，然後我們通過監控發現這個故障，然後迅速的把這個故障的業務指標所對應的介面，那個介面所對應的後面的應用，上下游畫個圈，所有相關聯的變更在最近15分鐘內的故障全都列出來（15分鐘是一個黃金的線，我們統計過90%的變更導致故障，15分鐘內一定會導致這個故障，只有10%的變更要一兩天或者兩三天通過一些特定的條件觸發之後導致故障），然後發給相關變更的同學，很有可能變更的同學第一時間是不知道有故障了，由於高強度的工作，不一定每個群都看，不一定每個資訊都讀，我們是直接電話打到他，說親請立即回滾。讓他回滾掉，然後業務恢復。

這個恢復速度，是比要去查出來原因等應急隊長再排程一下組織救火要快很多。這裡面很典型的，故障監控以及變更的資訊聯動的操作，然後這個東西其實進一步做，故障變更發現了之後，我們還是讓開發自己做的回滾。進一步去想故障能不能自愈，這類故障我們自己去操作回滾，而且回滾是安全的話。

我們還有一個前置條件，任何變更如果你的回滾預案是不安全的，是不能回滾的變更，是不可能被稽核通過的，任何回滾事件，是建立在100%能夠回滾回去的，這時候我們就可以通過故障自愈的方式，很簡單的把他恢復掉。

快速的初因定位和智慧根因定位。智慧根因定位，是做智慧基線演算法的同一個團隊的同學做的。智慧根因定位難點在於那個鏈條，我們有兩種，一種基於應用的鏈路，一種基於業務指標的鏈路，這兩種分別有不同的優化的效果。

然後還有就是覆盤，我們這邊人手不夠，可能你在做故障覆盤的同時，又發生了一個故障讓，故障恢復後，你是先把這個覆盤做完，還是接著做下一個呢，這樣的話人肯定是吃不消。我們提倡的是資訊的自動採集，自助式的覆盤。只要質量達標，裡面關鍵鏈路的資訊從SRE的角度或GOC的角度來看，質量是沒有問題，裡面不會存在這種坑蒙拐騙的行為就可以過的。自助式覆盤，是比較好的能夠減輕業務大發展時對穩定性訴求越來越高的點。

常態化演練，通過這個東西把一些我們常見的ITIL服務的相互之間的打通，我們的確可以看到執行管理域的成本效率是有優化的，這個東西的優化可以帶來我們業務連續穩定性的提升。

最後一個是體系閉環，就是說我們做一個體系也好，不管是好體系還是壞體系，我們做的最佳實踐，最終還是要業務方買單的。而業務方還是一群易怒，不關心穩定性這樣一群開發，你跟他談穩定性時，過後很快就忘了。核心點是閉環一定閉到他們那邊，讓他感受到我們是一起戰鬥的。

在去年元旦節，大家都放假在家，凌晨兩三點時，發生了一個故障，我們GOC很快就響應了，最後發現業務方起來4個非常高級別的專家，一線值班同學們都基本上沒看到，在放假凌晨的時候，大家是很難處理故障的。

這裡面希望跟大家講，穩定性是要形成協同作戰、共擔共建的體系閉環，只有這樣才可以真正保障線上業務，一個故障恢復，肯定不是某一個團隊能夠做的好的，那個團隊做的再好，他周邊的不給力，一樣會受非常大的牽連。

而且這個體系閉環裡面會面臨一個發展，他不是一個靜態的閉環，不是說你搞定了淘寶就搞定了一切，你會發現淘寶孵化出天貓，天貓孵化出天貓社群小店，孵化出新零售的各個新興業態。最後一點是想說的是國際業務，無論是印度、東南亞公司的跨國團隊，對我們帶來更大的挑戰，溝通上、文化上、業務上，都需要深入合作、共擔共建，從而實現體系閉環。

案例

盒馬鮮生從2016年開始摸索到2017年7月正式對外發布說阿里巴巴全資的盒馬鮮生是阿里巴巴旗下新零售的代表。從那個點開始迎來了很多關注，並且業務爆發式增長。

那時候盒馬鮮生門店天天爆滿，各種業務訴求和穩定性的問題逐步突出。GOC對接盒馬鮮生也差不多從那時開始，大約1個月跟盒馬同學完成了一個初步穩定性提升方案的落地，有了明確的穩定性目標、穩定性組織，還有很多穩定性專項。

現在再看928五城十店同開，雙十一活動，穩定性問題得到很好地管理和改善，而且交易也再創新高。通過執行無間能夠在一個月左右的時間，快速能夠摸清業務現狀，明確穩定性目標，最終確實提高穩定性，減少故障，縮短故障處理時長，為業務大發展創造條件。

同時，我們進一步探索新零售的運維保障體系該怎樣去建，因為當天貓社群小店做規模化的時候，當銀泰、大潤發需要穩定性的時候，GOC可以更快介入進去，從而形成體系閉環。

四、發展及方向

GOC的願景是線上業務能在無人值守中穩定執行。而線上業務可能處在不同的發展時期：一個大體量的穩定發展期，可能處在中型體量的飛速發展期，也可能處在各種需求迭代持續在變更的小體量創新探索期。

無論業務如何變，GOC始終堅守3個樸素的觀點：

1、防止能預見的問題。線上業務的穩定性應該以預防為主，比如消防，不是為了滅火，而是為了防火，讓火燒不起來，這才是消防最大的好處。
2、快速恢復不能預防的問題
3、不再重複已發生的問題

GOC後面的發展方向主要有四個方面：

1、自動化：會持續做下去因為還有很多點沒有做到自動化，或者場景變化的太快，還來不及自動化，場景就沒有。
2、智慧化，我們在監控的領域做到了智慧監控，我們在變更領域做到智慧變更，但我們依然相信還有很多領域需要智慧的，像天貓精靈一樣，希望後面也能出來對著GOC智慧值班工具說：Hi，GOC，幫我把出故障的機房斷掉。
3、國際化，今年雙十一，我個人備戰的時候，有個非常大的印象，雖然我們是喝著茶過0點的，但是好累。因為國際化，活動時區不僅僅是東八區，國內雙十一忙完後，發現巴西的雙十一還沒結束，一直搞到12號的下午4點多才結束。
4、無人值守。通過標準化SOP操作，做一些常規的業務巡檢，來代替高成本的人力，減少日常工作，同時用機器人來代替，也可以降低很多誤操作。

作者：

吳昌龍
阿里巴巴全球執行指揮中心，GOC (Global Operations Center)是保障阿里經濟體的線上業務穩定執行的核心團隊。
2014年碩士畢業，專注於雲端計算。
先後就職於微電影，Melotic（比特幣），Rakuten（日本第一大電商）。2016年回國加入了阿里巴巴GOC，到現在一直專注於運維保障。

原文來自微信公眾號：高效運維