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

Antes de escolher uma plataforma de CDC, teste o estado de reinicialização, a recuperação, a validação, o comportamento de reprodução, os diagnósticos e os limites de recuperação.

A maioria das demonstrações do CDC mostra o processo funcionando conforme o planejado. Os dados são transferidos. A meta é atualizada. O painel permanece verde. Mas uma avaliação de recuperação do CDC precisa testar uma questão diferente:

O que acontece quando o caminho se rompe?

As diretrizes do AWS Well-Architected recomendam testar a resiliência em condições adversas em ambientes o mais próximos possível da produção. Elas alertam contra o projeto de resiliência sem verificar como a carga de trabalho se comporta quando ocorrem falhas e cargas inesperadas.*

Uma prova de conceito (POC) da plataforma oferece à sua equipe a oportunidade de observar como o sistema se comporta quando a replicação atrasa, para durante o processamento ativo, perde o acesso imediato ao histórico de origem necessário ou precisa comprovar que o destino recuperado está correto.

O objetivo não é construir uma falha artificial que nunca ocorreria em produção. É avaliar se a plataforma torna a recuperação visível, testável e defensável em condições que refletem o seu ambiente.

Resposta rápida: Como você deve testar a recuperação do CDC durante um teste de ponto de atendimento (POC)?

Um plano de recuperação prático do CDC deve testar oito áreas:

1. Visibilidade de atrasos e pendências
2. Visibilidade do estado de reinicialização e recuperação
3. Atualização histórica
4. Progresso de recuperação e estagnação da recuperação
5. Diagnóstico e evidências de falha
6. Validação pós-recuperação
7. Repetição e impacto no consumidor final
8. Limites de recuperação e fronteiras de ressincronização

Para cada teste, pergunte-se qual condição foi introduzida, o que os operadores puderam ver, qual estado a plataforma manteve, o que aconteceu durante a recuperação, quais evidências permaneceram posteriormente e o que a plataforma não conseguiu estabelecer. Cada conclusão deve estar relacionada à origem, ao destino, à topologia, à versão, à configuração e ao cenário de falha testado.

O padrão é simples: mostre-nos o que acontece quando o caminho se rompe. Em seguida, mostre-nos como saberíamos que a recuperação foi bem-sucedida.

Antes da prova de conceito: comece identificando as lacunas que você precisa testar.

Chegar a este estágio significa que você provavelmente já determinou que a recuperação merece uma avaliação mais detalhada. Não repita toda a avaliação de prontidão dentro da Prova de Conceito (POC). Em vez disso, incorpore as lacunas documentadas no ambiente atual ao plano de testes.

Se essas lacunas não foram documentadas, comece com "Quando um problema de recuperação do CDC se torna um problema de plataforma ?" e documente as lacunas de recuperação no ambiente atual antes de definir a prova de conceito.

Em seguida, defina o ambiente que a prova de conceito (POC) pretende representar. No mínimo, documente:

• Tecnologias e versões de origem e destino
• Métodos de captura e aplicação
• Topologia de replicação
• Taxas de transação normais e de pico
• Políticas de registro de origem, diário ou histórico retido
• Condições de rede e alvo
• Requisitos de transformação e alteração de esquema suportados
• Objetivos de recuperação e cenários inaceitáveis ​​de recarga ou ressincronização
• Consumidores a jusante, sensibilidade à repetição e dependências de negócios.

Uma demonstração genérica fornece evidências limitadas.

A questão importante não é: a plataforma suporta recuperação? É: como a recuperação funciona para nossa origem, destino, configuração, carga de trabalho e requisitos operacionais?

Das capacidades às evidências

Os nomes das funcionalidades não são prova. Os testes abaixo mudam o foco da conversa de "Vocês apoiam isso?" para "Mostrem-nos como funciona quando a recuperação se torna necessária".

Teste POC 1: Fazer com que a replicação fique para trás

Crie uma condição controlada na qual a replicação permaneça ativa, mas não consiga acompanhar a atividade da fonte. O objetivo é determinar se os operadores conseguem distinguir entre operação normal, atraso crescente, recuperação progressiva e recuperação paralisada.

Solicite ao fornecedor que demonstre a magnitude do atraso, o tamanho e a direção do backlog, onde o atraso está ocorrendo, se o processamento está avançando e o que acontece com a exposição do histórico de origem à medida que a lacuna aumenta.

Que demonstração poderosa!

Tanto a magnitude quanto a direção do problema são visíveis. Os operadores não precisam inferir o progresso da recuperação a partir de um indicador de status verde. Eles podem saber o quanto está atrasado em relação à meta, onde ocorre o atraso e se as condições estão melhorando.

Teste POC 2: Interromper a replicação durante o processamento ativo

Implemente uma interrupção segura e suportada enquanto as transações estiverem em andamento. Um desligamento limpo pode demonstrar o comportamento normal de reinicialização, mas pode não mostrar o que acontece durante uma interrupção abrupta, uma interrupção de rede, uma falha no destino ou outro evento realista.

