in113

1. in113 feiladministrasjon

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

3. 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)

4. 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

5. 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

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

7. 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

8. 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

9. 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

10. ø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

11. 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)

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

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

14. en enkel analytisk modell • hver komponent har pålitelighet pi (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

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

16. 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

17. 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

18. 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) >= .998995 • 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

19. 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 - 0.1*(1-p(2)) p(2) >= (.999-1)/0.1+1 = .99

20. 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 • .00365 dg (5.25 min) 1000 ganger i året tilsvarer kaffepause (akseptabelt) • .000365 dg (31 sekund) 10000 ganger i året vil antakeligvis ikke merkes

21. seriesystem: pålitelighet alltid lavere enn ”dårligste” komponent • p <= mini 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 >= maxi p(i) • hvis jeg hekter på en ekstra i parallell med ultra-dårlig pålitelighet vil jeg øke p

22. 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...)