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

Un oleoducto de los CDC no tiene por qué fallar para generar riesgos.

A veces, la replicación sigue en curso. El estado del proceso es verde. El destino sigue disponible. Pero la cola de tareas pendientes está creciendo.

El objetivo se está quedando obsoleto. Y con cada minuto que el proceso se retrasa, las opciones de recuperación se vuelven más limitadas. La pregunta no es simplemente: "¿Está funcionando la replicación?", sino: "¿Está la replicación al día?".

Y si no lo es: "¿Cuánto tiempo tenemos antes de que esto se convierta en un problema de recuperación?"

El sistema de monitoreo más eficaz de los CDC no solo informa a los operadores si un proceso está funcionando correctamente o no, sino que también les ayuda a reconocer cuándo un oleoducto aparentemente saludable se está deteriorando gradualmente y será más difícil recuperarse posteriormente.

Un buen sistema de monitoreo ayuda a los equipos a responder:

• ¿A cuánto retraso nos encontramos?
• ¿Está aumentando o disminuyendo la acumulación de pedidos?
• ¿Está realmente avanzando el proyecto del oleoducto?
• ¿Los equipos posteriores ya están utilizando datos obsoletos?
• ¿Seguimos teniendo claro cuáles son nuestras opciones de recuperación si la situación empeora?

El objetivo no es predecir todos los fallos, sino reconocer los problemas incipientes con la suficiente antelación para que el equipo aún tenga opciones.

Dependiendo de la plataforma de origen y replicación, la monitorización eficaz de CDC puede incluir métricas y conceptos como el retraso de replicación, el crecimiento de la cola de cambios, el retraso de aplicación en origen y destino, el estado de reinicio, la posición del registro, el historial de cambios retenidos, los registros archivados, la progresión de RBA/LRSN, el comportamiento de recuperación y la exposición de datos posteriores. La terminología exacta varía, pero el objetivo siempre es el mismo: comprender si la replicación se mantiene al día y si la recuperación sigue siendo sencilla en caso de que las condiciones se deterioren.

¿Cómo puedo detectar que un proceso CDC se está quedando obsoleto antes de que falle?

Un proceso puede estar en funcionamiento mientras aumenta la latencia, crece la acumulación de tareas pendientes y los datos posteriores se vuelven obsoletos.

Respuesta rápida: Comience respondiendo cinco preguntas operativas:

1. ¿A cuánto retraso nos encontramos?
2. ¿La acumulación de pedidos pendientes está creciendo, se mantiene estable o está disminuyendo?
3. ¿Seguimos teniendo el historial de origen que podríamos necesitar si fuera necesaria una recuperación?
4. ¿Está realmente avanzando el proyecto del oleoducto?
5. ¿Quiénes ya se basan en los datos de los canales posteriores y hay algo que nos indique que la situación está empeorando?

Las métricas y los umbrales de alerta exactos dependen del origen, el destino, la plataforma de replicación, la carga de trabajo, los requisitos de recuperación y el caso de uso posterior. No existe un número universal de minutos, registros o espacio de registro que defina una emergencia de los CDC.

Un oleoducto puede indicar "En funcionamiento" y aun así estar encaminándose hacia un problema de recuperación.

El monitoreo debe responder a dos preguntas diferentes.

1. ¿El flujo de proyectos se encuentra en buen estado actualmente?

Esta es la pregunta operativa inmediata. ¿Es la replicación:

• ¿Sigues el ritmo?
• ¿Te estás quedando atrás?
• ¿Atascado?
• ¿Recuperante?
• ¿Funciona en un estado degradado?

El estado del proceso es parte de la respuesta. No es la respuesta completa.

2. ¿Estamos perdiendo opciones de recuperación a medida que aumenta el retraso?

Esta es la pregunta más difícil. Un oleoducto puede seguir activo mientras:

• La acumulación de pedidos sigue creciendo.
• El objetivo se vuelve cada vez más obsoleto.
• Ponerse al día lleva más tiempo.
• Los equipos de procesamiento posterior siguen utilizando datos antiguos.
• Cambios en el historial de fuentes disponibles
• Un problema operativo relativamente controlado se convierte en un problema de recuperación mayor.

La pregunta más importante es: "¿Si la situación empeora a partir de ahora, seguiremos entendiendo cómo podríamos recuperarnos?"

