El proceso se ha reanudado. ¿Puede confiar en los datos?

Tras un fallo o interrupción de la replicación, un reinicio exitoso solo demuestra una cosa: la replicación se está ejecutando de nuevo. No demuestra que todos los cambios se hayan registrado. No demuestra que las eliminaciones se hayan procesado. No demuestra que los valores estén actualizados. Y no demuestra que los equipos posteriores deban confiar en los datos.

Por eso es importante la validación posterior a la recuperación.

Las directrices del NIST sobre integridad de datos consideran la recuperación como algo más que la simple restauración de la disponibilidad. Hacen hincapié en la detección y respuesta oportunas ante la pérdida de integridad, así como en el papel de la preparación, el registro y las herramientas adecuadas para minimizar el tiempo de inactividad y las pérdidas cuando los datos pueden haber sido dañados o modificados.

Antes de declarar que la recuperación ha finalizado, los equipos necesitan pruebas suficientes para responder a una pregunta sencilla: ¿En qué nos basamos cuando decimos a la gente que los datos se pueden volver a utilizar de forma segura?

Respuesta rápida: ¿Cómo se validan los datos después de la recuperación tras la intervención de los CDC?

La validación debe responder a dos preguntas diferentes pero igualmente importantes.

• ¿Se recuperó la replicación con éxito?
  Esta es la cuestión operativa. El proceso se reinició. El retraso volvió a los niveles previstos. Se eliminó el trabajo acumulado.
• ¿Se puede confiar en los datos recuperados?
  Esta es la cuestión de la integridad de los datos. El resultado refleja los cambios esperados. Hay registros importantes. Se procesaron las eliminaciones. No quedan discrepancias inexplicables.

Un proceso saludable ayuda a establecer que la recuperación se produjo. La validación ayuda a establecer que la recuperación generó datos confiables. Un proceso práctico de validación posterior a la recuperación consta de cinco partes:

• Defina el período de recuperación.
• Identifique los datos y los sistemas posteriores que se vieron expuestos.
• Utilice la evidencia disponible de la fuente, la plataforma de replicación y el objetivo.
• Verifique específicamente los modos de falla que son importantes.
• Documentar qué se validó, qué se encontró y qué sigue siendo incierto.

No te fíes de una sola señal.

Un proceso en ejecución indica que la replicación está funcionando. El recuento de filas proporciona información sobre el conjunto de datos resultante. Una comparación entre el origen y el destino identifica las diferencias dentro de su ámbito de compatibilidad. Los registros y diagnósticos de la plataforma indican lo sucedido a nivel operativo. Las comprobaciones a nivel empresarial indican si el resultado final es coherente.

En conjunto, estas señales pueden sustentar una conclusión defendible. Analicemos cada una de ellas.

La validación es un proceso de cinco partes.

Las secciones siguientes profundizan en estas cinco áreas. Algunos pasos requieren varias comprobaciones. Por ejemplo, comparar los datos de origen y destino puede implicar validar recuentos, identificar cambios faltantes, comprobar si hay duplicados, confirmar eliminaciones e investigar valores obsoletos.

El objetivo no es completar trece tareas inconexas, sino reunir pruebas suficientes para responder a una sola pregunta: ¿Podemos confiar en los datos recuperados?

Defina la ventana de recuperación

Antes de realizar cualquier comparación, determine qué período está intentando evaluar. Comience con el último punto anterior al incidente en el que se sabía que la replicación funcionaba correctamente. Luego, identifique cuándo la recuperación y la puesta al día alcanzaron el punto que está evaluando.

Esto te da un margen de recuperación: desde el último estado correcto conocido → pasando por la interrupción → pasando por la puesta al día → hasta el estado en el que ahora quieres confiar. Dependiendo de la fuente y la plataforma, las referencias útiles pueden incluir:

• marcas de tiempo
• Reinicio o estado del proceso
• puntos de control
• marcadores
• posiciones del registro de origen
• Coordenadas de recuperación específicas de la plataforma

En entornos Db2 para z/OS, los equipos también pueden utilizar conceptos específicos del origen, como RBA o LRSN, según corresponda. La terminología exacta varía. Lo importante es que todos los que evalúan la recuperación se refieran al mismo período y al mismo límite lógico.

Cómo las posiciones de los registros de origen, incluidos Db2 para z/OS RBA/LRSN, pueden ayudar a fundamentar la validación posterior a la recuperación.

La posición del registro de origen puede ayudar a los equipos a identificar el período de procesamiento que intentan evaluar. En entornos Db2 para z/OS, RBA o LRSN pueden ser relevantes para comprender la posición del registro de origen, según la configuración y el entorno.

Estas coordenadas pueden servir de base para la investigación. No deben considerarse una prueba irrefutable de que el objetivo se ha completado. El equipo aún necesita conectar el estado de origen relevante, la evidencia de la plataforma de replicación y el estado objetivo resultante.

Preguntar:

¿Cuándo empezó realmente el problema?

¿Cuál fue el último estado en el que confiamos?

¿Cuándo comenzó la recuperación?

¿Cuándo volvió el objetivo al estado que estamos evaluando actualmente?

¿Qué transacciones, conjuntos de datos, tablas, archivos o procesos posteriores se encuentran dentro de ese período?

Por qué es importante

Si el período de validación es vago, la conclusión también lo será, por lo que no se puede responder con seguridad: "¿Se nos pasó algo por alto?" hasta que se llegue a un acuerdo sobre: ​​"¿Entre qué dos puntos?".

Identificar qué fue lo que realmente quedó expuesto

No valides todo automáticamente con el mismo nivel de esfuerzo. Primero, comprende qué cambió durante el período de recuperación y qué sistemas posteriores dependían de esos datos.

Preguntar:

• ¿Qué fuentes y objetivos se vieron afectados?
• ¿Qué tablas, archivos, conjuntos de datos o dominios de datos cambiaron durante ese período?
• ¿Qué aplicaciones posteriores, informes, análisis, API o procesos operativos dependen de ellos?
• ¿Se utilizaron datos de destino obsoletos mientras la replicación estaba retrasada?
• ¿Qué datos son lo suficientemente importantes para el negocio como para requerir una validación más exhaustiva?
• ¿Existen usos relacionados con clientes, informes, finanzas, operaciones, regulaciones u otros usos de alto impacto que estén dentro del alcance?

Esto ayuda a determinar el nivel de validación necesario. Una interrupción breve que afecte a datos de bajo riesgo puede justificar un enfoque de validación diferente al de una interrupción prolongada que involucre liquidaciones, reclamaciones, informes regulatorios u otro proceso crítico.

La cuestión práctica: “¿Qué es lo que realmente importa en este vacío?”

Ese es un punto de partida más útil que aplicar la misma lista de verificación a ciegas a todas las tablas.

Haz un inventario de las pruebas que realmente tienes.

La validación posterior a la recuperación debe basarse en tres fuentes:

A. La fuente

¿Qué información proporciona la fuente autorizada sobre el período afectado? La evidencia pertinente puede incluir:

• Registros de origen
• Historial de transacciones/cambios
• Marcas de tiempo
• Llaves
• Información de registro o secuencia específica de la fuente
• Totales de negocios
• Otras evidencias del sistema fuente

B. La plataforma de replicación

¿Qué información puede mostrar la plataforma sobre lo sucedido? Dependiendo del producto y la configuración, esto puede incluir:

• Estado de reinicio/proceso guardado
• Información de estado y monitoreo
• Errores y diagnósticos
• Información rezagada o de recuperación
• Capacidades de comparación o validación compatibles
• Otras evidencias operativas específicas de la plataforma

C. El objetivo

¿Qué contiene realmente el objetivo ahora? Dependiendo de los datos y del caso de uso, es posible que deba inspeccionar:

• Archivos
• Claves de negocio
• Recuentos
• Valores
• Marcas de tiempo
• Excepciones de destino
• Resultados posteriores
• Comportamiento a nivel de aplicación

La validación más sólida suele provenir de conectar las evidencias a través de estas capas, y no de tomar el estatus de "éxito" de un sistema como la respuesta definitiva.

Empieza con algo amplio, pero no te detengas en el número de filas.

El recuento de filas es útil. Sin embargo, es una de las primeras cosas que los profesionales experimentados advierten que no se deben considerar suficientes. Dos conjuntos de datos pueden tener el mismo número de filas y aun así ser incorrectos.
Podrías tener:

