Gestión de Cambios e Incidencias

Hemos discutido cómo la creación de una cultura ágil se ha convertido en una necesidad para la mayoría de las organizaciones y la importancia de evaluar la preparación operativa para su solución. La Gestión del Cambio y la Gestión de Incidentes son los pilares de la Gestión de Operaciones TI; y en un entorno ágil cuando los cambios ocurren con frecuencia, estos son componentes clave de su organización.

La gestión de cambios y la gestión de incidentes son prácticas de gestión de servicios de TI (ITSM) bien definidas que se incluyen en el marco de ITIL.

Si bien estos dos temas pueden no estar intrínsecamente relacionados, creo que están tan interconectados que deberían estar enraizados en la misma premisa.

La gestión de incidentes se trata de tener un proceso estructurado y bien definido al responder a un evento o interrupción, y la gestión de cambios se trata de tener un proceso para evaluar el riesgo de realizar un cambio en el entorno que podría causar un incidente. Si no tiene los medios para evaluar adecuadamente el impacto de una interrupción en su entorno, ¿cómo puede evaluar adecuadamente el riesgo de un cambio determinado?

Con ese fin, propongo el siguiente marco/flujo de trabajo como referencia. Si bien puede parecer un poco complejo al principio, el objetivo de este modelo es hacer que los procesos de evaluación del impacto sean menos un arte y más una ciencia, para eliminar parte de la subjetividad que puede interferir cuando se produce una interrupción. ocurriendo y los juicios se nublan por la urgencia del momento.

Nadie debería culparlo nunca por tener un proceso establecido y bien publicitado y por seguirlo, es posible que no estén de acuerdo con algunos de los detalles, pero siempre puede invitarlos a discutir para permitirles influir en los cambios en el futuro.

Las hojas de trabajo que se muestran a continuación están disponibles como una hoja de cálculo de Google compartida.

Evaluación del impacto de la interrupción

Evaluar las consecuencias de una interrupción es generalmente muy subjetivo. Si, por ejemplo, el impacto es una interrupción total de un sistema informático que tiene un solo usuario, lamento decir que la respuesta de su personal de TI será muy diferente si ese único usuario es un nuevo interno o el director general de la empresa. . Un sistema de desarrollo puede muy bien ser considerado como un sistema de producción para sus desarrolladores si no pueden hacer su trabajo sin ese sistema. ¿Pero tal vez puedan desarrollarse en su sistema local? Realmente depende de su situación, y debe tener en cuenta que lo que es cierto hoy puede no serlo mañana, debe reevaluar la importancia de ese sistema con regularidad.

Una vez más, la claridad y la transparencia son clave, y debe tener estas discusiones y llegar a un consenso sobre el resultado con los usuarios del servicio y las partes interesadas, tal vez en un documento de Objetivo de nivel de servicio (SLO) bien definido. Si es necesario, anime a los usuarios a proporcionar y mantener información precisa sobre el valor de este sistema para su equipo, tal vez un sistema de producción tenga copias de seguridad más frecuentes pero cueste más por mes.

La calificación de importancia de cada servicio debe realizarse a nivel de empresa, todos piensan que su División es más importante que las demás, y la calificación es relativa y debe permanecer bastante objetiva.

Comprender y documentar las dependencias en su entorno también es clave, especialmente con microservicios. ¿Quizás su servicio PoC es una dependencia ascendente de un sistema de producción? La metodología C4 (consulte Crear diagramas a partir de texto ) es bastante útil, la documentación es fundamental y no necesita un arquitecto de sistemas para hacer diagramas de Visio todo el día. Preferiré un diagrama tosco pero preciso a uno "bonito". día.

Disponibilidad

Para estar disponible, un sistema tiene que ser accesible y usable. Si un usuario no puede acceder al sistema, o si el sistema es lento o no responde, desde el punto de vista del usuario, no está disponible. Generalmente, el término tiempo de inactividad se usa para referirse a períodos en los que un sistema no está disponible.

Gravedad del incidente

La Severidad es la cantidad de daño o daño que un problema ha causado a la disponibilidad de un sistema, tal como lo ve el usuario.

experiencia, medida en términos de éxito o fracaso.

Para determinar la gravedad del Incidente, elija la categoría relevante más alta :

Tipo de impacto del incidente

El tipo de impacto del incidente tiene en cuenta la frecuencia de ocurrencia, medida por la frecuencia con la que ocurre el problema, así como la persistencia del problema, medida al observar si los usuarios que experimentan un problema pueden aprender a evitarlo o superarlo en el futuro. .

Los tipos son:

• Sostenido: el problema es constante para todos los usuarios durante un período de tiempo indeterminado
• Temporal: el problema es constante para todos los usuarios, pero solo durante un período breve y predeterminado
• Esporádico: el problema solo se manifiesta "de vez en cuando" o solo para algunos usuarios

La gravedad del incidente, combinada con el tipo de impacto, se utiliza para seleccionar el multiplicador del tipo de impacto.

Elija la categoría más relevante :

Pesos de los sistemas afectados y clasificación de categorías de incidentes

