作者介紹
朱祥磊，山東移動boss系統架構師，負責業務支撐系統架構規劃和建設。獲國家級創新獎1項、通信行業級科技進步獎2項、移動集團級業務服務創新獎3項，申請發明專利13項。
系統規模的不斷發展以及應用軟體架構的發展，推動着自動化運維的演進。是以在說自動化運維之前，需要先說說應用軟體架構的發展簡史。回顧過去，應用軟體架構先後經過了單塊架構、多層架構、服務化架構、分布式、微服務架構等：
單塊架構
應用軟體發展早期，系統規模一般很小，特點是應用功能集中、代碼和資料中心化，表現為一個軟體釋出包，集中部署，各子產品運作在同一個程序的應用程式。此時一般幾台機器就可以完成全部應用軟體功能。
以web應用程式為例，在web應用程式開發的早期，由于受到面向過程的思維及設計方式的影響，所有的邏輯代碼并沒有明顯的區分，是以代碼之間的調用互相交錯，錯綜複雜。譬如，我們早期使用的asp、jsp以及php，都是将所有的頁面邏輯、業務邏輯以及資料庫通路邏輯放在一起，這是我們通常提到的單塊架構。
在這種架構下，所需的機器數量很小，完全的scale-up模式，據說ibm公司在上世紀50年代曾經宣稱， 全世界隻需要5台計算機就夠了！
多層架構
為了解決單塊架構擴充性差的問題，同時解決代碼集中帶來的并行開發測試困難等問題，逐漸出現了多層架構，把表示層、業務邏輯層、資料通路層适當分離，分别打包部署。如通過實作model-view-controller的模式将資料、業務、展現進行分離。還有一種rpc架構，通過遠端過程調用實作應用架構分離。
此時每層都獨立打包，獨立部署于容器和單獨的伺服器中，應用結構更加複雜但也更加清晰，當然所需的伺服器數量就進一步增加了。
服務化架構
多層架構盡管大幅提升了應用的擴充性，但是随着軟體和系統規模的不斷擴大，垂直應用越來越多，應用之間互動不可避免，此時層間應用接口變得越來越龐大，最終會變得難以管理。通過将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速地相應多變的市場需求，也使不同服務的獨立擴充成為可能。
在這種模式下，可以按服務進一步拆分部署，應用可以擴充到更多的機器和容器上。
分布式雲化架構
随着業務不斷發展，硬體成本的下降，基于x86架構的廉價硬體+分布式軟體的模式日趨成熟，得到了大規模應用，分布式服務架構逐漸替代傳統的服務化架構，解決了傳統服務化的弊端，例如企業內建總線esb是實體總線，性能線性擴充能力有限，硬體負載均衡器的壓力越來越大，不斷擴容導緻硬體成本增加，随着業務規模的不斷增長，傳統的資料庫、配置中心等逐漸成為單點瓶頸。當然應用也徹底變為了scale-out架構，導緻機器和容器數量大幅上升。
微服務架構
微服務架構是對上面分布式雲化架構的拓展、服務化的進一步延伸，通過對服務進一步細化，形成微服務，運作于單獨的容器平台，可實作雲的彈性和靈活，如彈性伸縮、線上線下一緻的環境、提升自動化運維能力等。
别着急，下面再允許我介紹下自動化運維的内容，究竟包含哪些内容？
硬體和網絡的自動管理
雲化、虛拟機的自動管理
作業系統和軟體的自動化安裝、配置
正常任務（健康檢查、安全加強和檢查、備份、清理、資料管理、彈性伸縮等）
手工任務（容災切換、應急操作、應用部署和起停……）
監控
問題診斷
可視化
其中1、2、3主要是傳統iaas層關注的工作内容，重點是計算、存儲、網絡的自動化管理，4到8主要是paas層關注的工作内容，iaas層和paas層互相結合，共同完成自動化運維。
好了，終于到正題了，自動化運維前世今生來了…..
史前時代：此時系統規模很小，一般幾台，不超過幾十台，此時一般通過手工單台登入即可滿足運維要求。
中世紀時代（集中管理階段）：系統規模有了較大擴充，從幾十台到上百台，此時再通過手工方式已經無法進行，于是出現了各種shell腳本，通過腳本實作相關的運維，腳本僅僅是針對特定的場景，難以實作全流程的自動化。
中世紀拓展（集中管理的進階）：為了友善管理以及可視化，出現了各類商用或開源工具軟體實作自動化運維，如hp openview、puppet、saltstack、chef等等，做為腳本方式的提升。
新時代：系統規模進一步擴大，從上百台演進到上千上萬台，以前的方式由于存在弊端，如缺乏統一的cmdb或太簡單、不支援複雜環境、缺乏友好的可視化界面等，難以滿足要求，此時又出現了幾個分枝：
分枝一：從底向上的雲平台方案：通過雲管理平台實作計算、網絡、存儲的iaas層自動化管理，同步建立軟體paas層自動管理，最終實作融合。
分枝二：從上向下的雲平台方案：通過上層paas層自動化管理，逐漸向下探索，如容器等。
新生代自動化運維初探
下面重點介紹幾個自動化運維工具或平台：
openstack
openstack是iaas層目前最活躍的一個開源的雲計算 iaas 平台，即雲作業系統，類似于aws（亞馬遜的雲服務），通過各種開源元件實作了不同功能，目前大部分雲管理平台均基于openstack實作計算、網絡、存儲的統一管理，openstack支援如下功能元件：
計算服務（nova）：按需提供計算資源，建立和管理批量虛拟機 ，動态虛拟機管理：建立、重新開機、調整大小、遷移等。
對象存儲服務（swift）：基于普通硬體的大規模存儲，無中心節點，分布式存儲、水準擴充，同時多資料備份，保證安全，通過api接口對外通路。
塊存儲服務（cinder)：為虛拟機提供雲硬碟。
網絡服務（neutron）：為虛拟機提供網絡通路能力。
編排服務（heat）：提供自動化部署及管理服務。
資料庫服務（trove）：提供資料庫管理服務。
認證服務（keystone）：提供身份認證機制服務。
鏡像服務（glance）：提供虛拟機鏡像存儲服務。
監控服務（ceilometer）：提供計量與監控服務。
dashboard（horizon）：自服務、權限、圖形化界面。
openstack盡管對iaas層的自動化管理比較強大，但仍然需要注意如下幾點：
1、openstack版本衆多，如何選擇是一個難題。
例如存在社群版、發行版、商業公司定制版本等，如何選擇是一個難題，而且openstack每半年一個穩定版本，演進很快。一般認為對openstack項目中的開源代碼進行修改定制是個不錯的主意，但這從長期角度來看不一定最佳。“定制雲”很可能需要付出高昂的代價，不僅投資巨大、成本高昂，企業使用者還将被迫面對一大堆後續的管理及維護開銷，并被綁定在單一供應商或版本身上。
建議企業如果有很強的技術能力的話，可以根據自己的需求做定制，但需要把握好和社群發展的關系。 一般來說，需要根據自己的需求，選擇合适的版本，盡量不改變社群版本，定制化需求盡量在外圍進行改動。如果采用了廠商的版本，實際上也是某種綁定，可能離社群越來越遠。
2、需要慎重選擇相關元件合功能
由于openstack理念是分布式、最終一緻性，是以所有的原始功能元件都是基于這一設計，企業使用者考慮采納openstack之前，必須對企業業務應用進行分析：應用程式是否有可擴充性和彈性伸縮的要求？ 應用程式是否可以接受最終一緻性？ 應用程式是否無狀态化？ 應用程式的性能要求？應用程式的可靠性要求？ 應用程式的安全要求？ 應用程式的容災備份需求？ 不同的要求決定了openstack不同的計算、存儲、網絡等子產品設計。
3、openstack對paas層和實體機管理較弱，需借助其他工具實作
openstack已經能夠支援很多的iaas自動化運維和部分paas自動化運維任務，但不能滿足全部，如批量運維、深入監控、軟體管理等功能缺少，特别是對實體機運維較弱，一般需要結合其他paas層管理進一步完善自動化運維體系。
saltstack+定制
paas層自動化運維工具就太多了，例如監控就有nagios、ganglia、zabbix等，運維工具則有puppet、chef、saltstack、ansible等，不同企業根據企業自身開發實力、結合配置管理工具的資源豐富程度、依賴複雜程度考慮，會有不同的選擇。通過對運維工具本身的研究，結合運維人員的運維經驗和評估企業未來的規模，下面以開源saltstack+定制實作的方案進行介紹。
saltstack是繼 puppet、chef 之後新出現的s配置管理及遠端執行工具，與 puppet 相比，saltstack較為輕量；不像 puppet有一套自己的 dsl 用來寫配置，saltstack 使用 yaml 作為配置檔案格式，相對簡單，同時也便于動态生成；此外，saltstack 在遠端執行指令時的速度快，由于使用了zeromq，這個下發過程可以并行執行，速度比ansible的無agent ssh通信快得多，是一個分布式遠端執行系統，用來在遠端節點（可以是單個節點，也可以是任意規則挑選出來的節點）上執行指令和查詢資料。
從部署結構上看，saltstack的在部署上可以分為master和minion兩個部分，其中master相當于統領所有機器的總管，而minion則是部署在被管理機器上面的agent程序，master通過網絡将配置管理相關的操作下發到minion，由minion在對應機器的本地執行。典型的部署例子如下圖所示：
在現實生産環境中，大批量的使用者建立需求，檔案上傳需求、配置變更需求、軟體更新需求占用了維護人員大量的時間，引入saltstack後，該工具的遠端執行和配置管理可以解決該問題，真正實作批量化和自動化，滿足海量運維的需求。
容器
有了openstack和saltstack為代表的的paas層自動化工具還不夠，針對應用自動化運維場景，如彈性伸縮、devops（開發運維一體化、開發測試一緻的環境、自動資源排程、應用日志統一管控、應用服務的編排、微服務管理等），此時出現了容器技術，容器技術實作有很多種，但最流行的是docker。
傳統容器技術相較虛拟機優勢不是特别大。docker能夠流行一大重要是以就是它的創新--docker鏡像。docker建構了一整套建構、釋出、運作體系：容器（container）、倉庫（repository）、鏡像（images）。傳統容器隻解決了容器運作（run）的問題。而docker定義了一套容器建構（build）分發（ship）的标準，使應用管理非常便捷，尤其适合微服務管理。
注意容器對應用有特定的要求，并不是所有應用都适合，例如需要無狀态化、鏡像檔案不能太大等。
自動化運維需要注意的幾點：
一般的自動化運維工具均缺乏良好的可視化界面，需要進行結合定制開發。良好的界面可以更易于在企業内部推廣自動化運維。
自動化運維工具衆多，各有所長，應結合熟悉程度、技術特點進行針對性選擇。
多層的自動化管理工具，多頭的配置管理是個難題，建議考慮定制化，設計統一的cmdb，做到一點配置，多點更新。
ok，本文就到這裡，由于自動化運維是個很大的話題，涉及話題很大很廣，這次僅僅是答題的概述，後續将結合專題進行細化讨論。
原文釋出時間為：2017-02-28
本文來自雲栖社群合作夥伴dbaplus