如何設計並實現一個通用的應用運維管控平台

01-30

一、問題背景：

大部分的應用運維工作隨著伺服器數量和產品數量的增長而增加，而運維人數的不足導致單個運維人員所承擔的工作任務較為繁重，同時運維工作的不標準、無自動化使得應用運維任務十分複雜，耗費的大量的人員成本、時間成本和溝通成本。

應用運維工作說白了大體可以分為兩種情況：1. 在某個或某些伺服器上執行某個腳本或命令；2.將某個或某些文件傳輸到某個或某些特定的伺服器的特定位置上。在伺服器數量較少的情況下，可以通過ssh或scp命令實現上面兩個操作；伺服器數量較多的情況下，我們可以通過包裝ssh或者使用批量ssh工具，如pssh，ansible等來解決問題，但這種方式大多數都是一次性的方式，無論使用方法以及後續跟蹤來看都並不友好。

還有，由於一系列歷史原因，現網的服務環境也較為繁雜，現網的伺服器上的代碼、配置、軟體包、腳本等文件沒有進行統一的版本管理與配置管理，比如某個產品的代碼版本多種多樣；現網的代碼和文件幾乎都是通過一台複製到另一台的方式來實現；由於代碼版本、配置版本等問題導致的現網質量事件也並不在少數。

另外，應用運維也需要一個統一的資源管理系統，對現網的服務的數據進行業務維度的資源管理，系統運維的CMDB系統只在靜態資源維度進行了管控，動態的業務數據等資源需要應用運維團隊自行來管理。

因此，針對上面所述的各種問題，需要一個運維管控系統，來解決包括：資源管理、配置管理、任務管理、文件發布等一些列常用的運維跟蹤，通過簡單高效、自動化的方式將繁瑣的應用運維工作通過管控系統來完成，即可以降低運維的難度，也可以提高運維的效率，同時可以提高運維操作的成功率，並實現運維任務的持續跟蹤和管理，甚至在不遠的將來可以實現移動運維。

二、功能結構：

經過上述的分析和整理，我們將整個管控平台的功能細化到如下幾個大功能，如圖所示：

三、詳細設計：

這裡圍繞上面功能結構圖中的4個大功能，進行詳細的分析和設計，其中移動運維功能為附加功能，這裡暫時不介紹。

n3.1 資源管理n

先說資源管理，資源管理是一切後續自動化運維功能的前提，也是所有自動化功能的數據依賴。

資源管理的功能可以較為薄弱，但是對數據的要求比較高，可以基於系統運維的CMDB系統進行二次構建，主要的功能可以分為：

物理機資源管理：物理機資源管理功能，需要將CMDB中所有交付到應用運維的物理機資源進行重新整理，按照二級業務產品線進行管理，支持多種伺服器狀態（如部署中，備用池等等）標註。可以基於物理機資源管理系統進行伺服器初始化管理操作，加快服務初始化部署工作的效率。物理機資源管理對於後續的配置管理和作業管理來說是最為重要的，是後續兩個功能的數據基礎。

管理虛機資源管理：所有的管理服務都部署在管理虛機上，因此我們也需要對管理虛機進行管理，管理虛機的數據和物理機資源管理一樣，可以依賴系統運維的CMDB中的數據進行二次管理，功能和物理機資源管理類似，這裡不再闡述。

虛擬資源管理：虛擬資源管理就是在每一台物理機上的虛擬機/業務DB的資源管理，可以基於業務管理資料庫中的數據進行二次整合，或者通過數據採集上報的方式實現，儘可能的做到虛擬資源數據的有效性和狀態一致性。

n
虛擬資源數據在進行後續的虛擬資源管理、虛擬資源遷移等功能上會有較大幫助，可以基於虛擬資源管理完成自動化的實例遷移工作，節省大量的手動實例遷移任務。另外虛擬資源管理對宕機恢復或機房、機架斷電等問題也會有較大的幫助。
n
整個資源管理比較簡單，可以優先完成物理機資源管理功能，再實現虛擬資源管理功能。

