← Production Support L3: investigar e recuperar
12 / 12 · 50 MIN

Acesso, mudança e limites de recuperação

Planeia intervenções com autoridade, dados compatíveis e critérios verificáveis de recuperação.

Acesso proporcional à tarefa

Uma intervenção deve usar identidade atribuível, âmbito necessário e duração adequada. Microsoft Entra PIM é um exemplo de mecanismo para ativação temporária e registo de acesso; não se presume que qualquer organização use a mesma configuração. Num exercício, consultar configuração de um resource group durante 30 minutos exige leitura nesse âmbito, não Owner permanente na subscrição. Se falta acesso, usa o caminho de aprovação previsto ou pede a um colega autorizado que execute a consulta sob a própria identidade. Ter acesso técnico também não transfere a decisão sobre impacto de negócio. Regista quem autorizou e quem executou.

Preparar evidência para partilha

Um pacote de diagnóstico deve permitir correlação sem divulgar segredos. Prepara uma cópia com a janela relevante, versões, erros e identificadores necessários. Remove tokens de sessão e outros campos sem utilidade para o destinatário; conserva os originais no local protegido definido pela organização. Num caso, o fornecedor precisa de relacionar falhas de autenticação, não de reutilizar a credencial capturada. O canal aprovado protege o envio, mas não justifica excesso de conteúdo. Confirma que a minimização preserva o sintoma e as relações temporais. Não assumes anonimato garantido apenas por aplicar um hash.

Reverter código e preservar dados

Antes de reverter uma release, identifica efeitos já persistidos e compatibilidade da versão anterior. Uma imagem antiga disponível não garante que consegue ler os registos novos. Num cenário, 200 instruções foram gravadas com outro formato e o negócio exige preservá-las. Suspende promoção, delimita a população e avalia com os responsáveis uma recuperação compatível, uma conversão suportada ou uma correção em frente. Nenhuma alternativa deve ser escolhida apenas por parecer mais rápida. Explica risco, tempo, pré-condições e verificação funcional. Reconciliar IDs e efeitos é parte do plano, não uma tarefa implícita após o deploy.

Isolamento antes do segundo escritor

Num cluster com dados partilhados e pressuposto de escritor único, perder comunicação com um nó não prova que ele deixou de escrever. A documentação RHEL HA usa fencing para assegurar isolamento antes de executar o serviço noutro nó. Num exercício, a rede de gestão falha e o storage mantém-se acessível: não uses ausência de ping como autorização para o segundo escritor. Se o mecanismo falhar, escala e aplica o procedimento suportado, incluindo eventual alternativa autorizada. Regista a confirmação efetiva. Este princípio não é um comando universal de failover; arquitetura, agente e versão controlam a implementação.

Medir RTO e RPO com critérios claros

RTO e RPO só ajudam a decidir quando o âmbito e a medição estão claros. Define previamente quando começa a interrupção e o que conta como recuperação funcional. Num ensaio, a falha é às 08:00, o restore termina às 08:30 e a aceitação às 08:52: se o endpoint acordado é aceitação, mede 52 minutos. Um ponto de recuperação às 07:48 deixa uma janela potencial de 12 minutos. Compara cada medida com o seu objetivo. A janela não demonstra exatamente que operações se perderam; essa conclusão exige reconciliação dos dados e efeitos.

Fechar exceções e transferir responsabilidade

Depois da recuperação, lista acessos, regras e limites temporários ainda em vigor. Cada exceção precisa de remoção confirmada ou extensão aprovada com responsável e prazo. Num exemplo, expira o privilégio temporário, mas permanece a regra de firewall criada para diagnóstico: os dois mecanismos têm ciclos diferentes. Entrega também estados desconhecidos, reconciliação pendente e critérios de aceitação ao turno seguinte. A receção de um ticket não basta para transferir coordenação; obtém aceitação explícita. Resume o estado efetivo do serviço, as decisões tomadas e a próxima ação, sem declarar concluído o trabalho que apenas mudou de responsável.

NA PRÁTICA

Num failover fictício, o nó ativo perde gestão mas mantém acesso ao storage. O segundo escritor só deve avançar após confirmação de isolamento pelo procedimento suportado.

Armadilhas comuns

Acesso como autorização de negócio; rollback de imagem como reversão de dados; ping falhado como fencing; restore como aceitação.

Tópicos relacionados: Passagem de turno e escalamento · Runbooks que permitem decidir · Diagnóstico Linux, JVM e conectividade

Leva esta ideia contigo

Define quem decide, o que pode mudar e como comprovar integridade e resultado antes de fechar.

Criar conta

Referência: Privileged Identity Management overview · DR Production Support L3 2026.4; Linux, JDK 25 HotSpot, OpenSSL 3.5 and Kubernetes examples require installed-version checks