Los primeros 30 minutos tras una caída: el plan que se escribe de antemano

Cuando cae un servicio importante, la falla técnica es solo la mitad del problema. La segunda mitad se desarrolla entre las personas, y suele costar más.

Sin decisiones tomadas con antelación, los primeros treinta minutos se parecen en cualquier empresa. El responsable pregunta cada dos minutos al director técnico qué está pasando —y este dedica a las respuestas el tiempo que podría dedicar a la recuperación. Marketing sigue dirigiendo tráfico pagado a un sitio que no funciona. Soporte guarda silencio porque no sabe qué decir, y los clientes se enteran por las redes sociales antes que por la empresa. Los ingenieros en el chat discuten de quién fue el commit culpable en lugar de revertir el despliegue.

Todo esto son pérdidas evitables. Un protocolo de respuesta cuesta muchísimo menos que un sitio de respaldo, y en el momento de la incidencia ahorra un tiempo comparable.

Cuatro decisiones que se toman con antelación

1. Quién dirige y quién repara — son personas distintas

Durante una incidencia, el responsable técnico debe ocuparse del sistema, no de los informes de progreso. Por eso se introduce la función de coordinador de incidentes: puede ser el jefe de proyecto, el team lead o la persona de guardia —no importa el cargo, sino que esté designada de antemano.

El coordinador hace tres cosas: reúne a las personas necesarias, lleva la cronología de los eventos y protege a los ingenieros de preguntas externas. Todas las consultas de estado pasan por él, y él publica las actualizaciones con el ritmo acordado —por ejemplo, cada quince minutos, aunque no haya nada que decir. Un “trabajando, sin cambios” regular reduce más de la mitad de las preguntas entrantes.

La cronología de eventos no es burocracia. En dos días nadie recordará en qué momento se reinició el servicio y cuándo exactamente volvieron las métricas, y sin eso el análisis de la incidencia se convierte en un intercambio de impresiones.

2. Qué y cuándo decimos a los clientes

La decisión sobre en qué umbral la empresa informa públicamente de un problema se toma por adelantado y no se discute durante la incidencia. Por ejemplo: fallo de una función crítica más de diez minutos —publicamos un comunicado.

Son útiles frases preparadas: qué exactamente falla, qué ya se está haciendo, cuándo será la siguiente actualización. No prometas un tiempo de recuperación si no estás seguro —una promesa incumplida irrita más que la propia incidencia. Promete el tiempo del siguiente mensaje; eso lo controlas tú.

Por separado: la página de estado debe estar alojada fuera de su infraestructura. Una página que cae junto con el producto es inútil justo cuando se necesita.

Un mensaje honesto y puntual reduce notablemente la carga de soporte y el número de reclamaciones airadas —no porque los clientes se vuelvan más tolerantes, sino porque interpretan el silencio como indiferencia.

3. Dónde están los accesos y las instrucciones de emergencia

Un callejón clásico: el servidor de autenticación no está disponible, la contraseña del sitio de respaldo se guarda en el mensajero corporativo, y el mensajero está desplegado en la misma infraestructura.

De ello se desprenden varias exigencias simples. Las instrucciones de recuperación y las credenciales de emergencia se almacenan independientemente de la infraestructura principal y son accesibles incluso sin ella. El equipo tiene un canal de comunicación de reserva —un mensajero externo habitual sobre el que se acordó antes, no elegido en el momento de la incidencia. El segundo factor para cuentas críticas no depende de una sola persona que pueda estar en un avión.

Esto se verifica con una sola pregunta: si ahora todo se apaga a la vez, ¿desde qué dispositivo y siguiendo qué instrucción empieza a actuar la persona de guardia?

4. Revertir es más importante que arreglar

El error más frecuente durante una incidencia es buscar la causa y arreglarla en el sistema productivo en funcionamiento. Así, una caída que podría durar diez minutos se alarga a varias horas.

El protocolo debe decirlo de forma tajante: si la falla ocurrió después del despliegue y la causa no se encuentra en diez minutos —revertimos a la versión anterior y lo investigamos después. La decisión la toma el coordinador, no el autor de los cambios: al autor le resulta psicológicamente difícil revertir su propio trabajo, casi siempre pide “cinco minutos más”.

Aquí hay una aclaración importante que a menudo se olvida: el revert no siempre es posible. Si el release incluyó un cambio irreversible en la estructura de datos, no se puede volver atrás, y eso hay que saberlo por adelantado, no descubrirlo durante el proceso. De ahí una exigencia práctica para el desarrollo: los cambios en la estructura de la base deben ser compatibles con la versión anterior del código. Así el revert siempre seguirá siendo posible, y es una de las inversiones más baratas en resiliencia que existen.

Análisis sin búsqueda de culpables

La última parte del plan trata de lo que ocurre después de la recuperación, y determina cómo actuará el equipo la próxima vez.

Si por cada incidencia alguien pierde la prima, los empleados empiezan a ocultar errores. En vez de un “he aplicado una migración incorrecta, hay que revertir” inmediato, la persona intenta arreglarlo a escondidas durante tres horas —y cuando los demás se enteran, la magnitud del problema es mucho mayor que la original.

El análisis sin búsqueda de culpables no es debilidad, es cálculo. Su sentido es desplazar la pregunta: no “quién se equivocó”, sino “qué en nuestros procesos permitió que la acción de una persona detuviera el negocio”. La respuesta casi siempre está fuera del empleado concreto: no hubo revisión antes del despliegue, no hubo límites de permisos, no hubo posibilidad de revertir, el cambio se desplegó un viernes por la noche.

Un indicador práctico de cultura sana es el tiempo transcurrido entre que un ingeniero se da cuenta de su error y el momento en que el equipo se entera. Si son minutos —el proceso funciona. Si son horas —la gente tiene miedo, y ninguna técnica lo compensa.

Cómo se ve en papel

Un reglamento de cuarenta páginas nadie lo abrirá durante una incidencia. Funciona un documento de una página, accesible sin la infraestructura principal:

• Quién es el coordinador del incidente y quién le sustituye.
• Umbral en el que se declara el incidente.
• Canal de comunicación de reserva.
• Dónde están los accesos de emergencia.
• Regla de revert y quién toma la decisión.
• Quién y con qué plantilla informa a los clientes.
• Dónde se escribe la cronología.

Y lo principal —este documento debe haberse probado al menos una vez en ejercicios. Como con las copias de seguridad, un plan no probado es una suposición, no un plan: backup que nadie ha restaurado.

Si necesita redactar ese reglamento para su equipo y probarlo en la práctica —escriba.