En 2018 hubo un evento en la región South Central US de Azure, y a nosotros nos tocó lo menos cómodo de una caída: avisarle al cliente que nuestro servicio estaba abajo. No era un problema de un tercero lejano. Para el cliente, la caída era nuestra, y la conversación también.
Lo primero que se rompe es la comunicación
Cuando falla una región completa de un proveedor cloud, el equipo técnico entra en modo recuperación y la comunicación queda para "cuando sepamos más". Es el error más natural y el más caro: el cliente no necesita saber todo, necesita saber a tiempo qué pasa, qué está afectado y cuándo volverá a saber de ti.
Pro Tip: define antes del incidente quién le habla al cliente y con qué frecuencia. Si lo decides durante la caída, el primer aviso llega tarde y el segundo llega contradictorio.
De la caída salió una arquitectura
Ese aprendizaje no se quedó en una nota de cierre. A raíz del evento se creó un esquema de georedundancia que sigue vigente a la fecha. Desde entonces, cuando ha habido fallas parciales o amplias en los data centers de Azure, el esquema ha sido parte de cómo respondemos, y la lección se confirma cada vez: la oportunidad y la claridad de la comunicación son clave.
Pro Tip: convierte cada caída grave en un cambio de arquitectura, no solo en un documento. Un RCA que no termina en un control nuevo es una disculpa bien redactada.
El RCA: objetivo y honesto
Después de la recuperación viene la parte que más cuesta: un RCA objetivo y honesto. No uno que reparta culpas ni uno que proteja la imagen, sino uno que diga qué falló, qué control no existía o no funcionó, y qué cambia a partir de ahora. Esa honestidad es lo que fortalece tus controles y, de paso, la confianza del cliente.
Pro Tip: escribe el RCA para el cliente que lo va a leer con lupa. Si el análisis aguanta esa lectura, también te sirve a ti para cerrar el control que faltaba.
Lo que queda de esta historia
Los proveedores cloud van a seguir teniendo eventos, y cuando pasen, tu cliente no va a distinguir de quién fue la falla: va a juzgar cuánto tardaste en avisarle, qué tan claro fuiste y qué cambiaste después. La georedundancia nos protege de la siguiente caída; la comunicación a tiempo y el RCA honesto protegen la relación.
Artículo relacionado: la caída de Google Cloud en Londres y por qué la resiliencia ya es regulatoriaEn este tema
Ver todo el temaRespuesta rápidaDetail
¿Qué debe hacer un proveedor de servicios durante la caída de su proveedor cloud?
Lo primero que se rompe es la comunicación: el equipo entra en modo recuperación y el aviso al cliente queda para después. Lo correcto es tener definido antes del incidente quién le habla al cliente y con qué frecuencia, porque el cliente no necesita saber todo — necesita saber a tiempo qué pasa, qué está afectado y cuándo volverá a saber de ti. Después vienen dos piezas igual de importantes: convertir la caída en un cambio de arquitectura (en nuestro caso, un esquema de georedundancia que sigue vigente) y escribir un RCA objetivo y honesto que aguante la lectura de un cliente exigente.
Escrito y revisado por Rogelio Barajas González — Auditor Líder certificado ISO 27001:2022 e ISO 9001:2015, con experiencia directa en SOC 1 Tipo 2 y SOC 2 Tipo 2. Fundador de Barajas Advisory.
Los nombres de empresas, personas y algunos detalles identificativos menores han sido generalizados para proteger la confidencialidad de las organizaciones involucradas. Los hechos, cifras y aprendizajes narrados se mantienen fieles a lo ocurrido.
Verifica sus credenciales en LinkedIn:linkedin.com/in/rogelio-barajas-gonzalezÚltima actualización: septiembre 2026
Este es uno de nueve casos reales
Cicatrices de Nube — ¿quieres el resto de las historias?
Los nueve casos documentados —FinOps, Release Management, Service Delivery, Compliance y gobernanza de IA— con un checklist de autodiagnóstico por capítulo y un scorecard general al cierre.
Descarga el playbook gratis