作者:畢玄

編輯:謝然

每家公司對於所謂運維團隊到底應該做些什麼，都有各自的看法。本文首先由阿里巴巴的運維團隊在整個阿里巴巴的業務裡承擔的責任為切入點，回顧了阿里巴巴從工具化到自動化的過程，接著分享了阿里巴巴在智慧化領域的探索路線，最後總結了未來運維團隊所面臨的巨大挑戰，特別是運維智慧化落地，有效性提升，以及最終效率提升及成本節約上帶來的挑戰。

隨著大資料、機器學習和 AI 技術的飛速發展，智慧化運維成為運維的熱點領域。Gartner 的報告宣稱，到 2020 年，將近 50% 的企業將會在他們的業務和 IT 運維方面採用 AIOps，遠遠高於今天的 10%。儘管 AIOps 還是一個新名詞，但它無疑代表了運維未來的一種趨勢。

智慧化運維的終極目標，就是將運維人員從繁瑣的工作中解放出來，提高整體運維效率，降低運維成本，實現業務系統的高可用性。

運維環境的異構和複雜化，導致日常運維工作需要付出的人力、時間成本越來越高。 大約兩年前，智慧化運維開始被大家廣泛關注，隨著大資料分析、APM、智慧異常檢測、機器學習等技術的興起和逐漸成熟，運維需求也逐漸向自動化和智慧化過渡。從最初級運維發展到現在智慧化運維，大致經歷了四個階段：指令碼時代——工具時代——自動化時代——智慧化時代。

目前業界真正的智慧化運維的落地實踐其實並不多，大多還是停留在自動化甚至人工化階段，然而智慧化運維是大勢所趨，對於大公司來說，更是尤為重要。以下整理自 2017 上海 CNUTCon 全球運維技術大會上，阿里巴巴研發效能團隊負責人，阿里研究員畢玄的演講《智慧時代的新運維》。

阿里的運維體系承載著怎樣的責任？

阿里的運維體系介紹  

阿里的運維團隊，主要覆蓋五個層面。

資源的規劃與支付是運維的基石

整個運維團隊需要負責資源的規劃、資源的交付。

Quota 管理： 比如我們會跟業務團隊做一些預算的管理，對於每個業務團隊首先需要有預算。只要你有預算，運維團隊一定會把資源交給你，沒有預算一切免談。

規劃： 比如阿里每年的雙十一交易，業務團隊要給出下一年的交易額將做到多少，至於背後需要增加多少的機器量，業務團隊根本不關心。所以需要運維團隊來做從業務需求到資源的轉化和規劃，這對於公司來講非常重要，因為意味著最終我在基礎設施上要投多少錢，還有節奏的控制。

採購： 當規模大了以後，怎麼樣合理規劃資源的數量和交付節奏是非常重要的，比如 5 月份採購這批機器和 6 月份採購這批機器，是完全不同的概念。還需要資源的採購，比如 SSD 採購緊張，供應量不夠。通常大公司會有更多的渠道獲得更好的供應量，小公司就會很困難。怎麼做好供應鏈控制是非常重要的。

資源排程： 對於資源團隊來講，排程也很重要，我們交出去的機器是怎麼樣的交法，怎麼保證可用性、穩定性， Bootstrap 等，每個業務都有自己的規劃，按照業務需求怎麼把整個業務環境全部交給業務方。阿里目前就遇到了很大的挑戰，比如在國際化的擴張上，我們可能這個月需要在這裡建個點，下個月需要在另一個地方建個點，怎麼快速的完成整個資源，不僅僅是機器資源的交付，還有軟體資源的交付，是非常重要的。我們現在在擴充套件東南亞的業務，怎麼樣在東南亞快速的完成整個軟體資源的交付，對於我們的競爭是非常重要的。

 變更 是運維不可避開的坑

對於運維團隊來講，變更也是經常要做的部分，變更資訊的收攏，做應用層面的變更，基礎網路的 IDC 等等。

 監控 預測潛在的故障

