Seu sistema de distribuição de medicamentos do CDC não está inoperante. Você tem certeza de que está funcionando corretamente?

Um oleoduto do CDC não precisa falhar para representar um risco.

Às vezes, a replicação ainda está em execução. O status do processo está verde. O destino ainda está disponível. Mas o backlog está aumentando.

O alvo está se tornando cada vez mais obsoleto. E a cada minuto que o pipeline fica para trás, as opções de recuperação podem se tornar mais limitadas. A questão não é simplesmente: "A replicação está funcionando?", mas sim: "A replicação está acompanhando o ritmo?".

E se não for: "Quanto tempo temos antes que isso se torne um problema de recuperação?"

O monitoramento mais eficaz do CDC não se limita a informar aos operadores se um processo está funcionando ou não. Ele os ajuda a reconhecer quando um oleoduto aparentemente saudável está silenciosamente caminhando para uma situação da qual será mais difícil se recuperar posteriormente.

Um bom monitoramento ajuda as equipes a responder:

• Quão atrasados ​​estamos?
• A lista de pendências está aumentando ou diminuindo?
• O projeto está realmente progredindo?
• As equipes subsequentes já estão usando dados desatualizados?
• Ainda compreendemos as nossas opções de recuperação caso a situação piore?

O objetivo não é prever todas as falhas. É reconhecer os problemas em desenvolvimento com antecedência suficiente para que a equipe ainda tenha opções.

Dependendo da origem e das plataformas de replicação, o monitoramento eficaz do CDC pode envolver métricas e conceitos como atraso de replicação, crescimento do backlog, atraso de aplicação na origem e no destino, estado de reinicialização, posição do log, histórico de alterações retidas, logs arquivados, progressão RBA/LRSN, comportamento de recuperação e exposição de dados downstream. A terminologia exata varia, mas o objetivo é sempre o mesmo: entender se a replicação está acompanhando o ritmo e se a recuperação permanece simples caso as condições se deteriorem.

Como posso detectar se um pipeline do CDC está ficando para trás antes que falhe?

Um pipeline pode estar em execução enquanto o atraso aumenta, o backlog cresce e os dados downstream ficam obsoletos.

Resposta rápida: Comece respondendo a cinco perguntas operacionais:

1. Quão atrasados ​​estamos?
2. A lista de espera está aumentando, estável ou diminuindo?
3. Ainda temos o histórico de origem que podemos precisar caso a recuperação se torne necessária?
4. O projeto está realmente progredindo?
5. Quem já depende dos dados subsequentes e há algum indício de que a situação está piorando?

As métricas exatas e os limites de alerta dependem da origem, do destino, da plataforma de replicação, da carga de trabalho, dos requisitos de recuperação e do caso de uso subsequente. Não existe um número universal de minutos, registros ou espaço de log que defina uma emergência do CDC.

Um oleoduto pode indicar "Em execução" e ainda assim estar caminhando para um problema de recuperação.

O monitoramento precisa responder a duas perguntas diferentes.

1. O sistema de distribuição de produtos está saudável neste momento?

Esta é a questão operacional imediata. A replicação é:

• Está acompanhando?
• Ficando para trás?
• Parado?
• Em recuperação?
• Operando em estado degradado?

O status do processo faz parte da resposta. Não é a resposta completa.

2. Estamos perdendo opções de recuperação à medida que o atraso aumenta?

Essa é a pergunta mais difícil. Um pipeline pode permanecer ativo enquanto:

• A lista de espera continua a crescer.
• O alvo torna-se cada vez mais obsoleto.
• A recuperação leva mais tempo
• As equipes subsequentes continuam usando dados antigos.
• Alterações disponíveis no histórico de fontes
• Um problema operacional relativamente contido se transforma em um problema de recuperação maior.

A questão mais importante é: "Se a situação piorar daqui para frente, ainda saberemos como nos recuperaríamos?"

1. Quão atrasados ​​estamos?

