Antes de reiniciar, ¿sabe qué consecuencias tuvo el fallo?

Cuando falla una canalización de CDC, la presión es para que la replicación vuelva a funcionar. Pero antes de elegir una ruta de recuperación, el equipo necesita comprender qué cambió mientras la canalización estuvo inactiva.

Es posible que el origen haya continuado el procesamiento. El destino podría estar cada vez más desactualizado. Las aplicaciones posteriores podrían haber seguido funcionando, haberse detenido por completo o haber tomado medidas compensatorias. Es posible que el historial de origen necesario aún esté disponible, o que la ruta de recuperación normal ya esté cambiando.

La pregunta no es solo: ¿Cómo volvemos a empezar?

La pregunta es: ¿Qué consecuencias tuvo este fracaso y qué implicaciones tiene para la recuperación?

Las directrices de continuidad de FEMA describen el análisis de procesos empresariales como el mapeo de los flujos de trabajo, las actividades, la experiencia del personal, los sistemas, los datos y las instalaciones necesarios para realizar una función esencial. Esta misma mentalidad de dependencia resulta útil al evaluar el alcance de una interrupción de los CDC.*

Una evaluación del impacto de un incidente realizada por los CDC ayuda a establecer:

• El período y el estado de procesamiento afectados
• Los datos que no alcanzaron el objetivo
• Los sistemas y procesos comerciales posteriores expuestos
• Las condiciones que limitan las opciones de recuperación disponibles
• Las cuestiones abiertas que deben resolverse o gestionarse explícitamente

El objetivo no es retrasar la recuperación, sino evitar elegir un camino de recuperación basado en información incompleta.

¿Qué debo hacer inmediatamente después de que se detenga una tarea de replicación de CDC?

Antes de decidir cómo recuperarse, determine qué se vio afectado. Una evaluación del impacto de un incidente realizada por los CDC ayuda a establecer el período de recuperación afectado, los datos y los consumidores finales expuestos, la magnitud y la importancia de la brecha de datos resultante, las condiciones que limitan las vías de recuperación disponibles y las preguntas o riesgos que deben resolverse antes de seguir adelante.

Solo entonces el equipo podrá elegir una ruta de recuperación basada en evidencias y no en suposiciones.

Respuesta rápida: ¿Qué debería incluir una evaluación del impacto de un incidente realizada por los CDC?

Una evaluación práctica del impacto de un incidente realizada por los CDC debería responder a cinco preguntas:

1. ¿Cuál es el período de recuperación afectado?
2. ¿Qué datos y consumidores finales se vieron expuestos?
3. ¿Qué tan grande y significativa es la brecha de datos resultante?
4. ¿Qué condiciones limitan las vías de recuperación disponibles?
5. ¿Qué preguntas sin respuesta o riesgos deben resolverse o gestionarse antes de que se inicie la recuperación?

Las secciones siguientes describen el proceso utilizado para responder a esas preguntas. El objetivo no es completar una lista de actividades, sino reunir suficiente evidencia para elegir una vía de recuperación adecuada y establecer la base para la validación posterior a la recuperación.

La profundidad de la evaluación debe reflejar el alcance y el riesgo del incidente. Una interrupción contenida puede requerir solo una revisión breve, mientras que una interrupción compleja que involucre datos críticos, intervenciones manuales o una exposición significativa a sistemas posteriores requerirá una investigación más exhaustiva.

Defina la ventana de incidentes

Una vez establecido el último punto de procesamiento confiable, defina el período que debe abarcar la evaluación. La ventana de incidentes generalmente se extiende desde el último punto de procesamiento confiable conocido hasta la interrupción y el estado objetivo o de recuperación actual. Dependiendo del incidente, la ventana puede incluir:

• El período anterior a que alguien detectara el problema
• La replicación del tiempo se interrumpió o se degradó.
• Actividad continua de la fuente durante la interrupción
• Procesamiento parcial o intentos de reintento
• Cambios o intervenciones en el lado objetivo
• Reinicio inicial o actividad de recuperación

No des por sentado que el momento en que alguien se percató del fallo es el momento en que comenzó el fallo.

Preguntar:

• ¿Cuándo se tuvo constancia por última vez de que la replicación funcionara según lo previsto?
• ¿Cuándo empezó a ralentizarse, a fallar o a detenerse el procesamiento?
• ¿Cuándo se detectó el problema?
• ¿La fuente continuó procesando transacciones?
• ¿La captura, el transporte o el objetivo continuaron parcialmente?
• ¿Alguien intentó reiniciar el sistema o realizar cambios en la configuración?
• ¿Recibió la persona objetivo alguna actualización directa o compensatoria?
• ¿Qué punto representa el estado actual que se está evaluando?

