我今天想跟大家分享一下基于網易的一些互聯網產品運維的經驗，跟大家聊一聊容器在運維這塊的一些實踐和經驗。

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

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

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

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