O atraso de replicação indica o quanto o destino está atrasado em relação à atividade atual da fonte. Mas um número bruto nem sempre é suficiente. Um acúmulo de 100.000 alterações pode ser trivial em um ambiente e significativo em outro. O que os operadores geralmente precisam entender é: "O que esse atraso significa em termos de tempo e impacto nos negócios?"

Métricas de atraso de replicação do CDC: o que medir e como interpretá-las

Diferentes plataformas revelam atrasos e progressos de maneiras distintas. Dependendo da origem, do destino e da tecnologia de replicação, o monitoramento útil pode incluir:

• atraso de replicação decorrido
• atraso do lado da fonte
• alvo ou aplicar atraso
• atrasos em alterações ou transações
• posição da fonte versus posição de processamento atual
• profundidade da fila ou da tarefa
• taxa de transferência
• último registro de data e hora de processamento bem-sucedido
• tendência de recuperação
• Informações de diagnóstico e status específicas da plataforma

Os nomes exatos das métricas importam menos do que a capacidade dos operadores de respondê-las:

• Quão atrasados ​​estamos?
• Onde está o atraso?
• A situação está melhorando?

Perguntar

• Qual a distância até o alvo?
• Quando começou o atraso?
• Isso é normal para esse período de carga de trabalho?
• Quais sistemas subsequentes dependem desses dados?
• Em que momento o atraso passa a ser relevante para eles?

Por que isso importa

Um atraso de cinco minutos em relação à meta pode ser aceitável para uma carga de trabalho e inaceitável para outra. A métrica técnica deve ser interpretada no contexto dos dados utilizados.

O que é bom

A equipe operacional pode dizer: “Estamos aproximadamente com este atraso, e isto é o que isso significa para os sistemas que utilizam os dados.”

Não basta dizer: "A tarefa ainda está em andamento."

2. A lista de espera está crescendo, estável ou diminuindo?

A direção do atraso pode ser tão importante quanto a sua magnitude. Um oleoduto que está significativamente atrasado, mas que está se recuperando rapidamente, apresenta uma situação diferente de um oleoduto com um atraso menor que está perdendo terreno constantemente. Os profissionais da área costumam descrever isso de forma muito simples: "Está entrando em colapso?"

Perguntar

• A lista de espera está aumentando?
• A situação se estabilizou?
• Está encolhendo?
• O pipeline está acompanhando o ritmo da nova atividade de origem?
• O processamento está ocorrendo mais rapidamente do que a chegada de novos trabalhos durante o período de recuperação?
• A tendência mudou desde o início do incidente?

Taxa de captura versus taxa de processamento ou aplicação

Quando a plataforma expõe as métricas apropriadas, comparar as alterações que entram no fluxo de replicação com as alterações que estão sendo processadas no destino pode ajudar a mostrar se o ambiente está ganhando ou perdendo terreno. As métricas específicas variam de acordo com a plataforma. O princípio é simples: se o novo trabalho continuar chegando mais rápido do que o pipeline consegue processá-lo por um período prolongado, o backlog continuará crescendo, mesmo que o processo não tenha parado.

O que é bom

Os operadores conseguem distinguir rapidamente: ficar para trás → manter o ritmo → recuperar o atraso

Bandeira vermelha

O painel de controle mostra o atraso atual, mas não indica se a situação está melhorando.

4. O projeto está realmente progredindo?

Um processo pode estar ativo sem que haja, de fato, movimentação significativa de dados.

Isso faz com que a comprovação de atividade de processamento bem-sucedida seja uma importante verificação de sanidade.

Dependendo da plataforma, as equipes podem analisar:

• atividade de replicação bem-sucedida mais recente
• alteração processada mais recente
• aplicar alvo mais recente
• progresso em uma posição salva ou estado de processamento
• movimentação de atrasos
• taxa de transferência
• outro indicador de progresso específico da plataforma

Perguntar

Alguma coisa realmente avançou?

E então:

Está avançando na velocidade que esperaríamos para essa fonte e carga de trabalho?

A resposta deve levar em conta o padrão de atividade normal do sistema.