Solicite ao fornecedor que mostre qual estado de reinicialização ou de processo foi mantido, o que cada marcador significa, onde o processamento deverá ser retomado, qual limite de transação se aplica e se o trabalho pode ser repetido ou reprocessado.

Que demonstração poderosa!

Os operadores podem inspecionar o estado relevante antes da reinicialização e entender o que a plataforma fará. O fornecedor pode distinguir os estados de captura de origem, processamento, transporte e aplicação de destino, quando essas distinções forem aplicáveis.

Teste POC 3: Testar o suporte à recuperação histórica

Para CDC baseado em logs, as alterações acumuladas podem depender de logs ativos, logs arquivados, journals ou outros históricos de origem retidos. Teste a cadeia de dependências sob o modelo de retenção que seu ambiente de produção utilizará.

Peça ao fornecedor que explique qual histórico é necessário, onde ele reside, quem controla a retenção, como ele é recuperado, se a plataforma pode processá-lo diretamente e onde termina o limite de recuperação suportado.

Que demonstração poderosa!

O fornecedor demonstra como a plataforma localiza e processa o histórico necessário e o que os operadores podem monitorar. A resposta é específica para a origem e a configuração, não uma afirmação genérica de que a recuperação de logs arquivados é suportada.

Teste POC 4: Criar uma recuperação estagnada

Comece a recuperar o atraso e, em seguida, restrinja as condições de origem, rede, aplicação ou destino para que a lacuna existente pare de diminuir ou aumente. Isso testa se a plataforma distingue atividade de progresso real.

Solicite ao fornecedor que mostre a direção do backlog, o processamento atual e as taxas de aplicação, o avanço da posição, as novas tentativas ou a limitação de fluxo, o impacto na origem e no destino, e a base para qualquer estimativa de conclusão.

Que demonstração poderosa!

O progresso e a recuperação estagnada apresentam diferenças significativas. Os operadores podem verificar se a diferença está diminuindo, se mantendo estável ou piorando, e as estimativas de conclusão são baseadas em condições observadas, e não na capacidade de produção teórica.

Teste POC 5: Preservar e investigar evidências de falha

Simule uma falha representativa na fonte, na rede, na replicação ou no destino e avalie quais evidências permanecem disponíveis antes e depois da reinicialização.

Solicite ao fornecedor que demonstre como os operadores investigam a falha, como o contexto de processamento e os erros são correlacionados, por quanto tempo as evidências são retidas, o que pode ser exportado e quais evidências adicionais de origem, rede ou destino ainda são necessárias.

Que demonstração poderosa!

Os operadores podem conectar o que o pipeline estava processando, como o atraso ou a taxa de transferência mudaram, qual componente gerou o erro, qual estado permaneceu depois e qual ação de recuperação foi tomada. Evidências úteis não desaparecem silenciosamente quando o processo é reiniciado.

Teste POC 6: Validar o alvo recuperado

Uma reinicialização bem-sucedida comprova que a replicação foi retomada. Isso não comprova que o destino esteja completo, atualizado e correto. Inclua discrepâncias conhecidas sempre que possível e seguro, como uma inserção ou atualização ausente, um registro inesperado, um duplicado, uma exclusão ausente, um valor desatualizado, uma diferença de transformação ou um problema de ordenação onde a sequência é importante.

Solicite ao fornecedor que demonstre como as diferenças entre a origem e o destino são identificadas, quais objetos ou janelas de incidentes podem ser definidos no escopo, quais chaves e valores são comparados, como as discrepâncias são apresentadas e qual validação adicional permanece sob a responsabilidade da equipe operacional.

Que demonstração poderosa!

A plataforma identifica diferenças específicas e explica claramente o que a comparação comprova e o que não comprova. Uma contagem de linhas correspondente ou um processo concluído não são apresentados como evidência universal de integridade.

Teste POC 7: Repetição do teste e impacto no consumidor final

Acumule as alterações durante uma interrupção e processe-as durante a recuperação. Inclua tipos de eventos sensíveis à reprodução sempre que isso for seguro. A reprodução não é automaticamente um problema, mas a reprodução invisível ou mal compreendida pode ser.

Solicite ao fornecedor que mostre a janela de reprodução, os registros ou tipos de eventos afetados, o volume e a taxa esperados, o comportamento de repetição ou processamento repetido, as considerações de ordenação e quais evidências permanecem após a recuperação.

Por que a idempotência é importante

Uma plataforma de replicação não pode tornar um aplicativo de pagamento, notificação, inventário ou fluxo de trabalho idempotente. Ela pode fornecer informações suficientes para que as equipes subsequentes decidam se a supressão, a desduplicação, o sequenciamento ou a ativação coordenada são necessários.

Que demonstração poderosa!

A reprodução é visível e atribuível. As equipes subsequentes podem estimar o que chegará e quando, entender se o processamento repetido pode ocorrer e avaliar se são necessárias medidas de segurança do lado do consumidor.

Teste POC 8: Demonstrar o limite de recuperação

