Что рекомендуется для документирования стека ИТ-технологий, включая их взаимосвязь, в графической базе данных?

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

Учитывая эту проблему, в DevOps существует потребность в определении и документировании всех компонентов, составляющих различные технологические стеки в ИТ-среде. Традиционно это могло быть достигнуто с помощью правильного решения CMDB.

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

Например, работоспособное решение будет определять различные концепции, а также ключевые атрибуты, важные для этих концепций:

• аппаратные средства
• Виртуализация
• Операционные системы
• Серверы приложений
• Приложения

Эти понятия затем будут связаны друг с другом с точки зрения их отношений, чтобы сформировать решения. Например, приложение будет зависеть от сервера приложений, который будет зависеть от операционной системы и т. Д. Вместе это решение будет определено в «Финансовой системе». После определения системы все метаданные, связанные с этими системами, будут захвачены для облегчения координации для каждого уровня в стеке. Т.е. координация работы персонала технической поддержки для каждого слоя.

Целью такого решения было бы выполнять различные запросы к технологическим стекам, например:

• Чтобы определить, кто поддерживает какие компоненты
• Какие компоненты устарели
• Какие компоненты должны быть исправлены

Имея это в виду, какие инструменты с открытым исходным кодом существуют для определения всех компонентов стека ИТ-технологий, включая их взаимосвязь, в графической базе данных, такой как Neo4J?

Учитывая ваш первый абзац, организация, которую вы описываете, является сильно разрозненной организацией, чего, как правило, избегает организация DevOps.

Учитывая эту проблему, в DevOps существует потребность в определении и документировании всех компонентов, составляющих различные технологические стеки в ИТ-среде. Традиционно это могло быть достигнуто с помощью правильного решения CMDB.

То, что вы описываете здесь, может быть ITIL, который представляет собой систему управления, требующую документации, и вы смешиваете ее с тем фактом, что команда DevOps обычно определяет нижележащие слои как код, как таковой, возвращаясь к любой документации по разработке с оговорками кода. Документация часто встречается в методологии Scrum для гибкой методологии разработки (быстрые и короткие итерации, направленные на минимальное рабочее решение в конце итерации)

Отказ от ответственности за остальную часть этого ответа: я знаю больше о шеф-поваре и инспекции, и именно поэтому я принимаю их в качестве примера здесь; но они не являются единственными инструментами, существующими на рынке, я не буду их обсуждать, так как лучше вам будет удобнее.

Таким образом, остальная часть вопроса немного предвзята, и я лично не сталкивался с организацией, документирующей отношение уровня, которое вы описываете больше, чем инфраструктура как документация кода системы управления кодом и конфигурацией. (Опять же, это не значит, что никто этого не делает, я просто никогда об этом не слышал).
Чтобы проиллюстрировать мою компанию в среде шеф-повара, поваренная книга приложения объявит свои зависимости (tomcat, jboss, nginx / php и от какой ОС, необходимые точки монтирования для некоторых общих данных и в основном от имени ее схемы БД) и предоставит URI своих служб для быть использованным шеф-поваром для конфигурации других приложений, это похоже на определение вашей «Финансовой системы» и документации для нее в поваренной книге приложения README, с некоторыми другими файлами, если это действительно необходимо.

Системы управления конфигурацией обычно имеют центральное место для отчетов: «chef-сервер» для данных и «пользовательский интерфейс управления» для представления в мире chef «ansible tower» для мира ansible, чтобы назвать два из них, но обычно они нацелены на обеспечение контроля общая управляемая система, чем график зависимости.

Тем не менее, для chef, chef-сервер также действует как CMDB, который можно запрашивать различными инструментами (он возвращает данные JSON из HTTP-запросов), зависимости между приложениями могут быть выражены по-разному, и «из коробки» нет метод, каждая компания будет иметь свой собственный способ объявить их в системе для целей конфигурации, и поэтому вы можете использовать это для построения своего графика, но это на вашей стороне.

В инфраструктуре с точки зрения кода потребности инфраструктуры должны быть сохранены вместе с приложением, и все же это приложение знает, что ему нужно в качестве промежуточного программного обеспечения, какая ОС, с каким языком, каковы зависимости других служб и какие службы это приложение предложение).

Последнее, о чем я могу подумать, если вы хотите управлять этими зависимостями только для документации, это такие инструменты, как glpi, который в основном представляет собой CMDB и систему создания билетов, он использует преимущества документирования ресурсов и их отношения, чтобы иметь возможность определить, что влияет на них при открытии. Билет говорит, что приложение не работает. в сочетании с NG-инвентаризацией он позволяет запрашивать состояния системы и, как таковой, может выполнять ваш запрос на необходимость исправлений, но, на мой взгляд, это задача системы аудита, как, например, проверка встроенного в прогон шеф-повара, например, на следующем этапе быть, чтобы исправить устаревшие системы путем обновления / исправления их.