監控對於阿里來講主要分為基礎、業務、鏈路，在監控的基礎上要去做一些報警等。

穩定性 是不少企業追求的目標

穩定性這個概念我們以前認為針對的是大公司，因為它可能會影響到大眾的生活，會比較敏感。但是現在新型的網際網路公司，如外賣，ofo、摩拜等，它的穩定性要求比以前很多創業型公司更高，因為它有在那個點必須能用，如果不能用，對使用者會有直接的影響。所以穩定性可能在整個運維行業會得到越來越高的重視，但是對於很多中小型公司，穩定性的投入相當大的。

一鍵建站 讓規模化有力保障

像阿里在穩定性上主要會去做多活體系的建設，然後故障的修復、故障定位，然後還有一套全鏈路的壓測。規模化是很多運維團隊很痛苦的事情，可能今年機器在這個機房，明年你的基礎設施團隊可能告訴你，這個機房不夠用了，我們要換個機房。反正在阿里巴巴，很多的運維人員都說了，我們每年的工作中有一項不用寫的工作就是搬遷。雖然基礎設施團隊會承諾說三年內不會再搬，可是到了明年他會跟你說，由於某些原因我們還是再搬一下，搬完之後三年不會讓你再搬。但是從我們過去發展的三年，每年都在搬。未來我們確實相信阿里巴巴，可能在未來搬遷會相對更少一點，我們認為不能讓搬遷成為阿里巴巴運維團隊的核心競爭力。

我們在規模化層面做了很多事情，比如說我們做了一鍵建站，對於阿里來講，我們對機器資源的交付時間，要求會越來越高。比如說雙十一，是提前一個月交付資源還是提前兩個月還是提前三個月，對我們來講付出的錢是完全不一樣，而且可能相差非常大。

所以，技術層面能不能更好的把這個時間縮短，是非常重要的。所以一鍵建站的重要目的就是這個，每年雙十一我們都會拓展出非常多個站點，通過一鍵建站快速完成整個過程。搬遷就是我說的，反正我們每年都要搬，那我們應該把搬遷這套系統做得更好。還有騰挪，阿里很多時候因為需要做一些業務資源的複用，最好是有一個機櫃，這個時候怎麼更好完成挪的過程也是很麻煩。

我們還需要做一些單元的調整，因為對阿里的交易系統來講是有單元的概念的，我們怎麼更好的控制一個單元內機器的比率是非常重要的。一個單元的機器數可能是比較固定的，那如果比率搭配不好，就意味著瓶頸點會非常明顯。

以上，正是阿里巴巴的運維團隊所覆蓋的五個領域。整個運維體系的演進過程，差不多都是從最早的指令碼到工具到自動化，到未來的智慧化。

從工具化到自動化過關斬將

從工具化到自動化這個層面，過程並沒有那麼的容易，以及對整個行業來講，目前更多的工作仍然是在探尋自動化，怎麼樣讓自動化真正的被實現得更好。

這個行業的發展跟其他傳統的軟體，標準的軟體研發行業，我覺得很不一樣。比如說阿里從工具化到自動化這個過程中，我們認為工具化，其實挑戰相對小，即使傳統的運維人員也很容易寫一些工具，比如用 Python 去寫更多的工具體系。但是如果你的工具最重要變成能夠到自動化這個階段，就意味著對工具的要求會越來越高，比如說工具的質量，如果你寫出來的工具經常有問題，規模一大就扛不住，這個時候對於大家來講慢慢會越來越失去信任感。最後會很難完成這個過程。

運維團隊轉型研發團隊 組織能力是最大的壁壘

阿里過去走這條路的過程中，我們覺得最大的挑戰是組織的能力問題。運維團隊怎麼樣更好的完成朝研發團隊的轉型，這個過程對於很多運維團隊來講都是巨大的挑戰。對於一個組織來講怎麼完成這個過程也是非常重要的。

