El RTO que nadie quiso pagar

Cuatro horas. Alguien las escribió en una celda de una hoja de cálculo durante un taller de planificación, y desde entonces aparecen en cada auditoría. Nadie ha visto nunca que el servicio se recupere en cuatro horas.

Imagina el taller. Una sala de reuniones, una hoja de cálculo proyectada en la pared, una fila por servicio. El encabezado de la columna dice Tiempo máximo aceptable de inactividad. Cuando el cursor llega a los pedidos en línea, quien dirige ese negocio piensa en carritos abandonados, en un centro de llamadas desbordado y en un fin de semana de reembolsos, y dice cuatro horas. Alguien lo anota. Nadie propone una semana: en esa sala, una respuesta más larga sonaría a desinterés. El cursor baja a la fila siguiente.

No hay columna para el precio. Nadie pregunta cuánto pagaría el negocio, cada mes, para que las cuatro horas fueran ciertas. El equipo de infraestructura recibirá la cifra más adelante, como requisito, y nadie en la sala sabe que la última reconstrucción completa del sistema de pedidos a partir de sus respaldos, hace dos años, llevó casi toda una jornada. La cifra pasa al plan de continuidad, luego a una política y después a una diapositiva para el directorio; en cada paso se parece un poco más a un hecho.

En salas como esa suelen nacer los objetivos de recuperación: se deciden como una preferencia y se registran como un hecho. La diferencia entre cuatro horas en el papel y casi un día en la práctica no figura en ningún presupuesto ni en ningún registro de riesgos. Vive entre dos reuniones, la que eligió la cifra y la que fijó el presupuesto, y la organización descubre, el peor día posible, que nunca compró esa promesa.

Lo que de verdad promete la cifra

Supón que alguien te pregunta cuánto tardarías en volver a la carretera después de pinchar una llanta. La respuesta honesta depende menos de tu agenda que de lo que ya llevas en el auto. Sin llanta de repuesto, esperas una grúa: horas, pero no pagaste nada por adelantado. Con repuesto y gato, quizá veinte minutos, si el repuesto todavía tiene aire y ya cambiaste una llanta alguna vez. Con asistencia vial, lo hace otra persona a cambio de una cuota mensual. Con un segundo auto en la entrada, vuelves a moverte casi enseguida, y pagas un auto que casi siempre está parado. Cada respuesta más rápida se compra antes del pinchazo, llegue o no.

Un objetivo de tiempo de recuperación (RTO, por sus siglas en inglés) es la respuesta escrita de una organización a esa pregunta para un servicio concreto: el tiempo máximo que puede estar caído tras una interrupción antes de que el daño sea inaceptable. La guía de planificación de contingencias del NIST, la referencia habitual, lo subordina a una cifra mayor, el tiempo máximo tolerable de inactividad, que es la interrupción total que el negocio está dispuesto a absorber. El RTO normalmente debe ser más corto, porque con el sistema ya de vuelta todavía hace falta tiempo para reprocesar datos.

Su compañero, el objetivo de punto de recuperación o RPO, responde otra pregunta: ¿cuánto trabajo reciente puedes permitirte perder? Si la base de pedidos se copia cada noche, una falla a las cinco de la tarde se lleva los pedidos del día, diga lo que diga el RTO.

La palabra importante es objetivo. Registra lo que el negocio necesita, no lo que los sistemas pueden hacer. El tiempo de recuperación se fija como la respuesta del pinchazo: por lo que se construyó, copió, probó y dotó de personal antes de la falla. Escribir el objetivo no cuesta nada. Cumplirlo cuesta dinero todos los meses.

Una pregunta sin precio

El proceso que produce la cifra se llama análisis de impacto en el negocio. Para cada servicio, quienes dependen de él estiman cuánto les costaría una interrupción, en ingresos, clientes, penalizaciones contractuales, exposición regulatoria o seguridad, y cómo crece ese daño con cada hora. Tal como suele hacerse, también es una pregunta sobre el dolor planteada sin precio. Si le preguntas a alguien cuánto tiempo podría arreglárselas sin algo de lo que depende, la respuesta será corta, porque el costo de una respuesta corta lo paga otro.

