¿Cómo saber si las reclamaciones de recuperación de un proveedor de los CDC se sostendrán?

Pruebe el estado de reinicio, la recuperación, la validación, el comportamiento de reproducción, los diagnósticos y los límites de recuperación antes de elegir una plataforma CDC.

La mayoría de las demostraciones de los CDC muestran que el proceso funciona según lo previsto. Los datos se mueven. El objetivo se actualiza. El panel de control permanece en verde. Pero una evaluación de recuperación de los CDC debe poner a prueba una cuestión diferente:

¿Qué sucede cuando el camino se rompe?

La guía AWS Well-Architected recomienda probar la resiliencia en condiciones adversas en entornos lo más parecidos posible al de producción. Advierte sobre los riesgos de diseñar para la resiliencia sin verificar cómo se comporta la carga de trabajo cuando se producen fallos y cargas inesperadas.*

Una prueba de concepto de plataforma, o POC, ofrece a su equipo la oportunidad de observar cómo se comporta el sistema cuando la replicación se retrasa, se detiene durante el procesamiento activo, pierde el acceso inmediato al historial de origen necesario o debe demostrar que el destino recuperado es correcto.

El objetivo no es crear un fallo artificial que nunca ocurriría en un entorno de producción, sino evaluar si la plataforma permite visualizar, comprobar y defender la recuperación en condiciones que reflejen su entorno real.

Respuesta rápida: ¿Cómo se debe evaluar la recuperación del CDC durante una prueba en el punto de atención?

Un diagnóstico práctico de recuperación de los CDC debería evaluar ocho áreas:

1. Visibilidad de retrasos y tareas pendientes
2. Visibilidad del estado de reinicio y recuperación
3. Puesta al día histórica
4. Progreso de recuperación y estancamiento de la misma
5. Diagnóstico y evidencia de falla
6. Validación posterior a la recuperación
7. Reproducción e impacto en el consumidor final
8. Límites de recuperación y límites de resincronización

Para cada prueba, pregúntese qué condición se introdujo, qué pudieron observar los operadores, qué estado conservó la plataforma, qué sucedió durante la recuperación, qué evidencia quedó después y qué no pudo determinar la plataforma. Cada conclusión debe estar vinculada al origen, el destino, la topología, la versión, la configuración y el escenario de falla probados.

El criterio es sencillo: Muéstranos qué sucede cuando la ruta se interrumpe. Luego, muéstranos cómo sabríamos que la recuperación fue exitosa.

Antes de la prueba de concepto: comience con las brechas que necesita probar.

Llegar a esta etapa significa que probablemente ya haya determinado que la recuperación merece una evaluación más exhaustiva. No repita toda la evaluación de preparación dentro del POC. En su lugar, incorpore las deficiencias documentadas en el entorno actual al plan de pruebas.

Si esas deficiencias no se han documentado, comience con ¿Cuándo un problema de recuperación de CDC se convierte en un problema de plataforma ? Y documente las deficiencias de recuperación en el entorno actual antes de definir la prueba de concepto.

A continuación, defina el entorno que se pretende representar con la prueba de concepto. Como mínimo, documente lo siguiente:

• Tecnologías y versiones de origen y destino
• Capturar y aplicar métodos
• Topología de replicación
• Tasas de transacción normales y máximas
• Políticas de registro de origen, diario o historial retenido
• Condiciones de la red y del objetivo
• Requisitos de transformación y cambio de esquema compatibles
• Objetivos de recuperación y escenarios inaceptables de recarga o resincronización.
• Consumidores finales, sensibilidad a la reproducción y dependencias comerciales.

Una demostración genérica proporciona evidencia limitada.

La pregunta importante no es: ¿La plataforma admite la recuperación? Sino: ¿Cómo funciona la recuperación para nuestro origen, destino, configuración, carga de trabajo y requisitos operativos?

De las capacidades a la evidencia

