APRENDER. PRATICAR. EVOLUIR.Comparar a regra pretendida com a configuração
Uma política fictícia exige duas pessoas distintas antes de implementar. A equipa lista duas pessoas como required reviewers num ambiente GitHub e recebe uma aprovação. A documentação consultada indica que uma aprovação da lista pode satisfazer essa regra da ferramenta. Portanto, listar dois nomes não demonstra o requisito local de duas decisões. Outro detalhe: Protected branches only permite qualquer branch quando não existem regras de proteção de branches. O nome da opção não é evidência suficiente do efeito pretendido. O Change Manager deve pedir análise da configuração aplicável, limitações do plano e controlo que cumpra a regra organizacional. Um ensaio autorizado num ambiente apropriado pode verificar o comportamento. Estas aulas analisam documentação; não configuraram nem testaram uma conta real. Não concluas que o fornecedor impõe a política fictícia ou que uma única opção satisfaz todos os requisitos da organização.
Distinguir decisões, início e ordem dos jobs
No GitLab, a documentação de deployment approvals consultada aplica-se aos planos Premium e Ultimate. Uma pessoa pode dar uma aprovação por deployment, mesmo pertencendo a vários grupos elegíveis. Se duas regras exigem duas aprovações no total, a participação de Ana em ambos os grupos não produz duas decisões. Após obter as aprovações exigidas, ainda é necessário iniciar manualmente o job. Sem início ou registo de execução, reporta aprovação concluída e execução pendente. Para concorrência, resource_group pode serializar jobs, mas isso não garante que uma versão antiga nunca seja instalada depois de uma nova. A proteção de jobs desatualizados usa a hora de início do job para determinar antiguidade, não a data do commit. Confirma configuração, ordem e comportamento aplicáveis antes de transformar um estado da ferramenta numa afirmação sobre o serviço. São observações documentais, não resultados de uma execução real nesta formação.
Tratar retirada e exceção com limites explícitos
Uma exceção fictícia permite uma intervenção urgente no serviço S até às 03:00, com revisão posterior atribuída. Às 02:50 surge uma mudança independente em T. Os dez minutos restantes não alargam o âmbito da decisão. Encaminha T pela via aplicável e mantém a revisão de S. Se a autoridade retirar a aprovação de S às 02:55, uma etiqueta antiga approved não deve sustentar o início. Regista e reconcilia o estado conhecido antes da execução. O modelo Python da aula anterior compara estado, serviço e intervalo, mas aceita esses campos como entradas: não autentica a autoridade nem confirma que o registo recebido é o mais recente. A fronteira temporal exclusiva usada no código é uma regra do exercício. Num processo real, esclarece o significado da validade e as condições de interrupção com os responsáveis, incluindo ações já em curso.
Fechar com correspondência e aprendizagem
Um comando termina com sucesso e a aplicação responde, mas um parâmetro de acesso ficou diferente da proposta. Antes do fecho, identifica a diferença, os efeitos e a decisão de correção ou regularização. Se houve uma intervenção adicional não registada, preserva a sequência factual; não alteres retroativamente a proposta para criar a aparência de autorização prévia. A orientação NIST de gestão de configuração sustenta a análise de impacto e a documentação de mudanças, sem representar uma política bancária. Nas métricas, declara população e definição: para trinta mudanças implementadas, das quais três falharam, a taxa interna definida como falhas por implementações é 10%. Vinte pedidos cancelados antes da execução não pertencem a esse denominador. Usa os resultados para investigar causas e experimentar melhorias. Se os atrasos vêm de uma reunião e as falhas de testes insuficientes, mais assinaturas podem não resolver o problema observado.
Requisito local | Configuração observada | Diferença | Dono | Decisão | Próxima verificação
Estado: proposta / aprovação / início / validação / fecho
Desvio: esperado / observado / impacto / tratamento / históricoDuas regras, uma aprovação de Ana e nenhum início de job: não reportar duas aprovações nem implementação concluída.
Armadilhas comuns
Confundir pessoas listadas com aprovações exigidas; somar grupos como decisões; inferir execução da aprovação; serialização como garantia de versão recente; reescrever o histórico.
Tópicos relacionados: Aprovação de deployment · Configuração e evidência · Revisão após implementação
Liga cada afirmação a uma regra aplicável e a evidência do estado real; conserva desvios e decisões posteriores.
Referência: Deployments and environments · NIST SP 800-128 updated October 2019; DORA five-metric model and change approval guidance; vendor documentation inspected 2026-10-01