Litiges SLA opérateurs mobiles : pourquoi les preuves gagnent et les captures d'écran perdent

Chaque TowerCo, chaque opérateur colo, chaque CPO avec un SLA porteur de crédit a vécu cette conversation. Le locataire dépose un litige. Le locataire a des captures d'écran de sa propre surveillance montrant la panne de son côté. L'opérateur a des tableaux de bord montrant le site comme disponible. Les deux parties regardent des données réelles. Les deux parties sont convaincues que les données de l'autre partie sont fausses. Le litige se clôture avec un accord négocié qui ne reflète probablement pas ce qui s'est vraiment passé.

Les accords négociés sont une défaillance structurelle. Ils signifient qu'aucune des preuves des deux parties n'était suffisamment solide pour régler la question, ce qui signifie que le prochain litige aura la même forme. La sortie n'est pas une meilleure négociation — c'est une preuve qui soit de qualité cryptographique pour les litiges. Et l'écart entre une capture d'écran et une preuve de qualité litige est plus grand que la plupart des opérateurs ne le réalisent.

Deux parties avec deux piles de surveillance différentes observant la même infrastructure physique produiront deux chronologies différentes. Ce n'est pas un bug. C'est le comportement attendu de tout système où la surveillance est asynchrone, les chemins réseau sont différents, la méthodologie de comptage est différente, et les bases de temps peuvent ne pas être précisément synchronisées.

Une capture d'écran d'un RMS fournisseur est une affirmation sur l'état. Un flux d'événements hash-chained est un enregistrement de l'état. Les litiges SLA se règlent sur des enregistrements, pas sur des affirmations.

Le RMS fournisseur d'un TowerCo peut compter un site comme « disponible » tant que le contrôleur de site est joignable et que l'agrégateur BTS signale alimentation OK. Le NOC du locataire opérateur mobile peut compter le même site comme « en panne » si son réseau cœur n'a pas reçu de trafic des secteurs cellulaires depuis 90 secondes. Les deux définitions sont défendables. Elles mesurent des choses différentes. Aucune équipe n'est malhonnête.

Une capture d'écran d'une console RMS fournisseur est fondamentalement une affirmation sur ce à quoi le système ressemblait à un moment dans le temps. Il n'y a rien dans la capture d'écran elle-même qui dise : ce rendu a été généré à partir d'un ensemble spécifique d'événements de télémétrie sous-jacents ; ces événements se sont produits à ces moments précis ; les événements n'ont pas été altérés depuis leur enregistrement ; le rendu a appliqué cette méthodologie spécifique.

Quand un litige s'escalade et qu'un tiers — une équipe juridique, un arbitre, un auditeur — essaie d'évaluer la capture d'écran comme preuve, la capture répond à environ zéro des questions pertinentes. Quelles étaient les données sous-jacentes ? Étaient-elles complètes ? Quelqu'un aurait-il pu les modifier entre l'événement et le rendu ? Le tableau de bord a-t-il appliqué la même méthodologie que celle définie dans le SLA ? La plupart des systèmes RMS fournisseurs ne peuvent pas répondre à ces questions parce qu'ils n'ont pas été conçus pour ça.

Un flux d'événements de qualité litige a quatre propriétés qu'une capture d'écran n'a pas. Complétude : chaque transition d'état dans le système est enregistrée — perte réseau, fonctionnement ATS, alimentation BTS OK, remontée RF secteur — au moment de la transition, pas comme un cumul de synthèse. Inviolabilité : chaque événement est hash-chained au précédent et signé cryptographiquement à l'écriture. Persistance INSERT-only : le stockage sous-jacent interdit les opérations UPDATE et DELETE. Et rendu conscient de la méthodologie : le chiffre de disponibilité par locataire est calculé selon la méthodologie définie dans le SLA, pas le comptage préféré du fournisseur.

Avec des preuves de qualité litige, la conversation avec le locataire change de forme entièrement. Le locataire revendique 47 minutes d'indisponibilité. L'opérateur ouvre le flux d'événements scellé pour cette fenêtre, applique la méthodologie SLA, et produit un chiffre de 4 minutes avec les transitions sous-jacentes en pièce jointe. Le NOC du locataire peut valider le calcul par rapport à sa propre télémétrie, voir où les deux piles ont divergé — généralement dans le temps de reconvergence du réseau cœur, du côté du locataire par rapport au point de démarcation — et retirer la partie contestée.

Les opérateurs utilisant des flux de preuves scellées rapportent régulièrement que le volume de litiges initiés par les locataires chute au cours de la première année, parce que le NOC du locataire apprend que les preuves de l'opérateur tiendront. Les litiges qui restent sont de vraies situations limites qui méritent d'être résolues sur le fond.

L'autre conséquence des preuves scellées est réglementaire. SOC 2, ISO 27001, NIS 2, et les diverses normes sectorielles exigent toutes de plus en plus des enregistrements d'événements de qualité audit avec des horizons de rétention mesurés en années. Une capture d'écran ne peut pas satisfaire ces exigences. Un RMS fournisseur avec des cumuls mensuels non plus. Un flux d'événements scellé hash-chained le peut. Construire le journal d'audit dans la plateforme dès le départ est nettement moins coûteux que de l'ajouter ultérieurement — et les gains de litiges sont un effet secondaire du fonctionnement, pas un projet séparé.