Por qué es importante

Una interrupción de cinco minutos detectada de inmediato es diferente de una interrupción de cinco minutos descubierta horas después, cuando los sistemas posteriores continuaron utilizando datos obsoletos. El intervalo de tiempo del incidente determina qué debe investigar el equipo. También sirve como punto de partida para elegir una ruta de recuperación y validar los datos posteriormente.

Mapear los datos afectados

No todas las tablas, archivos, conjuntos de datos o dominios de datos dentro de una secuencia de replicación conllevan el mismo riesgo. Comience por identificar qué estaba incluido cuando la replicación se ralentizó o se detuvo. Luego, determine qué cambió realmente durante el período en que ocurrió el incidente. Para cada objeto o dominio de datos afectado, considere lo siguiente:

Actividad de cambio

• ¿Se produjeron inserciones, actualizaciones o eliminaciones?
• ¿Cuánta actividad de cambio se acumuló?
• ¿Se realizaron cambios de esquema compatibles?
• ¿Los mismos registros cambiaron varias veces?
• ¿Se trataba de transacciones de alto valor o de vital importancia para el negocio?

Importancia para el negocio

• ¿Los datos sirven de base para la elaboración de informes, la liquidación, las reclamaciones, los pagos, el inventario, el servicio al cliente, la detección de fraudes u otro proceso crítico?
• ¿Los datos están sujetos a requisitos de gobernanza, auditoría o regulación?
• ¿Qué tan actual debe ser la señal objetivo para su uso posterior?

Relaciones de datos

• ¿Es necesario mantener sincronizadas varias tablas o archivos?
• ¿Importa la relación encabezado-detalle, padre-hijo u otra dependencia?
• ¿Recuperar solo una parte de los datos afectados crearía un estado inconsistente?

Actividad del lado objetivo

• ¿Algún proceso escribió directamente en el destino?
• ¿Se actualizaron los registros manualmente?
• ¿Se cargaron datos desde otra fuente?
• ¿Algún equipo posterior intentó encontrar una solución alternativa?

Cuando los objetos relacionados deban permanecer consistentes, agrúpelos según esas dependencias. La recuperación y la validación deben reflejar las relaciones relevantes para la aplicación o el proceso de negocio, no simplemente el orden alfabético o el número de filas.

La pregunta práctica que hay que plantearse en cada situación es: "¿Qué datos son los más importantes en este incidente y qué relaciones deben preservarse durante la recuperación?".

Aplicar la misma respuesta a todas las tablas puede suponer una pérdida de tiempo en datos de bajo riesgo, al tiempo que se pasan por alto un pequeño número de dependencias críticas.

Evaluar la exposición aguas abajo

Un fallo en el CDC no afecta únicamente al proceso de replicación. Si la fuente sigue funcionando, las aplicaciones posteriores pueden permanecer disponibles mientras sus datos se vuelven cada vez más obsoletos. Otros consumidores pueden detenerse por completo. Algunos pueden seguir procesando información parcial o inconsistente. Para cada consumidor posterior, documente lo siguiente:

Lo que experimentó el consumidor

• ¿La aplicación dejó de recibir datos?
• ¿Continuó funcionando con datos obsoletos?
• ¿Recibió solo una parte de la información esperada?
• ¿Los usuarios vieron algún error o el problema permaneció oculto?
• ¿Se ha producido algún fallo en un evento o actualización previstos?

Si se tomaron medidas compensatorias. Durante una interrupción prolongada, los equipos pueden:

• Parchear manualmente los datos de destino
• Cargar datos desde una copia de seguridad o una fuente alternativa.
• Consultar temporalmente el sistema de registro
• Pausar un proceso empresarial
• Reprocesar transacciones fuera del flujo de trabajo normal
• Anular una decisión automatizada

Esas acciones son importantes porque pueden alterar el objetivo o crear conflictos con los cambios que se implementen posteriormente mediante la replicación.

¿Qué repetición o puesta al día puede desencadenar?

Algunos sistemas posteriores pueden aceptar cambios diferidos sin efectos secundarios. Otros inician la lógica de negocio cuando se produce un evento.

Dependiendo de la aplicación, la reproducción de los cambios acumulados podría desencadenar:

• Notificaciones
• Pagos
• Ajustes de inventario
• Transiciones de flujo de trabajo
• Solicitudes de servicio
• Integraciones descendentes
• Acciones duplicadas

