Durante anos asumimos que a nube era sinónimo de continuidade. Alta dispoñibilidade, redundancia xeográfica e escalabilidade automática convertéronse en conceptos case incuestionables dentro do discurso tecnolóxico. Porén, os incidentes recentes en grandes provedores volven lembrar unha realidade incómoda: a nube tamén falla, e cando o fai, faino a gran escala.
O apagón rexistrado nun centro de datos de Microsoft na rexión oeste dos Estados Unidos non foi un erro de software nin unha mala configuración puntual. Foi un fallo físico, unha interrupción do subministro eléctrico que afectou servizos tan básicos como Windows Update, Microsoft Store e compoñentes críticos de infraestrutura en Azure. A consecuencia foi inmediata para millóns de usuarios, pero tamén reveladora para as organizacións que dependen exclusivamente deste modelo.
Non é un caso illado. En menos dunha semana producíronse incidencias distintas, de natureza lóxica e física, que impactaron servizos centrais. A coincidencia temporal non é anecdótica. Pón de manifesto que a resiliencia non depende só de boas prácticas de deseño lóxico, senón tamén de factores moito máis básicos e menos controlables.
A nube está composta por centros de datos reais, alimentados por redes eléctricas reais, situados en localizacións concretas e expostos a riscos físicos. Xeradores de respaldo, sistemas de conmutación e procedementos de recuperación existen, pero non son instantáneos nin infalibles. A recuperación dun sistema complexo non se produce no momento en que volve a electricidade. A resincronización de datos, o arranque en frío de servizos distribuídos e a restauración da telemetría poden levar horas.
Durante ese tempo, moitas organizacións operan a cegas. Os equipos de operacións e seguridade perden visibilidade, os sistemas de monitorización deixan de ser fiables e as decisións deben tomarse con información incompleta. Non é só un problema de indispoñibilidade, senón tamén de perda de control.
Aquí é onde a resiliencia deixa de ser un concepto teórico e pasa a ser unha cuestión práctica. Ter copias de seguridade non é suficiente se non existe unha capacidade real de continuar operando cando o provedor principal falla. A alta dispoñibilidade dentro dunha única nube non resolve escenarios de caída rexional nin fallos de infraestrutura subxacente.
O deseño multi-rexión real, con capacidade efectiva de failover, segue sendo a excepción e non a norma. Moitas arquitecturas están pensadas para soportar erros internos do provedor, pero non para funcionar sen el. Isto crea unha dependencia estrutural que raramente se cuestiona ata que ocorre un incidente.
Desde unha perspectiva de xestión de risco, o problema non é confiar na nube, senón confiar exclusivamente nela. A centralización extrema introduce puntos únicos de fallo que non sempre son evidentes nos diagramas de arquitectura. Ademais, delegar completamente a resiliencia no provedor pode xerar unha falsa sensación de seguridade.
A pregunta que deberían facerse os responsables de TI e seguridade non é se a nube é segura, senón que ocorre cando non está dispoñible. Existe un plan de continuidade que contemple a indispoñibilidade total do provedor? Hai capacidade operativa fóra da nube principal, aínda que sexa limitada? Están probados estes escenarios ou só documentados?
Os incidentes recentes non son unha chamada ao abandono da nube, senón á madurez no seu uso. A nube é unha ferramenta poderosa, pero non elimina as leis básicas da física nin os riscos inherentes ás infraestruturas críticas. A resiliencia real constrúese asumindo que os fallos van ocorrer, non confiando en que non sucedan.
Cando a nube se apaga, o que queda en evidencia non é a tecnoloxía, senón as decisións de deseño, gobernanza e dependencia tomadas previamente. Prepararse para ese momento é unha responsabilidade que non pode externalizarse por completo.
