Classificação de falhas
01Determine o que falhou antes de decidir o que repetir.
Automação fiável não envia todos os erros para o mesmo ciclo. Flower distingue transporte, qualidade dos dados e resultados incertos no destino.
Transitório e repetível
Timeouts, limitação e indisponibilidade temporária usam tentativas limitadas, backoff, jitter e orçamento. O esgotamento torna-se acumulação ou alerta visível.
Permanente e acionável
Credenciais inválidas, permissões ausentes, esquema incompatível ou regra falhada não melhoram ao repetir. Pare a unidade, preserve contexto, isole e alerte o responsável.
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
02Avance 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
03Fiabilidade conquistada sob a pressão de dados reais.
A fiabilidade não é uma propriedade de uma apresentação. O Flower evolui desde 2019 com workloads contínuos em produção, incluindo volumes muito elevados de telecomunicações e dados financeiros críticos.
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 é controlada
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
04Especifique a recuperabilidade antes do primeiro incidente.
Uma promessa de autorrecuperação só se torna operacional quando a equipa acorda o que pode ser repetido, que evidência fecha uma unidade, como se reconcilia a incerteza e quando a automação deve parar. Converta essas expectativas em testes de versão e repita-os após cada alteraçã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.