Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
1
Proceso de Gestión de Incidentes IT&S
IT-OPs-01
Process Owner
Operaciones IT / Leandro Cinti
Registro de Cambios
Versión Descripción Autor Area Fecha de
creación
Revisado
por
1.0 Proceso de Gestión de
Incidentes IT&S
Paula Sajoux Dirección IT&S 15/1/19 Leandro
Cinti,
Hernan
Chao
Observaciones Leandro Gorriz y
Alejandro Gonzalez
Calderón
Gcia Desarrollo
IT
28/1/19
Aprobación Leandro Cinti Dirección IT&S 6/8/2019
2
Contenido Objetivo ......................................................................................................................................... 3
Alcance .......................................................................................................................................... 3
Situación actual ............................................................................................................................. 3
Pre-Condiciones ........................................................................................................................ 3
Definiciones ................................................................................................................................... 3
Incidente.................................................................................................................................... 3
Gestión de Incidentes .................................................................................................................... 4
Actores / Roles .......................................................................................................................... 4
Flujo de Proceso ........................................................................................................................ 6
Descripción detallada de tareas ................................................................................................ 7
Matriz RACI .............................................................................................................................. 12
Métricas................................................................................................................................... 14
Normativa Asociada .................................................................................................................... 14
ANEXO I ....................................................................................................................................... 15
Prioridad de los Incidentes ...................................................................................................... 15
ANEXO II: ..................................................................................................................................... 17
Template de comunicaciones de incidentes críticos .............................................................. 17
3
Objetivo El presente documento tiene como finalidad detallar el Proceso de Gestión de Incidentes de
Sistemas y Tecnología, cuyo objetivo es restaurar la operación normal del servicio afectado lo
más rápido posible, minimizando el impacto en el negocio y asegurando que se mantengan los
niveles acordados de calidad y disponibilidad.
Alcance Comprende las actividades que están vinculadas al proceso de Gestión de Incidentes de Sistemas
y Tecnología de VUCE.
Situación actual N/A
Pre-Condiciones
Del proceso
• El Proceso de Gestión de Incidentes - Mesa de Ayuda de VUCE derive los casos
técnicos.
• El sistema de monitoreo detecta una alarma que corresponde a un incidente.
Definiciones
Incidente
Se considera incidente a cualquier evento que no es parte de la operación normal de un Servicio
/ Sistema de IT. Se considera incidente, también, a toda Interrupción no planificada o reducción
en la Calidad de un Servicio de TI. Pueden tener impacto en el Servicio / Sistema, aunque el
mismo puede ser leve y resultar transparente para los usuarios (ejemplo: fallo de un Elemento
de Configuración que no ha impactado todavía en el Servicio, el fallo de uno de los discos de un
“mirror”).
Es importante remarcar la diferencia entre los siguientes conceptos:
• Un incidente es “cualquier evento que no es parte de la operación estándar de un
servicio y el cual causa o puede causar una interrupción o reducción en la calidad del
servicio "
4
• Un problema es una condición identificada desde múltiples incidentes exhibiendo
síntomas comunes, o de un incidente individual, con origen en un error individual pero
cuya causa es desconocida.
• Un error conocido es una condición identificada por un diagnóstico de la causa raíz de
un problema y el consiguiente desarrollo de una solución.
Gestión de Incidentes
Actores / Roles
Dueño del Proceso:
- Es el responsable de que se cumpla el proceso, de su diseño, actualización, entrenamiento
del personal.
- Es responsable de garantizar que su proceso se esté realizando de acuerdo con el proceso
acordado, documentado y que se estén cumpliendo los objetivos de la definición del
proceso.
- Responsabilidades:
• Documentar y publicar el proceso.
• Definir las métricas para evaluar la efectividad y eficiencia del proceso.
• Analizar las métricas para ejecutar las acciones correctivas necesarias.
• Responsable del diseño del proceso.
• Mejor la eficiencia y eficacia del proceso y revisar las mejoras propuestas.
• Asegurar el entrenamiento de los que participan en el proceso y que cada uno tenga
conciencia de su rol.
• Asegurar la existencia de revisiones y auditorias regulares del proceso, de sus roles y sus
responsabilidades, y de la documentación correspondiente.
Gestor de Incidentes:
- Es el responsable de la gestión operacional de un proceso.
- Puede ser la misma persona que sea dueño y gestor del proceso.
- Coordina las actividades del proceso.
- Responsabilidades:
• Planificar y coordinar todas las actividades del proceso junto con el dueño.
• Asegurar que las actividades se realizan según se requiera durante el ciclo de vida del
servicio.
• Asignar personal a los roles requeridos.
• Monitorear y reportar la performance el proceso.
• Identificar oportunidades de mejora.
• Implementar las mejoras del proceso.
5
• Definir la prioridad del incidente.
Operaciones IT:
Es el segundo nivel de soporte antes los incidentes técnicos: diagnostica las causas de eventuales
interrupciones en los servicios y el procesamiento o transferencias de información, y ejecuta
mecanismos de corrección (para restaurar el servicio) o escala a las áreas que correspondan.
Responsable de registrar y clasificar los incidentes detectados por monitoreo, y llevar a cabo
esfuerzos inmediatos para restaurar lo antes posible un servicio de TI que ha fallado.
Si no se encuentra una solución adecuada a estos fines, refiere el incidente a grupos de apoyo
técnico especializado (Soporte de Tercer Nivel).
Infraestructura IT
Es el técnico especialista o soporte de segundo nivel capaz de investigar en profundidad un
incidente o requerimiento para entregar una solución al usuario final. Diagnostica fallas de
hardware, conectividad y software de base y brinda soporte en la gestión de problemas con el
proveedor o fabricante que corresponda.
Desarrollo de Sistemas
Es el técnico especialista o soporte de segundo nivel capaz de analizar en profundidad un
incidente o requerimiento para proveer una solución al usuario final. Diagnostica fallas de
software y de configuración de aplicaciones o servicios, y proporciona soporte en la gestión de
problemas con el proveedor.
Contact Center
Es el primer nivel de soporte del usuario, el punto de contacto entre el usuario y VUCE.
Su responsabilidad es registrar y clasificar las llamadas, consultas y pedidos reportados y, de ser
posible, resolver las mismas. Si no lo puede resolver debe derivar al grupo que pueda hacerlo.
Mesa de Ayuda Funcional
Es el soporte funcional y de negocio del sistema VUCE.
Soporte de Cuarto Nivel
Es el soporte del proveedor de hardware o software. Por ejemplo: Arsat (servidores e
infraestructura), Modernización (base de datos, TAD/GDE), AFIP (servicios AFIP) o Aduana
(servicios de SIM).
6
Flujo de Proceso
7
Descripción detallada de tareas
Registro y Tipificación
1. Registra de Incidente
Al identificar una alarma de Monitoreo se registra un incidente en la herramienta de Gestión de
Incidentes con la siguiente categorización o tipificación:
- Origen ticket:
o Evento: cuando Operaciones IT detecta un incidente por medio de una alarma de
monitoreo de Nagios.
o Contact Center: cuando lo genera la Mesa de Ayuda.
- Tipo: Otra consulta o reclamo
- Motivo: Reclamo
- Relacionado con: VUCE (Ventanilla Única de Comercio Exterior)
- Programa/Rubro relacionado: Dificultades técnicas
- Asunto: se completa con la tipificación del incidente según la siguiente lista:
o Indisponibilidad total o parcial del Sistema
o Baja performance/lentitud de algún modulo particular o general del sistema
o Error aplicativo
o Problema de autenticación
Verificación inicial y Priorización
2. Verifica si Falta información
Analiza que el incidente contenga la información necesaria para el análisis y resolución del mismo.
Si le falta información realiza la actividad “Reasigna a nivel 1”, sino continúa con la actividad
"Verifica si es Reclamo o Incidente".
2.1 Reasigna a nivel 1
Reasigna el incidente al Soporte de Nivel 1 (quién lo registró) y se contacta con el Soporte Nivel
1 por mail y/o telefónicamente para avisarle que se requiere más información y que se le derivó
el reclamo. Continúa con el proceso “Gestión de Incidentes - Mesa de Ayuda de VUCE”.
8
3. Verifica si es Reclamo / Incidente
Verifica que el ticket esté catalogado como “Reclamo” en el campo motivo y que el contenido del
mismo corresponda a un incidente.
Si el mismo no es reclamo o incidente deriva el incidente a Soporte VUCE y continúa en el proceso
“Gestión de Mesa de Ayuda de VUCE”.
4. Define Prioridad
Evalúa la información del incidente y analiza los servicios afectados, componentes impactados,
alcance del incidente, como así también su correcta tipificación. La prioridad de cada incidente es
definida por el Gestor de Incidentes de acuerdo a la Urgencia y el Impacto del mismo. De ser
necesario, el Gestor de Incidentes analizará el caso con el senior management de VUCE. En el Anexo
I se encuentra la explicación del cálculo de la prioridad de los incidentes.
5. Actualiza Asunto con “Prioridad”
Actualiza en el incidente el campo Asunto agregando el texto “Prioridad CRITICA”, “Prioridad ALTA”,
“Prioridad Media” o “Prioridad BAJA”, según corresponda, al inicio del mismo (antes de la
tipificación del incidente).
6. Si la Prioridad es crítica
6.1. Comunica apertura del Incidente Crítico
Los incidentes de prioridad críticos son comunicados por correo a los directores, gerentes, Mesa
de Ayuda y Soporte de VUCE según el template del Anexo II.
Además se envía mensaje al celular de los directores y gerentes de VUCE informando la apertura
del incidente crítico.
9
Investigación y Diagnóstico
7. Evalua/Analiza Incidente
El analista de incidentes dispara el proceso técnico de resolución con las áreas involucradas.
Para encaminar el diagnóstico, debe determinar, en una primera instancia, si el incidente se
ocasiona por problemas en la infraestructura de IT o en la aplicación.
Para esta definición, utiliza como base la siguiente información:
- Descripción del usuario afectado en relación a los servicios que podrían estar fallando.
- Herramientas de monitoreo disponibles para chequear si hay algún impacto en la
infraestructura o en los servicios aplicativos.
- Errores conocidos que hayan sido registrados previamente.
8. Si es un incidente de infraestructura: toma alguna de las siguientes acciones según
corresponda:
• Si es de ARSAT: Abre ticket en ARSAT
• Si es PAEC, TAD, GDE o Servicio VUCE-TAD: Abre Ticket en Jira Modernización.
8.1. Actualiza el campo solución con el Nro. de Ticket gestionado: actualiza en el campo
solución del incidente con el ticket generado en ARSAT o en Modernización.
8.2. Actualiza estado a “Espera respuesta”: actualiza el estado del incidente a “Espera
respuesta”.
8.3. Recibe ticket resuelto: ARSAT o modernización avisan que el incidente fue resuelto.
Continúa con la actividad “Se pudo resolver el incidente”.
9. Busca la solución en base de Conocimientos VUCE
El analista de incidentes verifica en la Base de Conocimientos si existe una solución Error Conocido
para el incidente reportado.
De no contar con una solución en la Base de Conocimiento, busca si hay un Workaround. De existir
el workarround continúa con la actividad “Requiere gestionar Cambio” dentro de la fase de
Resolución de Incidentes.
Si existe solución definida en la Base de Conocimiento, se analizará si la misma es aplicable para la
resolución del incidente, en cuyo caso continúa con la actividad “Requiere gestionar Cambio” dentro
de la fase Resolución de Incidentes.
Si no existiera solución ni workaround, continúa con la actividad "Verifica si es Desarrollo".
10
9.1. Verifica si es Desarrollo
9.1.1. Analiza el incidente: evalúa la información del incidente y se analizan los servicios
afectados, componentes impactados, alcance del incidente, como así también su
correcta tipificación. Analiza sus posibles causas y acciones realizadas hasta el
momento, para determinar un diagnóstico.
9.1.2. Registra ticket en Jira VUCE: registra el ticket para la resolución por parte del
proveedor.
9.1.3. Requiere activar Soporte Proveedor: analiza si se requiere activar el soporte. Si no
requiere Activar Soporte continua con la actividad “Elabora solución”.
9.1.3.1. Actualiza estado a “Espera respuesta”: actualiza el estado en el incidente.
9.1.4. Elabora solución: elabora la solución con el detalle de los pasos a realizar para
remediar el inconveniente.
9.2. Si es Infraestructura
9.2.1. Analiza el incidente: evalúa la información del incidente y se analizan los servicios
afectados, componentes impactados, alcance del incidente, como así también su
correcta tipificación. Analiza sus posibles causas y acciones realizadas hasta el
momento, para determinar un diagnóstico.
9.2.2. Requiere activar Soporte Proveedor: analiza si se requiere activar el soporte
9.2.2.1. Activa Soporte Proveedor: se comunica con el soporte quien analiza el
incidente. De ser necesario, el soporte actualiza el mismo.
9.2.3. Elabora solución: elabora la solución con el detalle de los pasos a realizar para
solucionar el inconveniente.
Resolución y Recuperación
10. Requiere Gestionar Cambio
Si requiere gestionar cambios continúa con el “Proceso de Gestión de Implementación de Cambios
IT&S”.
10.1. Implementa la solución
Se aplican las acciones de solución del incidente y de recuperación del servicio impactado, y se
valida que las mismas sean efectivas.
11
11. Pudo resolver el incidente
Valida si se pudo resolver el incidente luego de la implementación de la solución.
Si el incidente no fue resuelto vuelve a la actividad “Evalua/Analiza Incidente”, sino continúa con la
siguiente actividad.
11.1. Si el incidente es crítico “Comunica cierre de Incidente Crítico”: comunica el cierre del
incidente por mensaje a los directores y gerentes de VUCE y, además, por correo a los
directores, gerentes, Mesa de Ayuda y Soporte de VUCE según el template del Anexo II.
11.2. Documenta la solución y cambia estado a “Solucionado”
Documenta la solución en el Incidente y cambia el estado del mismo a “Solucionado”.
Cierre:
12. Requiere confirmación Mesa de Ayuda
Si el incidente se generó desde la Mesa de Ayuda, la misma debe verificar con el usuario la resolución
del incidente.
12.1. Reasigna a nivel 1
Reasigna el incidente al usuario que se lo derivó de la Mesa de Ayuda, contacta al usuario de
Mesa de Ayuda por teléfono y/o por mail para avisarle que requiere la conformidad del usuario
y que le deriva el incidente. Continúa con el proceso “Gestión de Incidentes - Mesa de Ayuda de
VUCE”.
13. Cierra el incidente
Se realizan las actividades necesarias para el cierre del incidente.
12
Matriz RACI
En esta matriz se asignan los roles que un recurso debe ejecutar, para cada actividad dada.
A continuación se describe la representación de cada una de las letras asignadas.
R - Responsible (responsable de la ejecución)
Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe
normalmente un rol ITIL responsable de su ejecución.
A - Accountable (responsable del proceso en conjunto)
Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un
proceso y que recibe las informaciones de los responsables de la ejecución del proceso.
Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y para
cada proceso existe un Responsable de Proceso.
C - Consulted (consultado)
Alguien que no está implicado directamente en la ejecución de un proceso pero que brinda algún
tipo de input para el proceso y/o al cual se pide su consejo y opinión.
I - Informed (a informar)
Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del
proceso.
13
Ges
tor
de
Inci
den
tes
Op
erac
ion
es I
T
Infr
aes
tru
ctu
ra
IT
Des
arro
llo d
e
Sist
ema
s
Mes
a d
e A
yud
a
Sop
ort
e V
UC
E
Man
agm
ent
VU
CE
Registra incidente Información de Incidente Completa Incidente registrado I R R
Reasigna a nivel 1 Incidente con información faltante Información del incidente verificada R C I
Verifica si es Reclamo o Incidente Información de Incidente Información del incidente verificada R C I
Define Prioridad Información de Incidente CompletaInformación de Incidente Completa
Prioridad definidaR C
Actualiza Asunto con la Prioridad Información de Incidente Completa Incidente completo con Prioridad R
Comunica Apertura Incidente CRITICOInformación de Incidente Crítico
Completo
Comunicación de Apertura Incidente
CRITICOR I I I I
A
Evalua / Analiza Incidente Incidente registrado Incidente analizado R C C
Verifica si es Infraestructura Incidente analizado Incidente analizado R
Abre ticket en ARSAT Incidente analizadoIncidente analizado
Ticket de ARSATR C
Abre Ticket en Jira Modernización Incidente analizadoIncidente analizado
Ticket de Jira ModernizaciónR C
Actualiza en el campo solución con el Nro. de Ticket
gestionado
Incidente analizado
Ticket de Jira Modernización o ticket
de ARSAT
Incidente actualizado R
Actualiza estado a “Espera respuesta” Incidente actualizado Incidente con estado actualizado R
Recibe ticket resuelto de ARSAT o ModernizaciónTicket de ARSAT o Jira de
Modernización resuelto.Incidente actualizado R
Busca Solución en Base de Conocimiento Incidente analizado
Solución existente en Base de
Conocimiento o workaround.
Solución NO existente en Base de
Conocimiento.
R
Verifica si es Desarrollo Incidente analizado Incidente verificado R
Analiza el Incidente Incidente completo Incidente Analizado C R R
Activa Soporte Incidente analizado Incidente con soporte activado I R
Registra ticket en Jira para Everis Incidente analizado Incidente registrado en Jira Everis I RActualiza en el campo solución del Incidente el Nro.
de Ticket gestionado
Incidente analizado
Ticket en Jira Everest registradoIncidente actualizado I R R
Actualiza el estado a “Espera respuesta” Incidente analizadoIncidente actualizado con estado en
esperaI R R
Elabora Solución Incidente analizado
Solución elaborada a implementar (se
invoca a subproceso "Resolución de
Incidentes")
I R R
Implementa solución Solución a implementar que no
requiere Cambios Acciones de Solución implementadas R IC IC
Valida Incidente ResueltoCambios/Requerimientos
Gestionados Implementados
Acciones de Solución implementadas
Incidente resuelto validado R IC IC C C
Comunica cierre incidente Crítico Incidente resuelto validado Cierre incidente Crítico comunicado I R I I I
Documenta la solución y cambia estado a Solucionado Incidente resuelto validado Registro de Incidente actualizado R C C
Requiere confirmación Mesa de Ayuda Solución de incidente documentada
Solución confirmada con el usuario
Efectiva
Solución confirmada con el usuario NO
Efectiva
IC R
Cierra Incidente
Solución de incidente documentada
Solución confirmada con el usuario
(desde el Proceso Gestión de Mesa
de Ayuda de VUCE)
Incidente Cerrado I R
TAREAS Entradas Salidas
ROLES Y RESPONSABILIDADES
14
Métricas
La siguiente lista muestra los Indicadores Clave de Rendimiento (KPI / key performance indicators)
que deben considerarse para monitorear el desempeño de la Gestión de Incidentes.
KPIs:
➢ Porcentaje de cumplimiento de SLAs
➢ Incidentes pendientes de resolución
➢ Porcentaje de incidentes resueltos dentro de los SLAs por grupo de resolución
➢ Cantidad y porcentaje de incidentes resueltos sin ser derivados a otros grupos de resolución
➢ Cantidad de incidentes registrados por rangos horarios
➢ Porcentaje de incidentes críticos
Reportes:
➢ Disponibilidad del servicio (discriminando entre cortes programados y no programados)
➢ Top 10 de incidentes por categoría
➢ Cantidad de incidentes cerrados y no confirmados por el Usuario
➢ Informe de cierre de incidentes críticos
Normativa Asociada N/A
15
ANEXO I
Prioridad de los Incidentes
La prioridad de los incidentes se define en base a la Urgencia y el Impacto.
En la siguiente tabla se establece la prioridad del incidente en función de la urgencia y el impacto.
En la tabla hay cuatro niveles de prioridad, la prioridad 1 es la más crítica del negocio.
Prioridad de un
Incidente
IMPACTO
Alto Medio Bajo
URGENCIA
Alta Crítica Alta Media
Media Alta Media Bajo
Baja Media Bajo Bajo
El impacto indica el efecto de un incidente sin resolver en el negocio.
La urgencia se relaciona con la disponibilidad, y mide cuánto tiempo pasará antes de que el incidente
tenga un impacto significativo en el negocio, es decir, cuánto tiempo se puede tolerar el incidente
sin resolver.
La prioridad se utiliza para determinar el orden en que los incidentes deben ser abordados.
En caso de que múltiples incidentes tengan la misma prioridad, se debe considerar en primera
instancia la urgencia y luego el impacto, para identificar la secuencia de trabajo a realizar.
16
Definición de impacto
El impacto se debe evaluar como alto, medio o bajo según los siguientes criterios:
IMPACTO Características
ALTO Impacto mayor en los usuarios. Requiere de una gran cantidad de recursos para su resolución o de
la participación de especialistas de distintas áreas.
Existen servicios críticos, de aplicación o infraestructura, con indisponibilidad total. El impacto en el
negocio es severo.
Compromisos críticos del negocio no se pueden cumplir (ejemplo, no se puede oficializar una
destinación aduanera).
MEDIO Requiere recursos significativos para su resolución, pero podrían existir alternativas de resolución.
Existe una funcionalidad crítica degradada o con lenta respuesta que impacta en el usuario, pero no
hay indisponibilidad total. En ciertos casos, debido al horario del suceso su impacto es moderado.
BAJO Su resolución es sencilla y no requiere de gran cantidad de recursos o especialidad técnica.
Sucede sobre un componente no crítico para el usuario o existe una alternativa disponible.
Definición de urgencia
Para evaluar la urgencia se deberán tomar en cuenta los siguientes parámetros:
URGENCIA Características
ALTA Son incidentes que deben ser atendidos inmediatamente, en un plazo máximo de 15 minutos
desde que fueron reportados, ya que afectan seriamente la disponibilidad de un servicio crítico.
Es necesario actuar en la resolución de forma rápida.
MEDIA Son incidentes que requieren ser atendidos lo antes posible, en un plazo máximo de una hora
desde que son reportados. Se corre el riesgo de impactar más fuertemente al usuario si no se
toman acciones.
BAJA Son incidentes que pueden esperar un tiempo razonable por su solución y ser atendidos en más
de una hora desde que fueron reportados, en tanto, no se ponga en riesgo la disponibilidad del
servicio al usuario.
Nota: los tiempos establecidos para clasificar la urgencia son a modo de referencia y el oferente deberá ajustar
sus tiempos para asegurar el cumplimiento de los SLA´s mensuales.
17
ANEXO II:
Template de comunicaciones de incidentes críticos
APERTURA INCIDENTE PRIORIDAD CRITICA
Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción
Se ha abierto un incidente crítico en la plataforma de VUCE.
Servicio/sistema impactado: SERVICIO YYYY
Cantidad/tipo de usuarios afectados: NNNN
AVANCE O SEGUIMIENTO INCIDENTE PRIORIDAD CRITICA
Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción
Avance del incidente de VUCE: XXXXXXXXXXXX → indicar las novedades del mismo
Servicio/sistema impactado: SERVICIO YYYY
Cantidad/tipo de usuarios afectados: NNNN
CIERRE DEL INCIDENTE PRIORIDAD CRITICA
Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción
Cierre del incidente de VUCE
Servicio/sistema impactado: SERVICIO YYYY
Cantidad/tipo de usuarios afectados: NNNN