in113 feiladministrasjon

... vi gjentar •mål med drift: sikre at forventede funksjoner og kvaliteter opprettholdes •forventningen definert i tjenesteavtalen mellom bruker og driftsgruppe

feiladministrasjon •fault management (ISO management terminologi) – de fire ”R”-er –report: motta feilrapport –restore: gjenskape tjeneste med alternative ressurser (kanskje til dårligere kvalitet) –root cause: finne feil –repair: reparere feil (til produksjonskvalitet)

feiltyper •flyktige (intermittent) –dårlig ytelse grunnet midlertidig overlast •fikses egentlig ikke, gir for dårlig arbeidstakt –maskinvare som tidvis svikter •fikses med reparasjon, utbytting •varige (permanent) –programvare som har ”låst seg” •fikses med omstart –maskinvare som har sviktet •fikses med reparasjon, utbytting

statistisk tilgjengelighet •komponent e.l. er oppe, nede, oppe, nede... – gir oss en måleserie med –TTF: Time To Failure (varigheten av ”oppe”) –TTR: Time To Repair (varigheten av ”nede”) •Mean Time To Failure (MTTF): gj.snitt av alle målte oppetider –”mean” betyr gjennomsnitt •Mean Time To Repair (MTTR): gj.snitt av alle målte nedetider

•Availability, målt tilgjengelighet: p = MTTF / (MTTF+MTTR) p et tall mellom 0 og 1 •utilgjengelighet: 1-p

forbedre tilgjengelighet •redusere MTTR – reaktivt (skaden har skjedd) –redusere tiden det tar å utføre en/flere av de fire R’er •øke MTTF – proaktivt (skadeforebygging) –bruke mer pålitelige komponenter (maskinvare og programvare) –legge inn redundans og dynamisk binding –legge inn sikring mot feil bruk – en politikk som bestemmer hvem som får gjøre hva, og under hvilke omstendigheter dette kan tillates

redusere R-tid: bedre beredskap •report: oppdage feil tidligere –gode sensorer (overvåkning), effektive alarmer –godt beskrevne feil (symptomer) •recovery: –automatisk ”failover” til reserveressurser –manuell omdirigering (tregere, ofte nødvendig) •root cause: finne rotfeil –automatisk feilfinning: kostbar programvare som korrelerer mellom flere symptom •reparasjon: eget reservedelslager

•MTTR kan reduseres ved –økning av kompetanse hos personalet –forbedring av logistikk (beredskap) •definerte ansvarsområder •definerte prosedyrer •sikkerhet for at prosedyrer og ansvar fungerer (gjennom testing, ala ”brannøvelser”) –innføring av automatikk

øke MTTF? •planlegging krever at vi kan modellere systemet vi skal lage •vi må ha tall å ”plugge i modellen” –våre egne eller andres erfaringer –tester/erfaringer fra uavhengige kilder –uttalelser/garantier fra produsent •skal komme ut med et forslag til et tilstrekkelig godt system

modeller •må kjenne –belastning (last) fra omverden (brukere, programvare) –intern struktur i systemet •detaljrikdom kompliserer for mye, må arbeide på et høyt abstraksjonsnivå –anse en del for å være ”Windows 2000 Server”, operativsystem, ikke modeller interne deler •måter å teste resultatet på –simuleringsmodell –analytisk modell –eksperimentell modell (med virkelige deler)

eksperimentell 1.etablere en ”testlab” og et initielt systemoppsett (maskiner og programvare) 2.gjennomfør eksperiment 1.sett opp (koble sammen) systemet 2.start lastgeneratorer som simulerer typiske brukere og deres arbeidsmønster – varier lasten 3.vurder resultat (ytelse, pålitelighet) 3.endre systemoppsett og gå til pkt. 2 evt. avslutt hvis resultatet er akseptabelt

analytisk/simulering •samme prosedyre, bortsett fra at systemmodellen er ulik –analytisk formulert i et matematisk språk –programmatisk formulert i et simuleringsspråk

en enkel analytisk modell •hver komponent har pålitelighet p i (mellom 0 og 1) •flere slike i serie (etter hverandre) har samlet pålitelighet lik produktet av hver enkelt: p = p(1)*p(2)*... *p(n-1)*p(n) •flere i parallell har samlet upålitelighet lik produktet av hver enkelts upålitelighet: p=1 – [ 1-p(1))*(1-p(2))*...*(1-p(n-1))*(1-p(n) ] •kombinasjoner av seriell og parallell: gjøres om til rene serielle eller parallelle system

•nettverskort har MTTF=5 år= min •ved feil må –nytt bestilles med to dagers leveringstid (2880 min): p= /( ) =.9989 –nytt hentes i reservedelslager (10 min): p= /( ) = •Høgskolen har to navnetjenere (primær og sekundær) p(1)=.995, p(2)=.95 p= 1 - [(1-.995)*(1-.95)] = =.99975

planlegging •både MTTF og MTTR påvirkes i form av valg en gjør under planleggingen –en planlegger utfra forventningen til de enkelte komponenter •når planene er iverksatt og produksjonen er i gang er en prisgitt de valg en foretok under planleggingen –forventningen kan endres under produksjon (en ser at noe feiler mindre/mere enn før) –en bør periodisk revurdere produksjonsplanen i henhold til nye tjenestekrav og endringer i forventningen

design •tjenesteavtale definerer minste aksepterbare pålitelighet: P •problem for designer: sett sammen komponenter slik at samlet pålitelighet blir P eller høyere •ofte har en et system og skal forbedre det, da er det en/noen få komponenter som skal byttes ut eller forbedres på annen måte

seriedesign •eks.: anta at en nettverksrute har 10 hopp –finn p(k) slik at P >p(1)*p(2)*...*p(10) 0.99<=p(k) 10 p(k)>=.99 (1/10) p(k) >= –antar at alle nettverkskort er like (ikke alltid like realistisk) –virkelig pålitelighet er lavere, da det er mange andre ikke-modellerte deler i en rute

•HsM ønsker å gå fra en til to speilede filtjenere i parallell P=.999, og p(1)=0.9 P <= 1 - [(1-0.9)*(1-p(2))].999 >= *(1-p(2)) p(2) >= (.999-1)/0.1+1 =.99

hva ligger i ”nedetid” •målt over et år vil p=.99 bety 3.65 dager nedetid –3.65 dg kontinuerlig i mellomjula (betyr lite) –3.65 dg kontinuerlig i høysesong (alvorlig) –1.825 dg 2 ganger (mindre alvorlig) –0.365 dg (8.76 timer) 10 ganger i løpet av året er også alvorlig hvis det skjer i arbeidstiden –.0365 dg (52.5 min) 100 ganger i året merkes – dg (5.25 min) 1000 ganger i året tilsvarer kaffepause (akseptabelt) – dg (31 sekund) ganger i året vil antakeligvis ikke merkes

•seriesystem: pålitelighet alltid lavere enn ”dårligste” komponent –p <= min i p(i) –hvis jeg hekter på en ekstra med ultra-bra pålitelighet vil jeg bare redusere p •parallelle system: pålitelighet alltid bedre enn den ”beste” komponent –p >= max i p(i) –hvis jeg hekter på en ekstra i parallell med ultra-dårlig pålitelighet vil jeg øke p

redundanseksempel •reservelager maskinutstyr •flere Internett-koblinger, DNS, IP-ruter •backup av data og programvare •speiling/RAID-1 •roaming, tynne klienter, Intel PC ”overalt” •terminalplass/arbeidsplass bytteavtale •ansvarshavende i feiladm •mobile prosesser •mye plass (RAM, lager...)