Quando um problema de recuperação do CDC se torna um problema de plataforma?

Um incidente de CDC não é necessariamente um sinal de que a plataforma falhou. Todo ambiente de replicação eventualmente se depara com:

• Falhas de infraestrutura
• interrupções de rede
• Manutenção de fontes
• Interrupções de alvo
• Erros do operador
• Picos inesperados de carga de trabalho
• Alterações no aplicativo

As questões importantes são:

• O que acontece a seguir?
• A equipe consegue determinar rapidamente onde o processamento foi interrompido?
• Será que eles conseguem entender o que aconteceu durante esse intervalo?
• Eles conseguem se recuperar sem precisar recomeçar do zero?
• Eles conseguem provar que os dados resultantes são confiáveis?

Ou será que a recuperação depende do conhecimento tradicional, da investigação manual e de uma série de palpites fundamentados?

Um evento de recuperação difícil pode ser simplesmente um incidente infeliz. A incerteza repetida na recuperação geralmente aponta para algo maior. Isso está em consonância com o planejamento de contingência mais amplo e as diretrizes de resiliência. O NIST descreve a prontidão para recuperação como uma disciplina operacional contínua que inclui estratégias de recuperação, testes, treinamento, exercícios, manutenção e melhoria contínua, em vez de uma série de eventos técnicos isolados.*

Antes de avaliar fornecedores, arquiteturas ou mudanças de plataforma, determine se o problema reside no incidente em si ou na forma como a recuperação está sendo gerenciada.

Resposta rápida: O que torna uma plataforma do CDC pronta para a recuperação?

Uma plataforma do CDC preparada para a recuperação ajuda as equipes a responderem a quatro perguntas:

1. Onde podemos retomar nossas atividades com segurança?
2. O que aconteceu durante a interrupção?
3. Podemos nos recuperar sem recomeçar do zero?
4. Como podemos provar que os dados são confiáveis ​​posteriormente?

As plataformas mais robustas fornecem evidências para todos os quatro aspectos. As plataformas mais fracas fornecem apenas o status do processo e esperam que a equipe consiga descobrir o restante.

Indicadores de que a recuperação está sendo mais difícil do que deveria.

Toda equipe passa ocasionalmente por momentos de recuperação. O padrão a ser observado é a incerteza recorrente.

Pergunte a si mesmo

• A recuperação depende da disponibilidade de um especialista?
• Os operadores têm dificuldade em determinar onde o processamento foi interrompido?
• As equipes passam horas identificando o que aconteceu durante o intervalo?
• As decisões de reinicialização são tomadas com informações incompletas?
• A validação é em grande parte manual?
• O comportamento de recuperação continua sendo difícil de prever?
• As equipes que utilizam os dados posteriormente muitas vezes não têm certeza se podem confiar neles?
• Os incidentes desencadeiam repetidamente recarregamentos ou resincronizações em larga escala?
• Há debates frequentes sobre se a recuperação realmente teve sucesso?

Uma única resposta "sim" não indica um problema na plataforma. Vários padrões recorrentes provavelmente indicam.

Avaliação de prontidão para recuperação

Avalie seu ambiente atual.

Visibilidade da recuperação

• Podemos identificar onde o processamento foi interrompido?
• Podemos determinar a quantidade de dados afetados?
• Podemos avaliar a exposição a jusante?

Execução de recuperação

• Podemos retomar o processamento com segurança?
• Podemos processar o histórico acumulado?
• Podemos prever o comportamento de recuperação?

Validação de recuperação

• Podemos comprovar a integridade dos dados posteriormente?
• Podemos identificar discrepâncias de forma eficiente?
• Podemos documentar as evidências?

Maturidade operacional

• Os procedimentos estão documentados?
• Várias pessoas podem executá-los?
• Os proprietários a jusante estão envolvidos?
• Podemos explicar a decisão de recuperação meses depois?

Quanto mais respostas negativas você encontrar, mais forte será o argumento para aprimorar o modelo operacional, os recursos da plataforma ou ambos.

mínimos básicos

As plataformas de CDC empresariais devem fornecer:

• Status do processo
• Reiniciar ou estado do processo
• Monitoramento básico
• Informações sobre erros e diagnósticos
• Suporte de recuperação para fontes suportadas
• Procedimentos de recuperação para ambientes suportados

Essas funcionalidades respondem à pergunta: "A replicação foi reiniciada?" Isso é importante. Mas não é suficiente.

Funcionalidades essenciais que nem sempre estão incluídas.

A questão mais difícil é: "Poderemos defender a decisão de recuperação posteriormente?"
As funcionalidades que valem a pena avaliar incluem:

