Atendimento ADSL na casa do cliente: o que field service ensina sobre sistemas reais

Parte do meu trabalho na Oi era ir até a casa do cliente.

Não era só escritório, rack e terminal. Era pegar o equipamento, o agendamento do dia, e ir de endereço em endereço resolver problema de internet. ADSL caindo, wireless que não conecta, roteador que parou de funcionar, sinal que chega na rua mas some na sala.

Field service parece simples de fora. Na prática é onde você aprende o que "ambiente de produção não controlado" significa.

ADSL tem peculiaridade que quem nunca trabalhou com ela não imagina: a qualidade da linha física importa tanto quanto a configuração.

Cliente ligava reclamando que a internet estava lenta ou caindo. Primeiro instinto — e o instinto errado — era mexer no roteador, checar configuração PPPoE, reiniciar. Às vezes resolvia. Muitas vezes não.

O problema era na linha de cobre entre a central e a casa do cliente. Conexão velha, com emenda ruim, com interferência de equipamento elétrico próximo. A taxa de sincronização do modem despencava. Não havia configuração de software que resolvesse problema de física.

Isso ensinou algo que parece óbvio mas não é: diagnóstico começa pela camada errada quando você parte de onde é mais fácil mexer, não de onde o problema provavelmente está.

Vim para software e vi o mesmo padrão. Desenvolvedor com problema de performance mexe primeiro no código — porque é onde tem controle. Muitas vezes o problema é banco de dados, rede, ou infraestrutura. A camada onde é mais fácil agir raramente é a camada onde o problema está.

Wireless tinha categoria própria de problemas.

Cliente com sinal fraco em quarto distante do roteador. A solução "óbvia" era repetidor. Mas repetidor mal posicionado cria problema pior — roaming agressivo, latência alta, dispositivo que fica preso em AP com sinal ruim em vez de trocar para o melhor.

WPS era armadilha frequente. Wi-Fi Protected Setup — aquele botão no roteador que conecta dispositivo sem digitar senha — parecia conveniente. O problema é que WPS tem vulnerabilidade conhecida de brute force no PIN de 8 dígitos. Em 2014/2015 já era conhecida. Muitos roteadores residenciais vinham com WPS habilitado por padrão.

Quando ia ao cliente e via WPS ativo, desabilitava. Não porque o cliente pediu — mas porque era o correto fazer.

Esse instinto — de melhorar segurança mesmo quando não é o escopo do atendimento — ficou. Anos depois, quando revisei arquitetura de APIs e via endpoint sem autenticação, a reação era a mesma.

O que field service ensina que trabalho de escritório não ensina:

Horário de serviço é acordo, não estimativa. Quando você agenda atendimento às 14h na casa de alguém, essa pessoa reorganizou o dia para estar lá. Atrasar sem avisar tem custo real para uma pessoa real. Respeito a tempo do cliente não é cortesia — é profissionalismo.

Ambiente real é caótico. Em laboratório, equipamento funciona conforme especificação. Na sala de visitas de um cliente às 17h30 com criança correndo e TV ligada, você tem o que tem: cabo velho, tomada compartilhada com geladeira, roteador posicionado embaixo de uma TV de plasma. O sistema tem que funcionar nesse ambiente, não no ambiente idealizado.

Comunicar o que fez é parte do trabalho. Cliente não sabe o que é PPPoE. Não precisa saber. Mas precisa saber que o problema foi resolvido, o que foi feito, e o que fazer se voltar a acontecer. Técnico que resolve o problema e sai sem explicar entregou metade do trabalho.

Reproduzir antes de resolver. Frequentemente chegava na casa do cliente e o problema não estava acontecendo. "Estava caindo a noite toda e agora parou." Isso não significa que resolveu sozinho — significa que o problema é intermitente e está esperando a condição certa para aparecer. Fui embora cedo demais algumas vezes. Perdi chamado porque "estava funcionando quando o técnico foi lá" — e no dia seguinte voltou.

Reproduzir o problema antes de resolver foi o aprendizado. Sem reprodução confiável, qualquer correção é chute.

Anos depois, quando comecei a trabalhar com observabilidade em plataforma de software — SLOs, error budgets, alertas — percebi que estava aplicando a mesma lógica.

Problema que não consigo reproduzir é problema que não consigo resolver. Métrica que não consigo medir é métrica que não consigo melhorar. Ambiente de produção sempre vai ser mais caótico que o ambiente de desenvolvimento.

Isso aprendi na sala de visitas de um cliente com problema de ADSL em 2015. O vocabulário mudou. O princípio ficou.

Essa semana: qual é o problema que você está tentando resolver sem ter conseguido reproduzir de forma confiável?