2013年，雲梯1實現空間優化與跨機房集羣擴展，雲梯2單集羣規模從1500臺升級到5000臺，同時跨集羣擴展的5K項目順利取得階段性成果，阿里成爲第一個獨立研發擁有這類大規模通用計算平臺的公司。當時，雲梯一、雲梯2，再加上已上線的生產集羣，阿里總體集羣規模已超過萬臺。迄今爲止，全球範圍內，只有少數幾家公司擁有如此規模的自主知識產權的集羣。咱們很是幸運，可以運維和管理如此大規模的生產集羣。但短期大規模快速膨脹的現狀，確實也爲運維工做帶來了巨大的挑戰。面對這些挑戰，咱們不只迅速實現了自動化運維，還進行了數據化管理的轉型。數據庫
服務器數量激增，要求提高全局掌控能力
傳統的運維人員一般只面對幾十或者上百臺的服務器，規模不會太大，並且相對應用來講，每臺機器都是一個獨立節點。但在大規模分佈式集羣中，工做任務明顯不一樣：首先，運維人員面臨的服務器動輒就是三五千臺甚至上萬臺，量級大幅提高；其次，分佈式操做系統提供存儲、CPU調度能力、內存使用、網絡等功能，是基本資源的包裝整合，從邏輯上看，至關於一臺計算機；第三，基於分佈式系統開發的應用至關於一個分佈式數據倉庫，用戶能夠在上面作ETL處理、SQL查詢、數據導入導出等基本操做，以及實現一些MATLAB、統計軟件等功能。所以，與傳統運維相比，大數據運維人員要有更強大的總體把控能力，包括對機房網絡、帶寬、硬件、服務器的性能進行優化，熟悉飛天和Hadoop的上層應用，實現數據分析等，作到對各個方面的狀況瞭如指掌。緩存
以飛天5K項目爲例，因爲單集羣的服務器規模是5000臺，基本已獨佔1個機房，因此須要對總體機房的情況（包括網絡、空調、維修和現場應急狀態響應等），服務器，操做系統和上層應用進行全面的掌握。爲了實現這個目標，咱們先是作了屢次演練來驗證集羣的穩定性，包括部分網絡設備關機，整機架服務器斷電，Master服務器隨機挑選一臺斷電等。準備充分後，又作了一次「前所未有」的Failover測試――總體機房斷電。演習當天，飛天及MaxCompute的恢復過程大概歷時3個小時，整個演習過程當中無數據丟失。通過此次壓力測試，咱們全面瞭解了系統的穩定性狀況，鍛鍊了運維團隊在最短期內恢復整個集羣的協做能力，積累了更好的保障用戶穩定運行的寶貴經驗。服務器
實現系統的自我保護和自動化修復
在作5K項目測試時，一個測試做業因爲用戶使用不當致使盤古存儲服務器文件數突增3000萬個，形成存儲Master服務器繁忙，總體系統處理能力大幅下降，對系統形成了不小的衝擊。雖然咱們發現這一問題後馬上作了相應的限制處理，但此類問題仍是引起了咱們的思考。通常來講，出現如此問題時，開發人員和設計人員會將緣由歸結爲用戶不會使用或使用不當。言下之意就是，產品層面很難避免，也沒法完全解決。但站在運維角度來看，應該有更好的解決方案，一方面不能由於用戶的一個做業失常而中止服務；另外一方面，也不能老是依靠「人肉「救火。系統應該具有自我保護能力，這也是產品要努力的方向之一。網絡
此外，大規模分佈式系統選用的都是低成本服務器，設備損壞很常見。要實現對整個系統（包括飛天、MaxCompute、Linux、硬件和網絡等）的運維，就須要作好「軟硬件故障成爲常態」的準備，一旦發生異常狀況，能當即實現自動閉環處理，無需人工干預。爲此，阿里的運維和開發團隊合做研發了一套異常故障自動化處理系統――華佗。目前華佗系統已具有自動處理基本硬件和服務異常等常見問題的閉環處理能力，而且還在持續完善當中（具體可參閱《走近華佗，解析自動化故障處理系統背後的祕密》一文）。數據結構
大規模與精細化的平衡
當運維的服務器達到數千臺甚至上萬臺時會遇到諸多挑戰，如硬件配置的差別化、用戶數和任務數的急劇膨脹、大壓力下的邊界效應、小几率事件被觸發等。在這個前提下，咱們依然成功知足了諸如快速部署、自動化運維、監控報警、Log分析和精細化計量等運維要求，主要從如下三點着手。併發
提高系統化的基礎環境管理能力運維
這個問題看起來很簡單，就是要保證線上幾萬臺機器的環境一致或是能實現咱們想要的配置。但若是不提供底層的應用（如BIOS、FW等），僅是操做系統層面（如網卡驅動版本、系統參數的配置、基礎軟件的版本等），衆多品類就很難統一，尤爲是當硬件基礎發生變化的時候。舉個簡單的例子，假如一臺機器的某塊硬盤壞掉了，系統應用須要可以自動將損壞的硬盤下線。後臺的監控程序會進行輪詢，直到發現這塊壞盤，並將這塊盤從系統裏下線，進行修復處理後，再嘗試可否加回集羣。若是不能，就說明這個盤可能完全壞了沒法修復，系統就會自動提交報修工單，整個過程無需人爲干預。現場工做人員接到報修工單後，能夠從容安排時間，統一更換壞盤。新的硬盤裝好後，系統會自動識別並添加到服務中。若是故障的是系統盤，只要完成更換，系統就會自動觸發安裝和部署。同時要保證全部的驅動版本、FW、系統參數和軟件版本等作到同步一致地去Push。可見，在這個故障的整個處理過程當中，只有更換硬盤這個動做須要人工介入。若是有服務器重裝的需求，咱們會每週或每個月按期整理，啓動自動化的部署觸發，對整臺機器進行初始化處理，讓系統處於應用部署狀態，機器就會找到本身的兄弟節點去作一次克隆，恢復成跟線上的「兄弟姐妹」如出一轍的狀態，而後再上線。這個過程也是全自動完成的，惟一的人工介入就是點擊觸發命令。分佈式
大規模集羣快速自動化部署模塊化
你們知道在運維工做中有很大一部分是部署升級。而對於大規模集羣來講部署升級這部分工做尤爲重要。在飛天5K項目中，集羣機器數量短時間內由1000多臺直接擴展到5000臺。這時，發現老的部署方式基本沒法自動完成5000臺服務器部署。同時按老的方式作一次冷升級須要4~5個小時，這是應用沒法接受的。因而，咱們在分佈式部署工具大禹上也作了許多工做，提升了飛天部署效率，支持運維人員定製本身的部署流程，管理集羣的基本信息，同時還提供了豐富的工具集，包括文件分發工具、遠程執行工具、集羣信息管理工具和集羣縮容擴容等。咱們從新定義了應用binaryconf的目錄結構，同時分離配置和binary部署，爲配置中心統籌全部配置留出接口；分離應用binary和數據結構，在確保版本快速切換同時，保證了應用數據連貫性提供快速回滾的方案；輕量化對數據庫的依賴，角色資源信息採用讀取本地緩存方式；模塊化部署，同時支持交互式與非交互式部署。並且最主要的是，在部署時，咱們對應用binany分包傳輸方式作了調整，新開發了一套多點分佈併發傳輸工具，由之前單點傳輸速度越快越好，轉變爲多點精確控制流量下按預期傳輸。最終在整個5K項目結項時，整個集羣冷部署升級時可以將服務中止時間控制在20~30分鐘。工具
自研的簡單日誌服務SLS
咱們如今面對的大規模分佈式系統比以往任何系統都要複雜，系統自己有很是多的組件，每一個組件又有各自的Log數據，而不少Log之間又相互關聯，量大且目標多。在飛天5000臺服務器的環境下，大約有5000多個併發做業須要實時計算併發度、運行狀態、使用Quota等指標。從輸入的源數據來看，整個集羣須要實時分析的性能數據產出速度大約爲65MB / s，日誌數據的量更會提高一個數量級。須要同時匯聚的種類和維度不少，大到機器，小到做業和文件都須要有不一樣的視角能切入探索，定位細節根源。並且這些Log都是分佈在每臺Slave機器上的，須要統一地彙總收集進行分析。爲此，咱們使用了阿里雲自研的簡單日誌服務（SLS）來知足這些複雜的需求。SLS的主要功能有如下幾點。
- 實時收集AuditLog，監控全部操做的QPS和執行結果。
- 監控每種操做的等待延時與執行延時。
- 監控每一個文件、請求和Session客戶端執行生命週期。
- 經過FileID、文件名和操做類型進行實時分析，對整個文件的操做生命週期監控。
雖然syslog也作了一系列分析，但因爲它散佈在各個機器上，查找和定位很是不方便，而經過SLS能夠像單機同樣查找集羣中的問題：
- 整個集羣是否有特定錯誤；
- 天天針對segfault、oom和cgroup進行離線統計，根據具體segfault事件定位具體的內容和機器，如圖1所示。
經過SLS的各項指標和Log分析，對集羣的總體性能、QPS和流量等是否符合預期、做業 / 文件 / Slave上的存儲單元的生命週期是怎樣的，這些宏觀狀態和微觀細節都有完整的把握, 進而幫助咱們全面掌握分佈式系統的狀況。這項簡單日誌服務SLS不久前已經過阿里雲對外公測，每一個用戶能夠免費建立1個項目，並能使用不超過10M / s的寫入流量。
不斷完善的AliMonitor監控系統
面對上萬臺機器，好幾十個模塊，幾十萬個監控項，想要了解哪些機器監控項缺乏、哪些機器監控項異常、今天有哪些監控項報警、報警了多少次、團隊中每一個人天天收到多少報警、哪些是能夠系統自動處理不報警的等，都須要從監控數據入手，真正對整個平臺的監控有直觀而全面的瞭解，並在數據的指導下持續完善監控系統。
大規模的互聯網公司都極其詳細地定製化監控需求，阿里也不例外，咱們基於多年的運維經驗自主開發了一套監控系統AliMonitor，而且根據業務需求不斷進行優化和完善。Alimonitor是一套統一的分佈式監控平臺，支持系統監控、網絡監控、客戶端監控、容量監控、趨勢監控等，能自動添加基本監控，對服務器、虛擬機、應用VIP、網絡設備、Java應用等能提供準實時預警、報警，從數據採集到發出報警僅須要5秒鐘，讓運維人員第一時間掌握服務的健康情況。同時，它還具有多種故障預測及發現方式、豐富的數據圖表展現、容量規劃和報警，以及視圖的定製等功能。
開發和運維須要更加緊密合做
和傳統的業務系統相比，分佈式系統規模大和複雜性高，須要開發和運維更加緊密地合做。從運維人員的角度來看，運維就是對線上生產系統負責，是線上系統的Owner，要全面且深刻地瞭解產品。從開發人員的角度來講，若是對運維工做一無所知，那麼也很難開發出可靠的產品。所以，若是開發人員和運維人員之間存在壁壘，顯然會大大影響產品的穩定性。須要注意的是，這不是要模糊開發人員和運維人員的職責，雙方仍然要保持明確的分工，但在技術技能上，雙方應該更加靠近。例如，在飛天5K項目中，運維人員和開發人員緊密合做，用最短的時間開發完成了自有的大規模部署系統（大禹）和異常故障自動化處理系統（華佗）。並且在共同工做中，雙方都收穫甚豐。
結語
對於阿里這種規模的互聯網公司而言，隨着體量愈來愈大，用戶數量和基礎設施投入都在快速膨脹，數據也在呈幾何倍數增加。所以，在運維工做上已很難找到其餘企業的成功經驗來借鑑，但又不能憑空揣測解決方案，由於一旦判斷失誤，就會給公司形成巨大的損失。在這種狀況下，咱們深入感覺到只有一條通路：經過對真實數據進行分析和預測，將判斷失誤的機率降到最低。咱們相信，只要數據真實而且挖掘得足夠深刻，必定能找到最優的解決方案。例如，在平常運維中，咱們已能夠收集到不一樣通道的數據，如服務器溫度、負載、磁盤、應用情況等，並且數據種類和數量都在不斷增長。若是可以找到其中的聯繫並快速分析，將會給咱們的工做帶來更大變化。而基於技術分析優化運維水平，將是一個值得持續探究的課題，也是咱們團隊一個比較大的挑戰。