一千萬個為什麽

搜索

建議在圖形數據庫中記錄IT技術堆棧,包括它們彼此之間的關系?



我們為一家擁有500多名IT員工和超過1,000臺服務器的大型公司工作,每臺服務器都運行自己的業務應用程序,因此我們在了解哪位IT員工聯系哪臺服務器時遇到了巨大的信息和協調挑戰。協調問題與IT人員負責IT堆棧的不同層次的不同IT人員相結合。例如,有不同的團隊負責硬件,虛擬化,操作系統,應用程序服務器和應用程序本身。

考慮到這一挑戰,在DevOps中,需要定義和記錄IT環境中構成各種技術堆棧的所有組件。傳統上,這可能是通過合適的CMDB解決方案完成的。

我已經研究了典型的CMDB解決方案,例如 BMC Atrium 和其他為此,問題在於它們停留在IT資產本身的記錄級別,按照ITIL框架在高層次進行記錄,但不要詳細說明IT技術棧的文檔。我還調查了諸如 PuppetAnsibleSalt ,但這些工具更註重軟件部署和配置,而不是關於軟件周圍人的配合。

例如,一個可行的解決方案將定義各種概念,以及對這些概念重要的關鍵屬性:

  • 硬件
  • 虛擬化
  • 操作系統
  • 應用程序服務器
  • 應用

然後,這些概念將根據它們之間的關系相互關聯以形成解決方案。例如,應用程序將取決於應用程序服務器,這取決於操作系統等。此解決方案一起將在“財務系統”中定義。定義了一個系統後,與這些系統相關的所有元數據將被捕獲,以便協調堆棧中的每一層。即每層技術支持人員的協調。

這種解決方案的目的是對技術堆棧進行各種查詢,例如:

  • 確定誰支持哪些組件
  • 哪些組件過期
  • 需要修補哪些組件

有鑒於此,有哪些開源工具可以用來定義IT技術堆棧的所有組件,包括它們之間的關系?在Neo4J等圖形數據庫中?

轉載註明原文: 建議在圖形數據庫中記錄IT技術堆棧,包括它們彼此之間的關系?

一共有 1 個回答:

考慮到你的第一段,你所描述的組織是一個高度孤立的組織,這正是DevOps組織傾向避免的。

考慮到這個挑戰,在DevOps中有一個要求   定義並記錄構成各種組件的所有組件   IT環境中的技術堆棧。傳統上這可能   已經通過一個合適的CMDB解決方案來完成。

你在這裏描述的可能是ITIL,這是一個需要文檔的管理系統,你可以將它與DevOps團隊通常將底層定義為代碼的事實混合起來,因此它可以返回到任何開發文檔,其註意事項是<�經常在Scrum方法中看到的代碼就是文檔對於敏捷的開發方法(叠代結束時針對最小工作解決方案的快速和短期叠代)

對此答案的其余部分不承擔責任:我更了解廚師和inspec,這就是為什麽我把它們作為例子的原因。但它們並不是市場上現有的唯一工具,我不會就這些問題開展辯論,因為更好的是你更喜歡的工具。

因此,這個問題的其余部分有點偏頗,我本人並沒有遇到過一個組織,它將你描述的層次關系記錄為代碼和配置管理系統代碼文檔的基礎設施。 (同樣,這並不意味著沒有人會這樣做,我從來沒有聽說過) 為了說明我的公司在廚師環境中的應用,Cookbook會聲明它的依賴關系(tomcat,jboss,nginx/php,以及在哪些操作系統上,主要需要某些共享數據的安裝點及其數據庫模式名稱),並將其服務URI被其他應用程序配置的廚師使用,這聽起來像定義你的'財務系統',並且它的文檔在這個應用程序食譜自述文件中,如果確實需要,還有一些更多的文件。

配置管理系統通常有一個中央報告位置,數據的“廚師 - 服務器”是一個“管理用戶界面”,用於在廚師世界“可靠的塔”中呈現給負責任的世界並命名其中兩個,但他們通常更傾向於監督整體管理系統比繪制依賴關系。

這就是說,對於廚師來說,廚師服務器也可以作為一個CMDB,您可以使用各種工具(它從HTTP請求返回JSON數據)查詢CMDB,可以用各種方式表達內部應用程序的依賴關系,並且沒有“開箱即用”方法,每個公司都有自己的方式來在系統中聲明它們以便進行配置,因此您可以利用它來構建您的圖形,但這是支持您的。

在基礎設施中,作為代碼的角度來看,基礎設施需求將與應用程序保持一致,它仍然是應用程序,它知道它作為中間件需要什麽,哪個操作系統與哪些語言環境,哪些是其他服務依賴關系以及哪些服務這個應用程序提供)。

如果你想管理文檔的這些依賴關系,我可以想到的最後一件事就是 glpi 這樣的工具,它主要是CMDB和票務系統,它可以利用記錄資產及其關系,以便能夠告訴你什麽是當你打開一張票申說已停止時受到影響。再加上ng-inventory,它允許查詢系統狀態,因此可以滿足您對補丁需求的查詢,但在我看來,這是一個審計系統任務,就像可以檢查集成在廚師運行的例子一樣,因為下一個階段會通過更新/修補它們來修復過時的系統。