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

    這個行業(yè)的發(fā)展跟其他傳統(tǒng)的軟件，標(biāo)準(zhǔn)的軟件研發(fā)行業(yè)，我覺得很不一樣。比如說阿里從工具化到自動化這個過程中，我們認(rèn)為工具化，其實挑戰(zhàn)相對小，即使傳統(tǒng)的運維人員也很容易寫一些工具，比如用 Python 去寫更多的工具體系。但是如果你的工具最重要變成能夠到自動化這個階段，就意味著對工具的要求會越來越高，比如說工具的質(zhì)量，如果你寫出來的工具經(jīng)常有問題，規(guī)模一大就扛不住，這個時候?qū)τ诖蠹襾碇v慢慢會越來越失去信任感。最后會很難完成這個過程。

    運維團隊轉(zhuǎn)型研發(fā)團隊 組織能力是最大的壁壘

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

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

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

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

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

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

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

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

    DevOps是如何真正落地的

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

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

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

    成功率是衡量自動化運維的關(guān)鍵指標(biāo)

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