Anders myser på livets særere sider

Side 1/2: 1 2 »

2014-01-03

Frk Vable på telefonen

Jeg har snakket med frøken Vable - sekretæren til Onkel Skrue. Neida, jeg fabler ikke, jeg ble oppringt en gang for lenge siden og spurt om jeg var flink til å bygge korthus. Jeg tør sverge på at hun presenterte seg som Frk. Vable.

Bakgrunnen var at i undervisningen i IT-driftsfaget brukte jeg korthusbygging for å illustrere forskjellen mellom «stabil» og «robust». Jeg pleier å si at «stabil» refererer til evnen til å fortsette å forbli i den tilstanden noe er i, dvs at den ikke på egenhånd endrer tilstand. På den andre siden er «robust» evnen til å takle endringer i miljøet uten å tryne, eller evnen til å fortsette å være stabil selv om det kommer ytre påkjenninger.

Språklig er kanskje forskjellen litt tilfeldig, men det illustrerer viktige konsepter som trengs å holdes fra hverandre.

Et velbygd korthus er stabilt når det fortsetter å stå av seg selv, mens det er robust om det i tillegg tåler en viss mengde rugging i bordet. Det samme gjelder for en datamaskin, om den er stabil vil den ikke uprovosert ramle ned helt av seg selv, men man har ingen iboende garanti for at den ikke tryner dersom det kommer endringer i miljøet den lever i. Dersom den i tillegg er robust, vil den også i økende grad kunne takle en rimelig god mengde endringer i omgivelsene uten å tryne.

I en driftssituasjon er stabilitet et mer grunnleggende behov enn robusthet. Det som ikke er stabilt vil heller ikke kunne være robust. Men en løsning som «bare» er stabil gir nok en viss kortsiktig forutsigbarhet, men den gir også lett endringsvegring. Det skaper miljøer der parolen er: ikke rugg i båten, for da ramler sannsynligvis noe viktig sammen. Enhver endring er en rugging i båten, så om dine sysadminer bare har et stabilt, men ikke et robust system, så har du samtidig en bremsekloss for endringstakt. Alternativt kan du ha sysadminer helt uten endringvedring på et ikke-robust system, og da har du trolig et jojo-system med en reaktiv fikse-etterpå-mentalitet.

Derfor er det viktigste å sikre stabilitet, som også er enklere å oppnå siden det er en ferd oppover prosentskalaen mot 100%, sålenge man ikke har noe ytre krav om funksjonelle endringer. Det er mer utfordrende med robusthet, som har et åpent øvre mål siden ethvert system kan bli enda litt mer robust mot store og usannsynlige endringer.

Men tilbake til Frk. Vable. Forlaget som utgir Donald Duck & Co var på jakt etter noen som kunne profileres som ekspert på korthus, trolig i forbindelse med noen aktivitetssider i bladet. Jeg formoder at et google-søk bragte dem til meg og mine undervisningsfoiler om stabilitet og robusthet i korthus, siden de lå på net. Dum som jeg var sa jeg at jeg ikke var ekspert på korthus - sukk. Ellers kunne jo dette blitt litt artig.

I det minste burde jeg ha henvist til en eller annen professor på konstruksjonsteknikk. Det ville jo også faktisk vært relevant.

 

2013-07-29

Redundans

Redundans betyr noe som er overflødig. Det er lite tankekors at det er et svært negativt ladet ord når man snakker om personalpolitikk, mens når temaet er IT-drift, så er redundans noe pent og vakkert som alle vil gjerne ha.

Årsaken til det er at vanligvis ligger det en kontekst rundt når vi snakker om redundans innen IT-drift, nemlig at redundans eliminerer enkeltpunktsfeil (single point of failure, SPOF). En SPOF er et punkt i systemet der en feil – f.eks. en sviktende harddisk eller strømforsyning – tar ned ikke bare den feilende komponenten, men har ringvirkninger som tar ned de tjenestene som leveres med disse komponentene. Redundans brukes for å eliminere SPOF i systemet, ved å kreve at én eller flere ekstra, likeverdige (dvs redundante) løsninger som kjører i parallell med basisløsningen må feile før tjenesten som bygger på løsningen svikter.

