APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
GitOps acrescenta uma fonte versionada e um agente que tenta reconciliar o estado observado. Uma alteração manual pode desaparecer se a fonte continuar a declarar outra configuração. Durante um incidente, coordena a mitigação com esse mecanismo: atualiza a fonte aprovada ou usa uma suspensão temporária autorizada com responsável e retoma definida. O número de réplicas não é o único critério de sucesso. Observa fila, latência, erros e capacidade a jusante. Se seis workers saturam a base, a escala apenas deslocou o problema. Regista o motivo da exceção, a configuração final aceite e o critério para voltar à capacidade normal depois do pico.
Aplicação guiada
Probes respondem a perguntas diferentes. Readiness avalia se o Pod deve receber tráfego normal; falhar readiness não é, por si, a ordem de restart associada a liveness. Uma aplicação em Running pode continuar sem estar pronta. Para um container reiniciado, logs da instância anterior podem ajudar quando ainda estão disponíveis; seleciona namespace e container e usa --previous. Recolhe evidência antes de destruir objetos. O rollback do Deployment também tem limites: repor o template não desfaz uma migração incompatível de schema. Antes de reverter imagem, avalia dados e dependências com os responsáveis. A recuperação fica concluída quando a transação e os controlos relevantes foram validados, não apenas quando o comando termina.
Uma alteração manual de três para seis réplicas regressa a três: compara primeiro a fonte reconciliada e os eventos, antes de repetir o comando.
Armadilhas comuns
Lutar com o reconciliador; esquecer retoma; Running como Ready; rollout undo como recuperação da base; apagar evidência cedo.
Tópicos relacionados: Observabilidade, objetivos e ecossistema · Estado desejado, controlo e containers
Uma release precisa de intenção coerente, evidência funcional e recuperação compatível com os dados.
Referência: OpenGitOps principles · KCNA current four-domain curriculum; edition date unconfirmed