Política de gestión de incidentes del cliente

​​ Propósito

Cloudflare cree que la apertura y la transparencia son intrínsecas a la prestación de nuestro servicio, y busca ganar la confianza de nuestros clientes y de la comunidad de Internet en general.  Cloudflare opera una red global que impacta las vidas y la prosperidad de cientos de millones de personas y, por lo tanto, somos extremadamente conscientes de esa responsabilidad.

Este procedimiento operativo estándar (SOP) define cómo Cloudflare trata todos los incidentes y problemas que afectan su entorno de producción y las formas en que Cloudflare comunica la naturaleza y el impacto de estos incidentes a los clientes del Enterprise Plan, tanto planificados como no planificados, independientemente de la gravedad.  Este procedimiento especifica cómo se siguen de manera uniforme estos esfuerzos para

• maximizar el tiempo de actividad del entorno,
• minimizar el impacto en el cliente,
• reducir el tiempo de reparación y
• compartir información con nuestros clientes y la comunidad de Internet.

​​ Alcance

Este SOP se aplica a los clientes de Cloudflare y a los servicios al cliente que consumen los clientes. El SOP es aplicable a todos los entornos de producción de clientes en Cloudflare, incluidos:

• sitio web público de Cloudflare www.cloudflare.com Open external link )
• las API de Cloudflare (interfaces de programación de aplicaciones)
• interfaces salientes de terceros (por ejemplo, autorizaciones de tarjetas de crédito, etc.)
• infraestructura de red que es propiedad o es administrada por Cloudflare para servicios de producción
• software, hardware y servicios del proveedor que afectan cualquier parte de la producción de Cloudflare

​​ Información

Cloudflare quiere construir un mejor Internet. Para ofrecer una experiencia mejorada a millones de usuarios de Internet, las operaciones internas de Cloudflare deben seguir procesos y procedimientos de entrega de servicios excelentes.  Por lo tanto, los procedimientos de Cloudflare siguen muchas de las prácticas recomendadas estándar de la industria, algunas de las cuales siguen específicamente los patrones de la Tecnología de infraestructura de la biblioteca de información (ITIL).  Este SOP sigue las prácticas recomendadas de la metodología de gestión de problemas de ITIL.

​​ Definiciones

Categorías de términos clave del incidente:  Todos los eventos son condiciones que pueden provocar alertas; algunas alertas son incidentes notables (y otras no); todos los incidentes se deben evaluar (a veces a través de la automatización, a veces a través de la interacción humana); algunos incidentes son problemas; algunos subconjuntos de problemas son “importantes” e instigan actualizaciones de la página de estado; algunos incidentes importantes tienen una alta prioridad (P1), que requiere que se cree un Informe de incidentes.

Terminología

​​ Funciones y responsabilidades

​​ Las siguientes funciones y responsabilidades están asociadas con la gestión de incidentes dentro de Cloudflare: 

​​ Procedimiento operativo estándar

Esta sección detalla los procedimientos para la gestión de incidentes y problemas.  A alto nivel, estos procesos se relacionan de la siguiente manera:

• Gestión de incidentes:  El proceso general para observar y responder a alertas, que incluye: evaluar el impacto potencial y la gravedad de un incidente, clasificar el incidente como un problema, asignar una prioridad al problema o descartar el incidente como un evento sin impacto si no se puede identificar una condición problemática.

• Gestión de problemas:  Es el proceso de identificar el alcance y la extensión de un Problema, asignar un nivel de gravedad apropiado (P0, P1, P2, P3), las acciones para resolver el Problema y restaurar el estado óptimo para los servicios de producción y la comunicación del problema a las partes correspondientes.

• Gestión de resolución:  Es el proceso de investigar las causas y condiciones que conducen a una condición problemática, informar sobre la forma general en que se gestionó y resolvió un problema, y cualquier análisis posterior de cómo las condiciones y causas de un problema se pueden prevenir en el futuro.

El objetivo principal de la gestión de incidentes es identificar y reaccionar ante posibles problemas lo más rápido posible, y así minimizar el impacto en los servicios de producción y proporcionar los mejores niveles posibles de calidad y disponibilidad del servicio.  Los mejores niveles posibles de calidad y disponibilidad del servicio implicaría que todos los servicios operaran exactamente como fueron diseñados el 100 % del tiempo, y que estuvieran disponibles y accesibles el 100 % del tiempo.

Debido a que aceptamos que una combinación de fuerzas dentro de nuestro control, y fuerzas más allá de nuestro control, eventualmente impactarán la condición del servicio, definimos los Objetivos de nivel de servicio (SLO) y los Acuerdos de nivel de servicio (SLA) para describir qué degradaciones en la condición del servicio son aceptables para diversos servicios dentro de la red de Cloudflare.   Los SLA y SLO se expresan como porcentajes de períodos de tiempo (mensualmente y anualmente).

El nivel de información sobre un incidente puede variar, pero se debe recopilar la siguiente información antes de clasificar y priorizar un incidente:

• Fuente del remitente (alerta de monitoreo o fuente alternativa)
• Clientes (si corresponde)
• Sistema o aplicación (y nombre de host, si corresponde)
• Tiempo de alerta
• Alcance del impacto: número estimado de sistemas, usuarios o regiones afectados
• Tipo de impacto: alcance general del deterioro del servicio (por ejemplo, pérdida de acceso total, funcionamiento degradado, aplicaciones dependientes afectadas, impacto observado en el cliente)

Todos los incidentes que se clasifiquen como problemas, independientemente de la fuente, que tengan una prioridad de P0 o P1, se registrarán dentro del sistema de emisión de tickets Cloudflare, JIRA.  Algunas alertas indicarán condiciones que pueden no tener un impacto inmediato en los niveles de servicio y, según sea necesario, se clasificarán como Problemas con una prioridad P2 o P3.  

El sistema JIRA es el sistema de registro de toda la información del incidente y todas las demás fuentes de documentación sobre un problema (por ejemplo, historial de alertas, capturas de pantalla, registros de trabajo, conversaciones de chat) se adjuntan al ticket original de JIRA creado en respuesta a un incidente.

​​ Clasificaciones de incidentes

Después de reconocer una alerta, SRE inmediatamente clasifica la alerta correlacionándola con una categoría y un nivel de prioridad.  Al crear nuevos tickets JIRA para problemas de alta prioridad (P0 y P1), SRE se asegurará de que cada ticket se clasifique correctamente al incluir su Categoría y Prioridad.  

​​ Nivel de prioridad

Todos los tickets se clasificarán de acuerdo con los siguientes 4 niveles de prioridad.  Los criterios enumerados son directrices generales.   Las condiciones descritas a continuación deberían definir explícitamente un nivel de prioridad; sin embargo, a discreción de la administración de SRE o Cloudflare, a los Problemas se les puede asignar un mayor nivel de prioridad, según sea necesario.

​​

Categoría

Para un seguimiento y comunicaciones adecuados, los problemas de alta prioridad (P0 y P1) se asignarán a las categorías. Estas categorías (etiquetas de tickets) corresponden a las categorías comunicadas públicamente que se enumeran en la Página de estado pública de Cloudflare. 

Los tickets de menor prioridad (P2 y P3) se pueden clasificar mediante etiquetas y nomenclatura que son específicas de varios equipos de ingeniería y no ingeniería dentro de Cloudflare.  Estas etiquetas y categorías diversas no se incluyen en este documento. 

​​ Incidentes de seguridad

Es fundamental entender que los incidentes que se clasifican en la categoría de Seguridad requieren un manejo y procedimientos especiales.  Estos incidentes se deben registrar aquí y luego seguir los procedimientos de Incidentes de seguridad definidos por el equipo de Cloudflare de Información seguridad.

​​ Gravedad alta/incidentes prioritarios

Los incidentes P0 y P1 obviamente tienen un mayor impacto en el negocio y, por lo tanto, tienen algunos requisitos iniciales especiales para asegurar que se manejen de la manera más rápida posible.

​​ Gestor de incidentes

Para todos los problemas P0 y P1, se debe contactar al Gestor de incidentes en servicio de inmediato.  Se publicará un cronograma de gestores de incidentes para garantizar que el SRE sepa a quién contactar en un momento dado.  El gestor de incidentes es un recurso crítico responsable de lo siguiente:

• Validación de la gravedad de un problema
• Seguimiento del problema desde la presentación hasta la resolución
• Representación del mejor interés de los clientes.
• Registro de todas las acciones y tiempos.
• Dirección del personal hacia la resolución más rápida posible
• Asegurarse de que los clientes y la administración interna sean notificados del estado de acuerdo con períodos de tiempo predeterminados (o al cambiar el estado)
• Realizar escalamientos de clientes, internos o de terceros cuando se exceden los límites de tiempo o no se realiza el progreso adecuado
• Asegurarse que se aplique una explicación significativa al ticket después de la resolución
• Asegurarse de que el remitente inicial acepte que el problema se resolvió antes de que se cierre el ticket 

​​ Comunicaciones de incidentes

Las comunicaciones externas durante un incidente son críticas para:

• Notificar a las partes interesadas que Cloudflare conoce el problema y está buscando una solución
• Asegurar a los clientes que el asunto está bajo revisión y que Cloudflare está buscando sus mejores intereses.
• Los problemas no se prolongan innecesariamente y se hacen las escalaciones adecuadas
• Informar a las partes interesadas internas clave de incidentes importantes

Los principales tipos de comunicaciones durante un incidente incluyen:

Un miembro del equipo de CSUP de turno creará la página de estado con plantillas tan pronto como se identifique un incidente.

​​ Revisiones de post mortem

Cloudflare cree ninguno de los problemas críticos deberían repetirse de nuevo.  Con ese fin, todos los problemas P0 instigarán la publicación de un Informe de incidentes (IR), que incluye un Análisis de causa raíz (RCA) del problema y los factores generales que conducen al Incidente. A todas las publicaciones de IR las seguirá una reunión post mortem, una reunión en la que los ingenieros y gestores revisan y acuerdan los detalles del IR, las conclusiones del RCA y cualquier paso de remediación de seguimiento que se tomará para garantizar que las condiciones del problema no se repitan.

​​ Gestión de problemas y post mortem

La gestión de problemas difiere de la Gestión de incidentes en que su objetivo principal es la detección de las causas subyacentes de un incidente, así como su posterior resolución y prevención.

​​

Análisis de causa raíz y remediación

​​ Ticket del problema

Un RCA es un informe de análisis de causa raíz.  Un ticket Jira de un problema es el registro y el seguimiento de eventos que pueden justificar un RCA.  Este es un proceso mediante el cual los expertos en la materia (SME) de un área revisarán un problema P0 o P1 en busca de la causa subyacente del problema.  Una vez que esto se determina, los SME deben crear un plan de remediación para abordar las causas.  La entrega final es un ticket bien documentado para rastrear la remediación hasta su finalización y, si es necesario, un informe de incidentes bien redactado que se enviará a un equipo interno y/o cliente.

Los puntos anteriores siguen siendo aplicables, incluso si se trata de un proveedor externo o proveedor que suministra el RCA.  Cuando la información de RCA se recibe de un tercero, debemos asegurarnos de que el ticket del problema se actualice con toda la información relevante, incluyendo las correcciones pendientes que se deben rastrear.  

​​ Informe IR

El Informe de incidentes (“IR”) es el método principal de comunicación al cliente sobre un problema y puede contener algunas o todas las partes de lo que está escrito en el ticket.  

La persona que escribe el informe variará según la gravedad del problema y el área responsable.  Una vez completado el borrador del informe, es fundamental asegurarse de que el informe sea revisado por la administración de Cloudflare en cuanto a contenido, compromisos y presentación profesional.  Una vez que se aprueba el informe, se puede publicar para el cliente.

​​ Revisión del problema

Las secciones anteriores han detallado el manejo del incidente y el proceso de la causa raíz para asegurar una solución permanente.  La última parte del proceso de gestión de incidentes y problemas es asegurar que las métricas, tendencias e informes clave se lleven a cabo para garantizar que se siga el proceso correctamente, que se cumpla con los SLA y que no se pasen por alto los problemas subyacentes.

​​ Elaboración de informes

Los criterios de ticket que deben informarse tanto para tickets abiertos como cerrados incluyen los siguientes:

• Gravedad
• Categoría/subcategoría
• Grupo responsable
• Edad/días en que estuvieron abiertos

Siempre que sea posible, estos datos se deben informar gráficamente para mostrar tendencias visibles.  Estos informes se deben publicar para los gestores internos de Cloudflare y los propietarios de área.

​​ Análisis y responsabilidad

Cada propietario de área para tickets será responsable no solo de asegurarse de que sus tickets se cierren dentro de los plazos prescritos o razonables, sino también de revisar los informes y buscar tendencias, inquietudes y problemas recurrentes.  Con base en este análisis, se deben abrir más tickets de problemas para remediar cualquier problema que no haya surgido a través de un P0 o P1.  Esto permitirá una mejora continua y, en última instancia, reducirá el conteo de nuevos tickets al abordar las causas raíz.

​​ Reuniones de revisión de gestión de incidentes (post mortem)

Como parte de todas las reuniones del personal departamental, los gestores de grupo deben revisar los informes abiertos y de tendencias con los siguientes objetivos:

• Discusión de áreas de éxito o preocupación.
• Revisión de oportunidades de mejora por parte de los propietarios del área.
• Acuerdo sobre áreas que justifican que se abra un nuevo ticket de problema para el seguimiento de remediación