¿Qué es la comunicación de incidencias?

¿Qué es la comunicación de incidencias?

La comunicación de incidencias consiste en contar a las personas afectadas por una caída qué está pasando mientras aún está pasando: qué falla, a quién afecta, qué estás haciendo y cuándo recibirán la siguiente noticia. Es distinta de la respuesta a incidencias, el trabajo técnico de detectar, contener y arreglar el problema. La respuesta restaura el servicio; la comunicación atiende a todos los que esperan.

Ambas corren en paralelo y compiten por la misma atención, y por eso la comunicación suele quedarse atrás. Un equipo metido en una conmutación de base de datos no tiene ganas de redactar una actualización, y justo entonces es cuando los clientes más la quieren.

El ciclo de una actualización

La mayoría de los equipos usan cuatro etiquetas estándar que los lectores ya conocen:

1. Investigando (Investigating): algo falla y se está buscando la causa.
2. Identificado (Identified): se conoce la causa y la corrección está en marcha.
3. Monitorizando (Monitoring): la corrección está aplicada y se vigila que se mantenga.
4. Resuelto (Resolved): el servicio vuelve a funcionar con normalidad.

Cada actualización se añade a la misma incidencia en lugar de publicarse como una nueva, para que después se pueda seguir todo en orden.

Un ejemplo

Investigando, 14:05 UTC: "Algunos clientes no pueden iniciar sesión. Lo estamos investigando. Próxima actualización antes de las 14:30 UTC."
Identificado, 14:22 UTC: "Un nodo de base de datos defectuoso provoca los errores de inicio de sesión. Estamos cambiando a una réplica. Próxima actualización antes de las 14:45 UTC."
Monitorizando, 14:41 UTC: "El inicio de sesión funciona de nuevo. Vigilamos las tasas de error."
Resuelto, 15:10 UTC: "Las tasas de error han vuelto a la normalidad. Publicaremos un análisis posterior."

Qué hace útil una actualización

• Describe el impacto en términos del cliente. "No se puede iniciar sesión" es mejor que "auth-service devuelve 500".
• Di lo que sabes y lo que no. "Aún no conocemos la causa" es una actualización legítima y mejor que el silencio.
• Compromete la hora de la próxima actualización, no la de la solución. Tú decides cuándo vuelves a escribir, rara vez cuándo llega el arreglo.
• Publica la primera actualización pronto. Una nota breve a los diez minutos vale más que una detallada a los noventa.
• Evita culpar y evita quitar importancia. Ambas cosas cuestan confianza, en direcciones opuestas.

Errores habituales

• Alojar la página de estado en el sistema que está caído. Debe estar en una infraestructura aparte para sobrevivir a la caída.
• Callarse cuando el arreglo está "casi listo". Mantén el ritmo de actualizaciones hasta llegar a Resuelto.
• Contar historias distintas en sitios distintos. Publica un solo texto y replícalo por correo, chat y redes.
• Borrar el registro después. Un historial público de incidencias pasadas es parte de lo que da credibilidad a una página de estado.
• Depender de que alguien se acuerde. Si una persona tiene que acordarse de publicar, llega tarde. Vincula la primera actualización a tus alertas de monitorización.

Dónde se publican las actualizaciones

Lo habitual es una página de estado. Las suscripciones por correo envían las actualizaciones a quien le interesan sin obligarle a vigilar la página. El trabajo planificado sigue el mismo patrón con aviso previo, véase el mantenimiento programado. Los compromisos contractuales de disponibilidad se tratan en la gestión de SLA. Tras una incidencia importante suele venir un análisis posterior (postmortem), con otro público y otro propósito que las actualizaciones en directo.

Cómo ayuda LoadFocus

Las páginas de estado de LoadFocus asocian componentes a tus monitores. Según la página del producto, al activar las incidencias automáticas un monitor que falla abre la incidencia en la página por sí mismo y los suscriptores reciben aviso cuando se abre y de nuevo cuando se cierra. Las incidencias llevan una gravedad (minor, major, critical) y pasan por investigating, identified, monitoring y resolved, y después se puede publicar un postmortem. Las suscripciones por correo usan doble confirmación, el plan gratuito incluye 1 página, 10 componentes y 250 suscriptores, y las actualizaciones también pueden ir a Slack o a un webhook. Los dominios propios y las páginas privadas requieren un plan de pago. Para la monitorización que lo alimenta, consulta la monitorización de API; más sobre la práctica en buenas prácticas de monitorización para DevOps y desarrolladores.

Preguntas frecuentes: comunicación de incidencias

¿En qué se diferencia de la respuesta a incidencias?

La respuesta es el trabajo técnico de encontrar y arreglar el problema. La comunicación mantiene informadas a las personas afectadas mientras ese trabajo ocurre. Van a la vez y suelen necesitar personas distintas.

¿Cada cuánto debo publicar actualizaciones durante una incidencia?

Indica en cada mensaje la hora de la siguiente actualización y cúmplela, aunque solo diga que no hay cambios. Importa más un ritmo fiable que el detalle.

¿Qué debe decir la primera actualización?

Que conoces el problema, qué ven los clientes y cuándo llegará la siguiente actualización. Todavía no necesitas la causa.

¿Dónde debe alojarse la página de estado?

Separada del servicio que describe, para que cargue aunque tus propios sistemas estén caídos.

¿Debo publicar un postmortem?

En incidencias importantes ayuda. Describe qué pasó, el impacto, la causa y qué cambia ahora. Se escribe después del suceso para un público más amplio que el de las actualizaciones en directo.