• una fila faltante y una fila inesperada
• la clave correcta con un valor incorrecto
• un registro que debería haber sido eliminado pero que aún existe
• una actualización posterior sin un estado esperado anterior
• diferencias que se cancelan entre sí en el recuento total

Por lo tanto, utilice comprobaciones generales para identificar dónde profundizar en la investigación. Algunas comprobaciones generales útiles pueden incluir:

• recuentos de filas o registros esperados
• volúmenes de cambio previstos
• rangos clave
• Totales empresariales de alto nivel
• marcas de tiempo
• excepciones inesperadas
• estado informado por la plataforma

Una discrepancia indica de inmediato que algo requiere investigación. Una coincidencia indica que esta verificación en particular se realizó correctamente. No significa que todo esté comprobado.

El número de filas es un indicador, no una garantía de que todo esté en orden.

Comparar la fuente y el destino donde importa

Una vez que haya definido el período de recuperación y el alcance afectado, compare el origen y el destino en un punto lógicamente apropiado. Dependiendo de su entorno, la validación podría utilizar:

• Claves de negocio
• Comparación a nivel de récord
• Columnas seleccionadas
• Hashes o sumas de verificación cuando corresponda
• Totales de control
• Marcas de tiempo
• Valores de origen y destino
• Capacidades de comparación compatibles con la plataforma

El objetivo no es necesariamente comparar cada byte de cada conjunto de datos, sino determinar si los datos que deberían representarse en el destino están representados correctamente para respaldar la conclusión requerida.

Tenga cuidado con el momento oportuno.

Es necesario comparar el origen y el destino en estados significativos y lógicamente compatibles. Si el origen continúa cambiando mientras el destino aún se está sincronizando, una diferencia no implica automáticamente un fallo en la recuperación. Simplemente puede significar que se están midiendo ambos lados en momentos diferentes.

Por eso, el período de recuperación y el límite de comparación son importantes.

Cómo validar la integridad de la replicación CDC de mainframe a la nube después de la recuperación: sumas de comprobación, posiciones de registro y conciliación.

No existe una fórmula de validación universal. Sin embargo, los equipos suelen combinar varias formas de evidencia al validar los datos después de una recuperación de datos de un sistema central CDC.

Recuentos y totales de control: Útiles para identificar diferencias evidentes en los volúmenes esperados o en los agregados comerciales.

• Ideal para: detección de anomalías en general.
• No prueba: que los registros o valores individuales correctos estén presentes.

Claves y comparaciones a nivel de registro: Útiles para identificar registros faltantes, inesperados o que no coinciden dentro de un ámbito definido.

• Ideal para: encontrar diferencias específicas.
• No prueba automáticamente: la secuencia de transacciones ni ninguna forma de corrección histórica.

Hashes o sumas de verificación: Cuando sea apropiado, los hashes o las sumas de verificación pueden ayudar a comparar conjuntos de valores de manera eficiente.

• Útil para: detectar que los valores de origen y destino difieren.
• No te dice automáticamente: por qué difieren o si el comportamiento específico de la secuencia fue correcto.

Marcas de tiempo, estado de reinicio y posiciones del registro de origen: Estos datos pueden ayudar a determinar el período o el estado de procesamiento que se está evaluando. Para fuentes de mainframe, la terminología específica de la posición depende de la plataforma subyacente.

• Útil para: servir de base a la investigación de recuperación.
• No prueba automáticamente que los datos finales sean correctos.

Capacidades de diagnóstico y comparación de la plataforma Su plataforma de replicación puede proporcionar evidencia operativa o funcionalidad de comparación de origen a destino compatible.

• Ideal para: añadir evidencia específica de la plataforma al proceso de validación.
• Importante: comprenda con exactitud qué abarca la función para su origen y destino. No dé por sentado que la capacidad de comparación de plataformas garantiza la exactitud en todos los aspectos.

Validación a nivel empresarial: Para flujos de trabajo críticos, compruebe si los registros comerciales importantes, los totales, los eventos o los resultados tienen sentido después de la recuperación.

• Útil para: determinar si los datos son utilizables en el contexto relevante.
• No sustituye: la validación técnica cuando se requiere prueba técnica.

El enfoque más defendible suele ser la validación por capas: varias comprobaciones que responden a diferentes preguntas en lugar de una sola comprobación que pretende responder a todo.

