Fechar o ciclo com melhorias verificadas

Defina o ciclo que quer fechar

O software produz evidências durante o uso: erros, atrasos, pedidos de apoio, incidentes, ocorrências de manutenção e trabalho manual repetido. Um ciclo de vida completo devolve essas evidências às decisões de engenharia.

Software que se melhora a si próprio pode significar que a automação ajuda a identificar, propor, implementar e verificar alterações. Não significa necessariamente que um modelo se treina a si próprio. Indique que parte muda: código da aplicação, configuração, testes, instruções, fluxo de trabalho ou parâmetros do modelo.

A autorrecuperação repõe uma condição operacional conhecida. A melhoria autónoma altera o sistema para produzir um resultado melhor no futuro. A segunda afirmação exige uma comparação e proteção contra regressões.

Acompanhe uma observação ao longo do ciclo de vida

A sequência abaixo é uma proposta de método de engenharia. Não é uma afirmação de que um produto executa todos os passos autonomamente.

Mantenha ligações entre estes resultados. Uma ação de postmortem que diga «melhorar a monitorização» é difícil de verificar. Um sinal definido, um responsável, um limiar e uma resposta testada tornam a conclusão observável.

Mantenha a avaliação independente da proposta

Um agente pode criar uma correção e propor testes. A equipa continua a ter de verificar se esses testes detetam o problema original. Preserve um conjunto de avaliação versionado que a alteração não possa enfraquecer sem isso ser visível.

Para a fuga de memória fictícia, compare workloads e versões equivalentes. Inclua exports grandes, cancelamento, novas tentativas e casos de recusa de acesso. Use dados sintéticos que representem as estruturas relevantes sem expor registos de clientes.

Rejeite um export mais rápido se perder registos, contornar a autorização ou exceder o custo permitido. Defina estas restrições antes da otimização. Caso contrário, o sistema pode melhorar a métrica escolhida e piorar o serviço.

Se mudar as instruções ou o modelo de um agente, avalie o seu comportamento em tarefas representativas e falhas conhecidas. Mantenha a versão anterior disponível. Atualizar instruções não é evidência de que o modelo subjacente aprendeu com um incidente.

Lance e meça o resultado

Um lançamento canary disponibiliza uma versão candidata a uma população limitada. Compare os sinais da versão candidata e do grupo de controlo e defina quando expandir ou parar. Tráfego escasso ou workloads diferentes podem tornar a comparação inconclusiva. Orientações sobre canary.

A equipa fictícia regista uma referência inicial com um workload sintético fixo. Testa a correção, lança-a dentro de um limite aprovado e verifica períodos comparáveis em produção. Se as evidências continuarem insuficientes, regista a incerteza em vez de declarar um ganho.

Meça também o trabalho manual repetido. A automação pode reduzir trabalho operacional repetitivo, mas também precisa de manutenção e tratamento de falhas. Inclua estes custos ao avaliar o resultado. Orientações sobre trabalho operacional repetitivo.

Torne o registo de feedback utilizável

Use estes campos no exercício: observação e versão; referência inicial; causa proposta; critérios de aceitação; verificações de regressão; alteração e revisão; limite de lançamento; resultado medido; responsável e próxima revisão.

O Taiga Maintaining liga as ocorrências dos repositórios a trabalho de remediação. As Initiatives ligam uma alteração pretendida ao planeamento e à entrega. Estes elementos fornecem partes de uma cadeia de evidências. O responsável pelo serviço continua a ter de verificar o deployment e o resultado operacional. Maintaining, Initiatives.

Uma fábrica de software madura liga este trabalho entre produtos. Mantenha os direitos de decisão e os critérios de avaliação visíveis à medida que a automação aumenta. A prova final é um serviço melhor e verificado, não um número maior de alterações geradas.