dependencies - plugin - Cómo rastrear las dependencias del sistema?
maven import dependency plugin (10)
Apague cada máquina una a una y vea qué se rompe ...; p
En serio, no hay una respuesta simple a esta pregunta. Con una colección de sistemas, podría crear un diagrama que muestre las dependencias básicas, pero no tendría un gran significado a menos que tuviera una idea de la dependencia. Por lo general, su objetivo es determinar qué necesita para "revalidar" cuando cambia otro sistema, no qué máquinas puede apagar al azar. Pero ese tipo de información requiere una gran cantidad de detalles y es difícil de acumular en primer lugar.
Todo esto finalmente termina en una situación en la que sus sistemas están por delante de su automatización. Nunca encontrará una herramienta de automatización contraída que se mantenga al día. Por otro lado, con tantos detalles necesarios, cualquier cosa que pueda ocuparse de la mitad o incluso un tercio de la carga de trabajo será valiosa.
Introducción
En mi organización actual, tenemos muchas aplicaciones de escritorio y web que se alimentan entre sí en algún momento. Cuando se buscan aplicaciones antiguas o se crean aplicaciones nuevas, resulta muy difícil intentar recordar qué sistema depende de otros sistemas para funcionar. No estoy hablando de dependencias de software como DLL e imágenes, estoy hablando de sistemas completos como un sistema de Finanzas que depende del sistema de recursos humanos, etc.
Mi pregunta
¿Cuál es la mejor forma de rastrear cómo un sistema completo depende de otro?
La respuesta puede sugerir un método para hacer lo anterior, un paquete de software o técnicas de documentación.
En mi caso particular, Many significa más de 20 aplicaciones web y de escritorio en una docena de servidores.
Este es el tipo de aplicación que producimos en Tideway Systems , y que muchas organizaciones grandes utilizan para este propósito. Puede utilizar el producto para descubrir su patrimonio y utilizar las capacidades de modelado para describir sus aplicaciones comerciales (que generalmente constan de más de una pieza de software y servidores de intervalo).
Parece que califica para usar Community Edition of Foundation, que puede usar en hasta 30 servidores, solo descárguelo y compruébelo. ¡Entonces díganos lo que piensa, por favor!
Descargo de responsabilidad: Dirijo el grupo de desarrollo en Tideway . El producto es muy interesante, aunque no lo he escrito directamente :)
La mejor fuente de información se encuentra generalmente en los archivos de configuración. Esto normalmente tiene las cadenas de conexión, las URL del servicio web, etc., que darán una buena idea sobre las dependencias externas.
Otra técnica es mediante el uso de perfiles o el seguimiento y la aplicación de filtros, podemos rastrear fácilmente cualquier llamada externa. La mayoría de los casos, la dependencia está en la capa de la base de datos, y la comprobación de los servidores vinculados y el seguimiento de sus dependencias puede desenterrar mucha información.
No estoy seguro de si hay alguna forma automática de obtener esta información, especialmente si los sistemas están en múltiples plataformas. Se necesitará mucho trabajo manual para documentar todo eso.
Suena como un trabajo para un descubrimiento empresarial que está automatizado en la medida de lo posible. Según el tamaño de su organización y el entorno, existen diferentes soluciones. Para paisajes grandes, necesitará una CMDB (Configuration Management Database) de todos modos. Productos como HP Universal CMDB pueden descubrir y rastrear dependencias en entornos de gran escala.
Por ejemplo, puede descubrir las relaciones entre un sistema SAP y sus bases de datos relacionadas y los hosts en los que se ejecutan los sistemas distribuidos y mostrarle las dependencias. Más importante, puede advertirte en caso de que se realicen algunos cambios no autorizados en el entorno real.
Entonces, la respuesta depende de lo que usted considere como "muchos".
Yo diría que indiquen claramente eso en su documento de diseño de arquitectura. Hay algunas buenas herramientas para esto, como Enterprise Architect . Esta herramienta le permite crear diagramas usando el estándar UML para describir estas dependencias de una manera clara y visual.
La asignación de dependencia del sistema es una cosa. Las verdaderas configuraciones medioambientales, los uid, las contraseñas, las configuraciones de suplantación, los nombres de bases de datos y otros datos que cambian de desarrollo a qa uat a producción son el verdadero desafío.
¿Quién los almacena / recuerda a todos?
El desarrollador no sabe en qué servidor (s) de producción residirá su aplicación. Solo documenta el nombre de su base de datos de desarrollo, uid''s, pwd''s y describe sus tablas de base de datos, cadenas de conexión, etc.
Una vez que se ha registrado en el repositorio de código y se ha migrado al entorno de control de calidad, ¿quién es el guardián de los datos necesarios para actualizar esos archivos de configuración con los valores adecuados?
Nuevamente, cuando se migró a QA y UAT, ¿quién?
¿De quién es la responsabilidad de informar al próximo grupo de migración sobre lo que se debe cambiar?
En mi compañía, esto es lo que nos causa más dolor de cabeza. Cuando se aprueba el proceso interno de control de cambios y se crea una solicitud de migración para migrar la aplicación al entorno de producción, todo lo que se necesita es una configuración que olvidar para arruinar toda la implementación, y sucede todo el tiempo porque las líneas claras de responsabilidad no se dibujan (en mi opinión).
Más allá de la responsabilidad, creo que es un repositorio central para esta información.
es decir. Un sistema que almacena todos los ajustes de configuración para todos los proyectos / aplicaciones, y basado en su "rol" puede / no puede ver los valores reales.
El desarrollador finaliza su compilación y crea una solicitud de migración en el "sistema". La persona de QA recibe la notificación de que la compilación ### está lista. La persona de QA inicia sesión en el "sistema" y recupera las instrucciones de migración. Ahora saben claramente lo que se debe hacer, y están iniciando el proceso de migración y verificación del código.
Repita para UAT y finalmente prod.
Cuando alguien construye este sistema de migración, avíseme, porque ESO ayudará a muchas personas.
Tal vez lo construya yo mismo ... ¿Quién quiere contratarme?
Dos tipos de problemas involucrados:
a.) para aquellos que desean saber cómo determinar dependencias para cada componente
b) para aquellos que desean rastrear las interdependencias y sus prioridades en un sistema de componentes. (como en, qué componente se instala primero en un entorno de prueba, etc.)
Si lo que tiene es una serie de componentes, para cada uno de los cuales conoce dependencias, y desea un pedido de dependencia para toda la lista de componentes, puede encontrar que un módulo de Perl llamado Algorithm :: Dependency :: Ordered tiene algún valor . Hay otros módulos relacionados que pueden funcionar con registros de bases de datos de componentes, etc., o incluso registros de archivos simples. Pero una advertencia: he tenido problemas para hacer que esto funcione.
Alternativamente, una herramienta de gráficos puede ser valiosa.
Esta es la función de un grupo de "Gestión de configuración". Para comenzar, tendrá que hablar con los "expertos" de su empresa y crear un mapa / gráfico de aplicaciones. Use graphviz / dot para generar un diagrama, no será bonito, pero le dará una representación visual de las dependencias.
Aquí hay un ejemplo:
digraph g {
rankdir=LR;
app1->app2->db1;
app1->app3;
}
Espero que esto ayude,
Esta es una buena pregunta, parece que luchamos con esto cada vez.
Lo que hemos tratado de hacer durante el último año es ser "despiadado" en dos cosas:
automatización: si la automatiza y construye / implementa a menudo, entonces el proceso de automatización tenderá a hacer las cosas bien la mayor parte del tiempo (configuración de configuración, etc.)
wiki, wiki, wiki - tratamos de ser coherentes para mantener al equipo y al wiki del proyecto actualizados.
Curioso por ver otras respuestas.
Era nuevo en un trabajo y me sugirieron como primera tarea identificar las dependencias del sistema. Resultó que lo que mi jefe quería decir era ir a hablar con la gente, de esa forma yo aprendería quién era quién. Pensé que mi jefe quería que escribiera un programa de computadora para hacer eso. Y así lo hice. Mi suposición era que si un programa era un cliente de otro programa (un servicio o un servidor), entonces netstat -pant y netstat -panu luego grep para ESTABLISHED le daría eso. Puede identificar los servicios colocando la salida para ESCUCHAR.
Esta es solo una solución parcial. Sí, te dice qué aplicaciones hablan con qué aplicaciones, pero hay otras dependencias. Entonces, por ejemplo, algunas aplicaciones usan DNS para encontrar sus servidores, mientras que otras están codificadas o en archivos de configuración. Todo lo que utiliza TCP o UDP depende de IP. En la mayoría de los lugares, IP depende de ARP y Ethernet o WiFi. Todo lo que dependa de un servicio en otra LAN depende de al menos un enrutador.
Si tiene un equilibrador de carga o algún tipo de clúster, entonces el problema se vuelve más interesante. Si un servicio que sale de un equilibrador de carga y el servidor "real" detrás del cortafuegos baja, entonces el servicio se degrada pero aún está activo.
Se pone aún más interesante porque los servicios (programas) dependen de los servidores (hardware). Los servidores, a su vez, dependen de la potencia y el aire acondicionado.
Así que a medida que mi pensamiento se descontrolaba, las cosas se complicaron cada vez más y pensé en crear un lenguaje específico de dominio (DSL) para capturar todas estas dependencias. Pensé que, por ejemplo, server_1, server_3 y server_5 están en la fase de potencia 1; server_2, server_4 y server_6 están en la fase de potencia 2. Server_1, Server_3 y server_5 fallan casi al mismo tiempo: probablemente la fase 1 ha fallado. Todavía no me he dado cuenta de eso. Obviamente, la situación puede ser representada por un gráfico dirigido, simplemente no he resuelto los detalles.