RPO y RTO de una API de multas: probar la restauración
Un backup exitoso no demuestra que una API pueda recuperarse a tiempo. La evidencia aparece cuando se restaura en un entorno aislado y se mide la pérdida y la demora.
Por Marco Ferreiro ·
Decir que una API de multas tiene backups no responde la pregunta que importa durante una caída: ¿cuánto dato se perdería y cuánto tardaría el servicio en volver a cumplir su función? RPO y RTO expresan esos límites, pero sólo se vuelven evidencia cuando existe una restauración medida de punta a punta.
El ejercicio no tiene que esperar un desastre. Puede ejecutarse en un entorno aislado, con patentes sintéticas, un reloj controlado y criterios definidos antes de empezar.
Dos objetivos que miden cosas distintas
El Recovery Point Objective establece cuánta historia podría perderse. Si el último punto recuperable es de las 10:00 y el incidente se fija a las 10:07, la brecha observada es de siete minutos. El Recovery Time Objective establece cuánto puede demorar la recuperación desde el inicio del incidente hasta que el servicio vuelve a ser utilizable.
AWS y NIST tratan ambos como objetivos del negocio y del plan de contingencia, no como propiedades automáticas de una tecnología. Un snapshot diario no crea por sí solo un RPO de cinco minutos. Una instancia que enciende rápido tampoco demuestra que la consulta de una patente funciona de punta a punta.
Definir el incidente antes de medir
La prueba empieza con un escenario preciso: pérdida lógica de la base primaria, corrupción detectada o indisponibilidad de una región. Se registra una hora de corte única y se prohíbe ajustar el inicio después de conocer el resultado.
También se define qué se conserva: infraestructura, configuración versionada, referencias a secretos, datos, colas y artefactos de aplicación. Si un componente queda fuera, se documenta como dependencia manual y su tiempo integra el RTO.
Restaurar en un destino aislado
No se prueba sobre la producción activa. Se crea un destino sin rutas públicas ni consumidores capaces de mandar avisos de multas, webhooks o cobros. Las credenciales son de prueba y las integraciones externas usan dobles controlados.
La restauración parte del artefacto disponible en ese instante, no de una copia preparada especialmente. Se anota el identificador del backup, su hora, su hash o versión y todos los pasos manuales. Así otro equipo puede repetir el ejercicio.
Qué significa “servicio recuperado”
El cronómetro no se detiene cuando la base acepta conexiones. Para una API de infracciones, un criterio funcional puede exigir:
- autenticación y autorización correctas;
- creación de una consulta sintética;
- persistencia del estado y lectura posterior;
- procesamiento idempotente de un callback de prueba;
- respuesta del contrato público esperado;
- métricas, logs y alarmas nuevamente operativos.
Si falta una migración o una cola no consume, la infraestructura está encendida pero la consulta de una patente todavía no funciona.
Medir la pérdida sin datos reales
Antes del punto de corte se insertan eventos sintéticos numerados y fechados. Después de restaurar se busca el último evento íntegro y se calcula la diferencia contra la hora del incidente. También se comprueba que no existan relaciones partidas: consultas de patente sin resultado padre, callbacks duplicados o estados imposibles.
La cohorte no necesita patentes ni clientes reales. Identificadores reservados para pruebas y payloads irreales permiten medir integridad sin transformar producción en un banco de ensayo.
Registrar resultados y desvíos
El informe debe separar objetivo, resultado y margen. Por ejemplo: RPO objetivo de quince minutos, pérdida observada de nueve; RTO objetivo de una hora, recuperación funcional en cuarenta y ocho minutos. También registra qué paso consumió más tiempo y qué decisión humana fue necesaria.
Una ejecución favorable no autoriza a prometer disponibilidad ilimitada. El resultado pertenece al escenario, volumen, fecha y versión probados. Cambios de arquitectura o crecimiento significativo exigen repetirlo.
Un ejercicio que no alcanza el objetivo tampoco se maquilla como “parcialmente exitoso”. Se conserva el tiempo real, se identifica el cuello de botella y se abre una acción con responsable y fecha. Repetirlo después permite comprobar la mejora; editar el comienzo o excluir un paso lento destruye la comparabilidad.
Probar la restauración de forma periódica
NIST recomienda mantener y ejercitar los planes de contingencia. AWS también subraya que una estrategia de recuperación debe evaluarse regularmente. La periodicidad depende del cambio y del riesgo: una nueva base, un cambio en cifrado, otra región o una migración relevante son disparadores claros.
La mejor señal de continuidad no es una consola con backups verdes. Es un ejercicio reproducible que muestra qué se restauró, cuánto se perdió, cuándo volvió la consulta de patentes y qué quedó fuera.
Metodología
- Alcance
- Diseño de una prueba de restauración para una API y sus almacenes persistentes.
- Unidad de análisis
- Ejercicio aislado con un punto de recuperación, una hora de incidente y criterios funcionales de salida.
- Cobertura
- Datos, configuración, secretos referenciados, colas, jobs y consumidores necesarios para una consulta completa.
Limitaciones
- Los tiempos obtenidos en un ejercicio no garantizan el mismo resultado bajo un desastre de mayor alcance.
- La estrategia y los objetivos deben ser definidos por cada organización según impacto, costo y dependencias.
Fuentes
- SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — National Institute of Standards and Technology (consultada el )
- Disaster Recovery of Workloads on AWS — Amazon Web Services (consultada el )
- Recovery objectives RTO and RPO — Amazon Web Services (consultada el )
Preguntas frecuentes
¿Un backup verde prueba que el RPO se cumple?
No. Confirma que una tarea produjo una copia, pero no cuánto dato útil puede recuperarse ni si la copia es consistente. Eso se mide al restaurarla.
¿El RTO termina cuando arranca el servidor?
No necesariamente. Debe terminar cuando el criterio acordado de servicio se cumple, por ejemplo autenticación, consulta, persistencia y callbacks operativos.
¿La prueba debe usar consultas reales?
No. Puede usar una cohorte sintética con relaciones e invariantes equivalentes, evitando copiar patentes, personas o payloads de producción.
Notas relacionadas
Cómo diseñar un sandbox de API útil sin usar patentes ni personas reales
Un entorno de prueba sirve cuando reproduce decisiones y fallas del contrato, no cuando copia expedientes de producción. Los escenarios deterministas hacen posible probar sin PII.
Tests de contrato de la API de multas: cambios incompatibles
Un campo opcional nuevo suele ser compatible; un enum cerrado nuevo puede romper un cliente estricto. Los fixtures de consumidor convierten esas diferencias en pruebas antes del despliegue.
API key u OAuth para consultar multas: qué riesgo resuelve cada modelo
Los dos mecanismos autentican al sistema de la flota que consulta infracciones, pero difieren en emisión, alcance, expiración, rotación y operación. La elección parte del riesgo.