Was wird empfohlen, um einen IT-Technologie-Stack einschließlich seiner Beziehung zueinander in einer Diagrammdatenbank zu dokumentieren?

Da wir für ein großes Unternehmen mit über 500 IT-Mitarbeitern und über 1.000 Servern arbeiten und jeder Server seine eigenen Geschäftsanwendungen ausführt, haben wir eine enorme Informations- und Koordinationsherausforderung, wenn wir wissen, welcher IT-Mitarbeiter für welchen Server erreichbar ist. Das Problem der Koordination verschärft sich, wenn verschiedene IT-Mitarbeiter für verschiedene Ebenen des IT-Stacks verantwortlich sind. Beispielsweise gibt es verschiedene Teams, die für Hardware, Virtualisierung, Betriebssysteme, Anwendungsserver und die Anwendungen selbst verantwortlich sind.

Angesichts dieser Herausforderung besteht in DevOps die Anforderung, alle Komponenten zu definieren und zu dokumentieren, die die verschiedenen Technologiepakete in einer IT-Umgebung ausmachen. Traditionell könnte dies mit einer ordnungsgemäßen CMDB-Lösung erreicht worden sein.

Ich habe typische CMDB-Lösungen wie BMC Atrium und andere für diesen Zweck untersucht. Das Problem ist jedoch, dass sie nicht mehr auf der Ebene der Dokumentation von IT-Ressourcen selbst auf hoher Ebene gemäß dem ITIL-Framework stattfinden, sondern nicht auf die Dokumentation eingehen des IT-Technologie-Stacks im Detail. Ich habe auch Tools wie Puppet , Ansible und Salt untersucht , aber diese Tools konzentrieren sich mehr auf die Softwarebereitstellung und -konfiguration und nicht auf die Personalkoordination in Bezug auf Software.

Eine praktikable Lösung würde zum Beispiel die verschiedenen Konzepte zusammen mit den Schlüsselattributen definieren, die für diese Konzepte wichtig sind:

• Hardware
• Virtualisierung
• Betriebssysteme
• Anwendungsserver
• Anwendungen

Diese Konzepte würden dann in ihren Beziehungen miteinander verknüpft, um Lösungen zu finden. ZB würde eine Anwendung von einem Anwendungsserver abhängen, der von einem Betriebssystem usw. abhängen würde. Zusammen würde diese Lösung im "Finanzsystem" definiert werden. Nachdem ein System definiert wurde, werden alle mit diesen Systemen verbundenen Metadaten erfasst, um die Koordination für jede Schicht im Stapel zu erleichtern. Dh die Koordination des technischen Supports für jede Schicht.

Der Zweck einer solchen Lösung besteht darin, verschiedene Abfragen für Technologiestacks durchzuführen, z.

• Um festzustellen, wer welche Komponenten unterstützt
• Welche Komponenten sind veraltet?
• Welche Komponenten müssen gepatcht werden?

Welche Open-Source-Tools gibt es vor diesem Hintergrund, um alle Komponenten eines IT-Technologie-Stacks einschließlich ihrer Beziehung zueinander in einer Grafikdatenbank wie Neo4J zu definieren?

In Anbetracht Ihres ersten Absatzes handelt es sich bei der Organisation, die Sie beschreiben, um eine hochgradig isolierte Organisation, die genau das ist, was eine DevOps-Organisation tendenziell vermeidet.

Angesichts dieser Herausforderung besteht in DevOps die Anforderung, alle Komponenten zu definieren und zu dokumentieren, die die verschiedenen Technologiepakete in einer IT-Umgebung ausmachen. Traditionell könnte dies mit einer ordnungsgemäßen CMDB-Lösung erreicht worden sein.

