最近小嘉在逛知乎時看到一位知友提出了這樣的一個問題,這與之前溝通的一位客戶疑惑一致,為他解答的過程自己也整理除了一些思考,故和大家一起聊聊。
01. 開源工具為何會不符合公司要求?基于開源組件定制開發(fā)是否是好的方式?
開源工具早期包括現(xiàn)在一直都是國內(nèi)國外企業(yè)在做運維時首選的工具體系,并且其中不乏很多工具入門簡單,上手極快,功能強大,安裝部署容易,并且還有開源免費的優(yōu)勢,滿足了企業(yè)組織對維護數(shù)據(jù)中心穩(wěn)定運行保障的要求。這里的開源軟件包括監(jiān)控、日志、自動化等常見的運維場景。
1)單個開源工具無法滿足所有運維需求
單看其中一個開源工具,除了有上述提到的優(yōu)勢之外,其實也必然存在他的技術(shù)短板。就拿監(jiān)控舉例,Zabbix監(jiān)控發(fā)現(xiàn)功能非常好用,并且插件擴展的方式幾乎可以豐富任何場景。但zabbix仍有它的短板。對于當(dāng)前比較火的容器部署架構(gòu),Zabbix的IaaS層監(jiān)控的優(yōu)勢無法發(fā)揮出來,并且Zabbix 由于使用了關(guān)系型數(shù)據(jù)存儲時序數(shù)據(jù),在監(jiān)控大規(guī)模集群時存儲會遇到瓶頸。所以在容器、k8s架構(gòu)下,Prometheus成為了更有優(yōu)勢的工具。所以,為了滿足我們的運維需求,需要上很多運維工具。
2)運維核心轉(zhuǎn)向為整個應(yīng)用與架構(gòu)的健康性
我們在使用開源工具時,也會面臨很多場景問題無法滿足,現(xiàn)在的運維團隊不再是看單點的運行狀態(tài),而是更多以業(yè)務(wù)視角看整個應(yīng)用和架構(gòu)的健康性,這時zabbix的告警無法根據(jù)業(yè)務(wù)拓撲進行收斂就會成為很大的問題,瘋狂的告警郵件甚至給運維增加了很多工作量。并且,zabbix根據(jù)不同場景的深度使用,都需要通過定制開發(fā)實現(xiàn)。除此之外,不同行業(yè)的運維體系都有報表和監(jiān)控大屏的需要,這些也都需要基于業(yè)務(wù)特點,公司要求進行定開。而每種開源工具的代碼邏輯都不同,如果我們對所有使用到的工具都進行定制開發(fā),耗費的人力物力可想而知。
3)開源工具聯(lián)動&集成難
開源工具搭建運維體系就會存在另外一個問題,這些工具之間的聯(lián)動,也需要通過點對點的對接的方式建設(shè)。那么新上一個開源工具,就需要跟前面的n個開源工具做集成,這種集成所需的交付周期也會比較長,而且聯(lián)動效果對接口強依賴,開的接口數(shù)量也不小。
從上面的分析就可以回答這三個問題:
02. 我們需要的運維平臺是什么樣的?如何建設(shè)呢?
換而言之,當(dāng)遇到以上運維場景問題時,我們需要搭建一套自己的運維平臺。那么我們的運維平臺又要怎么建設(shè)呢?怎么才能把開源工具不滿足的短板補齊,滿足公司管理要求、又能滿足公司業(yè)務(wù)特點?
整個平臺如何搭建,可以參考OASR模型,結(jié)合運維流程,將IT運維對象 (Object)、運維活動(Activity)、運維場景(Scene)、運維角色(Role)進行分層剖析。
通過模型梳理清楚我們不同運維角色在運維場景中的需求,拆解每個運維場景涉及的運維活動和對應(yīng)的執(zhí)行對象,底層的不同技術(shù)棧對象如何納管,運維活動如何在一個平臺上實現(xiàn),以及這種平臺建設(shè)后萬一有新的技術(shù)棧,會不會也遇到開源工具遇到的問題?這些都要考慮。
在業(yè)內(nèi),就有實現(xiàn)運維平臺建設(shè)的案例,騰訊內(nèi)部根據(jù)這種運維場景和運維活動的梳理,內(nèi)部搭建了一套藍鯨運維平臺。目前,藍鯨運維平臺已經(jīng)在金融、證券、航司、交通、政務(wù)等行業(yè)落地,在自動化、部署、監(jiān)控、權(quán)限管理、日志等等各個方面有一套完整的解決方案。而為了避免開源工具使用中的問題,我們是這樣做的:
第一點,這個運維平臺為了能夠覆蓋多種技術(shù)棧,在平臺層通過一個Agent納管底層所有的運維對象節(jié)點,以及無法下發(fā)Agent的網(wǎng)絡(luò)設(shè)備等,可以通過協(xié)議管理的方式實現(xiàn),首先做到了平臺對底層資源的管控一體。
第二點,區(qū)分運維活動和運維場景,運維平臺的能力層(PaaS)能夠滿足所有拆解后的運維單一動作,比如配置平臺管理、腳本作業(yè)、容器管理等。而上層運維場景已經(jīng)沉淀了常用的場景,也可以基于底層能力的調(diào)用根據(jù)平臺的前后端開發(fā)框架,工具流水線、運行環(huán)境托管持續(xù)構(gòu)建,能夠完全滿足不同運維角色的運維場景需求。這種底層的PaaS能力做到了平臺一體。
第三點,針對開源工具和商用工具無法天然聯(lián)動的問題,在平臺之上常用的應(yīng)用配置門戶、監(jiān)控告警、IT運維服務(wù)管理、應(yīng)用發(fā)布自動化、災(zāi)備切換自動化等工具已經(jīng)實現(xiàn)了天然的聯(lián)動交互。并且外圍工具也可以基于藍鯨平臺提供的標(biāo)準(zhǔn)接口做集成對接,快速實現(xiàn)外圍工具與運維平臺的聯(lián)動一體。
目前,藍鯨平臺社區(qū)體驗版本,歡迎各位喜歡做運維開發(fā)技術(shù)研究的業(yè)內(nèi)大佬體驗環(huán)境和做更多的技術(shù)交流。
碼字不易,若覺得有用,可點贊關(guān)注我們,會持續(xù)提供研發(fā)&運維相關(guān)的干貨內(nèi)容。
若想深入了解咱們的運維平臺,歡迎去官網(wǎng)聯(lián)系嘉為藍鯨,我們將為您提供最新的產(chǎn)品材料與產(chǎn)品試用
CMDB治理:CMDB消費場景規(guī)劃指南
查看詳細
CTest測試管理平臺:上新用例結(jié)構(gòu)化設(shè)計
查看詳細
CCode代碼管理平臺:代碼合并前CI任務(wù)狀態(tài)校驗
查看詳細
嘉為藍鯨WeOps:高效監(jiān)控Kubernetes集群的三大關(guān)鍵點
查看詳細
CFlow價值流管理平臺:從流程線上化到價值可視化,研運黑盒破解之道
查看詳細
CPack制品庫:制品黑白名單,為軟件供應(yīng)鏈安全護航
查看詳細
申請演示