我想很多團隊都有這個感受，工具研發的團隊跟做運維操作的團隊之間，很容易產生一些衝突等等。所以阿里巴巴在走這個過程的時候，思考的核心就是怎麼讓一個運維團隊真正從組織能力上，演變成我們所需要的更好的團隊。

阿里在走這條路的時候，走了四個過程。這個過程阿里在不斷的摸索，最終到現在為止我們認為阿里的方式相對來講還是不錯的。我們最早跟大部分公司一樣，有一個專職的工具研發團隊和一個專職的運維團隊。工具研發團隊做工具，做出來給運維團隊用。這個過程中容易出現的最明顯的問題就是工具做完了，運維團隊說這個工具太難用了，不符合需求。要麼就是運維團隊執行的過程中，經常出問題，出問題還要找工具研發團隊來幫忙查問題在哪裡。本來運維幾行指令碼全部能搞定的問題，結果還要依賴工具團隊。慢慢這個局面越來越難突破，很難改變。

所以阿里後來做了一個嘗試，既然兩個團隊很難做很好的結合，那有一種方式是工具研發團隊做完工具以後，比如說做了一個釋出，做完這個功能以後，這個運維工作就徹底交給工具研發團隊，不讓運維團隊做了，運維團隊就可以做一些別的事情。這個模式看起來就是逐步接管的模式，讓工具研發團隊逐步解耦。

這個做了一段時間，碰到的最大問題還是組織能力問題。對於運維工具來講，質量怎麼做到很高，運維好像很容易做的樣子，但是實際上運維工具相當難做，它的複雜度比線上業務更大，就是它不是邏輯上的複雜，更多的是環境層面的複雜。因為比如會涉及網路涉及伺服器涉及機房等等，這跟業務完全不一樣。所以做了一段時間之後，我們覺得這還是一個問題。

將工具的研發和運維融為一體 突破組織能力問題

後面我們做完這輪之後又開始做另外一個方向的嘗試，讓工具的研發團隊和運維團隊做一個融合。所謂的融合就是把很多工具研發的人分派給運維團隊，到運維團隊去做。我們期望通過工具研發的人帶動整個運維團隊轉變成研發型團隊。這是我們的思路。

阿里巴巴在走前面這三步的時候，大概花了近一年半左右，意味著這其中我們大概做了三輪組織結構調整。因為我們認為這些都是要有組織層面的保障才能被實現的。

DevOps 是如何真正落地的

去年 6 月，我們做了一個最大的組織結構調整，把日常的運維工作交給研發做，研發自己會把日常的運維工作都做掉。但並不是說所有運維工作，現在仍然有一個做運維的團隊，這個運維團隊相對來講更不一樣，跟以前有非常大的不同。

我們認為這是 DevOps 真正的被徹底的執行。因為這個好處是，日常的運維工作交給了研發，運維團隊轉變成研發團隊這個過程非常困難，其實不完全是能力上的差距，更大的原因是，運維團隊要承擔非常多的日常雜活，尤其像集團性的公司，不管是阿里、騰訊、百度都一樣，集團性的公司多數支撐的 BU 都是無數個。你一個人支撐二十個 BU 一個 BU 裡面一天有一個人找你，你一天就不用幹別的活了，你一天就在跟他們不斷的聊天，做操作，嘴裡又叫著這個團隊要升級，要做組織升級，要轉變成研發團隊，實際上就是逼別人走向了一條死路。

所以我們認為，谷歌的做法，谷歌在 SRE 那本書提到的是，會強制留 50% 的時間給研發團隊做研發工作。這個說實話，在大多數公司很難執行這個政策，除非運維團隊跟研發團隊有非常強的話語權。但這個很難。所以阿里的做法我認為更為徹底，阿里告訴研發團隊，以後日常運維的工作不要找運維團隊，自己幹。這可能粗暴了一點，在運維體系還沒有準備得很好的情況下做了這個事情，所以後面相對來講也導致了問題，比如說運維工具四處建設、重複建設等等現象。但是從組織層面上來講，我們很欣慰的看到，在做完這輪組織調整過後的一年後，運維團隊的大多數人更多的時間是投入在研發工作上，而不是投入在日常的雜事上。我們看到了一個團隊的能力，在經過這一輪的調整得到了非常好的升級。而這對於組織來講是最大的利好。所以我們認為，這種模式是阿里現在最為推崇也最為看好的一個方向，這樣整個運維團隊將專注在我剛才講的五個部分的系統層面的研發以及建設上，而不是雜活上。這是阿里從工具化到自動化，最主要是這樣的一個過程。