En bil har minst to bremselys. Det er ikke bare for at det skal se fint og symmetrisk ut. Det betyr også at om én bremselyspære svikter, så kan biler bak fremdeles se når man bremser. Men det forutsetter at man skifter pærene når de går, slik at man gjenoppretter redundansen når den sikkerhetsmarginen den gir oss er blitt brukt opp.

Redundans er den viktigste arkitektekturmessige byggeklossen for å sikre kvalitet på dataanlegget, og det er et uunnværlig konsept innen høytilgjengelige løsninger. Poenget med høytilgjengelighet er ikke at maskinvaren har blitt så mye bedre med årene – det kan argumenteres med at den tvert om har blitt dårligere på endel områder. Poenget er derimot at man bygger løsninger som overlever feilende komponenter – og bygger disse løsningen av relativt rimelige, men ikke spesielt ufeilbare komponenter. Det er med andre ord det konstruerte systemet og den tjenesten det lever som har høy oppetid, ikke komponentene den er bygget opp av.

Redundans gir ofte mer kompliserte løsninger. Om ikke annet blir det flere komponenter enn for et system uten redundans. Men normalt blir det mer komplisert også utover dette. Ikke minst under feilsøkning, der redundans kan gjøre feilsituasjonene tilsynelatende umulig å reprodusere. Når man trenger å finne feilende komponenter, så kan man ikke lengre søke trøst i at sålenge systemet ser ut til å fungerer så er det neppe noen feil. Dermed blir overvåkning desto viktigere, og vips har man skaffet seg enda et nivå med kompleksitet og administrasjon.

Selve ordet betyr overflødig også rent bokstavelig. Redundare er latin og betyr det som renner tilbake, for eksempel etter irrigering av en åker. Midt-stavelsen kjenner vi fra «ad dundas», som betyr «til bølgene», dvs det har gått overbord og som er tapt eller kastet for alltid.

Redundans er riktignok rent språklig det som er overflødig, men i IT-drift er det en av de virkelig nyttige teknikkene.

 

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.

 

2008-08-29

Fordypningsemne i drift

I høst kjøres fordypningsemnet i drift TDT43, der vi skal gå igjennom ITIL v3 - det er ikke det samme som driftsfaget, som går på våren. Det er strengt tatt bare for femteklassinger i datateknikk, og det er bare meg og én student. Vi kommer til å kjøre det som en seminarserie, og dersom det er noen med nysgjerrighet, litt driftserfaring og deltakervilje som ønsker å kaste seg med, så kontakt meg. Da blir vi litt flere og diskusjonen går glattere og vi får flere vinklinger. Vi legger nivået på kurset i henhold til den formelle studenten, men det er sikkert noen rundt om som er på tilsvarende nivå, og som derfor kunne ha glede av å delta.

Vi bruker boka Foundation of IT Service Management Based on ITIL V3, og kommer til å ta ca ett kapittel pr uke, muligens med litt ekstra støttelitteratur som deles ut etter behov. Undervisningsformen er to timer pr uke. Hver dobbelttime starter med en kort presentasjon av kapittelet og deretter diskusjon. Alle som deltar forventes å ha lest kapittelet og på forhånd ha formulert en håndfull innspill til diskusjonen: problemstillinger, uklarheter, synspunkter, erfaringer, mangler, styrker, snubletråder osv.

Første dobbelttime er fredag 5. september kl 13.15-15.00 på Gløshaugen, rom IT-Syd 236. De resterende dobbelttimene blir på en annen ukedag, men tidpunkt er ikke bestemt, og evt deltakere kan komme med innspill. Tema for første dobbelttime er kapittel 1 og 2 i boka.

