Temps moyen d'innocence : comment prouver que le WiFi n'est pas en cause

S'exprimer en français avec un ton confiant, autoritaire et conversationnel - comme un consultant réseau senior briefant un client autour d'un café. Rythme mesuré, diction claire, humour pince-sans-rire occasionnel. Pas un cours magistral. Pas un discours commercial. Juste un discours franc de la part de quelqu'un qui a vu ce problème cent fois : Bienvenue dans le brief technique de Purple. Je vais vous parler aujourd'hui de quelque chose que chaque gestionnaire de réseau ressent au plus profond de lui-même, même s'il n'en a jamais entendu le terme formel. Le temps moyen d'innocence. Ou MTTI. [courte pause] Le temps que vous passez à prouver que ce n'est pas de votre faute. Voici le scénario. Il est neuf heures du matin. Les résidents d'un immeuble en location résidentielle gérée commencent à appeler la réception. Le WiFi est en panne. Le gestionnaire immobilier appelle le fournisseur de WiFi géré. Le fournisseur de WiFi géré appelle le FAI. Le FAI dit de vérifier le routeur. L'équipe du routeur dit de vérifier les points d'accès. Le fournisseur de points d'accès dit de vérifier les appareils clients. Et quelque part au milieu de tout cela, quarante-cinq minutes se sont écoulées, et personne n'a encore rien réparé. C'est exactement cela, le temps moyen d'innocence en action. [courte pause] Et cela vous coûte plus cher que vous ne le pensez. Laissez-moi le définir correctement. Le temps moyen d'innocence est le temps moyen écoulé entre le moment où un problème est détecté et le moment où une équipe donnée peut démontrer, preuves à l'appui, que son domaine n'est pas la cause racine. Ce n'est pas la même chose que le temps moyen d'identification, qui est la métrique globale de l'organisation pour trouver la cause racine réelle. Le MTTI est cloisonné. Il est personnel. C'est l'équipe réseau qui dit : voici les données, ce n'est pas nous, cherchez ailleurs. Le problème est que sans les bons outils, cette preuve prend du temps. Et chaque minute de MTTI est une minute ajoutée directement à votre temps moyen de résolution, votre MTTR. Les deux sont indissociables. Alors, pourquoi le WiFi est-il toujours accusé en premier ? [courte pause] Trois raisons. Premièrement, le WiFi est visible. Quand quelque chose tombe en panne, les gens regardent ce qu'ils peuvent voir, et les barres de signal WiFi sur leur téléphone sont l'indicateur de connectivité le plus visible. Deuxièmement, le WiFi est le dernier saut avant l'appareil, c'est donc la première chose qui semble suspecte lorsqu'un appareil ne peut pas accéder à Internet. Troisièmement, et c'est le point délicat, les équipes WiFi ne peuvent souvent pas prouver leur innocence rapidement parce qu'elles manquent de la télémétrie adéquate. Si vous ne pouvez pas présenter un bilan de santé impeccable pour la couche sans fil en moins de deux minutes, vous allez passer l'heure suivante à vous défendre. Dans une entreprise mono-locataire, c'est agaçant. Dans un environnement multi-tenant, c'est véritablement préjudiciable. Pensez à un hôtel comme Premier Inn, à un immeuble résidentiel en location gérée ou à un centre de conférence qui enchaîne les événements. Vous avez un gestionnaire immobilier qui ne possède pas le réseau. Vous avez des résidents ou des clients qui ne comprennent pas le réseau. Et vous avez un fournisseur de WiFi géré qui est responsable de la couche sans fil mais pas du circuit du FAI, ni du câblage interne du bâtiment, ni des appareils clients. Quand quelque chose tombe en panne, le gestionnaire immobilier accuse le fournisseur de WiFi parce que c'est le contrat qu'il peut pointer du doigt. Le résident accuse l'immeuble parce que c'est à lui qu'il paie son loyer. Et le fournisseur de WiFi doit disculper le réseau rapidement, sous peine de voir la relation se détériorer. [courte pause] Le MTTI n'est pas seulement une métrique technique dans ce contexte. C'est une métrique commerciale. Parlons donc de la méthodologie qui permet réellement de le raccourcir. Il y a cinq couches, et vous avez besoin des cinq. Couche un : les contrôles synthétiques continus. Avant même qu'un ticket ne soit ouvert, vous devriez avoir des sondes automatisées qui s'exécutent depuis la périphérie du réseau, testant la résolution DNS, l'accessibilité HTTP, la latence vers des points de terminaison connus et les flux d'authentification. Des outils comme Marvis de Juniper Mist, ou les tests synthétiques intégrés à des plateformes comme ThousandEyes, exécutent ces contrôles toutes les quelques minutes. Lorsqu'un incident survient, vous pouvez afficher un graphique et montrer exactement quand la couche WiFi a effectué son dernier contrôle synthétique propre, et si elle était saine ou dégradée au moment de la plainte. Cela réduit à lui seul considérablement le MTTI, car soit vous confirmez que le WiFi était sain, soit vous confirmez qu'il ne l'était pas, et vous arrêtez de débattre. Couche deux : la visibilité du chemin saut par saut. C'est là que la plupart des équipes échouent. Vous pouvez prouver que le point d'accès est sain. Vous pouvez prouver que le commutateur est sain. Mais pouvez-vous prouver que le chemin reliant le commutateur au raccordement du FAI est sain ? Dans un bâtiment multi-tenant, il y a souvent des sauts qui ne vous appartiennent pas. Le réseau de distribution interne du bâtiment, le commutateur central du propriétaire, le point de démarcation avec le FAI. Vous avez besoin de données de tracé de chemin qui traversent ces frontières. Pas seulement un ping vers huit-huit-huit-huit. Une véritable visibilité de type traceroute qui vous montre chaque saut, sa latence et s'il perd des paquets. Lorsque vous pouvez montrer que les sauts un à quatre sont propres et que le saut cinq, qui est le routeur périphérique du FAI, affiche quarante pour cent de perte de paquets, la conversation change immédiatement. Couche trois : les données de flux avec capture de paquets à la demande. NetFlow et IPFIX vous offrent une vue au niveau des conversations de ce qui communique sur le réseau. Lorsqu'un résident dit que le service de streaming est en panne, les données de flux vous indiquent si le trafic vers les plages IP de ce service quitte seulement le réseau. S'il quitte proprement le réseau et que le problème se situe en aval, voilà votre preuve. S'il ne quitte pas du tout le réseau, vous savez où chercher. La capture de paquets à la demande, disponible sur des plateformes comme Cisco Meraki et HPE Aruba, vous permet d'effectuer une capture ciblée pour un client ou un VLAN spécifique sans toucher au matériel. C'est votre couche d'analyse technique. Vous l'utilisez avec parcimonie, mais quand vous en avez besoin, elle est définitive. Couche quatre : la cartographie de la topologie et des dépendances. Dans un environnement multi-tenant, vous avez besoin d'une carte en direct qui montre quels points d'accès desservent quels locataires, à quels commutateurs ces AP se connectent, quelles liaisons montantes ces commutateurs utilisent et quel circuit FAI dessert chaque liaison montante. Lorsqu'un incident survient, vous pouvez immédiatement identifier le rayon d'impact. Cela affecte-t-il un seul locataire ou tous les locataires ? Un seul étage ou tout le bâtiment ? Un seul VLAN ou tous les VLAN ? Cette question de portée, résolue en trente secondes grâce à une carte de topologie, vous indique si le problème se situe au niveau de la couche WiFi, du réseau du bâtiment ou du WAN. Elle vous indique également qui d'autre impliquer et qui vous pouvez immédiatement exclure. Couche cinq : la corrélation d'événements. C'est celle qui relie tout le reste. Les journaux de modifications, les alertes de maintenance des FAI, les mises à jour de firmware des appareils, les événements d'alimentation et les plaintes des utilisateurs doivent tous figurer sur la même chronologie. Lorsque vous superposez un pic d'échecs d'association de clients à une mise à jour de firmware survenue douze minutes plus tôt, vous tenez votre cause racine. Lorsque vous superposez un pic de latence à une fenêtre de maintenance de FAI qui ne vous a pas été communiquée, vous tenez votre preuve pour l'escalade. La corrélation d'événements n'est pas glamour, mais c'est la différence entre un jeu de reproches de quarante-cinq minutes et une disculpation en quatre minutes. Un mot maintenant sur la dimension culturelle, car c'est là que beaucoup d'équipes se trompent. L'objectif de la réduction du MTTI n'est pas de gagner le jeu des reproches plus rapidement. C'est d'y mettre fin définitivement. [courte pause] Les preuves partagées changent la dynamique. Lorsque le fournisseur de WiFi peut envoyer au gestionnaire immobilier un lien vers un tableau de bord affichant du vert sur la couche sans fil, de l'orange sur le commutateur du bâtiment et du rouge sur le circuit du FAI, la conversation cesse d'être conflictuelle. Elle devient collaborative. Le gestionnaire immobilier appelle le FAI. Le FAI répare le circuit. Les résidents retrouvent leur connectivité. Et le contrat du fournisseur de WiFi est renouvelé parce que c'est lui qui a trouvé le problème. C'est là tout l'intérêt commercial d'investir dans des outils d'observabilité. Pas seulement un dépannage plus rapide, mais de meilleures relations avec les personnes qui vous paient. Passons en revue deux scénarios rapides pour rendre cela concret. Scénario un : un hôtel de 350 chambres. Les clients d'un établissement de type Premier Inn commencent à signaler que le WiFi dans les chambres est lent. La réception enregistre un ticket auprès du fournisseur de WiFi géré. Grâce aux contrôles synthétiques en cours, le fournisseur constate que les temps de résolution DNS ont bondi de douze millisecondes à quatre cents millisecondes à sept heures quarante-trois du matin. La couche WiFi est saine. Le tracé de chemin montre que la latence est introduite au troisième saut, qui est le routeur d'agrégation du FAI. Le fournisseur envoie au directeur de l'hôtel une capture d'écran du tracé de chemin avec le saut dégradé surligné en rouge, à côté du graphique du contrôle synthétique montrant que la couche WiFi est restée propre tout au long. Le FAI est contacté. Le FAI confirme un problème de routage de son côté. Temps total entre la plainte et la disculpation de la couche WiFi : six minutes. MTTR pour l'incident complet : vingt-deux minutes, car la correction du FAI a pris seize minutes. Sans les outils d'observabilité, cette disculpation de six minutes aurait donné lieu à quarante minutes d'allers-retours, et le MTTR aurait dépassé une heure. Scénario deux : une chaîne de magasins. Un détaillant national disposant du WiFi dans deux cents magasins constate que les terminaux de point de vente d'une région perdent par intermittence leur connectivité avec le processeur de paiement. L'équipe réseau est immédiatement accusée. Les données de flux montrent que le trafic vers la plage IP du processeur de paiement quitte proprement le réseau du magasin. Le problème ne vient pas du réseau. Une capture de paquets sur le VLAN du processeur de paiement montre un pic de retransmissions TCP, ce qui indique un problème côté serveur chez le processeur de paiement. L'équipe réseau partage les données de flux et le résumé de la capture avec l'équipe d'assistance du processeur de paiement. Le processeur de paiement identifie un répartiteur de charge mal configuré de son côté. Le MTTI de l'équipe réseau : huit minutes. Le temps de correction du processeur de paiement : trente-cinq minutes. Sans les données de flux, l'équipe réseau aurait passé ces trente-cinq minutes à reconfigurer des VLAN et à redémarrer des commutateurs qui fonctionnaient parfaitement. Très bien. Laissez-moi vous donner la version rapide des questions clés que l'on me pose sur ce sujet. Est-ce le WiFi ou l'appareil ? Lancez un contrôle synthétique depuis l'AP lui-même. Si l'AP accède proprement à Internet et que l'appareil ne le peut pas, le problème vient de l'appareil. Si l'AP ne peut pas accéder à Internet, le problème se situe en amont de l'appareil. Est-ce le WiFi ou le FAI ? Effectuez un tracé de chemin vers Internet. Si la latence ou la perte est introduite à un saut situé en dehors des limites de votre réseau, c'est le FAI. Quelle est la différence entre le MTTI et le temps moyen d'identification ? Le MTTI est le temps nécessaire à votre équipe pour prouver son innocence. Le temps moyen d'identification est le temps nécessaire à l'organisation pour trouver le coupable réel. Le MTTI est un sous-ensemble du temps moyen d'identification. Comment réduire le MTTI sans acheter de nouveaux outils ? Commencez par ce que vous avez. La plupart des plateformes de points d'accès d'entreprise, notamment Cisco Meraki, HPE Aruba et Juniper Mist, intègrent des tests synthétiques et des diagnostics clients. Utilisez-les. Documentez votre topologie. Créez un tableau de bord partagé visible par le gestionnaire immobilier ou l'équipe des opérations. La transparence est l'outil de réduction du MTTI le moins cher du marché. Pour conclure. Le temps moyen d'innocence est la taxe invisible sur chaque incident réseau. Dans les environnements multi-tenant, où la responsabilité est fragmentée entre fournisseurs, propriétaires et FAI, c'est la métrique qui détermine si vous conservez vos contrats ou si vous les perdez. La méthodologie pour le réduire n'est pas compliquée : contrôles synthétiques, visibilité du chemin, données de flux, cartographie de la topologie et corrélation d'événements. L'objectif n'est pas de gagner le jeu des reproches. Il s'agit de remplacer ce jeu par des preuves partagées, afin que chaque équipe puisse se concentrer sur la résolution du problème plutôt que sur la défense de son territoire. [courte pause] Car chaque minute passée à prouver son innocence est une minute de plus que vos résidents, clients ou acheteurs passent sans connectivité. Et c'est ce chiffre qui compte réellement. Merci pour votre écoute. Si vous souhaitez voir comment la plateforme de WiFi multi-tenant de Purple fait remonter ce type de données d'observabilité sur 80 000 sites actifs, rendez-vous sur purple point ai.