En muchos entornos, se trata fundamentalmente de una cuestión de idempotencia: ¿puede el consumidor procesar de forma segura un evento reproducido sin generar consecuencias comerciales no deseadas?

Por qué es importante

Una canalización técnicamente recuperable aún puede generar un problema empresarial más amplio. El origen puede estar en buen estado. El destino puede estar disponible. Pero los usuarios posteriores pueden tomar decisiones basándose en datos obsoletos o incompletos, y la recuperación puede tener consecuencias fuera de la plataforma de replicación.

Cuantificar la brecha de datos

Una vez que se comprenda el período de tiempo durante el incidente y el alcance afectado, describa la brecha en términos que sean útiles tanto para las partes interesadas técnicas como para las comerciales.

Las medidas técnicas pueden incluir:

• Tiempo transcurrido desde el último punto de procesamiento confiable
• Retraso de replicación actual
• Cambio o retraso en las transacciones
• Inserciones, actualizaciones y eliminaciones generadas durante el intervalo
• Posición de origen en comparación con la posición de procesamiento actual.
• Rendimiento de procesamiento o aplicación al objetivo
• Capacidad de recuperación disponible
• Disponibilidad de historial de fuentes relevantes
• Tiempo estimado de recuperación basado en el rendimiento observado

Evite considerar el tiempo de recuperación estimado como una garantía. El rendimiento real de la recuperación puede variar según la actividad de la fuente, la capacidad de la red, la presión sobre el destino, la contención de la infraestructura, el volumen de cambios y la carga de trabajo concurrente.

Las medidas empresariales pueden incluir:

• Transacciones aún no visibles para un sistema posterior.
• Informes o paneles que funcionan con información obsoleta.
• Los procesos empresariales se retrasan o se detienen.
• Decisiones o acciones tomadas utilizando datos obsoletos
• Se acercan los plazos de entrega de los clientes o de las autoridades reguladoras.
• Intervenciones manuales realizadas durante el intervalo
• Consumidores que requieren un trato especial durante la reproducción
• Riesgo financiero, operativo, de servicio o de cumplimiento

Las métricas técnicas básicas ayudan al equipo operativo a definir el alcance de la recuperación. Las medidas de impacto empresarial ayudan a las partes interesadas a comprender por qué el incidente es importante y cómo se debe priorizar la recuperación.

Por qué es importante

Una acumulación de 100 000 cambios puede ser rutinaria en un entorno y crítica para el negocio en otro. La magnitud de la brecha importa. También importa qué contiene esa brecha y quién depende de ella.

Confirmar de qué depende la recuperación

Se puede cuantificar una brecha, aunque la ruta de recuperación adecuada siga siendo incierta. Antes de optar por un reinicio, una puesta al día, una resincronización selectiva o una recarga general, documente las condiciones que influyen en las opciones disponibles.

Disponibilidad del historial de origen: Determine de qué información de origen depende la ruta de recuperación compatible. Dicha información podría incluir:

• Registros de transacciones activas
• Registros archivados
• Revistas
• Historial de cambios conservado
• Reiniciar o estado del proceso
• Posiciones de registro específicas de la fuente
• Información de recuperación gestionada por la plataforma

Si el historial de origen requerido ya no está disponible de inmediato, verifique si los registros archivados u otro historial conservado pueden recuperarse y procesarse mediante una ruta de recuperación compatible. Si el historial necesario no está disponible, las opciones de recuperación podrían ser más limitadas.

No dé por sentado que la presencia de registros archivados implica automáticamente que se admite una ruta de recuperación específica. Confirme cómo la plataforma utiliza ese historial para el origen, el destino y la configuración específicos.

Estado objetivo

Determinar si el objetivo se mantiene en una condición que permita la recuperación.

Preguntar:

• ¿El objetivo seguía estando disponible?
• ¿Se realizaron escrituras directas?
• ¿Se actualizaron los registros manualmente?
• ¿Cambió la estructura o los esquemas de destino?
• ¿Algún proceso recargó o resincronizó parcialmente los datos?
• ¿Es posible proteger el objetivo de cambios adicionales durante la recuperación, en caso necesario?

Comportamiento de reproducción del consumidor: Para los consumidores que inician una acción cuando llegan los datos, determine si los eventos retardados o repetidos se pueden procesar de forma segura.

Preguntar:

• ¿Puede el consumidor reconocer eventos ya procesados?
• ¿Podría la repetición desencadenar acciones duplicadas?
• ¿Están disponibles los identificadores de transacción o las claves comerciales?
• ¿Se pueden suprimir temporalmente las notificaciones, los pagos o los flujos de trabajo?
• ¿Debe el equipo de atención al cliente coordinar la recuperación?

Objetivos de recuperación: Compare el tiempo estimado de recuperación con los objetivos establecidos para los sistemas afectados.

Preguntar:

• ¿Cuánto tiempo pueden tolerar los usuarios finales datos obsoletos?
• ¿Se acerca alguna fecha límite relacionada con negocios, informes, liquidaciones o clientes?
• ¿La recuperación estimada se ajusta al plazo previsto para la recuperación?
• De no ser así, ¿qué acción alternativa o decisión de las partes interesadas se necesita?
• Si no existe un objetivo de recuperación formal, documente la tolerancia de la empresa ante el incidente actual en lugar de inventar un umbral genérico.

Por qué es importante

Conocer la magnitud de la brecha no le indica al equipo cómo recuperarse. El equipo también necesita comprender qué exige la ruta de recuperación respaldada, si esas condiciones aún existen y qué riesgos puede conllevar la recuperación en sí misma.

Documentar las preguntas abiertas y las limitaciones para la toma de decisiones.

Una evaluación de impacto debe visibilizar la incertidumbre, no ocultarla. Documente cuestiones como:

• ¿Es fiable la posición de reinicio?
• ¿Está disponible todo el historial de fuentes necesario?
• ¿Recibió el destinatario escrituras directas?
• ¿Existe algún conflicto entre los parches manuales y los cambios en el código fuente?
• ¿Se pueden reproducir los eventos acumulados de forma segura?
• ¿Qué datos requieren una validación más exhaustiva?
• ¿Qué equipos posteriores deben aprobar la reanudación?
• ¿Se aceptan excepciones para una recuperación controlada?

Las preguntas abiertas deben asignarse y evaluarse según el riesgo que presenten. Algunas pueden impedir la recuperación. Otras pueden gestionarse como excepciones explícitas con responsables, controles y acciones de seguimiento definidos.

El objetivo no es crear una certeza artificial, sino asegurar que la decisión sobre la recuperación refleje lo que se sabe, lo que aún se desconoce y las suposiciones que está haciendo el equipo.

Elaborar el resumen del impacto del incidente de los CDC

La evaluación debe concluir con un resumen escrito conciso que sirva de base para la decisión de recuperación y como punto de partida para la validación posterior a la recuperación. Incluir:

Ventana de incidentes

• Último punto de procesamiento de confianza conocido
• Inicio del incidente confirmado o estimado
• Momento en que se detectó el problema
• Límite de evaluación actual
• Período total transcurrido

Datos afectados

• Fuentes y objetivos involucrados
• Tablas, archivos, conjuntos de datos o dominios de datos afectados
• Cambio de volumen durante el intervalo
• Dependencias relevantes
• Cualquier escritura directa al objetivo o cambios manuales

Exposición aguas abajo

• Aplicaciones, informes, API, análisis o procesos afectados
• Si los consumidores se detuvieron, continuaron con datos obsoletos o recibieron información parcial
• Cualquier medida compensatoria adoptada
• Riesgos de repetición o de puesta al día

Evaluación de la brecha de datos

• Retraso o acumulación actual
• Esfuerzo estimado de recuperación
• Transacciones o eventos comerciales que aún no se reflejan en la cadena de suministro.
• Plazos comerciales o consecuencias operativas

Restricciones de recuperación

• Disponibilidad del historial de fuentes
• Reinicio o disponibilidad del estado del proceso
• condición objetivo
• Consideraciones del consumidor sobre la reproducción
• Ventana de recuperación prevista
• Limitaciones de la plataforma o la configuración

Preguntas abiertas

• ¿Qué queda por desconocer?
• ¿Qué preguntas influyen en la decisión de recuperación?
• ¿Quién es el propietario de cada pregunta?
• ¿Qué preguntas dificultan la recuperación?
• ¿Cuáles pueden gestionarse como excepciones documentadas?

Próxima decisión recomendada

La evaluación de impacto no debe prescribir automáticamente una ruta de recuperación específica. Debe proporcionar suficiente información para que el equipo determine si:

• Reanudar desde el estado guardado
• El proceso conservó los cambios históricos.
• Continuar con la recuperación supervisada
• Comparar los datos de origen y destino
• Resincronizar los datos seleccionados
• Realizar una resincronización o recarga más amplia
• Retrasar la acción hasta que se resuelva una cuestión crítica.
• Escalar la decisión a otros responsables técnicos o comerciales.