Dersom du er interessert i å delta, så send meg mail til anders@idi.ntnu.no. Det er fullt mulig å delta uten å ta eksamen - faktisk er det sannsynligvis ikke mulig å ta eksamen for andre enn de som formelt har kurset på timeplanen :-) Det er også fullt mulig å delta på bare noen av seminarene, ja til og med bare ha ambisjoner om det. I det høyst usannsynlige tilfellet at det flommer over med ønsker om å være med, så kommer jeg til å sette et tak på antall deltakelse.


 
naltKgCkeRvvTNEQGrN - lagt inn av Jonnie - 2011/6/11 22:19:08
And I thought I was the sesnlibe one. Thanks for setting me straight.
XMEKsEUpjDEYhrCviGd - lagt inn av jglqnythgph - 2011/6/12 09:11:31
SKdNAe <a href="http://xhmxrynijcng.com/">xhmxrynijcng</a>
eqfMfmBhOBQ - lagt inn av tppwpv - 2011/6/13 10:39:06
vdcepI , [url=http://kaavrbqpgeux.com/]kaavrbqpgeux[/url], [link=http://byfvmfamccwn.com/]byfvmfamccwn[/link], http://aebixurxceex.com/

2008-08-12

Tilgjengelighetsprisen 2008

Rune Andersen på IME ble nettopp tildelt tilgjengelighetsprisen for 2008 fra en eller annen instans ved NTNU med venner - jeg fikk ikke helt med meg hva eller hvem.

Når det deles ut slike priser, så tenker jeg umiddelbart: jaja, det er aldri noen jeg kjenner som får dem, og sjeldent for noe jeg synes er viktig. Men ikke slik denne gang!

Rune fikk prisen for å lage maler og gjøre websidene ved NTNU mer tilgjengelige. Han skal ikke lastes for mange av teknologivalgene ved NTNU, for hans banehalvdel er stort sett IME, samt der han har klart å komme i inngripen med NTNU sentralt. På IME har han latt være å bruke de store, interne, endringstunge, database(mis)brukende, dyre CMS-ene som ingen liker, og i stedet implementert alle websidene i en Wiki. Det er slikt man ikke alltid blir populær av, men hver gang noen har påpekt at noe ikke kunne gjøres i Runes system, så har han svart «vent litt» og så har funksjonaliteten vært der.

Rune har jobbet hardt for å følge standarder, lage maler som er renslige, ryddige, modulære, utvidbare og alle de andre tingene som vi ikke alltid finner på websider. For ham er det ikke tilstrekkelig at det fjongt og fancy ut i ens egen webbrowser, men det skal være riktig etter en standard, det skal være portabelt mellom ulike browserimplementasjoner, og koden skal være ryddig, selv om knappest noen kommer til noensinne å se på den.

Gratulerer, Rune!! Og gratulerer NTNU for at man også har satt søkelyset på at konstruksjon av websider ikke bare er en lekegrind for «webdesignere», men et område der man må tenke tilgjengelighet, skalering, standarder og slikt!

 

2008-07-19

Nettverksfrustrasjoner

Sukk. Akkurat nå har jeg 50% oppetid på nettverket hjemme, fordi nettverksmodemet fra Bluecom fungerer annethvert halvminutt. Ja, du leste rett. Dersom jeg pinger, så kommer ca 30 pingpakker gjennom, så det ca 30 som ikke kommer igjennom, så kommer ca 30 igjennom ... og det hele repeterer seg ad neuseam. Eller rettere sagt, slik hangler det en periode på rundt en halvtime, så er nettet ok en halvtime, så og så repeterer dén rytmen seg over en periode på rundt seks timer. Vanligvis går det noen dager mellom hver gang vi har en slik periode.

Det er nærmest som tortur å regne. Når jeg har tid til å feilsøke, så er alt ok, mens når jeg har det travelt, går den inn i sykler på halvminutter oppe og nede. Derfor jeg har aldri fått feilsøkt det skikkelig. Og med litt planlegging, så overlever jeg det alltid. Jeg har utviklet en teknikk med auditable pings og multitasking, så når det plopper i høyttaleren så kontekstsvitsjer jeg over til den oppgaven som trenger nett - i 30 sekunder. Det er en overdrivelse å si at det er en behagelig måte å jobbe på: ikke er det effektivt å kontekstsvitsje oppgaver to ganger per minutt, og heller ikke er det behagelig å sitte å lytte til plingingen, men det går ...

Tidvist har det fungert å boote ADSL-modemet, men det fungerer visst ikke lengre. Jeg tror det er noe som går i metning eller krasjer eller noe slikt, og så tar det ca 30 sekunder å resette. Det er heller ikke slik hele tiden. Grafene under viser hvordan det går i perioder, for siste halvannen dag og siste halvannen uke. De måler tiden frem til først og siste overførte byte i en wget fra en webside på NTNU.

Oppetid for nettet siste uka

Oppetid for nettet siste uka

Men nå er snart tålmodigheten slutt - hvilket betyr at nettet kommer til å virke prikkfritt i et par dager. Jeg kjenner blodtrykket stige bare ved tanken på å skulle kontakte en telefonkundeservicesenterhelpdesk for å forsøke å forklare dette feilmoduset. Det har virket som om det er en tendens til at det er verst på natta, enten frem mot midnatt eller like etter - så det er ikke helpdeskserviceåpningstidsvennlig. Som allerede nevnt er det heller ikke repeterbart på kommando, så det er et feilsøkingsmareritt.

Det er et feilmønster som ikke kunne vært mer frustrerende om det var ondsinnet designet av mine verste fiender. Det enkleste er vel å innse at Bluecom var et dårlig teknisk valg, og skifte til ny leverandør. Arrrrrgh!


 
- lagt inn av Magni - 2008/7/21 23:27:23
Sjå iallfall det positive i det: det er jobben min som betaler, så du ar grayis nett. Du kan få jobben din til å betale nett frå ein annan leverandør ;-)
- lagt inn av Magni - 2008/7/21 23:28:45
dslkjlkjfdkjvkjlcd cxkjlkcx k mxcøølcxølkcx full i hodet
- lagt inn av Magni - 2008/7/21 23:29:16
hurra fyllecaptcha
uOhHtqJKHZGxzX - lagt inn av Rosa - 2012/1/7 20:31:11
It's iemprative that more people make this exact point.