成功率是衡量自動化運維的關鍵指標

對於自動化來講最重要的問題是成功率，比如我們看所有的運維操作中，我們最關心的指標是成功率。比如一個運維繫統裡面的功能，在一個星期內，比如說會用幾十萬次，我們只關注成功率能不能做到 4 個 9 以上，否則算一下工單數就懂了，這個運維團隊得有多少人支援這件事情，這些人又沒有時間去幹研發的活，又要投入大量的精力做支援性的工作。所以我們在成功率上要做到非常高的保障，運維繫統我們以前看過是面臨最大的挑戰，我以前的背景全部是做線上業務型的系統，比如淘寶的交易等等。

後來我們發現運維繫統有個最大的不同在於，運維繫統對於成功率的追求比線上業務型系統更高一些。線上業務型系統，比如說我在訪問後面一個地方有問題的時候，我們會選擇儘快把這個過程失敗掉，而不是把時間不斷的拖長以及不斷的試錯。線上系統會更加快的把錯誤往外拋。但是對於運維繫統來講如果也這樣做，就意味著這個成功率非常難保障。所以運維繫統要有更好的思考，怎麼保障一次運維操作，這背後可能有幾十個系統，而且多數是無數的團隊寫的，阿里以前碰到的情況就是無數個系統，質量層次不起，什麼都有。怎麼保證在這麼複雜的環境下，保證對外的，對使用者層面這個成功率可以做到很高的。這是一個很大的問題。

規模帶來的挑戰也是不容小覷

隨著規模的不斷增長，所有開源型別的運維類的系統，在規模化，當你的機器規模等等其他規模上升到一個程度以後，通常來講都會面臨非常巨大的挑戰。阿里巴巴所有的這種型別的系統，我們論證都是自己做是比較靠譜。最大的原因是規模，規模上去以後會遇到很多問題。像程式碼託管、程式碼編譯什麼的，以前認為不會有太大的問題，事實證明規模上來以後這些裡面全都是問題。我們也要投入非常大的精力去做規模方面的解決。

所以我覺得，阿里從以前的工具化走向更加自動化的過程中，我們探討的核心問題就是能不能有一個非常好的組織去完成這個過程。能讓運維的團隊更加轉型向 DevOps 這樣的方向。所以我們一直說，我們一直很糾結運維團隊到底應該叫什麼名字，我們一致認為，運維研發團隊，我們覺得不大對，你的主要的活其實是幹研發而不是運維。但是叫研發運維又有點奇怪。後來阿里巴巴基本上是叫研發團隊。因為我們認為運維的研發團隊和線上業務的研發團隊沒有本質區別，都是做研發的，只是一個在解決運維領域的業務問題。剛才講的五個層次，運維領域的業務問題，也是業務，沒有什麼區別。線上業務，比如解決交易的問題，解決其他問題，這是完全一樣的。兩個研發團隊沒有本質區別。

所以這個過程，阿里經過過去這一年的組織調整以後，我們看到整個自動化層面，阿里有了很好的進展，但是離我們的期望還要更加努力繼續往前演進。

阿里巴巴在智慧化領域的探尋之路

現在智慧化這個話題特別火熱，就像我們說，AI 這個名字興起的時候，我們忽然發現，阿里巴巴所有的業務都講 AI+ 自己的業務，被所有人狂批一通。我們要想清楚，具不具備 AI 化的前提，可能前提都不具備就不斷探討這個名字。因為業界在不斷的炒熱非常多的名詞，讓大家去跟隨。

自動化是智慧化的前提  