Aspecto de una evaluación completada

El siguiente ejemplo es ilustrativo. Los nombres, valores, carga de trabajo y consideraciones de recuperación son sintéticos y no representan un umbral, arquitectura o procedimiento de recuperación recomendado.

Resumen del incidente

Pipeline: Flujo de replicación de pedidos a almacén
Último punto de procesamiento de confianza: Punto de control de destino confirmado correspondiente a las 2:14 a. m.
Fallo detectado: 2:17 a. m.
Evaluación completada: 4:00 a. m.
Brecha actual: Aproximadamente 1 hora y 46 minutos

Datos afectados

Exposición aguas abajo

Restricciones de recuperación

• El historial de fuentes requerido sigue estando disponible.
• El destino contiene actualizaciones manuales del inventario realizadas durante la interrupción.
• Los eventos retrasados ​​pueden generar notificaciones a los clientes durante el proceso de recuperación.
• Los datos del encabezado y los detalles del pedido deben recuperarse y validarse conjuntamente.
• Los propietarios de las zonas posteriores de la cadena de suministro necesitan un plan de comunicación y de respuesta claro.

Preguntas abiertas

• ¿Cómo deben conciliarse las actualizaciones manuales de destino con los cambios de origen entregados durante la puesta al día?
• ¿Deben publicarse, suprimirse o gestionarse por separado las notificaciones a los clientes que se hayan retrasado?
• ¿Qué comparación confirmará la coherencia entre el encabezado y los detalles del pedido después de la recuperación?

Conclusión de la evaluación

El estado de reinicio disponible y el historial de origen conservado permiten evaluar con mayor detalle una ruta de recuperación. Antes de proceder con la recuperación, el equipo debe acordar cómo gestionar las actualizaciones manuales de destino y las notificaciones diferidas.

La evaluación de impacto no prueba que la recuperación vaya a tener éxito. Establece las condiciones que debe abordar la decisión de recuperación.

Errores comunes en las evaluaciones de impacto de los CDC

Considerar el estado de la tubería como el límite del incidente: Un proceso que ha fallado o se ha degradado puede informar un estado operativo que no se corresponde con el último cambio reflejado correctamente en el destino. Utilice la fuente, la plataforma y la evidencia del destino más fiables disponibles para establecer el límite de la evaluación.

Medir únicamente el tiempo de inactividad transcurrido: El tiempo de inactividad por sí solo no explica cuánto cambió el sistema objetivo con respecto al origen, qué datos se vieron afectados ni qué sistemas posteriores siguieron funcionando. Mida tanto el retraso técnico como la exposición de los sistemas posteriores.

Suponiendo que el volumen de cambios equivale al tiempo de recuperación: El volumen de cambios es solo un factor. El rendimiento observado, el tamaño del registro, la actividad de origen, la latencia de destino, la presión sobre la infraestructura, la complejidad de la transformación y las cargas de trabajo concurrentes también afectan la duración de la recuperación.

Detenerse en el nivel técnico: Una evaluación que documenta el retraso y la posición en el registro, pero ignora a los usuarios finales, es incompleta. La consecuencia para el negocio determina la urgencia, la secuencia, la comunicación y el riesgo aceptable.

Ignorar las medidas compensatorias: Los parches manuales, las cargas alternativas, las soluciones provisionales y las escrituras directas en el destino pueden modificar las suposiciones de recuperación. Documente estas medidas antes de que comience la replicación y se entreguen los cambios acumulados.

Ocultar la incertidumbre: Las preguntas sin respuesta no desaparecen cuando comienza la recuperación. Documente lo que aún se desconoce, determine qué incertidumbres impiden la acción y gestione el resto como excepciones explícitas.

Cómo encaja la evaluación de impacto en el flujo de trabajo de recuperación

La evaluación del impacto de los incidentes por parte de los CDC se sitúa entre la detección y la ejecución de la recuperación.

Es compatible con:

Decisión de reinicio: La evaluación establece el alcance del fallo, el estado de procesamiento disponible, las dependencias del historial de origen, la condición objetivo y las consideraciones posteriores necesarias para elegir una ruta de recuperación compatible.

Leer más: El error más peligroso de los CDC en la recuperación ocurre después del fracaso.

Seguimiento de la recuperación: La acumulación prevista de trabajo, la actividad de origen, la tolerancia posterior y las condiciones de recuperación documentadas en la evaluación ayudan al equipo a interpretar el progreso de la recuperación.

