概述
運維體系經歷了指令碼時代、工具時代以及目前的DevOPS時代。另外在未來走向自動化運維和智慧化運維時代。
指令碼時代是所有公司都會經歷的過程，運維工作需要透過指令碼來操作，但隨著業務擴大和複雜度增加，透過指令碼越來越難以完成，所以就引入工具理念，在運維工具時代，通常都會經歷從純粹的工具團隊/運維團隊並行的階段，為了更好保障工具質量的在進入到工具團隊階段，再到逐漸由DevOPS思想和只能的偏軟體思想的工具團隊時代，到後來的應用運維團隊全部打散合併到各個BU的軟體開發團隊中，全面實踐DevOPS思想。
運維演變
運維是一種能力而不是一種崗位。研發人員將具備運維自身產品的能力，同時運維人員具備研發能力，技術將不在成為限制業務發展的瓶頸，DevOps帶來的效能提升反而能助力業務的構建。
指令碼化
應用運維團隊，首先要做所有日常運維的工作比如釋出、擴容、重啟、修改指令碼等，另外就是環境維護，比如作業系統升級也是運維來負責。除了這些日常工作還會負責容量管理，比如某個流量大的時期要確定擴容多少。
在這個階段透過指令碼來進行運維工作，寫一些單機指令碼，數量多而且還有一些批次操作的措施。
這個階段最容易出問題，複雜的邏輯會非常難實現。比如你的伺服器數量多分佈在不同城市，通常釋出時間視窗並不長，如果釋出的應用比較多，你就需要開啟很多視窗，最後你自己可能都不知道哪個視窗是更新的那個城市機房的伺服器，哪些更新了哪些沒更新。因為更新的時候肯定不能全部更新一定是分批進行的，要保證業務可以正常使用。
工具化
工具化非常簡單，思想就是透過軟體的系統實現複雜操作，複雜操作的本後其實可能是單機上的指令碼操作，因為這對運維人員來說便於維護，如果全部程式化就非常難了。
在這個階段通常會有一個工具團隊，專門做運維繫統專門做軟體層面的開發，同時保留運維團隊，運維團隊主要負責之前提到的哪些內容。這就意味著工具團隊不負責這些具體操作只負責寫系統。開始這2個團隊是分開的，然而在實際工作中也發現不少問題，工具團隊覺得自己做了很多工具，運維應該可以很輕鬆；運維告訴你其實並不是這樣，基本上跟以前差不多。
這裡的問題就是運維只是操作方式變化了，變成了點點點只是UI上的區別並沒有實質變化，而工具團隊也很容易有成就感認為做了很多可是別人不認可。出現這種問題的原因是工具不夠完善，工具使用過程中如果工具出現問題運維很難介入，只能讓工具團隊來解決，在這種情況下還不如手工操作指令碼執行這樣出現問題自己可以查。
另外如果把運維分成很多團隊比如網路、伺服器等每個團隊都是獨立的，他們去開發工具都是按照自己熟悉的語言和架構來編寫，這就變成百花齊放什麼都有，一出問題各種語言的各種架構的人都要來，生產系統是一個整體框架而運維繫統則是一個各自為政的狀態。
所以需要對工具團隊進行合併。向對待一個研發專案一樣去看待運維繫統。另外需要要工具團隊自己做運維工作，這樣就成為一個團隊的工作，不存在協調溝通問題。
另外工具化的前提是標準化，目錄結構、賬號等等，前期一個坑後期需要很多時間和經歷去解決。
DevOPS
Google的SRE團隊要求50%時間開發50%時間運維，但實際我們做不到因為運維壓力太大了還是別做開發了。但谷歌認為如果運維時間超過50%則會把這個壓力轉到研發團隊。那麼如何做好這個思想的落地？
決定把整個運維團隊拆掉，直接交給研發團隊，目標就是日常的運維操作逐步讓研發自己去做。但這個前提是，比如說你要把日常的運維操作全部交給這個系統的研發人員去做，意味著需要有一套很高質量標準的運維繫統，如果你沒有這個系統那研發就要崩潰了，所以這裡的挑戰是工具化的程度。
因為把這些工作交給了研發團隊，所以在這個階段可以把之前在工具化階段遇到的問題解決掉。
如何將這種思想落地是一個需要思考的事情，在這裡Docker是非常有效的讓DevOPS強制落地的方法，因為它有一個DockerFile，生產環境的一臺機器的整體環境，可能不是研發獨自搭建出來的，有可能是運維做一部分開發做一部分，所以沒有一個人請出這兒環境到底是什麼。而DockerFile強制描述了這些環境資訊，所以這個強制方案可以讓DevOPS很好的推進。
自動化
自動化意味著，怎麼樣讓工具中人參與的多個環節直接到沒人參與，這實現起來其實非常難。
比如釋出，釋出時運維中最常發生的變更，一個釋出動作怎麼做到沒有人？為什麼很難？比如釋出完一臺機器之後重啟了，你怎麼知道重啟完應用到底是否正常，這個標準很難去確定。
另外做到無人值守還會需要做到架構層面的支撐比如機房流量一鍵切換如果各個系統不具備這個能力，整個架構也不會具備。
智慧化
智慧運維、智慧化的前提是需要有大量的資料收集，如果沒有足夠的資料和經驗是難道做到自動化的，因為智慧化的前提是就是自動化。
目前的自動化只能做到針對非常強的特徵匹配因為畢竟目前很多時候還需要人去判斷。只有當你有大量實踐經驗和準確的資料之後才有可能做到，而且所謂的經驗如果不是格式化的就很難學習，還有特徵，人工提取的特徵意味著是偏向固化的，所以需要機器學習去提取特徵。
DevOPS轉型不是簡單的把工作量從運維轉向開發，目的是用研發的手段去改造傳統的人工、低水平的運維，真正用工具化、資料化來提升運維。
總結
在運維上，要避免的是開發系統的人不知道這個系統是如何部署和運維的，這樣知識不完整。很多系統開發簡單，但規模大，部署導致了複雜性，研發部知道這些，對系統認識不夠，也就不知道程式設計十分合理。
把日常工作交給研發、讓運維同學能有時間去做運維繫統的研發。這樣研發同學對自己的系統的執行環境更加清楚，增強控制權，自己寫的系統自己負責，同時運維也可以建設更好的系統。其實運維工作方式的變化也在倒逼運維人員的轉型，如果還停留在人肉上線的階段那麼被時代所淘汰是必然的，目前一二線網際網路公司已經沒有了人肉上線工作全是開發自己上線運維人員的角色得到了轉變同時在這種轉變過程彙總能力也得到了提升。不過小型網際網路公司還處在指令碼和工具化階段，這個沒辦法大公司也是這樣一步一步走過來的在阿里早期也是這樣一臺電腦開啟N多個shell指令碼進行停服務更新服務啟動服務的階段。所以我覺得目前運維轉型是一個自我驅動的過程而不是公司推動，因為真的到了公司去推動的時候你已經沒有價值了。