3.2 作業管理n

作業管理是應用運維管控系統的核心功能，也是應用運維工作中最經常使用到的功能，作業管理功能也可以分為如下子功能，如圖所示：

下面將分別對上面幾個子功能進行詳細介紹：

1. 腳本執行：

腳本執行和文件分發是整個作業功能的基礎功能，其他的功能都是通過對著兩個功能進行組裝和裝飾來實現的。

腳本執行的表現形式就是運維人員在頁面中提交一個腳本，腳本建議支持shell和python兩種形式，可以通過三種方式：

1）手動書寫；也就是在頁面上的編輯器中編寫腳本；

2）上傳腳本；也就是通過瀏覽器將本地的腳本上傳到系統中；

3）克隆系統腳本；所謂的系統腳本就是運維人員通過上面兩個步驟提交到系統中的腳本，可以分為基礎系統腳本和用戶系統腳本，基礎系統腳本就是那些我們明確可能會多次執行的腳本，比如伺服器初始化等腳本；用戶系統腳本就是用戶自定義的腳本，可以實現任何功能。

腳本的編寫要依賴一定的語法規範，我們可以為shell和python語言提供基礎的類包和函數庫，同時所有的腳本的執行結果都會根據腳本的exit的 $? 值來判斷，$? 值為0，則表示該腳本執行成功，若為其他值則表示腳本執行失敗。腳本的輸出內容會存儲到資料庫中用於後續的問題跟蹤和排查，因此需要運維人員寫腳本的時候注意寫上詳細的日誌內容。

腳本支持輸入參數。用戶可以在頁面中的參數一欄輸入執行參數，當然也可以直接寫到腳本里。

支持選擇執行賬戶。目前大部分服務的運行賬戶仍然是root用戶，後續可能會改成非root用戶，所以這裡支持選擇執行賬戶，具體的賬戶名稱，可以在用戶管理的功能中維護。

支持選擇所執行的伺服器。用戶在選擇好相應的腳本之後，需要指定在哪些伺服器上執行該腳本，因此需要支持選擇所需的伺服器。這裡面伺服器選擇分為兩種模式：

1）本地執行模式；本地模式指，該腳本的執行並不會到遠程伺服器去執行，而是在管理服務所在的本地執行，這種模式可以用來判斷遠程伺服器是否啟動等功能，或是某些只能在管理伺服器上執行的命令；

2）遠程伺服器執行模式；遠程伺服器執行模式就是比較常規的將腳本發送到遠程伺服器上，並在遠程伺服器上執行的模式，這種模式需要選擇所需要執行伺服器列表，這裡就需要依靠資源管理系統中的物理機管理功能了，可以通過某種方式對伺服器進行手動分組或自動分組，然後執行的時候可以按照不同的維度（比如按ip選擇，按機房選擇，按業務選擇，或按自定義組名選擇）選擇所需的伺服器組，進而將腳本下發到這些伺服器上執行。

總結一下，腳本執行功能比較基礎，同時還包含三個子功能，這三個子功能放到配置管理裡面去實現，後面會具體闡述：

1）腳本管理功能；用於管理用戶上傳的腳本和常用的基礎腳本。

2）賬戶管理功能；用於管理具體的執行用戶。

3）伺服器分組功能；用於基於資源管理系統的物理機管理數據按照某種方式劃分成一定的伺服器組。

說完具體的功能之後，我們需要確定具體的實現方式，準確的說，實現方式有兩種：

1）SSH遠程執行；可以通過封裝ssh和paramiko的方式實現，python中的ansible和fabric包也都支持遠程SSH執行的功能。Shell就用ssh命令即可。

該方式對中心節點要求比較高，每一個遠程執行命令都會在中心節點啟動一個進程（線程）來執行，對中心機的壓力較大，同時由於是基於SSH的原理，故命令執行的效率較差，命令執行時間長。

