海量運(yùn)維常用技術(shù)之---自動化運(yùn)維工具選型及應(yīng)用場景（獲獎名單已公布-10-24）

igkimm

PRTG。PRTG。

phpcool

    puppet沒有在生產(chǎn)環(huán)境使用過，不做評論。
    func在上一家公司作為基礎(chǔ)服務(wù)部署，有500臺左右的數(shù)量，總體而言還是比較穩(wěn)定，只負(fù)責(zé)遠(yuǎn)程操作的功能，同時結(jié)合資產(chǎn)庫再做一層UI封裝，一個自動化的運(yùn)維平臺原型已經(jīng)浮現(xiàn)，可滿足日常60%的運(yùn)維操作，那40%為啥沒覆蓋到？是的，func沒有統(tǒng)一配置管理，程序、系統(tǒng)態(tài)的支持。
    現(xiàn)引出saltstack吧，saltstack是今年7月份才接觸，個人針對不同業(yè)務(wù)場景不同功能點進(jìn)行了測試，結(jié)果符合預(yù)期。saltsatck非常強(qiáng)大、靈活，很多功能都沒有做太死板的封裝，都可以通過python api進(jìn)行擴(kuò)展。遠(yuǎn)程操作功能覆蓋了func，還加入了更多的模塊支持，更多見官網(wǎng)模塊簡介http://docs.saltstack.com/ref/modules/all/index.html#all-salt-modules，在程序配置方面，引入了公共與私有數(shù)據(jù)的不同角色，利用好可以動態(tài)配置靈活的程序配置規(guī)則，例子：基于saltstack實現(xiàn)的配置集中化管理，同時saltstack也支持系統(tǒng)程序包、系統(tǒng)態(tài)管理，良好執(zhí)行返回接口、代理支持（master的容量擴(kuò)展）、文件同步等等，更多特性大家有興趣可以去挖掘http://docs.saltstack.com/(官網(wǎng)doc)、http://wiki.saltstack.cn/FrontPage（中文wiki），目前社區(qū)活躍度很高，在github提交的bug，1天內(nèi)就有人跟進(jìn)并給予回復(fù)。從長遠(yuǎn)來看，saltstack蘊(yùn)藏著巨大的潛力，建議運(yùn)維人員都可以關(guān)注下。之前在使用的0.16.0版本還存在bug或文檔與程序描述不一致的地方，但升級到最新的0.16.4后功能上基本上都已經(jīng)解決，官網(wǎng)文檔也會第一時間完善，贊一個。

kongjx_cu

cfengine 為什么沒有提起？

kongjx_cu

cfengine 以前用的，過5k以上服務(wù)器，包括教育網(wǎng)，聯(lián)通和電信，做帳號同步使用，非常方便，不過是多臺做集群架構(gòu)，有總控服務(wù)器，在多線上放節(jié)點服務(wù)器，達(dá)到帳號同步目的。

GB_juno

之前有搞過chef+openstack，也考慮過puppet，運(yùn)維自動化就那么點工具，把一樣弄通就可以了。

Purple_Grape

偶用puppet管了幾十臺windows機(jī)器，總體效果還不錯。

puppet 性能問題還是有點小頭疼，客戶端經(jīng)常超時。

準(zhǔn)備將puppet放本地跑，定期通過版本控制或者h(yuǎn)ttp/ftp等文件傳輸協(xié)議下載規(guī)則文件到本地執(zhí)行，這樣服務(wù)端就成了純靜態(tài)文件下載了，

對比C/S結(jié)構(gòu)，功能雖然弱了，但自動化能力并沒有減弱，僅僅是設(shè)想，還沒實施。

saltstack 目前有點嫩，算是puppet的fork，雖然puppetlabs 被 vmware 通過投資控制了很大的話語權(quán)，但vmware不像oracle，沒有作惡前科，屬于開源友好型 。

chszs

用過puppet，感覺簡單易用。

zhaopingzi

這些東西沒使用過啊，不好意思