Co jest zalecane do udokumentowania stosu technologii IT, w tym ich relacji między sobą, w bazie danych grafów?

Pracując dla dużej firmy z ponad 500 pracownikami IT i ponad 1000 serwerów, z których każdy ma własne aplikacje biznesowe, mamy ogromne wyzwanie informacyjne i koordynacyjne, aby wiedzieć, z którym pracownikiem IT należy się skontaktować, dla którego serwera. Problem koordynacji jest złożony, ponieważ różni pracownicy IT są odpowiedzialni za różne warstwy stosu IT. Na przykład istnieją różne zespoły odpowiedzialne za sprzęt, wirtualizację, systemy operacyjne, serwery aplikacji i same aplikacje.

Biorąc pod uwagę to wyzwanie, w DevOps istnieje potrzeba zdefiniowania i udokumentowania wszystkich komponentów tworzących różne stosy technologiczne w środowisku IT. Tradycyjnie można to osiągnąć dzięki właściwemu rozwiązaniu CMDB.

W tym celu zbadałem typowe rozwiązania CMDB, takie jak BMC Atrium i inne, problem polega jednak na tym, że zatrzymują się one na poziomie dokumentowania samych zasobów IT, na wysokim poziomie, zgodnie z ramami ITIL, ale nie zajmują się dokumentacją stosu technologii informatycznych w szczegółach. Badałem również takie narzędzia, jak Puppet , Ansible i Salt , ale narzędzia te koncentrują się bardziej na wdrażaniu i konfiguracji oprogramowania, a nie na koordynacji ludzi wokół oprogramowania.

Na przykład wykonalnym rozwiązaniem byłoby zdefiniowanie różnych pojęć wraz z kluczowymi atrybutami ważnymi dla tych pojęć:

• Sprzęt komputerowy
• Wirtualizacja
• System operacyjny
• Serwery aplikacji
• Aplikacje

Te koncepcje byłyby następnie kojarzone ze sobą w zakresie ich relacji w celu stworzenia rozwiązań. Np. Aplikacja zależałaby od serwera aplikacji, który zależałby od systemu operacyjnego itp., Razem to rozwiązanie byłoby zdefiniowane w „Systemie finansów”. Po zdefiniowaniu systemu wszystkie metadane związane z tymi systemami zostaną przechwycone, aby ułatwić koordynację dla każdej warstwy na stosie. Tj. Koordynacja personelu wsparcia technicznego dla każdej warstwy.

Celem takiego rozwiązania byłoby wykonanie różnych zapytań przeciwko stosom technologii, takich jak:

• Aby ustalić, kto obsługuje które składniki
• Które składniki są nieaktualne
• Które elementy należy załatać

Mając to na uwadze, jakie narzędzia open source istnieją w celu zdefiniowania wszystkich składników stosu technologii IT, w tym ich relacji między sobą, w bazie danych grafów, takich jak Neo4J?

Biorąc pod uwagę twój pierwszy akapit, organizacja, którą opisujesz, jest silną organizacją, której właśnie organizacja DevOps zwykle unika.

Biorąc pod uwagę to wyzwanie, w DevOps istnieje potrzeba zdefiniowania i udokumentowania wszystkich komponentów tworzących różne stosy technologiczne w środowisku IT. Tradycyjnie można to osiągnąć dzięki właściwemu rozwiązaniu CMDB.

To, co tu opisujesz, może być ITIL, który jest systemem zarządzania wymagającym dokumentacji i łączysz go z faktem, że zespół DevOps zwykle definiuje podstawowe warstwy jako kod, ponieważ w ten sposób wraca do dowolnej dokumentacji programistycznej z zastrzeżeniami Code to Dokumentacja często spotykana w metodologii Scrum dla zwinnej metodologii rozwoju (szybkie i krótkie iteracje mające na celu minimalizację działającego rozwiązania na końcu iteracji)

Zastrzeżenie dotyczące pozostałej części tej odpowiedzi: znam więcej szefa kuchni i inspec i dlatego uważam je za przykład tutaj; ale nie są to jedyne narzędzia dostępne na rynku, nie otworzę debaty na ich temat, ponieważ lepsze jest to, z którym czujesz się lepiej.

W związku z tym reszta pytania jest nieco stronnicza, a ja osobiście nie spotkałem organizacji dokumentującej relacje warstw, które opisujesz bardziej niż infrastrukturę jako dokumentację kodu i kodu systemu zarządzania konfiguracją. (Znów, to nie znaczy, że nikt tego nie robi, po prostu nigdy o tym nie słyszałem).
Aby zilustrować moją firmę w środowisku szefa kuchni, książka kucharska aplikacji zadeklaruje swoje zależności (tomcat, jboss, nginx / php i od jakiego systemu operacyjnego potrzebowała punktów podłączenia dla niektórych współużytkowanych danych oraz nazwy schematu DB) i wystawi identyfikatory URI usług na zostać pochłoniętym przez szefa kuchni do konfiguracji innych aplikacji, to brzmi jak zdefiniowanie „systemu finansowego”, a dokumentacja na ten temat znajduje się w tej książce kucharskiej aplikacji README, z kilkoma innymi plikami, jeśli naprawdę są potrzebne.

Systemy zarządzania konfiguracją mają zwykle centralne miejsce raportowania, „serwer-szef kuchni” dla danych i „zarządzaj interfejsem użytkownika” do prezentacji w świecie szefów kuchni „ansible tower” dla ansible world, aby wymienić dwa z nich, ale zazwyczaj mają na celu nadzór nad ogólny system zarządzany niż wykres zależności.

To powiedziawszy, dla szefa kuchni serwer-serwer działa również jako CMDB, do którego można wysyłać zapytania za pomocą różnych narzędzi (zwraca dane JSON z żądań HTTP), zależności między aplikacjami można wyrażać na różne sposoby i nie ma „od razu po wyjęciu z pudełka” Metoda: każda firma będzie miała swój własny sposób na zadeklarowanie ich w systemie do celów konfiguracyjnych i jako taka możesz wykorzystać to do zbudowania wykresu, ale to po twojej stronie.

W infrastrukturze jako punkcie kodowym potrzeby infrastruktury byłyby utrzymywane wraz z aplikacją, to nadal aplikacja wie, czego potrzebuje jako oprogramowanie pośrednie, jaki system operacyjny, z jakim ustawieniem regionalnym, jakie są inne zależności usług i jakie usługi ta oferta aplikacji).

Ostatnią rzeczą, o której mogę pomyśleć, jeśli chcesz zarządzać tymi zależnościami tylko w dokumentacji, są narzędzia takie jak glpi, które są głównie CMDB i systemem biletowym, wykorzystuje dokumentację zasobów i ich relację, aby móc stwierdzić, na co wpłynie to po otwarciu bilet z informacją, że aplikacja nie działa. w połączeniu z inwentaryzacją ng umożliwia sprawdzanie stanów systemu i jako takie może spełnić twoje zapytanie o potrzeby łatek, ale moim zdaniem jest to zadanie systemu audytu, podobnie jak inspekcja zintegrowana z szefem kuchni dla przykładu, tak jak w następnej fazie naprawić nieaktualne systemy poprzez ich aktualizację / łatanie.