1. ¿Cuánto retraso llevamos?

El retraso en la replicación indica cuánto se ha quedado el destino con respecto a la actividad actual de la fuente. Sin embargo, una cifra simple no siempre es suficiente. Un retraso de 100 000 cambios puede ser insignificante en un entorno y significativo en otro. Lo que los operadores suelen necesitar comprender es: "¿Qué significa este retraso en términos de tiempo e impacto en el negocio?" .

Métricas de retraso en la replicación de los CDC: qué medir y cómo interpretarlas

Las distintas plataformas muestran el retraso y el progreso de forma diferente. Dependiendo de la fuente, el destino y la tecnología de replicación, la monitorización útil puede incluir:

• retraso de replicación transcurrido
• retraso del lado de la fuente
• objetivo o aplicar retardo
• retraso en cambios o transacciones
• posición de origen frente a posición de procesamiento actual
• profundidad de la cola o de la tarea
• rendimiento
• última marca de tiempo de procesamiento exitoso
• tendencia de recuperación
• Información de estado y diagnóstico específica de la plataforma

Los nombres exactos de las métricas importan menos que si los operadores pueden responder:

• ¿A cuánto retraso nos encontramos?
• ¿Dónde está el retraso?
• ¿Está mejorando la situación?

Preguntar

• ¿A qué distancia se encuentra el objetivo?
• ¿Cuándo comenzó el retraso?
• ¿Es esto normal para este período de carga de trabajo?
• ¿Qué sistemas posteriores dependen de estos datos?
• ¿En qué momento les importa el retardo?

Por qué es importante

Un objetivo con un retraso de cinco minutos puede ser aceptable para una carga de trabajo e inaceptable para otra. La métrica técnica debe interpretarse en el contexto de los datos utilizados.

Qué aspecto tiene lo bueno

El equipo operativo puede decir: “Estamos aproximadamente a esta distancia de retraso, y esto es lo que eso significa para los sistemas que utilizan los datos”.

No se trata simplemente de: “La tarea sigue en curso”.

2. ¿La acumulación de pedidos pendientes está creciendo, se mantiene estable o está disminuyendo?

La dirección del retraso puede ser tan importante como su magnitud. Un proceso que está significativamente atrasado pero que se está recuperando rápidamente presenta una situación diferente a la de un proceso con un retraso menor que está perdiendo terreno de forma constante. Los profesionales suelen describirlo de forma muy sencilla: "¿Se está incendiando?".

Preguntar

• ¿Está aumentando la acumulación de pedidos?
• ¿Se ha estabilizado?
• ¿Se está encogiendo?
• ¿El sistema está funcionando al ritmo de la nueva actividad de las fuentes de datos?
• ¿El proceso es más rápido que la llegada de nuevo trabajo durante el período de recuperación?
• ¿Ha cambiado la tendencia desde que comenzó el incidente?

Tasa de captura frente a tasa de procesamiento o aplicación.

Cuando la plataforma expone las métricas adecuadas, comparar los cambios que ingresan al flujo de replicación con los que se procesan en el destino puede ayudar a determinar si el entorno está mejorando o empeorando. Las mediciones específicas varían según la plataforma. El principio es sencillo: si durante un período prolongado llega trabajo nuevo a un ritmo mayor del que la canalización puede procesarlo, la acumulación de trabajo pendiente seguirá creciendo aunque el proceso no se haya detenido.

Qué aspecto tiene lo bueno

Los operadores pueden distinguir rápidamente: quedarse atrás → mantenerse estable → ponerse al día

Bandera roja

El panel de control muestra el retraso actual, pero no si la situación está mejorando.

4. ¿Está progresando realmente el proyecto?

Un proceso puede seguir activo sin que los datos avancen de forma significativa.

Eso convierte la evidencia de una actividad de procesamiento exitosa en una importante prueba de coherencia.

Dependiendo de la plataforma, los equipos pueden considerar lo siguiente:

• actividad de replicación exitosa más reciente
• cambio procesado más reciente
• Aplicar al objetivo más reciente
• progreso en una posición guardada o estado de procesamiento
• movimiento de cartera de pedidos
• rendimiento
• otro indicador de progreso específico de la plataforma

Preguntar

¿Ha habido algún avance real?

Y luego:

¿Está avanzando al ritmo que cabría esperar para esta fuente y carga de trabajo?