Los nombres de las capacidades no son prueba suficiente. Las pruebas que se describen a continuación llevan la conversación de "¿Apoyas esto?" a "Muéstranos cómo funciona cuando sea necesario recuperarlo".

Prueba de concepto 1: Hacer que la replicación se retrase.

Cree una condición controlada en la que la replicación permanezca activa, pero no pueda seguir el ritmo de la actividad de la fuente. El objetivo es determinar si los operadores pueden distinguir entre el funcionamiento normal, el retraso creciente, la recuperación progresiva y la recuperación estancada.

Solicite al proveedor que demuestre la magnitud del retraso, el tamaño y la dirección de la acumulación de datos pendientes, dónde se produce la demora, si el procesamiento está avanzando y qué sucede con la exposición del historial de origen a medida que aumenta la brecha.

Lo que demuestra una fuerte manifestación.

Tanto la magnitud como la dirección del problema son visibles. Los operadores no tienen que deducir el progreso de la recuperación a partir de un indicador de estado verde. Pueden saber cuánto retraso existe con respecto al objetivo, dónde se produce la demora y si las condiciones están mejorando.

Prueba de concepto 2: Detener la replicación durante el procesamiento activo.

Introduzca una interrupción segura y controlada mientras las transacciones se estén procesando activamente. Un apagado limpio puede demostrar el comportamiento normal de reinicio, pero es posible que no muestre lo que sucede durante una terminación abrupta, una interrupción de la red, una falla del dispositivo u otro evento realista.

Solicite al proveedor que muestre qué estado de reinicio o proceso se conservó, qué significa cada marcador, dónde se espera que se reanude el procesamiento, qué límite de transacción se aplica y si el trabajo se puede volver a intentar o reprocesar.

Lo que demuestra una fuerte manifestación.

Los operadores pueden inspeccionar el estado correspondiente antes del reinicio y comprender qué hará la plataforma. El proveedor puede distinguir entre el estado de captura de origen, procesamiento, transporte y aplicación en el destino, según corresponda.

Prueba de concepto 3: Prueba de soporte de recuperación histórica

Para la gestión de cambios basada en registros, los cambios acumulados pueden depender de registros activos, registros archivados, diarios u otro historial de origen conservado. Pruebe la cadena de dependencias según el modelo de retención que utilizará su entorno de producción.

Solicite al proveedor que explique qué historial se requiere, dónde reside, quién controla la retención, cómo se recupera, si la plataforma puede procesarlo directamente y dónde finaliza el límite de recuperación admitido.

Lo que demuestra una fuerte manifestación.

El proveedor muestra cómo la plataforma localiza y procesa el historial necesario y qué pueden supervisar los operadores. La respuesta es específica para la fuente y la configuración, no una afirmación genérica de que se admite la recuperación de registros archivados.

Prueba de concepto 4: Crear una recuperación estancada

Inicie la recuperación y, a continuación, restrinja las condiciones de origen, red, aplicación o destino para que la brecha existente deje de reducirse o aumente. Esto permite comprobar si la plataforma distingue la actividad del progreso real.

Solicite al proveedor que muestre la dirección de la cartera de pedidos pendientes, las tasas actuales de procesamiento y aplicación, el avance de la posición, los reintentos o la limitación de velocidad, el impacto en la fuente y el destino, y la base de cualquier estimación de finalización.

Lo que demuestra una fuerte manifestación.

El progreso y el estancamiento en la recuperación presentan diferencias significativas. Los operadores pueden observar si la brecha se está reduciendo, se mantiene estable o está empeorando, y las estimaciones de finalización se basan en las condiciones observadas, en lugar del rendimiento teórico.

Prueba de punto de atención 5: Preservar e investigar las evidencias de fallas

Provoca un fallo representativo de la fuente, la red, la replicación o el destino, y evalúa qué evidencia queda disponible antes y después del reinicio.

Solicite al proveedor que demuestre cómo los operadores investigan el fallo, cómo se correlacionan el contexto de procesamiento y los errores, cuánto tiempo se conserva la evidencia, qué se puede exportar y qué evidencia adicional de origen, red o destino aún se requiere.

