Un playbook de una sola persona que puedes ejecutar en 60 minutos

Cuando gestionas un SaaS tú solo, una caída no solo rompe el producto. Rompe tu día. Los clientes escriben, los dashboards parpadean en rojo y cada minuto que pasas adivinando es un minuto en el que la confianza se erosiona. La solución no es una sesión heroica de depuración. Es una secuencia corta y por escrito de movimientos que puedes seguir aunque tu cerebro funcione a base de cafeína y adrenalina.

Esta es una guía fundamentada de 60 minutos para fundadores solos y equipos muy pequeños. Asume que no tienes guardia rotativa, sala de guerra ni centro de operaciones de seguridad. Asume que tienes un portátil, una página de estado que puedes editar y aproximadamente una hora.

El objetivo es simple: cortar la hemorragia, contar a los clientes qué está pasando y dejarte un registro limpio de qué arreglar la semana siguiente.

Qué significa “respuesta a incidentes” en un SaaS unipersonal

La investigación es coherente. La respuesta a incidentes es un proceso estructurado para identificar, contener y recuperar sistemas tras una disrupción, con el objetivo explícito de limitar daño y tiempo de inactividad. Los marcos que la respaldan — la preparación, detección y análisis, contención/erradicación/recuperación y actividad posterior al incidente del NIST, o la versión en seis pasos del SANS — se diseñaron para equipos grandes, pero la forma también funciona para una sola persona.

Para un fundador único, la disciplina se reduce a cuatro trabajos en el orden correcto:

  • Detectar a tiempo para enterarte de la caída antes que tu bandeja de entrada.
  • Estabilizar el sistema para que los usuarios puedan hacer lo más importante, aunque algunas funciones fallen.
  • Comunicar con honestidad, dos veces: cuando lo notas y cuando tienes más información.
  • Registrar por escrito qué ocurrió, para que la próxima caída empiece desde una lista más corta.

Si te saltas cualquiera de ellos, la incidencia cuesta más: en confianza, en tickets de soporte y en la fuga silenciosa que sigue a una semana mala.

Pre-juego: qué dejar preparado antes de necesitarlo

Una respuesta de 60 minutos solo es posible si la parte aburrida ya está hecha. Dedica un fin de semana a estas cinco cosas para que, cuando algo se rompa, no estés construyendo el avión en vuelo.

1. Una página de estado editable desde el móvil

Elige una página de estado hospedada (la mayoría de herramientas de gestión de incidentes incluyen una, y también hay servicios independientes). La característica innegociable es que puedas publicar un aviso desde el navegador del teléfono, no solo desde el escritorio. Practica una vez publicando una incidencia falsa. La primera vez que pruebes el editor no debería ser durante una caída real.

2. Alertas que te despierten por lo importante

Configura tu herramienta de monitorización — chequeos de uptime, seguimiento de errores, alertas basadas en logs — para que te avisen por síntomas visibles para el usuario, no por trivialidades de infraestructura. “La API devuelve 500 en la ruta de login” es una alerta que pita. “Disco al 78 % en un volumen de logs” es un correo para el lunes. El MTTD (tiempo medio de detección) es la métrica que más importa en un equipo unipersonal porque el resto de relojes empieza aquí.

3. Una carpeta de runbooks con tres documentos

Guarda tres archivos cortos en texto plano en un sitio donde puedas encontrarlos bajo presión:

  • Mapa de arquitectura: dónde vive la app, dónde vive la base de datos, qué está en caché, qué habla con qué.
  • Acceso a credenciales: cómo llegar a la base de datos, al panel del hosting, al proveedor de DNS, al procesador de pagos y al servicio de correo. Guarda los secretos en un gestor de contraseñas, pero documenta el camino.
  • Lista de contactos: a quién escribirías o llamarías si necesitaras ayuda — un amigo desarrollador, el canal de soporte del hosting, un colaborador. Incluso una lista de uno es mejor que una lista vacía.

4. Una copia de seguridad que realmente hayas restaurado

Las copias de seguridad que nunca has probado son deseos. Al menos una vez, restaura una instantánea de la base de datos en un entorno de pruebas y confirma que los datos son reales. Documenta los pasos. Una restauración ensayada lleva minutos; una que no, lleva horas.

