阿里數據庫運維10年演進之路
導語
阿里巴巴集團擁有超大的數據庫實例規模，在快速發展的過程中我們在運維管理方面也在不斷的面臨變化，從物理器到容器、從獨占到混布、從本地盤到存儲計算分離、從集團內到大促云資源，從開源的MySQL到自研分布式數據庫，運維管控進行了自我革新與進化。
作者——譚宇（花名：茂七），阿里巴巴高級技術專家。2009年加入阿里，對分布式系統和數據庫領域有很大的興趣。目前負責阿里巴巴集團數據庫中臺建設，支撐了集團數據庫在容器化、存儲計算分離、在離線混部、大規模遷移建站以及智能運維等技術探索與落地。
本文梳理了阿里巴巴數據庫運維發展歷程以及對未來數據庫自治時代的看法，期待與諸位一起討論。
正文
我在阿里快十年了，前五年做一些分布式系統開發相關的工作，參與的系統包括TFS/Tair/OceanBase，后五年聚焦在數據庫運維平臺及服務的建設，從搭建數據庫集群、數據采集等底層運維到外部客戶服務、POC支持等都有所經歷，好的想法歷來***，外加個人天資愚鈍，不敢說有什么***的想法，都是實踐過程中的一些感悟，且與大家分享，也是對過去一段時間的總結。
關于阿里的數據庫，大家可能已經聽說過很多，阿里巴巴數據庫技術的發展與整個集團的技術發展類似，從商業到開源再到自主研發。早在09年以前，阿里巴巴數據庫或DBA團隊已經在業界非常知名，擁有多名Oracle ACE / ACE Director，外加自發性的與業界的交流、分享以及著作，構建了非常強的影響力，很多人因此吸引而加入，這是一段榮耀時光，當時很多知名人物現在有的在創業、有的仍在集團不同的領域奮斗，江湖中仍然可以搜索到他們的傳說。
后來就是轟轟烈烈的去IOE運動了，剛入職時經常在內部BBS上看到各種成功去除Oracle的帖子，基本套路就是DBA和業務開發一起配合，通過各種腳本把數據遷移到MySQL上。在這個過程中，遇到過很多問題，也在積極尋求各種新的技術，比如為了突破磁盤性能問題，在當時主流的還是機械硬盤的時候，使用了Fusion-IO等，也在MySQL內核上開始各種改進，形成了AliSQL。
關于去IOE、各自數據庫內核技術、支撐的業務這些方面，講的很多，大家可以搜到各自技術相關的文章，但很少有人講過這背后有一個什么樣的平臺來支持這些業務變化以及技術迭代。過去的5年里，我和我的團隊一直在做數據庫運維或者是服務方面的事情，很難，我相信各位如果有做過這方面經驗會感同身受。
一方面，這是運維類或服務類系統的“原罪”，這類系統形成初期，它只是一個工具或一個平臺，使命是支撐好業務，自己并不實際產生價值。所有的技術要在這里落地，等落完地好像和你又沒什么關系，價值感比較弱。今天K8S等系統的出現說明這個也可以做得很好，但相對來說這是一個更難做好的領域。
另一方面，業務的復雜性、技術棧的多樣性以及所依賴的組件決定了這個系統在實現層面很難，你需要把各個組件一層一層的串聯起來。從業務訪問到數據庫內核再到底層的網絡、存儲、OS、硬件等，任何一個層面出了問題都會集中反應到你的系統中，實現人員面臨著從上到下各個層面問題的理解、異常的處理，對團隊及個人能力要求極高。
一個很具體的例子，我們的運維系統涉及了前端、大數據處理、算法、數據庫、底層軟硬件等各個技術領域。在最初期團隊不可能有各個領域的專家，需要每個同學了解并解決不同的領域的問題。
我想就這些方面，系統性地跟大家介紹一下我們所做的一些工作。主要包括三個方面：***，我們整個系統的發展歷程，所謂從歷史看未來，不知道過去，無法推斷出未來我們的樣子。第二，現階段的技術和產品，比如我們如何支撐我們現有的工作，雙11大促等。第三，從過去和現在出發，我們未來一段時間要到達的樣子。
1. 從歷史看未來
阿里巴巴數據庫運維發展的歷程，主要有這幾個階段。09年以前，以商業數據庫為主，去IOE也才開始。之前沒有整體運維規劃、運維平臺。使用了各類腳本、工具。
在09年以后，由于規模迅速膨脹，這個時候自然產生了一些工具團隊，把各類腳本拼在一起，弄個界面，形成了最初的產品。
接著，隨著復雜度進一步增加，以及云計算的推動。交付方面有了更高的要求，形成了服務化，比如DBaaS等。
近年來，隨著大數據、機器學習等技術的發展，AIOPS催生智能化。在智能化的基礎之上，對各類服務平臺的服務質量的進一步要求，也就是自治。
總體來講，有兩次比較大的革新。
***次是從產品化到服務化。最初，我們的產品形成非常簡單。沒有什么平臺，沒有什么系統，大家一邊干活一邊沉淀一些腳本，到處分發。隨著規模的增長，原來的那套腳本需要管理起來了，我相信很多團隊最開始都會設立一個工具組，專門來干這個事情。這就會演變成一個團隊做工具，另一個團隊來使用，慢慢的兩者之間的GAP就出現了。工具團隊有工具團隊的KPI，業務團隊有業務團隊的KPI，分歧會逐漸增大。
另外一個問題則是大家都在攢工具，攢平臺。結果這些平臺之間是相互不能通信的。比如一個應用開發，需要數據庫、搜索、分布式存儲等各個系統，開發人員需要去逐個申請，效率不高。
服務化的變革就是在這種情況下發生的。我們不提供工具、平臺，而提供服務。這些服務之間相互打通，并且我們對提供的服務有相關SLA保證。這次革新可以說是云計算的基礎，云計算的本質是IT資源交付技術的進步，這是云計算帶給我們的***價值。
第二次革新是自治，我們目前正處于這次革新中。
對SLA或者服務質量的追求是沒有止境的。現在很火的Cloud Native、Serverless本質上都是對更高服務質量的一種追求。要提升服務水平，關鍵點有兩個，一是規模，規模大了才能做更多事情，比如混合部署、智能調度、機器學習，都要求一定的規模和大量的數據。這也符合當前提供基礎服務的云計算趨于集中的趨勢。
規模也是問題的根源，管理一千個實例和十萬個實例所需的技術完全不一樣，所以另一個關鍵點是技術水平，有了規模還必須有相應的技術，比如容器化、機器學習、存儲計算分離、RDMA網絡等技術的提升。
2. 理想照進現實
當然技術的積累是一個長期的過程，積累到一定程度就會引起質變。我們這些年在系統建設、技術積累方面所做了許多工作。先來看一組數據，這是剛剛過去的雙十一數據庫相關的一些情況。
大家可能看過一些數據，比如成交額，交易峰值。對于背后的數據庫而言，每秒有超過5000萬次的訪問。特別是在高峰期，讀寫比是和平時不一樣的。通常一般系統讀寫比大約是9：1或者7：1。但在雙11高峰時，數據庫的讀寫比可能是2：1。在寫入比例極高的情況下，要求數據庫不能出現任何抖動或者延遲，我們對任何一種新技術的引入都非常嚴格。
另外，阿里巴巴大促場景非常復雜，包括線上線下以及海內外多種場景。基礎設施分布在全球多地，數十個機房同時支撐，系統復雜性非常高。
總結來看，我們的業務場景大致有以下幾個特點：
- 業務多樣性。作為數據庫中臺，數據庫團隊要支撐集團所有業務。包括核心電商、線下新零售場景以及各個獨立子公司。各種場景對數據庫的要求也不一樣，比如線上場景就要求高并發低延時，故障快速恢復。線下場景則要求絕對可用，而且接入及使用數據庫的方式都不受控制。而新加入阿里體系的收購公司，有原來的運維體系，要求他們做改變也不太現實。總之需求的多樣性對數據庫的要求非常高。
- 基礎設施多樣化，數據中心分布在全球，有的用公有云、有的有自建機房，有的用物理機，有的用Docker、用彈性計算等，整個集團就是一個超級大的混合云。
- 雙11超級大熱點，除了成本和性能方面，雙11在彈性方面有很高的要求。我們也不可能為雙11買這么多機器，那太浪費了。早期，會在不同的業務線之間進行拆借，比如借云的機器或者借離線的機器，大促后歸還，全靠人肉搬機器。整個大促周期非常長，人力成本和機器成本都很高。
針對以上情況，我們形成了如下架構。主要思路是向下層屏蔽差異，向上層提供多樣化服務能力，中間圍繞著彈性、穩定性、智能化進行建設。
早期的運維系統因為各種原因，沒有設計好的架構導致難以擴展，***越來越臃腫，推翻重構的事情并不少見。現今，我們設計了服務化的運維系統整體架構：
- 一來可以清晰地理順系統各個模塊之間的交互方式并標準化，徹底解決原來工具時代遺留下來的各自為政，各個功能散落在不同地方的問題，整個系統的發展不再背負歷史包袱；
- 二來可以解決技術棧太多的問題，從前端到底層采集、算法分析，我們不可能統一成一個框架、一種語言。讓這些模塊能互不影響、互相交互，是整個系統能做強的基礎；
- 三來可以將整個系統的數據集中起來，為后續智能化所需要的統一數據、統一算法提供基本要素；四來可以向外提供統一形式、功能多樣化的服務。要想做好做強一個服務類的系統，服務化是***步。
在底層，我們做了統一的資源調度層，用來屏蔽底層計算、存儲、網絡資源的差異，向上交付標準的容器。
中間是數據庫層。因為業務的多樣性，數據庫類型多種多樣，運行在不同的環境，我們通過統一的命令通道和采集通道的抽象來屏蔽這些差異。
再往上是傳統的數據庫運維層，包括常見的數據庫的生命周期管理，我們稱之為Lego，希望OPS這樣的基礎功能能像樂高一樣百變組合，迅速搭建我們想要的功能。還包括數據采集、處理存儲的模塊Kepler，我們希望把所有的運行數據實時采集到，然后通過大數據處理、機器學習等手段發掘出深層價值，采集的數據包括OS、網絡、存儲，數據庫的SQL流水、性能指標等等，整個處理的數據量非常大，并且所有指標都要求是秒級的。每秒都要處理超過100G的原始報文。
再往上是智能決策層，這一層完成自動修復與優化的工作，比如預期內的故障，異常處理。也通過采集到的數據，做一些分析和決策。
我們把整個系統的功能以服務的形式提供出來，大家可以在這個基礎之上定制想要的功能。過去幾年，我們在架構實現方面一直堅持“一個平臺、一套架構，集團孵化、云上輸出”的策略，集團內部數據庫管控平臺提供服務，所有模塊在一套架構下實現，產品在集團檢驗后開始在云上輸出。不同的時期有不同的堅持，在智能化時代，我們對這個架構及策略也有所調整，這個在后面會提及。
解決架構問題后，我們過去兩年主要圍繞幾個能力進行建設，一是容器化與存儲計算分離，二是快速彈性與混部的能力，三是規模化交付與智能運維，這幾項工作都是今天能夠發展成為集團數據庫中臺以及支撐雙十一的關鍵能力。
***，容器化是技術的量變到質變，容器并沒有很多開創性的技術，各種技術合在一起開辟了新的思路。所以在把數據庫放到容器里首先要突破我們的運維思路，堅定可以把數據庫放到容器里的這個想法。當然這個過程中也遇到過穩定性和性能問題，比如網絡在使用bridge模式的時候，會有些CPU的增加。
最終在網絡團隊不斷優化后，基本可以做到與物理機持平。容器化一方面解決了很多環境問題，另一方面也為數據庫的調度提供了可能，我們從16年開始做數據庫容器化，到今年，絕大部份的數據庫都跑在了容器里。
第二，存儲計算分離。其實數據庫最開始就是存儲計算分離架構的。在互聯網時代，這個架構在最初遇到了瓶頸，因為互聯網時代的容量擴張非常快。然后出現了分布式系統，把計算搬到數據所在的地方。但是隨著技術的發展，特別是云的交付方式，存儲計算分離的交付則更為便捷。交付多少計算能力，交付多少存儲，一目了然。
另外，存儲和計算的發展也不太均衡，比如雙11的時候，我要求的是計算能力，其實存儲并沒有增加多少。所以隨著技術的發展，我們這一圈基本上又轉了回來。當然存儲計算分離要不要上，我們也是經過了很長時間的討論，今天來看，上存儲計算分離這個決定是對的。在這個過程中也遇到很多問題，主要是延遲的問題，畢竟經過一層網絡，IO時間是有增加的。
我們最開始上了左邊這個架構，將遠程存儲掛載到本地，這個延遲要較本地盤大很多，核心業務難以接受，在這個基礎之上，我們大規模引入RDMA網絡，通過DBFS bypass掉kernel，延時基本能和本地盤相當，所以今年所有的核心業務就跑在了這個架構上。
有了容器化和存儲計算分離的基礎，就可以比較好的解決彈性問題了。之前我們的彈性主要靠搬數據加搬機器，現在數據可以不用搬了。我們大促所用的機器主要來自兩個地方，一個是離線資源，另外一個是云資源，我們用完之后云可以繼續對外售賣。
大家知道，雙11的高峰期主要在零點時段。所以我們在高峰期來的時候彈性擴容，高峰期結束立即縮容，還機器給別人用。我們結合集團的調度，做了一套混部調度系統，可以做到數據庫快上快下，今年我們的核心集群10分鐘就可以完成彈性擴縮，而我們最終的目標是在1分鐘內完成。
第三，交付和診斷。我們說云計算是IT資源交付能力的進步。我們基本完成了向用戶交付數據庫資源，開發人員可以通過系統自助完成數據庫資源的申請與使用。如果只是把交付理解為用戶自助獲取數據庫資源的話，我們已經完成得很好了。
但集團有更嚴苛和復雜的交付任務。比如下面兩個例子：大促時需要在上十萬個數據庫實例里擴容數千甚至上萬個實例，大促完成后還需要縮容回來。每年有固定的或臨時的建站、遷站等操作，例如今年的一路向北和上海、張北多次建站，可能會涉及到數萬數據庫實例及數十PB數據，這些都非常考驗我們交付的能力。
之前的常規做法是讓人來評估，確定好操作的數據庫范圍，算好需要多少機器資源，如何擺放等，再通過我們提供的遷移操作來完成。人需要來控制其中的每一個步驟，這是一個相當繁瑣的工作。每年都要做那么幾次，在我們今天要求快上快下的時候就顯得特別力不從心。
所以我們提出軟件定義部署的概念，類似常說的編排。主要做兩個事情，一是把我們的這些操作都精確定義和記載下來，線上的運行環境也能用代碼精確定義出來。二是把中間的騰挪步驟交給系統，人只需要描述最終的狀態，在我們預測準確到一定程度后，這個最終描述狀態也可以由系統來完成，真正的完成大促自動化交付。
可以看到，我們的鏈路其實很長，中間的各個組件出了問題診斷是一件很難的事情。Gartner有一個名詞叫AIOPS，相信大家都聽說過，其實Gartner提出AIOPS很早，最開始指的是基于算法的OPS，隨著AI技術的發展呢，他順勢把這個詞的寫法給改了，但本質上沒有變，仍然是依托大數據、算法來改變OPS。
應該說這也是個樸素的概念，我們在差不多時刻也提出了這個想法，最開始叫做數據驅動，后來改名為運行數據與數據運營，也是通過各種算法，比如基線、異常檢測、關聯分析、趨勢預測等等來自動決策或輔助我們決策。
這便是CloudDBA的初衷，先把各種采集到的數據匯聚統一、預處理再加上領域知識和算法，打通從用戶到DB，從DB到底層硬件這兩個鏈路。在雙11的時候也能實時的診斷訪問鏈路。當然這里待挖掘的還非常多，現在我們可以說只應用了非常小的一部份。
***，我把之前講的這些都融進了一個產品HDM，全稱是混合云數據庫管理平臺。Gartner有一份報告指出，到2020年的時候，有85％的企業會使用混合云的架構。這和我們的判斷是一致的。之前提到過，阿里巴巴集團就是一個超大的混合云，所以我們推出了HDM，幫助企業把混合云數據庫架構打通。
HDM主要提供兩大功能，一是統一管理，不管是云上的還是云下還是其他云的數據庫，都可以進行統一管理與診斷。二是彈性擴展，一鍵把數據庫上云也不再是夢想。在數據庫層消除本地IDC和云的區別。
在提出HDM后一段時間里，我一度認為這基本上就是數據庫服務的未來了。但這些年，不管是數據庫領域，還是運維領域，都在飛速的向前發展，我們似乎又到了一個技術集中爆發的時間點。一方面是新的軟硬件技術，比如容器、高速網絡，機器學習，另外一個是云計算的發展，都在不斷的推動我們向前，提供更好的交付及服務。
3. 通往智能之路:自治數據庫平臺
在數據庫領域，有自治數據庫、智能數據庫，在運維領域，有AIOPS等等。這對數據庫運維來說到底意味著什么，我們結合過去和現在的情況，提出了自治數據庫平臺。這個定義是很多人一起討論了很久才定出來的。
首先是平臺的能力和目標，我們希望能做到自動駕駛，簡單的說就是不需要人的參與。要做到這個，就要具備自感知、自決策、自恢復、自優化四大能力。其次是平臺能為數據庫賦能，今天的現狀是我們用了很多種數據庫，不能對每個數據庫有很高的要求才能自治，我們可以進行能力分級。
我們也有非常明確的業務目標，這是阿里數據庫事業部掌門人公開的目標：在2020財年結束的時候，阿里集團85％的數據庫實例要能做到自動駕駛。我為此定了兩個評估指標，一是沒有人接收這些數據庫的報警，另一個是穩定性要達到99.995%。
目標有了，具體怎么實現？首先，自治是一個技術的量變到質變的過程。在過去的一段時間里，我們應用了大量的新技術，包括存儲計算分離，大數據處理與機器學習等等，掌握好這些技術是自治的基礎。
有了這些技術，還需要革新我們的思路，就像今天的電動汽車或自動駕駛，由傳統廠商來制造，都顯得差強人意，這一方面是思維定勢，另一方面則是有它的歷史包袱。
我們需要破除這些，比如我們之前的數據、運維、資源都是分割開來的，所謂自動處理都是先接收一個報警，然后根據報警的內容做自動化，這明顯沒辦法形成一個統一的整體。今天我們需要先去構建整個骨架，然后讓數據、算法去豐富、去潤滑整個系統。
另外還需要專業知識。數據庫是高度專業的系統，之前可能由DBA、內核開發人員去調校，靠數據，靠試錯，靠經驗。這些知識如何精確化、數字化下來，讓系統也具備這些能力，是我們要去努力的事情。
***，重要的一點是要持續提升原有的基礎能力，不是說我們今天智能化、自治化就是數據和算法，其他基礎能力同等重要，比如OPS，我們提出了一個ad-hoc執行：假如決策模塊作出了一個決策是全網內存水位高于95％的數據庫實例做一個action，你要能夠很快執行下去。
我們目前正在向這個方向前進，預計很快我們就會對一部份數據庫實例實施自治，歡迎有興趣的同學加入一起建設，共同迎接自治時代的到來。
