Om øl og bryggerier og øl-historie og sånt ...

2012-01-12

Snakke forbi hverandre

Her er en klassiker innen det å snakke forbi hverandre i en driftssammenheng.

Bruker: kontor-PC'en min fungerer ikke.
Sysadmin: (Feilsøker) ahh, det er xxx, den må bootes.
Bruker: Åja. (Drar tilbake til kontoret.)
Ved første øyekast ser jo dette helt greit ut. Men det er ingen som sjekket at begge hadde samme oppfatning av hvem som skulle boote den aktuelle maskinen. Det er fullt mulig at brukeren sitter på kontoret og venter på at en eller annen som skal komme og fikse problemet, mens sysadmin lener seg godt tilbake i stolen i trygg forvisning om at brukeren selv fikser det og saken dermed er løst.

Om vi i dette tenkte tilfellet spoler et par timer fremover, er det mulig at systemadministrator har en sint og frustrert bruker på døra. Da vil kanskje brukeren insistere på at «Du sa du skulle komme og fikse det, men du kom ikke.» I beste fall har man spilt tid, i verste fall er det der og da saken virkelig tar av.

Forsøk å legge merke til hvor ofte man blir enige om at noe skal gjøres, bare ikke hvem som skal gjøre det. Spesielt møter er ille på det, og gjerne mot slutten når alle er litt slitne og det er dårlig tid. Der kommer gjerne problemene når og hvis møtereferatet sier at en eller annen skal gjøre noe, og vedkommende er uenig i at den fremstillingen. Folk som er drevne i å skrive møtereferater vet at man må eksplisitt ta med med hvem, hva og innen når.

 

2012-01-11

ECC-minnet som feilet

For en stund tilbake fikk en av mine kolleger helt ufrivillig en leksjon i hva kombinasjonen av dårlig kundebehandling og manglende systemforståelse kan lede til. Han hadde en tjeneste som var såpass viktig at de hadde bestilt tjenermaskinvare som den kjørte på - deriblant ECC-minne.

ECC betyr Error Correcting Code, og litt forenklet kan vi forestille oss det som minne med dobbelt paritet: en paritetsbit for hver byte, og en paritetsbit for alle n'te bits i en blokk med minne - dvs en paritetsbit for alle LSB i hver byte osv. Da har man en matriselignende layout av bits, med paritet både kolonne- og radvist. Hver minnebit er med i to paritetsbits, og hvert par av paritetsbit deler maksimalt en enkelt bit. Det er da mulig ikke bare å detektere at det er bitfeil - som man kan med vanlig paritetsminne. Man kan i tillegg også bestemme posisjonen som har feil verdi, og dermed kan man korrigere den. Som en bonus er man også sikret deteksjon av alle dobbeltfeil.

Bitfeil i minnet er en del av livets realiteter. Det kan skyldes en så uunngålig ting som at kosmisk stråling har fått inn en fulltreffer på den delen av en minnebrikke der en bit lagres. Normalt er raten lav, og den druker i de fleste systemens iboende ustabilitet. Selvfølgelig kan også bitfeil skyldes at det er feil på minnebrikken, og det er ikke ignorerbart.

Om du ønsker å ha maksimal oppetid og stabilitet, er ECC-minne en god ide. Dessuten kan man formodentlig anta at hovedkort og systemer med ECC-minne også har høyere kvalitet forøvrig. Det er i hvert fall lov å håpe.

Min kollega kjøpte altså ECC-minne til tjeneren med den kritiske tjenesten. Etter en tids bruk ble det konstatert repeterende minnefeil på et bestemt punkt. Han samlet all informasjon som han visste support ville trenge og ringte dem. En av livets merksnodigheter er at jo større en organisasjon blir, jo mer frustrerende er det generelt å forsøke å kommunisere med deres supportavdeling, og dette var en av de aller største og formodentlig mest seriøse. Men min kollega fikk bakoversveis da han fikk beskjed at den modellen skiftet de ikke minne på, fordi den hadde ECC-minne, som korrigerer feilene, og dermed er ikke minne-feil noe problem.

Dette er et så blantant overtramp på tanken bak og forståelse av redundans at det er verd å analysere det. ECC-minne har innebygget redundans, nærmere bestemt en slags N+1-redundans selv om konseptet ikke helt passer. I det øyeblikket et redundant system får en feil, reduseres redundansen. Det er ikke en sikring mot feil, det er en galgenfrist du har kjøpt deg og som løper fra feilen har oppstått. Det gir deg litt mer tid til å fikse den uten at tjenesten rammes. Litt forenklet: systemet kan rammes av feil, men redundansen sikrer at tjenesten ikke rammes. Dersom du er så dumdristig å kjøre videre, kjører du uten eller med redusert redundans. Treffes du av enda en feil risikerer du at også tjenesten feiler.