Cada plataforma CDC apresenta condições em que a reinicialização ou a recuperação não são as soluções adequadas. Uma resincronização direcionada, uma resincronização mais abrangente ou uma recarga completa podem ser necessárias quando o estado de recuperação não estiver disponível, o histórico de origem necessário não puder ser processado, o destino for inconsistente, ocorrerem alterações não suportadas ou a validação revelar discrepâncias significativas.

Peça ao fornecedor que explique quais cenários suportam reinicialização, recuperação histórica, ressincronização direcionada, ressincronização mais ampla ou recarregamento, e quais evidências indicam aos operadores que o caminho de recuperação normal não se aplica mais.

Que demonstração poderosa!

A resposta é específica, qualificada e vinculada ao ambiente proposto. Um limite de recuperação honesto é sinal de maturidade, não de fraqueza.

Documente o que o POC realmente comprovou.

Uma prova de conceito (POC) rigorosa deve deixar um legado que vai além de capturas de tela, anotações de reuniões e uma declaração de que o teste foi aprovado. Para cada cenário, registre as condições do teste, as evidências observadas, o resultado da recuperação, a avaliação, as limitações e o acompanhamento necessário.

O objetivo não é atribuir uma pontuação genérica de recuperação. É determinar se a plataforma demonstrou as capacidades que seu ambiente exige nas condições testadas.

Utilize a Planilha de Avaliação do Plano de Recuperação do CDC . Esta planilha serve como registro para a avaliação. Use-a para:

• Defina a origem, o destino, a topologia, a carga de trabalho, o modelo de retenção e os objetivos de recuperação.
• Planeje os oito cenários de recuperação.
• Capturar comportamentos observáveis ​​e evidências retidas
• Capacidades de avaliação conforme demonstrado, parcialmente demonstrado, não demonstrado ou não aplicável.
• Limitações, dependências e questões em aberto do documento
• Compare os fornecedores apenas em condições equivalentes.
• Fundamente a recomendação final com evidências.

Uma funcionalidade não deve ser classificada como "Demonstrada" com base apenas na documentação do produto, material de apresentação ou explicação verbal. A classificação deve refletir o comportamento observável e as evidências coletadas da configuração testada.

Será que nossa equipe operacional normal poderia usar as evidências demonstradas aqui para entender a falha, gerenciar a recuperação e defender a liberação do sistema sem depender inteiramente do fornecedor ou de um único especialista interno?

Erros comuns no ponto de atendimento de recuperação do CDC

Testar apenas o caminho feliz: Um teste inicial de carga e replicação em estado estacionário bem-sucedido estabelece a funcionalidade básica. Eles não estabelecem o comportamento de recuperação. Inclua cenários controlados de atraso, interrupção, recuperação, validação e limites de recuperação.

Utilizando apenas desligamentos limpos: Desligamentos limpos podem não expor o mesmo estado de reinicialização, transação, diagnóstico ou comportamento de nova tentativa que interrupções abruptas. Teste condições de falha suportadas que reflitam riscos realistas de produção.

Aceitar rótulos sem definições: Termos como "exatamente uma vez", "perda de dados zero", "auto-recuperação", "recuperação automática", "recuperação perfeita" e "validação integrada" podem descrever comportamentos diferentes em diversas plataformas. Exija uma definição vinculada à configuração testada e ao cenário de falha.

Tratar o status do processo como evidência de recuperação: estar em execução não significa estar em dia. Estar em dia não significa estar validado. Estar validado dentro de um escopo não comprova a correção em todas as dimensões.

Não incluir dados com discrepâncias conhecidas: Se cada teste começar e terminar com dados corretos, a prova de conceito não estabelece o que a plataforma consegue detectar quando algo está errado. Inclua dados ausentes, inesperados, excluídos, desatualizados ou repetidos sempre que possível.

Ignorando o comportamento subsequente: a recuperação não para na tabela de destino. Alterações atrasadas e reproduzidas podem desencadear aplicativos, eventos, notificações, pagamentos, fluxos de trabalho ou decisões subsequentes.

Não documentar o que não foi demonstrado: Uma pergunta sem resposta não deve ser automaticamente considerada uma capacidade presumida. Registre-a como:

Coloque as alegações de recuperação à prova.

Um POC (Prova de Conceito) do CDC deve demonstrar mais do que a replicação bem-sucedida em condições normais. Deve mostrar o que os operadores observam quando o pipeline fica atrasado, qual estado de recuperação permanece após a falha, onde o processamento pode ser retomado, de que depende a recuperação histórica, como o progresso da recuperação é medido, quais evidências de diagnóstico sobrevivem, como o alvo é validado, o que a reprodução significa para os consumidores subsequentes e onde termina o caminho de recuperação suportado.

Aplique os mesmos testes a todas as plataformas, incluindo aquela que já está em operação no seu ambiente. A capacidade de recuperação não deve ser presumida com base no nome de um recurso ou em uma demonstração bem elaborada. Ela deve ser comprovada por meio de comportamento observável e evidências documentadas.

Mostre-nos o que acontece quando o caminho se rompe. Depois, mostre-nos como saberíamos que a recuperação foi bem-sucedida.
 

*AWS Well-Architected: Teste a resiliência usando engenharia do caos, novembro de 2024