Texto de apoyo {CM}

Funciones y Responsabilidades

Administrador de la configuración

Las responsabilidades del encargado o administrado de la configuración son:

• Trabajar los objetivos generales de acuerdo con el servicio de gestión IT; implementar la política de gestión de configuración de la empresa y sus estándares.
• Evaluar los sistemas de gestión de configuración existentes y el diseño, implementación y gestión de sistemas nuevos o mejorados para una mayor eficacia o eficiencia- incluyendo estimaciones y planificaciones de trabajo de recursos relacionados, rastreando e informando del progreso respecto a la planificación.
• Proponer y consentir el alcance de los procesos de la gestión de configuración, funciones, los ítems que deben ser controlados, y la información que hay que grabar. Desarrollar las normas, los planes y los procedimientos de la gestión de configuración.
• Montar una campaña de conciencia para ganar el soporte para el nuevo procedimiento de la gestión de configuración. Asegurar los cambios de los métodos y de los procesos de la gestión de configuración que han sido comprobados correctamente y avisados al personal antes de ser implementado. Planes, publicaciones e implementaciones en el nuevo sistema de la gestión de configuración
• Fabricar las herramientas para producir un medio efectivo de la gestión de configuración en términos de la base de datos y de las librerías del software y de la generación del informe.
• Crear y gestionar el plan, los principios y los procesos de la gestión de configuración y sus implementaciones. Esto incluye los procedimientos del registro del CI; acceso de la lista de control y privilegios. Asegurar que los roles y las responsabilidades correctas están definidos en los planes y procedimientos de la gestión de configuración.
• Proponer y ponerse de acuerdo con los CIs para ser identificados de forma unívoca con las convenciones de nombres correctas. Asegurarse de que el personal cumple con los estándares de identificación en tipos, entornos, procesos, ciclos de vida, documentación, versiones, formatos, bases, emisiones y plantillas (todo el contenido de la CMDB).
• Proponer (y/o ponerse de acuerdo) interfaces con la gestión de cambios, la gestión de problemas, gestión de redes, gestión de difusión, operaciones informáticas, finanzas y funciones de administración (con el resto de procesos en el departamento).
• Planificar y ejecutar la población de la CMDB. Gestionar y mantener la CMDB, las librerías centrales, las herramientas, los códigos de dominio público y los datos. Asegurar la administración de la CMDB.
• Proporcionar informes, incluyendo los de gestión (añadiendo la acción sugerida para realizar con las previsiones actuales o futuras), informes de impacto de análisis e informes del estado de la configuración.
• Usar o proporcionar la CMDB para facilitar el cálculo del impacto de los RFCs y para asegurar que los cambios implementados están autorizados. Al crear los registros de cambios, las bases de configuración, y el empaquetado de los registros de emisión se especifican los efectos en los CIs de un cambio autorizado.
• Proporcionar la CMDB para identificar otros CIs afectados por un error que está afectando al CI.
• Desarrollar las auditorías de configuración para comprobar que el inventario IT físico está acorde con la CMDB e iniciar la acción correctiva necesaria.
• Iniciar las acciones necesarias para asegurar los fuentes de forma que se mejore la infraestructura y los niveles de acceso de los empleados para arreglárselas en caso de cambio y/o crecimiento.
• Ayudar a los auditores en las actividades de auditoría del equipo de gestión de configuración para colaborar en los procedimientos establecidos. Asegurar la acción correctiva que se lleva a cabo.

Bienes versus Gestión de Configuración

Bien

Componente de un proceso tal como personas, alojamiento, sistemas informáticos, expedientes de papel, máquinas de fax, etc.

Elemento de Configuración (CI)

Componente de una infraestructura - o un artículo, tal como una Solicitud de Cambio, asociado con una infraestructura- y servicios, que estén (o han de estar) bajo el control de Gestión de Configuración. Cl’s pueden variar mucho en complejidad, tamaño y tipo- desde un sistema entero a un componente de hardware menor. Ejemplos son: hardware, software, documentación, procedimientos, funciones, alojamientos, servicios, servidores, entornos, equipamiento, componentes de red, escritorios, unidades móviles, aplicaciones, licencias, telecomunicación.

