CL.MP.

05
Gestión de
Incidentes
Procesos Cloud

v5 2024-Ene
 Mapa de Procesos – Delivery Cloud
Procesos BU Cloud
Capturar Oportunidades con el Cliente

Superar las Expectativas del Cliente

P01 Estrategia del Servicio P02 Diseño del Servicio
P.11 P.12 P.08 P.13 P.14
Diseño de Gestión de Gestión de Niveles Gestión de Capacidad Gestión de Continuidad y
Servicios Proveedores de Servicio y Demanda Disponibilidad

P03 Transición de Servicios

P.06 P.10 P.09
P.03 Gestión de Gestión de Activos y
Gestión de Liberación y
Gestión de Cambios Conocimiento Configuración
Despliegue

P04 Operación del Servicio

P.01 P.02 P.04 P.05 P.07
Operación de Servicios Gestión de Gestión de Gestión de Gestión de
Cloud Requerimientos Problemas Incidentes Eventos

P05 Mejora del Servicio

P.15
Gestión de Mejora Continua
Gestión de Incidentes
Prioridad Incidente = Impacto vs Urgencia
Objetivo del proceso: Impacto:
Urgencia: ¿cuánto tiempo se puede postergar la resolución del
Controlar y gestionar un incidente a lo ¿cómo puede afectar problema?
largo de su ciclo de vida, desde el el incidente al negocio
Tipo de
registro, priorización, escalamiento, del cliente? Fatal Critical Warning
Alertamiento
hasta su resolución, con el objetivo
Criticidad del CI desde Urgencia Urgencia 1 Urgencia 2 Urgencia 3
recuperar la disponibilidad y x
una vista de negocio URGENTE NORMAL BAJA
funcionamiento normal de los servicios Impacto

afectados.
1 - Alto Impacto 1 Crítica Alta Media
Productivos ALTO P1 P2 P3

Incidente: 2 - Medio
Productivos No Impacto 2 Alta Media Baja
Es “una interrupción no planificada de MEDIO P2 P3 P4
críticos
un servicio de TI o una reducción de la
calidad de un servicio de TI”. 3 - Bajo Impacto 3 Media Baja Baja
No Productivos BAJO P3 P4 P4
Ciclo de vida del Incidente: v2022-10

REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

 Definiciones de Impacto y Urgencia
Los Incidentes deben ser priorizados y clasificados según el Impacto y Urgencia que estos representen:
Impacto: La criticidad del equipo o sistema desde el punto Urgencia: Se establece a partir del tipo de evento detectado
de vista del negocio se convierte en el nivel de impacto. o incidente reportado.
Impacto del CI desde el Criticidad del Equipo o
punto de vista de Negocio Sistema URGENCIA Urgencia de atención del alertamiento

Impacto 1 Urgencia 1 Umbrales que impliquen indisponibilidad y/o

Alto Productivos Críticos Urgente degradación de servicio y se debe atender de
(Prod. Críticos) (Fatal) inmediato.

Impacto 2 Umbrales que impliquen crecimiento en consumo

Productivos No Críticos / Urgencia 2
Medio (CPU, memoria, disco) y que si no se toma acción
Productivos Contingencia Normal
(Prod. No Crítico) inmediata más adelantar podría generar
(Critical)
afectación.
Impacto 3 Urgencia 3
Bajo Ambientes QA / Dev Umbrales de aviso para tomar acción y evitar
Baja
(Dev QA) degradación y/o afectación.
(Warning)
Es necesario que el negocio (EL CLIENTE) establezca el valor de
criticidad para cada uno de los CIs que son parte del alcance del
servicio.
 2. Flujograma y
Lineamientos del Proceso

Nacimos para reinventar

