Що рекомендується для документування стеку ІТ-технологій, включаючи їх відношення один до одного, у графічній базі даних?

Працюючи у великій компанії з понад 500 ІТ-персоналом та понад 1000 серверів, кожен сервер працює за власними бізнес-додатками, ми маємо величезну проблему з інформацією та координацією, коли дізнаємось, до якого персоналу ІТ-персоналу звертатися, до якого сервера. Проблема координації полягає в тому, що різні ІТ-співробітники відповідають за різні рівні ІТ-стеку. Наприклад, існують різні команди, які відповідають за апаратне забезпечення, віртуалізацію, операційні системи, сервери додатків та самі програми.

Враховуючи цей виклик, всередині DevOps існує вимога визначити та документувати всі компоненти, що складають різні набори технологій в ІТ-середовищі. Традиційно це могло бути досягнуто за допомогою рішення CMDB про власність.

Я досліджував для цієї мети типові рішення CMDB, такі як BMC Atrium та інші. Однак проблема полягає в тому, що вони зупиняються на рівні документування ІТ-активів на високому рівні, відповідно до рамки ITIL, але не стосуються документації детально стеку ІТ-технологій. Я також досліджував такі інструменти, як Puppet , Ansible і Salt , але ці інструменти зосереджені більше на розгортанні та конфігурації програмного забезпечення, а не на координації людей навколо програмного забезпечення.

Наприклад, дієве рішення визначало б різні поняття, а також ключові атрибути, важливі для цих концепцій:

• Обладнання
• Віртуалізація
• Операційні системи
• Сервери прикладних програм
• Програми

Ці поняття потім будуть пов'язані між собою з точки зору їх взаємозв'язків, щоб сформувати рішення. Наприклад, додаток залежатиме від сервера додатків, який залежатиме від операційної системи тощо. Разом це рішення буде визначене у "Фінансовій системі". Визначивши систему, всі метадані, пов'язані з цими системами, будуть захоплені, щоб полегшити координацію для кожного шару в стеку. Тобто координація персоналу технічної підтримки для кожного рівня.

Метою такого рішення є виконання різних запитів щодо стеків технологій, таких як:

• Визначити, хто підтримує, які компоненти
• Які компоненти застаріли
• Які компоненти потрібно наклеїти

Зважаючи на це, які інструменти з відкритим кодом існують для визначення всіх компонентів стеку ІТ-технологій, включаючи їх відношення один до одного, в базі даних графіків, таких як Neo4J?

Враховуючи ваш перший абзац, організація, яку ви описуєте, є високооднорідним органом, саме цього DevOps організація прагне уникати.

Враховуючи цей виклик, всередині DevOps існує вимога визначити та документувати всі компоненти, що складають різні набори технологій в ІТ-середовищі. Традиційно це могло бути досягнуто за допомогою рішення CMDB про власність.

Те, що ви тут описуєте, може бути ITIL, це система управління, яка вимагає документації, і ви змішуєте її з тим, що команда DevOps зазвичай визначає базові шари як код, як такий він повертається до будь-якої документації про розробку із застереженнями Code - Документація часто бачиться в методології Scrum для гнучкої методології розвитку (швидкі та короткі ітерації, спрямовані на мінімальне робоче рішення в кінці ітерації)

Відмова від решти цієї відповіді: я знаю більше шеф-кухаря та інспектора, і тому я сприймаю їх як приклад; але вони не є єдиними інструментами, які існують на ринку, я не відкриватиму дискусію щодо них, оскільки кращим є той, з яким вам зручніше.

Як такий, решта питання трохи упереджена, і я особисто не зіткнувся з організацією, яка документує відношення шару, яке ви описуєте більше, ніж інфраструктура як код та документація системи управління конфігурацією. (Знову ж таки, це не означає, що ніхто цього не робить, я просто ніколи про це не чув).
Щоб проілюструвати мою компанію в шеф-кухарському середовищі, кулінарна книга додатків оголосить про її залежності (tomcat, jboss, nginx / php і для якої ОС потрібні точки монтажу для деяких спільних даних та найменування схеми БД в основному) та викриє свої URI-адреси служб повинен споживати шеф-кухарем для конфігурації інших програм. Це звучить як визначення вашої "Фінансової системи" та документації до неї в цій кулінарній книзі README з додатковими файлами, якщо це дійсно потрібно.

Системи управління конфігурацією зазвичай мають центральне місце звітності, "шеф-кухар-сервер" для даних, "керуючий інтерфейс користувача" для представлення у світі шеф-кухарів, "ансибіл башта", щоб ансиблевий світ назвав два з них, але вони, як правило, більше спрямовані на надання контролю над загальна керована система, ніж графік залежностей.

Однак, для шеф-кухаря шеф-кухар-сервер також виступає як CMDB, ви можете запитувати за допомогою різних інструментів (він повертає дані JSON з HTTP-запитів), залежність між додатками може бути виражена по-різному і немає "поза коробкою" методом, кожна компанія матиме власний спосіб оголосити їх у системі для цілей конфігурації, і як такий ви можете скористатися цим для побудови свого графіка, але це на вашому боці.

У інфраструктурі як кодової точки зору потреби інфраструктури зберігатимуться з додатком, це все ще програма, яка знає, що їй потрібно, як середнє програмне забезпечення, яка ОС, яка локаль, які інші послуги залежать і які послуги ця пропозиція програми).

Останнє, про що я можу подумати, якщо ви хочете керувати цими залежностями лише для документації - це такі інструменти, як glpi, який є, головним чином, CMDB та системою продажу квитків, він використовує переваги документування активів та їх відношення, щоб мати змогу розповісти, на що впливає, коли ви відкриваєте квиток із заявою, що заявка не працює. у поєднанні з ng-інвентаризацією він дозволяє запитувати стан системи і як такий може виконувати ваш запит на потреби в патчі, але, на мою думку, це завдання системи аудиту, як можна зробити перевірку, інтегровану в межах шеф-кухаря для приклад, як наступний етап Виправити застарілі системи шляхом оновлення / виправлення.