本文根據 GOPS2017·上海站演講《阿里巴巴運維保障體系的一種最佳實踐》整理髮布算法
前言
阿里巴巴全球運行指揮中心，GOC (Global Operations Center)保障阿里經濟體的業務穩定運行的核心團隊。咱們負責了整個阿里巴巴全局生產系統的穩定性。就像業界常常提到谷歌的SRE，咱們至關於阿里巴巴的SRE。安全
今天個人分享分爲四個部分：微信
一、穩定性現狀及挑戰
二、運維保障體系介紹
三、運行無間最佳實踐
四、將來的發展及方向網絡
1、穩定性現狀及挑戰
提到阿里巴巴，不得不說剛剛過去的雙十一。在剛剛過去的雙十一，每秒訂單建立的峯值達到32.5萬筆，每秒支付峯值達到25.6萬筆。相比2016年的17.5萬筆和12.5萬筆提高近80%。相比去年的緊張狀態，咱們今年收到的廣泛反饋是比較平穩。架構
同時，作爲阿里巴巴雙十一備戰的一員，雙十一當天切身感覺到，喝着茶就把今年的雙十一給過了的感受。而且業務上也再創新高，達到了1682億，這是一個很是不容易的技術新高度。運維
如上圖所示，阿里巴巴業務迅速擴展，對於穩定性保障來講很是有挑戰性。從基礎架構層面來看：咱們須要保障IDC，網絡基礎設施，安全，阿里雲、阿里通訊和釘釘；從業務層面來看，咱們須要保障天貓、淘寶、手淘、螞蟻金服、AE、飛豬、阿里媽媽、搜索；以及近期迅猛發展的新零售、大文娛業務，如盒馬鮮生，村淘、雲零售、優酷、阿里影業、阿里健康等。機器學習
今年9月28日，新零售盒馬鮮生作了五城十店同開活動，通常來講開一家超市成本很高，而互聯網的速度倒是，能夠一會兒開起來，固然盒馬鮮生不是就知足於一天能夠開10個店的速度，將來是百家店、千家的店的速度。工具
10月份，阿里雲馬來西亞區開服。用不到1年時間，完成數據中心的新建。而且馬來西亞數據中心，也恰好是馬老師E-WTP（Electronic World Trade Platform，電子世界貿易平臺）真實的落地，速度確實很是快。post
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個光榮的上了咱們新技術的榜，倒是是很難的點。
講完了現狀和挑戰以後，我想帶你們一塊兒回過頭思考一下。當咱們站在這樣的一個技術高度、廣度以及速度的時候，線上業務的穩定性、連續性以及運維保障方案有沒有不一樣。當出現故障的時候，或者頻繁出現故障的時候，如何保障用戶的使用不受影響或者受影響的程度能夠降到最低。
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什麼的。經過阿里巴巴的演練系統，能夠很快地落地，而且造成閉環，對於業務團隊是很是寶貴的經驗。
3、運行無間最佳實踐
基於運維保障體系，咱們摸索除了一個最佳實踐。這個圖仍是比較複雜，我簡單的講一下，它是分三層。但其中最核心的，最重要的是產品支撐。無論咱們用任何體系也好，用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能夠更快介入進去，從而造成體系閉環。
4、發展及方向
GOC的願景是線上業務能在無人值守中穩定運行。而線上業務可能處在不一樣的發展時期：一個大致量的穩定發展期，可能處在中型體量的飛速發展期，也可能處在各類需求迭代持續在變動的小體量創新探索期。
不管業務如何變，GOC始終堅守3個樸素的觀點：
一、防止能預見的問題。線上業務的穩定性應該以預防爲主，好比消防，不是爲了滅火，而是爲了防火，讓火燒不起來，這纔是消防最大的好處。
二、快速恢復不能預防的問題
三、再也不重複已發生的問題
GOC後面的發展方向主要有四個方面：
一、自動化：會持續作下去由於還有不少點沒有作到自動化，或者場景變化的太快，還來不及自動化，場景就沒有。
二、智能化，咱們在監控的領域作到了智能監控，咱們在變動領域作到智能變動，但咱們依然相信還有不少領域須要智能的，像天貓精靈同樣，但願後面也能出來對着GOC智能值班工具說：Hi，GOC，幫我把出故障的機房斷掉。
三、國際化，今年雙十一，我我的備戰的時候，有個很是大的印象，雖然咱們是喝着茶過0點的，可是好累。由於國際化，活動時區不只僅是東八區，國內雙十一忙完後，發現巴西的雙十一還沒結束，一直搞到12號的下午4點多才結束。
四、無人值守。經過標準化SOP操做，作一些常規的業務巡檢，來代替高成本的人力，減小平常工做，同時用機器人來代替，也能夠下降不少誤操做。
做者：
吳昌龍
阿里巴巴全球運行指揮中心，GOC (Global Operations Center)是保障阿里經濟體的線上業務穩定運行的核心團隊。
2014年碩士畢業，專一於雲計算。
前後就任於微電影，Melotic（比特幣），Rakuten（日本第一大電商）。2016年回國加入了阿里巴巴GOC，到如今一直專一於運維保障。
原文來自微信公衆號：高效運維