5. Una plantilla de comunicación medio escrita

Escribe ya las dos primeras frases de tres plantillas:

  • “Estamos investigando un problema que afecta a…”
  • “Hemos identificado la causa y estamos trabajando en una solución…”
  • “El problema está resuelto. Esto es lo que ocurrió…”

Rellenar huecos es más rápido que escribir desde cero con la bandeja de entrada ardiendo.

Los primeros 15 minutos: detectar y estabilizar

El primer cuarto de hora consiste en cortar la hemorragia. No intentes arreglar nada todavía. Arreglar bajo presión, sin diagnóstico, es como un error se convierte en tres.

Minutos 0–5: Reconoce y avísate. Cuando salte una alerta, haz estas tres cosas en este orden:

  1. Publica una nota breve de “investigando” en la página de estado. Incluso “estamos mirando informes de errores” basta.
  2. Abre la carpeta de runbooks y el panel correspondiente.
  3. Anota la hora. El reloj de MTTD acaba de empezar.

Minutos 5–10: Confirma que es real. Un número sorprendente de alertas son ruido. Comprueba dos señales independientes antes de comprometerte: la tasa de errores en tu herramienta de seguimiento y un informe real de un usuario desde el correo o el chat de soporte. Si solo una señal se activa, obsérvala cinco minutos más antes de tomártela en serio mentalmente.

Minutos 10–15: Contener, no curar. Contener significa reducir el radio del daño, no reconstruir el sistema. Opciones, aproximadamente de menor a mayor coste:

  • Revertir el último despliegue si la caída empezó tras un release.
  • Conmutar a una base de datos de respaldo o una réplica de lectura si la principal es la sospechosa.
  • Activar un feature flag para desactivar la ruta rota y que el resto del producto siga funcionando.
  • Estrangular o bloquear el tráfico problemático en el borde si ves abuso o un bucle descontrolado.

Elige el movimiento más pequeño que restaure el flujo principal — normalmente el login y un camino crítico de cobro. Una app degradada que los clientes aún pueden usar es una incidencia sobrevivible. Una app totalmente a oscuras es un evento de fuga de usuarios.

Minutos 15–35: comunicar y profundizar

Una vez que la hemorragia se ha frenado, divide tu atención entre dos tareas.

Comunica otra vez. Actualiza la página de estado con un mensaje corto y específico:

  • Qué se ha roto en términos de usuario (“los logins fallan para algunos usuarios”), no en jerga técnica.
  • Qué estás haciendo al respecto.
  • Cuándo publicarás la próxima actualización (comprométete a una ventana, como “antes de que cambie la hora”).

Si tienes clientes de pago visiblemente afectados, manda un correo breve. Si la caída toca algo regulado — datos de pago, datos de salud, usuarios en la UE — ten en cuenta que pueden empezar a correr plazos legales y de notificación de brechas; consulta la norma correspondiente en lugar de improvisar.

Diagnostica en paralelo. Ahora mira logs, métricas y cambios recientes. Las fuentes del dossier insisten en que el punto de la detección y el análisis es entender qué ocurre antes de empezar a cambiar cosas. Preguntas útiles:

  • ¿Qué cambió en las últimas 24 horas — despliegues, configuración, DNS, certificados, APIs de terceros?
  • ¿La base de datos está sana, o ves esperas por bloqueos, retraso de réplica o avalanchas de conexiones?
  • ¿Hay una dependencia caída — tu procesador de pagos, el proveedor de correo o una API crítica?

Muchas caídas de fundadores únicos no son errores nuevos. Son certificados caducados, un cambio silencioso en una API de un proveedor o una base de datos que por fin ha agotado un recurso que llevaba meses pidiendo prestado. Busca primero la causa aburrida.

Minutos 35–55: arreglar y verificar

Aplica el cambio más pequeño que aborde la causa diagnosticada. Después, verifica desde fuera — no desde tu sesión iniciada. Algunos hábitos que dan buen resultado:

  • Usa una ventana privada o un segundo dispositivo para probar el flujo real del usuario.
  • Observa la tasa de errores y la latencia p95 durante diez minutos, no diez segundos.
  • Comprueba directamente la cuenta del usuario afectado si puedes hacerlo de forma segura y dejando rastro.