Visibilidade do estado de recuperação

Os operadores conseguem determinar:

• Onde o processamento foi interrompido?
• Onde será retomado?
• O que representa o estado de reinicialização?
• O estado é realmente utilizável?

A visibilidade significativa do estado de reinicialização exige mais do que saber que um processo parou e tem uma posição salva. Uma plataforma oferece visibilidade genuína do estado de recuperação quando consegue responder a todas as quatro perguntas com evidências, não com inferências. Especificamente, a posição de reinicialização deve refletir a última alteração confirmada com sucesso no destino, e não simplesmente o último registro lido do log de origem. Esses dois pontos divergem durante falhas, encerramentos abruptos e falhas no meio da confirmação, e é nessa lacuna que o risco de perda e duplicação de dados é introduzido.

Ao avaliar essa capacidade, peça ao fornecedor que distinga entre o ponto de leitura do pipeline e o ponto de confirmação da entrega. Uma plataforma que não consegue separar claramente esses dois conceitos provavelmente está fornecendo informações sobre o status do processo e chamando isso de visibilidade do estado de recuperação. Isso é o mínimo necessário disfarçado de capacidade.

Uma resposta robusta descreverá um registro de posição confirmada que é atualizado transacionalmente com a gravação de destino, pode ser consultado independentemente do próprio processo do pipeline e permanece disponível mesmo quando o pipeline é interrompido ou falha. A capacidade de consultar esse registro diretamente, sem reiniciar o pipeline, é um diferencial significativo.

apoio à recuperação histórica

A plataforma consegue processar alterações históricas quando:

• Os registros ativos foram atualizados?
• Os registros arquivados ainda estão disponíveis?
• A recuperação começa horas após a interrupção?

E, igualmente importante: o fornecedor consegue explicar claramente quando esse processo de recuperação deixa de ser aplicável?

É nessa capacidade que as discussões sobre recuperação geralmente geram respostas enganosas. A maioria das plataformas de CDC (Controle de Dados de Mudanças) corporativas consegue processar alterações de logs de origem arquivados ou descarregados, sob as condições adequadas. As questões mais complexas são: quais condições devem existir, por quanto tempo essas condições normalmente duram em ambientes de produção e o que acontece com o caminho de recuperação quando elas deixam de ser válidas.

A retenção de logs de origem é regida por políticas definidas fora da plataforma de replicação, geralmente por administradores de armazenamento ou equipes de DBA que trabalham com restrições de custo e capacidade, em vez de objetivos de recuperação. Em ambientes mainframe de alto volume, os logs ativos podem ser rotacionados e descarregados em minutos durante períodos de pico. Uma plataforma CDC pode, em princípio, suportar a recuperação histórica a partir de logs arquivados, embora essa janela esteja praticamente indisponível quando a equipe de recuperação estiver pronta para agir.

Ao avaliar essa funcionalidade, peça ao fornecedor que explique a cadeia de dependências: qual histórico de origem a recuperação exige, onde esse histórico reside em diferentes momentos, quem controla sua retenção e em que ponto o caminho de recuperação suportado se encerra. Um fornecedor que consegue responder a essa cadeia com precisão demonstra que a funcionalidade foi testada em condições reais de produção. Um fornecedor que responde apenas "sim, oferecemos suporte à recuperação de histórico" sem abordar a dependência de retenção respondeu a uma pergunta diferente.

Durante uma prova de conceito (POC), teste isso explicitamente. Simule um cenário de recuperação onde o log ativo foi atualizado e verifique se a plataforma consegue localizar, acessar e processar os segmentos arquivados necessários de acordo com sua política de retenção, e não em um ambiente de teste padrão.

visibilidade de recuperação

Os operadores conseguem ver:

• Tendências de atraso?
• Crescimento da carteira de pedidos?
• Houve progresso na recuperação?
• Processando avanços?
• Qual o estado de conclusão da recuperação?

Ou será que eles simplesmente sabem que o processo está em andamento?

A discrepância entre saber que um processo está em execução e saber que a recuperação está progredindo é a origem da maioria dos problemas de gerenciamento de recuperação. Um pipeline em execução e um pipeline em processo de recuperação representam estados operacionalmente distintos. Uma plataforma que exibe apenas o status do processo os confunde, deixando os operadores sem as informações necessárias para gerenciar a janela de recuperação, definir expectativas para as etapas subsequentes ou reconhecer quando a recuperação estagnou.