La respuesta debe tener en cuenta el patrón de actividad normal del sistema.

Un entorno transaccional de alto volumen suele cambiar de forma continua.

Otra fuente puede tener períodos legítimos de poca o ninguna actividad.

Por qué es importante

Esto ayuda a identificar el estado incómodo en el que:

“Dice que está funcionando, pero no se mueve nada.”

Qué aspecto tiene lo bueno

El entorno de monitorización ayuda a distinguir:

La fuente es naturalmente silenciosa.

de

La replicación ha dejado de progresar.

Bandera roja

La única comprobación de estado es si existe el proceso de replicación.

5. ¿Quiénes ya están utilizando datos obsoletos?

Muchos problemas de los CDC comienzan como problemas técnicos y luego se convierten en problemas comerciales:

Es posible que la fuente siga funcionando correctamente. Es posible que el destino siga disponible. Es posible que la replicación siga en marcha. Sin embargo, es posible que los informes, los paneles de control, las API, los sistemas operativos y los entornos de análisis ya estén trabajando con datos cada vez más obsoletos.

Eso crea uno de los modos de fallo más peligrosos de los CDC: las pantallas están instaladas, pero los datos se están quedando obsoletos.

Preguntar

• ¿Qué aplicaciones dependen del objetivo afectado?
• ¿Qué informes o paneles de control lo utilizan?
• ¿Los análisis, las API, los sistemas operativos o las cargas de trabajo de IA siguen consumiendo los datos?
• ¿Alguien en la parte posterior del canal sabe que la información está desactualizada?
• ¿Se acerca algún período importante de informes, liquidación, procesamiento de lotes, atención al cliente o gestión operativa?
• ¿Debería suspenderse o restringirse algún uso posterior mientras se investiga el problema?

Por qué es importante

Varias cosas muy diferentes pueden ser ciertas al mismo tiempo:

• La fuente es saludable.
• El objetivo está disponible.
• El oleoducto está retrasado.
• La gente sigue utilizando el objetivo.

Eso puede dificultar la detección de la exposición a datos obsoletos en comparación con una interrupción limpia del servicio.

Qué aspecto tiene lo bueno

El equipo puede responder:

“Esto demuestra lo desactualizados que están los datos, estos son los consumidores afectados y estas personas conocen la situación actual.”

6. ¿Las advertencias, los errores o los eventos ambientales nos indican que algo está cambiando?

No todas las advertencias son una crisis.

Y las alertas que se generan con cada mensaje pueden crear tanto ruido que los operadores dejen de confiar en el sistema de monitorización.

El objetivo es identificar los acontecimientos relevantes en tu entorno e interpretarlos en su contexto.

Las señales útiles pueden incluir:

• errores de conectividad repetidos
• fallos de aplicación de destino
• reintentos
• cambios de autenticación o permisos
• cambios inusuales en el desfase
• mantenimiento de origen o destino
• mensajes de diagnóstico específicos de la plataforma

Observa el entorno que rodea al oleoducto.

Un cambio en el comportamiento de replicación que coincide con:

• un evento de Db2
• una IPL
• mantenimiento de infraestructura
• un cambio de red
• un cambio de seguridad
• una actualización de esquema o configuración
• un período de gran carga de trabajo

Puede que deba interpretarse de forma diferente a un evento de replicación aislado.

Esto no significa que el evento de origen haya sido necesariamente la causa del problema de los CDC.

Esto significa que los operadores deberían poder ver suficiente contexto para investigar la relación.

Qué aspecto tiene lo bueno

El equipo sabe:

• ¿Qué requiere acción inmediata?
• ¿Qué necesita investigación?
• lo que se puede observar
• cuando se justifica una escalada más amplia

Bandera roja

Cualquiera de los dos extremos:

Cada advertencia despierta a alguien.

or

Las advertencias se ignoran hasta que se detiene el proceso.

¿Cómo se deben configurar los umbrales de alerta de retraso de los CDC?

¿Cuánto retraso por parte de los CDC es demasiado?

No existe un umbral universal que funcione en todos los entornos CDC de mainframe.

Un umbral de alerta útil debería reflejar factores como:

• volumen de transacciones normal
• moneda de datos esperada
• tolerancia descendente para datos obsoletos
• disponibilidad del historial de fuentes
• objetivos de recuperación
• patrones de carga de trabajo
• tiempo de respuesta del equipo
• límites comerciales
• consecuencias de no responder