Si el arreglo no se mantiene, no sigas tocando. Vuelve al último estado conocido como bueno y replantéate. Una reversión limpia que puedas explicar es más creíble que cinco parches frenéticos a medias.

Minutos 55–60: declarar y documentar

Cuando la tasa de errores vuelva a la línea base y un puñado de usuarios confirme que todo se ve bien:

  1. Publica la actualización de “resuelto” en la página de estado con un resumen de una frase.
  2. Envía un correo corto a quien haya reportado el problema.
  3. Abre un documento nuevo — tu postmortem — y anota la cronología mientras esté fresca. Cinco viñetas y unas marcas de tiempo bastan por ahora. Lo refinarás mañana.

Cierra la incidencia en el sistema que uses. El reloj de MTTR se detiene aquí.

El postmortem: una plantilla pequeña que evita la próxima caída

Un postmortem no es una disculpa ni un documento para repartir culpas. Es un registro breve que convierte una mala hora en una hora futura más barata. La meta es identificar la causa raíz y los cambios que impedirán que se repita la misma incidencia.

Un postmortem útil para un fundador único cabe en una página:

  • Resumen. Dos frases: qué se rompió y a quién afectó.
  • Cronología. Marcas de tiempo para detección, primera comunicación, contención, arreglo y resolución.
  • Causa raíz. Una frase sobre el mecanismo real, no el síntoma. “La API de login devolvía 500 porque la tabla de sesiones alcanzó el techo de clave primaria tras una migración larga” supera a “el login estaba caído”.
  • Qué salió bien. Las partes de la respuesta que funcionaron — la alerta, la reversión, el aviso en la página de estado. No las omitas.
  • Qué salió mal. Los huecos que costaron tiempo — la alerta que faltaba, el panel confuso, el runbook desactualizado.
  • Acciones con responsable y fecha. Como máximo tres. Cada una debe ser lo bastante pequeña para enviarse en una semana. Si una acción llevaría un trimestre, divídela o descártala.

Una prueba útil: ¿un tú futuro, leyendo esto en frío un domingo por la noche, sabría exactamente qué cambiar y cómo verificarlo? Si no, el postmortem no está terminado.

Equilibrios y alcance: qué dejar fuera a escala unipersonal

Después de que baje la adrenalina, sentirás la tentación de añadir un programa de incidentes de empresa. Resístela. Para un fundador único, el perímetro realista es:

  • Adopta ya: página de estado, monitorización básica de uptime y errores, copia de seguridad probada, tres documentos de runbook y hábito de postmortem.
  • Aplaza hasta tener equipo: guardia rotativa formal, cobertura 24/7, herramientas de seguridad dedicadas y ejercicios de simulación. Son valiosos, pero dan retorno cuando tienes al menos dos respondedores y revenue real en juego.
  • Nunca te saltes: la comunicación honesta con el cliente y el postmortem. No cuestan nada y se acumulan.

Una forma útil de pensarlo: cada euro en herramientas de incidentes debería acortar el MTTD o el MTTR para tus modos de fallo reales. Si una herramienta no hace eso, es estantería.

Preguntas frecuentes

¿Cuánto debería llevar escribir un postmortem? Para un equipo unipersonal, treinta minutos al día siguiente es suficiente. La meta es un registro útil, no un documento para un auditor.

¿Realmente necesito una página de estado para un SaaS diminuto? Sí, en parte porque te compra tiempo. Publicar “investigando” permite que un cliente preocupado deje de escribirte mientras tú resuelves el problema real. La página de estado también es una herramienta de comunicación clave durante el arreglo.

¿Qué pasa si no encuentro la causa raíz en una hora? Es normal. Estabiliza, comunica y documenta lo que sabes. Marca la causa raíz como “en investigación” en el postmortem y programa un seguimiento. No todas las incidencias obtienen una respuesta limpia en una sola sesión.

¿Debo escribir a todos los clientes después de una caída? Con una lista pequeña, un correo breve tiene mucho retorno. Con una lista grande, la página de estado suele bastar y el correo se reserva para clientes de pago visiblemente afectados. Evita enviar una disculpa que no puedas respaldar con un cambio concreto.

Fuentes