Lo que demuestra una fuerte manifestación.

Los operadores pueden determinar qué estaba procesando la canalización, cómo varió el retardo o el rendimiento, qué componente generó el error, en qué estado se encontraba posteriormente y qué acción de recuperación se aplicó. La información útil no desaparece silenciosamente cuando se reinicia el proceso.

Prueba de concepto 6: Validar el objetivo recuperado

Un reinicio exitoso demuestra que la replicación se reanudó. No demuestra que el destino esté completo, actualizado y correcto. Se recomienda introducir discrepancias conocidas cuando sea práctico y seguro, como una inserción o actualización faltante, un registro inesperado, un duplicado, una eliminación faltante, un valor obsoleto, una diferencia de transformación o un problema de ordenación donde la secuencia importa.

Solicite al proveedor que demuestre cómo se identifican las diferencias entre el origen y el destino, qué objetos o ventanas de incidentes se pueden delimitar, qué claves y valores se comparan, cómo se presentan las discrepancias y qué validación adicional sigue siendo responsabilidad del equipo operativo.

Lo que demuestra una fuerte manifestación.

La plataforma identifica diferencias específicas y explica claramente qué demuestra y qué no demuestra la comparación. Un recuento de filas coincidente o un proceso completado no se presentan como prueba universal de integridad.

Prueba POC 7: Reproducción de la prueba e impacto en el consumidor final.

Acumula los cambios durante una interrupción y procésalos durante la recuperación. Incluye tipos de eventos sensibles a la reproducción cuando sea seguro hacerlo. La reproducción no es automáticamente un problema, pero una reproducción invisible o mal comprendida sí puede serlo.

Solicite al proveedor que muestre la ventana de reproducción, los registros o tipos de eventos afectados, el volumen y la tasa esperados, el comportamiento de reintento o procesamiento repetido, las consideraciones de ordenación y las pruebas que quedan después de la recuperación.

Por qué importa la idempotencia

Una plataforma de replicación no puede hacer que una aplicación de pago, notificación, inventario o flujo de trabajo sea idempotente. Puede proporcionar suficiente información para que los equipos posteriores decidan si se requiere supresión, deduplicación, secuenciación o activación coordinada.

Lo que demuestra una fuerte manifestación.

La reproducción es visible y atribuible. Los equipos posteriores pueden estimar qué llegará y cuándo, comprender si puede haber un procesamiento repetido y evaluar si se requieren medidas de seguridad del lado del consumidor.

Prueba POC 8: Demostrar el límite de recuperación

Cada plataforma CDC presenta situaciones en las que reiniciar o ponerse al día no es la solución adecuada. Puede ser necesaria una resincronización selectiva, una resincronización más amplia o una recarga completa cuando el estado de recuperación no está disponible, no se puede procesar el historial de origen necesario, el destino es inconsistente, se produjeron cambios no compatibles o la validación revela discrepancias importantes.

Solicite al proveedor que explique qué escenarios admiten el reinicio, la recuperación del historial, la resincronización selectiva, la resincronización más amplia o la recarga, y qué pruebas indican a los operadores que la ruta de recuperación normal ya no es aplicable.

Lo que demuestra una fuerte manifestación.

La respuesta es específica, cualificada y vinculada al entorno propuesto. Un límite de recuperación honesto es señal de madurez, no de debilidad.

Documentar lo que realmente demostró la persona de color.

Una prueba de concepto rigurosa debe ir más allá de capturas de pantalla, notas de reuniones y una declaración de que la prueba fue exitosa. Para cada escenario, registre las condiciones de la prueba, la evidencia observada, el resultado de la recuperación, la evaluación, las limitaciones y el seguimiento requerido.

El objetivo no es asignar una puntuación de recuperación genérica, sino determinar si la plataforma demostró las capacidades que su entorno requiere bajo las condiciones de prueba.

