Disputas de SLA con operadores: por qué la evidencia gana y las capturas de pantalla pierden

Cada TowerCo, cada operador de colo, cada CPO con un SLA que genera créditos ha vivido esta conversación. El inquilino presenta una disputa. El inquilino tiene capturas de pantalla de su propio monitoreo mostrando la interrupción en su lado. El operador tiene paneles mostrando el sitio como disponible. Ambos lados están mirando datos reales. Ambos lados están convencidos de que los datos del otro lado son incorrectos. La disputa se cierra con una división negociada que probablemente no refleja lo que realmente sucedió.

Las divisiones negociadas son un fallo estructural. Significan que la evidencia de ninguno de los lados fue suficientemente sólida para resolver la pregunta, lo que significa que la próxima disputa se verá igual. La salida no es una mejor negociación — es evidencia que es criptográficamente de grado de disputa. Y la brecha entre una captura de pantalla y evidencia de grado de disputa es mayor de lo que la mayoría de los operadores se dan cuenta.

Dos partes con dos pilas de monitoreo diferentes observando la misma infraestructura física producirán dos cronologías diferentes. Esto no es un error. Es el comportamiento esperado de cualquier sistema donde el monitoreo es asíncrono, las rutas de red son diferentes, la metodología de conteo es diferente y las bases de tiempo pueden no estar precisamente sincronizadas.

Una captura de pantalla de un RMS de proveedor es una afirmación sobre el estado. Un flujo de eventos hash-chained es un registro del estado. Las disputas de SLA se resuelven con registros, no con afirmaciones.

El RMS de proveedor de una TowerCo puede contar un sitio como «disponible» siempre que el controlador del sitio sea accesible y el agregador BTS reporte power-good. El NOC del inquilino operador puede contar el mismo sitio como «caído» si su red core no ha recibido tráfico de los sectores de celda durante 90 segundos. Ambas definiciones son defendibles. Están midiendo cosas distintas. Ninguno de los equipos está siendo deshonesto.

Una captura de pantalla de una consola RMS del proveedor es fundamentalmente una afirmación sobre cómo se veía el sistema en un momento en el tiempo. No hay nada en la captura de pantalla en sí que diga: este renderizado fue generado a partir de un conjunto específico de eventos de telemetría subyacentes; esos eventos ocurrieron en estos tiempos específicos; los eventos no han sido alterados desde que fueron registrados; el renderizado aplicó esta metodología específica.

Cuando una disputa escala y un tercero — un equipo legal, un árbitro, un auditor — intenta evaluar la captura de pantalla como evidencia, la captura de pantalla responde aproximadamente cero de las preguntas relevantes. ¿Cuáles eran los datos subyacentes? ¿Estaban completos? ¿Podría alguien haberlos editado entre el evento y el renderizado? ¿Aplicó el panel la misma metodología que define el SLA? La mayoría de los sistemas RMS de proveedores no pueden responder estas preguntas porque no fueron diseñados para ello.

Un flujo de eventos de grado de disputa tiene cuatro propiedades que una captura de pantalla no tiene. Completitud: cada transición de estado en el sistema queda registrada — pérdida de suministro, ejercicio del ATS, BTS power-good, reactivación de RF del sector — en el momento de la transición, no como un resumen agregado. Evidencia de manipulación: cada evento está hash-chained al anterior y firmado criptográficamente en el momento de escritura. Persistencia solo de inserción: el almacenamiento subyacente prohíbe las operaciones UPDATE y DELETE. Y renderizado consciente de la metodología: el número de disponibilidad por inquilino se calcula frente a la metodología definida del SLA, no la contabilización preferida del proveedor.

Con evidencia de grado de disputa, la conversación con el inquilino cambia de forma por completo. El inquilino alega 47 minutos de inactividad. El operador abre el flujo de eventos sellado para esa ventana, aplica la metodología del SLA y produce un número de 4 minutos con las transiciones subyacentes adjuntas. El NOC del inquilino puede validar el cálculo frente a su propia telemetría, puede ver dónde divergieron las dos pilas — típicamente en el tiempo de reconvergencia de la red core, en el lado del demarc del inquilino — y puede retirar la porción en disputa.

Los operadores que usan flujos de evidencia sellados reportan habitualmente que el volumen de disputas iniciadas por el inquilino cae durante el primer año, porque el NOC del inquilino aprende que la evidencia del operador resistirá. Las disputas que permanecen son casos límite reales que vale la pena resolver por sus méritos.

La otra consecuencia de la evidencia sellada es regulatoria. SOC 2, ISO 27001, NIS 2 y los distintos estándares sectoriales exigen cada vez más registros de eventos de grado de auditoría con horizontes de retención medidos en años. Una captura de pantalla no puede satisfacer estos requisitos. Un RMS de proveedor con resúmenes mensuales no puede satisfacer estos requisitos. Un flujo de eventos sellado hash-chained puede. Construir el registro de auditoría en la plataforma desde el principio es dramáticamente más barato que añadirlo después — y las victorias en disputas son un efecto secundario de operar, no un proyecto separado.