我今天想跟大家分享一下基于網(wǎng)易的一些互聯(lián)網(wǎng)產(chǎn)品運維的經(jīng)驗，跟大家聊一聊容器在運維這塊的一些實踐和經(jīng)驗。

網(wǎng)易云的歷程，大家現(xiàn)在知道比較多的網(wǎng)易云音樂、考拉、網(wǎng)易郵箱。最早網(wǎng)易云是給這些部門提供支撐的，自己在運維上積累了很多經(jīng)驗。這是我們運維部門統(tǒng)計出來從2015年-2016年之間服務器數(shù)量提交的工單增長，主要是因為這些業(yè)務部門產(chǎn)品發(fā)展非常快，所以它的規(guī)模發(fā)展也非常快，很多問題都會凸顯出來，比如以前需要手動做的東西，當大到一定規(guī)模的時候，會發(fā)現(xiàn)這個跟不上業(yè)務的發(fā)展。

傳統(tǒng)解決運維的問題有幾種，另一些是用配置管理工具，比如Puppet等，某個軟件需要在哪些服務器里是有的，或者直接給他一個版本或者某個配置文件，需要它存在某個路徑里，現(xiàn)在可以做更多的事情。但是傳統(tǒng)的這些解決辦法也有一些它自己的不足，比如自動化工具在做的過程中，可能會碰到這個節(jié)點在操作、更新或者部署的過程中，節(jié)點連接斷了，或者說操作過程中導致操作系統(tǒng)或者應用出了一些問題，你沒辦法回滾，也沒辦法繼續(xù)進行下去，你只能說登錄上去看一下怎么回事。配置管理工具也有一些問題，你要寫一個規(guī)則或者模板去定義你希望這些節(jié)點是處于一個什么樣的狀態(tài)，比如說你更新軟件，它是對于你正在提供服務的節(jié)點進行更改，比如你提供一個工具的更新，你更新過程中這個工具是用不了的。如果是操作系統(tǒng)級別的更新，可能還是需要在整個虛擬機的生命周期做這些操作，可能還是要有些重啟的操作。這些傳統(tǒng)的方法我們自己也用過，他們是解決了以前的一些問題，但是仍然還有些問題。另外，不可變基礎架構，當我需要去做一個更新的時候，我不是對現(xiàn)在正在工作的節(jié)點去做更改，去更新、打補丁、改配置，而是說去重新創(chuàng)建一個節(jié)點，用新的文件，用新的應用版本去發(fā)布新的節(jié)點，然后去替換現(xiàn)有的節(jié)點。這是它和傳統(tǒng)方式非常不同的一點，如果我想從一個1.0的版本升級到1.1，我傳統(tǒng)的方式可能是不管手動也好，用自動化的工具也好，把這個舊的版本卸載掉，或者直接升級到1.1版本。不可變架構是舊的節(jié)點不要了，重新創(chuàng)建一個跟它一模一樣的節(jié)點，但是這個節(jié)點裝的是1.1的版本。我的基礎架構怎么可能不變呢，總會有些配置是要改的，總會有些補丁要打的，包括一些安全的漏洞，可能還是要去做的。

并不是說整個系統(tǒng)不變，這個系統(tǒng)指的由多個組件、多個應用組成的系統(tǒng)，而是說系統(tǒng)中的一部分可能是無狀態(tài)的應用，這些無狀態(tài)的應用，尤其現(xiàn)在大家說得比較多的分布式的應用，總會有一些是無狀態(tài)的應用，部分采用不可變基礎架構是比較合適的，而那些有狀態(tài)的部分，可能還是要通過傳統(tǒng)的一些。我們也看到有些公司已經(jīng)在用類似的基礎架構去管狀態(tài)的服務，但是挑戰(zhàn)會更大。不可變基礎架構和傳統(tǒng)模式的變化，右邊這個圖大家都很熟悉，典型的軟件層代碼發(fā)布到管理工具，CI/CD這個流程，部署到測試環(huán)境最后上線的典型過程。其實有很多地方是沒有變的，它相比傳統(tǒng)模式怎么變化，以前我的運維，尤其是修補的那部分，我系統(tǒng)上線以后我發(fā)現(xiàn)要更改的那部分，我是在系統(tǒng)上線以后做的，不可變基礎架構的理念是說把這部分工作移到你前面在提交代碼和構建鏡像的那部分，把這部分工作放到這邊去做，包括你環(huán)境配置的更改都是提前去做。它不影響你現(xiàn)有的已經(jīng)上線的環(huán)境，不會影響你現(xiàn)在的服務，你仍然可以繼續(xù)提供服務，我會去發(fā)布一個新的環(huán)境，去把流量導過來。原來做的那些更改，有可能產(chǎn)生風險的那些操作提前了。這么帶來一個好處，你能提前發(fā)現(xiàn)你的錯誤，因為有時候你做一些更改，理論上做任何更改都是有風險的，你打一個補丁，你不知道可能會影響某個依賴或者操作系統(tǒng)哪塊出問題了，就會導致一些不可預計的問題。但是你如果是提前去，在預生產(chǎn)環(huán)境就能發(fā)現(xiàn)這個問題，你能很快修復這個問題，最重要是你的服務并沒有中斷，這是它和以前很不一樣的理念的地方。

我們的變化就是在不可變基礎架構里，我們做的變更修改是可以做版本控制，做版本控制帶來的好處是，可以做自動化，可以像管理代碼一樣去管理你的這些基礎設施。我們以前在做傳統(tǒng)運維的時候，我們上線的那些節(jié)點，很可能很多操作你是沒有記錄下來的，沒有書面記錄或者有一個系統(tǒng)記錄你做了什么東西，你改了某個配置，你改一個host文件，你去打一個補丁升級的庫，沒有這種記錄。而且你的記錄是很難有版本化的，你可能是在你團隊的某個文檔里去寫，而這個文檔可能只有做這個操作的人才知道，其他維護的人有可能根本不知道有這么一個文檔。很難把做下來的那些辦法記錄下來，以后如果其他的系統(tǒng)或者你要把這個業(yè)務節(jié)點遷到另外一個平臺上，你其實不敢遷，因為你都忘了你自己做了哪些操作了，時間越來越長以后，其實你在系統(tǒng)上做了很多事情。