Base de Datos de Gestión de Configuración CMDB

Muchas organizaciones ya utilizan algunos elementos de Gestión de Configuración, a menudo usando hojas de cálculo, bases de datos locales o sistemas basados en papel. En las infraestructuras de hoy en día grandes y complejas, la Gestión de Configuración requiere el uso de herramientas de soporte, que incluye la base de datos de Gestión de Configuración (CMDB). Son necesarios archivos electrónicos y físicos junto al CMDB para almacenar copias definitivas de software y documentación. Es probable que la CMDB se base en tecnología de base de datos que proporciona facilidades de interrogación flexibles y poderosas. La CMDB debe contener todas las relaciones entre los componentes del sistema, incluidos Incidencias, Problemas, Errores Conocidos, Cambios y Difusiones. La CMDB también contiene información sobre Incidencias, Errores Conocidos y Problemas y datos corporativos de empleados, proveedores, localidades y unidades de negocio.
La CMDB también se puede utilizar para almacenar y controlar los detalles de los usuarios de IT, empleados de IT y unidades de negocio, aunque las implicaciones legales de almacenar información sobre personas en la CMDB se deben considerar. Almacenar tal información en la CMDB permitiría que Cambios de Personal se relacionaran con la propiedad de Cambios de CI.

Rango y Detalle (Profundidad)

La Infraestructura de IT consiste en artículos de configuración. Un artículo de configuración es un elemento documentado de la infraestructura de IT, tal como hardware, software, alojamiento, personas y documentación (Categoría).

Rango CMDB

El factor primordial al decidir tanto el rango como el detalle es la información necesaria para gestionar el servicio al margen del coste o dificultad de obtener y mantener esos datos. Un punto de vista más pragmático es que no sólo se deben tener en cuenta esos factores sino también, y puede que de modo más importante, los directores deben considerar las consecuencias de almacenar datos poco exactos o desfasados en la CMDB.
Antes de que la transición de montar una CMDB se lleve a cabo, se debe decidir acerca de qué parte de la infraestructura de IT será controlada por la Gestión de Configuración. La elección del Rango influye al rango de diagnósticos de Gestión de Problemas, para la coordinación de Gestión de Cambios, etc. Esta elección se recoge de las Declaraciones de Misiones que se montan para los procesos. La elección del Rango también se monta en parte de un análisis de los servicios y su contribución a, o su impacto en, las actividades de negocio de los clientes. Aparte de esto, el Rango se puede recoger de la determinación del Acuerdo de Nivel de Servicio.

Detalle CMDB

Con la subdivisión en niveles, se crea una jerarquía de componentes y unidades. Se toman decisiones sobre qué son Cl’s principales y en cuántos niveles estos Cl’s deben ser detallados. El nivel más alto es la infraestructura de IT misma. El nivel útil más bajo es el nivel donde todavía sea posible llevar control. La encarnación de un CI en la CMDB sólo es efectiva cuando el control sobre el CI y la información que conlleva sea útil para otros procesos de ITIL.
Con el establecimiento de la jerarquía de una CMDB, rigen las siguientes normas:
Cuando hay más niveles, se debe mantener más información. Esto conlleva más trabajo y
resulta en una CMDB más grande.
Cuando hay menos niveles, hay menos control e información sobre la infraestructura de IT.
Cuando la CMDB no tiene profundidad suficiente, los cambios a los componentes más bajos no se puede mantener adecuadamente. Cada ajuste a componentes de un CI madre resultará en una versión alternativa del CI madre; un PC que aparece con dos discos duros tendrá entonces una versión A y una versión B. Si aparecen muchos ajustes en los componentes filiales, entonces la numeración de variación se volverá opaca y difícil de seguir.

Nombramiento y otros atributos

Nombramiento