Was Sie hier beschreiben, könnte ITIL sein, ein dokumentationspflichtiges Managementsystem, das Sie mit der Tatsache mischen, dass ein DevOps-Team normalerweise die zugrunde liegenden Ebenen als Code definiert, sodass es mit den Vorbehalten des Codes auf jede Entwicklungsdokumentation zurückgreift Diese Dokumentation wird häufig in der Scrum-Methodik für eine agile Entwicklungsmethodik verwendet (schnelle und kurze Iterationen mit dem Ziel einer minimalen Arbeitslösung am Ende der Iteration).

Haftungsausschluss für den Rest dieser Antwort: Ich kenne mich mit Chefkoch und Inspektion besser aus und nehme sie deshalb hier als Beispiel. Aber sie sind nicht die einzigen Werkzeuge, die es auf dem Markt gibt. Ich werde keine Debatte darüber eröffnen, da das bessere das ist, mit dem Sie sich wohler fühlen.

Aus diesem Grund ist der Rest der Frage ein wenig voreingenommen, und ich persönlich bin nicht auf eine Organisation gestoßen, die die Ebenenbeziehung dokumentiert, die Sie mehr als die Infrastruktur als Code- und Konfigurationsmanagementsystem-Codedokumentation beschreiben. (Auch dies bedeutet nicht, dass es niemand tut, ich habe nur noch nie davon gehört).
Um aus meiner Firma in einer Chefumgebung zu veranschaulichen, deklariert ein Anwendungskochbuch seine Abhängigkeiten (tomcat, jboss, nginx / php und auf welchem ​​Betriebssystem, benötigte Mount-Punkte für einige gemeinsam genutzte Daten und meistens seinen DB-Schemanamen) und macht seine Dienst-URIs verfügbar Für andere Anwendungskonfigurationen sollte der Chefkoch das "Finanzsystem" definieren. Die dazugehörige Dokumentation befindet sich in der README-Datei des Anwendungskochbuchs und enthält bei Bedarf weitere Dateien.

Konfigurationsmanagementsysteme haben normalerweise eine zentrale Berichtsstelle, "Chef-Server" für Daten und "Verwaltungs-UI" für Präsentationen in der Chef-Welt "Ansible Tower" für Ansible World, um nur zwei davon zu nennen das gesamte verwaltete System, als die Abhängigkeiten grafisch darzustellen.

Der Chef-Server fungiert jedoch auch als CMDB, die Sie mit verschiedenen Tools abfragen können (er gibt JSON-Daten aus HTTP-Anfragen zurück). Die Abhängigkeiten zwischen Anwendungen können auf verschiedene Weise ausgedrückt werden, und es gibt kein "out of the box". Nach dieser Methode deklariert jede Firma sie für Konfigurationszwecke auf ihre eigene Weise im System. Als solche können Sie dies nutzen, um Ihr Diagramm zu erstellen, aber das ist Ihre Seite.

In einer Infrastruktur als Code-Sicht würde der Infrastrukturbedarf bei der Anwendung bleiben, es ist immer noch die Anwendung, die weiß, was sie als Middleware benötigt, welches Betriebssystem, mit welchem ​​Gebietsschema, welche anderen Dienstabhängigkeiten und welche Dienste dieses Anwendungsangebot).

Das letzte, was ich mir vorstellen kann, wenn Sie diese Abhängigkeiten nur für die Dokumentation verwalten möchten, sind Tools wie glpi, die hauptsächlich eine CMDB und ein Ticketing-System sind. Es nutzt die Dokumentierung von Assets und deren Beziehung, um zu erkennen, was beim Öffnen betroffen ist Ein Ticket mit der Meldung, dass eine Anwendung nicht verfügbar ist. In Verbindung mit ng-inventory können Systemzustände abgefragt und somit die Abfrage nach Patch-Anforderungen ausgeführt werden. Meiner Meinung nach ist dies jedoch eine Aufgabe des Prüfsystems, wie sie beispielsweise in der nächsten Phase in einen Kochlauf integriert werden kann die veralteten Systeme zu reparieren, indem sie aktualisiert / gepatcht werden.