Jeg faldt over en stakkels internetbruger i en facebook gruppe, der havde oplevet at hans VDSL2 linje der ellers kører noget nær perfekt pludselig var flippet helt ud.
Hvad mon der er sket? Og hvordan kan telemetridata bruges til at komme med et kvalificeret gæt?
Er du nysgerrig? Så kom med på en rejse ind i et (meget lille) udsnit af de knap 6 milliarder rækker telemetridata som supporten bruger i hverdagen til at hjælpe kunderne, og som jeg og mit team af nørder i Fullrates netafdeling bruger til at lede efter problemer i access nettet.
Disclaimer: Nørd’o’teket er en uafhængig instans, som jeg driver i min fritid. Denne post og tilhørende video handler dog om et emne fra min dagligdag, hvor jeg arbejder som net udviklingschef i Fullrate.
Før du bliver forskrækket ved tanken om at din internetudbyder indsamler data om dig, vil jeg skynde mig at henlede din opmærksomhed på ordet “telemetri”. Jeg er 100% ligeglad med indholdet af de data du sender og modtager men til gengæld er jeg meget interesseret i om du har problemer med at sende/modtage de pågældende data. Derfor indsamler vi løbende informationer om hvordan din forbindelse virker. Det er f.eks. ting som hastigheden, signal til støjforholdet, fejl på linket og så videre.
Man kan ikke bare kigge på linjen når kunden ringer. Grunden til dette er, at transmissionsfejl meget ofte er af sporadisk natur. En kunde der har oplevet problemer om aftenen vil ringe til udbyderen næste dag, og her vil supporteren potentielt kigge på en fuldstændig fejlfri linje.
Her kan I se et perfekt eksempel på netop dette fænomen. En kunde klagede over tilbagevendende udfald på TV’et og på denne graf kan man se at linjens SNR periodisk dropper markant hver aften, men om dagen er den fejlfri.
Det var iøvrigt kundens eget TV setup som have en defekt strømforsyning der forstyrrede DSL linjen når den var tændt. Et ret sjovt eksempel, hvor selve dét at tænde for TV’et var det som ødelagde TV oplevelsen!
Uden historiske data har supporteren ikke en chance for at gennemskue at der faktisk er tale om fejl på DSL laget og vil derfor risikere at ende med at spilde kundens tid på unødvendige ombytninger af router og TV boks.
Derfor er den traditionelle tilgang i teleindustrien utilstrækkelig. Her skal der først etableres en særlig overvågning af linjen, og efter den har kørt i potentielt flere dage kan man så kigge på de data og vende tilbage til kunden med en konklusion.
Som net udviklingschef er jeg (blandt andet) ansvarlig for de systemer som supporterne benytter når de skal hjælpe en kunde og en af mine kæpheste i den forbindelse er, at den nødvendige information skal være til rådighed fra start, så man har mulighed for at se og korrekt diagnosticere problemet mens kunden er i røret – og gerne før kunden overhovedet ringer!
Metoden og hvordan vi kom frem til de værktøjer vi har udviklet har jeg i øvrigt tidligere beskrevet i denne artikel.
Nå det var jo egentlig Sune (som vores uheldige kunde hedder) jeg ville snakke om. Han oplevede en særdeles velfungerende linje på godt 100 Mbps som efter et par års problemfri drift pludselig blev meget ustabil. I videoen gennemgår og forklarer jeg nogle af de telemetridata vi benytter til at fejlsøge den slags problemer, og hvordan jeg ved at krydse med data fra nabolinjer kan skyde mig ind på det skyldige netværkselement.
Det er en emne som jeg har meget svært ved at udtrykke mig kortfattet om, så jeg må hellere advare: Det er en lang video!