對於我們來講，我們認為，比如說就像我對這個團隊，我自己的團隊講的一樣，我認為智慧化最重要的前提是，一是自動化。如果你的系統還沒有完成自動化的過程，我認為就不要去做智慧化，你還在前面的階段。智慧化非常多的要求都是自動化，如果不夠自動化，意味著後邊看起來做了一個很好的智慧化的演算法等等，告訴別人我能給你很大的幫助，結果發現前面自動化過程還沒有做完全。

一個最典型的 case，阿里巴巴以前一直在講，我們認為資源的搭配上，其實可以做得更好。比如說你半夜流量比較小，白天流量比較大，你能不能更好的做一些彈性，把資源釋放出來去幹點別的，然後白天再把它補起來。這從演算法層面上並沒有那麼複雜，從演算法層面做到一個簡單的提升是很容易做的。所以，當時我們就有很多團隊做了一個東西，可以做到這一點。結果等到落地的時候發現，業務不能自動伸縮。如果你想，比如說有些機器上面負載特別高，有些機器特別低，我們希望負載能拉得更均衡，線上業務更加穩定化，做一個演算法，比如說揹包，更好的去做組合，結果就是這個東西做完了，給出了建議說最好這個應用調到那臺機器，那臺應用調到這臺機器。給完之後業務團隊看了一眼，我們不幹，因為幹這些工作全部要手工幹，你還每天給我建議，更不要乾了，每天就來調機器了。

所以首先你要想明白你的前提，自動化，具不具備自動化的能力，不具備的話沒有必要在這方面做過多的投入。

資料結構化是智慧化的源動力  

目前 AI 領域基本是靠暴力，暴力破解，未來可能有別的方向，但是目前的 AI 基本上是靠大量資料的積累去尋找一個東西出來，所以它一定需要有大量的資料積累，資料包括非常多的東西，對於運維來講，可能基礎層面的資料，機器的資料，運維變更的資料，上面還有一些場景化的資料，比如你解決故障，有沒有更好的結構化的收集資料，這是非常重要的。資料這個層面比較難做的在於，      在最開始階段，多數公司的運維資料都是不夠結構化的，結構化不會做得那麼好，當然會有結構化，但是結構化的因素不會足夠好。

就像阿里巴巴在講，我們在電商領域 AI 化，我們最大的優勢就是不斷對外部講，我們擁有的是結構化的商品資料，其他公司最多從我們這裡扒結構化的商品資料。你扒過去之後還要自己分析，並且做商品結構的調整，這非常困難。但是阿里巴巴自己天然，所有人都會幫你把結構做得非常好。所以對運維來講也是一樣，如果你想在智慧化上有更多的突破，資料怎麼更好的做結構化，是一個非常大的挑戰。你很難想清楚。這兩個地方是我覺得首先要想清楚的。

智慧化最適合的運維場景

從目前來看，對於運維場景來講，智慧化特別適合解決的問題就兩種，對於所有行業好像都差不多，第一是規模，第二是複雜。規模就意味著，我有很多的機器，在很多機器中我要尋找出一個機器的問題，這對於，因為規模太大了，這時候對於用傳統的方式，將非常難解決這個問題。或者你要投入非常大的人力等等，有點得不償失。規模上來以後怎麼更好的解決規模的問題，智慧化會帶來一些幫助。第二是複雜，比如說你的應用從原來的一個應用變成了幾千個、上萬個、幾十萬個，這時候你要尋找出其中哪個應用的問題，將是非常複雜的問題。所以複雜度的問題是人類用人腦非常難推演的，但是機器相對來講是更容易做的。這是阿里有些團隊希望嘗試智慧化的方向，通常我們會看是不是在前面的這些前提條件上都具備。如果都具備了，那可以去探索一下。所以我講，阿里其實目前處於整個智慧化運維的探索階段，而不是全面展開階段。

阿里巴巴智慧化運維五步走

簡單講一下我們在各個領域目前在智慧化這個領域，在運維這五個領域，對於我們講，智慧化我們看到的一些可能性，包括我們正在做的事情。

