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 vi parlerò di qualcosa che ogni responsabile di rete conosce fin nel profondo, anche se non ha mai sentito il termine formale per definirlo. Mean time to innocence. O MTTI. [breve pausa] Il tempo che si perde a dimostrare che non è colpa vostra. Ecco lo scenario. Sono le nove del mattino. I residenti di un condominio in affitto (build-to-rent) 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 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 determinato 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 aziendale globale per trovare l'effettiva causa principale. L'MTTI è isolato nei silos. È personale. È il team di rete che dice: ecco i dati, non siamo noi, ora cercate altrove. Il problema è che, senza gli strumenti adatti, quella prova richiede tempo. E ogni minuto di MTTI è un minuto aggiunto direttamente al vostro mean time to resolution, il vostro MTTR. I due elementi sono inseparabili. Perché allora si dà sempre la colpa al WiFi per primo? [breve pausa] Per tre motivi. Primo, il WiFi è visibile. Quando qualcosa si rompe, le persone guardano ciò che possono vedere, e le barre 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 appare sospetta quando un dispositivo non riesce a navigare in internet. Terzo, e questo è il tasto dolente, i team che gestiscono il WiFi spesso non riescono a dimostrare rapidamente la propria innocenza perché non dispongono della telemetria adeguata. Se non siete in grado di mostrare uno stato di salute impeccabile per il livello 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, è realmente 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 catena. C'è un property manager che non possiede la rete. Ci sono residenti o ospiti che non comprendono la rete. E c'è un provider WiFi gestito che è responsabile del livello wireless ma non del circuito ISP, non del cablaggio dell'edificio e non dei dispositivi client. Quando qualcosa si rompe, il property manager incolpa il provider WiFi perché quello è il contratto a cui può fare riferimento. Il residente incolpa l'edificio perché è a loro 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 livelli, e servono tutti e cinque. Livello 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 il testing sintetico integrato in piattaforme come ThousandEyes, eseguono questi controlli ogni pochi minuti. Quando si verifica un incidente, puoi estrarre un grafico e mostrare esattamente quando il livello 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, smettendo di discuterne. Livello 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, spesso ci sono hop di cui non si ha la proprietà. La rete di distribuzione interna all'edificio, lo switch core del proprietario, il punto di demarcazione verso l'ISP. Servono dati di tracciamento del percorso che superino questi confini. Non un semplice ping a 8.8.8.8. Una visibilità effettiva in stile traceroute che mostri ogni hop, la relativa latenza e se sta perdendo pacchetti. Quando puoi dimostrare che gli hop da uno a quattro sono puliti e l'hop cinque, che è il router edge 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 visione a livello di conversazione di ciò che comunica con cosa sulla rete. Quando un residente dice che il servizio di streaming non funziona, i dati di flusso indicano se il traffico verso gli intervalli IP di quel servizio sta effettivamente lasciando la rete. Se sta lasciando la rete correttamente e il problema si trova a valle, questa è la prova. Se non sta lasciando affatto la rete, si sa 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 o una VLAN specifica senza toccare l'hardware. Questo è il livello forense. Si usa 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 quegli 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 i tenant? Un solo piano o l'intero edificio? Una sola VLAN o tutte le VLAN? Questa domanda di scoping, a cui si risponde in trenta secondi grazie a una mappa topologica, 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. 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 un rimpallo di responsabilità di quarantacinque minuti e un'assoluzione in quattro minuti. Ora, una parola sulla dimensione culturale, perché è qui che molti team sbagliano. L'obiettivo di ridurre l'MTTI non è vincere più velocemente al gioco del rimpallo di responsabilità. È porre fine del tutto a questo gioco. [breve pausa] Le prove condivise cambiano le dinamiche. Quando il provider WiFi può inviare al gestore della proprietà un link a una dashboard che mostra il verde sul livello wireless, l'ambra sullo switch interno all'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 lui a trovare 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 pagano. Permettetemi di presentare un paio di rapidi scenari per rendere concreto questo aspetto. 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 provider di WiFi gestito. Grazie ai controlli sintetici attivi, il provider può vedere che i tempi di risoluzione DNS sono balzati 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, che è il router di aggregazione dell'ISP. Il provider invia al direttore dell'hotel uno screenshot del tracciamento del percorso con l'hop degradato evidenziato in rosso, insieme al grafico del controllo sintetico che mostra che il livello WiFi è rimasto pulito per tutto il tempo. Viene contattato l'ISP. L'ISP conferma un problema di instradamento dal proprio lato. Tempo totale dal reclamo all'esonero del livello WiFi: sei minuti. MTTR per l'intero incidente: ventidue minuti, perché il ripristino dell'ISP ha richiesto sedici minuti. Senza lo strumento di osservabilità, quell'esonero di sei minuti sarebbe costato quaranta minuti di continui scambi di comunicazioni, e l'MTTR sarebbe stato superiore a un'ora. Scenario due: una catena di negozi al dettaglio. Un rivenditore nazionale con copertura WiFi in duecento negozi nota che i terminali dei punti vendita in una regione perdono a intermittenza la connettività con il processore di pagamento. La colpa viene immediatamente attribuita al team di rete. 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'acquisizione di pacchetti 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. Quest'ultimo identifica un bilanciatore di carico configurato in modo errato sul proprio lato. L'MTTI del team di rete: otto minuti. Tempo di ripristino 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 presenti la versione rapida delle domande chiave che mi vengono poste su questo argomento. È il WiFi o il dispositivo? Esegui un controllo sintetico dall'AP stesso. Se l'AP riesce a raggiungere internet in modo pulito e il dispositivo no, allora si tratta del dispositivo. Se l'AP non riesce a raggiungere internet, il problema si trova a monte del dispositivo. È il WiFi o l'ISP? Esegui un tracciamento del percorso verso internet. Se la latenza o la perdita vengono introdotte in un hop al di fuori del confine della tua rete, si tratta dell'ISP. Qual è la differenza tra MTTI e mean time to identify? L'MTTI è il tempo impiegato dal tuo 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, dispone di test sintetici e diagnostica client integrati. Usali. Documenta la tua topologia. Costruisci una dashboard condivisa che il property manager o il team operativo possano vedere. La trasparenza è lo strumento di riduzione del MTTI più economico disponibile. Per concludere. Il "mean time to innocence" è la tassa nascosta su ogni incidente di rete. Negli ambienti 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 delle colpe. È sostituire il gioco delle colpe 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ù al tempo che i tuoi residenti, ospiti o acquirenti trascorrono senza connettività. E questo è il numero che conta davvero. Grazie per l'ascolto. Se vuoi vedere come la piattaforma Multi-Tenant WiFi di Purple rende visibili questo tipo di dati di osservabilità su oltre 80.000 sedi attive, vai su purple dot ai.