Dos preguntas al equipo que determinan el presupuesto para la infraestructura

La conversación sobre tolerancia a fallos normalmente entra en detalles técnicos en el segundo minuto: replicación, conmutación, timeouts, quórum. Al responsable le queda evaluar la propuesta según la confianza que le inspire el interlocutor — lo cual es una mala manera de gestionar el presupuesto.

Para volver la discusión al terreno empresarial ayudan dos parámetros. No requieren conocimiento técnico, los define el negocio y determinan la arquitectura en su conjunto.

                         FALLO
                            │
   ─────────────────────────┼─────────────────────────►
        último punto       │      vuelta al trabajo
        de datos guardados  │
                            │
   ◄──────── RPO ──────────►│◄──────── RTO ──────────►
   cuántos datos perderemos │   en cuánto tiempo volvemos

RTO: en cuánto tiempo volveremos a operar

RTO (recovery time objective) — tiempo máximo permitido desde el momento de la falla hasta la recuperación del servicio.

En términos de negocio: en cuántos minutos u horas los clientes podrán volver a comprar.

Qué entra realmente en este tiempo

Aquí se esconde el principal error de planificación. RTO casi siempre se estima como la duración de los trabajos técnicos de recuperación, mientras que incluye toda la cadena:

detección → aviso a la persona adecuada → diagnóstico → decisión → restauración → verificación

La propia restauración a menudo resulta ser la parte más corta. Si el monitoreo detecta la falla en veinte minutos, el de guardia se despierta quince minutos después y investiga cuarenta, un RTO de una hora es inalcanzable, incluso cuando el procedimiento en sí toma cinco minutos.

De aquí la conclusión práctica: reducir el RTO casi siempre es más barato al inicio de la cadena. Configurar alertas sobre métricas de negocio concretas y establecer una guardia clara cuesta incomparablemente menos que la conmutación automática de la base de datos, y a menudo ahorra más tiempo.

Cómo el RTO determina la arquitectura

Un día. Basta con un servidor y copias de seguridad diarias. Un ingeniero levanta una máquina nueva y despliega el sistema sin prisas.

Varias horas. Se necesita un sitio de reserva preparado de antemano, réplica de la base de datos y una instrucción escrita de conmutación. La decisión la toma una persona, por eso el tiempo depende de lo rápido que esté disponible.

Minutos. Se requiere automatización: orquestación, conmutación automática de la base de datos. Cabe notar que incluso la conmutación automática no es instantánea — típicamente son decenas de segundos, porque el sistema debe asegurarse de que el servidor principal está realmente inaccesible y no simplemente pausado. Una configuración demasiado impaciente provoca conmutaciones innecesarias, lo cual puede ser peor que la propia falla.

Segundos. Alcanzable para componentes aislados, pero no para el sistema entero. El requisito de “segundos” a nivel de todo el negocio en la práctica significa “no lo hemos calculado”.

RPO: cuántos datos estamos dispuestos a perder

RPO (recovery point objective) — volumen máximo de datos, medido en tiempo, que se puede perder de forma irreversible.

En términos de negocio: de qué periodo desaparecerán pedidos, pagos y solicitudes y los clientes tendrán que volver a introducirlos.

Cómo el RPO determina la arquitectura

Un día. Basta con copias nocturnas. Una falla a las seis de la tarde implica la pérdida de todos los datos del día laboral. Aceptable para un sitio de contenidos; para una tienda online, por lo general no — pero esto debe comprobarlo el negocio, no el ingeniero.

Minutos. Se necesita archivado continuo del registro de transacciones de la base de datos en un almacenamiento separado. En una falla se restaura la última copia completa y se “reproduce” el registro hasta la última entrada guardada. La pérdida queda limitada al intervalo de envío del registro.

Cerca de cero. El archivado de logs no es suficiente — es una idea equivocada común. Garantizar la ausencia de pérdidas requiere que la base confirme al cliente la escritura solo después de que la copia de respaldo la haya aceptado, es decir, replicación síncrona. El coste es que cada operación de escritura se ralentiza durante el intercambio con el servidor de reserva; dentro de un mismo sitio esto son fracciones de milisegundo, entre regiones — decenas de milisegundos por cada escritura. Por eso un RPO cero en el ámbito geográfico es caro no solo en dinero, sino también en la velocidad del producto.

Ambos parámetros se definen por función, no por sistema

Exigir RTO y RPO únicos para toda la infraestructura es una forma segura de pagar de más. El pago de pedidos y la exportación de informes mensuales no pueden tener los mismos requisitos: en el primero el RPO tiende a cero, en el segundo perder un día no importa.

Por eso la tabla de requisitos se elabora por funciones de negocio — las mismas que se usan en la evaluación de la criticidad de los componentes. Normalmente resulta que requisitos estrictos hacen falta para dos o tres funciones de veinte, y eso reduce el presupuesto en varias veces.

La conversación que conviene tener

Escena típica: el negocio formula el requisito como «necesitamos que no se pierda nada y que todo funcione siempre». Los ingenieros lo toman literalmente, presentan un presupuesto para una arquitectura georrepartida con replicación síncrona y la discusión termina sin acuerdos — las partes se separan acusándose mutuamente de no entenderse.

La conversación progresa mejor si se empieza por tres preguntas para cada función clave:

1. ¿Cuánto puede no funcionar antes de que suframos un daño irreversible? No “cuánto nos gustaría”, sino después de qué plazo las consecuencias son irreversibles.
2. ¿Datos de qué periodo podemos recuperar manualmente? A veces la respuesta es tranquilizadora: los pedidos de los últimos diez minutos están en el correo y en el CRM, se pueden introducir de nuevo. Entonces no hace falta un RPO estricto.
3. ¿Cuánto cuesta esto? Cada endurecimiento de requisitos debe venir acompañado de un precio. La diferencia entre “cuatro horas” y “quince minutos” suele ser multiplicativa.

La práctica muestra que tras la tercera pregunta los requisitos se moderan por sí solos. Para la mayoría de sistemas de empresas medianas, una respuesta sensata es recuperación en unas horas y pérdida de datos en minutos. Esto se logra con medios probados y económicos.

Qué registrar

El resultado de la discusión — una tabla de una página: función, RTO, RPO, cómo se garantiza, cuándo se comprobó por última vez.

La última columna es más importante que las demás. El RTO declarado es una suposición; el RTO confirmado por simulacros es un hecho. Cómo separarlos se explica por separado: la copia de seguridad que nadie ha restaurado.