Cómo detectar transacciones o cambios faltantes después de la recuperación de CDC

La pregunta que se hacen los usuarios es sencilla: "¿Cómo sabemos que no se nos pasó nada por alto?"

Comience con la ventana de recuperación. Luego compare lo que debería haber llegado al objetivo con lo que realmente llegó. Dependiendo del entorno, esto puede implicar examinar:

• Registros de origen afectados
• Claves de negocios de alto valor
• Actividad de cambio durante el intervalo
• Registros objetivo
• Diagnóstico de la plataforma
• Resultados de comparación de origen a destino respaldados
• Resultados posteriores

Fíjese especialmente en los datos que cambiaron mientras la replicación estaba interrumpida o se estaba poniendo al día.

Señales de alerta

• No se han registrado los datos esperados.
• Las actualizaciones previstas no se reflejan
• Los totales posteriores ya no cuadran.
• Las excepciones de la plataforma o del destino siguen sin explicación.

No se pueden contabilizar determinadas transacciones de alto valor.

No extienda la conclusión más allá de la evidencia. Si validó un subconjunto definido de tablas o un período de recuperación específico, menciónelo. Una declaración justificable sería: «Validamos los conjuntos de datos afectados y el período de recuperación mediante estas comprobaciones y no encontramos discrepancias inexplicables».

Eso es más contundente que hacer una afirmación absoluta que las pruebas no pueden respaldar.

Cómo identificar cambios duplicados o reprocesados ​​después de reiniciar la canalización

Un reinicio o una recuperación pueden generar dudas sobre si el trabajo se procesó más de una vez. El comportamiento exacto de reintento y duplicación depende de la plataforma de replicación, el origen, el destino y la configuración.

No dé por sentado que existe una garantía de entrega universal. En su lugar, identifique dónde se observarían aplicaciones duplicadas o repetidas en su entorno. Algunos indicadores potenciales son:

• Registros adicionales inesperados
• Claves comerciales duplicadas
• Errores de restricción del objetivo
• Recuentos inconsistentes
• Eventos empresariales repetidos
• Errores o diagnósticos de la plataforma
• Anomalías a nivel de aplicación

En el caso de conjuntos de datos sin restricciones de unicidad natural, puede resultar más difícil detectar duplicados.

Por eso, los equipos deben comprender qué claves o reglas de negocio hacen que la duplicación sea visible antes de que ocurra el incidente.

Cómo detectar eliminaciones faltantes después de la recuperación de CDC

Las eliminaciones merecen una revisión aparte, ya que son fáciles de pasar por alto. Un destino puede contener todos los registros esperados y aun así presentar errores, pues incluye registros que ya no deberían existir. El lenguaje técnico para este problema es muy directo: «Los registros que se eliminaron del origen siguen estando en el destino».

Cuando se produjeron eliminaciones durante el período de recuperación, verifique que el estado de destino correspondiente las refleje adecuadamente. Dependiendo del modelo de datos, esto puede implicar:

• Comprobando las claves de negocio afectadas
• Comparación de la presencia de la fuente y del objetivo
• Revisión de los resultados de la comparación de plataformas compatibles
• Validar el comportamiento posterior donde los registros eliminados son importantes

No dé por sentado que una comparación de recuento exitosa siempre revelará las eliminaciones faltantes.

Cómo identificar valores obsoletos o incorrectos

A veces, el registro está presente en ambos lados. El problema es que el destinatario tiene la versión incorrecta. Busque:

• Valores que no coinciden con la fuente en el punto de comparación previsto.
• Actualizaciones de la ventana de recuperación que no se reflejan
• Resultados posteriores utilizando un valor anterior
• Diferencias que no pueden explicarse por la sincronización normal o la transformación.

Esto es importante porque una simple comprobación de existencia puede pasar incluso cuando el objetivo aún está obsoleto.

La pregunta no es solo: "¿Existe el registro?", sino: "¿Está el registro en el estado en que esperamos que esté?".

Cómo identificar cambios fuera de orden después de la recuperación de los CDC

El orden es más importante en algunas cargas de trabajo que en otras. Si el resultado del negocio depende de la secuencia, la comparación del estado final puede no responder a todas las preguntas. En esos casos, los equipos pueden necesitar evidencia adicional apropiada para:

• La fuente
• El objetivo
• La arquitectura de replicación
• El patrón de transacción afectado
• El requisito de pedido específico

No dé por sentado que una suma de verificación o la coincidencia del estado final de la fila demuestran el orden histórico. Del mismo modo, no dé por sentado que cada carga de trabajo requiere una validación de secuencia transacción por transacción.

El estándar correcto es: validar el comportamiento de pedido que realmente importa para el proceso de negocio y la arquitectura afectados.

Investiga las discrepancias; no las minimices.

Si una comprobación de validación detecta alguna diferencia, considérelo como evidencia para investigar.

Preguntar:

• ¿Se trata de una diferencia de tiempo prevista?
• ¿Hay transformación de por medio?
• ¿Se utilizaron estados de origen y destino equivalentes en la comparación?
• ¿El objetivo aún se está alcanzando?
• ¿Existe algún registro que falte sin explicación?
• ¿Hay algo presente que debería haberse eliminado?
• ¿Se procesó el cambio más de una vez?
• ¿Está obsoleto un valor?
• ¿La discrepancia es un caso aislado o forma parte de un patrón más amplio?

Luego, determine la remediación adecuada. Dependiendo del entorno, esto podría incluir:

• Corrección de un registro o conjunto de datos identificado
• Repetir un paso de validación
• Resincronizando los datos afectados
• Realizar una resincronización más amplia
• Restringir el uso posterior hasta que se comprenda el problema.

No permita que un gran número de comprobaciones satisfactorias oculte una discrepancia inexplicable en datos críticos para el negocio.

Crear un registro de evidencia posterior a la recuperación

El equipo que gestionó el incidente puede saber con exactitud lo que ocurrió hoy. Tres meses después, alguien más podría preguntar: "¿Cómo supimos que los datos eran seguros para volver a utilizarlos?".

No les obligue a reconstruir la respuesta de memoria. Cree un registro conciso de evidencia posterior a la recuperación que incluya:

Ventana de incidencias: ¿Cuándo se vio afectada la replicación?

Punto de recuperación: ¿Dónde se reanudó el procesamiento, utilizando la terminología adecuada para la fuente y la plataforma?

Ámbito afectado: ¿Qué fuentes, destinos, conjuntos de datos, tablas, archivos o procesos posteriores estuvieron involucrados?

Método de recuperación: ¿Qué ruta de recuperación se utilizó? Por ejemplo:

• Reiniciar desde el estado guardado
• Ponerse al día
• Resincronización dirigida
• Resincronización o recarga más amplia

Validación realizada: ¿Qué comprobaciones se realizaron? Para cada comprobación importante, registre lo siguiente:

• Lo que se examinó
• ¿Qué período o alcance se cubrió?
• Lo que el cheque pretendía establecer

Hallazgos: ¿Qué observó el equipo? ¿Se encontraron discrepancias?

Corrección: ¿Qué se corrigió, reprocesó o resincronizó?

Excepciones: ¿Qué queda sin resolver o fuera del alcance validado?

Conclusión: ¿Qué pruebas respaldan la decisión de que los datos posteriores relevantes están listos para su uso?

Ese registro puede respaldar:

• Revisión de incidentes
• Transferencia de operaciones
• Comunicación descendente
• Gobernancia
• Auditoría
• Solución de problemas futuros
• Mejora del manual de procedimientos de recuperación

¿Quién da la señal de que todo está bien?

Esta es una cuestión operativa que los equipos suelen dejar sin definir hasta que la presión es máxima. Alguien tiene que decidir si los datos están listos para usarse de nuevo. Esa decisión puede involucrar a más personas que solo a quien reinició el proceso. Dependiendo del incidente, puede requerir la participación de:

• El equipo de replicación o ingeniería de datos
• El propietario del sistema de origen
• El propietario de la plataforma o aplicación descendente
• operaciones de datos
• Un empresario
• Gobernanza, riesgo u otra función de control

El proceso exacto de aprobación debe reflejar la importancia de los datos afectados.

Principio clave: El equipo técnico debe ser capaz de explicar:

• Lo que se vio afectado
• ¿Qué fue validado?
• Lo que establecen los controles
• Lo que sigue siendo incierto
• ¿Qué excepciones aún existen?

De esta forma, las personas responsables del uso posterior del producto podrán tomar una decisión informada.