En lugar de copiar una regla genérica como por ejemplo:

“Alerta tras 30 minutos de retraso.”

preguntar:

“¿En qué momento esta situación comienza a amenazar la vigencia de los datos, los requisitos operativos o de recuperación que tenemos?”

Ese es el umbral que merece la pena tener en cuenta al diseñar.

Crea alertas basadas en decisiones, no solo en números.

Una alerta útil debería ayudar a alguien a decidir qué hacer a continuación.

Un modelo sencillo es:

Investigar

Algo se ha movido fuera del rango esperado del entorno.

Algunos ejemplos pueden ser:

• El retraso comienza a mostrar una tendencia al alza.
• El progreso del procesamiento se está ralentizando.
• advertencias repetidas
• cambios inexplicables en el rendimiento

La tarea inmediata es comprender el porqué.

Acto

Esta situación afecta de manera significativa a un requisito operativo o aumenta la complejidad de la recuperación.

Las acciones pueden incluir:

• investigar un cuello de botella objetivo
• examinar las condiciones de la fuente o de la infraestructura
• que involucra a un equipo adyacente
• revisar de qué información de origen depende la ruta de recuperación
• proteger a los usuarios posteriores de datos obsoletos
• preparándose para una recuperación controlada

Escalar

El problema ha excedido la autoridad operativa normal del equipo técnico o ha comenzado a afectar decisiones más amplias de negocio, riesgo o servicio.

Eso puede requerir la participación de:

• liderazgo en datos o plataformas
• operaciones de mainframe
• propietarios de sistemas aguas abajo
• partes interesadas del negocio
• gobernanza o riesgo
• gestión de incidentes

Los umbrales serán diferentes.

El proceso de decisión ya debería existir antes de que se active la alerta.

La prueba de observabilidad de dos minutos de los CDC: ¿Puede su equipo responder a estas cinco preguntas?

Un panel de control no es valioso por mostrar métricas, sino porque ayuda a los operadores a tomar decisiones. Prueba esto: ¿Puede un operador normal responder las siguientes cinco preguntas en menos de dos minutos sin consultar a un especialista de la plataforma?

Esto concuerda con las directrices operativas más amplias de Google Site Reliability Engineering, que considera la monitorización como una forma de evaluar el estado del servicio, diagnosticar problemas, identificar tendencias y comparar el comportamiento a lo largo del tiempo, y no simplemente recopilar o mostrar métricas.*

1. ¿Cuánto retraso llevamos?

¿Puede el operador identificar el retraso o la acumulación de tareas pendientes actual?

2. ¿Está mejorando o empeorando?

¿Pueden determinar si la acumulación de trabajo está creciendo, se mantiene estable o está disminuyendo drásticamente?

3. ¿El procesamiento realmente se está moviendo?

¿Pueden identificar la actividad reciente exitosa en lugar de basarse en un estado genérico de "En ejecución"?

4. Si esto se convierte en un evento de recuperación, ¿entendemos de qué depende la recuperación?

¿Pueden determinar qué historial de fuentes, estado u otra información sería relevante?

5. ¿Quiénes ya se ven afectados?

¿Pueden identificar qué sistemas o equipos posteriores podrían estar utilizando datos obsoletos?

Si el operador no puede responder a esas cinco preguntas en aproximadamente dos minutos, pregunte:

• ¿Qué información falta?
• ¿Qué está disperso entre demasiadas herramientas?
• ¿Qué requiere interpretación especializada?
• ¿Qué contexto existe solo en la cabeza de alguien?
• ¿Qué procedimiento de monitorización u operación debe modificarse?
• El encuadre de dos minutos es una heurística operativa práctica, no un referente del sector.
• Lo que importa es el principio:

La persona que responda al incidente debe ser capaz de comprender la situación con la suficiente rapidez para poder actuar.

Un sistema de monitorización que solo un especialista en la plataforma puede interpretar no es suficiente para una cadena de producción crítica desde el punto de vista operativo.

Cómo monitorear la recuperación de los CDC después de una interrupción

¿Cómo saber si los CDC realmente se están poniendo al día? El monitoreo no se detiene una vez que se reinicia el proceso. Durante la fase de recuperación, pregunte:

• ¿Se está reduciendo la lista de espera?
• ¿Con qué rapidez se está reduciendo?
• ¿Sigue llegando nueva actividad de la fuente?
• ¿El procesamiento se mantiene al ritmo de la nueva actividad al tiempo que se reduce la brecha?
• ¿Se están produciendo errores o reintentos?
• ¿Qué impacto está teniendo la recuperación económica en la fuente y el destino?
• ¿Los sistemas posteriores siguen trabajando con datos obsoletos?
• ¿Qué pruebas nos indicarán que la recuperación se ha completado realmente?

La distinción importante es:

Corriendo de nuevo

versus

alcanzado

versus

recuperado y validado.

No son necesariamente el mismo estado.

Los patrones de carga de trabajo de los sistemas centrales pueden cambiar lo que se considera "normal".

Los entornos de mainframe suelen tener períodos operativos diferenciados:

• procesamiento en línea máximo
• lote nocturno
• fin de día
• fin de mes
• cierre financiero
• picos estacionales
• mantenimiento programado

Un desfase que es normal en un período puede indicar un problema en otro.

• Lo mismo ocurre con:
• carga de trabajo de origen
• registrar o cambiar volumen
• presión objetivo
• capacidad de recuperación disponible
• contención de infraestructura

Evite definir "saludable" a partir de un único número promedio.

Supervise el proceso en función de la carga de trabajo que soporta.

Cuando el sistema de monitorización detecta un problema: ¿Qué debería ocurrir primero?

La monitorización proporciona a los equipos algo que, tarde o temprano, se agota en cualquier esfuerzo de recuperación: tiempo.

Cuanto antes se identifique un problema incipiente, mayor será el número de opciones de recuperación disponibles.

Confirma lo que realmente está sucediendo.

¿La afección es transitoria o permanente?

¿En qué punto de la ruta de replicación se ralentiza o se detiene el progreso?

Establecer el cronograma

¿Desde cuándo ocurre esto?

¿Cuándo se confirmó la última actividad exitosa?

Comprender el atraso

¿Cuánto te has quedado atrás?

¿Está creciendo o se está quemando?

Identificar la exposición aguas abajo

¿Quiénes ya confían en el objetivo?

¿Necesitan saber que los datos pueden estar desactualizados?

Conservar el estado actual

Capture el estado relevante, los errores, las marcas de tiempo, los diagnósticos y demás evidencia antes de realizar cambios importantes.

Decida si esto sigue siendo un asunto de seguimiento o se ha convertido en una decisión de recuperación.

Si el oleoducto se detiene o la situación se deteriora lo suficiente como para que se estén considerando medidas de recuperación, se debe pasar a un proceso de recuperación estructurado en lugar de improvisar.

Mi programa de desarrollo de software para el CDC se está quedando atrás. ¿Aún se puede recuperar?

El retraso por sí solo no significa que se hayan perdido datos.

Y un aumento en la acumulación de tareas pendientes no significa automáticamente que sea necesario recargar la batería por completo.

Pero el retraso puede convertirse en un problema de recuperación cuando el equipo no puede responder con seguridad a preguntas como:

• ¿A cuánto retraso nos encontramos?
• ¿Se está reduciendo la lista de espera?
• ¿En qué estado de recuperación/proceso se encuentra?
• ¿De qué historial de origen dependería la recuperación?
• ¿Cuánto tiempo se estima que llevará ponerse al día?
• ¿Quién consume datos obsoletos?
• ¿Qué ocurre si el oleoducto se detiene por completo?
• ¿Cómo demostraremos después que el objetivo es digno de confianza?

En ese punto, la pregunta útil cambia de:

“¿Se está ejecutando la replicación?”

a:

“¿Aún comprendemos cómo podríamos recuperarnos de la situación actual?”

Cómo Rocket Data Replicate & Sync brinda visibilidad operativa

Rocket Data Replicate & Sync (RDRS) proporciona capacidades de monitorización operativa y diagnóstico que pueden ayudar a los equipos a comprender el estado de los entornos de replicación compatibles.

La validación técnica de RDRS identifica capacidades que incluyen:

• información sobre el estado del proceso
• información de diagnóstico
• rastros
• comprobaciones de latencia
• Estado de reinicio/proceso almacenado para configuraciones compatibles.