2007-08-02

Valgets kvaler

Limoncelli og Hogan har - sammen med Strata Chalup som ny medforfatter - kommet med ny utgave av «The Practice of System and Network Administration», og dermed har jeg et valg foran neste års TDT4285-fag. Skal jeg bruke den nye boka, eller skal jeg velge en annen bok.

Den nye utgaven har vært annonsert lenge. De siste 2-3 årene har den kontinuerlig lagt omkring seks måneder frem i tid ... vanligvis et dårlig tegn. En kjapp blading i den viser at det er noen nye kapitler, og endel tillegg her og der, men generelt sett er det ikke de store fundamentale endringene. Prisen er også stiv, på 536,- men det er likevel billigere enn den forrige utgaven.

Alternativet er å bruke «IT Service Management based on ITIL - an introduction», som er på overkommelige 240 sider og rundt 330,- på Amazon, og full av presise definisjoner og TLA-er. På mange måter er den diametralt motsatt av Limoncelli-boka, for der Limoncelli formidler at det viktige er å gi deg som systemansvarlig en forståelse som du kan tilpasse og bruke i fremtidige situasjoner, så er ITIL-boka tilsynelatende et presist kart for hvordan en driftsenhet bør fungere. På et overordnet nivå er de egentlig ikke så forskjellige i filosofi, men i presentasjon og fremtoning er de ekstremt forskjellige.

Jaja ... livet er fullt av valg. Er det noen gamle studenter som leser denne bloggen og kan komme med råd og forslag til hvilken bok som er mest hensiktsmessig?

 
- lagt inn av magni - 8/2/2007 14:52:36
sjølv synes eg limoncelli et al si bok er bra. ITIL-boka virker ein del hakke tørrare og meir keisam. Eg synes kanskje at eit fag på universitetet skal vere litt meir generelt enn eit kurs i ITIL, sjølv om sistnemnde også blir veldig generelt. Magekjensla mi seier limoncelli.
- lagt inn av Simen - 8/2/2007 18:15:36
Jeg likte Limoncelli veldig godt. Det var riktignok mange sider å lese, men det var absolutt lesbart stoff. ITIL-boka virker etter beskrivelsen kjedelig og lite tenke-selv-vennlig. Kurset som sådan bør heller ikke bli for ITIL-sentrert, selv om ITIL er et nyttig verktøy.
- lagt inn av PO - 8/13/2007 14:29:42
Støtter Simen her :) Likte Limoncelli-boka godt og synes den fungerte greit til faget.
- lagt inn av Øyvind - 9/11/2007 14:34:38
Limoncelli-boken var en av mine favoritter når det kom til fagbøker, og jeg satte veldig pris på at mye av det de sa ble forsterket med (tidvis morsomme) anekdoter.

2006-09-25

Just one of those days ...

Det er mangt og mye man opplever. I lunsjen idag fortalte en av lunsjkameratene mine om en fyr hos seg som kom med en dyr, halvannet år gammel bærbar. Den hadde svart skjerm ... hvilket ikke er helt uvanlig. Etterhvert kom det frem hva som hadde skjedd. Familiens katte hadde pisset i den bærbare PC'en.