¿Cómo se les comunica a los equipos posteriores que los datos ya están listos de nuevo?

Evita los extremos. No digas que todo está bien si las pruebas no respaldan esa afirmación.

Pero tampoco le abrumes con un registro de incidentes técnicos a un responsable de negocio. Comunica cuatro cosas con claridad:

• Lo que sucedió: La replicación se interrumpió o se retrasó durante un período definido.
• ¿Qué se vio afectado?: Identifique los datos o sistemas posteriores relevantes.
• ¿Qué se validó?: Explique el alcance de las comprobaciones realizadas.
• Lo que queda pendiente: Indique cualquier excepción, limitación o trabajo de seguimiento que quede por hacer.

El mensaje más útil suena así:

La replicación se ha completado. Validamos los datos afectados para el período del incidente utilizando las comprobaciones descritas aquí. No encontramos diferencias inexplicables; estas diferencias identificadas fueron corregidas. Estos conjuntos de datos posteriores están listos para su uso. Las excepciones, si las hubiera, permanecen abiertas.

El lenguaje utilizado debe coincidir con las pruebas. Así es como se reconstruye la confianza sin pretender que la incertidumbre no existe.

Un oleoducto verde no es una estrategia de validación.

El error recurrente tras una recuperación es quedarse en el estado operativo: El proceso se está ejecutando. La latencia ha vuelto a la normalidad. El panel de control está en verde.

Todos quieren finalizar la llamada de conexión. Pero ninguna de esas señales, por sí sola, permite determinar si los datos del objetivo afectado son correctos.

La pregunta crucial que debemos responder es: "¿En qué pruebas nos basamos cuando les decimos a las personas que pueden volver a confiar en estos datos?"

Si la respuesta no es clara, el incidente no ha terminado.

Cómo evaluar las capacidades de validación posteriores a la recuperación

No todas las plataformas de los CDC proporcionan el mismo nivel de evidencia tras una interrupción. Algunas funcionalidades son requisitos básicos. Otras pueden reducir significativamente el esfuerzo, la incertidumbre y el riesgo que implica demostrar que la recuperación ha sido exitosa.

Requisitos básicos

Todas las plataformas CDC empresariales deben proporcionar:

• Información de reinicio o estado del proceso
• Estado operativo y seguimiento
• Información de error y diagnóstico
• Visibilidad de la actividad de recuperación
• Procedimientos básicos de recuperación para entornos compatibles

Estas capacidades ayudan a los equipos a responder: ¿Se recuperó la replicación y se reanudó el procesamiento?

La pregunta más difícil es: ¿Podemos demostrar que los datos recuperados son fiables?

Capacidades importantes que no siempre están incluidas

• Funcionalidad de comparación entre origen y destino
• Visibilidad de la posición de recuperación y el historial de procesamiento
• Apoyo para la recuperación histórica cuando se dispone de información histórica.
• Diagnósticos significativos que apoyen la investigación de la causa raíz
• Evidencia de inspección y validación del estado de recuperación
• Visibilidad de las discrepancias descubiertas durante la conciliación.
• Soporte para validar grandes conjuntos de datos de manera eficiente.
• Documentación e informes que respalden los requisitos de auditoría, gobernanza o aprobación posterior.

Estas capacidades determinan la cantidad de investigación manual necesaria antes de que los equipos puedan declarar con seguridad que la recuperación se ha completado. Ninguna función por sí sola debe considerarse una prueba universal de que la recuperación fue exitosa. La pregunta clave es: "¿Qué evidencia proporcionará esta plataforma a nuestro equipo después de un evento de recuperación y qué validación adicional necesitaremos?".

Preguntas que debe hacer a cada proveedor de los CDC

Pídale al proveedor que haga una demostración:

• ¿Qué estado de reinicio o proceso se observa después de una interrupción?
• ¿Qué información de monitorización y diagnóstico pueden consultar los operadores?
• ¿Cómo permite la plataforma recuperar el tiempo perdido tras una interrupción?
• ¿Qué capacidades de comparación entre origen y destino están disponibles?
• ¿Qué diferencias pueden identificar realmente esas capacidades de comparación?
• ¿Cuáles son los límites de esas capacidades?
• ¿Cómo encajan esas capacidades en un proceso de validación más amplio?
• ¿Qué pruebas pueden conservar los equipos para respaldar una decisión de que todo está bien?