Um ambiente transacional de alto volume normalmente pode mudar continuamente.

Outra fonte pode apresentar períodos legítimos de pouca ou nenhuma atividade.

Por que isso importa

Isso ajuda a identificar o estado desconfortável em que:

“Diz que está funcionando, mas nada se move.”

O que é bom

O ambiente de monitoramento ajuda a distinguir:

a fonte é naturalmente silenciosa

de

A replicação parou de progredir.

Bandeira vermelha

A única verificação de integridade é se o processo de replicação existe.

5. Quem já está usando dados desatualizados?

Muitos problemas do CDC começam como problemas técnicos e depois se transformam em problemas de negócios:

A origem pode ainda estar íntegra. O destino pode ainda estar disponível. A replicação pode ainda estar em execução. Mas relatórios, painéis, APIs, sistemas operacionais e ambientes de análise podem já estar trabalhando com dados cada vez mais desatualizados.

Isso cria um dos modos de falha mais perigosos do CDC: as telas estão funcionando, mas os dados estão ficando desatualizados.

Perguntar

• Quais aplicações dependem do alvo afetado?
• Quais relatórios ou painéis o utilizam?
• Será que as análises, APIs, sistemas operacionais ou cargas de trabalho de IA ainda consomem os dados?
• Alguém a jusante sabe que a alimentação está desatualizada?
• Está se aproximando um prazo importante para relatórios, liquidação, processamento de lotes, clientes ou operações?
• O uso subsequente deve ser pausado ou restringido enquanto o problema é investigado?

Por que isso importa

Várias coisas muito diferentes podem ser verdadeiras ao mesmo tempo:

• A fonte é saudável.
• O alvo está disponível.
• O oleoduto está atrasado.
• As pessoas ainda estão usando o alvo.

Isso pode dificultar a detecção da exposição a dados desatualizados em comparação com uma interrupção limpa.

O que é bom

A equipe pode responder:

“Os dados estão tão desatualizados assim, esses são os consumidores afetados, e essas pessoas conhecem a situação atual.”

6. Os avisos, erros ou eventos ambientais indicam que algo está mudando?

Nem todo alerta é uma crise.

E o envio de alertas para cada mensagem pode gerar tanto ruído que os operadores deixam de confiar no sistema de monitoramento.

O objetivo é identificar os eventos que importam no seu ambiente e interpretá-los dentro do contexto.

Sinais úteis podem incluir

• erros de conectividade repetidos
• falhas de aplicação de destino
• novas tentativas
• alterações de autenticação ou permissões
• mudanças incomuns no atraso
• manutenção de fonte ou alvo
• mensagens de diagnóstico específicas da plataforma

Observe o ambiente ao redor do oleoduto.

Uma mudança no comportamento de replicação que coincide com:

• um evento Db2
• uma IPL
• manutenção de infraestrutura
• uma mudança de rede
• uma alteração de segurança
• uma atualização de esquema ou configuração
• um período de grande carga de trabalho

Pode ser necessário interpretá-lo de forma diferente de um evento de replicação isolado.

Isso não significa que o evento original necessariamente causou o problema do CDC.

Significa que os operadores devem ser capazes de visualizar contexto suficiente para investigar a relação.

O que é bom

A equipe sabe:

• O que exige ação imediata
• O que precisa ser investigado
• o que pode ser observado
• quando uma escalada mais ampla for justificada

Bandeira vermelha

Em um dos extremos:

Cada aviso desperta alguém.

or

Os avisos são ignorados até que o pipeline seja interrompido.

Como devo definir os limites de alerta de atraso do CDC?

Quanto atraso do CDC é demais?

Não existe um limite universal que funcione em todos os ambientes de CDC (Centros de Controle de Doenças) de mainframe.

Um limiar de alerta útil deve refletir fatores como:

• volume normal de transações
• moeda de dados esperada
• tolerância a jusante para dados desatualizados
• disponibilidade do histórico de origem
• objetivos de recuperação
• padrões de carga de trabalho
• tempo de resposta da equipe
• prazos de corte para negócios
• consequências da falta de resposta

