Descrever o resultado necessário
Um serviço fictício de fundos precisa de recuperar a aplicação, renovar a identidade usada na ligação e validar um batch. Começa por descrever essas tarefas com o resultado que permite considerá-las realizadas. Na matriz do exercício, Ana e Bruno recuperam a aplicação; apenas Ana renova a identidade; Bruno e Carla recuperam o batch. Se Ana estiver ausente, existe cobertura nominal para duas tarefas e uma lacuna na terceira. A contagem de pessoas na equipa não identifica essa diferença. Regista a evidência de prática por tarefa, a versão do procedimento e as condições em que foi observada. A matriz serve para organizar a conversa e identificar dependências. Não é uma classificação geral do valor de cada pessoa nem uma autorização automática para produção.
Testar condições em conjunto
Acrescenta disponibilidade e autorização à competência observada. Bruno pode ter concluído um ensaio e continuar à espera de acesso aprovado para a janela de sábado. O registo correto conserva ambas as informações. Depois verifica simultaneidade: recuperação e validação exigem duas pessoas distintas no mesmo intervalo, mas só Ana demonstrou ambas. Cada tarefa tem um nome, embora o conjunto não seja executável. Duplicar Ana no calendário não cria uma segunda pessoa. No laboratório, um enumerador procura atribuições a pessoas distintas e encontra zero nesta configuração. Se Bruno demonstrar validação e estiver disponível e autorizado, passa a existir uma atribuição possível. O modelo verifica apenas as regras fornecidas. Não decide quem é competente, não avalia fadiga e não certifica uma escala real.
Delegar com limites utilizáveis
Uma substituição do gestor exige mais do que acesso ao calendário. Prepara decisões pendentes, resultados esperados, limites, contactos e escalamento, e confirma o entendimento da pessoa que assume. No exercício, a delegação cobre alterações de baixo risco em teste até às 18:00 UTC. Um pedido de produção excede o ambiente delegado mesmo com risco baixo. Uma aprovação exatamente às 18:00 também não satisfaz a regra explícita now < expires. Essa convenção pertence ao caso fictício e não é apresentada como regra geral de bancos. O passo adequado é obter decisão de autoridade válida, ou nova delegação explícita quando aplicável. Evita inventar autorização por causa da ausência do gestor. Regista a decisão real e o momento real, incluindo o impacto de esperar.
Rever a dependência após uma mudança
Dois substitutos podem executar o mesmo runbook e continuar dependentes de uma única pessoa para obter uma credencial. Examina esse caminho completo antes de declarar redundância. A solução precisa de respeitar o processo de acesso aplicável, sem copiar segredos para documentos partilhados ou usar contas pessoais de colegas. Mantém também evidência ligada à versão. Se N+1 altera o passo de identidade ensaiado em N, analisa o impacto e repete os passos afetados com as dependências necessárias. Preserva o resultado anterior como histórico. Para fechar o caso, apresenta ao responsável do serviço a lacuna, opções, capacidade necessária e condição de aceitação. Se o ensaio puder ser sequencial em vez de paralelo, essa alteração precisa de acordo e nova previsão de duração.
Task Demonstrated people
Recovery Ana, Bruno
Identity Ana
Batch Bruno, Carla
Ana absent -> identity gap
Recovery + validation exclusive to Ana -> no concurrent assignmentAna cobre recuperação e validação; se os dois papéis exigirem simultaneidade e exclusividade, cobertura por tarefa não basta.
Armadilhas comuns
Confundir nomes com capacidade; duplicar disponibilidade; esquecer uma credencial comum; alargar a delegação por conveniência.
Tópicos relacionados: Capacidade e carga operacional · Prontidão e aprendizagem
A cobertura precisa de funcionar nas condições da janela e dentro da autoridade realmente concedida.
Referência: Engineering Management · GitLab Handbook 2026; DORA current five-metric model; SRE and engineering guidance reviewed 2026-09-30