Resiliência com IA: fornecedor alternativo só ajuda se a troca foi testada

Gergely Orosz publicou no The Pragmatic Engineer trechos de Building Resilient Distributed Systems, de Sam Newman, sobre recuperação de desastres e riscos de incorporar IA ao produto.[19] O texto relaciona continuidade a monitoramento, idempotência, timeouts, retries e procedimentos de recuperação.[19] A questão de engenharia não é quantos fornecedores aparecem no diagrama. É o que o sistema continua entregando quando uma dependência deixa de funcionar.

O que muda para quem desenvolve

O planejamento usa RPO para expressar a perda de dados tolerável desde o último ponto recuperável e RTO para o tempo aceitável de retorno.[19] O RTO inclui restaurar dados, obter capacidade e redirecionar tráfego.[19] Newman também alerta para a disputa por infraestrutura durante uma crise e recomenda considerar reservas, prioridades e capacidade redundante.[19]

Ao usar modelos externos, o produto precisa prever indisponibilidade, rate limiting e esgotamento de cota.[19] Degradação controlada pode manter menos funções disponíveis, e rotas alternativas para um modelo podem diferir em disponibilidade e atraso de versões.[19] Formato parecido de API não comprova equivalência de comportamento.[19]

Minha leitura é que há uma diferença entre opção de troca e dependência adicional. Se o fluxo exige respostas de todos os provedores, adicionar mais um não cria uma alternativa. O texto faz justamente esse alerta sobre transações que dependem simultaneamente de vários fornecedores.[19]

Para o desenho do produto, classifique a IA como etapa obrigatória, assistência opcional ou processamento adiável. Essa classificação deve determinar o comportamento de falha, em vez de deixar cada chamada inventar sua própria política.

Como aplicar

Escolha uma operação importante e escreva seu contrato de continuidade. Defina a perda tolerável, o prazo de retorno, a capacidade mínima e o que o usuário verá se a IA estiver indisponível.

Execute em homologação dois exercícios separados: restaurar dados e substituir o modelo. Para a troca, mantenha o mesmo conjunto de entradas e a mesma avaliação de saída. Inclua casos em que o modelo precisa se abster ou devolver uma estrutura válida.

Simule limite de requisições, falta de cota e interrupção durante uma resposta. Observe se o sistema devolve uma alternativa útil, adia a tarefa ou encerra com erro explícito. Se houver ação externa, confira que uma tentativa de recuperação não duplica o efeito.

Registre latência até o início do streaming, duração completa, resultado funcional e gasto por tarefa. Newman recomenda acompanhar o progresso da resposta e a qualidade, não apenas sucesso HTTP.[19] Use esses dados para ajustar timeouts e decidir se a alternativa é operacionalmente aceitável.

Cuidados e limites

Mudanças de modelo exigem testes funcionais e avaliações de IA, e prompts precisam ser reavaliados ao migrar.[19] Um intermediário também pode depender integralmente de outro fornecedor.[19] Verifique se a rota alternativa remove a dependência que você pretendia contornar.

Metas menores de recuperação trazem custo e complexidade maiores.[19] Não prometa continuidade sem medir o caminho de restauração e a capacidade necessária. Uma alternativa documentada mas nunca exercitada ainda é uma hipótese de recuperação, não evidência de resiliência.

Fonte

[19] Fonte: The Pragmatic Engineer, com trechos de Sam Newman