Em vez de copiar uma regra genérica como:

“Alerta após 30 minutos de atraso.”

perguntar:

“Em que ponto essa condição começa a ameaçar a atualidade dos dados, os requisitos operacionais ou de recuperação que realmente temos?”

Esse é o limite que vale a pena considerar no projeto.

Crie alertas com base em decisões, não apenas em números.

Um alerta útil deve ajudar alguém a decidir o que fazer em seguida.

Um modelo simples é:

Investigar

Algo se deslocou para fora da faixa esperada do ambiente.

Exemplos podem incluir:

• O atraso começa a apresentar uma tendência de alta.
• progresso do processamento mais lento
• avisos repetidos
• alterações inexplicáveis ​​na produção

A tarefa imediata é entender o porquê.

Agir

A condição está afetando materialmente um requisito operacional ou aumentando a complexidade da recuperação.

As ações podem incluir:

• investigando um gargalo alvo
• examinando as condições da fonte ou da infraestrutura
• envolvendo uma equipe adjacente
• Analisando de quais informações de origem o caminho de recuperação depende.
• Proteger os usuários subsequentes de dados desatualizados.
• Preparando-se para uma recuperação controlada.

Aumentar

O problema ultrapassou a autoridade operacional normal da equipe técnica ou começou a afetar decisões mais amplas de negócios, riscos ou serviços.

Isso pode exigir o envolvimento de:

• liderança de dados ou plataforma
• operações de mainframe
• proprietários do sistema a jusante
• partes interessadas do negócio
• governança ou risco
• gerenciamento de incidentes

Os limites serão diferentes.

O processo de decisão já deve existir antes do alerta ser disparado.

O teste de observabilidade de dois minutos do CDC: Sua equipe consegue responder a estas cinco perguntas?

Um painel de monitoramento não é valioso apenas por exibir métricas. Ele é valioso porque ajuda os operadores a tomar decisões. Faça este teste: um operador comum consegue responder às cinco perguntas a seguir em menos de dois minutos sem consultar um especialista da plataforma?

Isso está em consonância com as diretrizes operacionais mais amplas da Engenharia de Confiabilidade de Sites do Google, que trata o monitoramento como uma forma de avaliar a integridade do serviço, diagnosticar problemas, identificar tendências e comparar o comportamento ao longo do tempo, e não simplesmente coletar ou exibir métricas.*

1. Quão atrasados ​​estamos?

O operador consegue identificar o atraso ou o acúmulo de trabalho atual?

2. Está melhorando ou piorando?

Eles conseguem dizer se a lista de espera está crescendo, estável ou se esgotando rapidamente?

3. O processamento está realmente em andamento?

Será que eles conseguem identificar atividades recentes bem-sucedidas em vez de se basearem em um status genérico de "Em execução"?

4. Se isso se tornar um evento de recuperação, entendemos do que depende a recuperação?

Eles conseguem determinar qual histórico, estado ou outras informações da fonte seriam relevantes?

5. Quem já foi afetado?

Eles conseguem identificar quais sistemas ou equipes subsequentes podem estar utilizando dados desatualizados?

Se o operador não puder responder a essas cinco perguntas em aproximadamente dois minutos, pergunte:

• Que informações estão faltando?
• O que está espalhado por muitas ferramentas?
• O que requer interpretação especializada?
• Que contexto existe apenas na cabeça de alguém?
• Que procedimentos de monitoramento ou operacionais precisam ser alterados?
• A estrutura de dois minutos é uma heurística operacional prática, não um parâmetro de referência do setor.
• O princípio é o que importa:

A pessoa que responde à ocorrência deve ser capaz de compreender a situação com rapidez suficiente para agir.

O monitoramento que somente um especialista da plataforma consegue interpretar não é suficiente para um oleoduto de importância operacional.

Como monitorar a atualização dos dados do CDC após uma interrupção

Como saber se o CDC está realmente se atualizando? O monitoramento não para quando o processo recomeça. Durante a atualização, pergunte:

• A lista de espera está diminuindo?
• Com que rapidez está encolhendo?
• Ainda há novas atividades de origem chegando?
• O processamento está acompanhando o ritmo das novas atividades e, ao mesmo tempo, reduzindo a lacuna?
• Estão ocorrendo erros ou novas tentativas?
• Qual o impacto da recuperação de atraso na fonte e no destino?
• Os sistemas subsequentes ainda estão funcionando com dados desatualizados?
• Que evidências nos dirão que a recuperação está realmente completa?

A distinção importante é:

correndo novamente

contra

alcançado

contra

recuperado e validado.

Esses não são necessariamente o mesmo estado.

Os padrões de carga de trabalho de um mainframe podem alterar o que significa "normal".

Os ambientes mainframe geralmente possuem períodos operacionais distintos:

• processamento online máximo
• lote noturno
• fim do dia
• fim do mês
• fechamento financeiro
• picos sazonais
• manutenção programada

Uma condição de atraso que é normal em um período pode sinalizar um problema em outro.

• O mesmo se aplica a:
• carga de trabalho de origem
• registrar ou alterar volume
• pressão alvo
• capacidade de recuperação disponível
• disputa de infraestrutura

Evite definir "saudável" com base em um único número médio.

Monitore o pipeline no contexto da carga de trabalho que ele suporta.

Quando o monitoramento detecta um problema: o que deve acontecer primeiro?

O monitoramento oferece às equipes algo que, eventualmente, acaba faltando em todos os esforços de recuperação: tempo.

Quanto mais cedo um problema em desenvolvimento for identificado, mais opções de recuperação estarão disponíveis.

Confirme o que realmente está acontecendo.

A condição é transitória ou prolongada?

Em que ponto do processo de replicação o progresso está diminuindo ou foi interrompido?

Estabeleça o cronograma.

Há quanto tempo isso vem acontecendo?

Quando ocorreu a última atividade bem-sucedida confirmada?

Entenda o backlog

Quão atrasado você está?

Está crescendo ou se consumindo?

Identificar exposição a jusante

Quem já está contando com esse objetivo?

Eles precisam saber que os dados podem estar desatualizados?

Preserve o estado atual

Registre o status relevante, erros, registros de data e hora, diagnósticos e outras evidências antes que grandes alterações sejam feitas.

Decida se isso continua sendo uma questão de monitoramento ou se tornou uma decisão de recuperação.

Se o fornecimento de gás for interrompido ou a situação se deteriorar a ponto de serem consideradas medidas de recuperação, adote um processo de recuperação estruturado em vez de improvisar.

Meu processo de coleta de dados do CDC está atrasado. Ainda é possível recuperar o atraso?

A latência por si só não significa que os dados foram perdidos.

E um acúmulo crescente de tarefas não significa automaticamente que será necessário um recarregamento completo.

Mas o atraso pode estar se tornando um problema de recuperação quando a equipe não consegue responder com segurança a perguntas como:

• Quão atrasados ​​estamos?
• A lista de espera está diminuindo?
• Qual é o estado de recuperação/processamento existente?
• De qual histórico de origem dependeria a recuperação?
• Quanto tempo provavelmente levará para recuperar o tempo perdido?
• Quem está consumindo dados obsoletos?
• O que acontece se o oleoduto parar completamente?
• Como provaremos posteriormente que o alvo é confiável?

Nesse ponto, a pergunta útil muda de:

“A replicação está em execução?”

para:

“Ainda sabemos como nos recuperaríamos da situação em que nos encontramos agora?”

Como a replicação e sincronização de dados do Rocket Data auxiliam na visibilidade operacional

O Rocket Data Replicate & Sync (RDRS) oferece recursos de monitoramento operacional e diagnóstico que podem ajudar as equipes a entender o estado dos ambientes de replicação suportados.

A validação técnica do RDRS identifica capacidades que incluem:

• informações sobre o status do processo
• informações de diagnóstico
• vestígios
• verificações de latência
• Estado de reinicialização/processamento armazenado para configurações suportadas