Hva gjør så denne personen (som er fast vitenskaplig ansatt på et institutt som har elektronikk som fokusområde)? Jo, han vil tørke PC'en, og den beste måten er å skru på strømmen, så det blir varme i elektronikken slik at kattepisset tørker opp, og en vifte som kan blåse det ut ... tenkte han. Etter lunsj skal de forsøke å ta ut harddisken og se om de i det minste kan få ut dataene.

Og sånn går dagene.

 
testing - lagt inn av anders - 9/28/2006 16:11:11
just testing
- lagt inn av anders - 9/28/2006 16:11:38
foobar

2006-03-12

Automatisering er som en løk

Man kan se på automatisering som en løk med flere skall, eller med flere lag eller nivåer. Innerst inne er kjerneaktiviteten i automatisering, men uten de ytre lagene blir det pislete og stakkarlige greier. La meg forklare:
  • Innerst inne ligger funksjonaliteten. Dersom ikke en automatisert oppgave faktisk løser oppgaven som er målet, så er og blir den dysfunksjonell samme hvordan du snur og vender på det. Dette er gjennomføringen, og de som tror dette er alt det er ved automatisering, har misforstått noe fundamentalt.

  • Neste nivå er stabilitet, som er et systems evne til å fortsette å virke over tid. Det motsatte - et ustabilt system - er noe som mer eller mindre faller sammen av seg selv. Stabilitet er viktig i en automatisert oppgave fordi den skal fortsette å kjøre gang på gang i overskuelig fremtid, men det tar tid og testing å sikre at den automatiserte oppgaven er stabilt spesifisert og programmert.

  • Tredje nivå er robusthet, som er beslektet med stabilitet, men allikevel fundamentalt forskjellig. Med robusthet menes et systems evne til forsatt å virke selv om omgivelsene rundt det endrer seg. Et stabilt korthus fortsetter å stå av seg selv, mens et robust korthus i tillegg takler at du puster på det og rugger litt i bordet. Stabilitet er viktig for en automatisert oppgave fordi miljøet det skal kjøre innen, garantert kommer til å endre seg over tid - du har kanskje ikke planlagt endringene ennå, men de kommer!

  • Det fjerde og siste nivået er elegant feiling. Det betyr at når systemet tross funksjonalitet, stabilitet og robusthet allikevel ikke kan fullføre oppgaven sin, så sier det ifra på en grei og informativ måte. Ting som den ikke har blitt programmert til å takle, skal den heller ikke forsøke å ordne.

Jeg misliker automatiserte jobber når de inntrengende, repeterende og pågående forteller meg om alt som er normalt. Jeg har allerede nok avbrytelser og oppmerksomhetsavledninger i arbeidsdagen til at jeg trenger noe som støyer bare for å fortelle meg at alt er i orden. Nettopp derfor er det viktig at en automatisert jobb holder kjeft sålenge alt er i orden, og kun skriker opp dersom noe er galt. Enkle, hyppige og lettolklige feil bør den settes opp til å håndtere selv, mens de øvrige bør videresendes til en systemadministrator i mest mulig ordrett kopi og med best mulig bakgrunnsinfo. Manuell, inkrementell tilpassing av den automatiserte oppgaven over tid er den enkleste måten å gjøre den stabil og robust på.

Dette betyr ikke at jeg har noe imot statistikkrapportering og logging av at alt er greitt. Det må imidlertid skilles skarpt mellom to ting som har hvert sitt bruksområde: På den ene siden er det som er tilstandslogging som en systemadministrator kan oppsøke for rapportgenerering eller post-mortem debugging. På den andre siden er det som varsler om at noe er galt, og som systemadministrator bør få som avbruddshåndtering.

 
sSbEUiyPwhgNJWjsDh - lagt inn av Lynda - 2011/6/12 19:41:35
That's really thinking out of the box. Thnkas!
SxZdhHsTDkfNJ - lagt inn av zmryjtskmz - 2011/6/13 09:50:15
uu9AVW <a href="http://plnwijztiwoy.com/">plnwijztiwoy</a>
WdYqJufgExHehU - lagt inn av uwqunyve - 2011/6/13 14:08:58
NivMCK , [url=http://tatficbvvksq.com/]tatficbvvksq[/url], [link=http://mywyndhdnide.com/]mywyndhdnide[/link], http://ajdgoldbhrps.com/

Side 1/2: 1 2 »