Flujo a Alto Nivel del proceso
Registro y Validación del Incidente
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito
Asegurar la atención
Solicitante Lineamientos
pertinente de un incidente.
Determinar si es realmente
Responsable de registrar o • El incidente es notificado a través de una alerta de monitoreo o
un incidente y no un falso
solicitar un incidente comunicación directa del Cliente a través de los canales de
positivo (triaje) mediante ticket INC: comunicación con el CECOM.
• Gestor de servicio • El campo ‘Método de reporte’ especifica el canal utilizado para
Roles que participan
(Gerente de Proyecto / reportar el incidente (ver opciones en la cartilla de categorización).
- Gestor de Servicio / Jefe de Proyecto /
especialista / Analista de Proyecto) • El CECOM es responsable de registrar el ticket tipo Incidente y
Coordinador
- Operador Cecom realizar una primera revisión (triaje) para validar la ocurrencia del
• Torres (Jefe de Torre /
Coordinador /
incidente, pudiendo haber tentativa P1.
Entradas Especialista de Torre) • El Coordinador de turno es responsable de validar las atenciones de
Recepción de Incidente
los incidentes que tienen asignados los administradores y/o
especialistas, tomando en cuenta la disponibilidad según los turnos y
Salidas el tipo de especialización que requieren los incidentes, para asegurar
Incidente registrado y una correcta asignación del Incidente.
validado
Categorización
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito Lineamientos
Asegurar una correcta • El CECOM realiza la categorización del ticket incidente según el síntoma percibido de acuerdo a la
categorización del
incidente utilizando el “Cartilla de Categorización de Incidentes y Problemas”.
modelo acordado.
• El administrador/especialista asignado al ticket (N1, N2 y N3) es responsable de validar la categoría
Roles que participan asignada al ticket, asegurando que coincida con la actividad que va a realizar.
- Administrador N1
- Especialista N2 / N3
Cartilla de
Categorización de
Entradas Incidentes y
- Incidente validado Problemas
- Cartilla de Categorización
de Incidentes y
Problemas
• El primer nivel de categorización corresponde al servicio de Administración Tecnológica.
Salidas
• El segundo nivel de categorización distingue los incidentes que afectan a los componentes del
- Nueva solicitud de para
construcción de nuevo
servicio tecnológico (Aseguramiento del Servicio) de los incidentes de afectan la seguridad de la
modelo información (Seguridad Inf).
- Incidente correctamente
categorizado
Priorización
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito Lineamientos
Asegurar una correcta • El CECOM prioriza el incidente de acuerdo a la “Cartilla de Priorización (Impacto x Urgencia)”.
priorización del incidente
según la matriz de Impacto: Determinado por la criticidad del Elemento afectado (CI) desde la visión del negocio.
Impacto por Urgencia. Urgencia: La prontitud requerida para resolver el incidente, también los umbrales superados en los
eventos de monitoreo determinan la urgencia en los incidentes.
• El administrador/especialista asignado al ticket (N1, N2 y N3) es responsable de validar la priorización del
Roles que participan
ticket y actualizar el valor de impacto y/o urgencia de ser necesario (generalmente en un incidente el
- Administrador N1
- Especialista N2 / N3
impacto se mantiene en el tiempo, mientras que la urgencia puede variar, lo cual implica realizar el cambio
de Prioridad).
Cartilla de Priorización
(Impacto x Urgencia)
Entradas
- Incidente categorizado • De identificarse un incidente como prioridad Crítica (Prioridad 1), este pasará a atenderse con el proceso de
- Cartilla de Priorización
Gestión de Incidentes Graves (P1), el registro del ticket Incidente lo realiza el CECOM en la herramienta
(Urgencia x Impacto)
Canvia Cloud Suite: Incident Center, durante el registro se debe asegurar que el elemento afectado (CI) esté
relacionado al ticket Incidente.
• En CCS: Incident Center el CECOM puede priorizar un incidente de prioridad Alta (P2) a prioridad Crítica (P1);
Salidas
de la misma forma, si durante la revisión del incidente P1 los participantes del War-Room comprueban que la
Incidente correctamente
priorizado
alerta no genera impacto crítico, indicarán al CECOM que se debe des-priorizar el incidente P1 a incidente P2.
En ambos casos CECOM registra el motivo del cambio de prioridad en el CCS Incident Center y
automáticamente este motivo se registra en el ticket (véase instructivo CCS: Incident Center).
Diagnóstico
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito Lineamientos
Asegurar el tratamiento
más efectivo e inmediato
• El administrador/especialista asignado al ticket (N1, N2 y N3) al iniciar la revisión del incidente,
para solución del incidente cambia el ticket incidente desde el estado ‘Asignado’ al estado ‘En curso’, con ello finaliza la
asignado a un grupo de medición del tiempo de respuesta del SLA u OLA.
soporte adecuado para
gestionar el evento • Para incidentes P1, CECOM asignará y pasará el ticket en estado ‘En curso’ a la primera Torre que
inicie el troubleshooting en el WarRoom P1.
Roles que participan
- CECOM • El administrador/especialista asignado al ticket (N1, N2 y N3) ejecuta el troubleshooting del
- Administrador N1 incidente.
- Especialista N2 / N3
• El administrador/especialista asignado al ticket (N1, N2 y N3) define los pasos a seguir para
Entradas resolver el incidente y valida que se encuentra dentro del tiempo de resolución del SLA u OLA.
Incidente correctamente
priorizado
• En esta etapa pueden intervenir varias torres en simultáneo (en el War-room de Incidente P1) o
secuencial (escalamiento entre torres).

Salidas • Si el incidente afecta la seguridad de la información, se coloca el check en el campo Incidente

Incidente con diagnóstico Seguridad Informática en la herramienta de tickets.
determinado
Resolución
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito
Lineamientos
Resolver y recuperar la • Se aplica una solución definitiva ante un error conocido o una solución temporal cuando se desconoce la causa raíz. Toda
disponibilidad o actividad técnica para la solución de un incidente debe coordinarse internamente en Delivery (No debe intervenir JP/GP).
funcionamiento normal del
incidente reportado dentro
• El administrador/especialista asignado al ticket que resuelve (N1, N2 y N3) es responsable de detallar en el ticket las
de los niveles de servicio actividades realizadas en la resolución y debe adjuntar en el ticket alguna evidencia que certifique que el incidente ha sido
resuelto y/o superado​.
Roles que participan
• En el caso de un incidente P1, todos los especialistas que intervienen en la solución deben recolectar evidencias y
- Administrador N1 documentar todo lo relacionado al incidente en el ticket P1. Si requieren un ticket independiente para el registro de horas
- Especialista N2 / N3 ocupadas en la solución, registrarán un ticket relacionado de tipo Work Order (WO).
• Para incidentes P1, el Crisis Manager de Turno indicará el responsable de la elaboración del informe técnico P1 de acuerdo
a la atribución del incidente (para clientes de sector privado se entregará un informe P1 si el incidente se define con
Entradas
responsabilidad Canvia, para clientes de sector público, se entregará un informe P1 en todo incidente P1).
Incidente con diagnóstico
determinado • Para incidentes P1, el Crisis Manager de Turno indicará el responsable de la elaboración del informe técnico P1; éste será el
equipo técnico que realice la acción principal y/o necesaria para recuperar el servicio, CECOM generará un ticket
requerimiento (WO) para la elaboración de informe técnico P1 y se asignará al responsable que indique el Crisis Manager,
Salidas pero los demás especialistas que intervinieron deben documentar y adjuntar las evidencias en el informe.
- Incidente con necesidad • El Incident Manager será el primer aprobador del informe de P1; si éste no tiene toda la información será devuelto a la
de escalamiento técnico
torre responsable. Ante una tercera devolución será escalado y devuelto al Jefe de Torre. El Jefe y/o Gerente de Torre será el
- Incidente resuelto
segundo aprobador del informe de P1 antes de enviarlo al Jefe de Proyecto.
 Escalamiento
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito Lineamientos
Garantizar que todos los
incidentes reportados • Cuando se identifica la necesidad de escalamiento por la complejidad de resolución del incidente o para evitar
cumplan los el incumplimiento del tiempo de solución del SLA u OLA, el Coordinador o Administrador, dependiendo el
procedimientos e horario, es responsable de gestionar el escalamiento técnico, reasignando a un especialista de nivel superior
instrucciones de trabajo
aprobados de acuerdo a
(N1  N2  N3) para la atención del incidente.
cada nivel de grupo de
soporte.
Esquema de escalamientos en Incidentes desde CECOM a los equipos técnicos
Roles que participan
HORARIO DE OFICINA + EXTENDIDO* FUERA DE HORARIO DE OFICINA
- Administrador N1
- Especialista N2 / N3 Clientes con alcance
- Coordinador de turno CRITICO Escalamiento a: Incidentes 24*7:
P1 Escalamiento a
• Coordinador (Hasta 6pm**) especialista [LA POSITIVA /
Entradas ALTO • Especialista (Después 6pm**) (Llamada telefónica)
FONAFE / SEDAPAL /
P2 SUNARP / ONPE /
Incidente con necesidad ** Validar c/torre en la OSCE ]
de escalamiento técnico MEDIO Matriz de Escalamiento Cloud
P3
Asignación a bandeja de tickets Llamada 24x7
en sección Horarios y Soporte
del coordinador de torre destino (Todas las
Salidas BAJO
(NO se hace llamada) prioridades)
P4
Incidente escalado
asignado a administrador * Horario de oficina + extendido: Lunes-Viernes 8:30am a 10:00pm y Sábados 8:30am a 1:00pm
de nivel superior
 Cierre del incidente
REGISTRO Y VALIDACIÓN CATEGORIZACIÓN PRIORIZACIÓN DIAGNÓSTICO RESOLUCIÓN ESCALAMIENTO CIERRE

Propósito
Lineamientos
Garantizar que toda la • Para finalizar la atención, el Administrador/Especialista (N1, N2, N3) cambia el ticket al estado ‘Resuelto’,
información de solicitud debiendo documentar las acciones aplicadas como solución en el campo Nota de resolución y seleccionar el
de servicio sea precisa y motivo de estado que corresponda:
esté actualizada antes del
cierre 1 2
Asegurar la gestión con
cliente post atención, en Cuando el incidente ha sido Cuando el cliente ha
caso aplique. causado por una acción o realizado una acción
inacción por parte de CANVIA, si causando la
es de prioridad crítica (P1) se va indisponibilidad o la
a requerir el Informe de Incidente degradación del servicio
Roles que participan
- Operador Cecom
• En incidentes P1 donde se aplicó una solución temporal o la causa raíz es desconocida, el equipo que
- Especialista N2 / N3
conforma el War Room P1 determina si la investigación debe continuar con la gestión de problemas, siendo el
CECOM quién genera el ticket problema a partir del incidente P1.
Entradas
• En incidentes P2, P3 o P4 donde se desconoce la causa raíz, la gestión de problemas se activa a demanda.
Incidente resuelto
• El ticket incidente puede ser reabierto hasta máximo 3 días calendarios desde que pase al estado Resuelto
ante una insatisfacción en la solución, posterior a este plazo, el ticket pasa automáticamente al estado
Salidas
Cerrado, impidiendo realizar cualquier modificación sobre este.
Incidente documentado y
cerrado • Los incidentes registrados con una cuenta personal en el campo ‘Cliente’ ofrecen la opción de calificar la
atención. Esto no aplica para tickets registrados con los clientes genéricos que representan a los proyectos.
 3. Indicadores

Nacimos para reinventar

 OLA Tiempo de Respuesta y Solución Incidentes
Tiempo de Respuesta en la atención de tickets Incidentes mide el tiempo trascurrido desde que el ticket es registrado, hasta que
pasa por primera vez al estado ‘En curso’ (En Proceso). Se excluye el tiempo que el ticket se encuentre en estado 'Pendiente' con
motivo 'Pendiente por cliente'.
OLA Prioridad Tiempo Objetivo Horario
P1 - Crítica 10 min 24 x 7
Tiempo de P2 - Alta 20 min
Respuesta de Lun.-Vie. 08:00am – 10:00pm
P3 - Media 60 min Sáb. 08:00am – 01:00pm
Incidentes (no incluye feriados)
P4 - Baja 180 min

