Temps moyen d'innocence : comment prouver que le problème ne vient pas du WiFi

S'exprimer en anglais britannique avec un ton confiant, autoritaire et conversationnel - comme un consultant réseau senior briefant un client autour d'un café. Un rythme mesuré, une diction claire, un trait d'esprit sec 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 ce brief technique Purple. Je vais vous parler aujourd'hui d'un sujet 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 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 profonde. Ce n'est pas la même chose que le temps moyen d'identification, qui est la mesure à l'échelle de l'organisation pour trouver la véritable cause profonde. Le MTTI est cloisonné. Il est personnel. C'est l'équipe réseau qui dit : voici les données, ce n'est pas nous, maintenant 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 inséparables. Alors pourquoi le WiFi est-il toujours accusé en premier ? [courte pause] Trois raisons. Premièrement, le WiFi est visible. Quand quelque chose ne fonctionne pas, 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 sensible, les équipes WiFi ne peuvent souvent pas prouver leur innocence rapidement parce qu'elles manquent de la bonne télémétrie. 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.Désormais, dans un environnement d'entreprise à locataire unique, cela est agaçant. Dans un environnement multi-tenant, cela est véritablement préjudiciable. Pensez à un hôtel comme Premier Inn, ou à un immeuble résidentiel construit pour la location, ou à un centre de conférences 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 invités 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 fournisseur d'accès internet, ni du câblage interne du bâtiment, ni des appareils clients. Lorsque quelque chose tombe en panne, le gestionnaire immobilier accuse le fournisseur de WiFi car c'est le contrat vers lequel il peut se tourner. Le résident accuse l'immeuble car c'est à lui qu'il paie son loyer. Et le fournisseur de WiFi doit dédouaner le réseau rapidement, sous peine de voir la relation se détériorer. [courte pause] Dans ce contexte, le MTTI n'est pas seulement une métrique technique. 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 de ces cinq couches. Couche une : les contrôles synthétiques continus. Avant même qu'un ticket ne soit créé, vous devriez avoir des sondes automatisées exécutées depuis le réseau lui-même, 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 dans 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 subi son dernier contrôle synthétique propre, et s'il était propre ou dégradé au moment de la plainte. Cela réduit à lui seul le MTTI de manière spectaculaire, car soit vous confirmez que le WiFi était opérationnel, soit vous confirmez qu'il ne l'était pas, et vous arrêtez d'en 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 opérationnel. Vous pouvez prouver que le commutateur est opérationnel. Mais pouvez-vous prouver que le chemin du commutateur jusqu'au point de raccordement du fournisseur d'accès internet est opérationnel ? Dans un immeuble 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 fournisseur d'accès internet. Vous avez besoin de données de suivi de chemin qui traversent ces frontières. Pas seulement un simple 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 démontrer que les sauts un à quatre sont propres et que le saut cinq, qui est le routeur périphérique du fournisseur d'accès internet, affiche quarante pour cent de perte de paquets, la conversation change immédiatement. Troisième couche : les données de flux avec capture de paquets à la demande. NetFlow et IPFIX vous offrent une vue au niveau des conversations pour savoir qui communique avec qui sur le réseau. Lorsqu'un résident signale que le service de streaming ne fonctionne pas, les données de flux vous indiquent si le trafic vers les plages IP de ce service quitte bien le réseau. S'il quitte le réseau correctement et que le problème se situe en aval, vous en avez la 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 forensique. Vous l'utilisez avec parcimonie, mais quand vous en avez besoin, elle est incontestable. Quatrième couche : la cartographie de la topologie et des dépendances. Dans un environnement multi-locataire, vous avez besoin d'une carte en temps réel indiquant quels points d'accès desservent quels locataires, à quels commutateurs ces AP se connectent, quels uplinks ces commutateurs utilisent et quel circuit de fournisseur d'accès internet dessert chaque uplink. Lorsqu'un incident survient, vous pouvez immédiatement identifier la zone d'impact. Est-ce que cela affecte 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 topologique, 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 impliquer et qui vous pouvez immédiatement exclure. Cinquième couche : la corrélation d'événements. C'est celle qui relie le tout. Les journaux de modifications, les alertes de maintenance des fournisseurs d'accès, les mises à jour de firmware des appareils, les événements liés à l'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 plage de maintenance d'un fournisseur d'accès qui ne vous a pas été communiquée, vous disposez de votre preuve pour l'escalade. La corrélation d'événements n'a rien de glamour, mais c'est ce qui fait la différence entre un jeu de reproches de quarante-cinq minutes et une mise hors de cause en quatre minutes. À présent, un mot sur la dimension culturelle, car c'est là que de nombreuses équipes font fausse route. 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 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 fournisseur d'accès, la conversation cesse d'être conflictuelle. Elle devient collaborative. Le gestionnaire immobilier appelle le fournisseur d'accès. Le fournisseur d'accès dépanne le circuit. Les résidents retrouvent leur connexion. Et le contrat du fournisseur WiFi est renouvelé parce que c'est lui qui a identifié le problème. Voilà l'argument commercial en faveur de l'investissement dans les outils d'observabilité. Il ne s'agit pas seulement d'un dépannage plus rapide, mais de meilleures relations avec les personnes qui vous rémunèrent. Permettez-moi de passer en revue quelques scénarios rapides pour rendre cela plus concret. Premier scénario : un hôtel de 350 chambres. Les clients d'un établissement de style Premier Inn commencent à signaler que le WiFi en chambre est lent. La réception enregistre un ticket auprès du fournisseur de WiFi managé. Grâce aux vérifications synthétiques en cours, le fournisseur constate que les temps de résolution DNS sont passés de douze millisecondes à quatre cents millisecondes à sept heures quarante-trois du matin. La couche WiFi est saine. Le suivi de chemin montre que la latence est introduite au troisième saut, qui est le routeur d'agrégation du fournisseur d'accès internet. Le fournisseur envoie au directeur de l'hôtel une capture d'écran du suivi de chemin avec le saut dégradé surligné en rouge, ainsi que le graphique de vérification synthétique montrant que la couche WiFi était propre tout au long de l'incident. Le fournisseur d'accès internet est contacté. Il confirme un problème de routage de son côté. Temps total entre la plainte et la mise hors de cause de la couche WiFi : six minutes. MTTR pour l'incident complet : vingt-deux minutes, car la résolution du fournisseur d'accès internet a pris seize minutes. Sans les outils d'observabilité, cette mise hors de cause de six minutes aurait nécessité quarante minutes d'allers-retours, et le MTTR aurait dépassé une heure. Deuxième scénario : une chaîne de magasins. Un détaillant national disposant du WiFi dans deux cents magasins remarque que les terminaux de point de vente d'une région perdent par intermittence la connexion avec le processeur de paiement. L'équipe réseau est immédiatement pointée du doigt. 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. Ce dernier identifie un équilibreur de charge mal configuré de son côté. Le MTTI de l'équipe réseau : huit minutes. Temps de résolution 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 présenter la version rapide des questions clés que l'on me pose sur ce sujet. Est-ce le WiFi ou l'appareil ? Lancez une vérification synthétique à partir de l'AP lui-même. Si l'AP peut accéder 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 fournisseur d'accès internet ? Effectuez un suivi de chemin vers internet. Si la latence ou la perte est introduite à un saut situé en dehors des limites de votre réseau, le problème vient du fournisseur d'accès internet. Quelle est la différence entre 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 véritable coupable. 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 possédez déjà. La plupart des plateformes de points d'accès d'entreprise, y compris 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é accessible par le gestionnaire immobilier ou l'équipe opérationnelle. La transparence est l'outil de réduction du MTTI le plus économique disponible. En résumé. Le temps moyen d'innocence (MTTI) est la taxe invisible sur chaque incident réseau. Dans les environnements multi-locataires, où la responsabilité est fragmentée entre les fournisseurs, les propriétaires et les 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 complexe : contrôles synthétiques, visibilité des chemins, données de flux, cartographie de la topologie et corrélation d'événements. L'objectif n'est pas de gagner au 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, invités ou clients passent sans connectivité WiFi. Et c'est ce chiffre qui compte réellement. Merci pour votre écoute. Si vous souhaitez découvrir comment la plateforme de WiFi multi-locataire de Purple met en valeur ce type de données d'observabilité sur plus de 80 000 sites actifs, rendez-vous sur purple dot ai.