A visibilidade genuína do backlog tem três componentes. Primeiro, o backlog deve ser expresso em unidades significativas: transações, registros de alterações ou volume de dados, e não apenas tempo decorrido. O tempo decorrido por si só não informa aos operadores quanto trabalho resta ou se a taxa de progresso é suficiente para cumprir qualquer prazo subsequente. Segundo, a tendência deve ser visível: o backlog está diminuindo, estável ou aumentando? Um backlog crescente durante um período de recuperação nominal indica que a atividade de origem está superando a taxa de replicação, o que é uma situação operacional diferente de um backlog decrescente que confirma o progresso. Terceiro, deve haver uma base para estimar a conclusão: a taxa de transferência observada nas condições atuais, e não um limite teórico.

Ao avaliar essa funcionalidade, peça ao fornecedor para demonstrar como a visualização de recuperação se apresenta durante um evento de recuperação ativo, e não apenas durante a operação normal. Pergunte especificamente: em qual unidade o backlog é expresso, com que frequência é atualizado e como seria se a recuperação tivesse sido interrompida? Uma plataforma cuja visualização de monitoramento é idêntica durante uma recuperação interrompida e durante uma recuperação em andamento não está fornecendo visibilidade da recuperação. Ela está fornecendo um indicador de progresso.

Suporte à validação: A plataforma pode ajudar a identificar:

• Faltam alterações?
• Processamento duplicado?
• Exclusões não encontradas?
• Valores obsoletos?
• Diferenças entre a origem e o destino?

Ou a validação é inteiramente manual?

A validação é a etapa mais frequentemente considerada concluída quando, na verdade, não o é. A falha de validação mais comum é a confirmação da contagem de linhas no nível da tabela e o tratamento de uma correspondência como evidência de integridade. A contagem de linhas não detecta exclusões não detectadas. Uma linha excluída na origem, mas não propagada para o destino, deixa a contagem inalterada e o destino incorreto. A contagem de linhas também não detecta valores obsoletos. Uma linha atualizada na origem e não replicada resulta em uma contagem de um em ambos os locais e dados diferentes em cada um. Uma abordagem de validação que se baseia apenas na comparação de contagens confirma que o mesmo número de linhas existe, e não que elas contenham os dados corretos.

Uma validação significativa requer uma comparação dos valores reais entre a origem e o destino para um conjunto de objetos definido e um período de tempo definido, com resultados que revelem discrepâncias específicas em vez de uma correspondência ou não correspondência geral. A comparação deve ser capaz de identificar quais linhas diferem, em quais colunas e se a diferença representa uma alteração ausente, uma duplicata, uma exclusão ausente ou um valor desatualizado. Essas distinções são importantes para a decisão de correção: cada categoria requer uma resposta diferente.

Ao avaliar essa funcionalidade, peça ao fornecedor que demonstre a saída da validação para um cenário que inclua uma exclusão ausente e um valor obsoleto, e não apenas uma inserção ausente. Esses dois modos de falha são os mais difíceis de detectar e os que têm maior probabilidade de sobreviver a uma verificação baseada em contagem. Pergunte também se a comparação está limitada a um período específico, pois uma comparação completa da tabela em um objeto de produção grande geralmente é impraticável sob restrições de tempo de recuperação. Uma plataforma que pode limitar a comparação especificamente ao período do incidente oferece uma funcionalidade de validação. Uma plataforma que exige uma varredura completa da tabela a cada vez possui um recurso de validação que pode não ser utilizável quando mais necessário.

Diagnóstico e investigação da causa raiz:

As equipes conseguem determinar:

• Por que ocorreu a interrupção?
• Qual componente apresentou falha?
• Quais eram as condições que existiam antes da falha?
• O que mudou depois?

Ou os operadores são obrigados a reconstruir o evento a partir de múltiplas ferramentas desconectadas?

A distinção entre diagnósticos integrados e a proliferação de ferramentas desconectadas é um dos sinais mais claros da maturidade da plataforma em um contexto de recuperação. Em um ambiente desconectado, a investigação da causa raiz exige a correlação de registros de data e hora e de eventos entre os logs da própria plataforma de replicação, os logs operacionais do sistema de origem, a camada de rede e o ambiente de destino, frequentemente de forma manual e sob pressão de tempo. Cada transferência entre sistemas é um ponto em que a sequência de eventos pode ser mal interpretada ou onde o contexto relevante simplesmente está ausente.

Um ambiente de diagnóstico integrado captura as condições que envolvem uma falha em um único registro correlacionado: o que o pipeline estava processando no momento do evento, qual era a taxa de processamento e o atraso no período anterior à falha, qual erro ou exceção foi gerado e qual era o estado do sistema imediatamente depois. Esse registro fica disponível sem a necessidade de reiniciar o pipeline e persiste por tempo suficiente para permitir uma análise pós-incidente.