2）Agent執行；在每台伺服器上部署一個Agent，用戶執行管控系統發送的腳本。這種方式的優點是可以採用拉的方式，由各個子節點訂閱分給自己的任務，執行完成後再講結果推給中心節點的數據；當然也可以像SSH方式通過推的方式由中心節點將任務發給遠程的Agent，然後Agent去執行，並將結果反饋給中心節點。這種方式的執行效率會比較高，可擴展性強，將來甚至可以通過該Agent進行配置或運行數據上報，對於配置管理也比較方便，缺點是需要開發Agent，Agent需要支持非同步非阻塞模式，且需要維護每台伺服器的Agent，包括部署和管理。

Python的saltstack軟體就是通過Agent的方式實現的，需要在每台物理機上部署一個saltstack minion進程用於接受任務和執行任務，在每個中心機上部署saltstack master進程用於下發任務，saltstack master通過將任務下發到zeromq中從而實現各個minion獲取任務並執行，同時saltstack也支持將任務執行結果存儲到Redis等資料庫中，便於後續的跟蹤和查看。

不過Agent也可以通過自行開發的方式實現，線上所有的Agent大多都是這種原理，也都是自己實現的，不過具有一定的開發難度。

因此對於腳本執行的實現方式來看總結如下：

1）如果用SSH的方式，使用python的ansible api或fabric。

2）如果用Agent的方式，可以考慮使用Python的saltstack minion Agent。

3）如果用自研Agent的方式，可以使用golang。上面兩種方式相對快速容易實現，這種方式會有一點的時間消耗，不過可以積累一定的開發經驗。

2. 文件分發：

文件分發是除了腳本執行的另一個基礎功能，該功能的技術描述就是將某台伺服器上的某個或某些文件，傳輸到其他的某個或某些伺服器的某個位置上。

文件分發功能分為以下兩個子功能，相關文件和模板的管理工作放到配置管理中去實現，這裡只介紹如何實現文件分發：

1）普通文件分發，如代碼包，鏡像文件，軟體包等。

2）模板文件分發，如配置文件等。

模板文件分發與普通文件分發不同的區別是模板文件中存儲變數替換的邏輯，這裡普通文件的管理和模板文件的管理以及配置變數的管理都放到配置管理系統中去實現，用戶選擇文件下發的時候可以選擇是普通文件還是模板文件，如果是模板文件就會自動去載入配置管理中的變數管理生成臨時的普通文件並下發。

具體的下發方式也分為兩種：

1）管理機文件下發到普通的業務物理機上。

其實大部分的文件分發場景應該都是這一種，也就是我們將基礎文件或模板文件放到管理機上，作為我們的基準文件，比如我們的部署代碼，軟體包等等，我們只要保證管理機上的文件版本的一致性，就可以保證普通的業務物理機上面的文件和管理機上的文件一致，也就是配置管理功能的中的文件版本一致性管理。

這種模式下的文件可能相對容量較小，比如小文件（幾k），軟體包（幾M），或者稍大文件（幾G），文件從管理機下發到某些業務物理機上面臨的問題是並發導致的傳輸速度問題，小文件情況下還可以忽略，基本可以在秒級完成，但稍大文件的傳輸就會有時間問題，隨著業務物理機的個數增加而增加，因此這種情況會有並發和流量的控制。

另外文件的傳輸會提前進行文件md5的對比判斷，如果文件的md5值相同，那就沒有再傳輸文件的必要，在稍大文件情況下可以節省較多的時間。

文件傳輸，可以使用ansible的copy模塊，或者salt的文件file模塊，當然也可以自研方式中封裝rsync的方式，rsync支持文件md5值校驗以及斷點續傳等方式。

2）物理機之間的文件互傳。

物理機之間的文件互傳準確的來說是反配置管理邏輯的，這種方式就和我們現在的文件傳輸方式很類似，也就是從一台伺服器scp文件到另一台伺服器上。對於配置文件和小文件、軟體包等需要配置管理的文件來說，我們需要明確禁止使用這種方式。但這種方式的好處就是可以用來P2P的傳輸較大的文件，比如幾百G的鏡像文件。