Så lenge feilene oppstår med lav rate, sporadisk og på tilfeldig steder uten noe mønster, er det ikke grunn til å bytte minnet - det var denne feilkorrigeringen du kjøpte ECC-minne for. Dersom feilene kommer på samme sted og kanskje med økende hyppighet, så vet du at det er minnet i seg selv som er problemet, og det må byttes.

Det er som med reservedekket til bilen. Når du har punktert, er det reservedekket som lar deg kunne kjøre videre. Men samtidig kjører du nå videre uten redundans, og bør reparere dekket (reetablere redundansen) snarest råd.

 

2012-01-10

De tre hovedproblemene

Har du vært ute for en IT-driftsavdeling med tekniske problemer? Joda, visst kan systemadministratorer stri med tekniske problemer, men det som virkelig skaper utfordringene er - satt på spissen - noe annet:

  1. Skalering. Det kan være lett nok å lage en løsning sålenge den ikke trenger å skaleres opp. Men når en løsning, en installasjon eller et design går fra å være nærmest et proof-of-concept til å være en reell løsning med et bruksvolum som totalt overskygger trivielle testeksempler, først da er det man får se om den skalerer. Husk at selv mange NP-komplette problemer lar seg enkelt løse om de bare er tilstrekkelig små nok. Gjør man ting rett, tester man for skalerbarhet. Gjør man det feil, antar man at skalerbarhet er brikken av puslespillet som faller på plass av seg selv helt på slutten.

  2. Endringshåndering. Rett nok kan det synes som om ting slutter å virke helt av seg selv, og tidvis - som en harddiskkrasj - er vel også det den beste forklaringsmodellen. Men oftest er noe endret, gjerne med vilje, men uten at man har hatt tilstrekkelig oversikt over problemer og bieffekter. Kontroll på og styring med endringsprosessene er essensielt dersom endringer skal være en målrettet forflytning i positiv retning, og ikke bare en krysning mellom risikosport og lotto.

  3. Personkommunikasjon. Folk snakker sammen, men de snakker også forbi hverandre, misoppfatter hverandre, forvirrer og avsporer hverandre, glemmer hva de avtalte, tolker begreper forskjellig osv. Kommunikasjon er ikke bare tale eller E-post, det er også dokumentasjon - som er kommunikasjon fra ett tidspunkt til en litt uspesifiert mottaker på et senere tidspunkt. Hver gang problemer koker ned til at noen «ikke visste», så har man trolig et kommunikasjonsproblem.

Min høyst udokumenterbare antakelse er at disse tre ikke-tekniske aspektene er forårsakende eller i det minste deltakende eller forsterkende årsaker i nesten alt av hva som tolkes som tekniske problemer.

Driftsstaber, eller i det minste personene som utgjør dem, er ofte flinkere til å takle de rent tekniske problemene enn disse tre aspektene. Utfordringen ligger i å lære dem til å takle også disse sidene. ...samt å lære av det når man først har gjort en feil.

 

2012-01-09

Siste vår for TDT4285

Faget som jeg har undervist siden omkring 2000 - TDT4285 Planlegging og drift av IT-systemer - blir tatt ut av fagplanen etter at det er undervist dette vårsemesteret. Det er en generell revidering av fagplanen for å konsolidere fagutvalget og tematisk spredning på instituttet som økser bort blant annet driftsfaget. Jaja, alt har tross alt en ende.

Dersom det er noen som ønsker å få med seg dette faget, må de kaste seg rundt realtivt fort. Siden det er et datateknikkfag, så er det visse formelle krav: såvidt jeg husker er det generell studiekompetanse og fordypning i matematikk. Men merk at jeg ikke jobber på studieadministrasjonen, så det er mulig at jeg tar feil her. Jeg har tatt feil i dette før! Sjekk med studieadministrasjonen eller kontakt meg direkte om du er usikker.

Kravet om matematikk er mest et formelt krav for fag som er en del av det gamle siv.ing-løpet. Selve driftsfaget har ikke i seg selv noe matematikk som konkret krever at man har fordypning i matematikk.

Første forelesning er tirsdag 10. januar kl 08:15-10:00 i aud H1 i Hovedbygget på Gløshaugen (vi snakker NTNU i Trondheim). Andre forelesning er torsdag 12. januar kl 11:15-12:00 i aud F6 i Gamle fysikk. Øvingene er mandager kl 15:15-17:00, men det er bare ganske få uker der det er obligatorisk oppmøte på dette tidspunktet. Deretter repeteres det ukentlig. Det er fullt mulig å kaste seg på selv etter første forelesning, men det blir verre for hver uke, og klokka tikker i retning noen oppmeldingsfrister som er veldig absolutte.

Det har vært snakket om å bygge faget om til et EEU-kurs (eksamensrettet etterutdanning), men vi får se om det blir noe av det.

Inntil videre tenkte jeg kanskje å blogge litt om IT-drift parallelt med undervisningen i den grad tiden tillater. Forhåpningen er synergetisk å hente materiale fra det jeg foreleser, men uten at jeg har tenkt å begrense meg til tematisk til det.