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

Fale em inglês britânico com um tom confiante, autoritário e de conversa - como um consultor sénior de redes a dar um briefing a um cliente enquanto bebem um café. Ritmo medido, dicção clara, ironia ocasional. Não é uma palestra. Não é um discurso de vendas. Apenas conversa direta de quem já viu este problema centenas de vezes: Bem-vindo ao briefing técnico da Purple. Hoje vou falar-vos de algo que todos os gestores de rede conhecem no seu íntimo, mesmo que nunca tenham ouvido o termo formal para o descrever. Mean time to innocence. Ou MTTI. [curta pausa] O tempo que passa a provar que a culpa não é sua. Eis o cenário. São nove da manhã. Os residentes de um bloco de apartamentos para arrendamento começam a ligar para a receção. O WiFi está avariado. O gestor do condomínio liga para o fornecedor de WiFi gerido. O fornecedor de WiFi gerido liga para o ISP. O ISP diz para verificar o router. A equipa do router diz para verificar os pontos de acesso. O fabricante dos pontos de acesso diz para verificar os dispositivos dos clientes. E algures no meio disto tudo, passaram quarenta e cinco minutos e ninguém resolveu absolutamente nada. Isto, mesmo aqui, é o mean time to innocence em ação. [curta pausa] E está a custar-lhe mais do que pensa. Deixem-me defini-lo corretamente. Mean time to innocence é o tempo médio decorrido entre o momento em que um problema é detetado e o momento em que uma determinada equipa consegue demonstrar, com provas, que o seu domínio não é a causa original. Não é o mesmo que o tempo médio de identificação, que é a métrica global da organização para encontrar a verdadeira causa original. O MTTI é isolado. É pessoal. É a equipa de rede a dizer, aqui estão os dados, não somos nós, procurem noutro lado. O problema é que, sem as ferramentas certas, essa prova demora 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, porque é que o WiFi é sempre o primeiro a ser culpado? [curta pausa] Três razões. Primeiro, o WiFi é visível. Quando algo falha, as pessoas olham para aquilo que conseguem ver, e as barras de sinal WiFi no telemóvel são o indicador de conectividade mais visível. Segundo, o WiFi é o último salto antes do dispositivo, por isso é a primeira coisa suspeita quando um dispositivo não consegue aceder à internet. Terceiro, e esta é a parte desconfortável, as equipas de WiFi muitas vezes não conseguem provar a sua inocência rapidamente porque não têm a telemetria correta. Se não conseguir mostrar que a camada sem fios está de perfeita saúde em menos de dois minutos, vai passar a hora seguinte a defender-se. Ora, num ambiente empresarial de inquilino único, isto é irritante. Num ambiente multi-inquilino, é genuinamente prejudicial. Pense num hotel como o Premier Inn, ou num bloco residencial de arrendamento de longa duração, ou num centro de conferências que acolhe eventos consecutivos. Tem um gestor de propriedade que não é proprietário da rede. Tem residentes ou hóspedes que não compreendem a rede. E tem um fornecedor de WiFi gerido que é responsável pela camada sem fios, mas não pelo circuito do ISP, não pela cablagem interna do edifício e não pelos dispositivos dos clientes. Quando algo falha, o gestor de propriedade culpa o fornecedor de WiFi porque é esse o contrato para o qual pode apontar. O residente culpa o edifício porque é a quem paga a renda. E o fornecedor de WiFi tem de ilibar a rede rapidamente, ou a relação deteriora-se. [pequena pausa] O MTTI não é apenas uma métrica técnica neste contexto. É uma métrica comercial. Por isso, vamos falar sobre a metodologia que realmente o encurta. Existem cinco camadas, e precisa de todas as cinco. Camada um: verificações sintéticas contínuas. Antes de qualquer ticket ser aberto, deve ter sondas automatizadas a correr a partir da própria rede, a testar a resolução de DNS, a acessibilidade 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 estas verificações de poucos em poucos minutos. Quando ocorre um incidente, pode extrair um gráfico e mostrar exatamente quando a camada WiFi teve a última verificação sintética limpa, e se estava limpa ou degradada no momento da reclamação. Só isso reduz o MTTI drasticamente, porque ou confirma que o WiFi estava saudável, ou confirma que não estava, e deixa de discutir sobre o assunto. Camada duas: visibilidade do caminho salto a salto. É aqui que a maioria das equipas falha. Pode provar que o ponto de acesso está saudável. Pode provar que o switch está saudável. Mas consegue provar que o caminho do switch até à entrega do ISP está saudável? Num edifício multi-inquilino, existem frequentemente saltos que não lhe pertencem. A rede de distribuição interna do edifício, o switch principal do senhorio, o ponto de demarcação para o ISP. Precisa de dados de rastreio de caminho que atravessem essas fronteiras. Não apenas um ping para o oito-oito-oito-oito. Visibilidade real do tipo traceroute que lhe mostra cada salto, a sua latência e se está a perder pacotes. Quando consegue mostrar que os saltos de um a quatro estão limpos e o salto cinco, que é o router de extremidade do ISP, está a mostrar quarenta por cento de perda de pacotes, a conversa muda imediatamente. Camada três: dados de fluxo com captura de pacotes a pedido. O NetFlow e o IPFIX oferecem-lhe uma visão ao nível da conversação sobre o que está a comunicar com o quê na rede. Quando um residente diz que o serviço de streaming não funciona, os dados de fluxo dizem-lhe se o tráfego para as gamas de IP desse serviço está sequer a sair da rede. Se estiver a sair da rede limpo e o problema for a jusante, essa é a sua prova. Se não estiver a sair da rede de todo, já sabe onde procurar. A captura de pacotes a pedido, disponível em plataformas como a Cisco Meraki e a HPE Aruba, permite-lhe obter uma captura direcionada para um cliente ou VLAN específico sem tocar no hardware. Essa é a sua camada forense. Utiliza-a com moderação, mas quando precisa dela, é definitiva. Camada quatro: topologia e mapeamento de dependências. Num ambiente multi-tenant, precisa de um mapa em direto que mostre quais os pontos de acesso que servem quais inquilinos, a que switches esses APs se ligam, que uplinks esses switches utilizam e qual o circuito do ISP que serve cada uplink. Quando ocorre um incidente, pode identificar imediatamente o raio de ação. Isto está a afetar um inquilino ou todos os inquilinos? Um andar ou o edifício inteiro? Uma VLAN ou todas as VLANs? Essa questão de âmbito, respondida em trinta segundos a partir de um mapa de topologia, diz-lhe se o problema está na camada WiFi, na rede do edifício ou na WAN. Também lhe diz quem mais deve contactar e quem pode excluir imediatamente. Camada cinco: correlação de eventos. Esta é a que une tudo. Os registos de alterações, os alertas de manutenção do ISP, as atualizações de firmware dos dispositivos, os eventos de energia e as reclamações dos utilizadores devem estar todos na mesma linha de tempo. Quando sobrepõe um pico de falhas de associação de clientes a uma atualização de firmware que ocorreu doze minutos antes, tem a sua causa raiz. Quando sobrepõe um pico de latência a uma janela de manutenção do ISP que não lhe foi comunicada, tem a sua prova para a escalada. A correlação de eventos não é glamorosa, mas é a diferença entre um jogo de atribuição de culpas de quarenta e cinco minutos e uma exoneração de quatro minutos. Agora, uma palavra sobre a dimensão cultural, porque é aqui que muitas equipas erram. O objetivo de reduzir o MTTI não é ganhar o jogo da atribuição de culpas mais rapidamente. É acabar com o jogo de atribuição de culpas por completo. [pausa curta] A partilha de provas muda a dinâmica. Quando o fornecedor de WiFi pode enviar ao gestor da propriedade uma ligação para um painel de controlo que mostra verde na camada sem fios, âmbar no switch do edifício e vermelho no circuito do ISP, a conversa deixa de ser adversarial. Torna-se colaborativa. O gestor da propriedade liga para o ISP. O ISP repara o circuito. Os residentes recuperam a conetividade. E o contrato do fornecedor de WiFi é renovado porque foram eles que encontraram o problema. Esse é o caso comercial para investir em ferramentas de observabilidade. Não apenas uma resolução de problemas mais rápida, mas melhores relações com as pessoas que lhe pagam. Deixe-me apresentar um par de cenários rápidos para tornar isto concreto. Cenário um: um hotel com 350 quartos. Os hóspedes de uma propriedade estilo Premier Inn começam a reportar que o WiFi no quarto está lento. A receção regista um ticket junto do fornecedor de WiFi gerido. Com os testes sintéticos a decorrer, o fornecedor consegue ver que os tempos de resolução de DNS dispararam de doze milissegundos para quatrocentos milissegundos às sete e quarenta e três da manhã. A camada de WiFi está saudável. O traçado do caminho mostra que a latência é introduzida no terceiro salto, que é o router de agregação do ISP. O fornecedor envia ao gerente do hotel uma captura de ecrã do traçado do caminho com o salto degradado destacado a vermelho, juntamente com o gráfico do teste sintético a mostrar que a camada de WiFi esteve limpa durante todo o tempo. O ISP é contactado. O ISP confirma um problema de encaminhamento do seu lado. Tempo total desde a reclamação até à exoneração da camada de WiFi: seis minutos. MTTR para o incidente completo: vinte e dois minutos, porque a correção do ISP demorou dezasseis minutos. Sem as ferramentas de observabilidade, essa exoneração de seis minutos teria sido quarenta minutos de avanços e recuos, e o MTTR teria sido superior a uma hora. Cenário dois: uma cadeia de retalho. Um retalhista nacional com WiFi em duzentas lojas nota que os terminais de ponto de venda numa região estão a perder intermitentemente a conectividade com o processador de pagamentos. A equipa de rede é imediatamente culpada. Os dados de fluxo mostram que o tráfego para a gama de IPs do processador de pagamentos está a sair 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 equipa de rede partilha os dados de fluxo e o resumo da captura com a equipa de suporte do processador de pagamentos. O processador de pagamentos identifica um balanceador de carga mal configurado do seu lado. O MTTI da equipa de rede: oito minutos. O tempo de correção do processador de pagamentos: trinta e cinco minutos. Sem os dados de fluxo, a equipa de rede teria passado esses trinta e cinco minutos a aprovisionar novamente VLANs e a reiniciar switches que estavam a funcionar perfeitamente. Certo. Deixe-me apresentar-lhe a versão rápida das principais perguntas que me fazem sobre este tema. O problema é do WiFi ou do dispositivo? Execute um teste sintético a partir do próprio AP. Se o AP conseguir aceder à internet de forma limpa e o dispositivo não, o problema é do dispositivo. Se o AP não conseguir aceder à internet, o problema está a montante do dispositivo. O problema é do WiFi ou do ISP? Execute um traçado do caminho para a internet. Se a latência ou perda for introduzida num salto fora do limite da sua rede, o problema é do ISP. Qual é a diferença entre MTTI e tempo médio de identificação? O MTTI é o tempo que a sua equipa demora a provar a inocência. O tempo médio de identificação é o tempo que a organização demora a 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 já tem. A maioria das plataformas de pontos de acesso empresariais, incluindo Cisco Meraki, HPE Aruba e Juniper Mist, possuem testes sintéticos e diagnósticos de clientes integrados. Utilize-os. Documente a sua topologia. Crie um painel partilhado que o gestor da propriedade ou a equipa de operações possam ver. A transparência é a ferramenta mais barata de redução de MTTI 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 fornecedores, proprietários e ISPs, é a métrica que determina se retém os contratos ou se os perde. A metodologia para o reduzir 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 provas partilhadas, para que cada equipa se possa concentrar em resolver o problema em vez de defender o seu território. [curta pausa] Porque cada minuto gasto a provar a inocência é um minuto adicionado ao tempo que os seus residentes, convidados ou compradores passam sem conectividade. E esse é o número que realmente importa. Obrigado por ouvir. Se quiser ver como a plataforma de WiFi Multi-Tenant da Purple apresenta este tipo de dados de observabilidade em 80.000 locais ativos, aceda a purple dot ai.