Utilice la Hoja de evaluación del punto de atención de recuperación de los CDC . Esta hoja de trabajo es el registro de trabajo para la evaluación. Úsela para:

• Defina la fuente, el destino, la topología, la carga de trabajo, el modelo de retención y los objetivos de recuperación.
• Planifique los ocho escenarios de recuperación.
• Capturar el comportamiento observable y la evidencia retenida
• Capacidades de velocidad según lo demostrado, parcialmente demostrado, no demostrado o no aplicable
• Limitaciones del documento, dependencias y preguntas abiertas
• Compare proveedores solo en condiciones equivalentes.
• Fundamente la recomendación final con evidencia.

Una capacidad no debe marcarse como demostrada basándose únicamente en la documentación del producto, el material de presentación o una explicación verbal. La calificación debe reflejar el comportamiento observable y la evidencia conservada de la configuración probada.

¿Podría nuestro equipo operativo habitual utilizar las pruebas aquí presentadas para comprender el fallo, gestionar la recuperación y confirmar que todo está correcto sin depender por completo del proveedor o de un único especialista interno?

Errores comunes en las pruebas de diagnóstico rápido (POC) de los CDC

Probar únicamente el escenario ideal: Una carga inicial exitosa y una prueba de replicación en estado estable establecen la funcionalidad básica. No establecen el comportamiento de recuperación. Incluir escenarios de retardo controlado, interrupción, puesta al día, validación y límites de recuperación.

Utilizar únicamente apagados limpios: Los apagados limpios pueden no presentar el mismo comportamiento de estado de reinicio, transacción, diagnóstico o reintento que las interrupciones abruptas. Pruebe las condiciones de fallo admitidas que reflejen un riesgo de producción realista.

Se aceptan etiquetas sin definiciones: términos como "exactamente una vez", "cero pérdida de datos", "autorreparación", "recuperación automática", "sincronización sin interrupciones" y "validación integrada" pueden describir comportamientos diferentes en distintas plataformas. Se requiere una definición vinculada a la configuración probada y al escenario de fallo.

Considerar el estado del proceso como evidencia de recuperación: Que esté en ejecución no significa que se haya recuperado. Que se haya recuperado no significa que esté validado. Que esté validado dentro de un ámbito no demuestra que sea correcto en todas sus dimensiones.

No introducir discrepancias conocidas: Si todas las pruebas comienzan y terminan con datos correctos, la prueba de concepto no permite determinar qué puede detectar la plataforma cuando algo falla. Incluya datos faltantes, inesperados, eliminados, obsoletos o repetidos siempre que sea posible.

Ignorar el comportamiento posterior: La recuperación no se detiene en la tabla de destino. Los cambios retrasados ​​y reproducidos pueden activar aplicaciones, eventos, notificaciones, pagos, flujos de trabajo o decisiones posteriores.

No documentar lo que no se demostró: Una pregunta sin respuesta no debe convertirse tácitamente en una capacidad asumida. Regístrela como:

Ponga a prueba las reclamaciones de indemnización.

Una prueba de concepto de CDC debe demostrar algo más que una replicación exitosa en condiciones normales. Debe mostrar qué ven los operadores cuando la canalización se retrasa, qué estado de recuperación queda después de un fallo, dónde se puede reanudar el procesamiento, de qué depende la recuperación histórica, cómo se mide el progreso de la recuperación, qué evidencia de diagnóstico se conserva, cómo se valida el objetivo, qué significa la reproducción para los consumidores posteriores y dónde termina la ruta de recuperación compatible.

Aplique las mismas pruebas a todas las plataformas, incluida la que ya está en funcionamiento en su entorno. La capacidad de recuperación no debe darse por sentada a partir del nombre de una función o una demostración impecable. Debe establecerse mediante un comportamiento observable y evidencia documentada.

Muéstranos qué sucede cuando el camino se rompe. Luego, muéstranos cómo sabríamos que la recuperación fue exitosa.
 

*AWS Well-Architected: Prueba de resiliencia mediante ingeniería del caos, noviembre de 2024