TMACUL

Gestión de la Configuración: Las familias, clases y relaciones 18/12/2015

Blog Post created by TMACUL Champion on Feb 3, 2017

GESTÃO DE CONFIGURAÇÃO: Famílias, Classes e relacionamentos  18/12/2015 

 

Gestión de la Configuración: Las familias, clases y relaciones


Ayer al final no da tiempo para continuar en el tema, pero vamos ...

 

FAMILIAS Y CLASES
activos / CMDB Todo de IC se dividen en familias y clases. Dentro de la misma familia pueden ser de diferentes clases de especialistas.

 

Un CI puede ser cualquier cosa. Equipamiento de servidor, red, persona, lugar, servicio, organización, contrato, todo lo que su imaginación lo permita. Sólo desea para su gestión.

 

En mi opinión, el modelo de datos CMDB fue muy bien planeado dentro de la herramienta. Dependiendo del tipo de IC, puede haber más o menos implicados en los atributos de los objetos.

 

Por lo tanto, todos los elementos tienen atributos comunes pero, dependiendo de la familia involucrada, pueden existir atributos adicionales.


Por lo tanto, es posible de una manera racional para almacenar cualquier tipo de información sobre la base, gestionados (IC) o no (activo).

 

La CMDB puede almacenar activos corporativos tanto de IC. Cuando sólo se considera un activo de un elemento, de forma predeterminada, ya no será gestionado por la herramienta de SDM. En su lugar, la herramienta de Activos CA puede desempeñar este papel si se integra con SDM.

 

Recuerde siempre que el más granular para su CMDB, más familias y clases será utilizada y la más trabajo que tendrá que gestionar ellos.

 

Y lo más importante: No todo lo que se puede registrar para ser registrado en la base. Y es por esta razón por la que tenemos que centrarnos sólo en los elementos de configuración que serán gestionadas por su empresa.


Esta decisión no es fácil de tomar, ya que implica algunas cuestiones conceptuales que abordarán cuando se trata de relaciones en la base.

 

RELACIONES


Apenas un IC se aísla en infraestructura. Lo más a menudo, no es un proveedor de IC e IC de la IC dependiente.
Como ejemplo, considere un servidor ...
Está conectado a la red, que depende de otros equipos de prestación de servicios, atender a los clientes específicos, tiene un software, y todas estas relaciones "pueden" ser consideradas entidades de crédito.

 

Por lo tanto, dependiendo de la finalidad de la infraestructura y la lógica del IC y físico que conlleva, puede haber de "enlaces" que conectan decenas "piezas de este rompecabezas."

Y al igual que la base catastral de CI, las relaciones también deben ser registrados y mantenidos en la CMDB, manualmemte o automáticamente.

 

Porque sólo de esta manera se puede responder a estas preguntas que hice en el primer post que escribí acerca de la configuración de la eficiencia del proceso.


Para ser más didáctica, seguir el razonamiento ...

 

Cuando una solicitud de cambio se abre por un analista, al menos un IC va a cambiar y puede tener un impacto en su infraestructura. Y dependiendo del tamaño de esa infraestructura, es posible que el analista no puede evaluar con precisión el impacto real de los cambios.


Y este impacto generado se puede calcular sólo si existen relaciones entre el CI y sus servicios.

 

La mayor dificultad en esta evaluación es que pasar por todos los niveles de las relaciones para identificar todos los servicios para la familia de la IC en cuestión. No se olvide que es relación de dependencia puede ser indirecta, es decir, puede haber otros circuitos integrados en los diferentes niveles implicados en esta topología.

 

Para facilitar este trabajo, "La gestión del cambio" puede utilizar la función "visualizador de CMDB" o propia "Explorador de impacto" del cambio, presente en la herramienta de SDM.

 

Una de las cuestiones más difíciles que necesitan ser contestadas antes de comenzar cualquier proceso de implementación de las relaciones está en el nivel de detalle que existe en la CMDB.

 

Un sistema puede ser considerado como un único software familia IC. Pero nada impide que este sistema es "roto" en módulos más pequeños de tipo IC, características, servicios de infraestructura, servicios web, URLs, etc.


Toda esta información para proporcionar información de impacto más precisa para el servicio de negocio.


El gran problema es que, existen las más partes no son los más relaciones. Y no todas las relaciones se pueden crear automáticamente.

 

Vimos el tamaño del dolor de cabeza? Sí. Mi recomendación es pensar bien antes de iniciar relaciones cargos. A veces no es fácil de ser muy experto.

 

La próxima semana se publicará la rutina SPEL que he desarrollado que facilita la exploración de las relaciones en la base y añade un gran valor para los cambios. Espere!

 

¡Buen fin de semana!

 

 

Publicado Originalmente: 18 de dezembro de 2015 às 23:38

FB: CA SDM Brasil 

Por: Daniel Bighelini

Outcomes