阿里應用運維體系的變遷

2016年12月1日-2日，Velocity China2016在北京舉行，會上阿里巴巴平臺架構部研究員林昊（花名畢玄）發表了題為《阿里應用運維體系演變》主題演講。主要介紹了阿里應用運維體系經歷的幾個不同階段的演變。畢玄作為親歷者，分享了阿里在這個過程中隨著業務發展、規模擴大、業界技術變化，在思路、方向和人才體系上的演進。

　　畢玄表示，阿里的運維體系先後經歷了指令碼時代、工具時代，以及目前正在全面落地DevOPS思想的過程，另外也在積極探索自動化運維和為未來的智慧化運維做準備。最初在08-09年的時候，阿里還處於指令碼的時代，大量的運維工作需要通過指令碼來操作，但隨著業務規模擴大和複雜化後，越來越難應付，開始引入運維工具理念；在運維工具時代，阿里的運維體系也經歷過從純粹的工具團隊/運維團隊並行的階段，到為了更好地保障工具質量的大一統的工具團隊階段，再到逐漸有DevOPS思想和職能的偏軟體思想的工具團隊時代；直到最近的阿里應用運維團隊的大變革，將以前的應用運維團隊全部打散，合併到各BU的軟體開發團隊中去，全面踐行DevOPS思想。最後，畢玄還分享了他對目前自動化運維及未來智慧化運維的一些分析和建議。

　　圖1

　　演講全文：

　　大家好，我是畢玄，我今天分享內容的主題叫阿里應用運維體系的演變。在講這個話題之前，我簡單講一下阿里和Velocity會議的緣份。我記不清楚是幾年前，我們有同事在美國參加Velocity大會後，覺得這個會在效能、前端，還有運維這三個專業領域上講的非常專業，做的非常好。所以當時我們有同事和Velocity的官方一起努力想把這個會引進到中國，我們覺得這是一場非常專業的會議。所以非常歡迎來參加Velocity大會的人，還有感謝在Velocity大會上演講的人，好，下面開始我今天的演講。

　　我先簡單介紹一下我自己。我是2007年加入阿里巴巴集團，在阿里九年來，一直做的都是基礎技術領域相關的東西。現在外部知道比較多的，比如阿里的服務框架、HSF、HBase、異地多活、混合雲，還有排程以及系統相關的東西。

　　圖2

　　大概是在2013年我從原來的基礎技術部門轉向運維部門，在這個部門待了三年左右。就是在這三年裡，我基本經歷了阿里巴巴在應用運維這個領域，我們所嘗試的一些方向性的演變。這些方向現在看來，多數在運維領域都是很明確的方向，比如最早期的指令碼時代，這是最基礎的一個階段，在指令碼化以後就是工具化，然後就是很火熱的DevOPS，然後朝自動化、智慧化演進。方向很明確，但是在每個不同階段演進過程中有很多問題，所有公司在往這些方向演進的過程中，很容易碰到各種各樣的挑戰和各種各樣的問題。我們覺得整個業界在走這個過程的時候，談失敗教訓的比較少一點，做成功經驗分享的比較多一點。但相對來講，其實失敗經驗可能更值得大家學習，成功經驗則因為每家公司的情況不同而會不一樣。

　　

　　圖3

　　我簡單講一下阿里走過這幾個方向的過程，並不代表阿里現在就是智慧化，阿里同樣是在不同的運維領域的不同階段。我們可以看阿里在走整個過程中所碰到的一些問題。

　　阿里應用運個團隊，首先要做所有日常運維的工作，像釋出、擴容、重啟、修改指令碼等。另外就是環境的維護，比如作業系統升級這些也都是運維團隊需要介入很多的。除了日常運維措施以外，阿里運維團隊還會負責容量管理。一個典型的案例，比如每年的“雙11”我們都會定一個指標，比如大家今年都知道阿里巴巴在今年“雙11”17.5萬筆的交易筆數峰值，其實我們在年初的時候，就會按照這個交易筆數去算，17.5萬筆需要多少機器，每個應用需要怎麼去分佈？以前都是運維團隊會介入，投入非常多的人力來計算怎麼樣去分佈機器。所以容量管理會成為整個運維團隊要花很大精力投入的一個方向。然後還有穩定性，所有運維團隊都需要去做的。比如說我們需要看監控，我們需要接所有的報警，故障出來需要處理。上述是一個大概的範圍，每家公司其實對運維團隊的範圍劃分可能會不大一樣。

