從人肉到智能,阿里運維體系經(jīng)歷了哪些變遷?
回顧阿里巴巴運維的發(fā)展階段,從最開始的人肉/腳本運維, 到簡單的工具、自動化, 到系統(tǒng)化和平臺的過程, 自動化到一定程度后,開始探索智能化運維領域。今天,阿里資深運維專家大舞,將帶你體驗阿里智能化運維背后的故事。
此外,我們推出了“阿里智能運維(大數(shù)據(jù)篇)”專欄,總結了一整套成體系的實踐方法,具體訂閱方式請見文末。
機器智能的前提是需要有數(shù)據(jù),AIOps的數(shù)據(jù)從哪里來?如何利用數(shù)據(jù)代替機器決策、分析?如何利用機器學習算法與基于大數(shù)據(jù)的業(yè)務運維管理平臺整合,在告警過濾、異常監(jiān)測、自動修復等環(huán)節(jié)發(fā)揮效用,真正能把運維同學解放出來提高整體運維效率,降低運維成本。我們認為AIOps是一個長期演進的過程,這也是我們區(qū)別于業(yè)界,在通往AIOps征途上增加DataOps階段建設及沉淀的重要原因,而我們接下來聊一聊DataOps時代——運維人才的能力要求。
人肉/腳本運維時代(Human/Scripts Ops)
運維工作本身其實是一個需要具備高度綜合技能掌握的工種,需要涉及的廣度相對別職業(yè)屬性的要求會更高,以前很多時候大家對運維的認識都停留在發(fā)布、變更、接報警、搬機器……其實這個很好理解,所有的互聯(lián)網(wǎng)大公司都是從小公司成長起來的,在還是小公司的時候,你需要面對的是不停地解決各種奇怪的問題,而由于有公司生存的壓力,追求短平快的結果使得大家會淪為一個搬來主義者,從各類技術論壇,甚至是個人blog上去搜索各種各樣的解決方案,以求快速workrun解決問題,但對于原理、系統(tǒng)全局上的東西,可能完全不會去深究。
工具化運維時代(Tools Ops)
做過運維的人都知道,運維同學比較喜歡編寫各種各樣的腳本,比如一鍵批量發(fā)布軟件,一鍵清理、交互式向導執(zhí)行等等,他們很喜歡通過黑屏上操作刷屏帶來成就感。每當我們的運維同學交接工作的時候,新來的運維同學基本上會照著自己的理解重新實現(xiàn)一套。人肉/腳本時代的運維存在大量的效率低下,以及各種各樣重復的腳本工具,同時也會帶來很多安全風險,回顧互聯(lián)網(wǎng)的發(fā)展史,幾乎每隔一段時間就有一些嚴重事故發(fā)生,而每次事故的背后卻是一些低級錯誤,甚至是手誤敲錯字符帶來的巨大代價。這時候大家都意識到,不能再任由運維同學隨意發(fā)揮了,需要將各式各樣的功能腳本收斂到工具里來,通過集成的運維工具迭代來實現(xiàn)復用和能力交接,這體現(xiàn)在DevOps的初級階段,此時還沒有延伸到Dev階段。
平臺型運維時代(DevOps)
隨著公司商業(yè)上的成功,隨之帶來的規(guī)模的發(fā)展,這個時候量變引起質變,今天對大廠的運維來說已經(jīng)遠遠不僅僅是上述這些工作,同時這些工作也不僅僅是靠加人手能解決得了的,例如說應用從原來的一個應用變成了幾千個、上萬個、幾十萬個,平臺規(guī)模從原來的幾百臺擴充到上萬&幾十萬臺,硬件由簡單的CPU,mem,機械硬盤增加到Gpu,F(xiàn)pga,Asic,Optan等各類異構硬件平臺,軟件架構變化,大數(shù)據(jù)分布式等等,當面對海量的各類匯總數(shù)據(jù),需要快速判斷業(yè)務止損,全局資源優(yōu)化運營等工作時,人工將會面臨非常大的挑戰(zhàn),甚至是不可能完成的任務。這個時期運維的工作職能更多轉變?yōu)椋?/p>
- 全局架構規(guī)劃
- 資源運營與成本優(yōu)化
- 自動化平臺開發(fā)
- 穩(wěn)定性保障
- 海量數(shù)據(jù)分析
- …….
數(shù)據(jù)化運維時代(DataOps):
對我們來說由于業(yè)務的需求對目前運維能力的要求越來越高,技能的要求上來說不光除了面上的廣度還需要一定方向的精度,甚至某些點的深度要非常專深。同時需要通過軟件工程化,數(shù)據(jù)化的運維的思路,圍繞數(shù)據(jù)鏈建設起整體運維智能化工具鏈,來解決超大規(guī)模分布式集群運維管理問題,提升整體產品的穩(wěn)定性,效率,成本。這樣對現(xiàn)在整個運維人員的綜合技能要求會有很大的挑戰(zhàn)。
業(yè)內隨著運維的發(fā)展逐步從Ops發(fā)展到今天大家業(yè)內都比較火熱的AIOps,現(xiàn)在運維界現(xiàn)放眼望去大家都太大談特談AIOps,認為只要有強大的算法,就能夠輕松實現(xiàn)不需要人為干預的智能化,當然這是個理想化,終局化的情況,最終的目標是要做到完全智能化,但這個難度不低于完全自動無人駕駛。在我們看來如果算法是kernel,那么工程化的程度就決定了能否把kernel發(fā)揮到***,能否做到易用和高可靠是我們要著力解決的問題,我們內部我們認為目前還處于DataOps階段,數(shù)據(jù)化一切運維對象,以數(shù)據(jù)驅動運維,工程化落地。與自動化駕駛分級類比:

隨著大數(shù)據(jù)時代的逐步發(fā)展促進運維人員的技能轉型需要具備更為復合性能力:
- 架構能力
- 研發(fā)能力
- 運維知識&業(yè)務理解
- 基本工程算法
- TPM(技術項目管理能力)
AIOps發(fā)展最終本質上還是要落地在公司的各類運維平臺&運維產品上,在完成初步構建后仍然需要持續(xù)的人力投入以及參與,而在目前的探索發(fā)展的投入階段,有大量的工需要去做,仍然需要專家或者分析師,從不同的維度,從不同的業(yè)務口徑,組合合適的可視化技術,機器學習技術,大數(shù)據(jù)分析技術,制定分析場景,平臺落地才能夠為運維產生持續(xù)的洞察,提供最終的業(yè)務價值。

在不同階段對于運維團隊的技術能力要求及轉型是必須歷經(jīng)的過程,同時也是一個痛苦的過程,能力要求的變化自然會帶來組織變革,對原有人員的沖擊也會比較大,整個部門從維護性部門轉變?yōu)檠邪l(fā)創(chuàng)新型部門,***帶來的沖擊是思想上的,在研發(fā)思維先有原理,然后逐步工程實現(xiàn)落地,而傳統(tǒng)運維是反過來很多東西都是已經(jīng)存在去維護它的穩(wěn)定。
這種陣痛也是團隊轉變需要去面對的,從被動救火式運維向主動精細化轉型,從問題驅動向價值驅動轉型,從操作運維向運維開發(fā)轉型,從依靠經(jīng)驗向智能化驅動運維轉型,這不僅是技術能力的轉型而且是運維系統(tǒng)化思路的轉型。時代在變化,唯一不變的只有擁抱變化!
【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件,轉載請聯(lián)系原作者】