資源的重點是成本

基礎設施選型

對於資源這一塊，整個公司層面最為關注的問題，就是成本。你交付的資源具不具備最低的成本，這個智慧化確實可以給非常大的幫助。比如第一點，怎麼更好的規劃這家公司機型、網路和整個資料中心，這為什麼要用智慧化的手段在於，一個數據中心的選址來自非常多的因素，除了政府層面的政策因素之外，還有很多其他因素需要考慮，比如說氣候等等各種各樣的因素，都需要在這個階段去考慮。你需要通過大量資料的積累來分析，比如在中國，在海外，到底有那些地方是對你的業務發展策略來講最適合的，是在哪裡，這要確定一個範圍，在一個範圍基礎上是進一步的人的建立。對於網路、機型來講，目前我們認為最可以做的在於，可能因為阿里的模式跟有些公司不一樣，阿里更多的機器都來自同一個部門，基本上是同一個部門在教阿里巴巴所有的機器。這就有巨大的好處了，因為都在一個團隊。比如阿里巴巴在去年開始建設統一的排程系統，更大的好處就來了，因為大家所有的資源都來自同一個地方，這個地方就收集了整個阿里巴巴的所有的資源需求、資料，資料全部在它手上。

如果你結合這個資料，以及它實際的執行情況，更好的就可以去推導，比如說對於阿里巴巴來講最合適的機型是什麼，這個阿里大概在去年就開始做嘗試。在去年以前所有的過程，阿里巴巴，比如說明年我的伺服器的機型，所謂機型，這裡講的機型的含義主要是比率問題，不是選擇下一代什麼樣的 CPU，那是硬體發展決定的。但是比率因素，以前我們更多的是人腦拍，人肉智慧。人肉智慧在一定階段是更加高階的，過了那個階段之後人就比不過機器了。團隊說我們明年要買的機型裡面的配置大概是這樣的，人算了一下，就這樣吧，就可以拍掉。去年開始我們引入了一套系統，這套系統會分析所有的資料以及錢，最重要的是錢，然後分析一下整個過程，推演對我們來說最合算的是什麼。所以適合的機型到底是什麼。

如果有一套非常好的推演的系統，來推演你的機型、網路、IDC 未來應該怎麼規劃，這對於成本領域將會產生巨大的幫助。比如說網路，現在的發展，萬兆，25G、45G、100G，你認為對於你的公司來講最合適的是什麼？多數公司八成就是人腦一拍就決定了，但是事實上可能不是這樣。

DC 大腦，讓控制更加智慧化

DC 大腦，這個現在比較火，這個領域現在非常火爆，火爆的主要原因有可能是因為去年穀歌的一篇文章，谷歌去年發表了一篇文章，裡面有一個訊息透露了一下，他們通過更好的智慧化，去控制整個機房的智慧等等。比如說控制空調的出口，就是那個風向往哪邊吹，控制這個，然後為谷歌節省了非常多的錢，非常可觀。所以對於很多資料中心團隊來講，現在都在研究這個領域。因為這個領域實在太省錢了。

我們後來類比了一下，我們說其實大多數人，可能你很難感覺資料中心，但是你最容易感覺的是另外一個地方，你的辦公室。比如說我們以前說，阿里巴巴一到夏天的時候，辦公室實在是太冷了，比外面冷多了。如果能夠更好的控制溫度，對於我們來講就會有巨大的幫助，對公司來講可能會更加省錢。所以怎麼樣做好這個非常重要。

彈性伸縮最大的前提是實現自動化

彈性伸縮，這是無數運維團隊都想做的事情，研發團隊說，業務團隊說，我要一百臺機器，你也不好反駁他，最後上線了一百臺，你發現他用十臺就夠了。但是你也很難跟他糾結這個問題，好像無數的運維團隊都在嘗試彈性伸縮。但是我說了，彈性伸縮最大的前提就是自動化，如果沒有自動化也沒有什麼意義。

