Tempo médio de inocência: como provar que a culpa não é do WiFi

Fale em português brasileiro com um tom confiante, autoritário e de conversa — como um consultor sênior de rede conversando com um cliente tomando um café. Ritmo medido, dicção clara, ironia sutil ocasional. Não é uma palestra. Não é um discurso de vendas. Apenas uma conversa direta de quem já viu esse problema centenas de vezes: Bem-vindo ao resumo técnico da Purple. Vou falar com você hoje sobre algo que todo gerente de rede conhece na pele, mesmo que nunca tenha ouvido o termo formal para isso. Tempo médio de inocência. Ou MTTI. [pausa curta] O tempo que você gasta provando que a culpa não é sua. Aqui está o cenário. São nove da manhã. Os moradores de um prédio residencial de aluguel começam a ligar para a recepção. O WiFi está quebrado. O gerente da propriedade liga para o provedor de WiFi gerenciado. O provedor de WiFi gerenciado liga para o provedor de internet. O provedor de internet diz para verificar o roteador. A equipe do roteador diz para verificar os pontos de acesso. O fornecedor do ponto de acesso diz para verificar os dispositivos dos clientes. E, em algum momento no meio de tudo isso, quarenta e cinco minutos se passaram e ninguém realmente resolveu nada. Isso, bem aí, é o tempo médio de inocência em ação. [pausa curta] E está custando mais caro do que você imagina. Deixe-me definir isso corretamente. O tempo médio de inocência é o tempo médio decorrido entre o momento em que um problema é detectado e o momento em que qualquer equipe específica consegue demonstrar, com evidências, que seu domínio não é a causa raiz. Não é o mesmo que tempo médio de identificação, que é a métrica de toda a organização para encontrar a causa raiz real. O MTTI é isolado. É pessoal. É a equipe de rede dizendo: aqui estão os dados, não somos nós, agora procurem em outro lugar. O problema é que, sem as ferramentas certas, essa prova leva tempo. E cada minuto de MTTI é um minuto adicionado diretamente ao seu tempo médio de resolução, o seu MTTR. Os dois são inseparáveis. Então, por que o WiFi sempre é culpado primeiro? [pausa curta] Três razões. Primeiro, o WiFi é visível. Quando algo quebra, as pessoas olham para o que conseguem ver, e as barras de sinal de WiFi no telefone são o indicador mais visível de conectividade. Segundo, o WiFi é o último salto antes do dispositivo, por isso é a primeira coisa que parece suspeita quando um dispositivo não consegue acessar a internet. Terceiro, e esta é a parte desconfortável, as equipes de WiFi muitas vezes não conseguem provar a inocência rapidamente porque não têm a telemetria correta. Se você não puder mostrar que a camada sem fio está funcionando perfeitamente em menos de dois minutos, passará a próxima hora se defendendo. Agora, em um ambiente corporativo de locatário único, isso é irritante. Em um ambiente multi-tenant, é genuinamente prejudicial. Pense em um hotel como o Premier Inn, ou um condomínio residencial de aluguel, ou um centro de convenções realizando eventos consecutivos. Você tem um gerente de propriedade que não é dono da rede. Você tem moradores ou hóspedes que não entendem de rede. E você tem um provedor de WiFi gerenciado que é responsável pela camada sem fio, mas não pelo circuito do provedor de internet, nem pelo cabeamento interno do prédio e nem pelos dispositivos dos clientes. Quando algo quebra, o gerente da propriedade culpa o provedor de WiFi porque esse é o contrato que ele pode cobrar. O morador culpa o condomínio porque é para quem ele paga o aluguel. E o provedor de WiFi precisa inocentar a rede rapidamente, ou o relacionamento se deteriora. [pausa curta] O MTTI não é apenas uma métrica técnica neste contexto. É uma métrica comercial. Então, vamos falar sobre a metodologia que realmente o reduz. Existem cinco camadas, e você precisa de todas as cinco. Camada um: verificações sintéticas contínuas. Antes de qualquer chamado ser aberto, você deve ter sondas automatizadas rodando a partir da própria rede, testando a resolução de DNS, alcançabilidade de HTTP, latência para endpoints conhecidos e fluxos de autenticação. Ferramentas como o Marvis da Juniper Mist, ou os testes sintéticos integrados em plataformas como o ThousandEyes, executam essas verificações a cada poucos minutos. Quando ocorre um incidente, você pode abrir um gráfico e mostrar exatamente quando a camada WiFi teve a última verificação sintética limpa, e se ela estava limpa ou degradada no momento da reclamação. Isso por si só reduz drasticamente o MTTI, porque ou você confirma que o WiFi estava íntegro, ou confirma que não estava, e para de discutir sobre isso. Camada dois: visibilidade do caminho salto a salto. É aqui que a maioria das equipes falha. Você pode provar que o ponto de acesso está íntegro. Você pode provar que o switch está íntegro. Mas você pode provar que o caminho do switch até a entrega do provedor de internet está íntegro? Em um edifício multi-tenant, muitas vezes existem saltos que não pertencem a você. A rede de distribuição interna do prédio, o switch principal do proprietário, o ponto de demarcação com o provedor de internet. Você precisa de dados de rastreamento de rota que cruzem essas fronteiras. Não apenas um ping para o oito-oito-oito-oito. Visibilidade real do tipo traceroute que mostra cada salto, sua latência e se está descartando pacotes. Quando você consegue mostrar que os saltos de um a quatro estão limpos e o salto cinco, que é o roteador de borda do provedor de internet, está mostrando quarenta por cento de perda de pacotes, a conversa muda imediatamente. Camada três: dados de fluxo com captura de pacotes sob demanda. O NetFlow e o IPFIX oferecem uma visão em nível de conversa do que está se comunicando com o quê na rede. Quando um morador diz que o serviço de streaming está quebrado, os dados de fluxo informam se o tráfego para as faixas de IP desse serviço está sequer saindo da rede. Se estiver saindo limpo e o problema for adiante, essa é a sua evidência. Se não estiver saindo de forma alguma, você sabe onde procurar. A captura de pacotes sob demanda, disponível em plataformas como Cisco Meraki e HPE Aruba, permite que você faça uma captura direcionada para um cliente ou VLAN específico sem tocar no hardware. Essa é a sua camada forense. Você a usa com moderação, mas quando precisa, ela é definitiva. Camada quatro: mapeamento de topologia e dependências. Em um ambiente multi-tenant, você precisa de um mapa ao vivo que mostre quais pontos de acesso atendem a quais locatários, a quais switches esses APs se conectam, quais uplinks esses switches usam e qual circuito de provedor de internet atende a cada uplink. Quando ocorre um incidente, você pode identificar imediatamente o raio de impacto. Isso está afetando um locatário ou todos os locatários? Um andar ou o prédio inteiro? Uma VLAN ou todas as VLANs? Essa pergunta de escopo, respondida em trinta segundos a partir de um mapa de topologia, diz se o problema está na camada WiFi, na rede do prédio ou na WAN. Também diz quem mais deve ser envolvido e quem você pode excluir imediatamente. Camada cinco: correlação de eventos. Esta é a que une tudo. Logs de alteração, alertas de manutenção do provedor de internet, atualizações de firmware de dispositivos, eventos de energia e reclamações de usuários precisam estar na mesma linha do tempo. Quando você sobrepõe um pico de falhas de associação de clientes com uma atualização de firmware que aconteceu doze minutos antes, você tem a sua causa raiz. Quando você sobrepõe um pico de latência com uma janela de manutenção do provedor de internet que não foi comunicada a você, você tem a sua evidência para a escalação. A correlação de eventos não é glamorosa, mas é the diferença entre um jogo de empurra de quarenta e cinco minutos e uma inocentação de quatro minutos. Agora, uma palavra sobre a dimensão cultural, porque é aqui que muitas equipes erram. O objetivo de reduzir o MTTI não é vencer o jogo de empurra mais rápido. É acabar com o jogo de empurra de uma vez por todas. [pausa curta] Evidências compartilhadas mudam a dinâmica. Quando o provedor de WiFi pode enviar ao gerente da propriedade um link para um painel mostrando verde em toda a camada sem fio, amarelo no switch interno do prédio e vermelho no circuito do provedor de internet, a conversa deixa de ser hostil. Torna-se colaborativa. O gerente da propriedade liga para o provedor de internet. O provedor de internet corrige o circuito. Os moradores recuperam a conectividade. E o contrato do provedor de WiFi é renovado porque foram eles que encontraram o problema. Esse é o caso comercial para investir em ferramentas de observabilidade. Não apenas uma solução de problemas mais rápida, mas relacionamentos melhores com as pessoas que pagam você. Deixe-me apresentar alguns cenários rápidos para tornar isso concreto. Cenário um: um hotel de 350 quartos. Os hóspedes de uma propriedade no estilo Premier Inn começam a relatar que o WiFi nos quartos está lento. A recepção abre um chamado com o provedor de WiFi gerenciado. Com as verificações sintéticas em execução, o provedor consegue ver que os tempos de resolução de DNS saltaram de doze milissegundos para quatrocentos milissegundos às sete e quarenta e três da manhã. A camada WiFi está íntegra. O rastreamento de rota mostra que a latência é introduzida no terceiro salto, que é o roteador de agregação do provedor de internet. O provedor envia ao gerente do hotel uma captura de tela do rastreamento de rota com o salto degradado destacado em vermelho, junto com o gráfico de verificação sintética mostrando que a camada WiFi esteve limpa o tempo todo. O provedor de internet é acionado. O provedor de internet confirma um problema de roteamento do lado deles. Tempo total desde a reclamação até a inocentação da camada WiFi: seis minutos. MTTR para o incidente completo: vinte e dois minutos, porque a correção do provedor de internet levou dezesseis minutos. Sem as ferramentas de observabilidade, essa inocentação de seis minutos teria sido quarenta minutos de idas e vindas, e o MTTR teria passado de uma hora. Cenário dois: uma rede de varejo. Uma grande varejista com WiFi em duzentas lojas percebe que os terminais de ponto de venda em uma região estão perdendo intermitentemente a conectividade com o processador de pagamentos. A equipe de rede é imediatamente culpada. Os dados de fluxo mostram que o tráfego para a faixa de IP do processador de pagamentos está saindo de forma limpa da rede da loja. O problema não é a rede. Uma captura de pacotes na VLAN do processador de pagamentos mostra um pico de retransmissões TCP, o que aponta para um problema no lado do servidor do processador de pagamentos. A equipe de rede compartilha os dados de fluxo e o resumo da captura com a equipe de suporte do processador de pagamentos. O processador de pagamentos identifica um balanceador de carga mal configurado do lado deles. O MTTI da equipe de rede: oito minutos. O tempo de correção do processador de pagamentos: trinta e cinco minutos. Sem os dados de fluxo, a equipe de rede teria passado esses trinta e cinco minutos reconfigurando VLANs e reiniciando switches que estavam funcionando perfeitamente. Certo. Deixe-me apresentar a versão rápida das principais perguntas que recebo sobre este assunto. O problema é o WiFi ou o dispositivo? Execute uma verificação sintética a partir do próprio AP. Se o AP conseguir acessar a internet de forma limpa e o dispositivo não, o problema é o dispositivo. Se o AP não conseguir acessar a internet, o problema está acima do dispositivo. O problema é o WiFi ou o provedor de internet? Faça um rastreamento de rota para a internet. Se a latência ou perda for introduzida em um salto fora do limite da sua rede, o problema é do provedor de internet. Qual é a diferença entre MTTI e tempo médio de identificação? O MTTI é o tempo que sua equipe leva para provar a inocência. O tempo médio de identificação é o tempo que a organização leva para encontrar o verdadeiro culpado. O MTTI é um subconjunto do tempo médio de identificação. Como posso reduzir o MTTI sem comprar novas ferramentas? Comece com o que você tem. A maioria das plataformas de pontos de acesso corporativos, incluindo Cisco Meraki, HPE Aruba e Juniper Mist, possui testes sintéticos integrados e diagnósticos de clientes. Use-os. Documente sua topologia. Crie um painel compartilhado que o gerente da propriedade ou a equipe de operações possa ver. A transparência é a ferramenta de redução de MTTI mais barata disponível. Para encerrar. O tempo médio de inocência é o imposto oculto em cada incidente de rede. Em ambientes multi-tenant, onde a responsabilidade é fragmentada entre provedores, proprietários e operadoras de internet, essa é a métrica que determina se você mantém ou perde contratos. A metodologia para reduzi-la não é complicada: verificações sintéticas, visibilidade do caminho, dados de fluxo, mapeamento de topologia e correlação de eventos. O objetivo não é vencer o jogo de empurra. É substituir o jogo de empurra por evidências compartilhadas, para que cada equipe possa se concentrar em resolver o problema em vez de defender seu território. [pausa curta] Porque cada minuto gasto provando a inocência é um minuto adicionado ao tempo que seus moradores, hóspedes ou clientes passam sem conectividade. E esse é o número que realmente importa. Obrigado por ouvir. Se você quiser ver como a plataforma de Multi-Tenant WiFi da Purple apresenta esse tipo de dados de observabilidade em 80.000 locais ativos, acesse purple ponto ai.