Tres grupos tienen cada uno una parte de la decisión, y rara vez se sientan en la misma sala. El negocio decide la tolerancia: cuánto tiempo puede estar sin el servicio. Tecnología conoce la capacidad: cuánto tarda de verdad la recuperación. Finanzas controla el presupuesto que determina si esa capacidad puede cambiar. Solo la tolerancia se convierte en una frase de la política, porque es la única que sale gratis escribir. Aquí nadie actúa mal: tecnología recibe la cifra como un requisito sin dinero asociado, y finanzas nunca ve una solicitud que diga cuatro horas.

Lo que finanzas ve, en cambio, es el costo de la capacidad sin la promesa que compra: un entorno de recuperación listo en una segunda región (un grupo de centros de datos lo bastante lejano como para no compartir el mismo desastre), una copia del sistema de pedidos en marcha a baja capacidad, licencias de software que solo importan en un desastre. En un informe mensual de costos, todo eso parece desperdicio, porque está ocioso por diseño; un seguro siempre parece inútil cuando no pasa nada. Así, la revisión de costos que recorta recursos ociosos, un ejercicio perfectamente sensato, alarga en silencio el tiempo real de recuperación, y nadie actualiza las cuatro horas, porque nadie relacionó una cosa con la otra.

Lo que cuesta cada hora

El NIST plantea la elección como un equilibrio: cuanto más se prolonga una interrupción, más cuesta, y cuanto más corto es el RTO, más cara es la solución de recuperación. El objetivo correcto está donde se cruzan las dos curvas, y es distinto para cada sistema. Lo que ese equilibrio no dice es que, a medida que el objetivo se acorta, el precio no solo crece, sino que cambia de naturaleza.

De días a horas, el costo es sobre todo disciplina: copias protegidas que de verdad se restauran, infraestructura descrita como código para reconstruir un entorno en lugar de recordarlo, y un procedimiento que alguien recorrió hace poco. AWS lo llama respaldo y restauración, la opción de menor costo y complejidad. Mantenerlo es barato; usarlo, lento. Es la grúa.

De horas a minutos, empiezas a pagar por cosas que funcionan mientras no pasa nada. En lo que AWS llama luz piloto (pilot light), los datos se copian sin pausa a la región de recuperación y las bases de datos están encendidas, pero los servidores de aplicación esperan apagados, así que nada puede atender a un cliente hasta que alguien los arranque y los escale. En una réplica en espera (warm standby), una copia completa del servicio, aunque más pequeña, funciona todo el tiempo y puede recibir tráfico de inmediato con menos capacidad. En ambos casos pagas cada mes un segundo entorno que, en un buen mes, no hace nada visible. Son el repuesto y la asistencia vial.

De minutos a casi nada, el costo entra en la aplicación misma. Operar a plena capacidad en dos lugares a la vez, lo que el sector llama activo-activo, significa que ambas copias aceptan pedidos y que el software debe resolver qué pasa cuando el mismo pedido cambia en las dos en el mismo segundo. AWS lo describe como el enfoque más complejo y costoso, el que puede llevar el tiempo de recuperación casi a cero. Es un problema de diseño, no una compra de infraestructura, y se paga en horas de ingeniería en cada funcionalidad posterior: el segundo auto, que además hay que mantener sincronizado con el primero.

La factura de infraestructura es solo una parte. Hay tres costos que nunca aparecen en ella.

El primero es el ensayo. Un camino de recuperación que nadie ejercitó hace poco es una hipótesis. Ejercitarlo cuesta días de ingeniería, una ventana de mantenimiento y el riesgo de que la propia prueba provoque una caída; por eso es lo primero que se pospone cuando el trimestre se complica.

El segundo son las dependencias. Un servicio no vuelve más rápido que lo más lento que necesita: el sistema de inicio de sesión, los registros DNS (la libreta de direcciones de internet, que dirige a los clientes hacia él), los secretos y certificados sin los que no arranca, el proveedor de pagos del otro lado. Un objetivo de cuatro horas para los pedidos es una afirmación silenciosa sobre todos ellos, y a muchos nunca se les preguntó.