對於幾百G的鏡像文件來說，如果使用第一種管理機管理的方式，只能1對多的傳輸將會造成傳輸時間的極大佔用，而使用這種P2P的方式，即可以極大的提升文件傳輸的速度。

物理機之間的文件互傳使用rsync即可，由於文件較大，且可能出現斷點，rsync是比較方便的解決大文件傳輸的方法，需要在每台伺服器上的Agent上對rsync功能進行封裝，支持Agent之間的rsync文件互傳。

物理機文件中需要管理的文件列表，可以通過Agent彙報到配置管理系統中，用戶選擇文件分發的時候，可以選擇配置管理系統中的點對點大文件傳輸功能，配置管理系統中可以自動選擇傳輸源，針對被傳輸物理機的個數，實現真正的點對點傳輸，不需要用戶自己去選擇源文件伺服器，可以節省大量的人為運維操作。

3. 批量執行：

所謂的批量執行功能就是上面兩個基礎功能中在選擇目的伺服器的個數的時候支持多個伺服器，而不是只能選擇單個伺服器。

在使用SSH方式情況下並發的速度會較差，可能控制在單機30-50個任務同時進行。

在使用Agent的方式情況下，任務本身是非同步下發的，可以實現同時1000+任務同時進行。

由於伺服器數量較多，且分機房的模式，整個後端架構會是與目前的UCloud後端架構類似的分散式架構，一個中心任務下發節點，每個機房一個任務中轉節點，每台伺服器一個Agent（或者中轉節點SSH的方式）。

4. 定製任務：

所謂的定製任務，就是可以通過任務組裝的方式，將腳本執行和文件分發這兩個主要功能（可以根據需要添加其他的功能，比如重啟後的伺服器ping探測，埠探測等），將上面的這些功能，按照1、2、3、4、5的方式組裝，具體的支持功能如下：

1）支持使用基礎功能模塊的子任務組裝成完成任務

2）支持設置每個子任務的子步驟的執行控制。比如失敗後停止，完成後停止等待確認，忽略失敗等功能。

3）支持每個子任務的執行伺服器ip修改。

定製任務適用於某些使用頻次較高的任務，比如伺服器初始化上線，代碼版本發布，軟體包更新等操作。

5. 定時任務：

定時任務是對普通的基礎任務以及定製任務實現定時執行的功能，該功能的實現也相對簡單，即按照crontab的分時日月周的語法，支持周期性或者定時性，也可以按照手機創建鬧鈴的方式選擇觸發時間和觸發頻率。

具體的實現方式如下：

1）用戶輸入的時間計劃通過轉換後寫到管理機的crontab服務中。

2）每次有定時任務產生或刪除或修改後生成新的計劃任務。

3）計劃任務中寫明具體的執行命令

4）通過腳本調度API的方式實現任務的定時執行。

6. 灰度計劃：

對於非周期性重複執行的任務，都可以加入灰度計劃功能，該功能又結合定時任務實現。

灰度計劃可以有兩個維度體現：

1）定製任務中的每個子任務的子步驟都可以實現灰度，即上面所說的完成後暫停，或失敗後暫停。

2）物理機個數維度，並發執行的時候支持自定義灰度計劃，比如：任務先執行1台伺服器，成功後隔多久後可以執行第二批伺服器，再間隔一段時間再執行第三批任務。同時可以設置任務失敗條件，比如：任何一台伺服器失敗，則整個任務失敗；或當失敗伺服器的數量達到灰度計劃伺服器數量的百分比後整個任務放棄執行。

上面這些是作業管理系統的主要功能，當然想要實現整個作業管理系統還會有一些其他的子功能，比如：

1）任務結果記錄跟蹤系統。

2）任務重做，重做任務子步驟是否重做控制。

3）腳本內容安全審核功能。

4）其他暫時未想到功能。

3.3 配置管理n

配置管理功能是整個管控功能中十分重要的一環，上面的作業管理系統中很多功能都依賴配置管理系統才能實現。

