¿Qué se recomienda para documentar una pila de tecnología de TI, incluida su relación entre sí, en una base de datos gráfica?

Trabajando para una gran empresa con más de 500 empleados de TI y más de 1,000 servidores, con cada servidor ejecutando sus propias aplicaciones comerciales, tenemos un enorme desafío de información y coordinación para saber con qué miembro del personal de TI contactar con cada servidor. El problema de la coordinación se agrava con la responsabilidad del personal de TI diferente por las diferentes capas de la pila de TI. Por ejemplo, hay diferentes equipos responsables del hardware, la virtualización, los sistemas operativos, los servidores de aplicaciones y las propias aplicaciones.

Teniendo en cuenta este desafío, dentro de DevOps existe el requisito de definir y documentar todos los componentes que constituyen las diversas pilas de tecnología dentro de un entorno de TI. Tradicionalmente, esto podría haberse logrado con una solución CMDB propia.

He investigado soluciones típicas de CMDB como BMC Atrium y otras para este propósito, sin embargo, el problema es que se detienen al nivel de documentar los activos de TI, a un alto nivel, según el marco ITIL, pero no abordan la documentación de la pila de tecnología de TI en detalle. También he investigado herramientas como Puppet , Ansible y Salt , pero estas herramientas se centran más en la implementación y configuración de software, y no en la coordinación de personas en torno al software.

Una solución viable, por ejemplo, definiría los diversos conceptos, junto con los atributos clave importantes para estos conceptos:

• Hardware
• Virtualización
• Sistemas operativos
• Servidores de aplicaciones
• Aplicaciones

Estos conceptos se asociarían entre sí en términos de sus relaciones para formar soluciones. Por ejemplo, una aplicación dependería de un servidor de aplicaciones, que dependería de un sistema operativo, etc. En conjunto, esta solución se definiría en el "Sistema de Finanzas". Una vez definido un sistema, todos los metadatos asociados con estos sistemas se capturarían para facilitar la coordinación de cada capa en la pila. Es decir, la coordinación del personal de soporte técnico para cada capa.

El propósito de tal solución sería hacer varias consultas contra las pilas de tecnología, tales como:

• Para determinar quién apoya qué componentes
• Qué componentes están desactualizados
• Qué componentes necesitan ser parcheados

Con esto en mente, ¿qué herramientas de código abierto existen para definir todos los componentes de una pila de tecnología de TI, incluida su relación entre sí, en una base de datos gráfica como Neo4J?

Teniendo en cuenta su primer párrafo, la organización que está describiendo es una organización muy aislada, que es exactamente lo que una organización DevOps tiende a evitar.

Teniendo en cuenta este desafío, dentro de DevOps existe el requisito de definir y documentar todos los componentes que constituyen las diversas pilas de tecnología dentro de un entorno de TI. Tradicionalmente, esto podría haberse logrado con una solución CMDB propia.

Lo que está describiendo aquí podría ser ITIL, que es un sistema de gestión que requiere documentación y lo mezcla con el hecho de que un equipo de DevOps generalmente definirá las capas subyacentes como código, por lo que vuelve a cualquier documentación de desarrollo con las advertencias del Código Esta documentación se ve a menudo en la metodología Scrum para una metodología ágil de desarrollo (iteraciones rápidas y cortas que apuntan a una solución de trabajo mínima al final de la iteración)

Descargo de responsabilidad para el resto de esta respuesta: sé más de chef e inspección y es por eso que los tomo como ejemplo aquí; pero no son las únicas herramientas existentes en el mercado, no abriré un debate sobre ellas, ya que la mejor es con la que se siente más cómodo.

Como tal, el resto de la pregunta es un poco parcial y yo, personalmente, no encontré una organización que documente la relación de capa que usted describe más que la infraestructura como código y documentación de código del sistema de administración de configuración. (De nuevo, esto no significa que nadie lo haga, simplemente nunca escuché hablar de eso).
Para ilustrar desde mi empresa en un entorno de chef, un libro de cocina de aplicaciones declarará sus dependencias (tomcat, jboss, nginx / php y de qué sistema operativo, necesitaba puntos de montaje para algunos datos compartidos y su nombre de esquema de base de datos principalmente) y expondrá sus URI de servicios a será consumido por el chef para la configuración de otras aplicaciones, esto suena como la definición de su 'Sistema de Finanzas' y la documentación está en este libro de cocina README, con algunos archivos más si es realmente necesario.

Los sistemas de gestión de la configuración suelen tener un lugar central de informes, "chef-servidor" para los datos y una "gestión de la interfaz de usuario" para su presentación en el mundo del chef "torre ansible" para el mundo ansible para nombrar dos de ellos, pero generalmente apuntan más a supervisar el sistema administrado general que graficar las dependencias.

Dicho esto, para chef, el chef-servidor también actúa como un CMDB que puede consultar con varias herramientas (devuelve datos JSON de solicitudes HTTP), las dependencias entre aplicaciones se pueden expresar de varias maneras y no hay 'fuera de la caja' Según el método, cada compañía tendrá su propia forma de declararlos en el sistema con fines de configuración y, como tal, puede aprovechar esto para construir su gráfico, pero eso está de su lado.

En una infraestructura como punto de vista del código, las necesidades de infraestructura se mantendrían con la aplicación, sigue siendo la aplicación quien sabe lo que necesita como middleware, qué sistema operativo, con qué configuración regional, qué otras dependencias de servicios y qué servicios Esta oferta de aplicación).

Lo último en lo que puedo pensar si desea administrar esas dependencias solo para documentación son herramientas como glpi, que es principalmente un CMDB y un sistema de tickets, aprovecha la documentación de los activos y su relación para poder saber qué se ve afectado al abrir un boleto que dice que una aplicación está inactiva. junto con ng-Inventory, permite consultar los estados del sistema y, como tal, puede satisfacer su consulta para las necesidades de parches, pero en mi opinión, esta es una tarea del sistema de auditoría, como podría hacer una inspección integrada dentro de una ejecución del chef, por ejemplo, como lo haría la siguiente fase ser para arreglar los sistemas obsoletos actualizándolos / parchándolos.