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

    監控 AI 化

    智能報警

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

    異常檢測直接影響到效率

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

    穩定性是以效率為原則

    故障修復要精準且快速

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

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

    用智能化做好故障定位