Netværksfejl

Stort set hver gang et eller andet stort system går ned i timevis, viser det sig at være 'netværksfejl', men hvad ved vi egentlig om disse 'netværksfejl', og hvordan kan vi blive bedre til at designe systemer, der overlever dem ?

ACM Queue har lige publiceret en rigtig interessant artikel fyldt med real-life 'netværksfejl', som med stort udbytte kan bruges som tjekliste i designet af distribuerede systemer.

Det er den slags empirisk erfaringsudveksling, der gør os allesammen klogere.

phk

Kommentarer (28)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Poulsen

Nogle af historierne overrasker mig en del.

Hvordan kan Microsoft i deres datacenter miste strømmen til en switch "... for no apparent reason." ???? Det skal de da have styr på.

Hvordan kan Cloudflare bare lægge en ny policy ud på alle routere uden at teste det først ?

Og jeg synes der er mange andre eksempler på, at ændringer bliver håndteret meget uprofessionelt.

Jeg laver også selv fejl, men her virker det som om der mangler rettidig omhu.
Nogle af eksemplerne tyder på, at man ikke har forestillet sig at netværket kan være væk.
Specielt grelt synes jeg de mange eksempler på split-brain er.
Det kan ikke undgåes 100%, men man kan altså godt øge redundansen imellem datacentrene. Og eventuelt bruge sort fiber.

Er problemet ikke snarere at driftsfolkene er så pressede, at de skærer hjørner for at nå deres ting ?
Eller at de mangler tid til uddannelse ?

Det er et ledelses problem i min optik.

Men det er selvfølgelig nemmere bare at give netværket skylden igen.
"Det er jo altid netværket det er galt med"

Hilsen fra en netværkstekniker i forreste skyttegrav.

  • 10
  • 0
Claus Jacobsen

Præcis som med elektrikeren dengang i Danske Banks serverrum kom til ved en fejl at "falde over en række ledninger" :-)
Murphys lov siger jo at alt kan ske. Uagtet af hvad der findes af procedurer i de enkelte virksomheder for udrulning, tests og hvad der nu ellers er af ting der har indvirkning på en hvilken som helst drift.

  • 1
  • 0
Benny Tordrup

Eller en historie, jeg hørte med uforklarlige nedbrud i serverrummet på næsten ens tidspunkter. Den blev først løst efter installation af videoovervågning, hvor man fandt ud af, at rengøringsdamen hev ledningen ud af strømstikket lige inden for døren for at bruge det til sin støvsuger :-)

  • 4
  • 1
Mogens Lysemose

Mange fejl opstår i skyndingen. Se godt eksempel, jeg brugte ikke kommentarformen som tiltænkt, fra en tablet med en ikke-testet browser hvor det åbenbart ikke virker , og fik så fumle-klikket, og vupti en kommentar som ikke kan slettes/ændres .

Netop det issue med det forkerte kabel kender jeg en større virksomhed der har oplevet en del gange. Der er masser af dokumentation og kontrol, men når der står adskillige ledere og åndner teknikerne i nakken arbejder for at de skal fikse det asap arbejder de ikke bedre, men dårligere...

  • 2
  • 0
Maciej Szeliga

Hvordan kan Microsoft i deres datacenter miste strømmen til en switch "... for no apparent reason." ???? Det skal de da have styr på.
'Nogen' har hevet det forkerte powerkabel


Jeg mener at have læst en historie fra det virkelige liv om en større maskine som spontant genstartede hver aften på bestemt tidspunkt, uden nogen grund...
...det viste sig, efter lang tids undren og mange undersøgelser af maskinen, at rengøringen tog stikket ud for at sætte støvsugeren til.

  • 0
  • 4
Kristian Nielsen

Jeg oplever desværre ofte at netværksafdelingen ikke aner hvad de har med at gøre. Det er som sådan ikke en kritik af den enkelte netværksmedarbejder, men har ofte oplevet at netværket er blevet så stort og komplekst at ingen i afdelingen efterhånden kan overskue det. Selv med diverse diagrammer, Visio tegninger og anden (til tider ikke opdateret) dokumentation er det umuligt at overskue konsekvensen af en simple firewall ændring eller netværksomlægning. Det er efterhånden sjældent at almindlig netværks vedligehold eller low risk changes ikke har en eller anden form for uventet impact.

Skylden ligger selvfølgelig ikke alene hos netværksafdelingen eller folkene i den. Server og Applikationsafdelingerne laver ofte sære netværksløsninger/ændringer, som ikke opfylder gældende regler eller aftaler og glemmer at informere netværksafdelingen omkring dette. Så hvordan skulle de kunne gøre noget ved det.

En, sjov, observation jeg har gjort mig med mange af de netværksfolk jeg har arbejdet med: Specielt ved mindre fejl (enkelte pakketab, connection drops, flapping lines, fejl lukkede FW porte og tilsvarende) har netværksfolk en tendens til at benægte alt. Først når det er lykkedes, ikke netværks, ressourcerne at skaffe hardcore beviser/the smoking gun, vil netværksteknikeren begynde at undersøge det.
Ved periodiske fejl er svaret ofte: "Er der fejl nu? Nej? Jamen så er der jo ikke en fejl vi kan undersøge".

Jeg ved godt at jeg sikkert at trådt en masse netværksfolk over tærende nu. Jeg er sikker på at der er mange som ikke tænker, ikke er eller arbejder sådan. Jeg taler kun ud fra mine erfaringer.

  • 2
  • 2
Erik Klausen

Jeg prøvede at læse artiklen, men fik følgende besked:
"Application server is busy. Either there are too many concurrent requests or the server still is starting up."
Så det er ikke kun netværket der giver problemer! :-)

  • 2
  • 0
