Mean time to innocence: come dimostrare che non è colpa del WiFi

Speak in British English with a confident, authoritative, and conversational tone - like a senior network consultant briefing a client over a coffee. Measured pace, clear diction, occasional dry wit. Not a lecture. Not a sales pitch. Just straight talk from someone who has seen this problem a hundred times: Benvenuti al briefing tecnico di Purple. Oggi voglio parlarvi di qualcosa che ogni responsabile di rete conosce fin nel profondo, anche se non ha mai sentito il termine formale. Mean time to innocence - il tempo medio per dimostrare l'innocenza. O MTTI. [breve pausa] Il tempo che passate a dimostrare che non è colpa vostra. Ecco lo scenario. Sono le nove del mattino. I residenti di un condominio in affitto iniziano a chiamare la reception. Il WiFi non funziona. Il property manager chiama il fornitore del servizio WiFi gestito. Il fornitore del WiFi gestito chiama l'ISP. L'ISP dice di controllare il router. Il team del router dice di controllare gli access point. Il produttore degli access point dice di controllare i dispositivi client. E nel bel mezzo di tutto questo, sono passati quarantacinque minuti e nessuno ha effettivamente risolto nulla. Questo, proprio questo, è il mean time to innocence in azione. [breve pausa] E vi sta costando più di quanto pensiate. Lasciate che lo definisca correttamente. Il mean time to innocence è il tempo medio che trascorre tra il momento in cui viene rilevato un problema e il momento in cui un qualsiasi team può dimostrare, prove alla mano, che il proprio dominio non è la causa principale. Non è la stessa cosa del mean time to identify, che è la metrica a livello aziendale per trovare l'effettiva causa principale. L'MTTI è compartimentato. È personale. È il team di rete che dice: ecco i dati, non siamo noi, ora cercate altrove. Il problema è che senza gli strumenti giusti, quella prova richiede tempo. E ogni minuto di MTTI è un minuto aggiunto direttamente al vostro tempo medio di risoluzione, il vostro MTTR. I due sono inseparabili. Allora perché si dà sempre la colpa al WiFi per primo? [breve pausa] Tre motivi. Primo, il WiFi è visibile. Quando qualcosa si rompe, le persone guardano ciò che possono vedere, e le tacche del segnale WiFi sul telefono sono l'indicatore di connettività più visibile. Secondo, il WiFi è l'ultimo miglio prima del dispositivo, quindi è la prima cosa che sembra sospetta quando un dispositivo non riesce a raggiungere internet. Terzo, e questo è l'aspetto più scomodo, i team del WiFi spesso non riescono a dimostrare rapidamente l'innocenza perché mancano della telemetria adeguata. Se non riuscite a mostrare un report pulito per lo strato wireless in meno di due minuti, passerete l'ora successiva a difendervi. Ora, in un ambiente enterprise single-tenant, questo è fastidioso. In un ambiente multi-tenant, è letteralmente dannoso. Si pensi a un hotel come Premier Inn, a un complesso residenziale build-to-rent o a un centro congressi che ospita eventi a ripetizione. C'è un property manager che non possiede la rete. Ci sono residenti o ospiti che non capiscono la rete. E c'è un provider WiFi gestito che è responsabile del layer wireless ma non del circuito ISP, del cablaggio interno all'edificio o dei dispositivi client. Quando qualcosa si rompe, il property manager incolpa il provider WiFi perché è il contratto a cui può fare riferimento. Il residente incolpa l'edificio perché è a quest'ultimo che paga l'affitto. E il provider WiFi deve scagionare la rete rapidamente, altrimenti il rapporto si deteriora. [breve pausa] L'MTTI non è solo una metrica tecnica in questo contesto. È una metrica commerciale. Parliamo quindi della metodologia che lo riduce concretamente. Ci sono cinque layer e sono necessari tutti e cinque. Layer uno: controlli sintetici continui. Prima ancora che venga aperto un ticket, dovresti avere sonde automatizzate in esecuzione dalla rete stessa, che testano la risoluzione DNS, la raggiungibilità HTTP, la latenza verso endpoint noti e i flussi di autenticazione. Strumenti come Marvis di Juniper Mist, o i test sintetici integrati in piattaforme come ThousandEyes, eseguono questi controlli ogni pochi minuti. Quando si verifica un incidente, puoi estrarre un grafico e mostrare esattamente quando il layer WiFi ha superato l'ultimo controllo sintetico pulito, e se era pulito o degradato al momento del reclamo. Questo da solo riduce drasticamente l'MTTI, perché o confermi che il WiFi era integro o confermi che non lo era, e smetti di discuterne. Layer due: visibilità del percorso hop-by-hop. Questo è il punto in cui la maggior parte dei team fallisce. Puoi dimostrare che l'access point è integro. Puoi dimostrare che lo switch è integro. Ma puoi dimostrare che il percorso dallo switch all'handoff dell'ISP è integro? In un edificio multi-tenant ci sono spesso hop che non possiedi. La rete di distribuzione interna all'edificio, lo switch core del proprietario dell'immobile, il punto di demarcazione verso l'ISP. Hai bisogno di dati di tracciamento del percorso che superino questi confini. Non solo un ping a otto-otto-otto-otto. Una reale visibilità in stile traceroute che ti mostri ogni hop, la sua latenza e se sta perdendo pacchetti. Quando puoi dimostrare che gli hop da uno a quattro sono puliti e l'hop cinque, che è l'edge router dell'ISP, mostra il quaranta percento di perdita di pacchetti, la conversazione cambia immediatamente. Terzo livello: dati di flusso con acquisizione di pacchetti on-demand. NetFlow e IPFIX offrono una vista a livello di conversazione di ciò che comunica con cosa all'interno della rete. Quando un residente segnala che il servizio di streaming non funziona, i dati di flusso indicano se il traffico verso gli intervalli IP di quel servizio sta effettivamente uscendo dalla rete. Se esce in modo pulito e il problema è a valle, questa è la tua prova. Se non esce affatto dalla rete, sai dove cercare. L'acquisizione di pacchetti on-demand, disponibile su piattaforme come Cisco Meraki e HPE Aruba, consente di effettuare un'acquisizione mirata per un client specifico o una VLAN senza toccare l'hardware. Questo è il tuo livello forense. Lo usi con parsimonia, ma quando serve, è definitivo. Quarto livello: mappatura della topologia e delle dipendenze. In un ambiente multi-tenant, serve una mappa in tempo reale che mostri quali access point servono quali tenant, a quali switch si collegano tali AP, quali uplink utilizzano tali switch e quale circuito ISP serve ciascun uplink. Quando si verifica un incidente, è possibile identificare immediatamente l'area di impatto. Interessa un solo tenant o tutti? Un piano o l'intero edificio? Una VLAN o tutte le VLAN? Questa domanda di scoping, a cui si risponde in trenta secondi grazie a una mappa della topologia, dice se il problema risiede nel livello WiFi, nella rete dell'edificio o nella WAN. Indica anche chi altro coinvolgere e chi si può escludere immediatamente. Quinto livello: correlazione degli eventi. Questo è l'elemento che unisce tutto il resto. Registri delle modifiche, avvisi di manutenzione dell'ISP, aggiornamenti del firmware dei dispositivi, eventi di alimentazione e reclami degli utenti devono trovarsi tutti sulla stessa sequenza temporale. Quando si sovrappone un picco di errori di associazione dei client a un aggiornamento del firmware avvenuto dodici minuti prima, si ha la causa principale. Quando si sovrappone un picco di latenza a una finestra di manutenzione dell'ISP che non è stata comunicata, si ha la prova per l'escalation. La correlazione degli eventi non è affascinante, ma fa la differenza tra uno scambio di accuse di quarantacinque minuti e una discolpa in quattro minuti. Ora, una parola sulla dimensione culturale, perché è qui che molti team sbagliano. L'obiettivo di ridurre il MTTI non è vincere più velocemente il gioco dello scaricabarile. È porre fine del tutto al gioco dello scaricabarile. [breve pausa] Le prove condivise cambiano la dinamica. Quando il provider WiFi può inviare al gestore della proprietà un link a una dashboard che mostra il verde sul livello wireless, l'arancione sullo switch dell'edificio e il rosso sul circuito dell'ISP, la conversazione smette di essere conflittuale. Diventa collaborativa. Il gestore della proprietà chiama l'ISP. L'ISP ripara il circuito. I residenti riottengono la connettività. E il contratto del provider WiFi viene rinnovato perché è stato l'unico a individuare il problema. Questo è il caso commerciale per investire in strumenti di osservabilità. Non solo una risoluzione dei problemi più rapida, ma relazioni migliori con le persone che ti pagano. Lasciatemi passare in rassegna un paio di scenari rapidi per rendere tutto questo concreto. Scenario uno: un hotel da 350 camere. Gli ospiti di una struttura in stile Premier Inn iniziano a segnalare che il WiFi in camera è lento. La reception apre un ticket con il fornitore del servizio WiFi gestito. Grazie ai controlli sintetici attivi, il fornitore può vedere che i tempi di risoluzione DNS sono passati da dodici millisecondi a quattrocento millisecondi alle sette e quarantatré del mattino. Il livello WiFi è integro. Il tracciamento del percorso mostra che la latenza viene introdotta al terzo hop, ovvero il router di aggregazione dell'ISP. Il fornitore invia al direttore dell'hotel uno screenshot del tracciamento del percorso con l'hop degradato evidenziato in rosso, insieme al grafico dei controlli sintetici che mostra che il livello WiFi è rimasto pulito per tutto il tempo. Viene contattato l'ISP. L'ISP conferma un problema di routing dal proprio lato. Tempo totale dal reclamo all'esonero da responsabilità del livello WiFi: sei minuti. MTTR per l'intero incidente: ventidue minuti, perché la risoluzione dell'ISP ha richiesto sedici minuti. Senza gli strumenti di osservabilità, quell'esonero da responsabilità di sei minuti avrebbe richiesto quaranta minuti di scambi di messaggi, e l'MTTR sarebbe stato superiore a un'ora. Scenario due: una catena di negozi al dettaglio. Un rivenditore nazionale con WiFi in duecento negozi nota che i terminali dei punti vendita in una regione perdono a intermittenza la connettività con il processore di pagamento. Il team di rete viene immediatamente incolpato. I dati di flusso mostrano che il traffico verso l'intervallo IP del processore di pagamento esce in modo pulito dalla rete del negozio. Il problema non è la rete. Un packet capture sulla VLAN del processore di pagamento mostra un picco di ritrasmissioni TCP, il che indica un problema lato server presso il processore di pagamento. Il team di rete condivide i dati di flusso e il riepilogo dell'acquisizione con il team di supporto del processore di pagamento. Il processore di pagamento individua un bilanciatore di carico configurato in modo errato dal proprio lato. L'MTTI del team di rete: otto minuti. Tempo di risoluzione del processore di pagamento: trentacinque minuti. Senza i dati di flusso, il team di rete avrebbe trascorso quei trentacinque minuti a riconfigurare le VLAN e a riavviare switch che funzionavano perfettamente. Bene. Lasciate che vi proponga la versione a risposta rapida delle domande chiave che mi vengono poste su questo argomento. È il WiFi o il dispositivo? Eseguite un controllo sintetico dall'AP stesso. Se l'AP può raggiungere internet in modo pulito e il dispositivo no, il problema è il dispositivo. Se l'AP non riesce a raggiungere internet, il problema è a monte del dispositivo. È il WiFi o l'ISP? Eseguite un tracciamento del percorso verso internet. Se la latenza o la perdita vengono introdotte in un hop al di fuori del confine della vostra rete, il problema è dell'ISP. Qual è la differenza tra MTTI e mean time to identify? L'MTTI è il tempo impiegato dal vostro team per dimostrare la propria innocenza. Il mean time to identify è il tempo impiegato dall'organizzazione per trovare il vero colpevole. L'MTTI è un sottoinsieme del mean time to identify. Come posso ridurre il MTTI senza acquistare nuovi strumenti? Inizia con quello che hai. La maggior parte delle piattaforme di access point aziendali, tra cui Cisco Meraki, HPE Aruba e Juniper Mist, dispongono di diagnostica dei client e test sintetici integrati. Usali. Documenta la tua topologia. Crea una dashboard condivisa che il property manager o il team operativo possano visualizzare. La trasparenza è lo strumento di riduzione del MTTI più economico disponibile. Per concludere. Il tempo medio di innocenza è la tassa nascosta su ogni incidente di rete. Nei contesti multi-tenant, in cui la responsabilità è frammentata tra fornitori, proprietari e ISP, è la metrica che determina se manterrai i contratti o li perderai. La metodologia per ridurlo non è complicata: controlli sintetici, visibilità del percorso, dati di flusso, mappatura della topologia e correlazione degli eventi. L'obiettivo non è vincere il gioco del rimpallo di responsabilità. È sostituire tale gioco con prove condivise, in modo che ogni team possa concentrarsi sulla risoluzione del problema piuttosto che sulla difesa del proprio territorio. [breve pausa] Perché ogni minuto speso a dimostrare l'innocenza è un minuto in più che i tuoi residenti, ospiti o acquirenti trascorrono senza connettività. E questo è l'unico numero che conta davvero. Grazie per l'ascolto. Se desideri vedere come la piattaforma Multi-Tenant WiFi di Purple mette in evidenza questo tipo di dati di osservabilità in 80.000 sedi attive, visita purple dot ai.