As métricas exatas voltadas para o operador, as coordenadas de reinicialização, os alertas e o comportamento de monitoramento podem variar de acordo com a origem, o destino, a versão, a topologia e a configuração.

Portanto, as equipes que avaliam o RDRS devem solicitar à Rocket que demonstre a experiência de monitoramento em seu ambiente específico.

Algumas perguntas úteis incluem:

• O que o operador consegue ver quando a replicação começa a ficar atrasada?
• Que informações sobre latência ou estado do processo estão disponíveis?
• Como a equipe pode saber se a replicação está progredindo?
• Quais erros e diagnósticos são expostos?
• Que estado de reinicialização/processo salvo os operadores podem inspecionar?
• O que a equipe consegue observar durante o processo de recuperação ou retomada das atividades?
• Como o monitoramento se integra ao modelo operacional mais amplo da organização?
• Que alterações no comportamento do sistema devem ser medidas durante a recuperação de dados em alto volume?

As alegações de impacto na produção também devem ser avaliadas usando evidências específicas da fonte, tanto em condições normais quanto em condições de recuperação da carga de trabalho.

O padrão útil não é:

“O RDRS possui sistema de monitoramento?”

Isso é:

“Será que o nosso operador habitual consegue identificar o que está acontecendo com rapidez suficiente para tomar a decisão correta?”

Lista de verificação de prontidão para monitoramento do CDC

Antes de depender de um pipeline CDC em mainframe para obter dados importantes subsequentes, pergunte-se:

• Podemos ver o quão atrasada está a replicação?
• É possível determinar se a lista de pendências está crescendo, estável ou diminuindo?
• Podemos afirmar se o processamento está realmente avançando?
• Entendemos de quais informações de origem o caminho de recuperação suportado pode depender?
• Sabemos quais sistemas subsequentes dependem do alvo afetado?
• Podemos identificar quando esses sistemas podem estar usando dados desatualizados?
• É possível identificar erros e diagnósticos relevantes?
• Podemos relacionar o comportamento de replicação a eventos relevantes de origem, destino ou infraestrutura?
• Os limites de alerta são baseados em nosso ambiente, em vez de valores padrão genéricos?
• Cada alerta relevante corresponde a uma ação ou decisão de escalonamento?
• Podemos monitorar o progresso durante o período de recuperação?
• A equipe operacional habitual consegue responder rapidamente às principais questões de saúde sem ajuda de especialistas?

Se várias respostas forem negativas, você pode ter dados de monitoramento.

Você pode ainda não ter visibilidade operacional suficiente.

Em resumo

A maioria dos problemas de recuperação do CDC não começa com uma interrupção completa. Começa com um fluxo de trabalho atrasado, um acúmulo de tarefas sem explicação e uma meta que se torna cada vez mais obsoleta, embora o processo ainda pareça funcionar bem.

Um bom monitoramento ajuda as equipes a responder:

• Quão atrasados ​​estamos?
• A lista de pendências está aumentando ou diminuindo?
• A replicação está realmente a fazer progressos?
• Quem já está exposto a dados desatualizados?
• Se isso se tornar um evento de recuperação, ainda entenderemos nossas opções?

O objetivo não é coletar mais métricas.

Trata-se de reconhecer um problema em desenvolvimento com antecedência suficiente para que os operadores possam responder enquanto a recuperação permanece simples.

*Google SRE: Monitoramento de Sistemas Distribuídos

A seguir: Antes de reiniciar

Se o fornecimento de gás for interrompido — ou se o atraso tiver progredido a ponto de se considerar uma ação de recuperação — passe do monitoramento para uma tomada de decisão estruturada de recuperação.

Antes de reiniciar um pipeline do CDC que falhou: 7 perguntas a responder

Analise onde a replicação parou, onde pode ser retomada, o que aconteceu durante a interrupção, se será necessário recuperar o atraso ou realizar uma resincronização mais ampla e como você comprovará a confiabilidade do destino posteriormente.