El nombre de un CI debe ser único. Cada CI en la infraestructura controlada debe ser identificado y sólo podemos hacer esto, dando a cada CI un número único. Como su automóvil. Este automóvil es único en- el mundo por una combinación de números en su matrícula y el estado /país donde vive.
Nombramiento debe ser lógico y sencillo. Sencillo porque ¿qué necesidad hay de hacerlo difícil? Personal de IT y clientes deben tener idea de cómo leer y montar la identificación de CI. Así que intente encontrar una identificación lo más lógica y sencilla como le sea posible: como Al 234567 en vez de PC_BUILDA_LOKI.4_ 1234.
A lo largo del ciclo vital de un CI, la primera identificación dada debe permanecer. !que la excepción confirma la regla! Así que esta es otra razón por la que no implementar números como PC_BUILDA_LOKI.4_ 1234 porque se relacione con el edificio donde se instaló.

Relaciones en la CMDB

Se pueden llevar al día muchos distintos tipos de relaciones. Las relaciones más frecuentes son:

• Es un componente de; esta es la relación de madre-hija del CI, como un disco A es un componente de un PCy un módulo de software es un componente de un programa.
• Es una copia de; una copia de un modelo estándar o de un programa.
• Se relaciona a un procedimiento, un SLA o un programa
• Se relaciona con; por ejemplo, un PC que está conectado con un segmento LAN.
• Es utilizado por; como un CI que es utilizado por un servicio, para que se puedan calcular los costes y la disponibilidad del servicio, o un módulo de software que es necesario para varios programas para que se pueda hacer un seguimiento de “cuál es el impacto de un ajuste”.

Igual que al determinar el número de niveles, es necesario sopesar de forma meticulosa qué es necesario, la cantidad de trabajo que conlleva y los recursos disponibles para ese trabajo, se debe hacer al determinar las relaciones necesarias.

Otras relaciones:

RFC’s: La relación con todas las RFC’s afectando este CI.
Relación con Cambios: La relación con todos los archivos de cambios afectando a este CI
Relación con Problemas: La relación con todos los archivos de Problemas afectando este CI
Relación con Incidencias: La relación con todos los archivos de Incidencia afectando este CI

Estados de CI’s

El ciclo de vida de un componente se puede dividir en muchas etapas distintas. Cada etapa puede recibir un código de estatus. Esta información se determina por los intereses que la organización ha hecho públicos con respecto a los rasgos de la infraestructura de IT que necesitan ser registrados. Al guardar la fecha de los cambios de estatus, se puede desarrollar una buena visión del ciclo vital de un producto; las horas de adquisición, las horas de instalación y la cantidad de mantenimiento y soporte que se ha invertido.
El estatus de un componente también puede ser decisivo en lo que se pueda hacer con él. Por ejemplo, cuando un estatus se mantiene al día de provisiones (no operacionales) este equipamiento no se puede utilizar para otras actividades sin consultar en general. El cambio del estatus puede estar afiliado a un ajuste o cambio, permitido o no permitido, o a una incidencia.
Se puede considerar la siguiente subdivisión:
Nuevos CI’s:

• En desarrollo/pedidos
• Probados
• Aceptados

CI’s Existentes:

• Recibidos.
• Aplicación no fijada de cambio para este CI, solicitada nueva versión.
• El cambio ha sido aprobado y se ha considerado en el plan, un nuevo CI y documentación (que también es un CI) llega.
• Bajo mantenimiento.
• Fuera de servicio, problemas técnicos
• Fuera de uso, archivado

Todos los CI’s:

• La orden se ha recibido o la versión ajustada está disponible.
• Está siendo probado
• Liberado, se puede instalar
• Activo, el CI está siendo utilizado.
• Provisiones

Línea Base (Baseline)

Una línea base de configuración es la configuración de un producto o sistema establecido en un momento concreto en el tiempo, que capta tanto la estructura como los detalles de una configuración. Es una referencia para más actividades. Una aplicación o línea de base de software proporciona la habilidad de cambiar o reconstruir una versión concreta en una fecha más adelante.
Las líneas base de configuración se deben establecer mediante un acuerdo formal en momentos concretos del tiempo y se deben utilizar como puntos de referencia para el control formal de una configuración. Las líneas base de configuración mas cambios aprobados a esas líneas de base, juntos, constituyen la configuración actualmente aprobada. Ejemplos específicos de líneas base que se pueden identificar son:

1. Un CI estándar particular necesitado cuando se compran muchos artículos del mismo tipo (p.ej. ordenador de escritorio) a lo largo de un periodo protactado. Si unos servidores deben incluir teclados de circuito impreso adicionales, esto podría corresponder a una “línea base plus”. Si todos los ordenadores de escritorios en el futuro tendrán estos teclados, se forma una nueva línea base.
2. Una aplicación de Difusión y su documentación asociada

• A la que referirse (debe existir físicamente y poder referirse a ella con facilidad)
• Como estado del software para distribución a locales remotos
• Como estado del software sobre el que trabajar en un futuro

Como estado en el que debe estar un sistema antes de poder mejorarlo aceptando nuevo hardware

• Software

Varias líneas base correspondientes a distintas etapas en la vida de un “artículo de línea base” pueden existir en un momento dado- por ejemplo, la línea base para una difusión de software que ya está en “vivo”, la de que estaba “vivo” anteriormente a éste y que ahora se encuentra archivado, el próximo que se instalará (salvo cambios bajo control de Gestión de Configuración) y uno o más bajo prueba. Más allá, si, por ejemplo, nuevo software se está introduciendo gradualmente a nivel regional, más de una versión de línea base podría estar “viva” a la vez. Por lo tanto, es mejor referirnos a cada una por su número exclusivo de versión, mejor que como “vivo”, “próxima” o “antigua”.
Una línea base de configuración es también una instantánea, o una postura, que está grabada. Aunque la posición se pueda actualizar después, la línea base de configuración se queda fijada como el estado original y por lo tanto, está disponible para poder compararse con la posición actual. Una línea base de configuración se utiliza para montar todos los componentes relevantes en preparación para un Cambio o una Difusión, y para proporcionar la base para una auditoria y regresión p.ej. después de un Cambio. El sistema de Gestión de Configuración debería poder guardar, proteger e informar de una línea base, su contenido y documentación.

Informes de Gestión

Los informes de gestión deberían estar diseñados para soportar actividades de Gestión de Servicio tales como monitorización de progreso, auditorias de Configuración y programación de servicios. Los informes se deben poner a disposición para interrogación y análisis de tendencias por parte de la Dirección de Servicio de IT y otros grupos dentro de la estructura de servicios de IT. En general, la Dirección de Gestión de Servicios debe marcar la dirección futura de la Gestión de Configuración a la luz de estos informes de gestión, teniendo en cuenta la carga de trabajo y crecimiento de la Gestión de Configuración programada.
Informes de dirección de Gestión de Configuración deberían cubrir lo siguiente.

• Resultados de auditorias de configuración
• Información sobre CI’s no-registrados o registrados de modo poco exacto que se han detectado y la acción correctiva
• Información sobre el número de Cl’s registrados y versiones de CI’s, divididos por categoría, tipo y estatus (y posiblemente también por localización u otros atributos de CI)
• Información de crecimiento y capacidad
• Información sobre el ritmo de cambio de Cl’s/ CMDB y la DSL
• Detalles de trabajo acumulado (backlogs) de Gestión de Configuración o atrasos causados por actividades de Gestión de Configuración y remedios propuestos.
• La posición de personal de Gestión de Configuración
• La cantidad de trabajo autorizado realizado fuera de horario por empleados de otros servicios de IT
• Los resultados de revisiones de eficiencia / efectividad, revisiones de crecimiento y auditorias del sistema de Gestión de Configuración y propuestas para atacar problemas reales o en potencia
• Datos y análisis del número de Cl’s por tipo (p.ej. servicios, servidores, enrrutadores, conmutadores, licencias de software, CI’s de escritorio, etc.)
• El valor de los Cl’s (o bienes)
• La localización de CI’s por unidad de negocio, grupo de soporte o servicio.