01Controlos integrados para fluxos fiáveis
| Controlo | Benefício operacional |
|---|---|
| Recuperação orientada por políticas | O Flower combina classificação de tentativas, backoff e políticas de circuitos para automatizar a recuperação no fluxo. O contexto de execução e os alertas proativos mostram o progresso e orientam a ação seguinte. |
| Verificação da conclusão | Combine verificações de conclusão de cópias com validação de esquema, contagens e totais de negócio para dados processados. Os critérios de aceitação integram o fluxo, com evidências de entrega disponíveis às equipas. |
| Operações de base governadas | Integre consultas, escritas preparadas e transações explícitas em fluxos declarativos. As permissões governam o acesso, enquanto validação, reconciliação e registos ligam a movimentação das linhas às políticas operacionais. |
Classificação de falhas
02Determine o que falhou antes de decidir o que repetir.
O Flower classifica condições de transporte, resultados de qualidade e estados do destino para escolher a resposta adequada. Recuperação, reconciliação, quarentena e alertas trabalham em conjunto no mesmo fluxo.
Transitório e repetível
O Flower responde a indisponibilidades temporárias com tentativas controladas, backoff e jitter. O progresso, as filas e os alertas mantêm-se visíveis na mesma visão operacional para acompanhar entregas recorrentes.
Permanente e acionável
Quando dados ou acessos precisam de atenção, o Flower isola a unidade afetada e preserva o contexto. As políticas de quarentena e notificação encaminham a informação à equipa responsável para uma resposta direcionada.
Incerto, reconciliar primeiro
A ligação pode falhar após commit no destino. Flower verifica identidade, tracking, contagens ou checksums antes de replay para não duplicar resultado incerto.
Ciclo de controlo da recuperação
03Avance apenas quando a unidade estiver segura e comprovada.
O mesmo ciclo acompanha os dados da origem ao destino. A recuperação transitória de rotina é automática; resultados inseguros ou incertos preservam contexto, seguem a política e geram sinal apenas quando é necessário julgamento humano.
Escolha o limite de retoma
Use objeto, ficheiro, lote determinístico ou menor unidade segura. Guarde o checkpoint fora do estado transitório e avance após confirmação no destino.
Condicione o avanço à validação
Fim do transporte é apenas um sinal. Estrutura, esquema, contagens, regras, integridade e reconciliação decidem publicação, revisão ou rejeição.
Mantenha ligada a evidência de recuperação
Registe tentativas, classe, identidades, validação, quarentena, reconciliação e ação final numa linhagem. Alertas incluem contexto para agir.
Moldado pela produção
04Fiabilidade conquistada sob a pressão de dados reais.
O Flower evolui desde 2019 em cargas de produção contínuas, com grandes volumes de telecomunicações e dados financeiros críticos. Essa experiência orienta a abordagem integrada de recuperação, validação e visibilidade.
A falha é explícita
Transferências incompletas, registos inválidos e violações de políticas tornam-se estados visíveis com tratamento definido, não defeitos silenciosos a jusante.
A recuperação segue as suas políticas
Orçamentos de tentativas, backoff, limites de retoma, quarentena, reconciliação no destino e ações de ciclo de vida adaptam-se ao endpoint e à carga em vez de serem improvisados num incidente.
As evidências permanecem ligadas
Linhagem, metadados, eventos, métricas e alertas ajudam a reconstruir o que foi movimentado, alterado e requer atenção.
Aceitação da recuperação
05Especifique a recuperabilidade antes do primeiro incidente.
Avalie a autorrecuperação com a sua carga, critérios claros de entrega, políticas de recuperação e evidências. Repita as verificações à medida que endpoints e políticas evoluem para levar um modelo fiável da avaliação à produção.
Escreva o contrato de recuperação
Para cada unidade, indique perda, duplicação e alteração de ordem permitidas, atraso máximo e evidência exigida no destino. Um contrato preciso evita considerar bem-sucedido um processo reiniciado quando o resultado dos dados permanece incerto.
Injete classes de falha distintas
Teste separadamente indisponibilidade da origem, interrupção do transporte, limitação, credenciais inválidas, rejeição de esquema, payload corrompido, armazenamento local cheio e timeout do destino. Cada caso deve seguir o percurso previsto de repetição, paragem, quarentena ou reconciliação.
Force um commit ambíguo
Corte a ligação depois de o destino poder ter feito commit, mas antes de a confirmação chegar ao emissor. Valide identidade, contagens, checksums ou outro sinal durável antes de permitir qualquer replay.
Reinicie além do limite de estado
Reinicie worker, host e serviço de estado dependente em momentos diferentes. Confirme que checkpoints, tentativas pendentes, contexto de quarentena e linhagem sobrevivem juntos e que atualização ou rollback não reinterpreta trabalho em curso.
Meça pressão e recuperação
Mantenha um endpoint indisponível até criar uma acumulação realista e restaure-o. Meça idade da fila, crescimento do disco, taxa de tentativas, throughput útil de recuperação, saturação e se o tráfego novo fica bloqueado ou protegido.
Comprove quarentena e replay
Envie unidades inválidas ou fora da política juntamente com trabalho válido. Confirme que dados inseguros param sem bloquear o restante, preservam contexto para diagnóstico e podem ser corrigidos e repetidos sem contornar validação nem duplicar unidades concluídas.
Comprove a restauração do estado durável
Remova ou corrompa o armazenamento de estado ativo e restaure-o a partir da cópia ou réplica documentada. Meça a lacuna do ponto de recuperação, reconcilie evidências de origem e destino e confirme que o checkpoint reconstruído não ignora trabalho elegível nem republica silenciosamente unidades concluídas.
Teste a passagem ao operador
Esgote o orçamento de tentativas e provoque uma falha permanente. O alerta deve identificar unidade, origem e destino, último limite seguro, tentativas, evidência, responsável e próximas ações aprovadas sem reconstrução entre ferramentas desligadas.
Condicione versões a exercícios de recuperação
Mantenha matriz de falhas, evidências esperadas e tempos de recuperação como suite repetível. Execute-a após alterações de runtime, conector, esquema, política ou infraestrutura para que recuperabilidade seja propriedade testada da versão.