摘要:反正在阿里巴巴,很多的運維人員都說了,我們每年的工作中有一項不用寫的工作就是搬遷。未來我們確實相信阿里巴巴,可能在未來搬遷會相對更少一點,我們認為不能讓搬遷成為阿里巴巴運維團隊的核心競爭力。以上,正是阿里巴巴的運維團隊所覆蓋的五個領(lǐng)域。
隨著大數(shù)據(jù)、機器學習和 AI 技術(shù)的飛速發(fā)展,智能化運維成為運維的熱點領(lǐng)域。Gartner 的報告宣稱,到 2020 年,將近 50% 的企業(yè)將會在他們的業(yè)務(wù)和 IT 運維方面采用 AIOps,遠遠高于今天的 10%。盡管 AIOps 還是一個新名詞,但它無疑代表了運維未來的一種趨勢。
智能化運維的終極目標,就是將運維人員從繁瑣的工作中解放出來,提高整體運維效率,降低運維成本,實現(xiàn)業(yè)務(wù)系統(tǒng)的高可用性。
運維環(huán)境的異構(gòu)和復(fù)雜化,導(dǎo)致日常運維工作需要付出的人力、時間成本越來越高。 大約兩年前,智能化運維開始被大家廣泛關(guān)注,隨著大數(shù)據(jù)分析、APM、智能異常檢測、機器學習等技術(shù)的興起和逐漸成熟,運維需求也逐漸向自動化和智能化過渡。從最初級運維發(fā)展到現(xiàn)在智能化運維,大致經(jīng)歷了四個階段:腳本時代——工具時代——自動化時代——智能化時代。
目前業(yè)界真正的智能化運維的落地實踐其實并不多,大多還是停留在自動化甚至人工化階段,然而智能化運維是大勢所趨,對于大公司來說,更是尤為重要。以下整理自 2017 上海 CNUTCon 全球運維技術(shù)大會上,阿里巴巴研發(fā)效能團隊負責人,阿里研究員畢玄的演講《智能時代的新運維》。
1、阿里的運維體系承載著怎樣的責任?
阿里的運維體系介紹
阿里的運維團隊,主要覆蓋五個層面。
?一.資源的規(guī)劃與支付是運維的基石
整個運維團隊需要負責資源的規(guī)劃、資源的交付。
Quota 管理: 比如我們會跟業(yè)務(wù)團隊做一些預(yù)算的管理,對于每個業(yè)務(wù)團隊首先需要有預(yù)算。只要你有預(yù)算,運維團隊一定會把資源交給你,沒有預(yù)算一切免談。
規(guī)劃: 比如阿里每年的雙十一交易,業(yè)務(wù)團隊要給出下一年的交易額將做到多少,至于背后需要增加多少的機器量,業(yè)務(wù)團隊根本不關(guān)心。所以需要運維團隊來做從業(yè)務(wù)需求到資源的轉(zhuǎn)化和規(guī)劃,這對于公司來講非常重要,因為意味著最終我在基礎(chǔ)設(shè)施上要投多少錢,還有節(jié)奏的控制。
采購: 當規(guī)模大了以后,怎么樣合理規(guī)劃資源的數(shù)量和交付節(jié)奏是非常重要的,比如 5 月份采購這批機器和 6 月份采購這批機器,是完全不同的概念。還需要資源的采購,比如 SSD 采購緊張,供應(yīng)量不夠。通常大公司會有更多的渠道獲得更好的供應(yīng)量,小公司就會很困難。怎么做好供應(yīng)鏈控制是非常重要的。
資源調(diào)度: 對于資源團隊來講,調(diào)度也很重要,我們交出去的機器是怎么樣的交法,怎么保證可用性、穩(wěn)定性, Bootstrap 等,每個業(yè)務(wù)都有自己的規(guī)劃,按照業(yè)務(wù)需求怎么把整個業(yè)務(wù)環(huán)境全部交給業(yè)務(wù)方。阿里目前就遇到了很大的挑戰(zhàn),比如在國際化的擴張上,我們可能這個月需要在這里建個點,下個月需要在另一個地方建個點,怎么快速的完成整個資源,不僅僅是機器資源的交付,還有軟件資源的交付,是非常重要的。我們現(xiàn)在在擴展東南亞的業(yè)務(wù),怎么樣在東南亞快速的完成整個軟件資源的交付,對于我們的競爭是非常重要的。
二.變更 是運維不可避開的坑
對于運維團隊來講,變更也是經(jīng)常要做的部分,變更信息的收攏,做應(yīng)用層面的變更,基礎(chǔ)網(wǎng)絡(luò)的 IDC 等等。
三.監(jiān)控 預(yù)測潛在的故障
監(jiān)控對于阿里來講主要分為基礎(chǔ)、業(yè)務(wù)、鏈路,在監(jiān)控的基礎(chǔ)上要去做一些報警等。
四.穩(wěn)定性 是不少企業(yè)追求的目標
穩(wěn)定性這個概念我們以前認為針對的是大公司,因為它可能會影響到大眾的生活,會比較敏感。但是現(xiàn)在新型的互聯(lián)網(wǎng)公司,如外賣,ofo、摩拜等,它的穩(wěn)定性要求比以前很多創(chuàng)業(yè)型公司更高,因為它有在那個點必須能用,如果不能用,對用戶會有直接的影響。所以穩(wěn)定性可能在整個運維行業(yè)會得到越來越高的重視,但是對于很多中小型公司,穩(wěn)定性的投入相當大的。
五.一鍵建站 讓規(guī)?;辛ΡU?/p>
像阿里在穩(wěn)定性上主要會去做多活體系的建設(shè),然后故障的修復(fù)、故障定位,然后還有一套全鏈路的壓測。規(guī)?;呛芏噙\維團隊很痛苦的事情,可能今年機器在這個機房,明年你的基礎(chǔ)設(shè)施團隊可能告訴你,這個機房不夠用了,我們要換個機房。反正在阿里巴巴,很多的運維人員都說了,我們每年的工作中有一項不用寫的工作就是搬遷。雖然基礎(chǔ)設(shè)施團隊會承諾說三年內(nèi)不會再搬,可是到了明年他會跟你說,由于某些原因我們還是再搬一下,搬完之后三年不會讓你再搬。但是從我們過去發(fā)展的三年,每年都在搬。未來我們確實相信阿里巴巴,可能在未來搬遷會相對更少一點,我們認為不能讓搬遷成為阿里巴巴運維團隊的核心競爭力。
我們在規(guī)?;瘜用孀隽撕芏嗍虑?,比如說我們做了一鍵建站,對于阿里來講,我們對機器資源的交付時間,要求會越來越高。比如說雙十一,是提前一個月交付資源還是提前兩個月還是提前三個月,對我們來講付出的錢是完全不一樣,而且可能相差非常大。
所以,技術(shù)層面能不能更好的把這個時間縮短,是非常重要的。所以一鍵建站的重要目的就是這個,每年雙十一我們都會拓展出非常多個站點,通過一鍵建站快速完成整個過程。搬遷就是我說的,反正我們每年都要搬,那我們應(yīng)該把搬遷這套系統(tǒng)做得更好。還有騰挪,阿里很多時候因為需要做一些業(yè)務(wù)資源的復(fù)用,較好是有一個機柜,這個時候怎么更好完成挪的過程也是很麻煩。
我們還需要做一些單元的調(diào)整,因為對阿里的交易系統(tǒng)來講是有單元的概念的,我們怎么更好的控制一個單元內(nèi)機器的比率是非常重要的。一個單元的機器數(shù)可能是比較固定的,那如果比率搭配不好,就意味著瓶頸點會非常明顯。
以上,正是阿里巴巴的運維團隊所覆蓋的五個領(lǐng)域。整個運維體系的演進過程,差不多都是從最早的腳本到工具到自動化,到未來的智能化。
2、從工具化到自動化過關(guān)斬將
從工具化到自動化這個層面,過程并沒有那么的容易,以及對整個行業(yè)來講,目前更多的工作仍然是在探尋自動化,怎么樣讓自動化真正的被實現(xiàn)得更好。
這個行業(yè)的發(fā)展跟其他傳統(tǒng)的軟件,標準的軟件研發(fā)行業(yè),我覺得很不一樣。比如說阿里從工具化到自動化這個過程中,我們認為工具化,其實挑戰(zhàn)相對小,即使傳統(tǒng)的運維人員也很容易寫一些工具,比如用 Python 去寫更多的工具體系。但是如果你的工具最重要變成能夠到自動化這個階段,就意味著對工具的要求會越來越高,比如說工具的質(zhì)量,如果你寫出來的工具經(jīng)常有問題,規(guī)模一大就扛不住,這個時候?qū)τ诖蠹襾碇v慢慢會越來越失去信任感。最后會很難完成這個過程。
運維團隊轉(zhuǎn)型研發(fā)團隊 組織能力是較大的壁壘
阿里過去走這條路的過程中,我們覺得較大的挑戰(zhàn)是組織的能力問題。運維團隊怎么樣更好的完成朝研發(fā)團隊的轉(zhuǎn)型,這個過程對于很多運維團隊來講都是巨大的挑戰(zhàn)。對于一個組織來講怎么完成這個過程也是非常重要的。
我想很多團隊都有這個感受,工具研發(fā)的團隊跟做運維操作的團隊之間,很容易產(chǎn)生一些沖突等等。所以阿里巴巴在走這個過程的時候,思考的核心就是怎么讓一個運維團隊真正從組織能力上,演變成我們所需要的更好的團隊。
阿里在走這條路的時候,走了四個過程。這個過程阿里在不斷的摸索,最終到現(xiàn)在為止我們認為阿里的方式相對來講還是不錯的。我們最早跟大部分公司一樣,有一個專職的工具研發(fā)團隊和一個專職的運維團隊。工具研發(fā)團隊做工具,做出來給運維團隊用。這個過程中容易出現(xiàn)的最明顯的問題就是工具做完了,運維團隊說這個工具太難用了,不符合需求。要么就是運維團隊執(zhí)行的過程中,經(jīng)常出問題,出問題還要找工具研發(fā)團隊來幫忙查問題在哪里。本來運維幾行腳本全部能搞定的問題,結(jié)果還要依賴工具團隊。慢慢這個局面越來越難突破,很難改變。
所以阿里后來做了一個嘗試,既然兩個團隊很難做很好的結(jié)合,那有一種方式是工具研發(fā)團隊做完工具以后,比如說做了一個發(fā)布,做完這個功能以后,這個運維工作就徹底交給工具研發(fā)團隊,不讓運維團隊做了,運維團隊就可以做一些別的事情。這個模式看起來就是逐步接管的模式,讓工具研發(fā)團隊逐步解耦。
這個做了一段時間,碰到的較大問題還是組織能力問題。對于運維工具來講,質(zhì)量怎么做到很高,運維好像很容易做的樣子,但是實際上運維工具相當難做,它的復(fù)雜度比在線業(yè)務(wù)更大,就是它不是邏輯上的復(fù)雜,更多的是環(huán)境層面的復(fù)雜。因為比如會涉及網(wǎng)絡(luò)涉及服務(wù)器涉及機房等等,這跟業(yè)務(wù)完全不一樣。所以做了一段時間之后,我們覺得這還是一個問題。
將工具的研發(fā)和運維融為一體 突破組織能力問題
后面我們做完這輪之后又開始做另外一個方向的嘗試,讓工具的研發(fā)團隊和運維團隊做一個融合。所謂的融合就是把很多工具研發(fā)的人分派給運維團隊,到運維團隊去做。我們期望通過工具研發(fā)的人帶動整個運維團隊轉(zhuǎn)變成研發(fā)型團隊。這是我們的思路。
阿里巴巴在走前面這三步的時候,大概花了近一年半左右,意味著這其中我們大概做了三輪組織結(jié)構(gòu)調(diào)整。因為我們認為這些都是要有組織層面的保障才能被實現(xiàn)的。
DevOps 是如何真正落地的
去年 6 月,我們做了一個較大的組織結(jié)構(gòu)調(diào)整,把日常的運維工作交給研發(fā)做,研發(fā)自己會把日常的運維工作都做掉。但并不是說所有運維工作,現(xiàn)在仍然有一個做運維的團隊,這個運維團隊相對來講更不一樣,跟以前有非常大的不同。
我們認為這是 DevOps 真正的被徹底的執(zhí)行。因為這個好處是,日常的運維工作交給了研發(fā),運維團隊轉(zhuǎn)變成研發(fā)團隊這個過程非常困難,其實不完全是能力上的差距,更大的原因是,運維團隊要承擔非常多的日常雜活,尤其像集團性的公司,不管是阿里、騰訊、百度都一樣,集團性的公司多數(shù)支撐的 BU 都是無數(shù)個。你一個人支撐二十個 BU 一個 BU 里面一天有一個人找你,你一天就不用干別的活了,你一天就在跟他們不斷的聊天,做操作,嘴里又叫著這個團隊要升級,要做組織升級,要轉(zhuǎn)變成研發(fā)團隊,實際上就是逼別人走向了一條死路。
所以我們認為,谷歌的做法,谷歌在 SRE 那本書提到的是,會強制留 50% 的時間給研發(fā)團隊做研發(fā)工作。這個說實話,在大多數(shù)公司很難執(zhí)行這個政策,除非運維團隊跟研發(fā)團隊有非常強的話語權(quán)。但這個很難。所以阿里的做法我認為更為徹底,阿里告訴研發(fā)團隊,以后日常運維的工作不要找運維團隊,自己干。這可能粗暴了一點,在運維體系還沒有準備得很好的情況下做了這個事情,所以后面相對來講也導(dǎo)致了問題,比如說運維工具四處建設(shè)、重復(fù)建設(shè)等等現(xiàn)象。
但是從組織層面上來講,我們很欣慰的看到,在做完這輪組織調(diào)整過后的一年后,運維團隊的大多數(shù)人更多的時間是投入在研發(fā)工作上,而不是投入在日常的雜事上。我們看到了一個團隊的能力,在經(jīng)過這一輪的調(diào)整得到了非常好的升級。而這對于組織來講是較大的利好。所以我們認為,這種模式是阿里現(xiàn)在更為推崇也更為看好的一個方向,這樣整個運維團隊將專注在我剛才講的五個部分的系統(tǒng)層面的研發(fā)以及建設(shè)上,而不是雜活上。這是阿里從工具化到自動化,最主要是這樣的一個過程。
成功率是衡量自動化運維的關(guān)鍵指標
對于自動化來講最重要的問題是成功率,比如我們看所有的運維操作中,我們最關(guān)心的指標是成功率。比如一個運維系統(tǒng)里面的功能,在一個星期內(nèi),比如說會用幾十萬次,我們只關(guān)注成功率能不能做到 4 個 9 以上,否則算一下工單數(shù)就懂了,這個運維團隊得有多少人支持這件事情,這些人又沒有時間去干研發(fā)的活,又要投入大量的精力做支持性的工作。所以我們在成功率上要做到非常高的保障,運維系統(tǒng)我們以前看過是面臨較大的挑戰(zhàn),我以前的背景全部是做在線業(yè)務(wù)型的系統(tǒng),比如淘寶的交易等等。
后來我們發(fā)現(xiàn)運維系統(tǒng)有個較大的不同在于,運維系統(tǒng)對于成功率的追求比在線業(yè)務(wù)型系統(tǒng)更高一些。在線業(yè)務(wù)型系統(tǒng),比如說我在訪問后面一個地方有問題的時候,我們會選擇盡快把這個過程失敗掉,而不是把時間不斷的拖長以及不斷的試錯。在線系統(tǒng)會更加快的把錯誤往外拋。但是對于運維系統(tǒng)來講如果也這樣做,就意味著這個成功率非常難保障。所以運維系統(tǒng)要有更好的思考,怎么保障一次運維操作,這背后可能有幾十個系統(tǒng),而且多數(shù)是無數(shù)的團隊寫的,阿里以前碰到的情況就是無數(shù)個系統(tǒng),質(zhì)量層次不起,什么都有。怎么保證在這么復(fù)雜的環(huán)境下,保證對外的,對用戶層面這個成功率可以做到很高的。這是一個很大的問題。
規(guī)模帶來的挑戰(zhàn)也是不容小覷
隨著規(guī)模的不斷增長,所有開源類型的運維類的系統(tǒng),在規(guī)模化,當你的機器規(guī)模等等其他規(guī)模上升到一個程度以后,通常來講都會面臨非常巨大的挑戰(zhàn)。阿里巴巴所有的這種類型的系統(tǒng),我們論證都是自己做是比較靠譜。較大的原因是規(guī)模,規(guī)模上去以后會遇到很多問題。像代碼托管、代碼編譯什么的,以前認為不會有太大的問題,事實證明規(guī)模上來以后這些里面全都是問題。我們也要投入非常大的精力去做規(guī)模方面的解決。
所以我覺得,阿里從以前的工具化走向更加自動化的過程中,我們探討的核心問題就是能不能有一個非常好的組織去完成這個過程。能讓運維的團隊更加轉(zhuǎn)型向 DevOps 這樣的方向。所以我們一直說,我們一直很糾結(jié)運維團隊到底應(yīng)該叫什么名字,我們一致認為,運維研發(fā)團隊,我們覺得不大對,你的主要的活其實是干研發(fā)而不是運維。但是叫研發(fā)運維又有點奇怪。后來阿里巴巴基本上是叫研發(fā)團隊。因為我們認為運維的研發(fā)團隊和在線業(yè)務(wù)的研發(fā)團隊沒有本質(zhì)區(qū)別,都是做研發(fā)的,只是一個在解決運維領(lǐng)域的業(yè)務(wù)問題。剛才講的五個層次,運維領(lǐng)域的業(yè)務(wù)問題,也是業(yè)務(wù),沒有什么區(qū)別。在線業(yè)務(wù),比如解決交易的問題,解決其他問題,這是完全一樣的。兩個研發(fā)團隊沒有本質(zhì)區(qū)別。
所以這個過程,阿里經(jīng)過過去這一年的組織調(diào)整以后,我們看到整個自動化層面,阿里有了很好的進展,但是離我們的期望還要更加努力繼續(xù)往前演進。
3、阿里巴巴在智能化領(lǐng)域的探尋之路
現(xiàn)在智能化這個話題特別火熱,就像我們說,AI 這個名字興起的時候,我們忽然發(fā)現(xiàn),阿里巴巴所有的業(yè)務(wù)都講 AI+ 自己的業(yè)務(wù),被所有人狂批一通。我們要想清楚,具不具備 AI 化的前提,可能前提都不具備就不斷探討這個名字。因為業(yè)界在不斷的炒熱非常多的名詞,讓大家去跟隨。
自動化是智能化的前提
對于我們來講,我們認為,比如說就像我對這個團隊,我自己的團隊講的一樣,我認為智能化最重要的前提是,一是自動化。如果你的系統(tǒng)還沒有完成自動化的過程,我認為就不要去做智能化,你還在前面的階段。智能化非常多的要求都是自動化,如果不夠自動化,意味著后邊看起來做了一個很好的智能化的算法等等,告訴別人我能給你很大的幫助,結(jié)果發(fā)現(xiàn)前面自動化過程還沒有做完全。
一個最典型的 case,阿里巴巴以前一直在講,我們認為資源的搭配上,其實可以做得更好。比如說你半夜流量比較小,白天流量比較大,你能不能更好的做一些彈性,把資源釋放出來去干點別的,然后白天再把它補起來。這從算法層面上并沒有那么復(fù)雜,從算法層面做到一個簡單的提升是很容易做的。所以,當時我們就有很多團隊做了一個東西,可以做到這一點。結(jié)果等到落地的時候發(fā)現(xiàn),業(yè)務(wù)不能自動伸縮。如果你想,比如說有些機器上面負載特別高,有些機器特別低,我們希望負載能拉得更均衡,在線業(yè)務(wù)更加穩(wěn)定化,做一個算法,比如說背包,更好的去做組合,結(jié)果就是這個東西做完了,給出了建議說較好這個應(yīng)用調(diào)到那臺機器,那臺應(yīng)用調(diào)到這臺機器。給完之后業(yè)務(wù)團隊看了一眼,我們不干,因為干這些工作全部要手工干,你還每天給我建議,更不要干了,每天就來調(diào)機器了。
所以首先你要想明白你的前提,自動化,具不具備自動化的能力,不具備的話沒有必要在這方面做過多的投入。
數(shù)據(jù)結(jié)構(gòu)化是智能化的源動力
目前 AI 領(lǐng)域基本是靠暴力,暴力破解,未來可能有別的方向,但是目前的 AI 基本上是靠大量數(shù)據(jù)的積累去尋找一個東西出來,所以它一定需要有大量的數(shù)據(jù)積累,數(shù)據(jù)包括非常多的東西,對于運維來講,可能基礎(chǔ)層面的數(shù)據(jù),機器的數(shù)據(jù),運維變更的數(shù)據(jù),上面還有一些場景化的數(shù)據(jù),比如你解決故障,有沒有更好的結(jié)構(gòu)化的收集數(shù)據(jù),這是非常重要的。數(shù)據(jù)這個層面比較難做的在于, ? ? ?在最開始階段,多數(shù)公司的運維數(shù)據(jù)都是不夠結(jié)構(gòu)化的,結(jié)構(gòu)化不會做得那么好,當然會有結(jié)構(gòu)化,但是結(jié)構(gòu)化的因素不會足夠好。
就像阿里巴巴在講,我們在電商領(lǐng)域 AI 化,我們較大的優(yōu)勢就是不斷對外部講,我們擁有的是結(jié)構(gòu)化的商品數(shù)據(jù),其他公司最多從我們這里扒結(jié)構(gòu)化的商品數(shù)據(jù)。你扒過去之后還要自己分析,并且做商品結(jié)構(gòu)的調(diào)整,這非常困難。但是阿里巴巴自己天然,所有人都會幫你把結(jié)構(gòu)做得非常好。所以對運維來講也是一樣,如果你想在智能化上有更多的突破,數(shù)據(jù)怎么更好的做結(jié)構(gòu)化,是一個非常大的挑戰(zhàn)。你很難想清楚。這兩個地方是我覺得首先要想清楚的。
智能化最適合的運維場景
從目前來看,對于運維場景來講,智能化特別適合解決的問題就兩種,對于所有行業(yè)好像都差不多,第一是規(guī)模,第二是復(fù)雜。規(guī)模就意味著,我有很多的機器,在很多機器中我要尋找出一個機器的問題,這對于,因為規(guī)模太大了,這時候?qū)τ谟脗鹘y(tǒng)的方式,將非常難解決這個問題?;蛘吣阋度敕浅4蟮娜肆Φ鹊?,有點得不償失。規(guī)模上來以后怎么更好的解決規(guī)模的問題,智能化會帶來一些幫助。第二是復(fù)雜,比如說你的應(yīng)用從原來的一個應(yīng)用變成了幾千個、上萬個、幾十萬個,這時候你要尋找出其中哪個應(yīng)用的問題,將是非常復(fù)雜的問題。所以復(fù)雜度的問題是人類用人腦非常難推演的,但是機器相對來講是更容易做的。這是阿里有些團隊希望嘗試智能化的方向,通常我們會看是不是在前面的這些前提條件上都具備。如果都具備了,那可以去探索一下。所以我講,阿里其實目前處于整個智能化運維的探索階段,而不是全面展開階段。
阿里巴巴智能化運維五步走
簡單講一下我們在各個領(lǐng)域目前在智能化這個領(lǐng)域,在運維這五個領(lǐng)域,對于我們講,智能化我們看到的一些可能性,包括我們正在做的事情。
一.資源的重點是成本
1. 基礎(chǔ)設(shè)施選型
對于資源這一塊,整個公司層面更為關(guān)注的問題,就是成本。你交付的資源具不具備較低的成本,這個智能化確實可以給非常大的幫助。比如第一點,怎么更好的規(guī)劃這家公司機型、網(wǎng)絡(luò)和整個數(shù)據(jù)中心,這為什么要用智能化的手段在于,一個數(shù)據(jù)中心的選址來自非常多的因素,除了政府層面的政策因素之外,還有很多其他因素需要考慮,比如說氣候等等各種各樣的因素,都需要在這個階段去考慮。你需要通過大量數(shù)據(jù)的積累來分析,比如在中國,在海外,到底有那些地方是對你的業(yè)務(wù)發(fā)展策略來講最適合的,是在哪里,這要確定一個范圍,在一個范圍基礎(chǔ)上是進一步的人的建立。
對于網(wǎng)絡(luò)、機型來講,目前我們認為最可以做的在于,可能因為阿里的模式跟有些公司不一樣,阿里更多的機器都來自同一個部門,基本上是同一個部門在教阿里巴巴所有的機器。這就有巨大的好處了,因為都在一個團隊。比如阿里巴巴在去年開始建設(shè)統(tǒng)一的調(diào)度系統(tǒng),更大的好處就來了,因為大家所有的資源都來自同一個地方,這個地方就收集了整個阿里巴巴的所有的資源需求、數(shù)據(jù),數(shù)據(jù)全部在它手上。
如果你結(jié)合這個數(shù)據(jù),以及它實際的運行情況,更好的就可以去推導(dǎo),比如說對于阿里巴巴來講最合適的機型是什么,這個阿里大概在去年就開始做嘗試。在去年以前所有的過程,阿里巴巴,比如說明年我的服務(wù)器的機型,所謂機型,這里講的機型的含義主要是比率問題,不是選擇下一代什么樣的 CPU,那是硬件發(fā)展決定的。但是比率因素,以前我們更多的是人腦拍,人肉智能。人肉智能在一定階段是更加高階的,過了那個階段之后人就比不過機器了。團隊說我們明年要買的機型里面的配置大概是這樣的,人算了一下,就這樣吧,就可以拍掉。去年開始我們引入了一套系統(tǒng),這套系統(tǒng)會分析所有的數(shù)據(jù)以及錢,最重要的是錢,然后分析一下整個過程,推演對我們來說最合算的是什么。所以適合的機型到底是什么。
如果有一套非常好的推演的系統(tǒng),來推演你的機型、網(wǎng)絡(luò)、IDC 未來應(yīng)該怎么規(guī)劃,這對于成本領(lǐng)域?qū)a(chǎn)生巨大的幫助。比如說網(wǎng)絡(luò),現(xiàn)在的發(fā)展,萬兆,25G、45G、100G,你認為對于你的公司來講最合適的是什么?多數(shù)公司八成就是人腦一拍就決定了,但是事實上可能不是這樣。
2. DC 大腦,讓控制更加智能化
DC 大腦,這個現(xiàn)在比較火,這個領(lǐng)域現(xiàn)在非常火爆,火爆的主要原因有可能是因為去年谷歌的一篇文章,谷歌去年發(fā)表了一篇文章,里面有一個消息透露了一下,他們通過更好的智能化,去控制整個機房的智能等等。比如說控制空調(diào)的出口,就是那個風向往哪邊吹,控制這個,然后為谷歌節(jié)省了非常多的錢,非常可觀。所以對于很多數(shù)據(jù)中心團隊來講,現(xiàn)在都在研究這個領(lǐng)域。因為這個領(lǐng)域?qū)嵲谔″X了。
我們后來類比了一下,我們說其實大多數(shù)人,可能你很難感覺數(shù)據(jù)中心,但是你最容易感覺的是另外一個地方,你的辦公室。比如說我們以前說,阿里巴巴一到夏天的時候,辦公室實在是太冷了,比外面冷多了。如果能夠更好的控制溫度,對于我們來講就會有巨大的幫助,對公司來講可能會更加省錢。所以怎么樣做好這個非常重要。
3. 彈性伸縮較大的前提是實現(xiàn)自動化
彈性伸縮,這是無數(shù)運維團隊都想做的事情,研發(fā)團隊說,業(yè)務(wù)團隊說,我要一百臺機器,你也不好反駁他,最后上線了一百臺,你發(fā)現(xiàn)他用十臺就夠了。但是你也很難跟他糾結(jié)這個問題,好像無數(shù)的運維團隊都在嘗試彈性伸縮。但是我說了,彈性伸縮較大的前提就是自動化,如果沒有自動化也沒有什么意義。
4. 資源畫像讓資源更好搭配
資源怎么更好的搭配,阿里巴巴在嘗試做資源的畫像。對于所有的在線業(yè)務(wù)來講,它的趨勢比較好預(yù)測,多數(shù)在線業(yè)務(wù),只有少數(shù)的在線業(yè)務(wù)不大好預(yù)測。多數(shù)在線業(yè)務(wù)是一個模式,如果預(yù)測得非常好,讓資源有合理的搭配,對于這家公司的資源將會產(chǎn)生巨大的幫助。
二.可以下降 30% 由變更引起的故障
在變更這個領(lǐng)域我們覺得首先是效率問題。阿里巴巴現(xiàn)在大概有幾萬的研發(fā)人員,我們又把運維這個工作交給研發(fā)了,那怎么讓研發(fā)在這個過程中,把變更這件事情做得更有效率和更沒有感覺,是阿里巴巴現(xiàn)在追求的一個重點。這個重點我們認為,智能化是可以發(fā)揮巨大的幫助的。上面講的第一個案例是講的文件分發(fā)過程當中的智能的流控。比如一次發(fā)布要一個小時,那意味著多數(shù)研發(fā)是需要去盯一個小時的,他雖然不一定要一直看著,但是到發(fā)完之后是要去看一下,這挺耗精力的。另外一個方向是現(xiàn)在業(yè)界很火的無人值守,怎么做到在發(fā)布過程中,對于研發(fā)來講較好是無感,我制定了在某天發(fā),只要測試通過了我就可以自動完成這個過程,有問題稍微控制一下就好了,沒有問題就當這件事情沒發(fā)生。這對于有眾多研發(fā)團隊,或者當然,如果你有運維團隊在做這件事情,對運維團隊來講就更有幫助了,意味著運維很多人可能就去掉了一大塊活。
所以,變更這個領(lǐng)域,我們最希望做的是朝這個方向去發(fā)展。目前來看阿里巴巴的嘗試,我們可以看到變更引發(fā)的故障比率是較高的,目前已經(jīng)鋪的這個領(lǐng)域中,可以下降 30% 因為變更引起的故障,攔截主要是用來攔截問題。
三.監(jiān)控 AI 化
智能報警
這個領(lǐng)域現(xiàn)在是 AI 進入運維行業(yè)中最火的領(lǐng)域,所有公司都在做。第一個是阿里在做的,阿里也不例外,我們也同樣在做。第一個是智能,大家比如說做運維的都知道,你寫完了一個業(yè)務(wù),要配監(jiān)控報警的閾值的,比如說 CPU 到多少應(yīng)該報警,然后響應(yīng)時間到多少應(yīng)該報警。阿里在嘗試的一個方向是讓你不要去配,阿里根據(jù)分析來決定什么情況下需要報警,這對于研發(fā)來講有巨大的幫助。
異常檢測直接影響到效率
第二點是異常檢測,這是很多公司都在做的。異常檢測之所以要做,較大的原因就是因為效率,如果不做,其實也 ok,但是要投入非常大的人力。比如說交易跌了,那到底是,比如對于我們來講,交易跌了,只要跌了就需要分析到底什么因素。而這個因素很有可能,最后你發(fā)現(xiàn)根本跟我們沒關(guān)系,可能是外部原因,國家節(jié)日等等,各種各樣的因素造成的。尤其是小規(guī)模的業(yè)務(wù),比如我們的海外業(yè)務(wù),波動非常大,如果一波動就認為是問題,這對于整個公司的效率來講是巨大的影響。
所以我們認為,如果異常檢測做得非常好,對我們的效率會有非常大的幫助。這張圖是通常來講,做異常檢測,運維的數(shù)據(jù)都是時序化,根據(jù)時序有各種各樣的算法,上面列了業(yè)界常用的算法。最左上角的算法是阿里巴巴自己研究的算法,從我們目前的測試情況來看,我們可以看到阿里巴巴自己研究的算法的準確率等等,得比業(yè)界高非常多。細節(jié)我不講了,最重要的原因是這個東西馬上會在某個會議上發(fā)表一篇論文,大家以后會看到。
四.穩(wěn)定性是以效率為原則
故障修復(fù)要精準且快速
穩(wěn)定性對我們來講最重要的是效率問題。第一個是故障的修復(fù),故障出現(xiàn)在越大的公司越大的規(guī)模越復(fù)雜的業(yè)務(wù)場景中,出現(xiàn)是不可避免的,一定會出現(xiàn),關(guān)鍵是出現(xiàn)之后怎么盡快把故障修復(fù)掉。故障修復(fù)這個領(lǐng)域,阿里巴巴嘗試了非常多的方案,也嘗試了很多年。很多的案例都是,這個過程需要慢慢的積累,原因在于信任感地當故障出現(xiàn)的時候,我們都說公司的很多團隊都處于高度緊張的狀態(tài),這個時候有一套系統(tǒng)拋出了,現(xiàn)在多數(shù)這種系統(tǒng)都是拋出三個決定,給你三個建議,然后你來選。有時候經(jīng)驗豐富的處理故障的人一看,你拋出的三個建議都不靠譜。當十個故障中,有八次,不用八次,如果有個四五次都是這樣的,以后所有人都不會看這套系統(tǒng)了,太不靠譜了,還不如人來判斷。這個系統(tǒng)難度非常高,需要整個公司堅定地朝這個方向走,并且更好的積累很多的數(shù)據(jù)。
故障修復(fù),阿里現(xiàn)在只嘗試了一些非常簡單的案例,對于阿里來講,比如一個機房出故障,因為整個阿里巴巴交易體系的架構(gòu)是支持多點的,對于我們來講如果在某種情況下,我們判斷一個機房出故障,我們可以自動的做一些流量的切換等等。但阿里現(xiàn)在也認為,智能化在穩(wěn)定性,尤其故障修復(fù)這種動作上,還是要非常小心,萬一沒事切出了問題,這影響更大。
用智能化做好故障定位
我們以前一直都認為定位這個問題不是個大問題,如果我能快速修復(fù),定位,你慢慢定好了,定個兩天我也無所謂。但是現(xiàn)在阿里特別重視的原因在于,故障定位損耗了我們非常多的人力,耗費了我們非常大的團隊力量。所以我們認為需要有更智能化的方法,把故障定位出來,以助研發(fā)團隊更專注投入在其他事情上。比如現(xiàn)在故障一出來,研發(fā)查了半天,一看,跟它都沒有什么關(guān)系。所以就浪費了很多,這張圖是我們現(xiàn)在在做的一套系統(tǒng),從一個異常,那里標一二三四五,當有一個異常出來之后,第一步發(fā)現(xiàn),第二步不斷的分析,一直定位到最后到底是哪個地方出了問題,我們的目標是最后盡可能定位到代碼層面的問題,或者是網(wǎng)絡(luò)或者是基礎(chǔ)設(shè)施等等。
五.邊壓邊彈 做好規(guī)?;\維
目前對阿里來講最重要的問題還是效率問題。比如說我們在每年準備雙十一容量的時候,很多人都知道阿里有全鏈路壓測,一個最重要的目的就是調(diào)整容量,怎么把一個機房的容量調(diào)整成比率是最合適的,比如說 A 應(yīng)用可能是瓶頸,但是事實上如果搭配得好,A 應(yīng)用就不再是瓶頸。所以怎么樣讓一個固定機器數(shù)下做一個較好的搭配,我們以前是壓一輪調(diào)整一下,再壓一輪再調(diào)整一下,這非常耗費一堆人通宵的精力。我們認為這個過程需要提升,現(xiàn)在改成非常簡單的模式,流量過來以后不斷的自動調(diào)整容量比例,我們會有一個所謂邊壓邊彈,一邊壓測一邊調(diào)整比例。相信很多運維同學都干過這個事情,因為業(yè)務(wù)方給你一個指標,你是要算的,而且很難算的很精準。邊壓邊彈意味著你不需要算得很精準,粗略算一個數(shù)就可以了,后面靠這套系統(tǒng)自動給你調(diào)平衡。
阿里巴巴在這五個方面,在智能化方面做的探索,阿里認為我們還不足以所有的領(lǐng)域都去覆蓋。
4、未來運維領(lǐng)域需要突破的防線
無人化 讓夢想照進現(xiàn)實
我認為現(xiàn)在運維這個領(lǐng)域中較大的挑戰(zhàn)仍然是,能不能真正的走向無人化,整個過程中是完全沒有人的。
從目前來看,要做到無人化最重要的是質(zhì)量問題,質(zhì)量做得不夠好是沒有辦法無人化的。另外如果出問題了能不能自動修復(fù)等等,所以我們認為無人化對運維領(lǐng)域是較大的挑戰(zhàn),能不能把這個落地變成現(xiàn)實,奠定了智能化的基礎(chǔ)。如果說智能化所有的動作要人介入,那基本就不用做了。
智能化 帶來效率上的質(zhì)變
在智能化這一點上,第一點是有效性的問題,如果這個智能表現(xiàn)得比人的智力還差一些,這個慢慢就沒有人相信這個東西了。所以怎么樣把有效性提升上來,另外最重要的是要看到智能化給運維領(lǐng)域帶來效率上的質(zhì)變。智能化投入非常大,要做大量的收集做大量的分析。所以較好帶來的是質(zhì)變而不只是量變,如果只是量變可能投入都收不回來。對于所有公司而言,更少的人更低的成本是非常重要的。人較好投入在一些更重要的研發(fā)等等事情上。
作者介紹
林昊 (畢玄),阿里巴巴研發(fā)效能事業(yè)部負責人。2007 年加入阿里,10 年間打造了阿里目前使用更為廣泛的核心中間件之一的服務(wù)框架;建設(shè)了阿里的 HBase 團隊,發(fā)展到今天 HBase 已經(jīng)是阿里最重要的 NoSQL 產(chǎn)品;打造阿里基于 LXC 的虛擬化系統(tǒng),以及集群資源管理系統(tǒng),不斷降低阿里巴巴在機器資源上投入的成本;設(shè)計并帶領(lǐng)團隊實現(xiàn)了阿里巴巴技術(shù)發(fā)展史上具有里程碑意義的異地多活。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/3961.html
摘要:前兩天有朋友拿了這樣一段代碼來問我,我想把一段代碼寫成模塊化的樣子,你幫我看看是不是這樣的。的一個好處在與依賴前置,所有被使用到的模塊都會被提前加載好,從而加快運行速度。 前兩天有朋友拿了這樣一段代碼來問我,我想把一段代碼寫成模塊化的樣子,你幫我看看是不是這樣的。,代碼大概是這樣的: (function(global) { var myModules = { n...
摘要:阿里巴巴的共享服務(wù)理念以及企業(yè)級互聯(lián)網(wǎng)架構(gòu)建設(shè)的思路,給這些企業(yè)帶來了不少新的思路,這也是我最終決定寫這本書的最主要原因。盡在雙阿里巴巴技術(shù)演進與超越是迄今唯一由阿里巴巴集團官方出品全面闡述雙八年以來在技術(shù)和商業(yè)上演進和創(chuàng)新歷程的書籍。 showImg(https://segmentfault.com/img/remote/1460000015386860); 1、大型網(wǎng)站技術(shù)架構(gòu):核...
摘要:精讀前端可以從多個角度理解,比如規(guī)范框架語言社區(qū)場景以及整條研發(fā)鏈路。同是前端未來展望,不同的文章側(cè)重的格局不同,兩個標題相同的文章內(nèi)容可能大相徑庭。作為使用者,現(xiàn)在和未來的主流可能都是微軟系,畢竟微軟在操作系統(tǒng)方面人才儲備和經(jīng)驗積累很多。 1. 引言 前端展望的文章越來越不好寫了,隨著前端發(fā)展的深入,需要擁有非常寬廣的視野與格局才能看清前端的未來。 筆者根據(jù)自身經(jīng)驗,結(jié)合下面幾篇文章...
閱讀 1599·2019-08-30 13:18
閱讀 1583·2019-08-29 12:19
閱讀 2127·2019-08-26 13:57
閱讀 4151·2019-08-26 13:22
閱讀 1192·2019-08-26 10:35
閱讀 2997·2019-08-23 18:09
閱讀 2516·2019-08-23 17:19
閱讀 689·2019-08-23 17:18