資源畫像讓資源更好搭配

資源怎麼更好的搭配，阿里巴巴在嘗試做資源的畫像。對於所有的線上業務來講，它的趨勢比較好預測，多數線上業務，只有少數的線上業務不大好預測。多數線上業務是一個模式，如果預測得非常好，讓資源有合理的搭配，對於這家公司的資源將會產生巨大的幫助。

可以下降 30% 由變更引起的故障

在變更這個領域我們覺得首先是效率問題。阿里巴巴現在大概有幾萬的研發人員，我們又把運維這個工作交給研發了，那怎麼讓研發在這個過程中，把變更這件事情做得更有效率和更沒有感覺，是阿里巴巴現在追求的一個重點。這個重點我們認為，智慧化是可以發揮巨大的幫助的。上面講的第一個案例是講的檔案分發過程當中的智慧的流控。比如一次釋出要一個小時，那意味著多數研發是需要去盯一個小時的，他雖然不一定要一直看著，但是到發完之後是要去看一下，這挺耗精力的。另外一個方向是現在業界很火的無人值守，怎麼做到在釋出過程中，對於研發來講最好是無感，我制定了在某天發，只要測試通過了我就可以自動完成這個過程，有問題稍微控制一下就好了，沒有問題就當這件事情沒發生。這對於有眾多研發團隊，或者當然，如果你有運維團隊在做這件事情，對運維團隊來講就更有幫助了，意味著運維很多人可能就去掉了一大塊活。所以，變更這個領域，我們最希望做的是朝這個方向去發展。目前來看阿里巴巴的嘗試，我們可以看到變更引發的故障比率是最高的，目前已經鋪的這個領域中，可以下降 30% 因為變更引起的故障，攔截主要是用來攔截問題。

監控 AI 化

智慧報警

這個領域現在是 AI 進入運維行業中最火的領域，所有公司都在做。第一個是阿里在做的，阿里也不例外，我們也同樣在做。第一個是智慧，大家比如說做運維的都知道，你寫完了一個業務，要配監控報警的閾值的，比如說 CPU 到多少應該報警，然後響應時間到多少應該報警。阿里在嘗試的一個方向是讓你不要去配，阿里根據分析來決定什麼情況下需要報警，這對於研發來講有巨大的幫助。

異常檢測直接影響到效率

第二點是異常檢測，這是很多公司都在做的。異常檢測之所以要做，最大的原因就是因為效率，如果不做，其實也 ok，但是要投入非常大的人力。比如說交易跌了，那到底是，比如對於我們來講，交易跌了，只要跌了就需要分析到底什麼因素。而這個因素很有可能，最後你發現根本跟我們沒關係，可能是外部原因，國家節日等等，各種各樣的因素造成的。尤其是小規模的業務，比如我們的海外業務，波動非常大，如果一波動就認為是問題，這對於整個公司的效率來講是巨大的影響。所以我們認為，如果異常檢測做得非常好，對我們的效率會有非常大的幫助。這張圖是通常來講，做異常檢測，運維的資料都是時序化，根據時序有各種各樣的演算法，上面列了業界常用的演算法。最左上角的演算法是阿里巴巴自己研究的演算法，從我們目前的測試情況來看，我們可以看到阿里巴巴自己研究的演算法的準確率等等，得比業界高非常多。細節我不講了，最重要的原因是這個東西馬上會在某個會議上發表一篇論文，大家以後會看到。

穩定性是以效率為原則

故障修復要精準且快速

穩定性對我們來講最重要的是效率問題。第一個是故障的修復，故障出現在越大的公司越大的規模越複雜的業務場景中，出現是不可避免的，一定會出現，關鍵是出現之後怎麼儘快把故障修復掉。故障修復這個領域，阿里巴巴嘗試了非常多的方案，也嘗試了很多年。很多的案例都是，這個過程需要慢慢的積累，原因在於信任感地當故障出現的時候，我們都說公司的很多團隊都處於高度緊張的狀態，這個時候有一套系統丟擲了，現在多數這種系統都是丟擲三個決定，給你三個建議，然後你來選。有時候經驗豐富的處理故障的人一看，你丟擲的三個建議都不靠譜。當十個故障中，有八次，不用八次，如果有個四五次都是這樣的，以後所有人都不會看這套系統了，太不靠譜了，還不如人來判斷。這個系統難度非常高，需要整個公司堅定地朝這個方向走，並且更好的積累很多的資料。