El tercero es la decisión. Trasladar un servicio a su sitio de recuperación, lo que se conoce como failover, tiene consecuencias: puede perder los últimos minutos de datos, y regresar después al sitio principal suele costar más que haberse ido. Así que la gente duda y espera a alguien con rango suficiente para decidir. Un failover que tarda quince minutos en ejecutarse y dos horas en autorizarse es una recuperación de dos horas y quince minutos. Acortar esa espera no cuesta dinero, sino autoridad: delegada por escrito antes del incidente, en alguien que estará despierto cuando ocurra.

¿Cuatro horas desde cuándo?

Hay un segundo lugar donde se esconde la brecha, y es el propio reloj. Cuatro horas, ¿contadas desde cuándo? ¿Y qué las detiene?

El inicio puede definirse al menos de cuatro maneras: cuando el servicio dejó de funcionar, cuando el monitoreo lo detectó, cuando alguien declaró el incidente o cuando alguien autorizó la recuperación. En una falla silenciosa de madrugada, esos momentos pueden estar a horas de distancia. Un equipo que arranca el reloj en la declaración mide qué tan rápido ejecuta, lo cual es útil, pero no lo que vivieron los clientes.

El final es igual de resbaladizo. La base de datos vuelve a funcionar, los servidores reportan que todo está bien, la página de estado se pone en verde. Nada de eso significa que un cliente pueda hacer un pedido, que el pedido llegue a datos que coinciden con el punto de recuperación acordado, que los pagos se procesen o que los controles de seguridad desactivados durante la emergencia vuelvan a estar activos. Un reloj que se detiene cuando «la base de datos funciona» puede registrar tres horas y cincuenta minutos para una caída que los clientes vivieron como nueve. Nadie mintió; usaron otro reloj.

La solución es una definición, escrita antes de la próxima prueba. Arranca el reloj de negocio cuando el servicio dejó de cumplir sus criterios acordados, con la mejor evidencia disponible, y deja constancia de qué marca sustituta usaste si el momento exacto no puede conocerse. Detenlo cuando un responsable confirme que las transacciones esenciales funcionan sobre datos en el punto de recuperación acordado. Por debajo, mide por separado la detección, la decisión, la restauración y la validación, porque ese desglose muestra adónde se va el tiempo.

Y decide de antemano si un estado degradado cuenta. Una llanta de repuesto temporal te pone en movimiento, a menor velocidad y por una distancia limitada. Aceptar pedidos y retrasar los envíos, o mantener la búsqueda pero no el pago, puede cubrir la necesidad real antes y por mucho menos dinero que una recuperación completa. Es una respuesta legítima, siempre que sea la que se acordó.

Declarado, demostrado, aceptado

Visto con claridad, todo RTO involucra tres cifras, y la mayoría de las organizaciones escribe solo una. El tiempo declarado es el objetivo de la política. El tiempo demostrado es lo que el servicio logró de verdad con el reloj acordado, en la última prueba realista o el último incidente real, con su fecha y sus condiciones a la vista: si el equipo sabía que venía la prueba, si alguien precalentó capacidad, si la arquitectura cambió desde entonces. La tercera es la brecha, y lo que costaría cerrarla.

Cuando el tiempo demostrado no alcanza al declarado, las opciones son pocas y todas cuestan algo: pagar para cerrar la brecha, sabiendo qué gasto compra qué horas; cambiar la promesa, con un modo degradado que cubra antes lo esencial; cambiar la cifra, de modo que el negocio firme un objetivo más largo con el impacto a la vista, o aceptar la diferencia como riesgo, por escrito, con un nombre y una fecha para volver a mirarla. El NIST pide algo parecido: cuando el RTO no puede cumplirse y el tiempo tolerable no admite margen, documentar la situación y un plan para mitigarla.

Lo que falta en esa lista es el desenlace más común: dejar la política en cuatro horas, la capacidad en casi un día y llamar a eso cumplimiento. Eso no es riesgo aceptado, sino riesgo que nadie aceptó, presentado como si alguien lo hubiera hecho.

Marco práctico

