Tema Operação & suporte. Complementa Conhecimento que não trabalha.

Três perguntas, três camadas

Operação madura separa restaurar, entender e corrigir de vez. Na prática isso vira N1, N2 e N3 — não por hierarquia de ego, mas por capacidade diferente em cada momento.

No N1, a pergunta é: o serviço voltou dentro do SLA? Runbook recuperável, comunicação clara ao cliente, severidade correta, escalação no tempo certo. No N2: por que quebrou e como estabilizar sem gambiarra que vira dívida? Logs, métricas, change recente, dependência que ninguém lembrava no mapa. No N3: o que mudar para não repetir — arquitetura, fornecedor, limite de plataforma, débito que só resolve com projeto.

Classificamos demandas em quatro classes de complexidade — de procedimento conhecido a incidente com impacto sistêmico. Classe 1 e 2 ficam com N1 (a 2 com apoio pontual de N2); classe 3 com N2; classe 4 com N3. Confundir camada é caro: N3 investigando disco cheio que N1 deveria limpar com runbook; N1 tentando refatorar pool de conexão porque “já vi isso antes”; ticket fechado como resolvido quando o sintoma sumiu mas a causa não.

O ticket que “resolve” e o serviço que não

O cenário das 2h17 não é exceção. Monitoramento dispara alerta de latência em API de matrícula. N1 reinicia o pod — métrica normaliza por vinte minutos. Ticket marcado resolvido. Às 4h o alerta volta; desta vez o pool de conexão do banco está saturado porque o restart mascarou leak que vinha desde o deploy das 18h.

Resolução de sintoma sem diagnóstico é o anti-padrão mais caro em suporte terceirizado: KPI de fila verde, cliente irritado, especialista interno gastando horas refazendo trabalho. Critério de fechamento em operação madura inclui: serviço estável por janela acordada, causa identificada ou explicitamente em investigação com owner N2, cliente informado com linguagem que ele entende — não só “normalizado”.

Quem segura a linha com o cliente

Em modelos ITIL sólidos, o service desk não “joga o ticket” para outra fila e some. Mantém ownership: o cliente fala com alguém que sabe onde o incidente está, quem foi acionado, qual o próximo passo e quando será a próxima atualização — mesmo que a engenharia esteja em bridge interna.

OLAs internos cronometram handoff: tempo máximo entre N1 identificar necessidade de N2 e N2 assumir; tempo de resposta de N3 em classe 4. O SLA com o contratante é a promessa pública; OLA é o que impede a promessa de ser ficção. Em governo e enterprise, isso não é luxo de processo — é resposta a auditoria. “Resolvido” no ITSM sem laudo, sem timeline e sem evidência não fecha ciclo para quem assina contrato público ou renovação com board.

Canal importa menos que disciplina: Trello, ServiceNow, e-mail estruturado — o que vale é que cada transição deixa rastro. “Falamos no WhatsApp” não escala nem sobrevive a troca de plantão.

Antes de executar: mapa e histórico

Triagem N1 não começa reiniciando servidor. Começa consultando o mapa contextual do contrato: arquitetura, integrações, riscos conhecidos, runbooks vigentes, incidentes similares. Em onboarding remunerado, esse mapa é criado com o cliente — visão geral, ambientes, acessos (sem credencial em texto claro), dependências críticas. Cada atendimento relevante atualiza o mapa; N2 revisa mensalmente consistência.

Sem mapa, cada plantonista reconstrói o ambiente do zero. Com mapa curado, a pergunta “já vimos isso?” tem endereço: laudo LEKTO#00127, runbook de failover do Redis, change do último release. É assim que operação fica mais barata no mês seis do que no mês um — não por heroísmo, por memória estruturada.

Laudo: memória que sobrevive à rotatividade

Atendimento relevante na UCloud gera laudo técnico — documento com identificação (cliente, data, responsável, classe), demanda original, contexto consultado, diagnóstico ou causa raiz, ações com timestamp, resultado validado, recomendações e horas consumidas. Numeração rastreável (UC#, LEKTO#, padrão institucional do cliente) liga o evento ao histórico do contrato.

Laudos de classe 3 e 4 passam por revisão N2/N3 antes de entrega. Não é burocracia: é o filtro que impede “achismo” virar registro oficial. Laudo ruim — “ajustado, ok” — é conhecimento tribal com data de validade. Laudo bom permite que o próximo analista, seis meses depois, entenda o que foi feito e por quê, sem abrir thread de Slack arquivada.

Aprendizado que muda procedimento vira runbook curado ou entrada no mapa. Incidente que não altera documentação alguma é oportunidade perdida — e quase garantia de repetição.

Depois do apagar do incêndio

Impacto alto pede revisão pós-incidente de verdade: linha do tempo minuto a minuto, onde a comunicação falhou, causa raiz (não só trigger), ações corretivas com dono e prazo, itens de follow-up que viram backlog priorizado. O que não vira runbook ou mapa reaparece no próximo plantão — só que mais caro, com cliente menos paciente.

É aqui que suporte especializado encontra Knowledge Operations: incidente deixa de ser episódio isolado e vira insumo para o canônico. Postmortem em slide que ninguém abre de novo não conta; postmortem que alimenta retrieve na IDE e na fila de plantão conta.

Em contratos recorrentes, medimos evolução: tempo médio de triagem, taxa de reabertura, percentual de atendimentos com laudo completo, incidentes recorrentes com mesma causa raiz. Se a última métrica não cai ao longo dos trimestres, a operação está apagando fogo — não operando.