Suporte de TI feito certo: um guia prático de campo

A maioria do trabalho de suporte de TI é avaliada pela velocidade, mas velocidade sem método apenas move o mesmo problema para outro lugar. Um ticket fechado em cinco minutos que reabre em três dias custa mais que um que leva vinte minutos e realmente resolve o problema. Este guia aborda os hábitos que separam alguém que fecha tickets de alguém que resolve problemas.

Comece com uma triagem real, não com um palpite

Antes de tocar em uma máquina, peça ao usuário para descrever o problema com suas próprias palavras, depois faça três perguntas de acompanhamento: quando começou, o que mudou recentemente e acontece o tempo todo ou intermitentemente. "Minha internet está lenta" pode significar resolução de DNS, um canal Wi-Fi saturado, uma NIC com falha ou um navegador com quarenta abas abertas. Anote o texto exato do erro se houver um. Screenshots batem descrições todas as vezes — peça um antes de pedir ao usuário para tentar qualquer coisa.

Resista à vontade de pular direto para "você já tentou reiniciar". Funciona com frequência suficiente para as pessoas usarem como padrão, mas se você pular a triagem vai perder padrões. Se três pessoas no mesmo switch reportam a mesma lentidão na mesma hora, esse é um ticket diferente de um laptop com um driver ruim.

Reproduza antes de corrigir

Se você não consegue reproduzir um problema, você não pode confirmar que o corrigiu. Peça ao usuário para caminhar pelos passos exatos em uma chamada de vídeo, ou faça você mesmo na máquina dele se as ferramentas remotas permitirem. Verifique ipconfig /all no Windows ou ip a no Linux para sanidade básica de rede, olhe para Event Viewer (eventvwr.msc) para erros de aplicação e sistema no horário reportado, e verifique journalctl -xe --since "1 hour ago" em máquinas Linux para a mesma janela.

Para travamentos de aplicação, obtenha o número de build exato e a versão do SO. "Travou" não te diz nada; "Outlook 16.0.17726 trava ao abrir um convite de calendário com anexo .ics" te diz onde procurar. Faça referência cruzada com problemas conhecidos nas notas de lançamento do fornecedor antes de assumir que é local.

Triagem por impacto, não por quem grita mais alto

Um único usuário bloqueado do email é inconveniente. Um servidor de arquivos compartilhado inacessível para quarenta pessoas é uma interrupção. Construa uma escala de severidade simples — algo como P1 para interrupções afetando múltiplos usuários ou sistemas críticos, P2 para bloqueadores de um único usuário, P3 para degradado-mas-funcionando, P4 para pedidos cosméticos ou de conveniência — e aplique consistentemente, mesmo sob pressão de um gerente que quer a coisa dele primeiro.

Documente a decisão de severidade no ticket em si. Isso te protege depois quando alguém pergunta por que seu P3 ficou dois dias enquanto você cuidava de três P1s.

Corrija a causa raiz, não o sintoma

Reinicie um serviço que continua travando ganha tempo, não uma solução. Se um spooler de impressão morre diariamente, verifique Get-WinEvent -LogName Application -MaxEvents 50 para o erro real antes de reiniciá-lo novamente. Se a senha de um usuário continua expirada inesperadamente, verifique a política de grupo aplicada à sua UO em vez de apenas redefini-la e seguir em frente.

Mantenha um log pessoal de correções recorrentes. Se você se encontra digitando o mesmo comando PowerShell ou o mesmo ajuste de registro três vezes, é um sinal de que pertence a um script ou a um runbook documentado, não na sua cabeça.

Documente como se alguém mais fosse ler

Cada resolução de ticket deve responder: qual foi a causa real, qual foi a correção e o que você verificaria primeiro se isso acontecer novamente. "Corrigido" como uma nota de resolução é inútil para o próximo técnico, incluindo você mesmo seis meses depois sem memória deste ticket.

Uma boa nota de resolução se parece com: "Causa raiz: escopo DHCP na VLAN 20 esgotado, novos dispositivos receberam endereços APIPA. Correção: ampliou escopo de /24 para /23, reserva para impressora adicionada. Verificar: verificar contagem de lease DHCP mensalmente, limite de alerta definido em 90%." Essa terceira frase é a que a maioria dos técnicos pula, e é a que previne o ticket repetido.

Escale com contexto, não apenas um encaminhamento

Quando um ticket vai para o tier 2 ou um fornecedor, inclua o que você já descartou. "Verifiquei cabos, troquei porta, confirmei configuração de VLAN, ainda sem luz de link" poupa a próxima pessoa de refazer seus primeiros vinte minutos. Escalações vagas como "usuário diz que tá quebrado, por favor avise" apenas move o atraso em vez de removê-lo.

Feche o loop com o usuário

Diga ao usuário o que estava errado em linguagem simples, não apenas "corrigido". As pessoas confiam mais em suporte quando entendem o que aconteceu, e reduz as mesmas pessoas abrindo o mesmo ticket mês que vem porque não percebem que está conectado.

Se você quer aprofundar no lado técnico de qualquer um desses — fundamentos de rede, event logs do Windows ou criar suas próprias ferramentas de diagnóstico — Korra Studio tem segmentos em Networking, Systems e Scripting que valem a pena trabalhar em seguida.