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 triagem, especialista e engenharia, não por hierarquia de ego, mas por capacidade diferente em cada momento.

Na triagem, 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 especialista: 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. Na engenharia: 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 na triagem (a 2 com apoio pontual do especialista); classe 3 com especialista; classe 4 com engenharia. Confundir camada é caro: engenharia investigando disco cheio que a triagem deveria limpar com runbook; triagem 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. A triagem 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 dono no time especialista, 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 triagem identificar necessidade de especialista e esse time assumir; tempo de resposta de engenharia 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 registro, sem timeline e sem evidência não fecha ciclo para quem responde a licitação 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

A triagem não começa reiniciando servidor. Começa consultando o mapa contextual do ambiente: 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; o time especialista 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: registro 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.

Registro técnico: memória que sobrevive à rotatividade

Atendimento relevante na UCloud gera registro 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 da parceria.

Registros de classe 3 e 4 passam por revisão do especialista e da engenharia antes de entrega. Não é burocracia: é o filtro que impede “achismo” virar documentação oficial. Registro ruim, “ajustado, ok”, é conhecimento tribal com data de validade. Registro 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 a busca na IDE e na fila de plantão conta.

Em parcerias recorrentes, medimos evolução: tempo médio de triagem, taxa de reabertura, percentual de atendimentos com registro 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.