Ao avaliar essa funcionalidade, peça ao fornecedor que demonstre como um evento de falha se apresenta em sua saída de diagnóstico. Especificamente: quanto contexto é preservado antes do ponto de falha, se esse contexto é correlacionado automaticamente ou requer montagem manual, por quanto tempo os dados de diagnóstico são retidos e se podem ser exportados para documentação pós-incidente. Uma plataforma que exige que os operadores reconstruam a narrativa do evento a partir de fontes desconectadas após o ocorrido aumenta o tempo de recuperação e o risco de erro humano justamente no momento em que nenhum dos dois é aceitável.

Consciência de repetição e idempotência: A recuperação geralmente requer o processamento de alterações acumuladas durante uma interrupção. Em algumas arquiteturas, eventos atrasados ​​ou repetidos podem desencadear ações subsequentes, como:

• Notificações
• Pagamentos
• Ajustes de estoque
• Transições de fluxo de trabalho
• Integrações externas

Uma plataforma preparada para recuperação deve ajudar as equipes a entender:

• Se está ocorrendo replay
• Quais sistemas a jusante podem ser afetados?
• Quais consumidores são capazes de lidar com eventos repetidos com segurança?
• Que evidências estão disponíveis para apoiar as decisões de recuperação?

A plataforma não precisa tornar todos os aplicativos subsequentes idempotentes. No entanto, ela deve fornecer aos operadores visibilidade suficiente para entender quando o comportamento de reprodução é importante e quais riscos a recuperação pode acarretar.

O teste prático para essa capacidade é se a plataforma torna a reprodução visível e atribuível, e não apenas tecnicamente correta. Uma plataforma que reproduz alterações acumuladas sem mostrar que a reprodução está ocorrendo, quais alterações estão sendo reproduzidas e em que taxa, deixa o operador sem as informações necessárias para coordenar com as equipes subsequentes ou suprimir ações subsequentes que não deveriam ser acionadas novamente.

A idempotência é uma propriedade do lado do consumidor, não da plataforma. A plataforma de replicação não pode tornar um sistema de pagamento idempotente. O que ela pode fazer é fornecer à equipe de recuperação evidências suficientes para uma conversa informada com a equipe do consumidor antes do início do processo de recuperação: aqui está o período de alterações que serão reproduzidas, aqui estão os tipos e volumes de registros, aqui está a taxa na qual eles chegarão. Essas informações permitem que a equipe do consumidor avalie se a supressão, a desduplicação ou a ativação coordenada são necessárias.

Ao avaliar essa funcionalidade, pergunte ao fornecedor como a reprodução é apresentada ao operador durante a recuperação, especificamente: a reprodução é distinguível do processamento normal na visualização de monitoramento? O operador consegue ver o que está sendo reproduzido e quando? E quais evidências são retidas após a conclusão da recuperação para confirmar o que foi reproduzido e para quem? Uma plataforma que trata a reprodução como um detalhe de implementação interna invisível para o operador coloca toda a carga de coordenação na comunicação manual entre equipes que podem não saber o que comunicar ou quando. Em uma recuperação urgente envolvendo sistemas de pagamento ou notificação, essa lacuna de coordenação é onde ocorrem os erros de recuperação mais graves.

Se você decidir que uma avaliação da plataforma é necessária

Avalie a capacidade da plataforma de fornecer:

• Visibilidade do estado de reinicialização
• apoio à recuperação histórica
• visibilidade de recuperação
• Suporte à validação
• Diagnóstico e evidências da causa raiz
• Consciência da repetição e limites de recuperação

O próximo passo não é simplesmente perguntar se a plataforma suporta recuperação. É testar essas capacidades em condições realistas.

Como saber se as alegações de recuperação de um fornecedor do CDC serão verdadeiras?

Se os problemas de recuperação persistirem

Se a avaliação apontar para lacunas de visibilidade recorrentes, desafios de validação, dependência de especialistas, recarregamentos repetidos ou crescente incerteza operacional, o próximo passo pode não ser a avaliação de fornecedores.

Provavelmente, o objetivo deveria ser transformar o padrão em algo que a liderança possa avaliar. Um único incidente difícil pode ser lamentável. Um padrão recorrente de esforço de recuperação, incerteza e impacto subsequente é uma evidência. A meta não é atingir uma contagem específica de incidentes, mas sim determinar se o problema de recuperação se tornou observável, mensurável e significativo o suficiente para justificar uma ação.

