APRENDER. PRATICAR. EVOLUIR.Sair do apoio reforçado com condições explícitas
O período de apoio reforçado, frequentemente chamado hypercare, aproxima desenvolvimento e operação durante a estabilização. O seu fim no calendário não demonstra transferência de capacidade. Num caso fictício, APS executa diagnóstico mas ainda não consegue recuperar o processamento com a sua conta. Identifica a tarefa em falta, o acesso ou conhecimento necessário e quem responde até haver autonomia demonstrada ou outra cobertura explicitamente aceite. A descrição pública da Google sobre entrada de serviços em SRE mostra aprendizagem prática e transferência progressiva de responsabilidade num contexto organizacional específico. Aplica o princípio de evidência às responsabilidades locais, sem impor o modelo Google ao banco. Uma passagem pode conservar defeitos aceites, desde que impacto, mitigação, dono, prazo e revisão estejam claros. “Aceite e aberto” não significa “corrigido”. Uma data de revisão ultrapassada exige uma decisão atual; não renova automaticamente a aceitação anterior.
Comunicar estados sem misturar marcos
Distingue publicado, instalado, ativado e validado. Se o pacote está instalado, mas a flag permanece desligada e a validação de negócio só começa às 09:00, comunica essas condições separadamente. Durante uma recuperação, a API pode estar disponível às 20:10, a fila terminar às 20:45 e a reconciliação ser aceite às 21:00. Há 35 minutos entre disponibilidade da API e fim da fila, mais quinze até reconciliação, mas estes dados não permitem classificar os cinquenta minutos como indisponibilidade total. Escolhe a medida que corresponde ao serviço e ao compromisso que estás a reportar. Um estado sintético verde que esconda reconciliação pendente pode induzir uma decisão errada do negócio. Confirma ainda consumidores pouco frequentes: três dias sem tráfego não demonstram que um consumidor mensal deixou de precisar do endpoint antigo. Liga desativação a evidência de dependências, decisão e condições de retenção aplicáveis.
Transformar o incidente numa alteração verificável
Numa revisão após incidente, separa factos, hipóteses causais e ações. O aumento de erros quatro minutos após a release merece investigação, mas ocorreu também uma mudança de rede; a ordem temporal, por si só, não prova a causa. Reconstrói a sequência, compara contexto e indica o que ainda não foi observado. Uma ação “melhorar testes” não tem condição de conclusão verificável. Formula antes: “o responsável de testes acrescenta a combinação de configuração afetada e demonstra deteção do erro antes da promoção, até à data acordada”. Um ticket fechado sem executar esse teste demonstra apenas estado administrativo. A aprendizagem exige confirmar o efeito pretendido e rever resultados. Nas orientações Google SRE, ações concretas e acompanhadas tornam a revisão útil. Usa exemplos próprios e seleciona mudanças relacionadas com as condições contribuintes; acrescentar uma aprovação genérica não resolve, por si só, permissões em falta ou evidência desatualizada.
Fechar responsabilidades e voltar a testar o controlo
Duas recuperações falharam por permissões em falta. A equipa atualizou o documento e fechou o ticket, mas APS ainda não executou a tarefa. O próximo resultado útil é uma execução observada pela conta operacional no contexto aplicável, com tratamento da falha se persistir. Se outros serviços partilham o padrão, identifica responsáveis e verifica aplicabilidade antes de alterar todos. Mantém as ações residuais visíveis após a passagem, incluindo datas de revisão vencidas. Um pedido novo fora do âmbito não deve consumir silenciosamente a capacidade reservada a um batch crítico: expõe prioridade, impacto e decisão de afetação. No exercício, redige uma nota em inglês com estado observado, lacuna, responsável, próxima evidência e decisão necessária. Discute uma alternativa aceitável, como prolongar cobertura temporária definida, e o seu custo. Não declares todos os problemas resolvidos apenas para concluir a release. O modelo Python da aula anterior demonstra diferenças entre marcos e revisão vencida, mas não substitui a observação destas tarefas ou a aceitação dos responsáveis.
Estado observado | Limitação | Responsável | Próxima evidência | Prazo/decisão
API disponível 20:10 | fila pendente | responsável APS | fim de processamento 20:45 | atualizar negócio
Ticket fechado | eficácia não testada | responsável de testes | executar combinação afetada | data acordadaAPS diagnostica mas não recupera; o consumidor mensal continua por confirmar; uma ação residual ultrapassou a revisão. O relatório mantém três linhas com donos e decisões, em vez de uma passagem “verde” pelo fim do calendário.
Armadilhas comuns
Tratar ticket fechado como eficácia demonstrada; confundir aceitação com correção; concluir desativação com tráfego curto; atribuir causa apenas pela sequência temporal; esconder capacidade consumida fora do âmbito.
Tópicos relacionados: Passagem a APS · Melhoria após incidente · Obsolescência e desativação
Fecha a release com estados e responsabilidades claros; confirma o resultado das ações antes de declarar que a aprendizagem foi aplicada.
Referência: The Evolving SRE Engagement Model · Google SRE release and canary guidance; GitHub immutable releases and GitLab release evidence and deployment safety; DORA five-metric model; inspected 2026-10-01