Casper Niebe

Man klipper strømmen til udstyret, så UPS'en slår til ... hvis altså den fungerer. Et alarmerende hyppigt problem med netop UPS'er, er den manglende overvågning af dem. Hvis ikke en tekniker adviseres, når en UPS slår til, opdager man ikke strømafbrydelsen før UPS'en løber tør. Det gør, at mindre strømudfald passerer ubemærket hen, men ved længerevarende nedbrud, udskyder UPS'en blot katastrofen. Mange har en tendens til at tro, at en UPS giver ekstra sikkerhed og stabilitet. Det gør den ikke - den giver bare lidt længere tid at reagere i, i tilfælde af strømsvigt/udfald, og kun hvis de overvåges og giver alarmer til teknikere, der kan gøre noget for at løse det egentlige problem.

  • 1
  • 0
Jn Madsen

Som Casper siger ..

Jeg kan nævne en situation fra den virkelige verden hos en større ISP'er.

Strøm ryger, større batteri backup tager over, helt efter bogen.
Batterier dør ud,- diesel motorer tager over, helt efter bogen.
Diesel motorer dør,- absolut ikke efter bogen.

Der var fejl på overvågningen af diesel tankene, man fik ikke af vide de var ved at løbe tør.

De der små irriterende ting når virkeligheden rammer.

  • 2
  • 0
Jesper Louis Andersen

Strøm ryger, større batteri backup tager over, helt efter bogen.
Batterier dør ud,- diesel motorer tager over, helt efter bogen.
Diesel motorer dør,- absolut ikke efter bogen.

Den har jeg også været med til:

Strøm ryger, batterier tager over. Helt efter bogen.
Strøm kommer tilbage, batterier bliver ikke koblet fra igen.
Systemet dør 4 timer senere for der er ikke strøm på batterierne mere.

Eller den her:

Strøm ryger, batterier tager over
Batterier løber efterhånden tør, diselmotoren startes
Man har glemt at fylde disel på diselmotoren...

  • 1
  • 0
Frank Pedersen

Hej Kristian, jeg mener du tager fejl sådan helt generelt, i hvert fald hvis du mener netværks drift. De fejl/mangler du beskriver ved netværksfolk/afdelinger, kan du finde i ethvert firmas afdeling hvis du kikker efter. Jeg nægter at tro på at der skulle være særligt mange netværksfolk der ikke ved hvad de har med at gøre. Faktisk tvært imod hvis du spør mig. De fleste netwærks folk jeg kender er yderst professionnelle og strukturede, og har tilmed gennem tiden oparbejdet en evne til at arbejde i ustrukturede miljøer.

Det er stress der gør at der nogle gange bliver lavet en hurtig høkerløsning for at spare tid og lige præcis de ting bliver ofte ikke dokumenteret. Det er der det onde netværks helvede af manglende dokumentation starter, ikke pga. manglende kvalifikationer.

Jeg ser ofte mere ustrukturerede folk i andre afdelinger end netop netwærks afdelingen.

/Frank

  • 0
  • 0
Michael Weber

Strøm ryger, batterier tager over

Og puuf!! siger UPSen mens en liflig duft af brændt elektronik spreder "hygge" i lokalet. Det ene af to ens controller-print i UPSen brændte af og der var netop to af hensyn til redundans. Men det ene print var brændt af, på en sådan måde, at det andet ikke tog over som det burde. Så ingen strøm på indersiden og på den anden side, fuldt opladede batterier og en fuld optanket dieselgenerator.

Trist.

  • 2
  • 0
Jan Poulsen

Og puuf!! siger UPSen mens en liflig duft af brændt elektronik spreder "hygge" i lokalet. Det ene af to ens controller-print i UPSen brændte af og der var netop to af hensyn til redundans. Men det ene print var brændt af, på en sådan måde, at det andet ikke tog over som det burde. Så ingen strøm på indersiden og på den anden side, fuldt opladede batterier og en fuld optanket dieselgenerator.

Trist.

Imod sort uheld hjælper ingenting.

Men efter at have arbejdet en kortere periode på en produktionsplatform så forstår jeg ikke, at man ikke har mere systematik omkring at lave periodiske katastrofe øvelser.

Det er vel bedre selv at vælge hvornår man vil have katastrofen end at lade systemerne fejle på et vilkårligt tidspunkt ?

  • 3
  • 0
Jn Madsen

De fleste er helt klar over hvad der burde gøres.

Man kan fange rigtigt meget ved at have testprocedurer og øvelser.
Men det hele dør for økonomens kuglepen. - Det koster penge.

Hvor mange fejlsituationer ville vi fange ved at afholde disse øvelser?
Hvad koster det? !!!!!
Hvor ofte ville vi blive ramt af uforudsete fejl?
Hvad koster det? !!!!!

Og så tager chefen en beslutning,- i disse tider ser det ud til at man krydser fingre og sparer de penge :)

  • 1
  • 0
Jan Poulsen

Hvor mange fejlsituationer ville vi fange ved at afholde disse øvelser?
Hvad koster det? !!!!!
Hvor ofte ville vi blive ramt af uforudsete fejl?
Hvad koster det? !!!!!

Hvad koster det når NemID er nede onsdag formiddag ?
Tror du ikke det ville have været billigere at teste klokken 03:00 istedet ?

Det er det jeg kalder "Strudse drift"
Hvis vi lukker øjnene hårdt nok i, så er der ingen problemer.

Men ROI afhænger nok af hvem man er.

  • 1
  • 0
Log ind eller Opret konto for at kommentere