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

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

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

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

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

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

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

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

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

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

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

    DevOps是如何真正落地的

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

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

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

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

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