Tempo médio até à inocência: como provar que o problema não é do WiFi

Fale em inglês britânico com um tom confiante, autoritário e de conversação - como se fosse um consultor de redes sénior a dar orientações a um cliente enquanto bebem um café. Ritmo comedido, dicção clara, ocasionalmente um humor seco. Não é uma palestra. Não é um pitch de vendas. Apenas uma conversa direta de quem já viu este problema centenas de vezes: Bem-vindo ao resumo técnico da Purple. Hoje vou falar-vos sobre algo que todos os gestores de rede conhecem no seu âmago, mesmo que nunca tenham ouvido o termo formal para isso. Mean time to innocence. Ou MTTI. [pequena 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 de arrendamento começam a ligar para a receção. O WiFi está avariado. O gestor da propriedade 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 no meio de tudo isto, passaram quarenta e cinco minutos e ninguém resolveu realmente nada. Isto, mesmo ali, é o mean time to innocence em ação. [pequena pausa] E está a custar-lhe mais do que pensa. Permita-me defini-lo corretamente. O 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 raiz. Não é o mesmo que mean time to identify, que é a métrica organizacional para encontrar a verdadeira causa raiz. O MTTI é isolado em silos. É pessoal. É a equipa de rede a dizer: aqui estão os dados, não fomos nós, agora procurem noutro lado. O problema é que, sem as ferramentas certas, essa prova leva tempo. E cada minuto de MTTI é um minuto adicionado diretamente ao seu mean time to resolution, o seu MTTR. Os dois são inseparáveis. Então, porque é que o WiFi é sempre o primeiro a ser culpado? [pequena pausa] Três razões. Primeiro, o WiFi é visível. Quando algo falha, as pessoas olham para o que conseguem ver, e as barras de sinal de WiFi no telemóvel são o indicador de conectividade mais visível. Segundo, o WiFi é o último salto antes do dispositivo, pelo que é 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 certa. Se não conseguir demonstrar o bom estado de funcionamento da camada sem fios em menos de dois minutos, vai passar a hora seguinte a defender-se. Ora, num ambiente empresarial single-tenant, isto é irritante. Num ambiente multi-tenant, é genuinamente prejudicial. Pense num hotel como o Premier Inn, ou num bloco residencial build-to-rent, 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 cliente. 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 este que paga o aluguer. 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, testando 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 a ThousandEyes, executam estas verificações a cada poucos minutos. Quando ocorre um incidente, pode extrair um gráfico e mostrar exatamente quando é que a camada de WiFi teve a última verificação sintética limpa, e se estava limpa ou degradada no momento da reclamação. Só isso reduz drasticamente o MTTI, porque ou confirma que o WiFi estava saudável, ou confirma que não estava, e deixa de discutir sobre o assunto. Camada dois: 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 desde o switch até à entrega do ISP está saudável? Num edifício multi-tenant, existem frequentemente saltos que não lhe pertencem. A rede de distribuição interna do edifício, o switch central do proprietário, 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 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. Terceiro nível: dados de fluxo com captura de pacotes sob procura. 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 indicam-lhe se o tráfego para as gamas de IP desse serviço está sequer a sair da rede. Se está a sair limpo da rede e o problema está a jusante, aí tem a sua prova. Se não está de todo a sair da rede, já sabe onde procurar. A captura de pacotes sob procura, disponível em plataformas como a Cisco Meraki e a HPE Aruba, permite-lhe realizar uma captura direcionada para um cliente ou VLAN específico sem tocar no hardware. Esse é o seu nível forense. Utiliza-o com moderação, mas quando precisa dele, é definitivo. Quarto nível: mapeamento de topologia e dependências. Num ambiente multi-tenant, precisa de um mapa em tempo real que mostre quais os pontos de acesso que servem quais os clientes, a que switches esses APs se ligam, que uplinks esses switches utilizam e que circuito de ISP serve cada uplink. Quando ocorre um incidente, pode identificar imediatamente o raio de impacto. Isto está a afetar um cliente ou todos os clientes? 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á no nível de WiFi, na rede do edifício ou na WAN. Também lhe diz quem mais deve envolver e quem pode excluir imediatamente. Quinto nível: correlação de eventos. Este é o nível que une tudo. Registos de alterações, alertas de manutenção do ISP, atualizações de firmware de dispositivos, eventos de energia e reclamações de utilizadores precisam todos de estar na mesma linha do 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 de vez com o jogo da atribuição de culpas. [curta pausa] Provas partilhadas mudam a dinâmica. Quando o fornecedor de WiFi pode enviar ao gestor da propriedade um link para um dashboard que mostra verde no nível sem fios, âmbar no switch interno 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 conectividade. E o contrato do fornecedor de WiFi é renovado porque foram eles que encontraram o problema. Esse é o argumento comercial para investir em ferramentas de observabilidade. Não apenas uma resolução de problemas mais rápida, mas sim 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 de 350 quartos. Os hóspedes de uma propriedade do 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 as verificações sintéticas a correr, o fornecedor consegue ver que os tempos de resolução DNS dispararam de doze milissegundos para quatrocentos milissegundos às sete e quarenta e três da manhã. A camada WiFi está saudável. O traçado do caminho (path trace) mostra que a latência é introduzida no terceiro salto (hop), que é o router de agregação do ISP. O fornecedor envia ao gestor do hotel uma captura de ecrã do traçado do caminho com o salto degradado realçado a vermelho, juntamente com o gráfico de verificação sintética que mostra que a camada WiFi esteve limpa durante todo o período. O ISP é contactado. O ISP confirma um problema de encaminhamento do lado deles. Tempo total desde a reclamação até à exoneração da camada 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 IP 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 dar-lhe a versão rápida das principais perguntas que me fazem sobre este tópico. É do WiFi ou do dispositivo? Execute uma verificação sintética 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. É do WiFi ou do ISP? Execute um traçado do caminho para a internet. Se a latência ou a perda forem introduzidas num salto fora do limite da sua rede, a culpa é do ISP. Qual é a diferença entre MTTI e "mean time to identify" (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, possui testes sintéticos integrados e diagnósticos de clientes. Use-os. Documente a sua topologia. Crie um painel de controlo partilhado que o gestor de 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 está fragmentada entre fornecedores, proprietários e ISPs, esta é a métrica que determina se retém ou perde contratos. A metodologia para a reduzir não é complicada: verificações sintéticas, visibilidade de caminhos, 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 a sua área. [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 Multi-Tenant WiFi da Purple apresenta este tipo de dados de observabilidade em 80.000 locais ativos, aceda a purple dot ai.