El plan de continuidad que nadie ha ensayado es un documento, no un plan

Hay una palabra escondida en el informe anual de caídas de Uptime Institute que cambia cómo hay que leer la parte de error humano. Al explicar qué provoca las caídas con error humano detrás, el informe de este año dice que la primera causa sigue siendo «failures to follow established procedures». Established. Establecidos. Es decir: el procedimiento estaba escrito, aprobado y guardado en alguna parte. Y no se siguió.

Eso descarta la respuesta cómoda. Si el problema fuera que falta documentación, se arregla escribiendo documentación, y escribir documentación es una tarea que se puede asignar un jueves por la tarde. Pero el informe no dice que falten procedimientos: dice que los que hay no se ejecutan cuando toca. Y un procedimiento que nadie ha ejecutado nunca no es un procedimiento. Es una hipótesis con formato de documento. Aviso ya, para no colar el titular por la puerta de atrás: eso es nuestra lectura y no la conclusión del informe, que sigue poniendo la energía como primera causa de las caídas con impacto. Al matiz completo llegamos en dos minutos.

Los números, y lo que no dicen

El informe es el Annual outage analysis 2026 de Uptime Institute, publicado en mayo de 2026 y firmado por Douglas Donnellan, Andy Lawrence y Rose Weinschenk. Estos son los tres datos que nos parecen los importantes, con su tamaño de muestra al lado porque hace falta para leerlos bien:

Ahora la parte incómoda, que preferimos poner antes de construir nada encima. Esas muestras son pequeñas: noventa y ocho, ciento noventa y nueve, doscientas veinte respuestas de operadores de centro de datos. Son autodeclaradas y retrospectivas, y una persona que mira hacia atrás su propia caída tiene todos los incentivos del mundo para verla evitable: sabe cómo acabó. Ese 87% mide cuántos operadores creen que su caída era evitable, que es una cosa distinta de cuántas lo eran.

Y hay más matices que juegan en contra del titular fácil. Uptime dice explícitamente que no cuenta el error humano como causa raíz, sino como factor contribuyente, y explica por qué: una caída por una actualización mal configurada puede venir de un defecto del software, de un cambio incorrecto o de unas pruebas que no se hicieron, y separar esas tres cosas después es casi imposible. La causa que sigue liderando las caídas con impacto de verdad, en su encuesta, es la energía: UPS, conmutadores de transferencia y generadores. No los procedimientos.

Dicho todo eso, la tesis se sostiene igual, y es nuestra lectura y no un dato del informe: si en la lista de motivos de error humano el primero es saltarse un procedimiento que ya existía, entonces lo que falta no está en el documento. Está en que nadie lo ha hecho nunca con el reloj corriendo.

Por qué se salta un procedimiento que existe

Casi nunca es por dejadez. Cuando nos toca entrar a ordenar un incidente ajeno, lo que aparece es siempre alguna variante de lo mismo: el procedimiento decía algo que ya no era verdad.

Ninguno de esos cuatro fallos se detecta leyendo. Se detectan ejecutando. Es lo mismo que ya contamos cuando escribimos que tu documentación de infraestructura te miente, con la diferencia de que allí hablábamos de inventario y aquí de instrucciones. Un inventario desactualizado te hace perder una hora. Un procedimiento desactualizado te la hace perder el día del incidente, que es el único día en el que el tiempo cuesta dinero.

El coste, en el idioma del comité

El mismo informe pone precio a la conversación. Más de la mitad de los encuestados, el 57%, dice que su última caída importante costó más de 100.000 dólares. Y por segundo año consecutivo, uno de cada cinco pasa del millón. Uptime lo atribuye menos a que haya más fallos y más a que cada vez más servicios dependen, directa o indirectamente, de un solo centro de datos o de una sola zona de disponibilidad.

Hay un segundo dato que a nosotros nos preocupa más que el dinero: la duración. La mayoría de las caídas públicas se resuelve en menos de doce horas (el 55%), pero la proporción de las que pasan de 48 horas ha crecido por segundo año consecutivo. Uptime lo relaciona en parte con los cortes de fibra y de cable submarino, que en 2025 se dieron a más del doble de su media histórica y que tardan más porque hay que ir físicamente a repararlos y coordinar a varias partes. Es exactamente el argumento por el que insistimos en que la redundancia contractual no es diversidad de ruta física: dos operadores en la misma zanja son un solo operador el día de la excavadora.

Y para traducirlo al único formato que entiende un comité, la aritmética de la disponibilidad no admite discusión. Un 99% de disponibilidad son 87,6 horas al año a oscuras: más de dos semanas laborales. Un 99,9% son 8,76 horas. Un 99,99%, 52,6 minutos. Cada nueve extra no se compra con suerte; se compra con arquitectura y con procedimiento. Si aún no has puesto números a esto, la parte aburrida y necesaria está en RTO y RPO sin humo.

Un martes a las diez, no un sábado a las tres

