El incidente describe una serie de fallos en la preparación y ejecución de un plan de Recuperación ante Desastres (DR) en un entorno AWS. La causa raíz principal fue una combinación de suposiciones no validadas y una falta de pre-aprovisionamiento de recursos en la región de recuperación. La arquitectura de DR asumía que las instancias, réplicas de bases de datos y fleets de contenedores podrían lanzarse y escalarse bajo demanda durante un evento de failover. Sin embargo, esta suposición no consideró las limitaciones de capacidad de la región de recuperación ni las cuotas de cuenta, lo que llevó a un fallo en la disponibilidad de recursos críticos.
La cascada de fallos se inició con la falta de validación de estas suposiciones. Los ejercicios de DR iniciales, aunque útiles, no fueron lo suficientemente rigurosos. Un ejercicio de tabletop reveló brechas en el alcance y la propiedad de los pasos del runbook. Un failover planificado expuso una misconfiguración crítica de DNS que impedía que las aplicaciones sirvieran a los usuarios, a pesar de que los componentes individuales parecían saludables. Finalmente, un 'surprise drill' puso de manifiesto la dependencia del conocimiento tribal de un solo ingeniero para la validación de la consistencia de la base de datos, lo que añadió un retraso significativo.
Las salvaguardas fallaron porque el proceso de validación de DR no era lo suficientemente maduro. La confianza en un failover planificado, donde los equipos están pre-alertados y observan de cerca, enmascaró problemas fundamentales de preparación, coordinación y dependencias no modeladas. La falta de un enfoque progresivo y de inyección de fallos impidió descubrir estas debilidades hasta que se realizaron pruebas más realistas. La lección clave es que la validación de DR debe ir más allá de la prueba mecánica del failover para incluir la preparación del equipo, la claridad del proceso y la resiliencia ante fallos inesperados.