Tres milisegundos. Ese es el tiempo que duró la bajada de tensión en la acometida eléctrica que, el 15 de julio, dejó tres servicios de la zona
Operamos hardware propio en datacenter y damos servicio de colocation, así que estos informes los leemos con un interés muy poco académico: lo que le pasó a Google en Países Bajos le puede pasar a cualquiera con un CPD, y la lista de cosas que fallaron ese día es exactamente la lista de cosas que casi nadie comprueba. El informe oficial de Google está publicado y es honesto hasta doler. Vale la pena leerlo entero, pero si no vas a hacerlo, aquí está lo que importa: la cadena completa, por qué la redundancia que había sobre el papel no funcionó, y las preguntas concretas que conviene hacer —a tu proveedor y a ti mismo— antes de que te toque.
La cadena, en orden
Casi todos los pasos que vienen a continuación son mecanismos de protección haciendo exactamente su trabajo. El problema está en cómo encajan. Reconstruido a partir del informe:
Las horas del informe están en hora del Pacífico; los intervalos son relativos al inicio de la falta eléctrica. La duración total del incidente fue de 14 h 55 min, y el impacto por servicio, de 9 h 24 min en Google Cloud VMware Engine (24 nubes privadas de 20 clientes), 12 h 57 min en Bare Metal Solution (9 clientes) y 8 h 31 min en NetApp Volumes.
Dos acometidas, dos DRUPS, y aun así una fila a oscuras
Sobre el papel, ese datacenter tenía todo lo que se le pide a un datacenter serio: doble acometida, respaldo rotativo diésel en cada lado, refrigeración con fuente redundante. En un cuestionario de auditoría, todas las casillas marcadas. Y aun así una fila entera se quedó sin corriente y una sala llegó a 44 grados.
La lección no es que la redundancia no sirva. Es que la redundancia solo cuenta si las ramas son de verdad independientes y están todas disponibles a la vez. Aquí falló por los dos lados. El evento que disparó todo fue común a las dos acometidas —una falta aguas arriba, en la red del suministrador, no distingue entre tu lado A y tu lado B—, y una de las ramas de frío estaba fuera por obras. Una configuración N+1 con una rama en mantenimiento no es N+1: es N, y encima con la sensación de tener margen.
El detalle más instructivo, sin embargo, es otro: la fila 3 no se cayó porque le faltara alimentación disponible, sino porque al intentar meter toda su carga por una sola acometida saltó una protección de sobrecarga. Es el fallo clásico del reparto de carga: cada rama aguanta su mitad, pero no aguanta las dos. Se descubre el día del corte, nunca antes, salvo que alguien haya hecho el ejercicio de sumar consumos reales por rama en vez de fiarse del diseño original. Si en tu CPD nadie ha vuelto a hacer esa suma desde que se instalaron los últimos cinco racks, esa suma está pendiente.
El eslabón que nadie audita: quién alimenta al que manda arrancar el frío
Si tuviéramos que quedarnos con una sola frase del informe, sería esta: el controlador de la enfriadora se quedó sin servicio durante el transitorio y no llegó a dar la señal para rearrancar las bombas. No se rompió el enfriador. No se rompieron las bombas. Se cayó el autómata que les dice que arranquen.
Esto es muy común y casi nunca aparece en un diagrama de resiliencia. Cuando alguien dibuja la cadena de frío, dibuja enfriadoras, bombas, tuberías y climatizadores de sala. Lo que casi nunca se dibuja es la electrónica de control: los PLC, los sensores, los variadores, los pequeños cuadros de mando que orquestan todo lo anterior. Son consumos ridículos —unos cientos de vatios— comparados con los megavatios que gobiernan, y precisamente por ridículos acaban quedando fuera de la alimentación protegida. El resultado es un sistema que sobrevive perfectamente al corte pero no sabe volver solo.
La prueba de que este era el diagnóstico está en la propia respuesta: entre las primeras acciones del equipo de instalaciones estuvo llevar un SAI portátil hasta los controladores de las enfriadoras. Un SAI de emergencia, arrastrado hasta allí en plena madrugada europea, para alimentar unos cuadros de control que gobiernan la refrigeración de una zona de un hiperescalar. Cuando lo lees así suena casi doméstico, y esa es justamente la parte que hay que retener: la infraestructura crítica se sostiene sobre piezas pequeñas que nadie mira hasta que se caen.
La pregunta que sale de aquí, y que sirve tanto para un hiperescalar como para el CPD de una empresa mediana: si se va la luz y vuelve treinta segundos después, ¿qué partes de tu instalación arrancan solas y cuáles necesitan que alguien vaya y les dé a un botón? La respuesta no está en el diagrama unifilar; está en la lista de qué hay conectado a alimentación protegida. Casi siempre hay sorpresas, y casi siempre están en el lado del clima, no en el de los servidores.
44 grados: el apagado no fue el fallo
Conviene decirlo porque en las lecturas rápidas del incidente se cuela lo contrario: apagar las máquinas fue lo correcto. A 44 grados de ambiente, la alternativa a un apagado ordenado no es «seguir dando servicio»; es cocer discos, fuentes y electrónica de red, y convertir un incidente de quince horas en una reposición de hardware de varias semanas. La factura de haber llegado a esa temperatura ya estaba puesta: cuatro nodos de almacenamiento SAN fallaron por calor antes de que empezara el apagado.
Lo que sí es discutible es el margen. Pasaron poco más de dos horas entre el corte y los 44 grados. Eso es todo lo que da una sala llena cuando se queda sin frío, y es bastante menos de lo que la gente intuye, porque la densidad por rack ha subido mucho más rápido que la capacidad de la sala de absorber calor. Si tu plan de contingencia asume que «da tiempo a reaccionar», ponle un número a ese «da tiempo». Google, con toda su instrumentación y su equipo presencial, tuvo dos horas.
Es un caso de manual de por qué la temperatura y el estado del clima tienen que estar en la misma consola de monitorización que el resto, y con umbrales que avisen antes del punto de no retorno, no cuando ya no hay nada que hacer. Ya escribimos sobre esto: una alerta que llega cuando ya no puedes actuar es ruido caro.
La letra pequeña: una zona no es un edificio
Aquí está la parte que más nos interesa de todo el incidente, y la que menos se ha comentado. Los tres servicios afectados fueron VMware Engine, Bare Metal Solution y NetApp Volumes. No es casualidad: son precisamente los servicios en los que el cliente tiene hierro dedicado —hipervisores, servidores físicos, cabinas— y no una abstracción repartida por software entre varias salas. Y esos tres servicios operaban desde un edificio concreto dentro de la zona.
El consejo estándar de cualquier hiperescalar es «despliega en varias zonas». Es un buen consejo. Pero esconde un supuesto que casi nadie verifica: que tu servicio se comporta como el modelo de zonas dice. Los servicios gestionados especializados suelen colgar de un datacenter único dentro de la zona, y eso no aparece en el diagrama bonito de la documentación. El resultado es una dependencia arquitectónica real que muchos equipos no saben que tienen, hasta que el edificio en cuestión se queda sin frío.
Dicho de otra forma, y sin ninguna intención de hacer sangre: cuando te llevas tu VMware a la nube de otro, cambias de dueño del rack, no de física. Los watios y los grados siguen ahí, sólo que ahora en un edificio en el que no puedes entrar y sobre el que no decides cuándo se hacen obras. A veces ese cambio compensa mucho. Pero la ventaja que se compra es operativa y financiera, no es inmunidad térmica, y conviene no confundir las dos cosas al escribir el plan de continuidad.
Lo que este incidente NO demuestra
No demuestra que la nube sea frágil ni que haya que sacarlo todo de ahí. Lo decimos nosotros, que vivimos de montar y mantener infraestructura fuera de los hiperescalares y que tendríamos el incentivo obvio de decir lo contrario.
Ese datacenter tenía doble acometida, respaldo rotativo, refrigeración redundante, telemetría térmica que permitió ordenar un apagado a tiempo y un equipo de instalaciones presencial que resolvió el problema con un SAI portátil. El armario del cuarto trastero de una oficina —con su SAI de 1.500 VA comprado en 2019, su aire acondicionado doméstico y su enchufe compartido con la cafetera— no tiene nada de eso, y ahí el mismo transitorio de tres milisegundos no habría dado quince horas de incidente: habría dado una sala cociéndose sin que ninguna alarma llegara a nadie hasta la mañana siguiente. Que a un hiperescalar le pase esto no es un argumento a favor de hacerlo en casa; si acaso es lo contrario.
La conclusión útil no es dónde, sino qué preguntas y qué asumes. Ya hicimos la cuenta a cinco años entre colocation y cloud público y la respuesta honesta fue «depende, y aquí están los números». Este incidente no cambia esa cuenta. Cambia la lista de preguntas que hay que hacer antes de firmarla.
Las siete preguntas que sí valen la pena
Sirven para el datacenter donde tienes tu colocation, para el proveedor cloud al que le compras servicios de hierro dedicado y para tu propia sala si todavía tienes una. Se responden mirando registros y calendarios, no marcando casillas.
- ¿Hay obras en marcha ahora mismo? Y si las hay, ¿qué rama de redundancia está degradada mientras duren y hasta cuándo? Es la pregunta más rentable de toda la lista y casi nadie la hace. Una reforma en el circuito de frío convierte tu contrato N+1 en un N durante meses, sin que cambie ni una línea del contrato.
- ¿Los controladores del clima están en alimentación protegida? No las enfriadoras: los controladores. Y las bombas, y los variadores. Es la pregunta que este incidente pone sobre la mesa y la que distingue a quien ha pensado el problema de quien ha comprado equipos.
- ¿Cuándo fue la última prueba de transferencia con carga real? Con fecha. Arrancar los generadores en vacío un martes por la mañana no prueba nada; lo que hay que probar es la transferencia con la carga que hay hoy, no la del día del diseño.
- Si una rama asume toda la carga, ¿aguanta? Esta es la que tumbó la fila 3. Pide el reparto de consumo por rama y compáralo con el calibre de las protecciones. Si nadie ha rehecho esa suma desde el último crecimiento, está desactualizada por definición.
- ¿Cuánto tiempo tengo desde que se para el frío hasta el apagado? Un número en minutos, medido, no estimado. Es tu ventana real de reacción y determina si un plan manual tiene sentido o si todo tiene que ser automático.
- ¿Mis sistemas están de verdad repartidos, o solo lo parece? En cloud: ¿el servicio que uso es multi-sala o cuelga de un edificio? En colocation: ¿mis dos «nodos redundantes» están en salas distintas, con acometidas distintas, o son dos racks contiguos alimentados por el mismo cuadro?
- ¿Quién me avisa, cuándo y por qué canal? Y con qué detalle. Google publicó un informe con la cadena entera, las horas al minuto y una lista de medidas correctoras con fecha de cierre. Ese nivel de detalle es lo que te permite decidir si sigues ahí. Un proveedor que sólo te da «incidencia resuelta» te está pidiendo que confíes sin datos.
Y aun con las siete respondidas
Aunque tu proveedor conteste bien a las siete, sigue habiendo una posibilidad real de que un martes cualquiera una sala entera se apague durante quince horas. Eso no se arregla con un contrato mejor: se arregla teniendo el servicio en otro sitio y habiéndolo probado. Es la misma conclusión a la que llegamos con la caída de AWS de este mismo mes, y no ha mejorado con la repetición: la recuperación que no has ensayado no es un plan, es una intención.
En la práctica, para la mayoría de empresas medianas eso significa cosas bastante mundanas: que las copias vivan lejos de la infraestructura que copian, que exista una segunda ubicación con capacidad suficiente para lo importante —no para todo, para lo importante—, y que alguien haya cronometrado alguna vez cuánto se tarda de verdad en levantar ahí lo crítico. Nosotros repartimos nuestra propia infraestructura de Proxmox y Ceph entre varios datacenters precisamente por esto, y la parte que de verdad enseña no es montarla: es cronometrar la vuelta.
Tres milisegundos. Es un buen recordatorio de que, por debajo de todas las capas de software, sigue habiendo un edificio, una acometida y un circuito de agua fría. Y de que la resiliencia de verdad no se compra: se comprueba.
Fuentes (verificadas): la bajada de tensión de 3 ms y la actuación de las protecciones del suministrador, el fallo del DRUPS del lado A por avería de componentes eléctricos, la transferencia correcta de las filas 1 y 2 y el disparo por sobrecarga de la fila 3, la caída del controlador de la enfriadora y las bombas que no rearrancaron, la fuente de frío redundante no disponible por obras, los 44 °C en la sala y el cruce del umbral de operación segura, el apagado de servidores, almacenamiento y conmutadores iniciado por los equipos de ingeniería, los cuatro nodos SAN NetApp caídos por calor antes de ese apagado, el SAI portátil provisional para los controladores, la duración total de 14 h 55 min, los impactos por servicio (9 h 24 min en GCVE con 24 nubes privadas de 20 clientes; 12 h 57 min en BMS con 9 clientes; 8 h 31 min en GCNV) y las medidas correctoras con fechas de cierre escalonadas hasta octubre de 2026 — informe oficial de incidente de Google Cloud. Todas las horas del informe están en hora del Pacífico. El apunte sobre que estos servicios operaban desde un datacenter concreto dentro de la zona y la brecha de transparencia que eso supone: The Register (21 de julio de 2026) y DataCenterDynamics. La lectura sobre redundancia degradada por obras, la electrónica de control fuera de alimentación protegida, la ventana térmica como número medido y las siete preguntas son nuestras. Imagen de portada: interior de una sala técnica (banco de imágenes de licencia libre).
¿Sabes qué hay debajo de tu infraestructura?
En everyWAN alojamos hardware propio y de clientes en datacenter —colocation— y montamos planes de recuperación que se prueban, no que se archivan. No vendemos inmunidad a los cortes de luz: eso no existe. Lo que sí hacemos es responder las siete preguntas de arriba sobre tu montaje concreto y decirte, con números, cuánto tardarías hoy en volver si una sala se apagara. A veces la respuesta es tranquilizadora. Cuando no lo es, mejor saberlo un martes cualquiera que a las cuatro de la madrugada.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN