Dagbog-bloggen

Praktikantopgaven: Et Danmarkskort

En af fordelene ved at få en kreativ datamatiker-praktikant ind i virksomheden er, at man kan få realiseret nogle af de gode ideer, man har liggende i skuffen til en regnvejrsdag, men ikke har haft tid til at gøre noget ved.

For vores vedkommende var en af disse ideer et Danmarkskort, der viser vores kunders fysiske placering, samt eventuelle problemer i vores net, som vi skal reagere på.

Det tog vores praktikant ca. 3 dage, fra ideen blev ham forelagt, til vi havde den første prototype, og derefter blev de næste par uger brugt på at finpudse brugerfladen, så vi kunne tage kortet i brug i vores kundeservice.

En genvej til proaktiv fejlfinding

I vores verden defineres proaktiv fejlfinding ved, at vi påbegynder fejlfinding på kundens forbindelse, før kunden selv opdager fejlen og tager kontakt til os.

Det er en stor fordel, da det giver en bedre oplevelse for kunden, og desuden sparer det tid i vores kundeservice.

Vores muligheder for proaktiv fejlfinding afhænger dog af, hvor meget kontrol vi har over kundens forbindelse.

På vores eget fibernet har vi fuld kontrol over alle elementer, da vi har mulighed for at overvåge samtlige switches i access-nettet, og hvis der er en fiber, der graves over, eller en switch, der går ned, får vi en alarm fra vores overvågningssystem.

På TDC's kobber- og coax-net lejer vi den sidste strækning ud til kunden af TDC, og det betyder, at vores muligheder for proaktiv fejlfinding bliver begrænset.

Når vi mister forbindelsen til en slutbruger, er det langt fra sikkert, at vi opdager det med det samme. Hvis der er tale om en DSL-kunde, der får overgravet sit telefonkabel, vil det for os se ud præcis som hvis han blot havde slukket for sit udstyr.

Det samme gælder, hvis der sker en fejl i en DSLAM eller switch hos TDC - for os er det eneste umiddelbare symptom, at der ikke kommer noget trafik fra den pågældende kunde.

Det er dog vigtigt for os at identificere de såkaldte multifejl, som berører flere kunder samtidig, dels fordi alvoren stiger med antallet af berørte kunder, dels fordi det har betydning for, hvordan vi skal gribe problemet an.

En måde at detektere multifejl på er at kigge på de pingtests, vi udfører på samtlige kunder hvert 5. minut.

De fleste af dem svarer på ping, og vi kan derfor konkludere, at de er gået offline, hvis de holder op med at svare.

Opgaven er nu at finde ud af, om der er nogen sammenhæng mellem de kunder, der er gået offline, og at der derfor er tale om en multifejl.

Hvordan gør man det?

Mange fejl i nettet har den store fordel, at de som regel manifesterer sig i et specifikt geografisk område. Derfor kan man plotte lokationen af de fejlramte kunder på et kort - det vil ret hurtigt give et billede af, om der er et generelt problem, der skal tages hånd om.

Samtidig gemmer vi historikken i et par timer, hvilket giver os mulighed for at spole tilbage i tiden og se, om der har været et issue, som siden er blevet løst.

Sådan blev opgaven løst

Vores praktikant fik et internt REST-API stillet til rådighed, hvorfra han kunne hente vores ping-historik for et givent tidsrum.

Samtidig blev han introduceret for DAWA, som jeg tidligere har talt varmt om, og herfra kunne han hente en komplet adresseliste med GPS-koordinater.

Ved at samkøre DAWAs adresseliste med vores ping-historik kunne han danne en liste med online og offline kunder og deres respektive lokationer.

Han byggede et kortværktøj baseret på Mapbox og Leaflet, som er et populært JavaScript-library til bygning af interaktive kortapplikationer. Valget faldt på et kort i gråtoner, så de grønne og røde markers for hhv. online og offline kunder træder tydeligt frem.

Vi vil dog gerne publicere resultatet på vores website, så vores kunder løbende kan se den aktuelle status på vores netværk, og det gav os en udfordring, som skulle løses.

Det går jo ikke, at vi offentliggør vores kunders adresser, og det ville i sidste ende være konsekvensen, hvis vi lod selve kortværktøjet være offentligt tilgængeligt, da et GPS-koordinat ofte er at sidestille med en fysisk adresse.

For at undgå at lække kundernes adresser til omverdenen byggede vores praktikant et script, som kunne tage et screenshot af kortet ved hjælp af wkhtmltoimage og gemme dette som et JPG-billede, som vi kan publicere i stedet.

På grund af billedets opløsning kan man ikke gå baglæns og udlæse en specifik kundes GPS-koordinat, og dermed er privacy-problemet umiddelbart løst.

Vi betragter derfor praktikantopgaven som løst - kortet fungerer, og det forbedrer vores kundeservice og vores overblik.

En oplagt udvidelse til kortet er at tilføje en funktion, så man kan visualisere den enkelte kundes pingtid ved hjælp af en farvegradient - dermed får vi tilføjet en ekstra nuance til vores kvalitetskontrol.

Det er dog sat på to-do-listen til den næste regnvejrsdag, da vores praktikant er i gang med den næste opgave, der handler om analyse af vores fakturadata.

Relateret indhold

Kommentarer (7)
Paul Wittig

Spændende!! Jeg er selv igang med 5. semesters praktik perioden på Datamatikeren hos LEGO. Måske kan der implementeres en form for machine learning, så der automatisk kan detekteres når områder har problemer. Det burde være visuelt tydeligt nu, så hvorfor ikke også noget selvtænkende logik, til at være følsom overfor nærliggende problemer, som automatisk sætter nogle alarmer igang. Machine learning er måske det forkerte værktøj, men ihvertfald en algoritme som kan "fornemme" problemer i områder :-) Ellers rigtig godt gået.

Yoel Caspersen Blogger

Det burde være visuelt tydeligt nu, så hvorfor ikke også noget selvtænkende logik, til at være følsom overfor nærliggende problemer, som automatisk sætter nogle alarmer igang. Machine learning er måske det forkerte værktøj, men ihvertfald en algoritme som kan "fornemme" problemer i områder :-)

Det er et glimrende forslag, som vi faktisk allerede har implementeret i vores system i dag.

Jeg tror du har ret i, at decideret machine learning nok er at skyde over målet, for de fleste fejl følger nogle bestemte mønstre, som er nogenlunde nemme at forudsige, og der er derfor ikke behov for kunstig intelligens, men blot en algoritme, der tager højde for de kendte fejltyper.

Hvis vi kigger på det underliggende fysiske net, er den enkelte telefoncentral hos TDC koblet på en fiberring, som skal sikre en vis form for redundans. Der vil typisk være mange telefoncentraler, der er koblet på samme fiberring.

Der er lidt over 150 fiberringe i TDC's net, og de ligger hver især inden for et relativt afgrænset geografisk område.

Typisk vil en udbyder på TDC's net aftage trafik gennem en enkelt port pr. fiberring - en såkaldt POI-port. Sker der en multifejl i TDC's net, vil det oftest gå ud over flere kunder på samme fiberring - typisk alle sammen, hvis fejlen ligger tæt på POI-porten, eller en delmængde, hvis fejlen fx ligger på en lokal telefoncentral.

I blogindlægget inkluderede jeg et screenshot fra en fejlsituation - og her ser vi et eksempel på, at kunder på flere fiberringe i TDC's net i hovedstadsområdet var ramt. I den konkrete situation var det et planlagt og varslet servicevindue, da vi skulle flytte rundt på nogle VLANs, men et spontant opstået nedbrud havde haft samme karakteristika, dog oftest i mindre skala.

Vi har i vores nuværende pingcheck inkluderet en funktion, som giver os et varsel, hvis flere end 5 kunder på samme fiberring går offline samtidig.

Præcis hvor grænsen skal gå, afhænger selvfølgelig af antallet af kunder, man har på den enkelte fiberring, og hvor finmasket nettet skal være - jo flere kunder, man har, jo flere vil der være, som af sig selv slukker for udstyret, men hvis man skruer for højt op for denne threshold, vil mindre fejl i nettet ikke dukke op på radaren.

Povl H. Pedersen

Hvis i bare tager screenshots, så har i ikke koordinater, men hvis man ved at centrum af cirklen er placeret meget præcist, så vil man ofte fra billedet kunne lokalisere ihvertfald nogle kunder.

Tilfældighed vil ikke hjælpe, da man så kan lave gennemsnit over flere kort, og få info til at ramme præcist.

I har lavet screenshots, jeg går ud fra at det betyder at man ikke kan flytte kort, og i har sørget for minimalt overlap - Eller alle screenshots er udsnit af det samme billede, så man ikke kan lægge 2 kort ovenpå hinanden og få flere data.

Man er nok nødt til at trunkere/afrunde alle koordinater inden de plottes. Hvis flere falder sammen, så kunne man lave større cirkler, eller markere på anden vis. Kun derved har du anonymiseret data. Og du har ikke behov for den høje præcision i dine plot.

Mange der tager billeder af stjerner smider måske 100 billeder ovenpå hinanden i stacking, det er lidt det modsatte, men ved at stacke mange utydelige signaler får de et tydeligt signal. Så det skal man huske.

Yoel Caspersen Blogger

Hvis i bare tager screenshots, så har i ikke koordinater, men hvis man ved at centrum af cirklen er placeret meget præcist, så vil man ofte fra billedet kunne lokalisere ihvertfald nogle kunder.

Det er en interessant pointe, og også noget af det, vi har diskuteret i forbindelse med uarbejdelsen af kortet. Men nu er cirklen netop ikke placeret præcist, da der sker afrunding flere steder i kæden, og vores målsætning har været, at det ikke må blive mere præcist end plus/minus 350 meter.

Det gode spørgsmål er, hvor tæt vi må komme på en adresse, før det er for tæt.

I København, hvor husene ligger tæt, og der endda ofte er flere etager, vil man ikke kunne identificere en præcis adresse, om så koordinatet passer på kloakdækslet i gaden udenfor.

Til gengæld kan man muligvis udpege en landmand i den mest vindblæste del af Vestjylland, selv om man rammer en halv kilometer ved siden af.

Alternativet til et kort med punkter, er en inddeling af kortet i zoner, fx efter sogne eller kommuner. Det er dog for upræcist til at vise, hvor der er problemer, og hvor der ikke er.

Vi har også kigget på, om et heatmap var måden at gøre det på. Det var ingen succes, og i mangel af bedre alternativ vendte vi derfor tilbage til (upræcise) prikker.

Tilfældighed vil ikke hjælpe, da man så kan lave gennemsnit over flere kort, og få info til at ramme præcist.

Er det et problem i praksis? Hvis kortet opdateres hvert 5. minut, vil du reelt kun have 12 samples pr. time, og du kan ikke vide med sikkerhed, om den nye prik, du ser på en given pixel, er en ny kunde, der er kommet online, eller en anden kunde, som blot har fået en ny lokation på kortet. Det giver lynhurtigt en meget stor mængde kombinationsmuligheder.

Morten Faurholt

Jeg er enig i privacy-bekymringen. Ja, lidt tilfældig støj adderet gør det sværere, men ikke umuligt. Problemet er at informationen stadigvæk er tilstede selvom man adderer tilfældig støj. Det er bedre, som Povl foreslår, helt at fjerne informationen via afrunding (d.v.s. i praksis at dele kortet ind i kvadranter af en eller anden størrelse), for så er informationen væk. Man skal så sætte en tærskel for graden af afrunding.

Men det bringer mig til en anden ting nemlig hvad behovet er. Den enkelte kunde kan have behov for at se status på sin egen forbindelse. Derudover har kunden ikke et behov for at se status på enkeltforbindelser, men mere bare overordnet status for området. Så her kunne man kollapse alle tilsluttet samme central (eller anden relevant delt infrastruktur) ind i én prik der så evt. via farve eller tal viser status. Hvis det ikke er muligt at bestemme denne inddeling, kan man også bare lave inddelingen ud fra de ovennævnte celler (som opstår ved afrunding) og så indenfor hver celle skrive det overordnede resultat for det område. En sådan celle kunne være fx 2x2 km. Man kunne vel også variere cellestørrelsen ud fra antallet af abonnenter.

Yoel Caspersen Blogger

Så her kunne man kollapse alle tilsluttet samme central (eller anden relevant delt infrastruktur) ind i én prik der så evt. via farve eller tal viser status.

Hvis vi starter ved det første spørgsmål: Hvad er behovet? Well, ud over en generel filosofi om at have en høj grad af transparens over for kunderne, er det også en helt lavpraktisk ide om, at vi måske kan give en bedre kundeservice og mindske antallet af henvendelser til vores kundeservice, hvis man som kunde visuelt kan se, at der er et generelt problem i ens område.

Ideen om at plotte relevant infrastruktur på kortet har vi også overvejet, men den giver to problemer. Dels kan det være uklart for en kunde i fx København, om han er tilkoblet centralen på Vesterbro eller i Valby, dels er der et ønske fra TDC om, at vi og andre aktører i telebranchen ikke udstiller de fysiske adresser på deres infrastruktur offentligt.

Sidstnævnte kunne vi i teorien blæse på, da de relevante data fra TDC allerede ligger offentligt tilgængeligt adskillige steder, men vi må vælge vores kampe med omhu - der er nok at tage af.

Det er muligt, at transparensen i denne case er mere til besvær end til gavn, og at en simpel liste over aktuelle problemer i nettet er bedre, når det kommer til stykket.

Ivo Santos

Ideen er sådan set nok for når jeg er ude at rejse er det jo fint at jeg kan tjekke om internet forbindelsen stadigvæk virker i forhold jeg for eksempel er afhængig af en mail server eller noget andet it-tjeneste jeg måtte have på min forbindelse, alle er trods alt forskellige.

I disse svindel tider kan det omvendt være en fordel for tyve, og hvad ved jeg af kriminelle typer, at man kan se hvor internettet eventuelt ikke virker da dette kan betyde det er lidt nemmere at begå indbrud fordi eventuelle web kamera dermed er slået fra, og måske er der en alarm som heller ikke virker. Det er lidt svært at sige hvad man skal mene i disse tider.

Som foreslået i et andet indlæg sætte en markering i forhold til måske et mindre område, og så kunne kan bruge en grøn farve hvis alt er i orden, en orange farve hvis kun visse kunder er berørte og en rød hvis det er hele centralen som er nede.

Det var egentlig en tanke jeg fik efter jeg kom til at tænke på defrag programmet som følger med DOS 6.22 som vist også er lavet af Norton. Der vises de forskellige felter alt efter hvor mange clustere der er i brug inden for et lille område.

Log ind eller Opret konto for at kommentere