Gestión de Configuraciones
Clasificación y Registro
La principal tarea de la Gestión de Configuraciones es mantener la CMDB.
Es imprescindible, para llevar esta labor con éxito, predeterminar la estructura
del CMDB de manera que:
- Los objetivos sean realistas: una excesiva profundidad o detalle puede
sobrecargar de trabajo a la organización y resultar, a la larga,
en una dejación de responsabilidades.
- La información sea suficiente: debe existir, al menos un registro de todos
los sistemas críticos para la infraestructura TI.
Alcance
En primer lugar habremos de determinar que sistemas y componentes TI van a ser
incluidos en la CMDB:
- Es esencial incluir al menos todos los sistemas de hardware y software
implicados en los servicios críticos.
- Se debe determinar que CIs deben incluirse dependiendo del estado de su
ciclo de vida. Por ejemplo, pueden obviarse componentes que ya han sido retirados.
- Es recomendable incorporar, al menos, la documentación asociada a proyectos,
SLAs y licencias.
En general cualquier servicio o proceso es susceptible de ser incluido en la CMDB
pero unos objetivos en exceso ambiciosos pueden resultar contraproducentes.
Nivel de detalle y Profundidad
Una vez determinado el alcance de la CMDB es imprescindible establecer el nivel
de detalle y profundidad deseados:
- Determinar los atributos que describen a un determinado CI.
- Tipo de relaciones lógicas y físicas registradas entre los diferentes CIs.
- Subcomponentes registrados independientemente.
Por ejemplo, si se decide incluir los equipos de sobremesa en la CMDB:
- Atributos: Fecha de compra, fabricante, procesador, sistema operativo, propietario,
estado, coste, etc.
- Relaciones: conexión en red, impresoras conectadas, etc.
- Profundidad: tarjetas de red, discos duros, tarjetas gráficas, etc.
Nomenclatura
Aunque este sea un aspecto muy técnico es de vital importancia predefinir los códigos
de clasificación de los CIs para que el sistema sea funcional:
- La identificación debe ser, por supuesto, única y si es posible interpretable por
los usuarios.
- Este código debe ser utilizado en todas las comunicaciones referentes a cada
CI y si es posible debe ir físicamente unido al mismo (mediante una etiqueta de difícil
eliminación).
- Los códigos no deben ser sólo utilizados para componentes de hardware sino también
para documentación y software.
hola que tal, muy bueno tu curso, queria saber si hay agun modelo de como hacer la CMDB ya que es la parte fundamental de esto y queria que me asesoren en esto ya que se estoy en un proyecto donde se esta implementado ITIL, gracias
Marcar mensaje como inapropiado
Por cathy 25/10/2007
Estimados amigos, como se ha definido ya, los CI tienen estrecha relación con la CMDB, ya que son practicamente los componentes principales de la misma, por otro lado, habría que tener (y esto depende del software que contiene la CMDB) la siguiente información:
* Tipo: Físco o Lógico
* Sub-Tipo: Si el tipo de CI es físico, los subtipos podrán ser Hardware, Software, Documentación y Usuarios/Grupos; si el tipo de CI es lógico, los subtipos podrán ser Aplicaciones, Subsistemas, Servicios IT.
* Ubicación: En este campo se debe identificar la ubicación (física) del CI.
* Propietario: Es la persona responsable del CI, no necesariamente quien utiliza este recurso.
* Descripción: La descripción del mismo
* Vendedor/Proveedor: De quien se ha comprado
* Modelo/Marca:
* Nro de Serie:
En la sección de Atributos se podría indicar:
* Versión:
* Fabricante:
Posteriormente, se definen las relaciones que pueden tener los CI entre sí.
Un saludo desde Santa Cruz Departamento Autónomo de Bolivia.
Fernando Viveros P.
Email: fernanvp@gmail.com
Marcar mensaje como inapropiado
Por Fernando Viveros Palma 13/02/2008
Si es hardware y conectado a red también se deberia de identificar la dirección IP, si tiene acceso a internet..
Marcar mensaje como inapropiado
Anonimo 08/04/2009
Desde el puntos de vista de elementos críticos, debemos tener estandarizados nuestros procesos críticos, de tal forma que todo componente de Hardware, software, y recursos humano este claramente identificado, así en el evento de un un incidente que coloque en riesgo la operatividad del negocio, tengamos claro el paso a paso en el diagnostico y solución del incidente y quienes deben necesariamente intervenir en el. Procedimientos claramente documentados, inventarios al día, proveedores y personal interno implicado, como software requerido, es muy importante para ser almacenado en un centro de documentación centralizado o no, según sea el caso. Al fin y al cabo lo que nos interesa es saber que debemos hacer si se presenta un incidente que pasos hay que seguir y tener claro los tiempos de solución. Sigo insistiendo si ustedes hacen un BCP y un DRP bien elaborado esto que se expresa aquí debe sonar muy pero muy familiar, porque al fin y al cabo es la operatividad del negocio basada en la identificación plena de los procesos críticos. Quienes mejor conocen el proceso son el mismo personal, para ellos hay que crear estándares en documentación junto con un centro de documentación que maneje versiones, perfiles, etc. un verdadero DMS. Es la parte mas aburrida para el personal técnico porque es documentar y muchos no les gusta eso, así que delegar esa tarea a una persona que acompañe al personal en su nueva disciplina es lo mas adecuado. os formatos de documentación deben ser mediante formato estándar definido por IT, para se mandatorio para las diferentes áreas que la conforman BD, Infraestructura de red y operativa, sistemas administrativos, soporte de usuarios o helpdesk etc. Para quienes les gusta el software libre KnowledgeTree es una idea, OpenSharePoint otra para los que no a lo mejor Microsoft SharePoint sea una.
Marcar mensaje como inapropiado
Por Fabian Cortes 21/04/2009