配置管理整個功能經過梳理之後如下圖所示：

下面將依次介紹上面所述的功能：

1）賬戶管理：

所謂的賬戶管理十分簡單，就是服務運行的時候所使用的用戶，目前線上的服務大多都是root用戶，但是有改成業務用戶的趨勢，故需要有一個賬戶管理功能。運維人員在使用作業管理的時候，選擇相應的用戶進行任務執行。

該功能可以發展成用戶許可權管理系統，即在該系統中控制每一個用戶的系統許可權。生成相應的許可權配置文件，並下發到所有伺服器上。不過用戶管理的功能可能系統運維已經管理，這裡就不再敘述了。

2）文件管理：

文件管理功能比較基礎，其實主要是對管理機上的重要文件進行管理，比如代碼版本，腳本文件，軟體包文件等等，文件類型包括：普通文件，文件夾，壓縮文件和模板文件。

文件管理中，用戶按照一定的規範將所需要的文件放到管理機上的指定位置，並將相應的路徑配置在資料庫中。

文件管理主要用在作業管理中進行文件分發的基礎文件依賴。

3）腳本管理：

腳本管理也是文件管理中的一種，但需要單獨管理，腳本是作業管理系統的基礎依賴。腳本分為基礎系統腳本和用戶自定義腳本兩種。

所謂的基礎系統腳本就是經過嚴格認證過的，可以重複多次使用的基礎功能腳本。而用戶自定義腳本指用戶通過上傳或是通過web 編輯器提交的腳本文件，存儲下來用戶後續可能的重複使用。

基礎系統腳本和用戶自定義腳本都會存儲在管理機的固定位置上，在文件管理中進行管理，用戶在使用的時候選擇對應的腳本名稱即可。

腳本也支持添加標籤，方便記憶和查找。

4）分組管理：

分組管理也是基礎功能之一，在作業系統中腳本執行和文件分發都需要有明確的伺服器ip地址，而分組管理就是將這些ip地址按照特定的用戶自定義的方式來命名和分類，支持添加標籤，用戶在選擇伺服器的時候可以通過搜索的方式選擇到一組伺服器中的一個或幾個。

分組管理依賴於資源管理系統，以資源管理系統的物理機資源（管理服務是虛擬機資源）為依據，用戶選擇一部分伺服器並進行命名或添加標籤從而得到一個新的分組。

分組可以分為靜態分組和動態分組兩種。

所謂的靜態分組指的是確定完分組後，如需變化必須手動添加或修改的分組。這類分組會佔很大一部分。

而動態分組指的是可以通過對伺服器資源的某種匹配而自動將其添加到某個分組中的功能，比如說某個機房新上線N台伺服器，可以不需要手動，而自動的添加到某個組中。這種功能可以通過手動來實現，在技術和時間限制的情況下，可以暫時不考慮。

分組功能還有組優先順序的概念，主要是結合變數管理、模板管理結合使用，這些在變數管理和模板管理裡面再進行介紹。

5）變數管理：

變數管理主要是配合分組管理和模板管理使用，所謂的模板就是在不同的情況層顯不同內容的文件，而如何呈現不同內容就是在模板中配置了相關的變數名稱，而變數的具體賦值則需要在變數管理裡面體現。

變數管理建議使用yml語法格式來編寫，比如如下的格式：

region:n id: 7001n name: jsn mongodb:n hosts:n - 172.27.117.201n - 172.27.117.202n - 172.27.117.203n port: 27017n

編寫完成後解析成格式化的數據，比如下面表格：

nkeynvaluenregion.idn7001nregion.namenjsnregion.mongodb.hostsn[『172.27.117.201』,』172.27.117.202』,』172.27.117.203』]nregion.mongodb.portn27017n

用戶可以選擇兩種可視化方式，但使用的時候需要按照解析後格式化的方式來使用，比如用戶在模板中需要使用某個region的mongodb的伺服器列表，則需要這種方式來使用：region.mongodb.hosts , 如果需要進一步處理該數據，可以在模板文件中直接使用Python語法處理，這個在模板管理中再介紹。