Recurso relacionado: Seu problema de recuperação do CDC é técnico. Seu plano de negócios não pode ser.

Como o Rocket Data Replicate & Sync se encaixa nisso

A mesma estrutura deve ser aplicada ao Rocket Data Replicate & Sync, assim como a qualquer outra plataforma de CDC. O RDRS inclui funcionalidades que suportam:

• Processo salvo e estado de reinicialização
• Recuperação histórica para fontes suportadas
• Diagnóstico operacional
• Visibilidade de atraso e latência
• Funcionalidade de comparação em lote para ambientes compatíveis
• Análise de diferença entre origem e destino

Assim como em qualquer plataforma do CDC, essas funcionalidades devem ser avaliadas em relação a:

• Tipo de fonte
• Tipo de alvo
• Combinação de captura/aplicação
• Configuração
• Histórico de origem retido
• Objetivos de recuperação
• Requisitos de validação

O objetivo não é determinar se o RDRS consegue reiniciar a replicação. É determinar quais evidências o RDRS pode fornecer antes, durante e depois da recuperação, para que sua equipe possa decidir com segurança quando os dados estiverem prontos para serem confiáveis ​​novamente.

Lista de verificação de avaliação de prontidão para recuperação do CDC

Para cada pergunta, responda: Sempre, às vezes ou não.

Visibilidade da recuperação

• Os operadores conseguem determinar onde o processamento foi interrompido?
• Eles conseguem identificar o último estado de processamento confiável?
• Será que eles conseguem entender a quantidade de dados afetados?
• Eles conseguem determinar quais consumidores a jusante estão expostos?
• Eles conseguem informar se o histórico de origem necessário ainda está disponível?

Execução de recuperação

• Será que a equipe consegue se recuperar sem depender de um único especialista?
• Os procedimentos de recuperação estão documentados e são revisados ​​regularmente?
• É possível monitorar o progresso da recuperação de forma eficaz?
• Os planos de recuperação são claramente compreendidos antes que um incidente ocorra?
• A equipe consegue prever quando uma ressincronização mais ampla poderá ser necessária?

Validação de recuperação

• A equipe consegue validar os dados recuperados sem depender inteiramente de investigação manual?
• É possível identificar discrepâncias entre a origem e o destino de forma eficiente?
• É possível investigar sistematicamente alterações ausentes, exclusões, duplicatas ou valores obsoletos?
• A organização pode apresentar provas que sustentem a decisão de que está tudo bem?

prontidão operacional

• As dependências subsequentes estão documentadas?
• Os riscos de repetição e o comportamento do consumidor são compreendidos?
• As responsabilidades de resposta estão claramente atribuídas?
• A organização registra as lições aprendidas após eventos de recuperação?
• Um novo membro da equipe pode participar de forma razoável da recuperação utilizando processos documentados?

Capacidade da plataforma

• A plataforma oferece visibilidade significativa do estado de reinicialização?
• Fornece diagnósticos úteis durante falhas?
• Suporta a recuperação histórica quando aplicável?
• Isso ajuda os operadores a entender o que aconteceu durante a interrupção?
• Isso auxilia na validação pós-recuperação?

Orientações de pontuação

Na maioria dos casos: a recuperação provavelmente é um processo operacional documentado, e não uma atividade especializada.

Uma combinação de consistência e inconsistência: o ambiente está funcionando, mas a recuperação pode depender do conhecimento individual, de etapas manuais ou de práticas inconsistentes.

Vários "nãos": O risco de recuperação provavelmente é maior do que o esperado. O problema pode não ser mais o incidente individual. Pode ser visibilidade, maturidade do processo, capacidades da plataforma ou uma combinação dos três.

Conclusão

Um incidente do CDC não indica automaticamente um problema na plataforma. Incertezas repetidas, sim. Se a recuperação depende repetidamente de:

• conhecimento tribal
• Investigação manual
• Recargas amplas
• Validação difícil
• Visibilidade limitada
• Decisões de recuperação difíceis de defender

O problema pode ser maior do que a interrupção específica.

Os ambientes de CDC mais robustos fazem mais do que simplesmente transferir dados. Eles ajudam as equipes a entender o que aconteceu, a se recuperar com segurança quando ocorrem interrupções e a comprovar que os dados resultantes são confiáveis ​​posteriormente.

Porque:

Correr não é o mesmo que ser saudável.

Reiniciado não é o mesmo que recuperado.

Recuperado não é o mesmo que validado.

E um oleoduto verde não é prova de que os dados estejam corretos.

*NIST SP 800-34 Rev. 1: Guia de Planejamento de Contingência