Cloud assessments / Continuidad
Tu plan de recuperación trae un número. Nadie lo ha medido.
Todo plan de continuidad promete un tiempo de recuperación. Muy pocos se han cronometrado alguna vez. Recovery Proven toma un conjunto representativo de tus sistemas, los levanta en otro lado en un ambiente aislado y mide cuánto tarda hasta que alguien puede trabajar. Te llevas el número real junto al prometido, y la lista de todo lo que se atravesó.
Lo que vas a saber después y hoy no sabes
- Tu tiempo real de recuperación, sistema por sistema. Medido desde que se declara la falla hasta que un usuario puede trabajar. No estimado de una ficha técnica.
- Cuántos datos perderías de verdad. El punto de recuperación que te dan hoy tu replicación y tus políticas de respaldo, frente al que el negocio autorizó.
- Qué regresa en el orden equivocado. La base de datos que tiene que estar arriba antes del ERP, el servidor de licencias que nadie listó, el nombre que sigue apuntando al sitio viejo.
- Qué le falta a tu runbook. Los pasos que sólo viven en la cabeza de alguien, y quién tendría que estar despierto para ejecutarlos.
Cómo funciona
- Partimos de tus objetivos, no de los nuestros. El tiempo de recuperación y la pérdida de datos que tu negocio ya comprometió son la vara. Si nunca se fijaron, los fijamos contigo, sistema por sistema, antes que nada. Sin un objetivo no hay nada que aprobar ni reprobar.
- Evidencia sin accesos. Tu equipo corre un script de sólo lectura con sus propias credenciales y revisa la salida antes de compartirla. De esa evidencia leemos cómo está configurada hoy la recuperación: replicación, políticas de respaldo, redundancia, red y nombres.
- Un failover real, aislado de producción. Los sistemas seleccionados se levantan en una red de recuperación aparte. Producción sigue corriendo, los usuarios no se ven afectados y nada se conmuta de verdad.
- Un cronómetro, no un estimado. Cada paso se mide y se registra. Cuando un paso falla, el ejercicio no falló. Esa falla es el hallazgo que el ejercicio existe para producir.
Qué cubre
- Qué se prueba. Un conjunto representativo de sistemas acordado contigo, con al menos uno de cada nivel de recuperación; un failover y un failback controlados de ese conjunto; una restauración de prueba de cada política de respaldo, y una sesión de resultados con la dirección de TI y de operaciones.
- Lo que ayuda a que salga bien. Un responsable que pueda sentar en la mesa a infraestructura, aplicaciones y seguridad; tus objetivos de recuperación, o la gente que puede fijarlos; una ventana para la prueba aislada, y la evidencia del script de solo lectura.
- Lo que normalmente queda. El tiempo de recuperación y la pérdida de datos medidos por sistema, junto a su objetivo; una matriz de hallazgos trazable a la evidencia; tu runbook corregido con lo que enseñó la prueba; un puntaje de madurez por dominio que puedes comparar año con año, y un plan priorizado. El alcance exacto se define en tu propuesta.
Cómo trabajamos
Sesión de alcance
Acordamos qué sistemas entran a la prueba, cuáles son los objetivos y qué preguntas tiene que contestar el reporte.
Evidencia
Tu equipo corre el script y envía el paquete. El calendario arranca cuando llega la evidencia, no cuando se firma el contrato.
Plan de prueba
Orden de recuperación, dependencias, criterios de éxito por sistema y el camino de regreso, escritos y aprobados antes de abrir la ventana.
Failover y failback controlados
Levantamos los sistemas en la red aislada, validamos la integridad de los datos, cronometramos cada paso y regresamos todo a su lugar.
Reporte y runbook
Resultados, brechas y plan, presentados a la dirección. Lo que no se pudo probar se declara como brecha de alcance, nunca se presenta como hallazgo.
Qué sigue
Cada brecha apunta a una corrección específica. Una copia que vive en el mismo sitio que producción es un problema de respaldo. No tener dónde levantar los sistemas es un problema de recuperación ante desastres. Un solo firewall entre la planta y el ERP es un problema de disponibilidad. El plan te dice cuál tienes y en qué orden resolverlo.
El puntaje está hecho para repetirse. Un plan de recuperación envejece cada vez que se agrega un servidor o cambia una aplicación, así que una segunda corrida un año después te dice si vas mejorando o nada más envejeciendo.
Preguntas
¿Esto afecta a producción?
No. La prueba corre en una red de recuperación aislada. Producción sigue corriendo y tus usuarios siguen trabajando.
¿Y si hoy no tenemos recuperación ante desastres?
Entonces la prueba mide lo que sí tienes: cuánto tardas en reconstruir los sistemas seleccionados desde tus respaldos actuales en un ambiente limpio. Ese número suele ser el más convincente del reporte.
¿Necesitan acceso a nuestra nube o a nuestros servidores?
Para la evidencia no: tu equipo corre un script de sólo lectura y decide qué enviar. Para el failover trabajamos junto a tu equipo, con accesos limitados al ambiente de recuperación y al tiempo que dura la prueba.
¿Y si nunca fijamos objetivos de recuperación?
Entonces la primera sesión los fija por sistema, con la gente dueña de cada proceso. Sin objetivos la prueba no tendría contra qué medirse.
¿Qué plataformas cubren?
Servidores en tu propio centro de datos que recuperan hacia AWS, y cargas que ya corren en AWS o en Azure. Si tu recuperación corre sobre algo más, te lo decimos en la llamada de alcance, antes de que te comprometas.
¿Qué pasa si el failover falla?
Entonces el ejercicio hizo su trabajo, un mes antes de que hiciera falta y no el día en que hizo falta. Cada falla se cronometra, se explica y se convierte en una línea del plan.
Conoce tu tiempo real de recuperación.
Una llamada de alcance para acordar los sistemas, los objetivos y la ventana.