之所以需要有變數管理，就是因為模板管理的存在，很多配置需要按照不同的環境生成，而這些環境就需要有變數管理這個功能來控制。

變數管理細分可以分為幾個維度：

全局變數
全局變數指的是那些在任何場景下都只有一個的變數，可能會改變，但全局只有這一個變數，它一變會影響到所有的使用它的模板。
n

組變數
組變數是指和分組管理結合後對某個分組設置的變數，組變數的使用場合比較多，而且不同的分組之間可能還有優先順序的問題，因此需要在分組的時候設置組的優先順序。
n
建議將組的優先順序分為如下幾類：
n
- 全局組（級別最低）
- IDC組（級別次之）
- Set組（級別次之）
- 自定義組（級別次之）

主機變數
主機變數是主機級別的動態變數，具有較高的優先順序，建議結合資源管理系統使用，可以給每一台物理主機（虛擬主機）都設置一組相應的動態變數，比如某個set的某些mongodb集群，需要區分主、從，設置的變數可以這個樣子：
n
172.27.117.252 id=0 priority=2 arbiterOnly=Falsen 172.27.117.248 id=1 priority=1 arbiterOnly=Falsen 172.27.117.247 id=2 priority=0 arbiterOnly=Truen
在服務部署的時候可以根據相應的優先順序決定生成的配置文件的不同，甚至執行腳本的不同。
任務變數
任務變數是具有最高優先順序的變數，這個變數只有任務執行的時候，通過輸入的參數來控制，該變數實際並不進行管理，使用用戶在使用的時候輸入而已，一次性的操作。

6) 模板管理

模板管理就是管理各種配置文件的管理系統。

配置文件之所以需要管理，是因為兩個原因：

在不同的環境中配置文件的內容可能是不同的
配置文件中的某些內容可能是會被修改的

我們以下面的配置文件為例，分別說說這兩種情況下使用模板管理的必要性：

[common]nregion = {{ region.id }}nset = 1ninstance = 1n.n.n.nn[network]nlisten-ip = {{ inventory_hostname }}nfile_ulimit = {{ global.file_ulimit }}n

上面配置文件中的 {{ region.id }}以及{{ inventory_hostname }}說的就是第一種情況，而{{ global.file_path }}就是第二種情況。

第一種情況中，在不同的region之間，文件的格式不變，但region.id的值是有變化的；inventory_hostname這裡表示的是某個伺服器的ip地址，這個在伺服器級別都是變化的。因此這類文件需要是需要進行模板管理的。

第二種情況中，所有的file_ulimit都是一樣的，那我們為什麼不寫死在文件里而把它變成變數呢？是因為這個配置，雖然現在沒有變化，但將來可能會發生變化，在變數管理中直接修改一下，那新的配置文件就都會按照這個生成了，比起去改一個文件內容還有可能產生格式錯誤的風險來說，這種方式是不是簡單多了。

至於模板文件如何編寫，這裡將會使用python的最通用的模板引擎jinja2引擎，所有的語法都必須遵循jinja2的引擎即可，變數使用變數管理中定義的變數，對於每一台主機都是在使用的時候動態生成最新的臨時文件，並通過文件分發的方式傳輸就可以了。

7) 軟體管理

所謂的軟體管理，也就是軟體包的管理，軟體包的管理有兩種：

rpm或yum，npm，pip等安裝的軟體包，具有明確的包管理工具。
壓縮包或目錄格式的代碼版本。

具有軟體包管理工具的代碼，比較容易進行管理，只要通過每台伺服器自動的Agent定期執行list操作將所需要跟蹤的軟體包的版本進行跟蹤，並彙報到中心管理資料庫即可。

而壓縮包或目錄格式的代碼版本則比較麻煩，需要對比MD5值，以及具有參照樣本才可以管理。

這些所有的軟體包都需要有一個最新可用的全局版本管理，用於進行版本對比操作，甚至可以直接點擊升級。