　　指令碼化，其實就是最早的階段，所有的運維團隊都幹過。阿里大概是在2008年左右，我們會比較多的通過指令碼化操作來做運維。那個時候我們會經常看到，運維同學會寫一些單機的操作指令碼，數量會有很多，而且還有一些批量操作的措施。這是最古老的時代，現在多數的運維團隊可能已經跨過了這個時代，但是這個時代還有很多小的運維團隊在開始的時候也都會經歷。

　　這個階段最容易出現最明顯的問題就是，複雜的邏輯會非常難實現。這個我印象比較深刻，阿里為什麼在這個階段有很強的感受呢？我們在2008年到2009年年初左右的時候，我那個時候還不在運維團隊，在中介軟體團隊。當時我去看運維做釋出，阿里那個時候大概在一個城市有兩三個機房，我們就會看到釋出的時候阿里當時有一個時間視窗，比如某天早上的一個小時內要完成所有的釋出，那時候我們一個早上要完成100多個應用的釋出，分佈在兩個機房，那時候因為沒有釋出系統，同學用批量指令碼處理不同的機房，然後會看到運維同學開啟很多不同的視窗。有時候會問一下運維同學，連他們自己也不知道這個應用現在發了哪幾個機房，因為發的時候肯定不能全殺掉髮，比如分一半，或者分更多批次，這個時候很容易忘哪些發過哪些沒發過，哪些釋出成功哪些沒有成功。

　　我們現在再看那個階段，我們就知道指令碼化對我們來講，雖然後面肯定還要有指令碼，但是純粹靠腳

　　本化完成運維操作的時代要過去了，而且是扛不住了。所以阿里開始各種各樣新方法嘗試的階段，我們把這個階段稱為工具化時代。

　　圖4

　　工具化的時代非常簡單，思想就是通過軟體的系統實現所有運維的複雜操作。複雜操作的背後仍可能是單機上的指令碼操作，因為這對運維人員來講是最容易維護的，如果全是程式化是非常難。所以這個時候的思想比較簡單。

　　在工具化這個時代，我們嘗試了非常多手段，怎麼樣讓這個時代走的更好更順暢。如果你的運維團隊從一開始就以傳統運維團隊開始往前演進，估計碰到的問題會和阿里差不多。阿里最早覺得我要做運維繫統，所以我們成立了一個工具團隊，是專門做運維繫統的，專門做軟體層面的開發。同時還保留原來的運維團隊，運維團隊主要負責我剛剛講的那一堆操作東西。這意味著工具團隊不負責這些具體運維操作，只負責寫系統。開始的時候這兩個團隊是分開的，然而在運轉的過程中，我們就會很容易碰到下面這種情況：工具團隊覺得我們自己做了很多工具，運維應該變得很幸福了；運維同學告訴你，其實我們生活沒有變的很幸福，基本上跟以前差不多，甚至更慘了。

　　這個過程中，你很容易碰到這兩個團隊互相講各自碰到的一些挑戰和問題，包括各自認為自己做的好的部分，但是最終確實你能感受到的是，運維的這項工作好像沒有被徹底改變掉，雖然有改變，比如以前可能是批量去一個黑屏視窗操作一堆的批量指令碼，現在改變成了用一些有UI的系統，運維同學就是點點點，但是對運維同學來講，並不一定是實質性的改變。另外，工具團隊自己也會很容易出現成就感等等的問題，因為他們覺得，我明明做了很多東西，為什麼運維團隊的同學會不認可。

