Disputas de SLA com carriers: por que a evidência vence e os prints de tela perdem

Todo TowerCo, todo operador de colo, todo CPO com um SLA que gera crédito já viveu esta conversa. O locatário registra uma disputa. O locatário tem prints de tela do próprio monitoramento mostrando a interrupção do lado dele. O operador tem painéis mostrando o site como disponível. Ambos os lados estão olhando para dados reais. Ambos os lados estão convencidos de que os dados do outro lado estão errados. A disputa fecha com uma divisão negociada que provavelmente não reflete o que realmente aconteceu.

Divisões negociadas são uma falha estrutural. Significa que a evidência de nenhum dos lados foi sólida o suficiente para resolver a questão, o que significa que a próxima disputa terá a mesma aparência. A saída não é uma negociação melhor — são evidências que são criptograficamente de nível de disputa. E a lacuna entre um print de tela e evidência de nível de disputa é maior do que a maioria dos operadores percebe.

Duas partes com duas pilhas de monitoramento diferentes observando a mesma infraestrutura física vão produzir duas linhas do tempo diferentes. Isso não é um bug. É o comportamento esperado de qualquer sistema onde o monitoramento é assíncrono, os caminhos de rede são diferentes, a metodologia de contagem é diferente e as bases de tempo podem não estar precisamente sincronizadas.

Um print de tela de um RMS de fornecedor é uma afirmação sobre o estado. Um fluxo de eventos hash-chained é um registro do estado. Disputas de SLA se resolvem em registros, não em afirmações.

O RMS do fornecedor de uma TowerCo pode contar um site como «disponível» enquanto o controlador do site está acessível e o agregador BTS reporta power-good. O NOC do locatário carrier pode contar o mesmo site como «fora» se a rede core deles não recebeu tráfego dos setores de célula por 90 segundos. Ambas as definições são defensáveis. Estão medindo coisas diferentes. Nenhuma equipe está sendo desonesta.

Um print de tela de um console RMS de fornecedor é fundamentalmente uma afirmação sobre como o sistema parecia em um momento no tempo. Não há nada no print de tela em si que diga: este renderizado foi gerado a partir de um conjunto específico de eventos de telemetria subjacentes; esses eventos ocorreram nestes momentos específicos; os eventos não foram alterados desde que foram registrados; o renderizado aplicou esta metodologia específica.

Quando uma disputa escala e uma terceira parte — uma equipe jurídica, um árbitro, um auditor — tenta avaliar o print de tela como evidência, o print de tela responde a aproximadamente zero das perguntas relevantes. Quais eram os dados subjacentes? Estavam completos? Alguém poderia tê-los editado entre o evento e o renderizado? O painel aplicou a mesma metodologia que o SLA define? A maioria dos sistemas RMS de fornecedores não pode responder a essas perguntas porque não foram projetados para isso.

Um fluxo de eventos de nível de disputa tem quatro propriedades que um print de tela não tem. Completude: cada transição de estado no sistema é registrada — perda de utilitária, acionamento de ATS, BTS power-good, reativação de RF de setor — no momento da transição, não como um rollup de resumo. Evidência de adulteração: cada evento está hash-chained ao anterior e assinado criptograficamente no momento da escrita. Persistência somente INSERT: o armazenamento subjacente proíbe operações UPDATE e DELETE. E renderização ciente da metodologia: o número de uptime por locatário é calculado em relação à metodologia definida do SLA, não à contagem preferida do fornecedor.

Com evidência de nível de disputa, a conversa com o locatário muda de forma completamente. O locatário alega 47 minutos de downtime. O operador abre o fluxo de eventos selado para aquela janela, aplica a metodologia do SLA e produz um número de 4 minutos com as transições subjacentes anexadas. O NOC do locatário pode validar o cálculo em relação à própria telemetria deles, pode ver onde as duas pilhas divergiram — tipicamente no tempo de reconvergência da rede core, do lado do demarc do locatário — e pode retirar a porção disputada.

Operadores que usam fluxos de evidência selados reportam rotineiramente que o volume de disputas iniciadas por locatários cai no decorrer do primeiro ano, porque o NOC do locatário aprende que a evidência do operador vai se sustentar. As disputas que permanecem são casos limítrofes reais que valem a pena resolver pelos méritos.

A outra consequência da evidência selada é regulatória. SOC 2, ISO 27001, NIS 2 e os vários padrões setoriais exigem cada vez mais registros de eventos de nível de auditoria com horizontes de retenção medidos em anos. Um print de tela não pode satisfazer esses requisitos. Um RMS de fornecedor com rollups mensais não pode satisfazer esses requisitos. Um fluxo de eventos selado hash-chained pode. Construir o log de auditoria na plataforma desde o início é dramaticamente mais barato do que adicioná-lo depois — e as vitórias em disputas são um efeito colateral de operar, não um projeto separado.