Las métricas exactas que ve el operador, las coordenadas de reinicio, las alertas y el comportamiento de monitorización pueden variar según el origen, el destino, la versión, la topología y la configuración.

Por lo tanto, los equipos que evalúen RDRS deberían solicitar a Rocket que demuestre la experiencia de monitorización en su entorno específico.

Algunas preguntas útiles son:

• ¿Qué puede observar el operador cuando la replicación comienza a retrasarse?
• ¿Qué información sobre latencia o estado del proceso está disponible?
• ¿Cómo puede el equipo saber si la replicación está progresando?
• ¿Qué errores y diagnósticos se exponen?
• ¿Qué estado de reinicio/proceso guardado pueden inspeccionar los operadores?
• ¿Qué puede observar el equipo mientras se lleva a cabo la recuperación o el proceso de puesta al día?
• ¿Cómo se integra el monitoreo en el modelo operativo general de la organización?
• ¿Qué cambios en el comportamiento del sistema deberían medirse durante la puesta al día de un alto volumen de tráfico?

Las afirmaciones sobre el impacto en la producción también deben evaluarse utilizando evidencia específica de la fuente, tanto en condiciones normales de carga de trabajo como en periodos de recuperación.

El estándar útil no es:

“¿El sistema RDRS cuenta con sistemas de monitoreo?”

Es:

“¿Nuestro operador habitual puede darse cuenta de lo que está sucediendo con la suficiente rapidez como para tomar la decisión correcta?”

Lista de verificación de preparación para el monitoreo de los CDC

Antes de confiar en una canalización CDC de mainframe para datos importantes posteriores, pregúntese:

• ¿Podemos ver cuánto retraso presenta la replicación?
• ¿Podemos determinar si la acumulación de pedidos pendientes está creciendo, se mantiene estable o está disminuyendo?
• ¿Podemos determinar si el procesamiento está avanzando realmente?
• ¿Comprendemos de qué información de origen puede depender la ruta de recuperación compatible?
• ¿Sabemos qué sistemas posteriores dependen del objetivo afectado?
• ¿Podemos identificar cuándo esos sistemas pueden estar utilizando datos obsoletos?
• ¿Se pueden observar errores y diagnósticos significativos?
• ¿Podemos relacionar el comportamiento de replicación con eventos relevantes de origen, destino o infraestructura?
• ¿Los umbrales de alerta se basan en nuestro entorno en lugar de en valores predeterminados genéricos?
• ¿Cada alerta relevante se corresponde con una acción o una decisión de escalamiento?
• ¿Podemos supervisar el progreso durante el período de recuperación?
• ¿Puede el equipo operativo habitual responder rápidamente a las preguntas básicas de salud sin ayuda de especialistas?

Si varias respuestas son no, es posible que tenga datos de monitoreo.

Es posible que aún no disponga de suficiente visibilidad operativa.

En resumen

La mayoría de los problemas de recuperación de los CDC no comienzan con una interrupción total. Comienzan con un proceso que se está quedando atrás, un retraso acumulado sin explicación y un objetivo que se está volviendo cada vez más obsoleto, mientras que el proceso aún parece funcionar correctamente.

Un buen sistema de monitoreo ayuda a los equipos a responder:

• ¿A cuánto retraso nos encontramos?
• ¿Está aumentando o disminuyendo la acumulación de pedidos?
• ¿Está progresando realmente la replicación?
• ¿Quiénes ya están expuestos a datos obsoletos?
• Si esto se convierte en un evento de recuperación, ¿seguiremos entendiendo nuestras opciones?

El objetivo no es recopilar más métricas.

Se trata de detectar un problema incipiente con la suficiente antelación para que los operadores puedan responder, mientras que la recuperación sigue siendo sencilla.

*Google SRE: Monitoreo de sistemas distribuidos

Siguiente: Antes de reiniciar

Si el oleoducto se detiene, o si el retraso ha progresado hasta el punto de que se estén considerando medidas de recuperación, se debe pasar de la monitorización a una decisión de recuperación estructurada.

Antes de reiniciar una canalización CDC fallida: 7 preguntas que debe responder.

Analice dónde se detuvo la replicación, dónde puede reanudarse, qué sucedió durante el lapso, si puede ser necesario ponerse al día o una resincronización más amplia, y cómo demostrará posteriormente que el objetivo es confiable.