Continuidad de negocio en un mundo impredecible

Las interrupciones de los últimos años han dejado una lección concreta: casi ninguna figuraba en los planes de continuidad escritos antes de que ocurrieran. Los planes construidos alrededor de un único escenario —incendio, inundación o caída de sistemas— resultaron frágiles. Los basados en capacidades demostraron ser adaptables.

Esta es la decisión central del diseño de la continuidad de negocio actual: ¿planificar para las causas o para las consecuencias?

Un análisis riguroso de impacto en el negocio pregunta qué debe poder hacer la organización, cuánto tiempo puede sobrevivir sin hacerlo y de qué depende esa actividad. Las respuestas no dependen del escenario: perder un proveedor, un centro de datos o un equipo clave puede provocar la misma consecuencia operativa.

El mapeo de dependencias suele ser demasiado superficial en los BIA. No basta con saber que la gestión de pedidos depende de un ERP. Hay que saber qué administrador tiene las credenciales de recuperación y si estará localizable en un día festivo.

Conviene profundizar una capa cada vez. Los pedidos dependen del ERP; el ERP, de un clúster de bases de datos; el clúster, de una plataforma de virtualización; y la plataforma, de un servidor de licencias que deja de emitir tokens tras catorce días sin conexión. Esa dependencia de cuarto nivel no suele aparecer en los diagramas de arquitectura y puede convertir una interrupción de dos horas en una de dos días. Los servidores de licencias, las autoridades de certificación, el DNS y la sincronización horaria son ejemplos clásicos. Comparten una característica: nadie se ocupa de ellos porque siempre funcionan.

También conviene distinguir entre el impacto que se acumula y el que aparece de inmediato. Un equipo financiero puede tolerar normalmente un día sin herramientas de informes y, sin embargo, encontrarse con un plazo regulatorio inamovible a final de mes. Los requisitos de continuidad que ignoran el calendario generan prioridades de recuperación correctas de media y equivocadas en los días decisivos.

Un objetivo de tiempo de recuperación (RTO) de cuatro horas es una aspiración hasta que alguien restaura el sistema en ese plazo y lo documenta. Según nuestra experiencia, la primera prueba real suele revelar un tiempo de recuperación entre dos y cinco veces superior al objetivo declarado.

La diferencia rara vez se debe a la restauración en sí. Surge del trabajo que nadie había contado: localizar la documentación vigente, obtener la aprobación de alguien que está durmiendo, descubrir que al entorno de recuperación le falta una regla de cortafuegos y reconstruir las integraciones que dependen del sistema, no solo el propio sistema. La recuperación es una secuencia y los objetivos declarados suelen medir únicamente el paso central.

Los objetivos de punto de recuperación (RPO) merecen el mismo escepticismo. Un RPO de cuatro horas presupone que se pueden reconstruir las transacciones de las últimas cuatro horas y que alguien sabe cuáles eran. Cuando reconstruirlas depende de que un cliente recuerde qué pidió, la tolerancia real a la pérdida de datos es una cuestión de proceso de negocio, no de configuración de las copias de seguridad.

Descubrirlo es un éxito, no un fracaso, siempre que ocurra durante un ejercicio y no durante un incidente.

Lo más difícil de una crisis rara vez es la ejecución técnica. Es decidir, con información incompleta, si activar el entorno alternativo, si informar a los clientes y quién tiene autoridad para gastar sin aprobación previa.

La conmutación al entorno alternativo es el ejemplo más claro. A menudo solo puede revertirse con un coste importante, y la información que la justifica suele llegar una hora después del momento ideal para actuar. Los equipos que nunca han ensayado esa decisión tienden a esperar, porque esperar no exige una firma. Nombrar a quien puede decidir y establecer el umbral para hacerlo convierte una hora de vacilación en una decisión.

Los ejercicios de escritorio que ensayan estas decisiones aportan más resiliencia que otra página de documentación. Los más productivos eliminan deliberadamente un recurso: se simula que la plataforma principal de chat no está disponible o que la persona que siempre tiene la respuesta está de vacaciones. Los puntos únicos de fallo humanos aparecen enseguida y suelen ser más baratos de resolver que los técnicos.

Registra lo que ha revelado el ejercicio y trata los hallazgos con la misma seriedad que los de auditoría: responsables, fechas y seguimiento. Un ejercicio cuyas lecciones se comentan y después se archivan ha producido una tarde agradable, no una mejora.