最近小嘉在逛知乎時看到一位知友提出了這樣的一個問題，這與之前溝通的一位客戶疑惑一致，為他解答的過程自己也整理除了一些思考，故和大家一起聊聊。

01. 開源工具為何會不符合公司要求？基于開源組件定制開發(fā)是否是好的方式？

開源工具早期包括現(xiàn)在一直都是國內國外企業(yè)在做運維時首選的工具體系，并且其中不乏很多工具入門簡單，上手極快，功能強大，安裝部署容易，并且還有開源免費的優(yōu)勢，滿足了企業(yè)組織對維護數(shù)據(jù)中心穩(wěn)定運行保障的要求。這里的開源軟件包括監(jiān)控、日志、自動化等常見的運維場景。

1）單個開源工具無法滿足所有運維需求

單看其中一個開源工具，除了有上述提到的優(yōu)勢之外，其實也必然存在他的技術短板。就拿監(jiān)控舉例，Zabbix監(jiān)控發(fā)現(xiàn)功能非常好用，并且插件擴展的方式幾乎可以豐富任何場景。但zabbix仍有它的短板。對于當前比較火的容器部署架構，Zabbix的IaaS層監(jiān)控的優(yōu)勢無法發(fā)揮出來，并且Zabbix 由于使用了關系型數(shù)據(jù)存儲時序數(shù)據(jù)，在監(jiān)控大規(guī)模集群時存儲會遇到瓶頸。所以在容器、k8s架構下，Prometheus成為了更有優(yōu)勢的工具。所以，為了滿足我們的運維需求，需要上很多運維工具。

2）運維核心轉向為整個應用與架構的健康性

我們在使用開源工具時，也會面臨很多場景問題無法滿足，現(xiàn)在的運維團隊不再是看單點的運行狀態(tài)，而是更多以業(yè)務視角看整個應用和架構的健康性，這時zabbix的告警無法根據(jù)業(yè)務拓撲進行收斂就會成為很大的問題，瘋狂的告警郵件甚至給運維增加了很多工作量。并且，zabbix根據(jù)不同場景的深度使用，都需要通過定制開發(fā)實現(xiàn)。除此之外，不同行業(yè)的運維體系都有報表和監(jiān)控大屏的需要，這些也都需要基于業(yè)務特點，公司要求進行定開。而每種開源工具的代碼邏輯都不同，如果我們對所有使用到的工具都進行定制開發(fā)，耗費的人力物力可想而知。

3）開源工具聯(lián)動&集成難

開源工具搭建運維體系就會存在另外一個問題，這些工具之間的聯(lián)動，也需要通過點對點的對接的方式建設。那么新上一個開源工具，就需要跟前面的n個開源工具做集成，這種集成所需的交付周期也會比較長，而且聯(lián)動效果對接口強依賴，開的接口數(shù)量也不小。

從上面的分析就可以回答這三個問題：

• 單一的一種工具是無法覆蓋所有的技術棧的，必然需要用多種工具配合使用，來完成一套完整的運維體系；對于個性化的場景，需要大量的定制開發(fā)，以及開源工具間點對點的對接方式需要時間，項目周期長，幾乎跟不上業(yè)務系統(tǒng)敏捷迭代的速度；所以才會有許多公司考慮開發(fā)自己的運維平臺。
• 深度定制開發(fā)，開源工具聯(lián)動集成，這些工作量必然耗費人力物力，這就導致開源工具開發(fā)過程中的成本投入也不見得比研發(fā)運維平臺來得少。
• 如果參與到開源社區(qū)維護開源工具，不同開源工具的代碼邏輯、代碼語言都不相同，學習成本很高。而做自己的運維平臺卻是“一勞永逸”的事情，既規(guī)避了開源工具未來可能閉源的風險，又能夠最符合我們自身的業(yè)務特點，代碼邏輯也能夠保持規(guī)范且一致。

02. 我們需要的運維平臺是什么樣的？如何建設呢？

換而言之，當遇到以上運維場景問題時，我們需要搭建一套自己的運維平臺。那么我們的運維平臺又要怎么建設呢？怎么才能把開源工具不滿足的短板補齊，滿足公司管理要求、又能滿足公司業(yè)務特點？

整個平臺如何搭建，可以參考OASR模型，結合運維流程，將IT運維對象 (Object)、運維活動(Activity)、運維場景(Scene)、運維角色(Role)進行分層剖析。

通過模型梳理清楚我們不同運維角色在運維場景中的需求，拆解每個運維場景涉及的運維活動和對應的執(zhí)行對象，底層的不同技術棧對象如何納管，運維活動如何在一個平臺上實現(xiàn)，以及這種平臺建設后萬一有新的技術棧，會不會也遇到開源工具遇到的問題？這些都要考慮。

在業(yè)內，就有實現(xiàn)運維平臺建設的案例，騰訊內部根據(jù)這種運維場景和運維活動的梳理，內部搭建了一套藍鯨運維平臺。目前，藍鯨運維平臺已經(jīng)在金融、證券、航司、交通、政務等行業(yè)落地，在自動化、部署、監(jiān)控、權限管理、日志等等各個方面有一套完整的解決方案。而為了避免開源工具使用中的問題，我們是這樣做的：

第一點，這個運維平臺為了能夠覆蓋多種技術棧，在平臺層通過一個Agent納管底層所有的運維對象節(jié)點，以及無法下發(fā)Agent的網(wǎng)絡設備等，可以通過協(xié)議管理的方式實現(xiàn)，首先做到了平臺對底層資源的管控一體。

第二點，區(qū)分運維活動和運維場景，運維平臺的能力層（PaaS）能夠滿足所有拆解后的運維單一動作，比如配置平臺管理、腳本作業(yè)、容器管理等。而上層運維場景已經(jīng)沉淀了常用的場景，也可以基于底層能力的調用根據(jù)平臺的前后端開發(fā)框架，工具流水線、運行環(huán)境托管持續(xù)構建，能夠完全滿足不同運維角色的運維場景需求。這種底層的PaaS能力做到了平臺一體。

第三點，針對開源工具和商用工具無法天然聯(lián)動的問題，在平臺之上常用的應用配置門戶、監(jiān)控告警、IT運維服務管理、應用發(fā)布自動化、災備切換自動化等工具已經(jīng)實現(xiàn)了天然的聯(lián)動交互。并且外圍工具也可以基于藍鯨平臺提供的標準接口做集成對接，快速實現(xiàn)外圍工具與運維平臺的聯(lián)動一體。

目前，藍鯨平臺社區(qū)體驗版本，歡迎各位喜歡做運維開發(fā)技術研究的業(yè)內大佬體驗環(huán)境和做更多的技術交流。

碼字不易，若覺得有用，可點贊關注我們，會持續(xù)提供研發(fā)&運維相關的干貨內容。

若想深入了解咱們的運維平臺，歡迎去官網(wǎng)聯(lián)系嘉為藍鯨，我們將為您提供最新的產(chǎn)品材料與產(chǎn)品試用