Tu región primaria está degradada y el negocio quiere hacer failover. Explícame el proceso.

Confirma el alcance de la degradación y si hacer failover es genuinamente más rápido que esperar, porque el failover no es gratis y las caídas parciales a veces se recuperan antes. Consigue una decisión explícita de un responsable, y luego sigue el runbook: promociona la réplica aceptando la pérdida de datos conocida, mueve el tráfico en la capa de DNS o de enrutado, verifica con peticiones reales y comunica. Planifica la vuelta atrás de forma deliberada más tarde, cuando la primaria esté estable.

Lo primero es que hacer failover es una decisión, no un reflejo. Quiero saber el alcance, si es un servicio o la región entera, y qué está diciendo el proveedor, porque si la estimación es de quince minutos entonces un failover que tarda treinta y pierde datos es la peor opción. Así que llevo esa evaluación al comandante del incidente o al responsable de negocio y toman la decisión de forma explícita, porque nadie debería aceptar pérdida de datos de forma unilateral a las tres de la mañana. Una vez tomada, sigo el runbook en vez de improvisar. Promociono la réplica en la región secundaria, sabiendo que aceptamos el retraso de replicación que hubiera en el momento del fallo, y apunto ese número para la conciliación posterior. Muevo el tráfico en la capa de enrutado, y aquí compruebo que los health checks y las vidas de los registros son lo bastante cortas para moverse rápido, porque un registro cacheado mucho tiempo hace que esto tarde mucho más de lo esperado. Luego verifico con peticiones reales en vez de con un panel. Y la vuelta atrás es su propio cambio planificado en horario laboral, nunca un segundo failover apresurado.