Tiempo de Solución en la atención de tickets Incidentes se mide el tiempo trascurrido desde que el ticket es registrado hasta que se
resuelve. Se excluye el tiempo que el ticket se encuentre en estado 'Pendiente' con motivo 'Pendiente por cliente'.

OLA Prioridad Tiempo Objetivo Horario

P1 - Crítica 2 horas 24 x 7 Nota: Estos
Tiempo de objetivos OLA son
P2 - Alta 4 horas internos para Cloud,
Solución de Lun.-Vie. 08:00am – 10:00pm
P3 - Media 8 horas Sáb. 08:00am – 01:00pm NO SE PRESENTAN
Incidentes (no incluye feriados) en propuestas para
P4 - Baja 16 horas clientes.
 SLA Tiempo de Respuesta de Incidentes
El Tiempo de Respuesta en la atención de tickets Incidentes se mide el tiempo trascurrido desde que el ticket es registrado, pasa
por una asignación de acuerdo a la categoría hasta que pasa por primera vez al estado ‘En curso’ (En Proceso) cuando se inicia el
diagnóstico que busca resolver el incidente.

SLA Cumplimiento Prioridad Tiempo Objetivo Horario

90% * 1-Crítica 15 min 24 x 7

Tiempo de 90% 2-Alta 30 min

Respuesta de Lun.-Vie. 08:00am – 10:00pm
Incidentes 90% 3-Media 90 min Sáb. 08:00am – 01:00pm
(no incluye feriados)
90% 4-Baja 240 min

*Debido a que los incidentes de Prioridad Crítica P1 no tienen una alta volumetría, el indicador se mide con frecuencia trimestral. En caso de
requerida la medición sea mensual para el SLA de Tiempo de Respuesta para los incidentes de Prioridad 1 solo aplicará cuando la volumetría de
incidentes con esta prioridad sea igual o mayor de 4 incidentes P1 dentro del periodo de medición.

Nota: SLA de Tiempo de Respuesta estándar para nuevos clientes Cloud.

 SLA Tiempo de Solución de Incidentes
El Tiempo de Solución en la atención de tickets de Incidentes se mide el tiempo trascurrido desde que el ticket es registrado, pasa
por una asignación, diagnóstico hasta que concluye la recuperación de la disponibilidad del servicio, cuando pasa al estado
‘Resuelto’. La solución de un incidente implica recuperar la disponibilidad del servicio, no incluye el tempo de análisis de causa raíz.

SLA Cumplimiento Prioridad Tiempo Objetivo Horario

90% * 1-Crítica 2.5 horas 24 x 7

Tiempo de 90% 2-Alta 5 horas

Solución de Lun.-Vie. 08:00am – 10:00pm
Incidentes 90% 3-Media 10 horas Sáb. 08:00am – 01:00pm
(no incluye feriados)
90% 4-Baja 20 horas

• Debido a que los incidentes de Prioridad Crítica P1 no tienen una alta volumetría, el indicador se mide con frecuencia trimestral.
• En caso de requerida la medición sea mensual para el SLA de Tiempo de Solución para los incidentes de Prioridad 1 solo aplicará cuando la
volumetría de incidentes con esta prioridad sea igual o mayor de 4 incidentes P1 dentro del periodo de medición.

Nota: SLA de Tiempo de Solución estándar para nuevos clientes Cloud.

Se requiere la aprobación del Delivery Manager para su inclusión en propuestas a clientes.
 Consideraciones para la medición de los SLA
• El tiempo que se excluye de la medición de los niveles de servicio dentro del horario de servicio es el que se presenta cuando la atención
del ticket requiere información adicional o una respuesta elevada a EL CLIENTE el ticket se colocará en el estado Pendiente con el motivo
‘Cliente’ mientras se espere la respuesta, luego cuando se obtenga respuesta, se reanudará la atención del ticket y la medición
correspondiente.
• En caso de que los servicios sean afectados por vicios ocultos, bugs de sistemas, o la solución dependa por un tercero que no sea EL
CLIENTE ni CANVIA, el tiempo de SLA no será contabilizado en contra de CANVIA.
• Serán excluidos los tickets en los que se determine que la razón y/u origen del incidente fue a raíz de una acción de EL CLIENTE o por un
tercero que no sea EL CLIENTE ni CANVIA.
• Serán excluidos los tickets que correspondan a atenciones en equipos o sistemas con soporte en back level (sin soporte por el fabricante o
desarrollador).
• En los tickets que se registran atenciones fuera del alcance del servicio no se consideran para medir el cumplimiento de los niveles de
servicios.
• Serán excluidos los tickets que correspondan a restauraciones de componentes del servicio.
• Las penalidades sólo se aplicarán a CANVIA cuando el incumplimiento se produzca por causas atribuibles exclusivamente a CANVIA. Para
que esto resulte aplicable se requiere de un proceso en donde para cada una de los incumplimientos se elabore un “root-cause análisis” en
el cual se determine cuál fue la razón y/u origen del problema y las conclusiones de este informe deben ser aprobados conjuntamente
entre EL CLIENTE y CANVIA. Sólo en aquellos casos en que el resultado consensuado del informe determine que la causa origen del
incumplimiento no se produjo exclusivamente por causas atribuibles a CANVIA es que se excluyen las penalidades a CANVIA.
 Controles del proceso
Control Comentario
IM01. Cumplimiento
Incidentes atendidos vs SLA/OLA Tiempo de Respuesta cumplido o no
Incidentes SLA y OLA
cumplido
Tiempo de Respuesta
IM02. Cumplimiento
Incidentes atendidos vs SLA/OLA Tiempo de Solución cumplido o no
Incidentes SLA y OLA
cumplido
Tiempo de Solución
IM03. Resueltos por Cantidad o porcentaje de tickets incidentes cerrados por Servicio Afectado
Servicio Afectado (Servicio Afectado: SAP / Base de Datos / Sistemas Operativos / Etc.)

Incidentes sin atender, para identificar el backlog de requerimientos

IM04. Pendientes por
pendientes que se van reduciendo o acumulando por nivel de soporte
Nivel de Soporte
(Grupos resolutores: N1, N2, N3)

Cantidad o porcentaje de tickets Incidentes resueltos o cerrados por nivel

IM05. Resueltos por Nivel
de soporte (Grupos resolutores: N1, N2, N3), para identificar que se logra
de Soporte
alta resolución en el primer nivel
 Controles del proceso (cont.)

Control Comentario

Promedio del tiempo consumido al atender los tickets (solo se mide el tiempo
IM06. Tiempo
en el estado 'En Curso' (En Proceso)) de los tickets (no mide estados
Promedio de Atención
pendientes) por prioridad.

Cantidad y porcentaje de incidentes cerrados o resueltos divido por el motivo

IM07. Tipo de Solución
indicado al resolver ( Responsabilidad CANVIA o Cliente).

IM08. Incidentes por Cantidad y porcentaje de los tickets incidentes por la Prioridad P1 y otras
prioridad prioridades.

Cantidad y porcentaje de incidentes según su Fuente Reportada (Método de

IM09. Fuente Reporte) dividiendo los Incidentes originados por Alertas (Eventos: Azure
Reportada Monitor / Solarwinds/Pandora/Elastic) e Incidentes originados o reportados
por el cliente mediante los Canales (Correo/Teléfono)
 Auditoría a los tickets incidentes
Secuencia de auditorías:
1. Determinar
criterios a evaluar

7. Programar 2. Programar torres

siguiente auditoría a auditar

6. Feedback a la 3. Muestreo de los

torre tickets

4. Evaluación de los
5. Informe de los
tickets
resultados
seleccionados
 4. Estados

Nacimos para reinventar

 Uso Correcto de los Estados en Incidentes
Secuencia de Estados y Niveles de Servicio

Asignado En Curso Pendiente En Curso Resuelto Cerrado

•Ticket con • El ticket se • El • El ticket • El ticket ha • Se cumple el
el encuentra asignatario vuelve a
asignatario sido resuelto y periodo de
en curso ha dejado estar en termina la garantía para
INCIDENTE y está a la siendo de atender atención
espera que revisado atención que el ticket
el ticket por el
el por el asignatario requerida. sea reabierto
por algún
especialista asignatario. motivo del ticket. (3 días
comencé a calendar).
revisar. específico.

Tiempo de Respuesta

Tiempo de Resolución Cancelado

En caso
cliente/solicitante
desestima el
incidente.
 Uso Correcto de los Estados en Incidentes
Estado Pendiente
Al seleccionar el estado “Pendiente” durante la atención de un ticket de incidente, se deberá llenar de forma obligatoria
los campos de “Motivo de estado” y “Justificación de Estado”:

Recuerda:
• Los estados ‘Pendiente’ se usan para indicar que en cierto momento no se está atendiendo
un ticket o que este se encuentra siendo revisado por un tercero o cliente. Este comentario
se incluirá en la nota de justificación de estado pendiente del ticket.
• El único motivo de estado ‘Pendiente’ que pausa la medición de los SLA y OLA es el motivo:
‘Pendiente Cliente’.
 Uso Correcto de los Estados en Incidentes
Estado Cancelado
Al seleccionar el estado “Cancelado” se indica que la atención del incidente ya no es requerida, por lo que se deberá
llenar de forma obligatoria los campos de “Motivo de estado” y “Justificación de Estado”:

El comentario que se incluirá en la nota de justificación de estado cancelado del ticket debe detallar
el motivo de la cancelación y deberá coincidir con el motivo de estado ‘Cancelado’ que sea
seleccionado: si es por motivo de un ticket incidente duplicado (‘Por duplicidad’), porque hubo un
error en el registro o fue un ticket de prueba (‘Falla de registro’), o la cancelación la solicitó el cliente
(‘Por cliente’) o la misma torre (‘Por Torre de Soporte’).
 Uso Correcto de los Estados en Incidentes
Estado Terminado - Cerrado
Al completar la atención del ticket incidente, se debe usar el estado “Terminado” y se deberá llenar el campo ‘Nota de Resolución’ con
el comentario de la solución realizada, en este se mencionan las acciones realizadas y además se debe seleccionar obligatoriamente un
motivo de estado:

• Si la ocurrencia del incidente tiene atribución al cliente, es decir el cliente ha realizado una acción que ha provocado el incidente,
por ejemplo, realizó un pase a producción sin informar a CANVIA, reinició el servidor o tuvo un incidente en un componente fuera
de la administración de CANVIA, en estos casos se debe usar la opción: ‘Responsabilidad Cliente’ en el campo motivo de estado.
• Si la ocurrencia del incidente no es directamente atribuible al cliente, en los demás casos, se considerará como atribuible al servicio
o a CANVIA por ser el proveedor que administra dicha solución o componente afectado. En este caso se deberá usar la opción:
‘Responsabilidad Canvia’ en el campo “Motivo de estado”.
Una vez cambiado al estado ‘Terminado’, el ticket incidente se mantendrá disponible para su reapertura durante los siguientes 3 días
calendarios, luego de esto pasará automáticamente al estado ‘Cerrado’. Si el ticket es un ticket interno (entre torres), se puede
adelantar su transición al estado ‘Cerrado’.
 5. Gestión de Incidentes Graves
P1

Nacimos para reinventar

 Roles

Incident Manager (IM) Crisis Manager (CM)

Asegurar el cumplimiento del Proceso de Incidentes así como Responsable de Gestionar la recuperación y/o
el cumplimiento de los OLAs/SLAs establecidos disponibilización del servicio ante un incidente P1.
 Gestionar/Coordinar a diario el Proceso.  Validar que el incidente sea un P1 (afectación de servicio
crítico).
 Identificar excepciones y/o desviaciones al Proceso para su
revisión y aprobación.  Gestionar las notificaciones internas y alertas de
escalamiento.
 Asegurar que los lineamientos, procedimientos, políticas
asociadas al Proceso sean comunicadas a todos los equipos.  Liderar la sala WAR: Liderar al equipo técnico designado para
 Auditorías Internas para asegurar cumplimiento del Proceso la atención del incidente P1.
 Asegurar cumplimiento del protocolo de incidentes P1
 Definición/Medición de los KPIs del Proceso
(checklist de atención/validación de incidentes).
 Monitorear y comunicar el cumplimiento de los KPIs,
 Tomar decisiones para la recuperación del servicio
 Tomar acción ante tendencias negativas de los KPIs. comprometiendo al equipo de Servicio (GP/JP) cuando sea
 Verificar revisión post de los incidentes P1 (Comité de requerido.
Incidentes P1).  Consolidar un plan de resolución integral
 Asegurar que el personal documente el ticket de registro y lo
resuelva ante resolución del incidente.
 Determinar el responsable de elaboración del informe técnico
de incidente P1.
 Gestión de Crisis (Incidentes P1)
CLIENTE AFECTADO

Interfaz: Gerente / Jefe de Proyectos

Conocimiento de Alcance del Proyecto y Línea Base del Proyecto

Auto-ticketing / CECOM Durante diagnóstico y

Ocurre un incidente de
Inicia registro de ticket Inicio del War-Room Cierre del War-Room
indisponibilidad del resolución del
servicio.
Incidente mediante P1 P1
CCS: Incident Center Incidente P1

CECOM CM / Especialistas CM / Especialistas

Evento CECOM Aplican descartes del Define responsabilidad del
Elemento (CI) con Realiza triaje y Inicia sala War-Room Protocolo de incidente (Canvia/Cliente)
criticidad: 1-Alto primeros descartes en MS Teams Incidente P1
Especialistas
Umbral: Fatal Documentan el ticket
Robot / CECOM Crisis Manager CM / Especialistas
Incidente P1 y cambian a
Ejecuta pasos del estado Resuelto
Cliente Llamar a: Valida la prioridad Troubleshooting
JP -> GP del incidente
Reporta incidente -Síntomas Crisis Manager
CM -> CM Bkp
con alto impacto al -Eliminar variables Define responsable para el
Especialistas de Crisis Manager
negocio -Plantear hipótesis informe de incidente P1
turno
Lidera la sala -Probar hipótesis
CECOM WarRoom CM / Especialistas
Supervisión CECOM Define necesidad de
Informa por creación de ticket problema
WhatsApp CM / Especialistas Informa de manera
Incidentes P1 Define plan de recurrente en
WhatsApp P1 cada 30 Crisis Manager
resolución del
minutos Define responsable para
incidente
JP/GP análisis de ticket problema
(Canvia/Cliente)
Informa al cliente CECOM
Finaliza seguimiento a War
Room (CCS: Incident Center)
 Protocolo de Incidentes P1
En la Matriz de Escalamiento Cloud (ISO.F.10)
https://canvia.sharepoint.com/:x:/s/CloudDelivery/EXGE492GtHtCpGoyNhHmPm4BDK_mrvGkG-WWR1trDwEK4w?e=IaqtSD

La sección Protocolo de Atención P1

amplía las indicaciones de las
acciones que se deben realizar para
la atención de un incidente P1.

Se incluyen también enlaces a

documentos técnicos para hacer
descartes en ciertas plataformas o
sistemas.
 Acciones ante Incidente Prioridad 1 Masivo
1. Considerar como Incidente P1 Masivo: a partir de 2 clientes o más (lo cual incluye a clientes de Proyectos
Cloud y también debe contar a clientes de otras BU con servicios de Cloud), y aplica para los casos de
incidentes donde la afectación sea a los equipos multi-cliente donde se impacten las comunicaciones
(switches, firewall, balanceador), seguridad (ransomware, malware), infraestructura compartida (switches
SAN, storage, chasis o ESXI), condiciones especificas del datacenter (falta de combustible, falla del sistema de
aire acondicionado).
2. Al identificar situación de Incidente Masivo, se debe asegurar que los especialistas a contar en el War-Room
son: NOC, SOC, INFRA, MONITOREO.
3. Al identificar situación de Incidente Masivo el Crisis Manager realiza el escalamiento contacta a los Gerente
de Torre (NOC-SOC-INFRA) / Delivery Manager, cada Gerente de Torre contacta a los Jefe de Torre en su
gestión.
4. CECOM al identificar los proyectos afectados, va contactando a los JP/GP de los proyectos afectados y los
suma al War-Room.
5. El War-Room tiene como prioridad la solución de los incidentes, se debe evitar hacer salas aparte para
resolver el incidente, usar un canal único: el Crisis Manager modera la sesión entre especialistas y JP/GP
priorizando el análisis y solución técnica, y luego las consultas de información.
 Cascada de Escalamiento en Incidente P1 Masivo
Especialista SOC Especialista INFRA
CECOM
Especialista NOC

Cuando se identifica Delivery Manager

Jef. Torre SOC
que el Incidente P1 Ger. Torre SOC
es de impacto Crisis Manager Jef. Torre NOC

Masivo Ger. Torre NOC

Jef. Torre INFRA
CECOM y Crisis Manager Ger. Torre INFRA
escalan llamando a los Grupo JP/GP A
roles indicados, quienes a Gerente Grupo A
su vez escalan llamando Grupo JP/GP B
en cascada al siguiente Gerente Grupo B
grupo de personas CECOM Focal Service Grupo JP/GP C
Gerente Grupo C
Grupo JP/GP D
Gerente Grupo D
 Flujo Informe Técnico P1
GP:
Condiciones: Validación final del
• Se entrega Informe en incidente P1 responsabilidad Canvia
informe técnico antes
(Sector Privado)
• Se entrega Informe en todo incidente P1 (Sector Público)
de la entrega al Cliente.

Crisis Manager: CM Especialistas:

Incident Manager: IM Jefe de Torre: JT Jefe de Proyecto: JP
Se asegura que durante Consolida la bitácora
1er aprobador del 2do aprobador del 3er aprobador del
el War-Room se genere de eventos y reúne
una bitácora de eventos informe técnico P1 informe técnico P1 informe técnico P1
evidencias
** En la Sala WAR se Elaboración Informe:
revalida la torre QA del informe
• Resumen Ejecutivo
owner del informe P1 • Cronología de los completo
Hechos (evidencias)
• 5 Whys Ante demora, riesgo Revisión y Aprobación Revisión y Aprobación
• Planes de Acción incumplimiento OLA del informe del Informe
(Fecha, Responsable) (96 horas), escala con
• Conclusiones
JT/GT
Informe debe tener visión
holística del incidente

Revisión interna con N2/N3 de

la Torre Owner del Informe P1

El informe se publica en la
ruta: Cloud Repository y se
comenta en el ticket INC el
link para al acceso al informe.
96 horas
Formato del anuncio inicial de un incidente crítico en el chat
‘Incidente P1’ en WhatsApp/Teams

El anuncio inicial de un incidente en el

chat ‘Incidente P1’ debe indicar lo siguiente:

• Cliente(s) o proyecto(s) afectado(s) [Obligatorio]….....

• Servicio(s) o servidor(es) afectado(s) [Obligatorio]……
• Número de ticket Incidente [Obligatorio]………………….
• Resumen del ticket (Error o situación identificada)…...
• A quienes se informó (JP/GP/IM) [Obligatorio]………….
• El War Room que se usará [Obligatorio]…………………….

Para abrir el WarRoom se cumple en el incidente es Prioridad 1-Crítico, lo que corresponde a servicios totalmente afectados o a la indisponibilidad del
servicio. No se puede contemplar como P1 un incidente de menor prioridad donde la afectación sea parcial, por ejemplo, una degradación o lentitud
en el funcionamiento de los servicios.
 Lineamientos de uso del chat ‘Incidentes P1’
El chat Incidentes P1 es de uso A partir que el Nivel 1 anuncia el incidente y se determina la sala War Room
exclusivo para escalar incidentes de que se está asignando se deben realizar las comunicaciones relacionadas con
prioridad Crítica P1. dicho incidente dentro del chat del War Room asignado.

Prioridad 1

Prioridad 2

Prioridad 3

Prioridad 4

No se debe usar para escalar incidentes

de otra prioridad, o requerimientos. Esto significa que el intercambio de capturas de diagnóstico, consultas
técnicas no se debe hacer en el chat Incidente P1.
 War Room P1 con MS Teams
War Room 01: https://teams.microsoft.com/l/channel/19%3a760fb2378a1e47e2a5222e72b015843a%40thread.tacv2/War%2520Room%25201-IncP1?groupId=2b4f4c2b-1161-4544-9101-63294283b6a9&tenantId=0faacd36-7680-4441-817a-936a4e0244de
War Room 02: https://teams.microsoft.com/l/channel/19%3a046346eb4fd54268b0b1006c96a23114%40thread.tacv2/War%2520Room%25202-IncP1?groupId=2b4f4c2b-1161-4544-9101-63294283b6a9&tenantId=0faacd36-7680-4441-817a-936a4e0244de

