Mean time to innocence: como provar que o problema não é o WiFi

Fale em inglês britânico com um tom confiante, autoritativo e de conversação - como um consultor de rede sênior orientando um cliente durante um café. Ritmo comedido, dicção clara, inteligência perspicaz 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 boletim técnico da Purple. Vou falar com você hoje sobre algo que todo gerente de rede conhece no fundo da alma, mesmo que nunca tenha ouvido o termo formal para isso. Tempo médio para a inocência. Ou MTTI. [curta pausa] O tempo que você gasta provando que a culpa não é sua. Eis o cenário. São nove da manhã. Os moradores de um condomínio 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 ISP. O ISP 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 clientes. E no meio de tudo isso, quarenta e cinco minutos se passaram e ninguém realmente consertou nada. Isso, bem aí, é o tempo médio para a inocência em ação. [curta pausa] E está custando a você mais do que você imagina. Deixe-me definir isso adequadamente. O tempo médio para a inocência é o tempo médio decorrido entre o momento em que um problema é detectado e o momento em que qualquer equipe específica pode demonstrar, com evidências, que seu domínio não é a causa raiz. Não é o mesmo que o 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 o primeiro a ser culpado? [curta pausa] Três razões. Primeiro, o WiFi é visível. Quando algo quebra, as pessoas olham para o que podem ver, e as barras de sinal de WiFi no telefone são o indicador de conectividade mais visível. 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á em perfeito estado em menos de dois minutos, passará a próxima hora se defendendo. Agora, em um ambiente corporativo single-tenant, isso é irritante. Em um ambiente multi-tenant, é genuinamente prejudicial. Pense em um hotel como o Premier Inn, ou um bloco residencial build-to-rent, ou um centro de convenções realizando eventos consecutivos. Você tem um gerente de propriedade que não é o proprietário da rede. Você tem moradores ou hóspedes que não entendem a 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, não pelo cabeamento interno do edifício e não pelos dispositivos dos clientes. Quando algo quebra, o gerente da propriedade culpa o provedor de WiFi porque esse é o contrato que ele pode apontar. O morador culpa o edifício porque é para quem ele paga o aluguel. E o provedor de WiFi precisa exonerar a rede rapidamente, ou o relacionamento se deteriora. - 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 encurta. Existem cinco camadas, e você precisa de todas as cinco. Camada um: verificações sintéticas contínuas. Antes que qualquer ticket seja aberto, você deve ter sondagens automatizadas sendo executadas a partir da própria rede, testando a resolução de DNS, a acessibilidade de HTTP, a latência para endpoints conhecidos e os 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 puxar um gráfico e mostrar exatamente quando a camada de 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 o MTTI drasticamente, porque ou você confirma que o WiFi estava saudável, ou confirma que não estava, e para de discutir sobre isso. Camada dois: visibilidade do caminho salto por salto. É aqui que a maioria das equipes falha. Você pode provar que o ponto de acesso está saudável. Você pode provar que o switch está saudável. Mas você pode provar que o caminho do switch até a entrega do provedor de internet está saudável? Em um edifício multi-tenant, muitas vezes existem saltos que você não possui. A rede de distribuição interna do edifício, o switch principal do proprietário, o ponto de demarcação para o provedor de internet. Você precisa de dados de rastreamento de caminho que cruzem essas fronteiras. Não apenas um ping para o oito-oito-oito-oito. Visibilidade real no estilo 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. NetFlow e IPFIX oferecem uma visão em nível de conversa sobre o que está se comunicando com o que na rede. Quando um morador diz que o serviço de streaming não está funcionando, os dados de fluxo mostram se o tráfego para as faixas de IP desse serviço está sequer saindo da rede. Se estiver saindo da rede sem problemas e o erro for downstream, essa é a sua prova. Se não estiver saindo da rede de forma alguma, você já 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 precisar tocar no hardware. Essa é a sua camada forense. Você a utiliza com moderação, mas quando precisa, ela é definitiva. Camada quatro: mapeamento de topologia e dependência. Em um ambiente multi-tenant, você precisa de um mapa ao vivo que mostre quais pontos de acesso atendem a quais inquilinos, a quais switches esses APs se conectam, quais uplinks esses switches usam e qual link de ISP atende a cada uplink. Quando ocorre um incidente, você pode identificar imediatamente o raio de impacto. Isso está afetando um inquilino ou todos os inquilinos? 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. Ela também indica quem mais deve ser acionado e quem você pode excluir imediatamente. Camada cinco: correlação de eventos. Esta é a camada que une tudo. Logs de alterações, alertas de manutenção de ISP, atualizações de firmware de dispositivos, eventos de energia e reclamações de usuários precisam estar todos na mesma linha do tempo. Quando você cruza um pico de falhas de associação de clientes com uma atualização de firmware que ocorreu doze minutos antes, você encontra a causa raiz. Quando você cruza um pico de latência com uma janela de manutenção do ISP que não foi comunicada a você, você tem a sua prova para a escalação. A correlação de eventos não é glamorosa, mas é a diferença entre um jogo de empurra-empurra de quarenta e cinco minutos e uma isenção de culpa em quatro minutos. Agora, uma palavra sobre a dimensão cultural, porque é aqui que muitas equipes erram. O objetivo de reduzir o MTTI não é ganhar o jogo de culpas mais rápido. É acabar com o jogo de culpas por completo. [pequena pausa] A evidência compartilhada muda a dinâmica. Quando o provedor de WiFi pode enviar ao administrador do condomínio um link para um painel mostrando verde em toda a camada sem fio, amarelo no switch do prédio e vermelho no link de ISP, a conversa deixa de ser adversarial. Ela se torna colaborativa. O administrador do condomínio liga para o ISP. O ISP corrige o link. Os moradores recuperam a conectividade. E o contrato do provedor de WiFi é renovado porque foram eles que identificaram o problema. Esse é o caso comercial para investir em ferramentas de observabilidade. Não apenas uma resoluçã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 no quarto está lento. A recepção registra um tíquete com o provedor de WiFi gerenciado. Com as verificações sintéticas em execução, o provedor pode 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 de WiFi está saudável. 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, juntamente com o gráfico de verificação sintética mostrando que a camada de WiFi estava 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 de 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, aquela inocentação de seis minutos teria levado quarenta minutos de idas e vindas, e o MTTR teria sido de mais de uma hora. Cenário dois: uma rede de varejo. Uma varejista nacional com WiFi em duzentas lojas percebe que os terminais de ponto de venda em uma região estão perdendo conectividade de forma intermitente 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 da rede da loja de forma limpa. 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 do lado do servidor no 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. 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 provisionando novamente 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 é o provedor de internet. Qual é a diferença entre MTTI e tempo médio de identificação? MTTI é o tempo que sua equipe leva para provar inocência. 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ê já tem. A maioria das plataformas de access point corporativas, incluindo Cisco Meraki, HPE Aruba e Juniper Mist, possui testes sintéticos e diagnósticos de clientes integrados. Use-os. Documente sua topologia. Crie um painel compartilhado que o gerente do local ou a equipe de operações possa visualizar. A transparência é a ferramenta de redução de MTTI mais barata disponível. Para concluir. O tempo médio para a inocência é o imposto oculto em cada incidente de rede. Em ambientes multi-tenant, onde a responsabilidade é fragmentada entre provedores, proprietários e ISPs, essa é a métrica que determina se você reté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 da culpa. É substituir o jogo da culpa por evidências compartilhadas, para que cada equipe possa se concentrar em resolver o problema em vez de defender seu território. [curta pausa] Porque cada minuto gasto provando a inocência é um minuto adicionado ao tempo que seus moradores, convidados ou compradores passam sem conectividade. E esse é o número que realmente importa. Obrigado por ouvir. Se você quiser ver como a plataforma Multi-Tenant WiFi da Purple apresenta esse tipo de dados de observabilidade em mais de 80.000 locais ativos, acesse purple dot ai.