La conclusión operativa es incómoda pero simple: hay que apagar algo a propósito, con gente delante, en horario de oficina. Los hyperscalers llevan años haciéndolo y le pusieron nombre —chaos engineering, el Chaos Monkey de Netflix—, pero la versión de una pyme no es un bicho automático que mata máquinas al azar. Es una cita en el calendario, una vez por trimestre, y una lista de lo que se rompe.

Así lo hacemos nosotros, y así lo montamos para clientes:

Nuestro último simulacro de recuperación completa terminó en 14 minutos. Lo decimos con la advertencia puesta: es un dato interno nuestro, sobre nuestra infraestructura y nuestro procedimiento, y no es una garantía contractual ni es tu número. Sirve para una sola cosa, que es la que importa: es un número que existe porque alguien apagó algo y miró el reloj. El tuyo, mientras no lo midas, se queda en desconocido, y desconocido es la categoría peligrosa: no lo puedes prometer, no lo puedes presupuestar y no sabes si te cabe en la jornada.

Cuándo NO deberías hacer un simulacro

Aquí es donde nos separamos de la versión de folleto de esta idea. Sin unas condiciones previas, apagar algo a propósito es jugarse una caída de verdad para escribir un informe bonito. Son cuatro, y si te falta una, el simulacro no es tu siguiente paso.

Y una advertencia más, porque nos la hemos encontrado: el simulacro no sustituye a la gobernanza del cambio. Que sepas recuperarte de una caída no reduce la probabilidad de provocarla el próximo viernes con un cambio sin revisar. Son dos trabajos distintos: entorno de pruebas parecido al de producción, despliegue por partes y alguien que revisa antes de tocar. El estudio clásico que puso números al peso del error humano en los grandes servicios de internet es de hace más de veinte años —Oppenheimer, Ganapathi y Patterson, USENIX 2003— y ya entonces situaba el hardware en la cola de la lista. El informe de Uptime no dice lo mismo con los mismos datos, pero apunta en la misma dirección.

Las tres preguntas que lo revelan en cinco minutos

No hace falta una auditoría para saber por dónde vas. Estas tres preguntas, hechas en voz alta en una reunión de dirección, dan el diagnóstico completo por la cara que pone la gente:

Si las tres respuestas empiezan por «pues debería» o por «lo tenemos documentado», ya sabes en qué grupo estás. Nada de esto es reproche: la mayoría de las empresas con las que trabajamos llegaron a nosotros justo ahí, y llegar ahí es lo normal cuando el negocio crece más rápido que la infraestructura. Lo que no es normal es quedarse.

El fallo es inevitable; la avería es una decisión

Un disco se rompe: eso es un fallo, y ocurrirá. Que por ese disco la web deje de vender, el almacén no saque pedidos y los comerciales miren una pantalla congelada: eso es una avería, y eso se decidió antes, cuando alguien eligió dónde vivían los datos. Misma rotura, resultado opuesto.

El informe de Uptime termina, por su cuenta y sin que nadie le pregunte, en el mismo sitio: dice que las pruebas regulares, la formación del personal y una gestión del cambio más disciplinada seguirán siendo de las medidas «most effective — and cost-efficient» para reducir el riesgo de caída. Es la frase más útil del informe entero, y no habla de comprar nada. Habla de ensayar.

Nosotros esto lo montamos como parte del trabajo de cumplimiento y continuidad: el calendario de simulacros, quién los conduce, qué se cronometra y qué se arregla después. La foto previa —qué dependencias tienes de verdad y cuáles no aguantan una prueba— la sacamos en consultoría, y la parte de volver a levantarlo, en disaster recovery. Ninguna de las tres cosas empieza comprando hierro. Empieza apagando algo un martes.

Fuentes (verificadas el 3 de septiembre de 2026): el 87% con mejor gestión/procesos/configuración y su subida de siete puntos respecto a 2024 (n=98, encuesta de 2025), el 92% que señala el error humano como contribuyente al menos menor (n=220, Data Center Resiliency Survey 2026), «failures to follow established procedures» como primera causa de las caídas con error humano (n=199), el tratamiento del error humano como factor contribuyente y no como causa raíz, el rango histórico de dos tercios a cuatro quintos, la energía como primera causa de las caídas con impacto, el 57% por encima de 100.000 dólares y uno de cada cinco por encima del millón, ambas del Global Data Center Survey 2025 (al que el propio informe se refiere también como su encuesta anual de 2025), el 55% resuelto en menos de doce horas y la subida por segundo año de las caídas de más de 48 horas, los cortes de fibra y cable submarino al doble de su media histórica en 2025 y la frase sobre pruebas regulares y gestión del cambio — Uptime Institute, «Annual outage analysis 2026» (UII Keynote Report 201, mayo de 2026; Douglas Donnellan, Andy Lawrence y Rose Weinschenk). El peso del error humano en grandes servicios de internet — D. Oppenheimer, A. Ganapathi y D. Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. La aritmética de los nueves es cálculo directo sobre 8.760 horas al año. El simulacro de 14 minutos es un dato interno de everyWAN sobre nuestra propia infraestructura: es una prueba realizada, no una garantía de servicio.