El estándar debe ser el mismo para todas las plataformas de CDC: no acepte "el proceso se reinició" como prueba. Pregunte qué pueden inspeccionar, comparar, probar y justificar los operadores posteriormente.

Cómo encaja Rocket Data Replicate & Sync

Rocket Data Replicate & Sync (RDRS) incluye funcionalidades que pueden contribuir a la investigación y validación posteriores a la recuperación para las configuraciones compatibles.

Las capacidades documentadas de RDRS incluyen:

• Estado de reinicio y proceso guardado
• Información de monitorización y diagnóstico
• Funcionalidad de comparación por lotes para fuentes compatibles.
• Compatibilidad con el procesamiento de registros archivados para entornos basados ​​en registros compatibles donde el historial requerido permanece disponible.

Estas capacidades pueden proporcionar evidencia operativa y de validación durante una investigación de recuperación. Al igual que con cualquier plataforma de los CDC, las organizaciones deben evaluar RDRS en función de sus fuentes, objetivos, configuraciones, requisitos de recuperación y procedimientos operativos específicos. La pregunta más importante es: "¿Qué evidencia puede proporcionar RDRS en los escenarios de recuperación a los que nuestro entorno tiene más probabilidades de enfrentarse?".

Lista de verificación de validación posterior a la recuperación

Antes de informar a los usuarios posteriores que los datos están listos nuevamente, confirme:

• El periodo de recuperación está claramente definido.
• Se conocen las fuentes, los objetivos y los consumidores finales afectados.
• Se ha eliminado el retraso o se comprende el estado restante.
• Se han revisado las fuentes pertinentes, las plataformas de replicación y las evidencias objetivo.
• La validación fue más allá del simple estado del proceso.
• Las comprobaciones generales, como los recuentos o los totales, no se consideraban una prueba universal.
• Se compararon los registros, valores o claves comerciales importantes cuando fue pertinente.
• Se tuvieron en cuenta los cambios faltantes.
• Se tuvieron en cuenta los cambios duplicados o repetidos cuando fue pertinente.
• Se tuvieron en cuenta las eliminaciones que se produjeron durante el período de recuperación.
• Se tuvieron en cuenta valores obsoletos o incorrectos.
• Se evaluó el ordenamiento cuando la secuencia importaba.
• Se investigaron las discrepancias inexplicables.
• Cualquier medida correctiva o de resincronización quedó documentada.
• Las excepciones restantes son explícitas.
• Los propietarios de las zonas de consumo saben qué es seguro utilizar.
• Se han registrado las pruebas que justifican la declaración de que todo está bien.

En resumen

Poner en marcha de nuevo el proceso es solo la mitad de la recuperación. La pregunta más difícil es: "¿Cómo demostramos que los datos son correctos?".

Comience por definir el período de recuperación. Comprenda qué se vio afectado. Utilice evidencia del origen, la plataforma de replicación, el destino y el entorno posterior. Busque deliberadamente cambios faltantes, duplicados, eliminaciones faltantes, valores obsoletos y problemas de ordenación donde sean relevantes. Investigue las discrepancias en lugar de asumir que son inofensivas. Y deje suficiente evidencia para que alguien que no participó en la llamada de incidente pueda comprender por qué se autorizó el uso del destino.

Porque:

Volver a correr no es lo mismo que estar recuperado.
Y que un oleoducto sea ecológico no significa que los datos sean fiables.

La recuperación se considera completa cuando el proceso es estable y la organización cuenta con pruebas suficientes para volver a confiar en los datos.

*NIST SP 1800-26: Integridad de los datos, detección y respuesta a eventos destructivos

A continuación: ¿Su plataforma actual es lo suficientemente buena para la recuperación?

Si la recuperación depende repetidamente de la validación manual, el conocimiento tácito, la investigación entre equipos o la incertidumbre sobre lo que sucedió durante el lapso, la siguiente pregunta puede ser más importante que el incidente en sí.

Cómo evaluar las capacidades de recuperación de CDC empresariales cuando la pérdida de datos es inaceptable.

Utilice el marco de evaluación para definir qué debe hacer visible, comprobable y demostrable su plataforma antes de que se produzca el próximo fallo.