故障修復，阿里現在只嘗試了一些非常簡單的案例，對於阿里來講，比如一個機房出故障，因為整個阿里巴巴交易體系的架構是支援多點的，對於我們來講如果在某種情況下，我們判斷一個機房出故障，我們可以自動的做一些流量的切換等等。但阿里現在也認為，智慧化在穩定性，尤其故障修復這種動作上，還是要非常小心，萬一沒事切出了問題，這影響更大。

用智慧化做好故障定位

我們以前一直都認為定位這個問題不是個大問題，如果我能快速修復，定位，你慢慢定好了，定個兩天我也無所謂。但是現在阿里特別重視的原因在於，故障定位損耗了我們非常多的人力，耗費了我們非常大的團隊力量。所以我們認為需要有更智慧化的方法，把故障定位出來，以助研發團隊更專注投入在其他事情上。比如現在故障一出來，研發查了半天，一看，跟它都沒有什麼關係。所以就浪費了很多，這張圖是我們現在在做的一套系統，從一個異常，那裡標一二三四五，當有一個異常出來之後，第一步發現，第二步不斷的分析，一直定位到最後到底是哪個地方出了問題，我們的目標是最後儘可能定位到程式碼層面的問題，或者是網路或者是基礎設施等等。

邊壓邊彈 做好規模化運維

目前對阿里來講最重要的問題還是效率問題。比如說我們在每年準備雙十一容量的時候，很多人都知道阿里有全鏈路壓測，一個最重要的目的就是調整容量，怎麼把一個機房的容量調整成比率是最合適的，比如說 A 應用可能是瓶頸，但是事實上如果搭配得好，A 應用就不再是瓶頸。所以怎麼樣讓一個固定機器數下做一個最好的搭配，我們以前是壓一輪調整一下，再壓一輪再調整一下，這非常耗費一堆人通宵的精力。我們認為這個過程需要提升，現在改成非常簡單的模式，流量過來以後不斷的自動調整容量比例，我們會有一個所謂邊壓邊彈，一邊壓測一邊調整比例。相信很多運維同學都幹過這個事情，因為業務方給你一個指標，你是要算的，而且很難算的很精準。邊壓邊彈意味著你不需要算得很精準，粗略算一個數就可以了，後面靠這套系統自動給你調平衡。

阿里巴巴在這五個方面，在智慧化方面做的探索，阿里認為我們還不足以所有的領域都去覆蓋。

未來運維領域需要突破的防線

無人化 讓夢想照進現實

我認為現在運維這個領域中最大的挑戰仍然是，能不能真正的走向無人化，整個過程中是完全沒有人的。

從目前來看，要做到無人化最重要的是質量問題，質量做得不夠好是沒有辦法無人化的。另外如果出問題了能不能自動修復等等，所以我們認為無人化對運維領域是最大的挑戰，能不能把這個落地變成現實，奠定了智慧化的基礎。如果說智慧化所有的動作要人介入，那基本就不用做了。

智慧化 帶來效率上的質變  

在智慧化這一點上，第一點是有效性的問題，如果這個智慧表現得比人的智力還差一些，這個慢慢就沒有人相信這個東西了。所以怎麼樣把有效性提升上來，另外最重要的是要看到智慧化給運維領域帶來效率上的質變。智慧化投入非常大，要做大量的收集做大量的分析。所以最好帶來的是質變而不只是量變，如果只是量變可能投入都收不回來。對於所有公司而言，更少的人更低的成本是非常重要的。人最好投入在一些更重要的研發等等事情上。

原文來自微信公眾號：高效運維開發