Probar un failover —la transferencia de un servicio a una instancia o ubicación alternativa— permite comprobar si el servicio puede seguir funcionando cuando falla su ruta principal. Pero ninguna prueba con impacto real es completamente inocua: puede revelar dependencias ocultas, provocar errores o complicar el retorno. La decisión práctica no es simplemente «probar o no probar», sino escoger el alcance que aporte evidencia suficiente con un riesgo aceptable.
Para responsables de tecnología, infraestructura y operaciones, una prueba útil empieza por delimitar qué se quiere demostrar y qué no se tocará. También requiere responsables identificados, señales observables y condiciones de parada acordadas antes de ejecutar cambios. Así, el ejercicio deja de ser una maniobra improvisada y se convierte en una verificación controlada.
Qué demuestra una prueba y qué no demuestra una copia de seguridad
Una copia de seguridad y un failover responden a necesidades distintas. La copia conserva datos para poder recuperarlos; el failover intenta mantener o restablecer el servicio usando una ruta alternativa. Tener copias no demuestra por sí solo que la aplicación pueda arrancar en otro entorno, que las credenciales funcionen o que los usuarios puedan completar sus tareas.
Una prueba de failover puede aportar evidencia sobre la conmutación, la disponibilidad de dependencias y el comportamiento de la aplicación durante la transición. No demuestra automáticamente que todos los datos estén íntegros, que cualquier escenario de desastre esté cubierto ni que la recuperación vaya a repetirse igual bajo otras condiciones. La conclusión debe limitarse al escenario realmente probado.
Antes de empezar, redacta una afirmación verificable, por ejemplo: «El recorrido de consulta de pedidos funciona en la instancia alternativa cuando se aísla la ruta principal». Evita objetivos vagos como «validar la resiliencia». La afirmación concreta ayuda a elegir pruebas, métricas y criterios de éxito sin ampliar el alcance durante la ejecución.
Elegir el nivel de prueba según el riesgo
No todas las comprobaciones requieren conmutar producción. Escoge el nivel más bajo que pueda responder a la pregunta planteada y escala solo si la evidencia es insuficiente.
- Revisión documental: inspecciona diagramas, configuración, procedimientos y responsabilidades. Es apropiada para encontrar pasos obsoletos o dependencias no documentadas. No prueba que la ruta alternativa funcione en ejecución.
- Simulación o ejercicio de mesa: el equipo recorre un escenario y decide qué haría, sin cambiar el sistema. Permite descubrir dudas operativas y problemas de coordinación, pero no verifica la infraestructura.
- Entorno aislado: ejecuta la conmutación en un entorno separado que reproduzca las dependencias relevantes. Reduce la exposición de producción, aunque las diferencias de configuración o carga pueden limitar lo que se aprende.
- Conmutación controlada: modifica una parte delimitada del tráfico o de la infraestructura real, con observación y retorno preparados. Puede dar evidencia directa, pero tiene mayor riesgo y exige autorización, ventana y capacidad de intervención.
Considera el impacto potencial, la reversibilidad del cambio, la calidad de la observabilidad y la sensibilidad de los datos. Si no puedes detectar una degradación o recuperar el estado anterior con confianza, no aumentes el nivel de prueba hasta resolver esas carencias.
Delimitar recorrido, dependencias y participantes
Define el servicio y el recorrido que se probarán desde la perspectiva del usuario. Por ejemplo, no basta con confirmar que una instancia está activa si el usuario necesita autenticarse, consultar información y completar una operación. El alcance debe identificar qué pasos se incluyen, qué usuarios o tráfico quedan expuestos y qué componentes quedan fuera.
Haz un inventario de dependencias que puedan cambiar el resultado: DNS, balanceadores, bases de datos, almacenamiento, sistemas de identidad, colas, APIs externas y mecanismos de monitorización. Para cada una, aclara si participa en la prueba, quién puede intervenir y cómo se distinguirá un fallo de esa dependencia de un fallo del servicio principal.
Asigna, como mínimo, una persona responsable de dirigir la prueba, otra con autoridad para detenerla y responsables técnicos de los componentes afectados. Acordad también quién comunica el inicio y el cierre, quién observa la experiencia del usuario y quién ejecuta el retorno. En equipos pequeños una persona puede cubrir más de una función, pero las responsabilidades deben ser explícitas.
Preparar condiciones previas y plan de retorno
Antes de cualquier cambio, confirma que las configuraciones de origen y destino son conocidas, que existe acceso operativo y que los pasos de conmutación y retorno están documentados. Comprueba que las personas necesarias están disponibles durante toda la ventana; no dependas de localizar a un especialista después de iniciar el cambio.
Define un plan de retorno que responda tres preguntas: qué condición lo activa, quién lo ejecuta y cómo se verifica que el servicio volvió a un estado aceptable. El retorno no siempre equivale a deshacer el último cambio: si hubo escrituras o una actualización de estado, volver a la ruta anterior puede producir inconsistencias. Si no está claro cómo proteger los datos y evitar dos rutas activas en conflicto, limita la prueba a simulación o entorno aislado.
Acuerda las condiciones previas con el equipo: estado saludable del servicio, monitorización disponible, ausencia de cambios concurrentes relevantes y comunicación preparada. Si alguna condición no se cumple, posponer es una decisión de control, no un fracaso del ejercicio.
Definir señales de éxito y criterios para detenerse
Establece de antemano qué observaciones indican éxito. Combina señales técnicas y funcionales: disponibilidad de los componentes alternativos, errores y latencia, estado de dependencias y resultados de una transacción de prueba. Desde el punto de vista del usuario, verifica el recorrido acordado, no solo que los servidores respondan.
Los umbrales deben adaptarse al servicio y a su línea base; no existe un número universal apropiado para todos los sistemas. Documenta el valor o condición que activa la parada, quién lo observa y durante cuánto tiempo se evaluará. Criterios típicos son un aumento sostenido de errores, una degradación fuera del margen acordado, pérdida de una dependencia esencial o discrepancias de datos. Define además cómo actuar ante una señal ambigua: pausar y evaluar, en lugar de seguir por inercia.
Una parada puede significar detener nuevos cambios, revertir tráfico o volver a la ruta conocida. No esperes a que el servicio falle por completo. La autoridad para abortar debe ser inequívoca y cualquier integrante designado debe poder invocarla sin negociar durante una incidencia.
Ejecutar por etapas y validar la recuperación
- Registrar el estado inicial. Anota la salud del servicio, las métricas relevantes, los cambios en curso y el recorrido funcional de referencia.
- Aplicar el cambio mínimo. Sigue el procedimiento aprobado y evita introducir ajustes adicionales durante la prueba, salvo que el plan indique cómo gestionarlos.
- Observar cada etapa. Verifica el cambio de ruta, las dependencias y el recorrido del usuario. Mantén comunicación entre quien ejecuta y quien observa.
- Detener o continuar según los criterios. Si se alcanza una condición de parada, prioriza contener el impacto y ejecutar el plan acordado. Registra qué ocurrió y a qué hora.
- Verificar el retorno o la operación alternativa. Confirma el estado final del servicio y revisa que no queden rutas, procesos o cambios temporales sin controlar.
La prueba no termina cuando el tráfico llega al destino alternativo. Comprueba que las operaciones representativas producen resultados coherentes, que las dependencias responden y que la observabilidad sigue funcionando. Si el ejercicio incluye escrituras, valida con especial cuidado el estado de los datos y los mecanismos de sincronización, sin asumir que la ausencia de alertas equivale a integridad.
Convertir resultados en mejoras concretas
Registra el escenario, el alcance, las personas responsables, las señales observadas, las decisiones y cualquier desviación del procedimiento. Separa hechos de hipótesis: «la consulta devolvió un error» es una observación; su causa puede requerir investigación. No presentes una prueba parcial como validación completa de la recuperación.
Convierte cada brecha en una acción con responsable y criterio de cierre: actualizar una dependencia documentada, corregir una alerta, aclarar el retorno o preparar un entorno de prueba más representativo. Repite el ejercicio cuando los cambios afecten componentes críticos, cuando una prueba revele incertidumbre relevante o cuando el procedimiento cambie. La frecuencia debe responder al riesgo y a la evolución del servicio, no a una fecha arbitraria.
En resumen, la forma más segura de probar un failover es limitar lo que se expone, escoger un nivel proporcional al riesgo y acordar de antemano cómo reconocer tanto el éxito como la necesidad de parar. La evidencia obtenida será útil si describe exactamente qué se probó, qué quedó fuera y qué debe corregirse antes del siguiente ejercicio.