　　阿里在這個階段大概走了有一年左右，因為當時差不多這兩個團隊都是我在帶，後來我們覺得這個方式可能會有些問題。我們當時的判斷是，之所以會出現上述現象有一個很大的原因，就是工具的質量不夠高。比如說，為什麼有些運維同學覺得有工具後，和以前相比並沒有很大提升，甚至說更差，很大的原因是工具在運轉的過程中出現這樣那樣的問題。當工具出問題的時候，運維同學會很難介入，這個時候會完全依賴工具團隊來解決。這種情況往往讓這些運維同學覺得，還不如手工操作好了，批量指令碼完全可以搞定，出問題也能自己查。所以我們認為工具的質量是當時最大的問題。

　　以前阿里的組織結構決定了工具團隊分散在很多不同的團隊，比如網路有自己的運維團隊，伺服器有自己的運維等等，他們都是完全分開獨立的。分開的情況下有一個問題，每個團隊都會按照自己最熟悉的語言和架構建設自己的運維繫統，所以也就導致最後運維繫統不像我們的生產系統，生產系統可能有一個統一的架構固化，而這種運維級的系統出現的狀況就則是百花齊放，什麼都有，一出問題，各種語言各種架構的人都要出來了，所以整個體系的質量是非常難保證。總的來說我們認為工具質量是根本原因，其中工具團隊的分散是主要因數之一。所以我們決定合併所有工具團隊，把所有的工具團隊合成一個團隊，像一個軟體研發部門來應對上述的運維問題，之後我們確實能夠很好地的去應對各種質量的問題，包括建立起統一的運維繫統體系。

　　

　　圖5

　　在這個階段的過程中，我們的工具的質量確實在逐步提升，因為開始走統一化了，對架構與技術有更多的控制力了。但在完成這個階段以後，我們仍然沒有解決工具團隊和運維團隊分開的問題，所以我們後來決定嘗試另外一種思路，乾脆讓工具團隊自己做運維，比如工具團隊認為我能把釋出做好，就由工具團隊把所有的釋出工作全部承接，這樣就變成一個團隊的工作了，不存在更多的協調溝通問題。這個模式我們運轉了一段時間，但我們覺得仍然有提升的空間。

　　在工具化這個階段中，我們碰到的問題一方面是我剛才講的那些，還有一個問題是推進落地。推進落地上，大家可能都知道，很多運維團隊最早構建的時候，都是由偏系統操作的人才來構建的，而不是偏軟體體系開發的人才來構建。所以這個體系會導致一個現象，那就是挫敗感。因為寫軟體有些時候還是需要一定的時間，特別是你的軟體要做到很高的成功率，要做到很好的質量，其實還是需要有時間積累的。所以在寫這個軟體的過程中，很容易出現挫敗感，會導致你會覺得，我還不如不要寫軟體，用指令碼好了。因為每個人都更相信自己可控的東西，不可控的東西會很難堅定的執行。所以，我們覺得在工具化的過程中，方向很容易被人接受，但是真的要堅定的走這條路，思想上是需要有轉變的，而且需要有時間保障。比如運維團隊中很容易出現一個現象，我可能一個星期全部都在處理線上問題，要麼都在處理日常操作，處理活動需求等等，根本沒有時間寫軟體，完全沒有。所以這種情況下也不可能做工具化，也做不了。

　　軟體質量是我們在這個過程中發現的最重要問題，阿里最早認為運維繫統比較簡單，我們後來在發展過程中，看到的第一個現象是成功率的問題，發現成功率和線上系統完全是兩種思路，比如線上系統偏向於當系統出問題，後面系統有超時等各種各樣問題的時候，我們使用盡可能讓它失敗掉。但是運維繫統為了保證成功率，我們需要有失敗的重試等等各種各樣的策略，這個也是很高的要求。在成功率之後，我們逐漸碰到了像穩定性、效能這樣的問題。因為我們的規模越來越大，比如我們同一天同一個時間段可能要完成非常多次的釋出，一次釋出後面可能對應上千臺以上的機器，如何在這麼短的時間內做到效能上的絕對保障，也是一個很大的挑戰。

　　很簡單，大家可以想一下每年的“雙11”，“雙11”零點就是一個時間點，肯定不能在那個時間點附件進行任何釋出。但是有可能在那個時間點前的半個小時發現了一個緊急Bug，而且必須修復，這個時候對釋出來講就是個巨大考驗，而且在阿里的發展歷史上，確實碰到過一次這樣的案例。所以我們越來越會覺得運維繫統，除了成功率以外，在穩定性、效能這兩個領域也面臨巨大考驗，它跟生產級的系統其實沒有什麼區別。

　　另外，我們在推動整個工具化的過程中，碰到另外一個問題是標準化，我們認為國外很多網際網路公司在這點上做的相對較好，他們可能一成立的時候在運維體系上就會走標準化。比如一臺機器上目錄結構怎麼樣，日誌放在哪裡，埠是怎麼樣，可能全部都是標準，在公司一成立的時候，這個就已經是標準，這就決定了這個公司在以後不斷演化的時候，他的運維繫統是比較容易做的。但阿里是一個百花齊放的系統，那就意味著A業務和B業務的運維繫統標準可能完全不一樣，就是你連目錄在哪兒都找不到，更不用說賬號這些，所以導致運維繫統非常難統一，必須面對多種環境做不一樣的東西。所以標準化是我們在這個階段中遇到的另外一個大問題，我覺得是阿里在後幾年不斷做運維繫統過程中明白了一個道理，以前埋下的一個坑後面要花很多年的時間來填補。

　　因為工具化階段化碰到的這麼多問題，讓阿里意識到我們工具化中欠缺了一個核心思想，即以軟體體系構建整個運維體系，包括思想層面，即以一個軟體工程師的思想來做運維體系。大家看這頁幻燈片，《SRE：Google運維解密》這本書中提到的Google的SRE團隊，他們可能是業界做的相對較好的運維團隊，在這本書中，有幾句很經典的話，我稍微摘錄了一下。比如Google認為SRE是DevOPS模型在Google的最佳具體實踐，DevOPS只是個思想，它不是一個可落地的東西，因為光講思想是落地不了的，思想這個東西大家聽完可能就結束了。關鍵是這個思想怎麼被落地？Google認為，SRE就是DevOPS的最好展現。像SRE團隊有一個核心思想，他會強調，我是一個軟體工程師，所以我應該用軟體的方法去應對重複勞動，這個是所有軟體工程師刻在骨子裡不會被改變的思想。因為軟體工程師很難接受自己做一件重複的事情，重複做很多次，他基本上願意花更多的時間做系統。

　　圖6

　　另外我們可以從這本書裡看到GoogleSRE團隊在時間上有保障的。比如說SRE的團隊必須花50%的精力在真正的開發工作中。很多團隊其實也想做到這樣，但關鍵是做不到，你可能也會說，我也希望我的團隊50%做研發50%做運維。但是你會發現運維壓力太大了，還是別做開發了。同樣處於這個階段，Google有明確的方案來做時間保障。比如說，他如果覺得超過50%，他會把這個壓力轉接給研發團隊，自然會保證運維團隊的時間分配。所以，正如Google的這本書裡提到的，我們認為在SRE是DevOPS思想在Google落地的一個很好展現。

　　阿里也認為，DevOPS是我們的方向，DevOPS是我們更好的解決工具化的一個方案，就是一種思想。但關鍵是，我們怎麼樣才能把這個思想在阿里落地。所以阿里今年做了應該算很大的一次組織結構調整，我們決定把負責整個集團業務的應用運維團隊拆掉，直接交還給所有的研發團隊，我們的目標是日常的運維操作逐步讓研發自己去做。但這是有前提的，比如說你要把日常的運維操作全部交給這個系統的研發人員去做，意味著需要有一套很高質量的運維繫統。如果你沒有這個系統研發估計就要崩潰了，所以這裡面的挑戰在於工具化的程度。但是因為交還給了研發團隊，所以我們相信在這個階段中，可以把我們在工具化這個階段碰到的各種問題都解決掉。