Leer más: Su canal de suministro de los CDC no está caído. ¿Está seguro de que está en buen estado?

Validación posterior a la recuperación: La ventana de tiempo del incidente, los datos afectados, las dependencias y las acciones compensatorias identificadas en la evaluación definen qué debe validarse después de la recuperación.

Leer más: El oleoducto vuelve a estar en marcha. ¿Se puede confiar en los datos?

Comunicación posterior: El mapa de consumidores y el resumen de impacto aclaran quién necesita actualizaciones, qué datos permanecen restringidos y qué evidencia respaldará la eventual declaración de que todo está correcto. La evaluación convierte un fallo indefinido en un incidente delimitado con un alcance conocido, restricciones explícitas y un camino más claro hacia la recuperación.

Utilice la evaluación posterior al incidente.

La evaluación de impacto no debe desaparecer cuando comience la recuperación. Una vez que el objetivo haya sido validado y se haya reanudado su uso, revise la evaluación para identificar qué cambios deben producirse antes de la próxima interrupción.

• ¿Qué información tardó demasiado en encontrarse?
• ¿Qué dependencias faltaban o estaban mal documentadas?
• ¿Qué equipos posteriores se enteraron del problema demasiado tarde?
• ¿Qué decisiones dependieron de un solo especialista?
• ¿Qué intervenciones manuales generaron riesgo de reconciliación?
• ¿El entorno de monitorización reflejó los datos reales y el impacto en el negocio?
• ¿La plataforma proporcionó suficiente información de reinicio, diagnóstico, recuperación y validación?
• ¿Deberían modificarse los procesos de retención o recuperación del historial de fuentes?
• ¿Qué umbrales, manuales de procedimientos, asignaciones de responsabilidad o procedimientos de comunicación deberían actualizarse?
• ¿Podría el mismo fallo generar la misma incertidumbre de nuevo?

Un solo incidente puede revelar una deficiencia en el proceso. Los incidentes repetidos pueden indicar un problema mayor de monitoreo, modelo operativo, capacitación o capacidad de la plataforma.

El objetivo no es solo recuperarse de esta interrupción, sino lograr que la siguiente respuesta sea más rápida, clara y fácil de defender.

Lista de verificación de evaluación del impacto de incidentes de los CDC

Antes de elegir una ruta de recuperación, confirme que el equipo ha establecido lo siguiente:

• El último punto de procesamiento confiable conocido
• La ventana de incidentes
• Las fuentes y objetivos afectados
• Los datos cambiaron durante el intervalo
• Relaciones y dependencias importantes
• Sistemas y procesos comerciales posteriores expuestos
• Si se utilizaron datos obsoletos o parciales
• Acciones manuales o compensatorias tomadas
• Retraso y acumulación de trabajo actual
• Disponibilidad de historial de fuentes requerida
• Cambios o restricciones en el lado del objetivo
• Riesgos de repetición o duplicación de acciones por parte del consumidor
• Requisitos previstos de recuperación y puesta al día
• Preguntas abiertas y propietarios asignados
• Preguntas que bloquean la recuperación
• Las excepciones se gestionan explícitamente.
• La evidencia que requerirá validación posterior a la recuperación

La evaluación estará lista para fundamentar la decisión de recuperación cuando el equipo pueda explicar qué sucedió, qué se vio afectado, de qué depende la recuperación, qué sigue siendo incierto y qué debe ser cierto antes de que se pueda proceder con la acción.

En resumen

Un fallo en la CDC no se define únicamente por el tiempo que la replicación estuvo indisponible. Se define por lo que cambió durante ese lapso, quiénes se vieron afectados, qué opciones de recuperación siguen disponibles y qué riesgos puede conllevar la propia recuperación.

La pregunta crucial no es simplemente: ¿Cómo logramos que la replicación vuelva a funcionar?

La pregunta es: ¿Comprendemos el impacto lo suficientemente bien como para elegir el camino de recuperación adecuado?

Una buena evaluación de impacto proporciona al equipo una comprensión compartida de:

• Dónde comienza el incidente
• Lo que afectó el incidente
• ¿Qué condiciones limitan la recuperación?
• ¿Qué preguntas siguen sin resolverse?
• ¿Qué pruebas serán necesarias posteriormente?

Esa es la diferencia entre reiniciar basándose en suposiciones y recuperarse de un problema que el equipo realmente comprende.

FEMA: Análisis de procesos empresariales y análisis del impacto empresarial.