總之，最終的軟體管理的結果會呈現如下的形態，以某台伺服器為例：

伺服器ip: xxx.xxx.xxx.xxxn| 軟體包名稱| 版本號 | 是否是最新可用版本| 點擊升級n| :—-|:—-|n| nodejs| v0.1.1| 是|n| libvirt| x.x.x| 是|n| zookeeper| 3.3.5| 否| 升級n

當然有了軟體管理之後，當我們有某種類似如：將某些伺服器上面的某個軟體包升級！這樣的問題的時候，無論是獲取基準ip列表，還是後續的升級工作，都十分簡單了。

當然版本升級工作會和作業管理相結合，每個版本升級都會是一個單獨的作業，這樣版本升級的進度，結果也都一目了然，而且還可以做到灰度。

8）服務管理

服務管理有點類似監控工具，它所層顯的狀態和版本管理類似，實現的方式也類似，都是通過Agent定時上報的機制獲取最新的數據。

所謂的服務管理，就是講每一台伺服器上所運行這些進程進行管理，當然不是全部進程，而是我們所關注的服務進程，呈現的狀態如：

以伺服器：xxx.xx.xxx.xxx為例：n| 進程id| 進程名稱| 啟動時間| 檢查時間|運行時間 | 運行用戶| 運行狀態| 操作n|:—-:n| 1234| uhost-action| 2016-2-07 10:00:00| 2016-2-17 10:00:00 | 10day | root|運行中 | 重啟/停止n| 2345| uimage3-action| 2016-2-07 10:00:00 |2016-2-17 10:00:00| 8day | root|已停止 | 啟動n

上面是某台伺服器上的服務管理的實時情況，每一個任務都可以有詳細的跟蹤記錄，可以用於問題跟蹤，服務報警，dashborad展現等等。

另外服務管理可以和作業管理相結合，實現服務的重啟，停止，啟動等功能。

服務管理功能也是很有用的功能。

到此位置，整個配置管理工具的功能介紹也完成了，具體的實現方式可以有兩種實現方式：

基於過程的實現方式（主動）
基於過程的實現方式，就是所說的的配置變化，通過中心觸發的方式實現，伺服器上所有的配置變化都是主動的而不是被動的，可以通過SSH的方式，也可以通過Agent的方式來實現。可以使用Ansible、fabirc的API或者salt的daemon，也可以自研daemon的方式實現。
n

基於結果的實現方式（被動）
基於結果的實現方式是指整個操作並不關心過程，也不是主動觸發的，而是被動觸發的，這種方式是基於Agent的實現方式。運維人員對某台伺服器的某個配置設置一個最終的狀態，Agent獲取這個最終狀態後執行相應的操作，只要Agent滿足條件需求，那麼這台伺服器最終所呈現的結果就是我們配置的結果，Puppet就是這種理念設計的，當然也可以自研。
n

總結：

整個運維管控系統還是比較大的系統，每一個子系統的功能的很複雜，而且還需要結合使用，整體的架構是分散式的，多種開源軟體與自研系統結合的方式實現，大體功能和架構如上面所述，具體的實現上肯定會有很多細節需要攻克的。

PS: 這個功能和架構設計參考了騰訊的藍鯨系統，並結合了Ansible、saltstack和puppet的理念，綜合而成，而且其中的部分功能已經實現完成。

——————

徵稿範圍

題材不限，與「技術」及「雲」相關即可，但文章不得少於500字，圖文並茂為佳。可以是：

不同雲廠商產品使用體驗及數據評測；
項目部署到雲平台前後數據分析對比；
雲上遷移/部署過程遇到的問題及解決方案；
其他雲上部署經驗；

……

作品提交鏈接：http://cn.mikecrm.com/fj6KmCu

「UCloud機構號」將獨家分享雲計算領域的技術洞見、行業資訊以及一切你想知道的相關訊息。

歡迎提問&求關注 o(*////▽////*)q～

以上。