APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
O suporte L2 transforma um pedido inicial numa situação suficientemente definida para agir ou escalar. A fronteira com L1 e L3 depende da organização: confirma o serviço abrangido, o runbook aplicável, os acessos autorizados e quem decide alterações. Começa pelo comportamento esperado e observado, utilizadores afetados, início conhecido e último sucesso confirmado. Um alerta mede uma condição; não demonstra sozinho o impacto de negócio. Junta sintomas relacionados sem perder os identificadores originais e evita criar várias intervenções concorrentes sobre a mesma falha. A prioridade deve refletir impacto e urgência segundo critérios acordados, incluindo prazos batch e dependências que podem ampliar a falha.
Aplicação guiada
Num cenário fictício, um portal de relatórios apresenta latência enquanto um processo de fundos deixa de produzir um ficheiro necessário ao fecho. Pergunta se existe alternativa, quanto trabalho está pendente e qual é o prazo do consumidor. Regista factos e hipóteses separadamente, atribui um responsável e define a próxima atualização. Se o procedimento permite recolha de diagnóstico mas exige aprovação para reinício, prepara essa decisão com evidência e risco. Não esperes por uma causa definitiva para comunicar impacto confirmado ou pedir ajuda. Esta disciplina permite manter autonomia operacional sem assumir poderes que o papel não concede.
Um alerta de CPU e um ficheiro em falta exigem perguntas diferentes sobre o impacto.
Armadilhas comuns
Prioridade pela ordem de chegada; assumir direitos pelo título; esperar pela causa para comunicar.
Tópicos relacionados: Hipóteses e evidências úteis · Diagnóstico por camada · Mitigação e validação operacional
Confirma impacto, âmbito e autoridade antes de escolher a intervenção.
Referência: Incident response · Operational support; PostgreSQL 18, OpenSSL 3.5 and BIND 9.20.29 examples; reviewed 2026-09-30