　　另外，我們認為DevOPS思想落地有一個很大的問題，就是到底怎麼落地的問題。在這個過程中我們覺得Docker是非常有效的讓DevOPS強制落地的方案，Docker中有一個最典型的方案DockerFile。生產環境的一臺機器的整個執行環境，可能不是研發獨自搭出來的，最大的可能是研發搭了其中的一部分，然後運維給你搭了另外一部分。所以這個環境是由兩個人共同搭出來的，也就是說，其實沒有一個人能很清楚的描繪那個環境到底是什麼，包括研發自己。所以在出問題時，問題排查就需要多方團隊共同對資訊，一起排查。但是因為DockerFile強制描述了這個應用執行的所有的環境資訊，所以研發就會非常清楚所依賴的整個軟體棧是怎麼樣，這個時候再出問題的時候會有極大的幫助。這是一個強制方案，所以可以讓DevOPS更好的推進。

　　阿里現在仍然有很多東西在工具化這個階段，但是自動化確實也有一些，我們也在朝這個方向演進。為什麼以前讓運維同學感覺到幸福感還不夠？是因為工具很多時候還是要人點的。人點其實也是時間投入，而且可能是巨大的碎片化時間投入，會導致你工作很難持續。自動化意味著，怎麼樣讓工具中人蔘與的多個環節直接演進到沒有人蔘與，整個過程無人值守，這個實現起來其實非常難。

　　圖7

　　比如說釋出，釋出是運維中最長的變更，一個釋出動作怎麼樣能做到完全沒有人？為什麼很難？舉個阿里的典型案例，釋出完一臺機器之後重啟了，你怎麼知道重啟完的應用到底是正常還是不正常，這個判斷標準挺難去確定的，現在業界有很多種方案去摸索，到底這個東西是正常還是不正常。這是一個很複雜的話題。更不要說網路裝置的釋出等等，更加複雜化了，因為你沒有辦法判斷，而且一發就發上去了。所以怎麼樣朝無人值守演進是一個很難的方向。

　　另外，有些要做到無人值守，還會需要做到架構層面的支撐，比如阿里有機房級的流量一鍵切換的能力，最早的時候阿里在這個過程中，仍然有很多人工介入的部分，就是因為各個系統其實不具備這個能力，整個架構也不具備這個能力。所以我們為了做到這一點，整個架構層面都做了很多調整。

　　所以真的要做到自動化，我們認為這是運維中一個非常重大的里程碑，而且也非常難做到。我們碰到的主要問題是成功率，因為自動化意味著整個過程中顯然成功率要做到非常高，因為只要一失敗，就要有人介入，除此之外還需要架構的支撐能力。

　　智慧化是現在很火的一個話題，很多場合都會講智慧運維。智慧運維、智慧化的前提顯然是需要有大量的資料收集，如果沒有足夠的資料，足夠的經驗，因為運維的很多工作其實是經驗，是很難做到自動化的，非常非常的難。所以智慧化的前提是自動化，如果你連自動化都沒有做好，智慧化根本無從談起。阿里運維還有很多故障的處理，故障到底出現在哪裡，這都是非常難判斷的。

　　我們現在的智慧化運維只能做非常具體特徵性的，比如我們嘗試如果單個機房出現故障的時候，是不是可以做自動切換。但是可以看到這個面對的場景非常狹窄，而且會需要很強的特徵匹配，所以這個就很難做了。

　　所以我們認為在智慧化這個階段，阿里有些領域在嘗試，我們碰到的主要問題在資料的準確性。其實運維可能會收集很多資料，但是資料要做到精準，其實對技術能力有很高的要求。另外就是經驗，所謂的經驗，如果不是格式化的是很難被學習的，所以這也是一個很大的挑戰。然後是特徵層面，人工去提取的特徵，就意味著那個特徵會非常固定性，所以需要有機器學習的介入做特徵的提取。所以，我們覺得先最好安心完成前面的工具化、自動化，在有大量資料的收集和大量經驗的採集後，可以朝智慧化這個方向去演進。

　　總的來講，阿里經過這幾年的摸索，我們覺得DevOPS顯然是一個大的方向，但是這個方向要被落地，需要有機制的保障。比如說，Google的SRE之所以做的比較好，顯然有機制級保障，就是整個公司對運維團隊的機制保障。另外就是需要有有效的落地方法。然後自動化是運維領域中的巨大里程碑，智慧化的前提就是剛剛講的。這就是我今天的話題，謝謝大家！

　　快樂分享，快樂生活