El RTO que se puede firmar

Antes de que un RTO entre en una política, una sola página debería reunir:

1. La promesa. El servicio, la interrupción que cubre y el reloj: qué lo arranca, qué lo detiene y si un estado degradado cuenta.
2. La evidencia. El tiempo demostrado con ese reloj, cuándo se midió y en qué condiciones.
3. El precio. Lo que costaría cerrar la brecha en infraestructura, ensayos, dependencias y autoridad delegada, y qué horas compra cada parte.
4. La firma. Quién aceptó la brecha que queda y cuándo volverá a revisarla.

Una página con las cuatro convierte el RTO de un deseo en una decisión de compra. Una página con solo la primera es la celda de la hoja de cálculo del taller.

La columna que falta

Nada de esto defiende tiempos de recuperación cortos, ni los ataca. Algunos servicios merecen minutos y el dinero que los compra. Muchos pueden estar caídos un día con una disculpa y trabajo acumulado, y tratarlos como si necesitaran cuatro horas gasta un dinero que protegería mejor otra cosa. Lo importante es que la elección se haga con el precio a la vista, que la hagan quienes van a pagarlo y que se rehaga cuando cambien el precio o el diseño.

Así que vuelve al taller. El año que viene, agrega una columna junto a Tiempo máximo aceptable de inactividad: ¿cuánto pagarías, cada mes, para que eso fuera cierto? Pon al lado el tiempo demostrado y el nombre de quien se hará cargo de la diferencia. Puede que las cuatro horas sobrevivan a esa conversación, o que se conviertan en doce, con pedidos tomados por teléfono, o en dos, con un entorno en espera y una partida presupuestaria a la altura. Cualquiera de esas respuestas es un objetivo. La cifra que hoy ocupa la celda es otra cosa: un número que todos aprobaron y nadie compró.

Notas de fuentes

Estas fuentes respaldan las definiciones de RTO, RPO y tiempo máximo tolerable de inactividad, el equilibrio entre el costo de recuperarse y el costo de la interrupción, y las estrategias de recuperación en la nube que se describen aquí. El taller de planificación, el servicio de pedidos, el objetivo de cuatro horas y todos los tiempos del artículo son ejemplos hipotéticos, igual que la llanta pinchada. La tesis de que los objetivos de recuperación se fijan sin precio, las definiciones del reloj y la lista de una página son criterio de este artículo y no se atribuyen a ninguna fuente.

• RTO, RPO y la interrupción tolerable. El NIST define el tiempo máximo tolerable de inactividad como la interrupción total que el responsable de un sistema está dispuesto a aceptar; el RTO, como el tiempo máximo que un recurso puede permanecer sin servicio antes de que el impacto sea inaceptable, y el RPO, como el momento hasta el cual pueden recuperarse los datos. Señala que el RTO normalmente debe ser más corto que el tiempo máximo tolerable y que, cuando no puede cumplirse, hay que documentar la situación y un plan para mitigarla. Fuente: NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, 2010.
• Recuperarse antes cuesta más. La misma guía trata el objetivo como un equilibrio: una interrupción cuesta más cuanto más dura, las soluciones de recuperación se encarecen a medida que el RTO se acorta, y el punto de equilibrio es distinto para cada organización y sistema. Fuente: NIST SP 800-34 Rev. 1, figura 3-3, «Cost Balancing».
• Cuatro estrategias de recuperación en la nube. AWS describe el respaldo y la restauración, la luz piloto, la réplica en espera y el activo-activo en varios sitios, desde la opción de menor costo y complejidad hasta la más compleja y costosa. La luz piloto no puede procesar solicitudes sin una acción previa; la réplica en espera puede atender tráfico de inmediato, con menos capacidad. Fuente: AWS, «Disaster recovery options in the cloud», documentación vigente.
• Objetivos según la necesidad del negocio, y luego probados. AWS Well-Architected indica que el RTO y el RPO deben fijarse según las necesidades del negocio y que las implementaciones de recuperación ante desastres deben probarse para validarlas. Fuente: AWS, «Plan for Disaster Recovery (DR)», Reliability Pillar, documentación vigente.