A los sistemas se les asigna un peso de sistemas arbitrario en función de su nivel relativo de criticidad para la organización.

Este peso, combinado con el multiplicador de tipo de impacto , se utiliza para determinar la puntuación de impacto .

Elija el sistema afectado con la puntuación más alta :

Administracion de incidentes

Una vez que tenga una comprensión clara del impacto de una interrupción total en un sistema en particular y que tengamos una forma de cuantificarlo, puede comenzar a definir su proceso de gestión de incidentes.

Alcance

El proceso de gestión de incidentes debe seguirse independientemente de la causa real de la interrupción informada, ya sea que se deba a un problema en su centro de datos interno o con un proveedor de nube o un ISP.

El proceso de gestión de incidentes NO es apropiado para las solicitudes de los usuarios o para el seguimiento de problemas con los sistemas del usuario o la configuración local, está destinado a realizar un seguimiento de los problemas con los sistemas institucionales compartidos. Tampoco es adecuado que los usuarios soliciten cambios o nuevas aplicaciones, se debe implementar un proceso de Solicitudes de Servicio para tal fin.

Meta

El objetivo de la gestión de incidentes es la restauración rápida del servicio o servicios afectados. Según la gravedad y el impacto de la interrupción, puede ser necesario un proceso de gestión de problemas para determinar la causa raíz de uno o una serie de incidentes relacionados, ambos tienen un objetivo relacionado pero distinto.

Pasos

1. Detectar
2. Responder
3. Recuperar
4. Aprender
5. Mejorar

La Calificación de Categoría de cualquier Incidente dado o Incidente potencial se calcula como un factor de la Severidad del Incidente y el Tipo de Impacto que tiene en los Sistemas Afectados . Esta clasificación se utiliza en la Gestión de incidentes (consulte la página 3) para determinar el alcance de la interrupción, así como en la Gestión de cambios2 para determinar el riesgo potencial de las acciones que se están realizando.

El puntaje de impacto del sistema afectado más crítico se usa para determinar la calificación de categoría de incidente , que incluye el plan de acción y comunicación más apropiado para la situación.

Calificación de Categoría de Incidentes y Plan de Comunicación

La Calificación de Puntaje de Impacto determina la Categoría del Incidente y los pasos que deben seguirse para comunicar y registrar adecuadamente el evento:

Tenga en cuenta que estas acciones se proporcionan como un ejemplo, estoy seguro de que tendrá pasos adicionales para incluir.

Gestión del cambio

El proceso de Gestión de cambios debe usar exactamente los mismos pesos de Sistemas afectados y Calificación de categoría de incidente que discutimos anteriormente, la medida de una interrupción en su organización no ha cambiado, la única diferencia es que debemos incluir la probabilidad de que esa interrupción ocurra durante el cambio. Más sobre eso a continuación, primero definamos nuestra terminología.

Alcance

La Gestión de cambios se aplica a todos los cambios realizados en cualquiera de los sistemas de TI de la empresa, en las instalaciones o en la nube.

Meta

El proceso de Gestión de cambios utiliza la misma calificación de impacto que el proceso de Gestión de incidentes . El objetivo de la Gestión del Cambio es evaluar adecuadamente el nivel de riesgo de cualquier cambio realizado en los servicios de la Organización para que se puedan seguir los canales de comunicación y aprobación adecuados. Además, los objetivos también son:

1. Apoyar la implementación oportuna y efectiva de los cambios requeridos por TI
2. Gestionar adecuadamente el riesgo de la Organización
3. Minimizar el impacto negativo de los cambios en/para la Organización
4. Asegúrese de que los cambios logren los resultados comerciales deseados
5. Garantizar que se cumplan las expectativas de gobierno y cumplimiento
   

La Calificación de Categoría de cualquier Incidente dado o Incidente potencial se calcula como un factor de la Severidad del Incidente y el Tipo de Impacto que tiene en los Sistemas Afectados .

Probabilidad

La probabilidad es la probabilidad de que ocurra el peligro y, a menudo, se clasifica en una escala de cinco puntos:

• Seguro - 80 a 100% - Es muy probable que se manifieste un problema durante o después del cambio
• Probable - 60 a 80% - Es probable que ocurra un problema durante o después del cambio
• Posible - 40 a 60% - Un problema puede ocurrir pero lo más probable es que no ocurra durante o después del cambio
• Improbable - 20 a 40% - Existe una posibilidad remota de que ocurra un problema durante o después del cambio
• Raro - 0 a 20% - Es muy poco probable que ocurra un problema durante o después del cambio

El factor de riesgo del cambio propuesto se mide multiplicando la Calificación de Categoría de Incidente más alta posible por la Probabilidad más alta de que ocurra este peligro:
Riesgo = Probabilidad x Gravedad

Al aplicar cambios a los sistemas de la Organización y la infraestructura de apoyo, el equipo de TI evaluará el impacto potencial del cambio en función de la siguiente matriz de evaluación de riesgos:

Cambio de Calificación de Riesgo y Plan de Comunicación

Dependiendo del Factor de Riesgo , así como de la Urgencia del cambio, el equipo de TI seguirá lo siguiente

pasos para informar a los usuarios del cambio: