Por qué necesitas un plan escrito
Durante un incidente, tu cerebro no funciona a plena capacidad. El estrés reduce tu enfoque. Olvidas pasos. Te saltas la comunicación. Arreglas el síntoma pero no la causa.
Un plan de respuesta a incidentes escrito elimina el pensamiento de los primeros 10 minutos. Sigues una lista de verificación. Sabes qué hacer y en qué orden. El plan maneja el proceso para que tu cerebro pueda encargarse de la depuración.
Esta plantilla está diseñada para equipos pequeños (2-10 personas). Asume que no tienes un equipo SRE dedicado ni una guardia con 15 personas. Asume que la persona que recibe la alerta es también la que arregla el problema.
El plan de respuesta a incidentes
Paso 1: Detectar
Tu herramienta de monitorización te alerta. Recibes una notificación: “Monitor [nombre] caído. 3 fallos consecutivos. HTTP 500.”
No entres en pánico. Tómate 30 segundos para verificar. Comprueba el sitio tú mismo. Revisa tu panel de monitorización por otras alertas. Un solo monitor caído podría ser una falsa alarma. Varios monitores caídos significa un incidente real.
Si usas PingWatchdog, los incidentes se crean automáticamente cuando los monitores caen. Obtienes una cronología de lo que pasó y cuándo. Este es tu punto de partida para la depuración.
Paso 2: Declarar
Si se trata de un incidente real (no una falsa alarma o un evento planificado), decláralo. Informa a tu equipo. Informa a tus usuarios.
Para tu equipo: Publica en tu canal de incidentes designado (Slack, Discord, Teams). Incluye lo que sabes: qué monitores están caídos, cuándo cayeron, qué errores estás viendo. Menciona a cualquiera que pueda necesitar estar involucrado.
Para tus usuarios: Actualiza tu página de estado. Publica una actualización de “Investigando”. No necesitas conocer la causa raíz. Solo necesitas reconocer el problema. “Estamos investigando informes de errores elevados de API. Próxima actualización en 15 minutos.”
Tu página de estado debería actualizarse automáticamente desde tus datos de monitorización. Si un monitor está caído, la página de estado debería mostrarlo. La actualización manual les dice a los usuarios que estás en ello.
Paso 3: Investigar
Empieza con la explicación más simple. ¿Desplegaste recientemente? ¿Cambió una dependencia? ¿Tuvo un incidente un servicio de terceros?
Revisa tus datos de monitorización. ¿Qué errores están reportando las sondas? ¿Conexión rechazada? ¿Fallo de DNS? ¿Timeout? ¿HTTP 500 con un mensaje de error específico? Los datos de la sonda muestran lo que ve el mundo exterior.
Revisa tus logs. Logs de aplicación, logs de base de datos, logs del servidor web. Busca errores que comenzaron aproximadamente al mismo tiempo que el monitor cayó.
Revisa tu infraestructura. ¿Está el servidor arriba? ¿Está la base de datos aceptando conexiones? ¿El uso de memoria o disco está aumentando? ¿La utilización de CPU es anormal?
Paso 4: Mitigar
Una vez que sepas qué está mal, detén la hemorragia. Puede que esta no sea la solución permanente. Está bien. El objetivo es restaurar el servicio primero, luego arreglar la causa raíz.
Mitigaciones comunes:
- Desplegar un rollback: Si un despliegue reciente causó el problema, vuelve a la versión anterior. Despliega la solución después de resolver el incidente.
- Reiniciar un servicio: Los pools de conexiones de base de datos, servidores de caché y colas de mensajes a veces necesitan un reinicio. Reinicia el servicio y monitoriza la recuperación.
- Escalar recursos: Si el problema es agotamiento de recursos (CPU, memoria, conexiones), escala hacia arriba. Puedes reducir después del incidente.
- Conmutación por error: Si un solo servidor o región está afectado, redirige el tráfico a otro lugar.
Paso 5: Comunicar
Durante la mitigación, publica otra actualización de estado. “Problema identificado como agotamiento del pool de conexiones de base de datos. Estamos desplegando una solución.”
Después de desplegar la solución, publica de nuevo. “Solución desplegada. Monitorizando recuperación.”
Después de confirmar la recuperación, publica la actualización final. “Servicio restaurado. Duración del incidente: 23 minutos.”
No dejes pasar más de 30 minutos sin una actualización, incluso si la actualización es “Seguimos investigando. Hemos acotado el problema a la capa de base de datos.” El silencio crea incertidumbre. Las actualizaciones crean confianza.
Paso 6: Resolver
Espera a que tus monitores confirmen la recuperación. No declares el incidente resuelto basándote en una comprobación manual rápida. Deja que las verificaciones automatizadas confirmen que el servicio está estable.
PingWatchdog resuelve incidentes automáticamente cuando los monitores vuelven al estado “arriba” durante un período sostenido. Esto asegura que no cierres un incidente prematuramente.
Paso 7: Post-mortem
Dentro de las 24 horas posteriores al incidente, escribe un breve post-mortem. No necesita ser un documento formal. Un mensaje de Slack o un breve documento funciona. Responde estas preguntas:
- ¿Qué pasó? Describe el incidente en lenguaje sencillo.
- ¿Cuál fue el impacto? ¿Cuánto tiempo estuvieron afectados los servicios? ¿Qué servicios? ¿Cuántos usuarios?
- ¿Cuál fue la causa raíz? ¿Qué desencadenó específicamente el fallo?
- ¿Cómo se detectó? ¿Lo detectó la monitorización? ¿Lo reportó un usuario?
- ¿Cómo se resolvió? ¿Qué pasos se tomaron para arreglarlo?
- ¿Qué evitará que se repita? ¿Qué acciones resultan de esto?
El objetivo del post-mortem no es asignar culpas. Es aprender y mejorar. Cada incidente es una oportunidad para hacer tu sistema más fiable.
Configurando tu kit de herramientas de incidentes
Para ejecutar este plan, necesitas algunas cosas preparadas antes de que ocurra un incidente:
Monitorización: Monitorización de disponibilidad, monitorización SSL y monitorización heartbeat. Necesitas saber de los problemas antes que los usuarios. Configura la monitorización de PingWatchdog.
Alertas: Alertas enrutadas a los canales correctos. Los monitores críticos van a PagerDuty o notificaciones telefónicas. Los no críticos van a Slack. Configura canales de alerta.
Página de estado: Una página de estado pública donde los usuarios pueden comprobar la salud del servicio. Las actualizaciones durante incidentes deben ser rápidas y honestas. Configura una página de estado.
Gestión de incidentes: Incidentes creados automáticamente con cronologías. Cuando comienza un incidente, no deberías tener que crear un ticket manualmente. La herramienta de monitorización debería hacerlo por ti. Más información sobre gestión de incidentes.
Canales de comunicación: Un canal de Slack, sala de Discord o canal de Teams designado para incidentes. Todos saben a dónde ir durante un incidente.
Practica el plan
Haz un simulacro. Elige un servicio no crítico. Tíralo intencionadamente. Sigue el plan. Cronometra cuánto tarda cada paso.
La mayoría de los equipos descubren que la parte más difícil no es la solución técnica. Es la comunicación. “Arreglé el problema en 5 minutos pero pasé 15 minutos averiguando qué decir en la página de estado.” La práctica hace la comunicación más rápida.
Empieza a construir tu plan
La plantilla anterior funciona tal cual. Personaliza los nombres de canales, las rutas de escalado y las referencias a herramientas para tu equipo. Mantenlo breve. Si el plan ocupa más de una página, tu equipo no lo leerá durante un incidente.
Empieza a monitorizar gratis con PingWatchdog. Cada plan incluye gestión de incidentes con creación y resolución automática de incidentes.