En MS Teams encuentra en la sección: ‘Equipos’ al

grupo ‘Cloud Repository’, dentro de este se podrá Cuando se solicite agregar un
acceder a los War Room 1 y 2. asunto, se debe colocar el
número de ticket

Una vez reportado el Incidente P1, CECOM inicia

el War Room con el botón ‘Reunirse ahora’
Enlaces a documentación del Proceso de Incidentes A.02 Gestión de Incidentes
Curso del Proceso Gestión de Incidentes
https://aprendemos.canvia.com/course/view.php?id=99&sectionid=482
Resumen del (Curso Operación Cloud - Módulo 02)
Proceso CL.MP.05 Gestión de Incidentes https://canvia.sharepoint.com/:b:/s/CloudDelivery/EYwFvydsqRRAt7cysEFqU08BWD2iNGNeO2QdLK3dcjGmUA?e=OT3trz
Video de Presentación del Proceso https://web.microsoftstream.com/video/012e644a-748d-4e06-9d21-51ee764a7bf9?st=1033
CL.P.05 Gestión de Incidentes (Procedimiento
https://canvia.sharepoint.com/:b:/s/CloudDelivery/Ee---hD3S0dOkBqsbUGsUeQBYeK52Pr9ca-KMcKUOdKrYQ?e=3b9lpA
Detallado)
Procedimiento
Detallado ISO.P.18 Manejo de Recuperación de Servicios https://canvia.sharepoint.com/:b:/s/CloudDelivery/EUWNu63H7CVMk3EsfNoUqH4B_NR2Wnnm3_zzs4kkczYOeA?e=yYHe0T
ISO.P.22 Protocolo de Actividades Post
https://canvia.sharepoint.com/:b:/s/CloudDelivery/EamSgfbLI5ZPvqfR_V6RnE4BYiEjyHN-xwojz4oQB2ifxQ?e=neiyfg
Incidentes Críticos P1
AUT.I.06 CCS Uso del Módulo Incident Center https://canvia.sharepoint.com/:b:/s/CloudDelivery/Edz0PhuAbZ5NphrWCYb9Nh0BGpEg-OTiweH3BtIX6-Wnqg?e=ZOImLQ
Instructivos ISO.I.20 Registro y Seguimiento de Incidentes
https://canvia.sharepoint.com/:b:/s/CloudDelivery/EWjTfOYU4mxNmeNP2B10YkMBOS78aTA9hmjpnPIcBv1ZHg?e=HCefmv
de backup de BD archive
Video de Gestión de Incidentes en la
https://web.microsoftstream.com/video/2b30d50c-9e62-4b55-bde4-dcae98d92506
herramienta Remedy
Proceso de Gestión de Crisis (Incidentes P1)
https://canvia.sharepoint.com/:p:/s/CloudDelivery/EXnXx0wBG3ZHtRBDkn2QAOoBo1xhkv1Zt8euyduPzSWpzg?e=PWYhTV
(PDF)
Proceso de Gestión de Crisis (Incidentes P1)
https://canvia.sharepoint.com/:p:/s/CloudDelivery/EVRH2FdWmnFNukEI4xCQlAgBgKHX2RfTi5RYkEup7pGWvw?e=lQpgsK
(Formato PPTX)
Lineamientos para los Crisis Manager (Video
https://canvia.sharepoint.com/:v:/s/CloudDelivery/Ecu3F5QOHntAqtnwW13MkmoBfDqcZ003Dg9fhYEwvGWftA?e=5PvMlD
de Capacitación)
Recursos
Adicionales: Cartilla de Categorización de Incidentes https://canvia.sharepoint.com/:b:/s/CloudDelivery/EQxY7l_kj5dOmJNcY7TqowcBIAh2_adx7K14WFhmjpGvow?e=jdiyeO

Cartilla de Priorización (Impacto x Urgencia) https://canvia.sharepoint.com/:b:/s/CloudDelivery/EQQ5MsWjyGNJmLpdAMT0_2YBjzwHArpRyiZnXilZbsHR6g?e=hwoeK8

Plantilla Informe de Incidentes Graves (P1)
https://canvia.sharepoint.com/:w:/s/CloudDelivery/ESdOIHcAYEBMoeY1h_hCUEEBpGhxwQJHNL5Z_c6Kv_dUjQ?e=fvprST&download=1
(ISO.F.07)
Video de Capacitación en la Elaboración de los
https://web.microsoftstream.com/video/af46c197-8be2-47de-9ad2-86b30976753a
Informes de Incidentes P1
Ruta de Publicación de los Informes de https://canvia.sharepoint.com/:f:/s/CloudDelivery/Eoi3Cen0EWpNslYnDyAOXG0BfL2Moz--RZbLsL9-KM7n_Q?e=ZJRto2
Incidentes Graves (P1)
Encuéntralos también en el índice de la documentación ISO.F.39 Roadmap Inducción en los Procesos de Operación Cloud.xlsx
Gracias
P r o c e s o s C lo u d
[email protected]