Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

TDT4285 Planlegging og drift av IT-systemer Våren 2004

Liknende presentasjoner


Presentasjon om: "TDT4285 Planlegging og drift av IT-systemer Våren 2004"— Utskrift av presentasjonen:

1 TDT4285 Planlegging og drift av IT-systemer Våren 2004
Introduksjon TDT4285 Planlegging og drift av IT-systemer Våren 2004 Våren 2004 TDT4285 Planl&drift IT-syst

2 TDT4285 Planl&drift IT-syst
Våren 2004 Faglærer og und.ass. Faglærer: Anders Christensen Telefon: (evt: ) E-post: Kontor: IT-Syd rom 234 Und.ass: Morten Werner Olsen E-post: Min bakgrunn for å undervise dette faget: Arbeidet i orakeltjenesten ; Arbeidet i studdrift ;. Siving i datateknikk 1994 fra IDI; RUNIT ; siv.ing/konsulent.. IDI leder teknisk gruppe. Undervist SIF ; Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

3 TDT4285 Planl&drift IT-syst
Våren 2004 Timeplan Mandag Tirsdag Onsdag Torsdag Fredag Forel: F4 Øving: F2 Forel: H1 Øving: F6 Vi ser at det er timeplanfestet 5 timer i 4 ulike rom. Auditorium F4 har bare 40 plasser, og det spørs om det er tilstrekkelig. Jeg har lært til neste år. Dersom du erklærer at du bruker projektor, så får du et nytt og oppusset auditorium, ellers får du et gammlet et. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

4 Vekttall og timefordeling
TDT4285 Planl&drift IT-syst Våren 2004 Vekttall og timefordeling 3 timer 4 timer Jeg vil legge opp forelesningene slik at jeg antar denne tidsfordelingen. Det vil si at jeg antar følgende: at alle bruker ca en time på forberedelser og etterarbeid pr forelesningstime. at alle har inntil 5 timer pr uke til øvingsløsning og fordypning i faget. Det er viktig å jobbe jevnt med faget, da det er et modningsfag, det betyr at man må ha forståelse. Det er ikke tilstrekkelig å pugge formler. Dette er ikke et fag man får god karakter ved å sprenglese noen dager foran eksamen. Det er ingen grunn til å prokrastinere! 3 timer 2 timer Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

5 TDT4285 Planl&drift IT-syst
Våren 2004 Todelt øvingsopplegg Ukentlige øvinger med løsningsforslag, der de som ønsker det kan få øvingen kommentert og rettet av und.ass. En felles, obligatorisk øving mot midten av semesteret. Målet er at alle skal tilpasse, dokumentere, installere og drive hver sin del av en datamaskin. De ukentlige øvingene er i tradisjonen med ’regneøvinger’. De vil relatere seg mer eller mindre til de som har vært undervist den siste uka eller så. Disse øvingene vil være svært tekstlige, derfor finnes det heller ikke noen fasit; men vi deler ut et løsningsforslag som viser hvordan ting kan gjøres. Disse øvingene er frivillige. Den timeplanbelagte øvingstimen er planlagt å skulle brukes til å gjennomgå disse oppgavene. Den obligatoriske øvingen er lagt opp som et stykke arbeid i grupper der hver enkelt gruppe skal gjøre sin del av driften på en felles maskin. De store utfordringene i denne øvingen blir: Å håndtere ’mange kokker og mye søl’. Siden det er så mange ulike personer og grupper som skal operere på samme maskinen, blir den administrative overheaden i et slikt prosjekt langt større og mer utfordrende enn for en normal situasjon med helttidsarbeidende sysadminer. Å dokumentere komplett et subsett av et driftssystem. Å organisere arbeidet med driften av dette systemet, og ikke minst koordinere mellom gruppene. Vi kommer tilbake senere med mer detaljert informasjon om denne øvingen. Det er åpent for alternativer, og det er ennå ikke fastlagt noe. Første vanlige (frivillige) øving er torsdag 15/1. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

6 TDT4285 Planl&drift IT-syst
Våren 2004 Fjernstudenter Fraråder å skulke forelesningene Men: tilrettelegger for de som ikke være i Trondheim i semesteret. Viktig: utenbys studenter må gi beskjed så fort som mulig Nettopp fordi det er et modningsfag, frarådes det at man sitter og leser på egen hånd. Det er sammenhengen i faget, snarere enn de enkelte elementene som er viktig, og det kan være vanskelig å få med seg i selvstudium. Som alternativ for de som måtte jobbe utenbys fra: Forelesninger og annet materiell på nett. Alle innleveringer elektronisk Obligatorisk øving som ett av følgende: En del av felles oppgave som kan gjøres over nettet Være med på gruppe som arbeidsdeler slik at det er mulig Egen, isolert oppgave – som neppe er mindre :-) Problemstilling: hva gjør vi med utdrag i fra bøker? Men det er viktig at vi snarest mulig får vite hvem som eventuelt trenger spesialbehandling ifm obligatorisk øving. Dette er ikke et opplegg for de som bor i Trondheim og som ikke har lyst til å ta den vanlige obligatoriske øvingen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

7 TDT4285 Planl&drift IT-syst
Våren 2004 Forelesningsplan Introduserende (3) Grunnleggende kunnskap (8) Konsepter (9) Konkrete områder (18) Utsyn fremover (4) Det er 42 (14x3 timer) forelesninger. Hver forelesning er en mer eller mindre selvstendig enhet. Det finnes en utførlig forelesningsplan. Forelesningene er forsøkt gruppert etter overordnet emne. Hensikten med forelesningsplanen er å tillate studentene å forberede seg, ikke primært å kunne skulke uinteressante forelesninger. Skal forsøke å varsle i god tid hva som er pensum og hvilke emner som skal tas opp. Det setter studentene i stand til å forberede seg til forelesningen. Kan komme til å forskyve litt i starten, avhengig av om pensumbøkene er tilgjengelige. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

8 TDT4285 Planl&drift IT-syst
Våren 2004 Pensumlitteratur Limoncelli & Hogan: Practice of System and Network Administration Diverse utfyllende papers Foiler fra forelesningene Obligatorisk øving Læreboka dekker pensum ganske godt, men den har huller på blant annet følgende områder: Dokumentasjon – alle faser Installasjonssystemer Storskala prosjektplanlegging Inn- og ut-sourcing Analytisk systemadministrasjon Standardiseringsorganisasjoner ITIL Den største fordelen med læreboka er at den (som dette faget) er OS-agnostisk. Selv om forfatterne er Unix-baserte, så kan læreboka brukes under vilkårlig operativsystem. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

9 Utfyllende litteratur
TDT4285 Planl&drift IT-syst Våren 2004 Utfyllende litteratur Burgess: Principles of System and Network Administration. Nemeth & al: Unix System Administration Handbook. Mikalsen & al: Drift av lokalnettverk. Mark Burgess: Principles of System and Network Administration, Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein: Unix System Administation Handbook, Second edition. Prentice Hall 1995, Arne B. Mikalsen & Per Borgesen: Drift av lokalnettverk – Design og sikkerhet. 3. utgave; Tapir forlag, Trondheim 1999; Ikke løp og kjøp disse. Det er ikke nødvendig for fagets del. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

10 TDT4285 Planl&drift IT-syst
Våren 2004 Forelesninger Tilstedeværelse er ønskelig! Deltakelse i timene er ønskelig! Tidlig på dagen -> trøtthet? Foreleser kan spørre studentene. Diskusjon av mikrocases. Starter presis ... Fransklæreren min som vi foreslo kunne snakke fransk til oss mens vi lyttet, og som prepliserte at man tok ikke pianotimer for lytte til pianolæreren spille. Sent på dagen er man ofte trøtt, derfor er det viktig å skaffe deltakelse. Husk å ta et eple før forelesningen. (Men ikke ta med til foreleser!) Med mikrocases menes relativt korte diskusjoner av små hendelser (reelle eller tenkte) som illustrerer det vi går igjennom av teori. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

11 Kommunikasjonsmidler
TDT4285 Planl&drift IT-syst Våren 2004 Kommunikasjonsmidler (Forelesninger og øvingstimer) Ukentlig trefftid? Epostliste Pr epost Newsgruppe (ntnu.ime.idi.tdt4285) It’s learning? Vi trenger å fastsette tidspunkt for trefftider. I utgangspunktet er det ikke så sannsynlig at det dukker opp mange på disse tidspunktene (hvorpå jeg kan gjøre annet arbeide), men dersom det er noen som har vanskeligheter eller problemer, er det greitt at det allerede finnes et ukentlig tidspunkt. Forslag: tirsdager kl 13: Er det ønske om å bruke it’s learning. Jeg har aldri brukt det, men er villig til å lære, men jeg ønsker å begrense antallet formater og medier som brukes til informasjon. Håndsopprekning over hvor mange som ønsker å bruke hvilke medier for kommunikasjon. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

12 TDT4285 Planl&drift IT-syst
Våren 2004 Rammer for faget O/S-agnostisk Langvarig, holdbar kunnskap Bygger på andre fag ved IDI Se på prinsippene i faget Ikke datasalsøvinger At det er O/S-agnostisk betyr at det ikke er koblet spesifikt mot ett bestemt operativsystem. Faget skal være like relevant for alle O/S. Dog vil nok Unix bli brukt mest i illustrerende eksempler. At det er langvarig og holdbar kunnskap betyr at jeg vil forsøke å undervise det som er relevant selv flere år frem i tid, fremfor her-og-nå-info som er utdatert med neste versjon. At det bygger på andre fag ved IDI betyr at dette faget ikke er en isolert, selvstendig utdanning innen planlegging og drift av IT-systemer. Det må kombineres med andre fag, som gir spesifikk kunnskap innen områder som programmering, datanett, systemutvilkling osv. Emner som er dekket i andre fag vil jeg forsøke å holde meg borte fra; eller bare gi utfyllende kunnskap til. At faget bygger på prinsippene betyr at vi skal forsøke å se overordnet på problemene. Det er ikke så interessant å lære konkret hvordan man legger inn en bruker. I stedet vil vi se på hva en brukerdatabase bør inneholde, og hvordan man vedlikeholder og driver den. At det ikke er datasalsøvinger betyr bare at det ikke er noen klassiske regneøvinger eller tilsvarende som er tatt med i faget. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

13 Plassering av TDT4285 ved IDI
TDT4285 Planl&drift IT-syst Våren 2004 Plassering av TDT4285 ved IDI Datamask. og opsys Prosjekt Datamod og database Diplom TDT4285 Faget bygger formelt på tre andre fag, i henhold til studieplanen. Men det er mest for å skisserer hvilken bakgrunn en ser for seg at studentene skal ha før de tar faget. Studiemessig kan man velge fordypningsemne for Drift av datasystemer, som har har undervisningsmoduler og prosjekt; samt diplomoppgave. Ytelsesvurdering Programmering Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

14 TDT4285 Planl&drift IT-syst
Våren 2004 Eksamen (22 mai 2004) Form er skriftlig Tid er 5 timer Kun kalkulator som hjelpemiddel Må ha godkjent obligatorisk øving Oppgaveformat likner tidligere år Repetisjoner spiser ikke forelesningene Det finnes flere sett med eksamensoppgaver og løsningsforslag. Dele ut disse i forelesningen evt vise til at de ligger på nettet. Nevn litt om at det er en obligatorisk øving, som må være godkjent for å kunne gå opp til eksamen. Det vil bli fulgt opp at den er godkjent, men det vil ikke være vanskelig å stå i obligatorisk øving for det som gjør et reelt forsøk. Eksamen blir neppe med multiple choice som i fjor. Merk at dette er et modningsfag, og det vil eksamensformen bære preg av. Det vil være oppgaver der det forventes at studentene på egen hånd klarer å sette sammen elementer fra ulike sider i faget og se sammenhengen mellom dem. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

15 Synkroniseringsukene
TDT4285 Planl&drift IT-syst Våren 2004 Synkroniseringsukene Undervisningsfri i faget Obligatorisk øving deles ut før synk Kanskje en seminarserie om ITIL, men det er ikke formelt relatert til faget, eller del av pensum I disse ukene (også kalt vårferien) er det ikke planlagt undervisning. Hvilke uker er det? 8 og 9 eller 9 og 10? Jeg vurderer å dra i gang en seminarserie i disse to ukene, der målet er diskusjon og introduksjon til ITIL. Dette vil delvis dekke det som undervises i faget, og er ikke spesifikt rettet mot faget. Det er heller ikke noen formell del av faget, men vil kunne være nyttig tilleggsstoff. Sannsynligvis blir det som halvdagsseminarer, med forelesing/presentasjon og påfølgende diskusjon. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

16 TDT4285 Planl&drift IT-syst
Våren 2004 Kjernen i faget Lite eller ingenting: Formler Regning Operativsystemer Kommandoer Få absolutter Mye av (sentralt): Forståelse Modning Kombinere kunnskap Case-studier Prinsippene Mange alternativer Dette gjør at det er lite å pugge, men mye å være oppmerksom på. Det er sannsynligvis et umulig fag å pugge til kvelden før eksamen. Tidligere har personer med endel erfaring tatt faget, og gjort det godt, nettopp fordi erfaringsgrunnlaget har gitt dem en ramme å sette faget inn i. Det betyr at det er et fag som man bør lese bredt og mye i, men uten å eksamenspugge konkrete ting. Jeg vil forsøke å ta med ett-to konkrete, reelle eksempler fra dagliglivet (gjerne fra lokale og samtidige kilder) for å illustrere det som er dagens tema. Disse eksemplene kan gjerne presenteres som et case i dialog med studentene. Det er viktig å få med seg at det ikke er noen fasit i dette faget, det finnes mange måter å gjøre en ting på; men det finnes en slags konsensus om at noen måter er bedre enn andre. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

17 TDT4285 Planl&drift IT-syst
Våren 2004 Målgruppe for faget Kommende IT-sjefer ved SMB Driftssjefer ved store bedrifter ’Systems architects’ som skal planlegge og implementere datasystemer Erfarne sysadmins ved store systemer Konsulentbransjen Eller sagt på en annen måte: hvem er du om X år? Det er ikke et mål å lære bort kommandoer for ditt og ikoner for datt. Det finnes det flere fag og linjer ved ulike ingeniørhøgskoler som tar seg av. Det er målet at studentene skal kunne gå inn som IT-sjef på små og mellomstore bedrifter, og med mer erfaring også for store bedrifter. Gi forståelse for hva det vil si å ha ansvar for å drive et middels eller stort datasystem. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

18 TDT4285 Planl&drift IT-syst
Våren 2004 Spørsmål? Er det noen spørsmål??? Her er det det vanligvis faller en rungende taushet over salen, og jeg må begynne å stille konkrete spørsmål for å få folk i tale... Spørsmål for å holde i gang/starte konversasjonen dersom det blir tid til overs på slutten: Hva er motivasjonen for å ta faget? Hvor mange tenker på å ta drift videre fra neste år (prosjekt/diplom)? Hvor mange er fra siv.ing kontra fra cand scient? Hvor mange er fra IDI kontra fra andre steder? Hva har andre studenter sagt om faget fra tidligere år? Hvor mange er innom for å snuse på faget, og hvor mange har allerede valgt? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

19 TDT4285 Planl&drift IT-syst
Våren 2004 Utfordringene TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Denne forelesningen skal formidle hva som er de viktigste utfordringene i drift av IT-systemer, og forsøke og gi en forståelse for hvordan disse i stor grad er problemer som henger sammen og som har overlappende årsaker. Videre blir det presentert ti utfordringer somer gjengangere i IT-drift. Forelesningen skal også fortelle litt om historikken og karakteren til faget. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

20 TDT4285 Planl&drift IT-syst
Våren 2004 Historikk Tynne klienter IBM-PC 2000 Mainframes 1990 Servicecenter 1980 IT-avd Bærbare 1970 EDB-avd De første datamaskinene var mainframes som kom på 40- og 50-tallet. Det var digre beist og ble i stor grad brukt som vitenskaplige regnemaskiner. Siden maskinene var dyre og sjeldne, var drift av dem ikke egentlig et problem: i forhold til prisen på maskinen var det billig å ansette en av ingenører til å drive dem. Driftsansvarlig var som en konge som eneveldig styrte over maskinen. Eksempelvis, da NTH kjøpte sin første datamaskin, Gier i 1962, sende man et halvt dusin teknikere ned til produsenten i Kjøbenhavn for å hjelpe til med å lodde den sammen. Idag ville det være utenkelig, både av tekniske, økonomiske og ressursmessige grunner. Selv så sent som i 1985, da NTH kjøpte sin først Cray-maskin, kom det flyttende til Norge to amerkanere sammen med maskinen – to hardwareingeniører som hadde som arbeidsoppgave å passe på maskinen. Bakgrunnen var den samme: Hareware var dyrt, og ingenører var (i forhold) billig. Dermed var det heller ikke noe stort poeng i å effektivisere driften for å spare på arbeidstiden til ingeniørene. Utover 60-tallet og utpå 70-tallet endret dette seg noe. Det ble flere maskiner, og de såkalte ’minimaskinene’ begynte å komme. Dette var maskiner var billigere og som ’bare’ var på størrelse med et kjøleskap, i motsetning til tidligere tider da mange maskiner ville krevd en hel leilighet (eller i det minste en romslig hybel) for å få plass. Samtidig blir det flere maskiner i hvert regnesenter, og man blir nødt til å tenke effektivisering av arbeidstid, fordi man ikke kan fortsette å ansette nye ingeniører etterhvert som maskinparken øker. Med andre ord blir kostnadene til driftspersonalet blir mer tydelig i forhold til innkjøpskostnadene til maskinene. Det er altså i løpet av 60-tallet at man får de første systemadministratorene. Det blir en yrkesgruppe hvis arbeidsoppgaver helt og holdt er å drive datamaskiner. De driver ikke datamaskinene fordi de også skal bruke dem selv (som var vanlig tidligere), men fordi andre skal drive dem. Det er altså en professjonalisering. 1960 ”Internettet” Regnesentre Hjemmemaskinen Minimaskiner Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

21 TDT4285 Planl&drift IT-syst
Våren 2004 Fagets karakter Fra aktivitet → yrke → fagfelt Mange ”midlertidige” og tilfeldige utøvere Er blitt en karrierevei Fremdeles litt vel mye kvakksalveri Raske endringer (paradigmeskifte) Både pragmatisk og religiøst Aldri kjedelig – alltid noe som skjer Faget har utviklet seg fra å være noe man bare gjorde som en administrativ overhead til å bli et eget yrke. Historisk er det et ungt yrke, og dermed er det mange i det som ikke har noen formell utdanning. Mange er sysadmin ”midlertidig” mens de drømmer om en ”skikkelig” jobb innen det ”egentlige” fagfeltet. Spør en sysadmin om hva som egentlig er yrket hans, så er sjansen stor for at han begynner å snakke om partikkelfysikk eller brobygging. Dersom leger drev bransjen sin som sysadmins driver sin, hadde de (nesten) alle blitt arrestert for kvakksalveri. Et paradigmeskifte er når grunnlaget endrer seg 3 størrelsesordner. Mange ting har ikke endret seg siden 60-tallet: biler, fly, telefonen (unntatt mobiltlf), men IT har gjennomgått flere paradigmeskifter: distribuert datakraft, arbeidstasjon, datanettverk osv. I tillegg kommer enorme ytelsesgevinster. Det er sært at faget kombinerer enorm pragmatisme (bare det ’virker’ så er det ikke så farlig hvordan det virker) med tildels sterk religiøsitet, blant annet rundt valg av operativsystem. En ”røverhistorie” som viser at man ikke har designet tilstrekkelig defensivt: Bruker starter tekstbehandling, skriver dokument, lagrer og avslutter (evt lagrer under avslutting). Filen skrives til cache, og programmet avslutter. Cachen forsøkes flushes over nettet til hjemmeområde, noe som feiler. Programmet er avsluttet og dataene kan ikke flushes fra cachen: dataene tapt og bruker sint. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

22 TDT4285 Planl&drift IT-syst
Våren 2004 Hva er IT-drift? Ressurs- utnytting Indirekte oppgave Funksjonalitet For andre enn deg selv Bruker- behov Kost- nader Stabs- funksjon Stabilitet Heltids- beskjeftigelse Profesjonell drift av storskala dataanlegg Vedlikehold Alle disse må være med for å kvalifisere under den definisjonen av IT-drift som vi bruker i dette faget: Øverst til venstre: Professjonell, dvs som yrke, for andre Øverst til høyre: Drift, dvs pågående vedlikehold for å opprettholde Nederst til høyre: Storskala, dvs fokus på mange samtidig Nederst til venstre: Dataanlegg, dvs hele eller store deler av et totalt system Litt for mange har lest noen nummer av Computer World, samtidig som de har drevet sin egen bærbare, og tror de dermed har alt som trengs for å drive store dataanlegg. Merkelig nok ... Få av proffene på IDI later til å tro at de har peiling på drift, trolig fordi de vet at dette er et vanskelig område med behov for spesialinnsikt som de ikke har fra sine respektive områder. Et interessant spørsmål er hvor mange er nok til å kvalifisere for storskala drift. Det er umulig å si et konkret tall, for det avhenger av hvordan du angriper problemet. Det finnes personer som driver en enkelt maskin men allikevel kvalifisererer som storskala drift, samtidig finnes det anlegg av hundrevis med maskiner som sannsynligvis ikke gjør det. Likevel ser det ut til å være en grense et sted mellom 10 og 100, der en eller annen grad av storskala drift nødvendigvis sniker seg inn. Mange maskiner Datamaskiner Mange brukere Brukere Nettverk Stor kompleksitet Parallelle systemer Infra- struktur Programvare Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

23 Systemadministrators roller?
TDT4285 Planl&drift IT-syst Våren 2004 Systemadministrators roller? Tilretteleggeren Brann- mannen Produkt- finneren Team-med- arbeideren Hjelperen Prosjekt- lederen Etterforskeren Bruker- forkjemperen Installatøren Vedlikeholderen Nisje- område- eksperten Nattevakta Leverandør- kontakten Skurken Prosjekt- arbeideren Improvisatøren Psykologen Problem- forebyggeren Rutine- utføreren Infrastruktur- byggeren Kvalitets- sikreren Budsjett- administratoren Sikkerhets- eksperten Utdanneren Dommedags- profeten Dette er å være litt vaktmester, litt skipskaptein, litt mekaniker, litt psykolog. Kort sagt, en må være litt av alt. Det er ikke så interessant å gå igjennom alle disse rollene. Det viktige er at dette er roller, som en sysadmin veksler mellom gjennom en typisk arbeidsdag. Dermed må en også være i stand til å veksle roller og identifisere og skille sine roller. Ikke alle har kvalifikasjoner til å dekke enhver rolle. Dette avhenger av personlighet. Dermed har man behov for team satt sammen av personer med ulik personlighet slik at man tilsammen kan dekke alle rollene. Merk at endel av rollene er gjensidig motstridene. F.eks er det en konflikt mellom fikseren og kvalitetssikreren. Derfor bør det helst deles mellom to forskjellige personer, eller man trenger ansatte som har svært god forståelse av hvordan slike roller håndteres. Den visjonære Vaktmesteren Planleggeren Feil- søkeren Reparatøren Policy- skriveren Selgeren Hønemor Fikseren Overvåkeren Laboratorie- teknikeren Helten Lytteren Løsnings- designeren Avstrafferen Innkjøperen Lederen Teknokraten Syndebukken Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

24 TDT4285 Planl&drift IT-syst
Våren 2004 Terminologi Sysadmin (systemadministrator) person som er (del-)ansvarlig for drift av et datasystem. Drifte – noe man gjør med kyr. Nevne betydningsforskjellen mellom ”System administration” og ”Systems administation”. Få med definisjoner på ”drifte” ifra ordbøkene Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

25 Tre store problemstillinger
TDT4285 Planl&drift IT-syst Våren 2004 Tre store problemstillinger Endringshåndtering Skalerbarhet (Person)kommunikasjon Merk at ’ingen’ av disse punktene er tekniske eller veldig spesielle for datamaskiner. Det er sjelden direkte teknisk uoverkommelige problemer ved et dataanlegg. (Satt på spissen.) En sysadmin er vanligvis kompetent nok til å håndtere det tekniske, men det er det andre som skaper problemene. Hver av disse momentene er forårsakende, deltakende eller forsterkende i 90% av alle problemer på et dataanlegg. Nevne at jeg bruker ”90%” når jeg synser og egentlig mener ”de fleste”. Merk at med kommunikasjon menes ikke bare person-til-person-kommunikasjon. Det omfatter også formidling av informasjon fra en person til seg selv på et senere tidspunkt; dokumentasjon osv. Kommunikasjonen kan være synkron eller asynkron. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

26 Problemstilling 1 Endringshåndtering
TDT4285 Planl&drift IT-syst Våren 2004 Problemstilling 1 Endringshåndtering Målrettet og nyttig endring Planlagt i forkant, bieffekter klarlagt Kontrollert gjennomføring Forhåndstestet og -anonsert Rekonstruerbart og reverserbart Sporbarhet i ettertid Evne til ferdigstilling Motsatsen til alt dette er en endring som ingen helt vet motivasjonen for, eller om den har noen positiv effekt. Den ble gjennomført ad hoc (gjerne en fredag før ferien), uten at man tok hensyn til ringvirkninger. Den ble implementert på et levende system uten testing og uten at noen andre visste om noe (aller minst brukerne). Ingen kan i ettertid si helt sikkert hva som ble gjort eller hvordan man evt skal komme tilbake til opprinnelig system. Det er noe uklart hvem som gjorde det, men det er bare 90% ferdig, men ingen vet helt sikkert hvem som skal gjøre den siste biten. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

27 Problemstilling 2 Skalerbarhet
TDT4285 Planl&drift IT-syst Våren 2004 Problemstilling 2 Skalerbarhet Kapasitetsplanlegging Testing opp mot antatt full last ”Organisatorisk” skalerbarhet Monitorering Kan ta ut stordriftfordeler Med kapasitetsplanlegging menes å beregne volumet av en tjeneste, og implementere løsninger som dekker dette behovet. Det omfatter å teste under full last, men i testomgivelser. Med organisatorisk skalerbarhet menes at de rutiner og organisasjonsformer man bygger opp kan takle hele organisasjonen. Eksempelvis restoring av backup, der restoring av typen ’stikk innom så skal jeg fikse det for deg’ skalerer linært med antallet restores (som er omtrentlig likt antallet personer). Motsatsen til skalerbarhet er hyppige utstyrskjøp, for gjennom ’brute force’ å forsøke å kaste penger på problemet. Løsningene må hyppig byttes ut fordi de ikke takler endrede rammebetingelser særlig godt. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

28 Problemstilling 3 Personkommunikasjon
TDT4285 Planl&drift IT-syst Våren 2004 Problemstilling 3 Personkommunikasjon Alle oppfatter ett budskap likt Differensiering av viktighet på meldinger Sikre seg at meldinger kommer frem Unngå ’antagelser’ Unngå forsinkelser i byråkrati Unngå forvrengning og filtrering Noen eksempler: Drift: ingen klager så da virker det nok Brukerne: drift er inkompetente som ikke ser at dette ikke virker Bruker: PC’en min virker ikke Drift: (feilsøker) åja, den må rebootes. (merk: passiv form) Bruker: javel. (går, antar at drift snart kommer for å reboote) Drift: (antar at brukeren vet at han skal reboote maskinen) Hovedbudskap: Hvordan unngå disse feilene gjennom å designe systemet, rutinene, infokanalene og staben. Kommentar: kinesisk hviskelek må være funnet opp av en som kjenner disse problemene. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

29 TDT4285 Planl&drift IT-syst
Våren 2004 Ti utfordringer Måldefinisjon Feilsøking og –retting Endringer Sikkerhet Divergens Kompleksitet Kommunikasjon Katastrofeplanlegging Bevare eller forbedre? Læring Vi skal se nærmere på disse ti områdene. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

30 Utfordring 1 Måldefinisjon
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 1 Måldefinisjon Er det sikkert at kundene og deres behov er tilstrekkelig klarlagt, og at man har definert oppgavene som skal løses, med hvilket kvalitetsnivå og med hvilken indre prioritering? Vet man om man leverer dette? Hvis ikke driver man ikke dataanlegget ... dataanlegget driver deg! Man må vite hva man skal gjøre på overordnet nivå. Dette er uproblematisk for små systemer, men blir lett kaotisk på store systemer, og det skalerer derfor ikke godt uten en bevisst strategi. Årsaken til dette er at kommunikasjonen med brukermassen kollapser under sin egen vekt når det blir for mange brukere og for mange driftspersoner. Case: gå til en systemadministrator og spør hva han gjør akkurat der og da, og hvordan det hjelper brukerne. Sjansen er stor for at han ikke klarer å svare annet enn i litt tåkede vendinger. Det er også mulig at du skremmer vettet av ham (er det effektivisering på gang?) eller får han sint (verdsetter du ikke innsatsen min?). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

31 Utfordring 2 Feilsøking og -retting
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 2 Feilsøking og -retting Utfører man målrettet og hensiktsmessig feilsøking? Tester man tilstrekkelig? Og er feilrettingen relevant, og ikke bare symptombehandling; eller store rekonfigureringer der en korrigering er tilstrekkelig? Feilsøking er en (helst) ikke-intrusiv analyse for å finne årsakssammenhengen for en eller annen oppførsel. Feilretting er å korrigere noe som ikke lengre virker slik det var designet. Feilretting balanserer mellom symptombehandling, som er en temporær og tilsynelatende korreksjon, og rekonfigurering – som er et redesign av systemet. Ved symptombehandling er faren at man må rette feilen mange ganger og at man går glipp av å finne en dypereliggende feil med flere implikasjoner. Ved rekonfigurering er faren at man introduserer nye feil når man endrer systemet. Eksempel 1 (symptombehandling): Bookmarksfil ble automagisk slettet; men hentes inn fra backup. Eksempel 2 (rekonfigurering): Bytt ut web-browseren med et konkurrerende produkt. Faktisk årsak: Browsers cacheområdet ble automatisk slettet, men var satt ett nivå for høyt oppe, slik at bevaringsverdige filer ble slettet. Generelt: er feilsøkingen målrettet, eller forsøker man seg frem på måfå uten særlig progresjon. Det er i alle fall to (uproduktive) teknikker ute og går: ”seen-to-be-doing-something”, dvs at det er viktigere at folk ser du gjør noe, enn at det er er wså veldig nyttig. Den andre teknikken er å lete etter noen å skylde på – den ansvarlige – i stedet for å lete etter selve feilen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

32 TDT4285 Planl&drift IT-syst
Våren 2004 Utfordring 3 Endringer Skjer endringer på en planlagt, kostnadseffektiv, målrettet, dokumentert, reverserbar og repeterbar måte; og at alle berørte personer er informert, og at ingen uventede bieffekter oppstår? De fleste oppgavene ser mindre ut i forkant enn de faktisk viser seg å være. Dessuten er gjerne folk overoptimistiske. Videre er det ofte lett å utsett en oppgave til siste liten, og da er det ofte for lite tid til å gjennomføre det. En ser ofte at oppgaver omtales som ”bare en liten endring”, men så baller det på seg. Det man anså som så lite at man ikke trengte noen stor, formell prosess, vokser raskt til en dimensjon der det er umulig å få håndtert det uten en formell prosess. Merk: det er et problem at kostnadene med å strukturerearbeidet kommer ”up-front” hos den personen som utfører det ... det kommer med en gang, og er veldig synlig. Hvis man derimot slurver til noe ad hoc, uten en strukturert kvalitetsprosess, så kommer ekstrakostnadene spredd utover som bieffekter hos mange personer og over lang tid. Men kostnadene er ikke så synlige, og for systemansvarlig er de mindre. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

33 TDT4285 Planl&drift IT-syst
Våren 2004 Utfordring 4 Sikkerhet Er alle viktige data identifisert, og sikret mot tap; og er alle data som uvedkommende ikke skal ha innsyn i sikret på tilstrekkelig måte? Håndteres sikkerhet fortløpende eller i skippertak? Case: Stig som kom på PVV mens han var i Forsvaret, og kom frem til at det var sikrere der enn i Forsvaret, for på PVV tenkte de sikkerhet med litt av hjernen hele tiden, mens i Forsvaret var sikkerhet noe man bare tenkte på mellom ett og tre på torsdager. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

34 TDT4285 Planl&drift IT-syst
Våren 2004 Utfordring 5 Divergens Har man sikret at maskinene over tid ikke divergerer som følge av mange akkumulerte, tilfeldige småendringer? Finnes det mekanismer for å konvergere maskinenes tilstand? Vi kaller ofte dette for bitråte. Det vanlige symptomet er: ”Det virket i går/i fjor, og jeg har ikke gjort noenting i mellomtiden”. Det kan skilles mellom bitråte som følge av at verden endrer seg, dvs lovlige endringer som bare ikke er blitt tatt høyde for eller tatt til følge på lokal maskin; og endringer som skyldes feil. Det siste kan være gjenglemte temp-filer, krøll som oppstår når harddisken går full, ved strømstans, prosesser som krasjer, bugs, innbrudd osv. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

35 Utfordring 6 Kompleksitet
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 6 Kompleksitet Har man oversikt over systemets kompleksitet; og er kompleksiteten større enn hva brukernes behov tilsier? En sjekk på IDI blant 730 harddisker på 692 PC’er, fant 132 ulike modeller (også minor revisions), men de 7 hyppigste modellene utgjorde mer en halvparten av harddiskene. Hvor mange maskiner går ned når en maskiner svikter? Hvor mange Single Point of Failure har du. Hvor mange andre tjenester avhenger en vilkårlig tjeneste av? Case: maskinrommet vårt kommer ikke opp av seg selv dersom strømmen har vært borte. Ikke fordi det er noe galt, men fordi kompleksiteten er stor, og bitråden er stor mellom hver hovedboot fordi det er langt imellom dem. Dermed er det alltid noe ”nytt” som går galt. Case: ”ingen” har bootet det norske strømnettet. Ifm år2000 var det enkelte som lurte på om det ville la seg gjøre på kort tid. Oppstart etter større strømstans kan ofte ta en god stund (selv om det da ofte er snakk om skader etter storm etc). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

36 Utfordring 7 Kommunikasjon
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 7 Kommunikasjon Får alle parter den kommunikasjon de skal ha; blir all kommunikasjon oppfattet korrekt og likt; og finnes det måter å ta tak i situasjoner der kommunikasjon er utilstrekkelig eller misforstått? Generelt må vi kjempe mot en overflyt av informasjon, der spam bare er ett enkelt element. Det som blir stadig viktigere er å kunne skille ut den viktige informasjonen fra den uviktige informasjonen. Det samme gjelder i stor grad for brukerne, som helst overser informasjon inntil den er blitt ekstremt viktig eller det som ble advart mot allerede har skjedd. Tilbakemeldinger fra brukerne blir i beste fall øyeblikksbilder som må utfylles med info og statistikk for å kunne finne reelle trender. Viktige teknikker er å si ting veldig eksplisitt, gjenta ting, stille kontrollspørsmål etc. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

37 Utfordring 8 Katastrofeplanlegging
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 8 Katastrofeplanlegging Er det tatt høyde for at driften kan fortsette (med unntak av mindre og akseptable ulemper) uansett hvilken (u)tenkelig hendelse som måtte skje? Noen ting man kanskje ikke hadde forutsett skulle kunne skje: Politiet kommer av en eller annen grunn og beslaglegger hele datasenteret ditt, inklusive alle sett av backup. Det kommer en tornado for aller første gang i historisk tid. Bygningen brant ned om natta Datasenteret ditt er truffet av et fly som har styrtet. Dersom ”alt” brant, hvor lang tid ville du bruke på å rekonstruere, tilhvilken kostnad? Er dette akseptabelt for bedriften (ville den overleve?) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

38 Utfordring 9 Bevare eller forbedre?
TDT4285 Planl&drift IT-syst Våren 2004 Utfordring 9 Bevare eller forbedre? Skal ressursene brukes på vedlikeholdsarbeid (dvs å holde ting flytende) eller å forbedre, øke og fornye systemet (dvs at man kommer videre)? Jeg kaller dette ofte for oppdrift og framdrift. Du trenger begge deler og en god balanse mellom dem. Oppdriften er det som gir deg penger idag, mens fremdriften er det som skal gi deg pengene i morgen. Observasjon: Intet datasystem er så godt og veldrevet og veldokumentert som det som brukerne har sluttet å bruke. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

39 TDT4285 Planl&drift IT-syst
Våren 2004 Utfordring 10 Læring Lærer man av feilene man gjør? Lærer andre av de feilene man gjør? Er det noen som forsøker å finne ut hvilke feil som gjøres og analysere hva som kunne vært gjort bedre, og hvordan det da skulle vært gjort? Nøkkelen til forbedring ligger i det man idag gjør. Ordet forbedre indikerer at det er noe som er annerledes og bedre i forhold til noe annet og eksisterende. Innen drift er målet å se på forholdet mellom behov, ytelse og kostnader, og forsøke å for samsvar mellom ytelse og behov, samt å bedre forholdet mellom ytelser og kostnader. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

40 TDT4285 Planl&drift IT-syst
Våren 2004 Løsningsskisser TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI I denne forelesningen skal vi se på en skisse til rammeverk som løser de problemene som vi identifiserte i forrige forelesning. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

41 Faser i en driftsorgs liv...
TDT4285 Planl&drift IT-syst Våren 2004 Faser i en driftsorgs liv... Områdebasert arbeidsdeling Rollebasert arbeiddeling Supermann Datasenter Radarpar Trekløver 1.linje ITIL Oppdeling av ansvars- område 2.linje Egentlig en dårlig navngivning, for er det skillene som er vertikale eller er det inndelingen som er spredd vertikalt. Radarparet virker fordi de deler kontor, men forutsetter at de småprater om arbeidet hele tiden. Ypperlig for oppæring. Det er typisk at slike radarpar har en tendens til å pådra seg klengenavn som Pompel og pilt, eller Karius og Baktus. Trekløveret er nærmest ustabilt. Jeg tviler på at det lar seg skalere opp til fire personer. Normalt er det et mellomtrinn der det først skilles ut en 3.linje, før 1. og 2. linje skiller lag. 3.linje Heltemodellen Teammodellen Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

42 Helter, team og skalerbarhet
TDT4285 Planl&drift IT-syst Våren 2004 Helter, team og skalerbarhet Heltemodell skalerer bra i små miljøer Heltemodellen kollapser i store miljøer Teammodellen skalerer bra i store miljøer Teammodellen fungerer svært dårlig i svært små miljøer Heltemodellen kan ”tynes” ved oppdeling Merk at denne grafen ignorerer produktivitet! Dette er et ypperlig eksempel på to modeller som skalerer forskjellig. Juletertemodellen, anarki eller kollektiver er en videreføring av oppdelt heltemodell. Merk at heltemodellen kan deles opp, slik at et ansvarsområde kan deles i to mindre ansvarsområder. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

43 Område- eller rollebasert? (eks)
TDT4285 Planl&drift IT-syst Våren 2004 Område- eller rollebasert? (eks) Omr.basert arb.deling Win-tjenere Win-klienter Unix-tjenere Nettverk Skrivere Web og epost Rollebasert arb.deling Brukerstøtte Rutineoppgaver Feilsøking Oppgradering Overvåkning Videreutvikling Vertikal arbeidsdeling er at hver ansatt (eller radarpar) tar kontroll over ’sin’ haug og er eneveldig konge på den. Autonomi. ’Geografisk’ oppdeling. Horisontal arbeidsdeling er at man samarbeider, slik at hver enkelt tar sine faser, deler, fokus etc av en felles totaloppgave. Man jobber flere på samme systemet. Områdebasert arbeidsdeling kan deles etter arbeidsoppgaver, som vist på denne foilen, men det er også mulig å dele inn etter geografi, organisasjon eller etter budsjett. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

44 Når kollapser områdebasert arb.deling?
TDT4285 Planl&drift IT-syst Våren 2004 Når kollapser områdebasert arb.deling? Det blir for mange grenseflater. Hver grenseflate blir for kompleks. Det ikke finnes naturlige gr.flater Vrient å avgjøre ansvar utfra gr.fl. Område1 Område2 Område3 Her er protokoller gode, naturlige grenseflater. Eksempler kan være SMTP, IMAP, POP, LPR, SSH. De er dokumenterte, stabile (innen hver versjon), og man kan bestemme på hvilken side av protokollen en bestemt feil/problem ligger. En killer for vertikal arbeidsdeling er når det ikke er mulig å avgjøre på hvilken side av en grenseflate som et problem ligger. Problemet blir da spilt ping-pong med; brukerne klandrer feil driftsorganisasjon; og man kommuniserer dårlig. Område4 Område5 Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

45 Trenivås rolledeling for drift
TDT4285 Planl&drift IT-syst Våren 2004 Trenivås rolledeling for drift 1.linje Brukerstøtte FAQ Enkel feilsøk Rutiner Enkel adm 2.linje Feilsøking Feilretting Tyngre adm Monitorering 3.linje Konfigurering Systemdesign Dyp feilsøking Sys.analyse Strategiarbeid Merk at det er ikke noe magisk med akkurat tre nivåer. Det er de som har flere nivåer, men tre er vanlig. Enkelte opererer også med hybridnivåer, som Runits halvannende Linje. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

46 TDT4285 Planl&drift IT-syst
Våren 2004 Hvorfor linjedeling Ikke bruke høy kompetanse på småting Skalerbarhet Lokal karrierevei Organisatorisk sporbarhet av ansvar Styringsmulighet (top-down) Avpersonalisere arbeidet Muliggjør ’single point of entry’ Med å bruke kompetanse rett: at de mest kompetente lager noe som de mindre kompetente kan drive videre. Dette forutsetter organisering. I motsatt fall blir en flink person hengende med historisk support på de han har laget. Med organisatorisk sporbarhet av ansvar menes at man ikke skal måtte løpe rundt og finne ’rette’ vedkommende, men kunne forholde seg til en sjef – som har ansvaret, selv om det er en under ham som praktisk utfører oppgaven. Det vil si det motsatte av ansvarspulverisering. Med å avpersonalisere arbeidet menes at det skal anonymiseres, slik at en person kan erstatte en annen – så man ikke er avhengig av en bestemt person på middels eller lang sikt. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

47 Dokumentasjon og rutiner
1.linje: utfører spesifiserte, forhåndsdefinerte rutiner. 2.linje: utfører ikke-dokumenterte oppgaver innenfor et dokumentert system. 3.linje: endrer system og dokumentasjon i parallell. Våren 2004 TDT4285 Planl&drift IT-syst

48 1.Linjes oppgaver (rutiner)
TDT4285 Planl&drift IT-syst Våren 2004 1.Linjes oppgaver (rutiner) Kart ...bruker kartet som turguide, og utfører rutiner som er definert på forhånd. Rutine-samling Rutiner Kroneksempelet er bytte av backuptaper. 1.linje Terreng Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

49 2.Linjes oppgaver (drift)
TDT4285 Planl&drift IT-syst Våren 2004 2.Linjes oppgaver (drift) Med feil ...med kartet som referanse: retter terrenget der det er ’galt’, samt utfører oppgaver som ikke er formulert som rutiner Kart’ Retting Feilsituasjon Feilretting Kroneksemplene er installasjon av enda en terminaltjener, eller retting av at en disk har krasjet. 2.linje Operasjon Endringer innen samme kart Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

50 3.Linjes oppgaver (prosjekt)
...utvikling av systemet; endring av kart og terrreng i parallell. Kart Kart’ Stor endring Stor endring Terreng Våren 2004 TDT4285 Planl&drift IT-syst

51 Prosjekt, rutiner og drift
3.linje Med feil Prosjekt Kart Kart’ Stor endring Rutine-samling Retting Feilsituasjon Rutiner Feilretting Stor endring 2.linje 1.linje Terreng Operasjon Endringer innen samme kart Våren 2004 TDT4285 Planl&drift IT-syst

52 Arbeidsfokus og erstattbarhet
TDT4285 Planl&drift IT-syst Våren 2004 Arbeidsfokus og erstattbarhet På lang sikt 3.linje Erstatt- barhet 2.linje 1.linje På kort sikt Kan også si veldig forenklet at 1.linje har kort tidshorisont og kan erstattes raskt (dersom systemet er satt godt opp og er veldokumentert!). De kan derfor avlønnes lavt og hentes ’fra gata’ på kort varsel – men man kan ikke klare seg lenge uten dem! Motsatt har 3.linje veldig lang tidshorisont. Det tar lang tid å trene dem opp, fordi de har mye historisk innsikt og mye kunnskap som ikke er detaljdokumentert, samt forståelse av hvordan systemet er satt sammen. Du ønsker ikke å miste dem. På kort sikt På lang sikt Avhengighet/arbeidsfokus Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

53 TDT4285 Planl&drift IT-syst
Våren 2004 Eksempler på oppgaver Skifte passord (1) Restore slettede filer (1) Manglende toner (1) Ingen utskrift (1+2) Nettet er tregt (1+2+3) Installere ISDN på bærbar (2) Nytt backupsystem (3) Merk at dette er omtrentlige plasseringer! Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

54 Kontinuerlig forbedring
Analysere Prioriteringsplan Loggdata Monitorere Konstruere 3.linje 1-2.linje Igangsette Installerbart system Kjørende system Våren 2004 TDT4285 Planl&drift IT-syst

55 Helter og teammedarbeidere
TDT4285 Planl&drift IT-syst Våren 2004 Helter og teammedarbeidere Heltemodellen Teammodellen Tett kom- munikasjon Formelle kanaler Kort om- stillingstid Konsistent Fordeler Bruker- nærhet Profesjonell avstand Form- fasthet Eierfølelse Det er et mål at man unngår å jage rundt og rundt i dette diagrammet. Refererer til Dilbert-stripa tidligere. Ta de lyseblå som eksempel, deretter de gule. Ugjennom- trengelig Tidsfor- sinkelse Vagt og ullent Byråkratisk Ulemper Avstand, upersonlig Personal- utskiftning Utbrenthet Person- avhengig Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

56 TDT4285 Planl&drift IT-syst
Arbeidstitler 1.linje: systemoperatør, operatør 2.linje: systemadministrator 3.linje: systemarkitekt, systemanalysator, systemintegrator Våren 2004 TDT4285 Planl&drift IT-syst

57 ”Single point of entry”
TDT4285 Planl&drift IT-syst Våren 2004 ”Single point of entry” Brukere Alle henvendelser fra brukerne skal gå igjennom et ’call-center’. 1.linje Helpdesk Operatør Problemer og farer med dette er blant annet: Lang og tungrodd vei for ekspertbrukere som egentlig trenger (og bør!) snakke direkte med 3.linje. Helpdesk kan komme i en feilelimineringsmodus, ikke i en feilløsningsmodus. Personene på 3.linje mister bakkekontakten med hva brukeren trenger. Anekdote om hvordan Digital ’løste’ problemet med at DecTerm kunne skrive over passordfila. Moral: helpdesk fungerte ikke når brukeren ringte for å hjelpe helpdesk. Kommer tilbake til helpdesk senere. 2.linje 3.linje Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

58 TDT4285 Planl&drift IT-syst
Våren 2004 Hvorfor ’SPOE’ Motvirke dobbeltrapportering Koordinere innsats Gi bedre oversikt og utestående oppg Skjerme mot avbrytelser Lette prioritering Sikre tilbakemelding til bruker En annen – sleip – begrunnelse kan være å gjøre det frustrerende for brukeren å ta ut support; slik at kjekt-å-ha-spørsmålene blir filtrert bort av selv selv. Dersom du lider når du står i supportkø, så stiller du ikke spørsmål i tide og utide! Fare: at en Single point of failure blir en lynavleder der spørsmål og problemer blir sporet inn og aldri håndtert. Nær slektning av helpdesk og ticketsystemer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

59 TDT4285 Planl&drift IT-syst
Våren 2004 Modifiserte modeller Kortslutning: Helpdesk videreformidler kontakt mellom bruker og saksbehandler i stedet for å være filter. Dynamisk 1-2.linje: Enkelte personer veksler mellom 1. og 2. linje avhengig av pågang og arbeidsmengde. Kortslutning bør bare gjøres når det er sannsynlig at ikke 2-3.linje trenger å skjermes fra brukeren, og der kommunikasjon direkte er bedre/enklere/sikrere enn å gå igjennom en helpdesk. Merk at det er en fin linje mellom kortslutning og ’dumping’. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

60 Linjedeling som roller
TDT4285 Planl&drift IT-syst Våren 2004 Linjedeling som roller Vanlig med tidsmultipleksing Hyppig (timer) Middels (dager) Langvarig (uker) En person kan ha roller på ulike linjer for ulike delområder (matriseorganisasjon) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

61 TDT4285 Planl&drift IT-syst
Hvorfor? Driftsorganisasjonen må kunne skaleres på samme måte som datasystemet og brukermassen Kommunikasjonen med brukerne blir professjonalisert gjennom et single point of entry Endringer håndteres gjennom en strukturert og målrettet prosess. Våren 2004 TDT4285 Planl&drift IT-syst

62 TDT4285 Planl&drift IT-syst
Våren 2004 Klienter TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Kommer til å si mindre om DHCP. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

63 TDT4285 Planl&drift IT-syst
Våren 2004 Hva er en klient? Andre maskiner er ikke avhengig av den Ingen/få viktige persistente data Få brukere er avhengig av den Typisk arbeidsplass Typisk en-av-mange maskin Avhengig av tjenere Hva skiller en klient fra en tjener? Merk at det finnes maskiner som er i en gråsone, og som ikke er ’ren’ klient eller ’ren’ tjener etter disse definisjonene. Eksempelvis er en bærbar ikke en ren klient, for den har presistente data, og heller ikke en hjemmemaskin, som neppe er en av mange like. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

64 TDT4285 Planl&drift IT-syst
Våren 2004 Evards livssyklus Rebuild New Update Build Entropy Unknown Clean Config’d Viktig å forstå denne modellen som en grov modell. Det er også endel transisjoner som ikke er intuitive. Build er bygging av OS, mens Initialize er konfigurering til lokale forhold. Dermed blir rebuild en lokal reinstallering. Det beste eksemplet er kanskje bærbare, der en rebuild kan være en tung operasjon. Det er også for grovt å dele inn i Unknown og Configured, for det er en lang gråsone i mellom dem. Det viktigste med modellen er å vise de ulike operasjonene, som har ulike mål: Update oppdaterer en fungerende maskin, og er massivt parallelt i sin natur, fordi ’alle’ maskinene skal oppdateres samtidig. Dermed må det automatiseres parallelt. Initialize vil i mindre grad kreve parallellisering, men fordrer allikevel stor grad av automatisering, dels fordi det er mulig/ønskelig (fra et økonomisk og tidsmessig synspunkt) og dels fordi det er den beste måten å sikre konsistens på. Debugging er i sin natur one-of-a-kind og kan ikke automatiseres (selv om prosessen bak debugging i noen grad kan formaliseres og standardiseres; samt at enkelte operasjoner gjentas såvidt ofte at de kan optimaliseres og delautomatiseres.) Siste utvei til debugging er en rebuild. Debug Initialize Retire Off Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

65 Build kontra Initialize
TDT4285 Planl&drift IT-syst Våren 2004 Build kontra Initialize Build-operasjonen: Innlegging av standard operativsystem Er lik for alle maskiner av samme platform Initialize-operasjonen: Tilpasser maskinen til brukes spesifikke behov Utfører (oftest) de siste feilrettingene Utfører maskinspesifikke tilpassinger Disse skaper endel forvirring. Generelt inneholder build det som operativsystemet kommer med som default, mens initialize inneholder det som kreves av lokale tilpassinger, inklusive oppdateringer av de aller siste patchene. Det er et spørsmål om leverandøren kan levere ferdig installerte systemer, f.eks ved å speile et disk-image ved bygging av maskin. Dette skaper et oppdateringsbehov, da leverandørs disk-image stadig må oppdateres. Et kompromiss kan være å la leverandør installere et basissystem som tar maskinen tilstrekkelig opp på det lokale nettet til at resten av den (fullt oppdaterte) installasjonen kan sluttføres. Merk at det er problemer med sikkerhetspatcher. Historie om hvordan Windowsmaskiner blir tatt mellom installasjon av 1.0-utgaven av et OS og slutten av installasjonen der maskinen blir patchet opp. Dette er dog blitt bedre i senere utgaver. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

66 Forfatterens hovedbudskap
TDT4285 Planl&drift IT-syst Våren 2004 Forfatterens hovedbudskap Tre viktige ting med klienter: Automatisere installasjon Håndtere oppdateringer Konfigurere nettverksparametre Dette er kanskje litt forenkelt. Det kommer i alle fall feilsøking med i bildet. Det er relevant ifm systemer der bruker har ”store” rettigheter på maskinen, så som ofte er tilfelle med windows og lokalt installerte maskiner (endog maskiner med lokal administrator). Derimot, dersom maskinen ikke er noe ”spesiell” for brukeren, så blir dette som står over mer korrekt. I tillegg kommer selvfølgelig hardware, sikkerhet, monitorering, brukerstøtte etc Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

67 Automatisere? Effektivitetsgrunner
TDT4285 Planl&drift IT-syst Våren 2004 Automatisere? Effektivitetsgrunner Tillater at man kan utføre raske endringer Utrulling må ikke være hinder for nødvendige oppdateringer Erstatter feilsøking på en kostnadseffektiv måte. Tillater å parallellisere mange maskiner Kan bruke arb.kraft med mindre erfaring Effektivisering er et område med sterk fokus innen drift, spesielt siden drift i stor grad i bunn og grunn er en administrativ overhead. Uansett ønsker man å fase ut eller effektivisere bort de operasjonene som dette er mulig for. En historie fra Intro-salene: I utgangspunktet var en reinstallasjon en halv ukes arbeid. Dermed ble det også til at reinstallasjon var noe som ble dyttet fremover i tid dersom det var mulig. ’Nei, vi kan ikke ta en halv uke til det nå, vi får vente til påske-reinstallasjonen’. Etter at vi fikk helautomatisert det, slik at reinstallasjon tok 2-3 timer for en person, er det blitt mer vanlig å gjøre en reinstallasjon en formiddag på halvdelen av maskinene. (Og selvfølgelig, etter at vi fikk tynne klienter har behovet i stor grad falt bort.) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

68 Automatisere? Konsistensen
TDT4285 Planl&drift IT-syst Våren 2004 Automatisere? Konsistensen Brukerne kjenner seg igjen fra maskin til maskin. Fjerne slurvefeil (især sent om natta) Kan være trygge på at alt er konsistent Minsker holdningen om reinstaller-for-å-fjerne-feilen. Konsistensen hjelper på mange områder. Det som kanskje er viktigst er at dersom maskinene er like, slipper man å holde rede på lokale særegenheter og spesialiteter. Det særegne er ikke nødvendigvis dårligere – kanskje tvert om – men det øker kostnadene å holde oversikt over, og dersom man skal drive det felles blir kostnadene høyere. Eksempler er lokaltid, som i Norge eksisterte til toget og telegrafen kom – og så ble det uhåndterlig. En annen ting var de ulike mål og vekt og penger som fantes i Tyskland før samlingen på 1800-tallet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

69 Automatisering? Kvalitetsgrunnene
TDT4285 Planl&drift IT-syst Våren 2004 Automatisering? Kvalitetsgrunnene Prosessen er iboende ”dokumentert” Automatiserte prosesser er repeterbare Setter en baseline for hvordan ting gjøres Muliggjør review av fremgangsmåte fra andre parter Det er selvfølgelig feil å si at en automatisert prosess er dokumentert. Men man har laget en ’baseline’, en rettesnor å måle installasjoner etter. Det vil si at man opphøyer ett resultat til ’rett’ og ett annet resultat til ’feil’ – selv om det skulle fungere for brukeren. Det essensielle her er at automatikken gir konsistens, som muliggjøre repeterbarhet og rekonstruksjon. Dermed kan man bruke review og audit på prosessene for å forbedre resultatet. Uten dette, ville prosessen være ad hoc, med forskjeller fra maskin til maskin – noe som stjeler oppmerksomhet idet man må holde styr på mange ulike varianter. At det ikke trenger å være problematisk at alt utstyret er forskjellig konfigurert kan f.eks snekre vise. De opererer sjelden på ’like hus’, men de har kunnskaper som går på snekring og materialbruk generelt, og ikke på det enkelte hus plantegning spesielt. Likevel har de en viss grad av standardisering gjennom ’norsk’ byggeskikk. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

70 Fundamentalistisk automatisering
TDT4285 Planl&drift IT-syst Våren 2004 Fundamentalistisk automatisering All interaksjon skal skje i starten! Fornuftige defaultverdier skal tilbys der det er mulig (evt arve fra gml inst) Absolutt ALT må automatiseres Basisinfo skal være kunne være inkonsistent Automatiseringen må testes – tilstrekkelig! Forfatterens budskap på en LISA var ’automize, automize, automize’. Det er ikke hensiktsmessig å delautomatisere. Det er som med løvetann, inntil du får bort alt, er enhver effekt bare delvis og temporær. Det er viktig at man får bort alt, og at man ikke ’hviler’ på en 99% løsning. Ved en reinstallasjon vil det være interessant å arve endel verdier fra tidligere installasjon, der kroneksemplet er private keys og setting av hostnavn og evt IP-adresse. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

71 TDT4285 Planl&drift IT-syst
Våren 2004 Hva lager entropi? ”Tidens tann” eller bit-råte Lokale systemadministratorer Dårlig sikkerhet mot innbrudd Ustabil/dårlig testet programvare Manglende minnebeskyttelse (win95/98) Veldig variabel bruk OS-bugs og uflaks Akkurat som entropien er kaotisk, må feilsøkingen være ’kreativ’ og uforutsigbar. Det er vanskelig å vite hvorhen du ender når du starter på å feilsøke et problem. Den beste sikringen mot entropi er et system som ikke lar seg endre (eller konfigurere). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

72 The four holy Rs of brute force
TDT4285 Planl&drift IT-syst Våren 2004 The four holy Rs of brute force Retry Restart Reboot Her passer det med historien til Borud om servicemannen som forsøkte å følge oppskriften, om igjen og om igjen, helt til Borud skrev ’cd ..’ i et ubevoktet øyeblikk, slik at det virket. Reinstall Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

73 Debugge eller gjenbygge
TDT4285 Planl&drift IT-syst Våren 2004 Debugge eller gjenbygge Sikkerhetsrelaterte problemer. Gjennomgående feil Alvorlige feil Dersom du ønsker å forstå sammenheng Debugge Hurtighet er viktig Viktig at ting er likt Har vært på utlån Motvirke ”tidens tann” Gjenoppbygge Knytte dette til evant livssyklus, dette er det to måtene å komme ut av unknown-tilstanden på, og angir motivasjonen for å velge den ene fremfor den andre. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

74 Hvordan utføre etterkontroll?
TDT4285 Planl&drift IT-syst Våren 2004 Hvordan utføre etterkontroll? Nullalternativ: ignorer Monitorere bruken av maskinen en periode Stikke innom og sjekke den manuelt La installasjonen utføre en egen ettertest og melde ifra om resultatet Be om tilbakemelding fra første bruker Problemstilling: ’Det virker fordi jeg har gjort det’. ... Mens realitetene er at det virker fordi det er testet ... Og dobbelttestet. Men likevel er et av hovedkonseptene i mange systemer for å både effektivisere og styrke kvaliteten at man ikke skal teste, men utføre rett i utgangspunktet. Det er en iboende motsetning her: testing er noe man gjør fordi man ikke stoler på utførelsen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

75 TDT4285 Planl&drift IT-syst
Våren 2004 Platformer En platform er en kombinasjon av hardware, software, bruksmønster, konfigurasjon, sikkerhet, operativsystem, plassering, eierskap, brukerstøtte eller annet som måtte fordre at maskinene av denne platformen må praktisk håndteres forskjellig fra andre maskiner av andre platformer. Platform er vanskelig å eksakt og godt definere. Det beste er vel å si at dersom du føler behov for å drive to grupper datamaskiner hver for seg, så har du identifisert et mulig skille mellom to platformer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

76 Platform kontra variant
TDT4285 Planl&drift IT-syst Våren 2004 Platform kontra variant Platformer Dyptgående forskjeller Drives mer eller mindre separat Lite stordrift annet enn kunnskapsgjenbruk Varianter Små/mellomstore forskjeller Maskinene drives som ett anlegg Kan enkelt ta ut stordriftsfordeler Platformer krever skille mellom systemer, mens varianter kan bygges inn og håndteres innenfor en enkelt platform. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

77 Tommelfingerregler om platformer
TDT4285 Planl&drift IT-syst Våren 2004 Tommelfingerregler om platformer To er ”dobbelt” så dyrt som en Priorter noen få (first class citizens) Forsøk variantbegrensning Forsøk å kollapse to plattformer til varianter av samme platform Variantbegrensning er ikke alltid like lett, og kolliderer ofte med brukernes ønske om det siste, det beste og det som paser dem personlig. Ofte må man velge det minste felles multiplum (som ingen er fornøyd med) eller man må velge luksusløsninger som tilfredsstiller alle. Å velge fellesløsninger er ofte fordyrende – noe som må måles opp mot innsparelsene man får ved å kunne effektiviseres. Vanskeligere å variantbegrense ”personlig” utstyr som bærbare enn kontormaskiner. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

78 Konfigurerbarhet og automatikk
TDT4285 Planl&drift IT-syst Våren 2004 Konfigurerbarhet og automatikk Helmanuell installering Billig Automatisk installering Gjenbruk- barhet Kloning Merk at automatisk installering kan være skriptbasert eller tilstandsbasert, eller (som er mest vanlig) en hybridløsning et sted imellom de to. Avspilling av tasttrykk Kostbart Liten Stor Automatikk Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

79 TDT4285 Planl&drift IT-syst
Våren 2004 Speiling/kloning Fordel fordi: Enkelt å vedlikehold en golden host Unngår endel problemer fordi ukomplekst Ulempe fordi: Tenderer mot svært mange platformer Må kanskje velge gammel hardware Ender med tallrike spesialtilfeller Den typiske speilingen er med ghost. Det som er vanlig er at man har ett image pr hardwareplatform. Det er ikke uvanlig at organisasjoner som bruker speiling har en svært streng variantbegrensning, med kjøp av en enkelt modell i opptil et halvt år om gangen. Ved overgang til speiling er det gjerne utfasing av svært mange av maskinene. Mitt personlige syn på speiling er at det er en for grov teknikk, og at den allikevel ikke løser alle problemene, slik at man ender opp med manuelt speilede systemer uansett. Speiling brukes også til backup og i sikkerhetssammenheng (ta kopier for arkiv). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

80 Automatiserte oppsett
TDT4285 Planl&drift IT-syst Våren 2004 Automatiserte oppsett Fordel fordi: Svært konfigurerbart/tilpassningsdyktig Omfattende operasjon, dvs tester maskinen Relativt lett å vedlikeholde mange varianter Ulempe fordi: Maksimal kompleksitet Krever mye arbeid og kompetanse Dette er kanskje den mest omfattende angrepsvinkelen, men det er også den mest fleksible. Dersom du allikevel trenger kompetansen som skal til, er det ”billig” å bruke den på å lage et automatisert installasjonsoppsett. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

81 Forhåndslastet oppsett
TDT4285 Planl&drift IT-syst Våren 2004 Forhåndslastet oppsett Fordel fordi: Slipper å gjøre det selv Kort leveringstid til sluttbruker Leverandørs ansvar i tilfelle problemer Ulempe fordi: Vanskelig å gjenskape Ømtålelig for endringer i leverandørs oppsett Skaper ofte trøbbel med drivere Typisk eksempel: bærbare med sære drivere for spesialkonstruert hardware. Typisk finner du dem (kanskje?) på nettet. Uansett ønsker du oppdateringer, og det betyr å bytte ut med siste versjon. Dette er oppgaver som gjerne dyttes på yngstemann i driftsgruppa(!) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

82 TDT4285 Planl&drift IT-syst
Oppdateringer En oppdatering er en målrettet endring på en allerede installert og brukbar maskin, og omfatter typisk sikkerhetsmessige, stabillitetssikrende eller funksjonalitetsutvidende endringer. Våren 2004 TDT4285 Planl&drift IT-syst

83 Spesielt for oppgraderinger
TDT4285 Planl&drift IT-syst Våren 2004 Spesielt for oppgraderinger Antar at maskinen er brukbar Må ikke overforbruke nett el.l Skal ikke trenge fysisk tilgang Bruker forventer en virkende maskin Maskinen kan være i aktiv bruk Maskinen kan ha sære variasjoner Maskinen kan være av nett Maskinen kan ha dual boot Noe av dette er iboende for klienter, mens andre ting er iboende for oppdateringer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

84 TDT4285 Planl&drift IT-syst
Våren 2004 Utrullingsmetodikk Også kalt ”one-some-many” Test på en utviklingsmaskin – flere ganger Test på en testmaskin Korriger og gå tilbake til pkt 1 hvis nye feil Test på ca 50% flere maskiner Repeter forrige to punkt til alle er dekket Denne strategien kan egentlig brukes på alt som skal rulles ut. Basis for den er at du skal teste, dobbeltteste og trippellteste, og man bruker utrulling i liten skala som test-case. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

85 TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI
Tjenermaskiner TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst

86 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon En tjener er en datamaskin på hvilken tjenester som brukes av brukere eller andre maskin er implementert, slik at andre i større eller mindre grad er avhengig av tjenermaskinen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

87 Hva skiller klienter og tjenere?
TDT4285 Planl&drift IT-syst Våren 2004 Hva skiller klienter og tjenere? Avhengighet; andre maskiner og brukere er avhengig av den Kostnader; typisk større kostnader i innkjøp og i drift Konfigurasjon; annerledes konfigurert en den vanlige klientmaskinen Bruk; yter normalt felles tjenester Tjener er dyrere, større, viktigere, tyngre og coolere. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

88 TDT4285 Planl&drift IT-syst
Våren 2004 Valg av maskinvare ”Standard” hyllevare Billig! Spesiell tjener-maskinvare Pålitelig og med høy kvalitet Redundante løsninger Overvåkningsmuligheter Feilkorrigering Feildetektering og evt –korrigering på minne. Kan trekke sammenligning til pariet med en paritetsbit for enkeltfeildeteksjon, og to paritetsbits for enkeltfeilkorrigering og dobbeltfeildeteksjon. Doble strømforsyninger Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

89 Momenter ved maskinvalg
TDT4285 Planl&drift IT-syst Våren 2004 Momenter ved maskinvalg Romslig utvidbar kasse Kraftige CPU’er Høy I/O-ytelse Støtte for utvidelse/oppgrad Monterbar i 19’’ rack Tilgang fra bakside Enkle Kan stables i høyden Kompakte Ikke spesielt utvidbare Støtte for fjerndrift To typer maskiner, som tilsvarer to ulike tilnærmingsmåter for maskinene: alle tjenester på en enkelt maskin, eller tjenestene spredd utover mange maskiner med en tjeneste pr maskin. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

90 Vedlikeholdskontrakter
TDT4285 Planl&drift IT-syst Våren 2004 Vedlikeholdskontrakter Pris; kontra hva det koster være uten Responstid; for påbegynt service Eskalering; hvis resultatløst Onsite/offsite; kommer de til deg? Reservedeler; hvem holder/betaler Låne-ordninger; hva gjør du imens? Sammenligne vedlikehold og garanti og forsikring. Studentene kjenner sikkert siste, men vedlikehold betyr at du får løpende oppdateringer av programvare, og at du kan ringe noen direkte dersom noe er galt (men da begynner potensielt taksameteret å løpe). Kan også kontrasteres mot reklamasjon, men dette kommer vel igjen ifm merkantile emner og materialadministrasjon. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

91 Vedlikeholdstrategier
TDT4285 Planl&drift IT-syst Våren 2004 Vedlikeholdstrategier Overkapasitet; etterbestilling av deler Reservedeler; noen enkeltdeler Reservekits; nesten komplett innmat Reservemaskiner; komplette Nærboende tekniker; løpende kontakt Resident tekniker; kontor hos deg Out-sourcing; sette bort hele jobben Merk at det ikke er tatt med noe om nulløsningen, som er å ignorere problemet, og handle reaktivt dersom noe skulle skje. Fortell om Cray-maskinen i 1985, som kom med to amerikanske teknikere, et godt eksempel på en resident tekniker. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

92 Reaktiv og proaktiv vedlikehold
TDT4285 Planl&drift IT-syst Våren 2004 Reaktiv og proaktiv vedlikehold Reaktivt Servicekontakt Reservedeler Garantiordninger Etterbestille deler Reservemaskin Backup/restore Proaktivt Overkapasitet Planlagt utfasing Automatisk failover Monitorering Redundans Diskspeiling Husk at reaktiv og proaktiv er to ulike paradigmer – to måter å se verden på. Det er ikke gitt at den ene er gal og den andre korrekt, de er bare forskjellige. Kan kanskje fortelle om lyspærer og hvordan man gjør det i ganger og auditorier. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

93 TDT4285 Planl&drift IT-syst
Våren 2004 Sikkerhetmodell tj4 tj1 tj2 tj3 Tjenere må settes sikrere enn andre maskiner. Et innbrudd på en tjener brer seg raskt til å bli et innbrudd på svært mange maskiner. Fortell om innbruddet på NTNU i januar 2003, som gikk i flere måneder før de fikk tilgang til en tjener, og deretter var de ute på hundrevis av maskiner i løpet av dager og uker. Viktige maskiner Kontormaskiner Eksterne maskiner Hjemmemaskiner Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

94 TDT4285 Planl&drift IT-syst
Våren 2004 Momenter ifm tjenere Backup; inneholder viktige data Plassering; ergonomi, kjøling, strøm, nett OS-valg; må være tilpasset bruken Fjerndrift; konsolltjenere Adgang; begrenset for uvedkommende Hotswap; HW-endringer under kjøring Kan fortelle om Novell, som er klassisk eksempel på et nett-operativsystem som har forskjellig tjener og klient. Andre eksempler er tynne klienter og terminaltjenere, og endog gamle stormaskiner. Mht fjerndrift er det relevant å fortelle om store konsollkonsentratorbokser. Hotswap: fortell om Cray’en som ikke ble bootet av Dispen på ca 2 år. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

95 Harddisker – servicestrategier
Monitorere loggdata Tidvis speiling av viktige data Kontinuerlig speiling RAID-løsninger med feiltoleranse Backup Våren 2004 TDT4285 Planl&drift IT-syst

96 Spesialtjenere (server appliances)
TDT4285 Planl&drift IT-syst Våren 2004 Spesialtjenere (server appliances) Fordeler: Spesialkonfigurasjon Fintunet til bestemt oppgave Frigjør tid (fra å konfigurere egne spesialmaskiner) Lite ekstra funksjonalitet/kompleksitet Ulemper: Øker antall platformer Andre usikkerhetsmomenter er kompatibilitet og muligheter for service og oppdatering i fremtiden. Fortell om HP, som ville selge oss et oscilloskop som inkluderte en HP/UX-boks, og på forespørsel om sikkerheten på boksen svarte de at ’dere kan jo sette et passord’. Boksen kom med tomt passord, for den stod jo vanligvis for seg selv uten noen kontakt med omverdenen, og i alle fall stod den på en lab langt bak en brannmur. Vi ville putte den rett på nettet for å kunne bruke en skriver. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

97 TDT4285 Planl&drift IT-syst
Våren 2004 Redundans Følgende dimensjoner finnes: Kapasitet: ibruk/ekstra – speilende – av Aktivisering: manuell – automatisk Bytting: hotswap – reset – slå-av Toleranse: enkeltfeil – dobbeltfeil – etc Nevn N+1-redundans og N+2-redundans og full (2N-redundans) Merk at en betingelse for redundans er a) hotswap (ellers kan ikke feilende enheter byttes) og b) at noen monitorerer, slik at feilende enheter faktisk blir byttet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

98 Standard, billige tjenere
Bruk og kast dem Redundans erstatter kvalitet Fungerer greitt til CPU, men ikke I/O Prisdifferansen minsker etterhvert Våren 2004 TDT4285 Planl&drift IT-syst

99 TDT4285 Planl&drift IT-syst
Våren 2004 Tjenester TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

100 TDT4285 Planl&drift IT-syst
Definisjon Tjenester er kontinuerlig kjørende programmer som tilbyr en standardisert funksjonalitet, basert på en protokoll, overfor brukere eller klientprogrammer, ofte over nettverk. Våren 2004 TDT4285 Planl&drift IT-syst

101 Eksempler på tjenester
DNS – navnetjenester Lpd – utskrift over nettet DHCP – fildeling og utskrift fra Windows NIS – autorisasjon og annet Web-tjener Ftp – deling av filer over nettet Våren 2004 TDT4285 Planl&drift IT-syst

102 TDT4285 Planl&drift IT-syst
I dette kapitlet Brukers/kundes/SAs behov Arkitekturvalg Pålitelighet og kompleksitet Navnevalg Skalerbarhet Monitorering Brukerstøtte Våren 2004 TDT4285 Planl&drift IT-syst

103 Samle data om brukers behov
Hvordan skal det brukes Viktig vs nyttig funksjonalitet Hvem er brukerne Hvor kritisk er funksjonaliteten Behov for tilgjengelighet Behov for support Våren 2004 TDT4285 Planl&drift IT-syst

104 TDT4285 Planl&drift IT-syst
Behov for en SLA? Liste tjenester Spesifisere hver tjenestes nivå Tilgjengelighet Ytelse Brukersupport Reponstid for ulike problemer Eskaleringsregler Bøter, priser, ekstra arbeid Våren 2004 TDT4285 Planl&drift IT-syst

105 TDT4285 Planl&drift IT-syst
Operative behov Administrative grensesnitt Interoperabilitet og integrerbarehet Skalerbarhet Oppgraderbarhet Implementerbarhet av pålitelighet Nettverk (latenstid og båndbredde) Budsjettering Våren 2004 TDT4285 Planl&drift IT-syst

106 TDT4285 Planl&drift IT-syst
Arkitekturvalg Protokoll Oppgrad Kommite Dynamisk Statisk Kompati- bilitet Utvidelser Produkt Våren 2004 TDT4285 Planl&drift IT-syst

107 Kompleksitet og pålitelighet
Funksjon- alitet Brukers behov? Bugs (pålitelighet) Bredde i bruk Våren 2004 TDT4285 Planl&drift IT-syst

108 TDT4285 Planl&drift IT-syst
Navnevalg s/n zevs.idi.ntnu.no mail.idi.ntnu.no Hardware- navn Maskin- navn Generiske navn Tung rekonfig Enkel dynamikk Våren 2004 TDT4285 Planl&drift IT-syst

109 Plassering av tjenestemaskiner
Plassering på maskinrom Sikring mot innbrudd og tyveri Bedre nettverkstilgang Synliggjøre avhengighetene UPS, kjøling og annen infrastruktur Plassering på kontor Bekvemmelig Billig Våren 2004 TDT4285 Planl&drift IT-syst

110 TDT4285 Planl&drift IT-syst
Fjerninnlogging Mulig innlogging Dvs minst mulig fjerninnlogging på tjenestemaskiner Aktiviserer ”bugs” Avlytting? ”Støy” Aktivitet Kompleks bruk Fyller loggene Våren 2004 TDT4285 Planl&drift IT-syst

111 En eller flere tjenestemaskiner
En tjener per service Gir en enkel situasjon på hver maskin Men kan ligge på samme hvis tett kobling HW er en del av tjenesten En tjener for alt Spesielt for duplikate tjenester Gir færre maskiner Kan følge regionale/organisastorisk grenser Våren 2004 TDT4285 Planl&drift IT-syst

112 TDT4285 Planl&drift IT-syst
Våren 2004 Ytelsesplanlegging Estimer ressursbruk (initielt og full bruk) Test for å kunne estimere skalering Skaff nok ressurser Skaff nok kompetanse Gjør det skikkelig fra starten! Tenk på flyplassen i Denver og baggasjekaoset der. Fortell om billettbestilling på posten, der alle plutselig skal ha samm billetten (har lagt i sovepose utenfor i dager) og så skal alle logge inn på samme tjeneren samtidig. Da spørs det om systemeier har spek’et systemet rett. Mulig at man kan trekke paralleller til et elektronisk valg, der mange ikke fikk stemt, fordi man ikke hadde tatt høyde for at så mange kom på en gang. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

113 TDT4285 Planl&drift IT-syst
Monitorering Monitorer for følgende: Snikende ytelsesdegradering Tilgjengelighet Alvorlige feilmeldinger Kapasitetsproblemer Brukers subjektive oppfatning Omfang og mønster av bruk Våren 2004 TDT4285 Planl&drift IT-syst

114 TDT4285 Planl&drift IT-syst
Tjenesteutrulling Gjør det rett første gang (førsteinntrykk) Ha ekstra ressurser i starten Rull ut litt om gangen (hvis mulig) Gjør utrulling sømfri hvis mulig Ta ned gamle løsninger pent Overlever til drift Fullfør (eller avvikle) utrullingen! Våren 2004 TDT4285 Planl&drift IT-syst

115 Feller ifm skalerbarhet
Inkrementell utvikling istedetfor inkr. utrulling Manglende ressursutnyttelse For lite ressurser For lite utvidbarhet Våren 2004 TDT4285 Planl&drift IT-syst

116 Overfasing til ny maskin
Begge tjenester operative en stund Gammel tjeneste Ny tjeneste Monitorering Bruker Våren 2004 TDT4285 Planl&drift IT-syst

117 TDT4285 Planl&drift IT-syst
Avhengigheter Tjeneste som mest avhenger av: DNS Tjeneste som flest av henger av (bl.a): Utskrift Fildeling Kjenn til avhengighetene! Våren 2004 TDT4285 Planl&drift IT-syst

118 Statisk dokumentasjon
TDT4285 Planl&drift IT-syst Våren 2004 Statisk dokumentasjon TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Med statisk dokumentasjon menes den dokumentasjonen som koeksisterer med det eksisterende systemet. Det omfatter ikke dokumentasjon som produseres ifm en endringsprosess. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

119 TDT4285 Planl&drift IT-syst
Våren 2004 Hva er dokumentasjon? Forklaring av systemet? Blueprint for systemet? Infrastruktur for komm. mellom sysadmins? Byråkratisk herk og evig stilskriving? System Implementerer Forklarer Viktig: mellom de to første, er det systemet eller dok’en som er ’rett’? Og for nr 3, er dok en del av systemet, eller er det et verktøy for operasjoner på systemet? Dok Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

120 TDT4285 Planl&drift IT-syst
Våren 2004 Målsetting Formidle kunnskap mellom sysadmins (kommunikasjon) Sette et utgangspunkt for systemet (endringshåndtering) Felles referansepunkt for samarbeid (skalering) Målet med god dokumentasjon er å kommunisere med andre/kolleger og med seg selv, i nåtid og fremover, slik at man formidler forståelse for og innsikt i de valgte løsningene. Viktig her å få med referanse til review og audit og relatere det til tredje punkt. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

121 Dokumentasjonsfeller
TDT4285 Planl&drift IT-syst Våren 2004 Dokumentasjonsfeller Read-write-forhold. At alle dokumenterer på hvert sitt vis Dårlig dok blir ansvarsfraskriving Å tro at ”dette husker vi, dere ...” Å dokumentere uten en bruksplan Å skrive dokumentasjonen etterpå. Med read-write-forhold menes hvor mange ganger leser man det man skriver. Her kan diplomer og doktoroppgaver være et eksempel, de leses kanskje i gjennomsnitt av 1,5 personer utover forfatteren selv. Anekdote: Hjemme har jeg silo overflow på serieport. Jeg fikk fikset det tidligere, men jeg glemte å dokumentere hva jeg gjorde. Etter oppgradering er det kommet tilbake, og nå vet jeg ikke hvordan jeg skal bli kvitt det igjen. Brukte noen timer forrige gang, og regnet med at jeg ville huske det dersom det ble bruk for det igjen. Når det gjelder bruksplan, kan det sammenlignes med å bygge hus. Ingen bygger et hus uten en plan for hvordan det skal brukes. Eksempelvis kan man nevne OL på Lillehammer, der bygningene i OL hadde etterbruksplaner for hvordan de skulle benyttes etter OL. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

122 Dimensjoner å måle dok etter
TDT4285 Planl&drift IT-syst Våren 2004 Dimensjoner å måle dok etter Endringsrate (ggr pr tidsenhet) Endringsvolum (% pr endring) Lokalitet (% lokal info) Spesifiserthet (rutineliste vs oversikt) Brukshyppighet (daglig vs aldri) Automatiseringgrad (manuell vs auto) Omfang (alt vs sporadiske områder) Forandrerlighet, som er et dokuments evne til å kunne oppdateres i forbindelse med endringer på systemet. En tabell har relativt stor forandrlighet, mens en ’stil’ har lav sådan. Med lokalitet menes graden av lokal info kontra generell info. Kan også ta med read-write-forholdet som ble listet tidligere. Ortogonalitet, som er graden av at ting er dokumentert ett enkelt sted, i stedet for at det samme er dokumentert flere steder samtidig. Det vil si at man kun trenger å oppdatere en entret informasjonsbit ett sted. Dette kan knyttes til normaliseringsformer i databaseteknikk. Kan også snakke om graden av ’snakk’ kontra ’informasjon’. Kan kanskje kalle dette graden av utenomsnakk. Kan også måle dok i kilo eller hyllemeter, men det er ikke spesielt hensiktsmessige verdier. Kan også nevne at Digital – som regnes for svært flinke til å dokumentere – hadde ’the gray wall’: dokumentasjon som kom på egne paller ved siden av maskinen. Tidligere the orange wall. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

123 TDT4285 Planl&drift IT-syst
Våren 2004 Sammenhenger Fordelaktig Høy lokalitet Lavt volum Lav endringsrate Indireksjon av hyppige endringer Ufordelaktig Generaliseringer utover lokal fokus Manglende struktur Monotolittisk Ikke tilpasset lesers kompetansenivå Usikkert hvor hensiktsmessig denne foilen er, for det meste er vel sagt i de tidligere foilene. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

124 Hva kjennertegner god dok?
TDT4285 Planl&drift IT-syst Våren 2004 Hva kjennertegner god dok? Forventninger til format Forventninger til plassering Forventninger til fokus Forventninger til innhold Forventninger til tilgjengelighet Forventninger til oppdaterthet Forventninger, forventninger og forventninger. Manualsidene til Unix er et godt eksempel, ditto for cursor-over-ikon under Windows. Når det gjelder forventninger til oppdaterhet, kan det fortelles om da jeg var i Sintef Runit, og vi la ut hvem-gjør-hva-i-Sintef på nett. Utleggingen bestod i å konvertere WP til HTML, og var en kjempejobb. Det var første gang det var gjort. Skjedde i Vanligvis var dette en papirversjon som kom annethvert år. En uke etter at vi hadde fått ting inn, kom den første henvendelsen om at noe (et telefonnummer) måtte oppdateres. Dårlig dok kjennetegnes av ’flow-of-consciousness’, skifte av format, ugjennomtrengelighet, monotolittiskhet. I det hele tatt kan James Joyce’ ’Ulysses’ være kroneksemplet på dårlig datadokumentasjon (i tillegg til at den handler lite om data). God dok inneholder gjerne diagrammer, figurer, tabeller og andre ting som gir visuell oversikt ved et enkelt øyekast. Dårlig dok inneholder ofte skjermdumper og konfigurasjonsfiler (trenger ikke være dårlig), fordi det oftest forteller hvordan ting og enkeltkomponenter er, ikke hvordan ting henger sammen. Kan ikke dokumentere en konfigurasjonsfil ved å lime inn et bilde av den i manualen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

125 Tommelfingerregler for dok
TDT4285 Planl&drift IT-syst Våren 2004 Tommelfingerregler for dok Skap en struktur Jevnlige reviews og audits Skap tilgjengelighet La dok være en del av ”loop’en” Oppdater! (helst før endring) Eliminer det som ikke vil bli brukt eller oppdatert. Struktur må understrekes! Videre må det forklares hva audit og review er. Review ser på systemet (helst på dokumentasjonen) og evaluerer hvorvidt det er et godt eller et dårlig design, hvor svakhetene ligger, hva som er ’godt nok’ og hva som kunne gjøres bedre. En audit sjekker hvor god overensstemmelse det er mellom dok og system. Disse to følges gjerne ad, slik at en audit verifiserer at dokumentasjonen stemmer (og evt oppdaterer), mens review sjekker fornuften til denne dokumentasjonen etterpå. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

126 TDT4285 Planl&drift IT-syst
Våren 2004 Andre tips ... Visualiser en målgruppe når du skriver Ha peer review på all dok Bruk maler og sjablonger La en disposisjon først Visualiser målgruppe Peer review Dessverre er stilskriving en dødende kunst. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

127 Dok-typer: Systemdokumentasjon
Format: manualer Innhold: referansedokumentasjon Når: for alle leverte systemer Fare: for mye og for generelt Skriver: leverandør Bruker: alle Våren 2004 TDT4285 Planl&drift IT-syst

128 Dok-typer: Brukerdokumentasjon
TDT4285 Planl&drift IT-syst Våren 2004 Dok-typer: Brukerdokumentasjon Format: how-tos, FAQ og guider Innhold: hvordan få ting til Når: for alle tjenester som er levert Fare: rett fokus, nivå og vanskelighetsgrad Skriver: alle Bruker: brukerne Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

129 Dok-typer Systembeskrivelse
Format: tekstlig Innhold: overordnet beskrivelse Når: felles for hele systemet Fare: gjentaking av info fra subdok. Skriver: 3.linje Bruker: alle Våren 2004 TDT4285 Planl&drift IT-syst

130 Dok-typer Systemoversikt
Format: diagram, skisser, tabeller Innhold: lokal referanseinformasjon Når: for alle delsystemer Fare: manuell oppdatering Skriver: automatisert av 3.linje Bruker: alle Våren 2004 TDT4285 Planl&drift IT-syst

131 Dok-type: Subsystembeskrivelse
Format: tekstdokument Innhold: gjennomgang av alt for et subsys Når: ett dokument for hvert subsys Fare: gjenfortelling av systemdok Skriver: 3.linje Bruker: fortrinnsvis 3. og 2.linje Våren 2004 TDT4285 Planl&drift IT-syst

132 Dok-type: Standard operasjonsrutine
Format: trinnvis liste Innhold: fremgangsmåte/prosedyre Når: alle rutineoppgaver Fare: forsøke å håndtere for mange feil Skriver: 3.linje Bruker: 1.linje Våren 2004 TDT4285 Planl&drift IT-syst

133 Dok-type: Test-rutine
Format: skrittvis prosedyre med fasit Innhold: testing av funksjonalitet Når: alt som kan slutte å virke Fare: vag fasit eller for omfattende Skriver: 3.linje Bruker: 1.linje og all feilsøking Våren 2004 TDT4285 Planl&drift IT-syst

134 TDT4285 Planl&drift IT-syst
Våren 2004 Dok-type: HW-logg Format: historisk dagbok, loggføring Innhold: løpende info om endringer Når: hver gang noe hw-messig skjer Fare: for detaljert nivå Skriver: alle, spesielt 1. og 2.linje Bruker: alle Langt vanligere før, når man hadde ’stormaskiner’ som kostet mye og det var få av. Dette gikk av moten når arbeidsstasjonene kom inn – dels fordi det var mange av dem, og dels fordi de ofte var personlige, slik at ’eieren’ kunne huske historikken i stedet for å dokumentere den. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

135 Dok-type: Kommentarer i konfig-filer/prog
TDT4285 Planl&drift IT-syst Våren 2004 Dok-type: Kommentarer i konfig-filer/prog Format: innbakt som kommentarer Innhold: overordnede forklaringer Når: ved endring av standardverdier Fare: platte selvfølgeligheter Skriver: fortrinnsvis 2. og 3.linje Bruker: alle Snubletråd: Eksempelvis ... i=i+1 # inkrementer variabelen i med 1. Ikke en lærebok i programmering, men hints til å forstå hva programmet egentlig gjør på et overordnet nivå. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

136 Dok-type: Hjernemessig ’coredump’
Format: oppramsing i fritt format Innhold: alt som en person kan om noe. Når: ved liten tid Fare: ikke top-down og bredde-først Skriver: hvem-som-helst Bruker: hvem-som-helst Våren 2004 TDT4285 Planl&drift IT-syst

137 Sammenheng mellom dok-typer
Systembeskrivelse Systemoversikt HW- logg Subsystembeskrivelse SOP Testrutiner Systemdokumentasjon Våren 2004 TDT4285 Planl&drift IT-syst

138 Rammer for dokumentasjon
TDT4285 Planl&drift IT-syst Våren 2004 Rammer for dokumentasjon En ferdighet som må læres, så sørg for trening for de ansatte. Skap belønning for å arbeide med systemet og skrive god dok. Arbeid aktivt med å endre vanene til de som ikke dokumenterer Lag revisjonsplan for dok Gjenta dette med stilskriving! Dokumentasjon er en adm overhead, og derfor må det skapes insentiv til å utføre det. Man kan sammenligne situasjonen innen en driftsorg, der dok er adm.overhead, med en org der drift er adm.overhead. Det er også viktig å stresse at dokumentasjon må revideres, spesielt dersom ikke ’doken skriver seg selv’. Det betyr at man må ha et bibliotek over dokumentasjon, og at noen har som eksplisitt oppgave å sørge for å ta tak i dokumentasjon som trenger oppdatering. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

139 Sideeffekter av dokumentering
Lettere å dokumentere et godt enn et stort og kaotisk system. Vanskeligere å anta – må sjekke Senker hastigheten i arbeidet :-) Lettere for flere å arbeide sammen Muliggjør audit og review Våren 2004 TDT4285 Planl&drift IT-syst

140 TDT4285 Planl&drift IT-syst
Våren 2004 Dok er nødvendig for å: Anonymisere arbeidsoppgaver Muliggjøre peer review Spesifisere en normaltilstand Identifisere forbedringsområder Angir basis for endringer. Kan du si at du har et konkret system, eller er det et evigvarende work-in-progress? Hva hvis sjefen din kom til deg en dag: nå fryser vi systemet på det nivået vi har idag, ingen endringer de kommende tre årene. (Vi ser bort ifra oppgraderingspress og sikkerhetspatcher). Ville det vært mulig. Vet du i det hele tatt hva du har? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

141 Dynamisk dokumentasjon
TDT4285 Planl&drift IT-syst Våren 2004 Dynamisk dokumentasjon TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Relevant å få med at det finnes mange endringsmodeller. Denne baserer seg på paperet vi bruker i pensum. Læreboka har en annen modell, som er ekvivalent, men et annet format. ITIL, som vi skal snakke om mot slutten av kurset har en tredje, som i tankegang har de samme elementene, men er større og har en mye mer kompleks og avansert prosessmodell. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

142 Prosjekt, rutiner og drift
TDT4285 Planl&drift IT-syst Våren 2004 Prosjekt, rutiner og drift 3.linje Med feil Prosjekt Kart Kart’ Stor endring Rutine-samling Retting Feilsituasjon Rutiner Tar her utgangspunkt i en drift delt på tre linjer. Feilretting Stor endring 2.linje 1.linje Terreng Operasjon Endringer innen samme kart Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

143 TDT4285 Planl&drift IT-syst
Våren 2004 Change Mgmt Checklist Base-line Change ctl form Initial work plan Test på testsystem Review av klient Review av manager Review av kolleger Backup-out-strategi Test på preprod.sys Endelig work plan Opplæring Revisjon av roller og ansvar Implementering Dette er en sjekkliste for management som de bruker for å ta hvert skritt i prosessen for seg. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

144 TDT4285 Planl&drift IT-syst
Arbeidsplan for CCF Baseline CCF Workplan v1 Opplæring Test på testsystem Kundereview Roller Workplan v2 Ledelsesreview Test på preprod. Ansvar Workplan v3 Review av kolleger Implementering Våren 2004 TDT4285 Planl&drift IT-syst

145 Baseline (statisk) dok
Må ha en definert baseline for å kunne planlegge en strukturert endring Alle behov for endringer i baseline må identifiseres og håndteres Våren 2004 TDT4285 Planl&drift IT-syst

146 TDT4285 Planl&drift IT-syst
Hva består baseline av? Tjenerkonfigurasjon Programvareliste Roller og ansvarstildeling Nettverksskisser Installasjonsbeskrivelse og -logger Standard operasjonsrutiner (SOP) Change Control Form (CCF) – tidligere Plan for sikkerhetskopiering Katastrofeplan Testskripts Våren 2004 TDT4285 Planl&drift IT-syst

147 TDT4285 Planl&drift IT-syst
Change Control Form Kunde/brukerfokus: beskrivelse av: Implikasjoner Begrunnelse Overordnet fremgangsmåte Brukes i beslutninger og review Hos kunde I egen organisasjon Blant egne teknikere Våren 2004 TDT4285 Planl&drift IT-syst

148 TDT4285 Planl&drift IT-syst
CCF – innhold (I) Problemdefinisjon – hva er det som gjør at vi ønsker å utføre en endring på systemet. Løsningsbeskrivelse – i korte trekk, hvordan ønsker å å møte disse utfordringene. Endringene omfang – hvem og hva omfattes av endringene og nedetiden. Våren 2004 TDT4285 Planl&drift IT-syst

149 TDT4285 Planl&drift IT-syst
CCF – innhold (II) Prosjektteam – hvem er med på denne endringsrunden, hvordan er roller og ansvar fordelt. Kompleksitet – er endringen vanskelig, vil det kunne få store ringvirkninger ved feil, kreves det mye koordinering? Konsekvens av nullalternativ – er det mulig å klare seg uten? Våren 2004 TDT4285 Planl&drift IT-syst

150 TDT4285 Planl&drift IT-syst
CCF – innhold (III) Estimert nedetid – hvor lenge må hvilke maskiner og tjenester være helt eller delvis nede. Prioritet – så denne endringen kan vurderes opp mot andre endringer, kanskje også noe om konsekvenser ved å utsette. Våren 2004 TDT4285 Planl&drift IT-syst

151 TDT4285 Planl&drift IT-syst
CCF innhold (IV) Revalideringplan – hvordan (og med hvilke tester) verifiserer man at systemet er operativt etter endringen. Backout-plan – hvordan kan man reversere endringen underveis dersom det slår feil Status – hvilket steg i prosessen har denne CCF’en kommet Våren 2004 TDT4285 Planl&drift IT-syst

152 TDT4285 Planl&drift IT-syst
CCF – innhold (V) Merknader – diverse informasjon, kommentarer, fotnoter og advarsler fra personer i prosessen. Ting som ikke passer inn i de øvrige punktene. Tilhørende dokumentasjon – liste med referanser til annen relevant dok, deriblant systemdokumentasjon. Våren 2004 TDT4285 Planl&drift IT-syst

153 TDT4285 Planl&drift IT-syst
CCF Innhold (VI) Prosedyre – trinnvis fremgangsmåte, men på et relativt overordnet plan, for dette detaljeres i en Workplan, der det nærmest går på kommandonivå. Første trinn – første deloppgave under installasjonen Andre trinn ... Tredje trinn ... Våren 2004 TDT4285 Planl&drift IT-syst

154 TDT4285 Planl&drift IT-syst
CCF – innhold (VII) Testplan – hvordan tester man den nye funksjonaliteten, plan med testskripts som etterpå kan legges inn i baseline. Implementasjonsmerknader – tekniske merknader. Administrativ informasjon – så som dato, forfattere, versjonsnummer etc. Våren 2004 TDT4285 Planl&drift IT-syst

155 Mulige feller under impl.
Målendring underveis Manglende parallellisering av oppgaver Manglende underveis-info Personavhengigheter istf roller Ad hoc kortslutning av en ellers ryddig prosess pga tidsnød For mange roller på en enkelt person Våren 2004 TDT4285 Planl&drift IT-syst

156 Tjeneroppgraderinger
TDT4285 Planl&drift IT-syst Våren 2004 Tjeneroppgraderinger TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI I denne forelesningen er målet å fotfølge en oppgradinger av en tjener, f.eks oppgradering av operativsystem på en tjener. Er dette kompatibelt med andre typer oppgraderinger? Ja, metoden er generell, selv om det som står her relaterer seg til ett bestemt område. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

157 TDT4285 Planl&drift IT-syst
Tjeneroppgradering Lag en tjeneste-sjekkliste Verifiser kompatibilitet Lag verifiseringsverktøy Lag en backout-plan Velg et vedlikeholdsvindu Informer brukerne Gjennomfør testene Gjennomfør oppgraderingen Gjennomfør ettertesting Ved feil, gjennomfør backout-planen Våren 2004 TDT4285 Planl&drift IT-syst

158 Punkt 1: Lag en tjeneste-sjekkliste
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 1: Lag en tjeneste-sjekkliste Den bør inneholde informasjon om avhengigheter og konfigurasjon ifm: Hvilke tjenester ytes av tjeneren? Hvem er brukerne av tjenesten? Hvilken programvare er installert? Det er strengt tatt det samme hva slags format du bruker til en slik tjeneste-sjekkliste, bruk gjerne papir og blyant, selv om det ikke er så lett å håndtere elektronisk. Det er viktig at brukerne tas med på denne prosessen, for det er ikke sikkert at en enkelt systemadministrator (eller alle systemadministratorene) har full oversikt. Hvilket er en god indikasjon på at alle systemadministratorene bør tas med på review. Hovedpoenget med review er at de svake sidene skal finnes, og således er det nært beslektet med en ”brainstorming”. Det er viktig at et review ikke bare blir en tom sermoni, men at den inneholder aktiviteter som gjør at man er sikre på at deltakerne graver seg tilstrekkelig ned til å finne i alle fall de fleste, de viktigeste og de mest iøynefallende feilene. Noen tips til å finne programvare på maskinene: let etter åpne porter, let i accountingen, let etter hva som finnes av programvare. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

159 Punkt 2: Verifiser kompatibilitet
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 2: Verifiser kompatibilitet Verifiser at hver enkelt programpakke er kompatibel med det nye OS-et, evt: Oppgrader programpakka på gml OS Oppgrader til ny versjon samtidig med oppgraderingen av OS Slutt å støtte programpakka Her er poenget at før vi starter å oppgradere OS, trenger vi å vite hvorvidt det som er nyttelasten på maskinene: programvaren som brukerne benytter også vil fungere under det nye OS-et. Dersom man ikke gjør det, vil man lett kunne få en OOPS-opplevelse. Det spiller ingen rolle at man får oppgradert OS-et helt perfekt, dersom ikke programvaren som OS-et skal være infrastruktur for ikke lengre virker. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

160 Punkt 3: Lag verifiseringsverktøy
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 3: Lag verifiseringsverktøy Lag tester som verifiserer det viktigste av fuksjonaliteten i hver programpakke som finnes på maskinen. Automatiser kjøring av alle testene Lag regresjonstest av den automatiske kjøringen av testene. Det er viktig at man ikke tester absolutt alt, men et rimelig tverrsnitt. Det er gjerne slik med dataprogrammer at de enten ikke virker overhodet, eller så virker de rimelig greitt. Dermed er greitt nok å få med seg noe som tar 90% av feilene. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

161 Punkt 4: Lag en backout-plan
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 4: Lag en backout-plan En backoutplan er en plan for hvordan du reverserer endringen, slik at du kommer tilbake til det opprinnelig systemet. Ikke sammenbland backout med backup, der backup er en redundant kopi av informasjon, men backout (å rygge ut) er å reversere en helt eller delvis gjennomført enring, vanligvis fordi det viste seg ikke å oppfylle kravene. Det bør heller ikke blandes sammen med fall-back, som vanligvis brukes i forbindelse med en reserverløsning, gjerne av dårligere kvalitet som man kobler over til dersom den primære løsningen ikke lengre fungerer. Det er viktig at man planlegger oppdateringen slik at ikke en backout blir vanskeliggjort. Eksempelvis er det lurt å installere ny OS-versjon på en ny disk, slik at den gamle kan settes tilbake som en en del av en backout-plan. Dersom man i stedet hadde startet direkte å endre på filene i den opprinnelige installasjonen, hadde man brent alle bruer, og ville være ute av stand til å returnere til utgangspunktet. (En del hærførere bruker nettopp dette til å sikre seg at retrett er umulig.) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

162 Punkt 5: Velg et vedlikeholdsvindu
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 5: Velg et vedlikeholdsvindu Når skal endringen gjennomføres? Hvor lang tid skal settes av til å gjennomfør den? Hvor mye tid skal reserveres for eventuelt å iverksette backout? Vi kommer tilbake med mer om vedlikeholdsvinduer i en senere forelesning. Det er lurt å sette av godt med tid, gjerne gange realistisk estimat med 2 eller 3 for å få tiden som formelt reserveres. Når man først har en varslet nedetid, er det sjelden så mye verre om det var 3 timer enn 1 time. Det er viktig at tidspunktet for iverksetting av backup overholdes. Ellers risikerer man å ende i en lang rekke med ”bare en ting igjen å rette, så er alt i orden”. Dette er et selvbedrag. Derfor er det bedre å sette av langt mer enn nok tid til oppgraderingen, og samtidig hardhendt håndheve overgang til backout dersom man allikevel ikke klarer å møte tidskravene. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

163 Punkt 6: Informer brukerne
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 6: Informer brukerne Hvem/hva blir rammet? Hva vil skje? Når skjer det? Hvorfor skjer det? Hvordan kan du gi beskjed om at dette må stoppes pga store ulemper. Kontaktinformasjon Det er lurt å holde alle slike meldinger i samme format, slik at brukerne venner seg til det. Det er også lurt å holde dem kortfattede, eventuelt med pekere til mer informasjon for de som er interessert. Ofte gidder ikke en person å bruke mer enn 2-3 sekunder på en slik informasjonssak, og det er all tiden du har tilgjengelig til å fange oppmerksomheten og overbringe informasjonen. (Samme utfordring som reklamebransjen, forresten.) Det er ofte lurt med en kortfattet introduksjon som setter brukeren i stand til å forstå om dette er relevant eller ikke. Si noe om konsekvensene av det som gjøres. (Det er ikke tilfeldig at hvem og hva som rammes kommer aller først på denne lista.) Det bør annonseres på flere steder, avhengig av historikk og hensiktsmessighet. Men bruk de samme stedene hver gang, slik at man lærer seg til hvor man finner slik info. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

164 Punkt 7: Gjennomfør testene
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 7: Gjennomfør testene Gjøres like før vedlikeholdsvinduet Avslører om det har oppstått feil etter at oppgraderingen ble planlagt. Evt feil etter oppgraderingen er da trolig som følge av oppgraderingen, ikke noe man arvet fra det gamle systemet. Det er viktig at dette kommer så tett opp til starten på vedlikeholdsvinduet som mulig, men det kan godt komme før varslet starttidspunkt for nedetid. Dersom du finner feil, så kan det enten rettes der og da, eller i alvorlige tilfeller kan oppgraderingen reduseres eller utsettes. Det er ikke tilrådelig å starte på en oppgradering dersom deler av det gamle systemet ikke virker. Det hindrer en effektiv backout. Samtidig risikerer du at ytterligere feil innføres under oppgradering, slik at du etterpå må lete etter dobbeltfeil. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

165 Punkt 8: Gjennomfør oppgraderingen
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 8: Gjennomfør oppgraderingen Følg vanlig praksis og dokumentasjon for hvordan du oppgraderer. Ha gjerne med ”sidemann” som kan kikke på, hjelpe til, kommentere og fungere som en kontrollør. Dersom det tar for lang tid, avbryt og utfør backout. En sidemann kan fungere som tilgjengelig arbeidskraft i tilfelle en krise som krever ekstra innsats. Videre kan han lære endel av å se på deg, og du kan lære endel av hans kommentarer til ditt arbeide. (Men det fordrer ikke altfor store egoer.) Dersom du forteller hva du gjør mens du gjør det, mener mange at det blir riktigere ... Tempoet er lavere, og du får tenkt deg litt ekstra om for hver trinn. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

166 Punkt 9: Gjennomfør ettertesting
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 9: Gjennomfør ettertesting Etter at oppgraderingen er gjennomført, må testene utføres på ny Ved feil: feilsøk, feilrett og kjør ny testing Dersom det tar for lang tid, avbryt og utfør backout. Teste – teste – teste! Her er det at du får stor nytte av at testene er samlet i en suite som kan kjøres automatisk. Dersom du skulle utført dem manuelt, ville det raskt tatt mye tid, og man blir fristet til å hoppe over den siste delen av testene dersom de første gikk feilfritt igjennom. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

167 Punkt 10: Ved feil, utfør backout-plan
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 10: Ved feil, utfør backout-plan Backoutplanen bør ikke utsettes i håp om at man skal finne ”siste feilen” Viktig at noen har myndighet og ansvar for å si at backout skal iverksettes Må iverksettes tidsnok til at det er nok tid igjen til både backout og etterfølgende testing. Men det kan tenkes at enkelte mindre feil er til å leve med, at de ikke påvirker brukerne, og så videre. Det kan ofte være nyttig å involvere brukerne i slik vurderinger, for de kan ofte bedre leve med degradert funksjonalitet når de selv har vært med å ta avgjørelsen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

168 Punkt 11: Informer om utfallet
TDT4285 Planl&drift IT-syst Våren 2004 Punkt 11: Informer om utfallet Etter nedetid, fortelle hva av det som har vært nede og som å er oppe igjen Etter oppgradering, fortell om det og hva som er nytt/bedre/annerledes Etter backout, fortell om det og hva av forespeilte ny funksjonalitet som allikevel ikke er der. Informasjon er et interessant felt. Lærebokforfatteren forteller at plakater tapet over skjermene med store røde bokstaver ikke virket. Andrew Iversen har fortalt om at plakater på G-128 ikke virket, så de plasserte plakatene over kortleserne. Selv det virket ikke, for brukerne løftet vekk plakaten og dro kortet og gikk inn. På spørsmål om de ikke så plakaten, svarte de at joda, men de tenkte at den kanskje ikke gjaldt. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

169 Oppgradere eller nyinstallere
Bevarer mye av det gamle oppsettet Tar korter tid Kan få med grums fra tidligere inst Kan feile på komplekse installasjoner Våren 2004 TDT4285 Planl&drift IT-syst

170 Prøving av oppgraderingen
Generalprøve, der man gjør maken oppgradering på et lignende oppsett ”Mimeprøve” der man strekker alle kabler og ”gjør” alle fysiske operasjoner, men uten å faktisk endre noe. Våren 2004 TDT4285 Planl&drift IT-syst

171 TDT4285 Planl&drift IT-syst
Modeller Ferdigstille ny maskin offline, og bytte med gammel maskin, som blir stående som kald ressurs for backout. Ta ned maskin, reinstallere på den, og ta den opp med nytt OS. Fase brukerne gradvis over til ny ressurs i nettet, og ta ned gammel maskin når alle er faset over. Våren 2004 TDT4285 Planl&drift IT-syst

172 TDT4285 Planl&drift IT-syst
Etterbruk at testene Legg dem til et ”bibliotek” av tester som du kan bruke for å sjekke systemets tilstand etter vedlikehold el.l. Bruk dem til å monitorere maskinene for endringer. Visualiser output. Bruk dem som referanse for hvordan komponenter i systemet oppførte seg på et gitt tidspunkt. Våren 2004 TDT4285 Planl&drift IT-syst

173 TDT4285 Planl&drift IT-syst
Våren 2004 Vedlikeholdsvinduer TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

174 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon Et vedlikeholdsvindu er et forhåndsdefinert, varslet tidsrom der dataanlegget kan tas ned for å gjennomføre vedlikehold og oppgraderinger, typisk flere i parallell. Vanligvis legger man endringer og oppgraderinger til et vedlikeholdsvindu, ikke omvendt. Dvs at det ikke er ”pent” å lage et vedlikeholdsvindu fordi man har en endring. Sammenlign med busser, man går til busstoppet (sammen med andre) fordi man vet at det kommer en buss. Det er ikke slik at man sender ut en buss fordi man ser at det er noen på busstoppet – det er taxi :-) Dette eksemplet kan også dras så langt som til å sammenligne kostnader, buss er dyrere enn taxi. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

175 TDT4285 Planl&drift IT-syst
Våren 2004 Vedlikeholdsvinduer Forrige forelesning Planlegging Oppgradering Denne forelesningen Vedlikeholdsvindu Oppgrad1 Oppgrad5 Her må det trekkes inn at vi nå jobber på et metanivå av forrige forelesning. Da handlet det om hvordan man planlegger og gjennomfører en endring. Nå handler det om hvordan man koordinerer en slik endring med andre endringer og med brukerne. Planlegging Planlegging Oppgrad2 Oppgrad4 Oppgrad6 Planlegging Planlegging Nedtaking Oppstart Oppgrad3 Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

176 TDT4285 Planl&drift IT-syst
Våren 2004 Gangen i et vedl.vindu Forberedelse Gjennomføring Gjenstart Endringsforslag Schedulere vinduer Velge én flight director Bygge en masterplan Fjerne tilgang Ta systemet kontrollert ned Gjennomføre oppgradere Utføre testing Ta systemet opp Åpne tilgang Annonsere tilgjengelighet Være tilstede for brukerne Være obs på evt problemer Her er de samme tre fasene som i forrige forelesning: forberedelse, gjennomføring og etterarbeid. I stor grad er det overlapp i aktivitetene, men samtidig er det også slik at de to kapitlene opererer på forskjellige nivåer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

177 Rollen som flight director
TDT4285 Planl&drift IT-syst Våren 2004 Rollen som flight director Schedulering av deloppgaver Bestemme go/no-go på deloppgaver Bestemme iversetting av back-out Diktator for vedl.vinduet Ha tilstrekkelig oversikt/kunnskap Denne rollen har fått et fancy navn. Det er en nyttig teknikk, dels fordi det gir rollen innhold gjennom en analogi, og dersom denne er godt valgt kan det være med å skape en felles forståelse av hva oppgavens rolle og ansvar går ut på. Dernest skaper det litt liv, farge og kanskje status å ha slike roller. Det ville ikke være like kult å være vedlikeholdsvinduskoordinator, liksom ... Oppgavens rolle er å være den som bestemmer når det er for lite tid til å bestemme i fellesskap. Sånn sett er det en midlertidig myndighet som er tildelt noen. Kan sammenlignes med en flyver eller en kaptein, som har ’all’ makt ombord. Her er det viktig at dette er en rolle. Selv når sjæfen til flight director er med på arbeidet, så er det flight director som bestemmer – i vedlikeholdsvinduet. Fortell om russisk fregatt som strandet utenfor Skagen fordi admiralen ombord (passasjer) kom på en god ide som kapteinen ikke turde motsi. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

178 Oppetid og nytteområde
TDT4285 Planl&drift IT-syst Våren 2004 Oppetid og nytteområde Kan tas ned ad hoc Sporadisk oppetid Vedlikeholds- vinduer Kan ikke tas ned 1 2 3 4 5... Finnes en egen notasjon for dette, jeg ser ikke sikker på hvordan, om det er N3 for 99,9% og N5 for 99,999%, der sifferet angir hvor mange 9-tall man har. N1=1mnd; N2=3,5dgr; N3=8,5timer; N4=51minutter; N5=5minutter; N6=30sekunder; N7=3sekunder. Hvorvidt opptid regnes med eller uten vedlikeholdsvinduer er et definisjonsspørsmål. 0% 90% 99% 99,9% 99,99% 99,999% Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

179 Rammer for vedl.vinduer
TDT4285 Planl&drift IT-syst Våren 2004 Rammer for vedl.vinduer Kort og avgrenset periode Planlagt på forhånd Annonsert overfor alle impliserte Reduserer funksjonaliteten Hektisk med mye parallell aktivitet Må organiseres Her er det igjen viktig hvorvidt man legger opp vedlikeholdsvinduer fordi man har noe man skal gjøre, eller man utsetter det man skal gjøre til et vedlikeholdsvindu. I det første tilfellet er det vel ikke egentlig et vedlikeholdsvindu, for det blir gjerne bare en enkelt ting som skal gjøres, og den situasjonen snakket vi om i forrige forelesning. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

180 Regelmessighet av vedl.vinduer
TDT4285 Planl&drift IT-syst Våren 2004 Regelmessighet av vedl.vinduer Positivt Negativt Etter behov Fleksibelt Lite koordinering Serialisering På faste tidspunkter Brukeren kan tilpasse sitt arbeide Bedre planlegging Miste status hvis den ikke brukes Vi har egentlig snakket om disse tingene flettet inn i foregående foiler. Ta det som en oppsummering. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

181 Regelmessighet – eksempler
TDT4285 Planl&drift IT-syst Våren 2004 Regelmessighet – eksempler Første mandag pr mnd fra til klokken neste morgen Fra fredag 1800 til mandag 0800, én gang i hver av juni, juli, august, desember og januar. Eksempler på slik regelmessighet. Det finnes selvfølgelig ingen fasit på hyppighet eller lengde. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

182 TDT4285 Planl&drift IT-syst
Planlegging i forkant Leveringstid på utstyr Rekkefølgen innen en masterplan Avhengigheter Planlegging i forkant av et vedl.vindu Lisenser Innhente kompetanse Annonsering Endrings- planer Våren 2004 TDT4285 Planl&drift IT-syst

183 TDT4285 Planl&drift IT-syst
Våren 2004 Endringsforslag Hvilke endringer skal gjøres? Hvilke maskiner er involvert i arbeidet? Hva må gjøres i forkant før man kan utføre endringen? Avhengighet av andre systemer/maskiner? Hva blir berørt? Hvem utfører/har ansvar for endringen? Hvor lang tid tar det (klokketid og arb.tid)? Hva er testproc. og hva trengs av utstyr? Hva er back-out, og hvor lang tid tar det? Her legger boka opp til at man skal ha et endringsforslag. Dette er i stor grad med overlapp fra CCF ifra paperet som vi tidligere har gått igjennom. Men merk at fokus på dette dokumentet er koordinering med omgivelsene, ikke prosessen med endring som sådan. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

184 Saksgang ved endringsforslag
TDT4285 Planl&drift IT-syst Våren 2004 Saksgang ved endringsforslag Siste uka Endrings- utkast Peer- review Frysing Gjennom- føring Det er flere iterasjoner på endringsforslaget, men på et gitt tidspunkt, for eksempel siste uka, så fryses det, slik at eventuelle endringer må via flight director. Det bare må være slik, for at flight director skal kunne ha noe håndfast å holde seg til. Men til gjengjeld betyr det at de enkelte som arbeider med endringer må ha ting klart i god tid. Det er med andre ord ikke mulig å ’vente og se’ eller la ’veien bli til mens man går’. I tilfelle endringer Flight- director Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

185 TDT4285 Planl&drift IT-syst
Våren 2004 Masterplanen Masterplanen settes opp at flight director: Gir en schedule av aktivitetene Tar hensyn til avhengigheter Realistisk mht tidsrammene/ressurser Merk at masterplanen er en skisse som utarbeides i forkant, men som må kunne tillempes underveis dersom uforutsette ting skjer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

186 TDT4285 Planl&drift IT-syst
Våren 2004 Når timing er viktig Ingen skal ha mer en ett fokus Hvis mulig: pipeline oppgaver Ha egne troubleshootere for ekstraordinære problemer La det være noe slakk At myndighet og ansvar er klart definert At beslutningsgrupper er små Det er ikke tid til å sette ned en komite, og derfor må det være klare ansvarsforhold og klart hvem som tar beslutninger. Diskusjon og slikt kan man heller ta etterpå og forarbeidet kan være langt mer demokratisk dersom det er ferdiggjort i forkant. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

187 CCF versus endringsforslag
Change control forms: Fokus: kommunikasjon Peer review Endringshåndtering Genererer et spor (historikk) Kvalitetssikring Endringsforslag Schedulering Timing Gjennomføring Koordinering Våren 2004 TDT4285 Planl&drift IT-syst

188 TDT4285 Planl&drift IT-syst
Case: IDI flytter 1 Lade: 2p Elektro 2x2p Demontere gml utstyr Demontere gml utstyr 1p+sjåfør Transport på vei 2(+1)p Midlertidig plassering Transport på tralle IT-Vest 4x2p Midl. Plassering utenfor mask.rom Montering Våren 2004 TDT4285 Planl&drift IT-syst

189 TDT4285 Planl&drift IT-syst
Case: IDI flytter 2 8 9 11 15 17 23 Nedtaging Demontering Transport Oppmontering Mat Gjenstart Alle De fleste Noen Våren 2004 TDT4285 Planl&drift IT-syst

190 Koordinering under driftstans
Scheduler forstyrrende aktiviteter samtidig, og helst først i vedl.vinduet Sørg for enkel kommunikasjon mellom systemadmin’ene, f.eks via radio. Ha en tilgjengelighet neste dag Monitorer systemet neste dag Gjennomfør en post mortem-granskning Våren 2004 TDT4285 Planl&drift IT-syst

191 Shutdown/boot-sekvenser
Punktvis liste over rekkefølgen ting tas ned Punktvis liste over rekkefølgen ting tas opp Prioriteringsrekkefølge: Systemadministrasjonsverktøy Basis systemtjenester Sekundære systemtjenester Brukertjenester Arbeidsstasjoner Våren 2004 TDT4285 Planl&drift IT-syst

192 Hvis du trenger 7x24 oppetid
Du må ha tilstrekkelig redundans Du kan ikke fjerne tilgang til systemet Du kan ikke gjøre en full nedtaging Kommunikasjonsbehovet er ofte mindre direkte Masterplanen må legges opp så ingen viktig tjeneste er ute av drift Tilgjengelighet må monitoreres løpende Våren 2004 TDT4285 Planl&drift IT-syst

193 TDT4285 Planl&drift IT-syst
Våren 2004 Tre aktiviteter Konfigurering – tilpassing av en installasjonsbase for et sett maskiner Installering – opplasting av installasjonsbase til en ny maskin Vedlikehold – daglig kamp for å holde seg i målområdet og rette opp problemer som måtte ha oppstått Skiller mellom disse for aa unngaa aa opptre som en hobbygartner Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

194 TDT4285 Planl&drift IT-syst
Våren 2004 Tjenstekonvertering TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

195 Tjenestekonvertering
En eksisterende tjeneste skal skiftes ut med en ny, enten ved oppgradering software, skifte av hardware, protokoll eller endring i infrastruktur. Våren 2004 TDT4285 Planl&drift IT-syst

196 TDT4285 Planl&drift IT-syst
Våren 2004 Utrullingsstrategi En Gammel Gammel Gammel Deg selv Noen Flash-Cut SA-kolleger Overlapp Ny Avbrudd Ny Ny Mange Igjen kommer vi over one-some-many. Andre Sømløst Brudd Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

197 Kommunikasjon Gammel tjeneste Er helpdesk informert?
Har du full kontroll på hvordan brukerne benytter tjenesten? Avbrudd ved konverteringen? Bruker Konvertering Bruker Bruker Må noe gjøres på hver brukes maskin? Ny tjeneste Er ny tjeneste fullstendig Kompatibel med den gamle? Våren 2004 TDT4285 Planl&drift IT-syst

198 Dersom avbrudd er nødvendig
Så kort som mulig Bør være velorganisert Bør komme på et for brukeren komfortabelt tidspunkt Må være annonsert i god tid Våren 2004 TDT4285 Planl&drift IT-syst

199 TDT4285 Planl&drift IT-syst
Våren 2004 Lagdeling og søyler Lagdeling – dersom sømløs overgang er mulig Søyler – dersom man man får funksjonsbrudd Kunde1 Kunde2 Kunde3 Kunde4 Applikasjon Protokoll Lagdelt Tjener Datalager Søyle Op.sys Med andre ord, du endrer alt på en gang dersom du allikevel skal ha nedetid. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

200 TDT4285 Planl&drift IT-syst
Rioting mob technique Unix-team B PC-team B HØYRE KONTORREKKE Senior troubleshooters VENSTRE KONTORREKKE PC-team A Unix-team A Våren 2004 TDT4285 Planl&drift IT-syst

201 TDT4285 Planl&drift IT-syst
Avbrudd Få men store er bedre enn mange og små. La brukeren få vite på forhånd hva han tjener på avbruddet. (What’s in it for me?) La brukeren få innvirke på valget av tidspunkt for avbruddet. La brukeren få beskjed i god tid, så han kan planlegge sin egen aktivitet og være produktiv under bruddet. Våren 2004 TDT4285 Planl&drift IT-syst

202 Overfasing av tjenester
Gammel På forhånd Logging redirekt Gammel Ny Overgang Gammel Ny I etterhånd Feilmelding m/info Ny Etterpå Våren 2004 TDT4285 Planl&drift IT-syst

203 Avbruddstrategier Sentralt Hos brukeren Sømløst Trivielt
”En-noen-mange” Avbrudd Vedlikeholds- vinduer ”Rioting mob” på isolerte delsystemer Våren 2004 TDT4285 Planl&drift IT-syst

204 TDT4285 Planl&drift IT-syst
Våren 2004 Back-out-plan En plan for å reversere en delvis gjennomført endring Klare rammer for når den skal gjennomføres dersom man ikke kan fullføre endringen Jo raskere og enklere en back-out kan gjennomføres, jo bedre Back-out kalles også roll-back. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

205 TDT4285 Planl&drift IT-syst
Viktige momenter Back-out- plan Trippel- testing Dobbelt- testing Peer- review Opplæring Planlegging Testing Tilstede- værelse Informasjon Annonsering Kommunikasjon Våren 2004 TDT4285 Planl&drift IT-syst

206 TDT4285 Planl&drift IT-syst
Våren 2004 Skalerbarhet TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

207 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon Med skalerbarhet menes evnen til å takle en økning i størrelse med færre ressurser pr enhet enn det som allerede er tilfelle for eksisterende base. Man kan snakke om skalering i betydningen at en løsning skalerer innenfor et visst verdiområde (denne mailtjenesten skalerer til mail i timen). Da mener man området som løsningen håndterer uten ytterligere utstyr eller design, altså for konstante kostnader. Men i en annen forstand kan samme uttrykk bety at løsningsmetoden vil fungere for dette verdiområdet, og kostnadene er mer eller mindre lineære. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

208 TDT4285 Planl&drift IT-syst
Våren 2004 Kostnader og ytelse Kostnader kan være Proporsjonale med bruk Kreve en initialkostnad Kostnad Her kan vi sammenligne med taxi og buss, der bussen har en ren proporsjonal kostnad (billetten koster like mye for alle sammen) mens taxi har en initialkostnad for hver fjerde passasjer. Dette er en av grunnene til at TCO-målinger er vanskelige, for en TCO vil alltid være relevant for en viss belastning, og dersom to eller flere løsninger ikke er spesifisert for samme verdiområde (det er ikke utelukkende tilstrekkelig å beregnet for et enkelt punkt), så sammenligner man ikke kompatible løsninger. Ytelse Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

209 Tendens ved adm overhead
TDT4285 Planl&drift IT-syst Våren 2004 Tendens ved adm overhead Innsats Arbeids- innsats Restinnsats Det er fristende, men for enkelt å si at i en organisasjon med N personer er overheaden N*N. I små organisasjoner der man må ha alle-til-alle forhold, så kan nok dette være riktig. Ta med at UiO har flere ikke-vitenskapelige enn vitenskapelige stillinger (men dette må være blant faste stillinger, ikke blant midlertidige stillinger (dvs stipendiater). Selv om en tekniker eller sekretær ikke vil se på seg selv som en overhead, så er det allikevel det på et overordnet nivå. Her er det også viktig å merke seg at verdien av arbeidet kan variere kolossalt fra en dyktig til en middels dyktig person. Og i praksis kan dette overdøve en rekke andre effekter. Adm overhead Ant personer Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

210 TDT4285 Planl&drift IT-syst
Tendenser Jo større organisasjon, jo mer administrativ overhead Over en viss grense: ikke lengre uproduktiv tid, men negativ innsats Administrativt kaos ødelegger motivasjon og skaper konflikter Våren 2004 TDT4285 Planl&drift IT-syst

211 Geografisk eller oppgavemessig arbeidsdeling
TDT4285 Planl&drift IT-syst Våren 2004 Geografisk eller oppgavemessig arbeidsdeling Delorg1 Delorg2 Delorg3 Delorg4 Begge disse er delt etter områdebasert arbeidsdeling, det er bare spørsmål om området er delt inn etter organisasjon eller etter datateknisk emne. Delorg5 Skrivere Windows Web Nettverk Mac Backup Unix Epost Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

212 TDT4285 Planl&drift IT-syst
Våren 2004 Driftspersons fokus Endringsrate, bredde og fokus spiser alle av en persons oppmerksomhet og fokus. Økes det i en dimensjon, må det reduseres i en av de andre. Endringsrate Bredde Versjon1 Versjon2 Versjon3 Skrivere Unix Windows Nettverk Drift Brukerstøtte Ekspertinnsikt Utvikling Forskning Dybde Her er poenget at en persons fokus har et `konstant’ volum, selv om man kan benytte det i dybde, bredde eller høyde. Likevel er det mer eller mindre konstant. Jfr lastenes sum er konstant. Fortell om hvordan man skyter kråker i Sør-Afrika. Nevn litt om konseptet med 7+-2. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

213 Kostnader ved to driftsformer
TDT4285 Planl&drift IT-syst Våren 2004 Kostnader ved to driftsformer Drifts- innsats Storskaladrift Driftsform: en-og-en Målet med storskaladrift er å få hver nye forstørrende enhet til å bli billigere enn de tidligere enhetene. Dersom kostnaden er lik, sier vi at det den skalerer lineært. Dersom den er billigere skalerer den bedre enn lineært, mens i motsatt fall skalerer den dårligere enn lineært. Ant maskiner Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

214 TDT4285 Planl&drift IT-syst
Tendenser En-og-en-drift Skalerer lineært Håndterer koordineringsoppgaver dårlig Storskaladrift Bedre enn lineær skalering Betraktelig initiell investering Administrativ overhead Våren 2004 TDT4285 Planl&drift IT-syst

215 Uniformering av kundes behov
Kvalitet Levert kvalitet Enkeltkunder Våren 2004 TDT4285 Planl&drift IT-syst

216 Klasser av kvalitetsnivåer
TDT4285 Planl&drift IT-syst Våren 2004 Klasser av kvalitetsnivåer Kvalitet Kundene grupperes i tre klasser som får ulik grad av kvalitet. Man kan dermed lage tre ulike løsninger som kundene kan ”velge” imellom. Det blir langt billigere å ha noen få slike standardiserte løsninger enn mange spesialtilpassede løsninger. Den overskytende kvaliteten er ikke bortkastet, fordi den kan brukes som en indikasjon på ekstra kvalitet som brukeren får ”gratis” ... Ekstrafordeler, dvs fordeler du ikke hadde bedt om. Enkeltkunder ”Ekstrafordel” Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

217 TDT4285 Planl&drift IT-syst
Våren 2004 Uniformitet Variantbegrensning er uniformering Mål: ”One size fits all” Kvalitet: For høy: bonus For lav: kontraktsbrudd Fare: bruker føler at det er ham, ikke løsningen som er uniformert. Dessverre blir ofte one-size-fits-all til one-size-fits-none. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

218 TDT4285 Planl&drift IT-syst
Våren 2004 Variantbegrensning Trivielt: en enkelt løsning dekker behovet Middels: trenger flere løsninger; Tilpasse brukers behov til tilgjengelig system Tilpasse systemet til brukers behov Vanskelig: må ha spesialløsning; Akseptere et system i tillegg La brukeren ordne sitt eget system Utvide systemet til å håndtere spesialtilfeller Det bør ikke være et mål i seg selv å skulle variantbegrense, men når det kan eliminere unødig eller uønsket variasjon, så kan det gi et billigere dataanlegg. Jeg vil påstå at variantbegrensning aldri bør være et mål i seg selv, men det kan være ønskelig for å ta ut gevinster i kostnader, standardisering el.l. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

219 Midler for å øke skalerbarhet
TDT4285 Planl&drift IT-syst Våren 2004 Midler for å øke skalerbarhet Organisatoriske Arbeidsdeling Tekniske Ortogonalitet i løsningsvalg Standardisering av løsning Fokus på robusthet/stabilitet Out-source uvesentligheter Generalisere løsningene Robusthet er evnen til å absorbere uforutsette (unormale) hendelser og allikevel fortsette å fungere. Stabilitet er evnen til å fortsette å fungere når omgivelsene er like – dvs at det ikke krasjer av seg selv. Generalitet er evnen til å kunne håndtere også bruk og tilfeller som man ikke kan forutse. Referer til sendmail, som er programmet som ble skrevet for å løse et problem som ikke lengre eksisterer, men som var så generelt at det løser problemer som ikke eksisterte da det ble skrevet. (også påstått å være et typisk av de programmene som gir Unix et dårlig rykte). Når det gjelder standardisering, så er bensin et godt eksemple. Det er samme bensinen som brukes i ”alle” biler, og bensinprodusentene og bilprodusentene produserere alle produkter som passer hverandre. Det gjør at de kan konsentrere seg om hver sin produksjon (ortogonalitet), samtidig får man standiserte løsninger som er allestedsnærværende og enkle å forstå for brukeren (standardisering) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

220 Skaleringsmodeller av drift
TDT4285 Planl&drift IT-syst Våren 2004 Skaleringsmodeller av drift Stor drifts- organisasjon som tar ut stordriftsfordeler System- produsent Drift flyttes nærmere bruker Liten, lokal driftsorganisasjon Drift er inkludert i systemet. Produsenten håndterer Brukerne driver sine egne maskiner To ekstremer av skalering av drift er at brukerne overtar driften selv, og at programvareprodusenten gjør drift overflødig ved at alle installasjoner globalt kan drives fra en enkelt organiasjon. Dermed blir det gjerne sammenfall (eller i det minste overlapp) mellom produksjon og drift av et system. De to ekstremene er kompatible og sammenfallende. Jeg er ikke sikker på om noen har fått til det ekstremt høyre tilfellet, men vi ser momenter av det i Microsoft updates, der Microsoft ønsker å vedlikeholde datamaskinen din. Kanskje det heller skulle vært presentert som en ring der de to ekstremene møter hverandre? Stordrift Superskalert drift Lokal drift Ingen drift Bruker Drift? Økende skalering Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

221 TDT4285 Planl&drift IT-syst
Våren 2004 Redundans SIF8076 Planlegging og Drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

222 TDT4285 Planl&drift IT-syst
Definisjon Redundans er å bruke ekstra, overflødig kapasitet for å etablere en sikkerhetsmargin mot feil på systemet. Våren 2004 TDT4285 Planl&drift IT-syst

223 TDT4285 Planl&drift IT-syst
Ulike typer redundans Fail-over – sømløs overgang til en annen men funksjonelt lik komponent Backup – sikkerhetskopi av viktige data Duplisering – flere enheter som løser samme problem, og som kan dekke opp for hverandre. Fall-back – alternativ, men dårligere løsning som kan ta over i tilfelle feil Våren 2004 TDT4285 Planl&drift IT-syst

224 Fail-over ved full redundans
Samme prinsipp som for RAID1 tjener1 Opprinnelig To eller flere ekvivalente tjenere klient Auto fail over speiling tjener2 Etter feil på tjener1 Våren 2004 TDT4285 Planl&drift IT-syst

225 Overkapasitet ved N+1–redundans
tjener1 Trenger tre enheter Har fire enheter Ekstra kapasitet er en nyttig bieffekt Ved feil kan man leve med redusert kapasitet tjener1 tjener1 tjener1 Ekstra enhet Våren 2004 TDT4285 Planl&drift IT-syst

226 Single point of failure
Definisjon: SPOF er en enkelt komponent som helheten avhenger av. Eksempler: Strøm, datanett Redundans: eliminerer SPOF. spof spof Våren 2004 TDT4285 Planl&drift IT-syst

227 SPOF kan også være ønskelig...
Ta ut en feil på en kontrollert punkt (eksempel: sikring i et sikringsskap) Tillater oversiktlig punktsikring Bruken blir samtidig testing Det er betraktelig lavere kostnader Våren 2004 TDT4285 Planl&drift IT-syst

228 TDT4285 Planl&drift IT-syst
Eksempel: RAID5 NB: forenklet modell! ”Data” ”Paritet” Ekstra Disk1 Disk2 Disk3 Disk4 Disk5 Disk6 Disk7 Gjenoppbygging Av harddisk2 Våren 2004 TDT4285 Planl&drift IT-syst

229 TDT4285 Planl&drift IT-syst
Full og N+1–redundans N+1-redundans En ekstra av hver komponenttype Vanligvis for HW Implementert for utvalgte komponenter Full redundans Hele systemet er duplisert Dyrt (>2*kostnad) Kan implementeres for en hel site Våren 2004 TDT4285 Planl&drift IT-syst

230 TDT4285 Planl&drift IT-syst
Feller ifm redundans Fail-over blir til doblet levetid Like instanser med identiske bugs Installert men utestet Kjøpt – men falsk – trygghet Ingen garanti mot menneskelige feil Kan bli en ”hvit elefant” Våren 2004 TDT4285 Planl&drift IT-syst

231 Eksempel: Kjøling på IDIs maskinrom
Vifte Strøm Tilsvarende kjøleenhet Lukket kjøles- system Radiator Datagulv Vannverket Våren 2004 TDT4285 Planl&drift IT-syst

232 - Fordel av høyere oppetid
Kostnader Redundans koster mer Ekstra utstyr + Høyere kompleksitet NB: omtrentlig regnestykke + Mer vedlikehold - Fordel av høyere oppetid = Ekstra kostnader Våren 2004 TDT4285 Planl&drift IT-syst

233 Alternativ: recovery i stedet for redundans
Kostnader vs oppetid Kostnader 99,9% 99% 90% Oppetid Alternativ: recovery i stedet for redundans Våren 2004 TDT4285 Planl&drift IT-syst

234 Return On Investment (ROI)
Resultat med nulløsning (=R1) Resultat med investering (=R2) Kostnad av investering (=Invest) ROI = (R2 – R1) – Invest Merk at resultatene er basert på Ulike sansynlighetsfordelinger NB: svært forenklet Våren 2004 TDT4285 Planl&drift IT-syst

235 TDT4285 Planl&drift IT-syst
Våren 2004 Eksempel: en bil Dekk: 4+reservedekk (N+1 redundans) Bensin: Reservekanne (backup) Bremselys: To stk (full redundans) Bremser: håndbrekket (fall-back) Taxi: Kan ringes etter (out-soucing) S.belte og k.pute: ulik funk (duplisering) Frontlys: inkl p.lys (fall-back) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

236 TDT4285 Planl&drift IT-syst
Våren 2004 Navnerom TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

237 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon Et navnerom er et sett av mulige identifikatorer, som tilfredsstiller visse syntaktiske regler, og der hver identifikator er knyttet til en ressurs. Navnerommet er ofte endelig, eller endelig innenfor visse ikke-tekniske rammebetingelser. Viktig å huske at et navnerom er en ressurs, og som sådan må den administreres og gjetes. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

238 TDT4285 Planl&drift IT-syst
Eksempler på navnerom Brukernavn for innlogging Telefonnummer IP-adresser på Internett Maskinnavn UID-er for brukere URL’er på Web Nicknames på IRC Våren 2004 TDT4285 Planl&drift IT-syst

239 Kategorier av navnerom
TDT4285 Planl&drift IT-syst Våren 2004 Kategorier av navnerom Flate. Alle på ett nivå uten duplikater. Hierarkiske. Duplikater er tillatt, sålenge de befinner seg på hvert sitt sted i hierarkiet (eller nettverket) Anarkistiske. (først til mølla), en dynamisk prosess der man tilpasser et felles navnerom til situasjonen. Internett er hierarkisk, mens EARN/Bitnet var flate. Kan fortelle om Apollo, som hadde et flatt hierarki, slik at en maskin på kjemi ”overtok” som leder på nettet etter at Maskin bootet sine maskiner. Den satte deretter nytt systempassord. Både Windows og Mac har hatt tidligere systemer uten særlig hierarkisk struktur som har gitt voksesmerter. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

240 Fyllingsgrad av navnerom
TDT4285 Planl&drift IT-syst Våren 2004 Fyllingsgrad av navnerom Glisne navnerom. Der det er langt flere mulige navn enn det er navn som er tatt i bruk. Kompakte navnerom. Der en stor andel av navnene i navnerommet er tatt i bruk. Enkeltfeil kan gå upåaktet i kompakte navnerom, men kan fanges i glisne navnerom. Som eksempler på et navnerom som gikk fullt slik at man måtte utvide dem kan nevnes telefonsystemet, som var tresifret innen kommunen, deretter firsifret innen kommunen, deretter femsifret innen region med to retningssiffer, nå er det åttesifret nasjonalt. Det var visst nok for all fremtid (før vi fikk mobiltelefoner og kreativ bruk av telefonnummer). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

241 TDT4285 Planl&drift IT-syst
Navneromsmetrikker Diameter. Hvor mange systemer (maskiner) bruker dette navnerommet? Tykkelse. Hvor mange tjenester benytter seg av dette navnerommet? Konsistens. Når samme navnerom brukes parallelt, hvor stor grad av samstemmighet er det mellom deres tolkning av attributter? Våren 2004 TDT4285 Planl&drift IT-syst

242 TDT4285 Planl&drift IT-syst
Diameter og tykkelse NTNU IDI Norge Mail Web Print Samba Våren 2004 TDT4285 Planl&drift IT-syst

243 TDT4285 Planl&drift IT-syst
Eksempler på navnerom anders (brukernavn) (telefonnummer) (IP-adresse) furu (maskinnavn) 26806 (UID-er for brukere) Anchr (nickname på IRC) Våren 2004 TDT4285 Planl&drift IT-syst

244 TDT4285 Planl&drift IT-syst
Våren 2004 Tommelfingerregler Flate navnerom skalerer dårlig, og krever en sentral navneautoritet. Dynamiske navnerom er praktisk, men kan ha implikasjoner for sikkerhet og overhead. Hierarkiske navnerom som skal skaleres tilstrekkelig opp, krever en distribuert database. Planlegg godt, for navn lever veldig lenge! Problem med nummeriske navnerom er at de kan lure deg til å tro at de er sammenhengende mens det egentlig er huller i dem. Et eksempel var lisemaskinene, der lise1 og lise3-35 fantes, men ikke lise2, det var ment å kjøpe en ekstra tjener, men det ble aldri penger til den. Kan også fortelle om den studenten som argumenterte for at vi skulle kalle alle maskinene våre opp etter ulike modeller av stridstanks. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

245 TDT4285 Planl&drift IT-syst
Våren 2004 Fem navnepolitikker Merk at det finnes en rekke hybrider av disse: Formelaktige. F.eks pc001, pc002 etc Temabaserte. F.eks januar, februar etc Funksjonelle. F.eks mail, skriver, backup Anarkistiske. Dvs at alle velger sine navn Random. Tilfeldige verdier brukes Kan her nevne FIDI0001-FIDI999, som kom like etter at vi burde ha hett EIDTxxxx, mens vi idag burde ha hett EIDIxxxx. Viser ulempen med å overlagre for mye informasjon i navnet, spesielt når dette er redudant informasjon slik at det kan bli inkonsistenser. Merk at alle disse skalerer ulikt. Det er en rekke fordeler og ulemper med dem. Med temabaserte navn går man ofte tom for navn, eller navnet blir ikke endret når maskinen flyttes fra ett temaområde til et annet. De funksjonelle skalerer dårlig når det blir flere av dem. De formelaktige er upersonlige og de to siste har ingen struktur. Kan trekke paralleller til navngivning av skip og fly og gater og stjerner og månekratre. Kan også påpeke at man ofte velger de samme navnene. Alle maskiner skulle en stund hete odin, og maskin nummer to skulle hete tor. Derfor valgte IDT å kalle sigyn, yme, mime osv. Et annet eksempel er at fysikerne både ved UiO og NTNU bodde i Sem Sælands vei. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

246 Case: navngiving av skrivere
Organisatorisk. Etter gruppe og avdeling Rommessig. Etter rom og byggnavn Tema. Etter en eller annen fellesnevner Anarkistisk. Navnet er temmelig fritt valgt HW-messig. Modellnr er også navnet Serienr. Navnet er likt serienummer Formelaktig. Alle skriverne nummereres Våren 2004 TDT4285 Planl&drift IT-syst

247 TDT4285 Planl&drift IT-syst
Navnepolitikk Bør være formulert skriftlig Brukes ved opplæring Må håndheves (hvem er ansvarlig)? Hvilke navn er (ikke) godkjent? Hvordan (av hvem) velges navn? Hvordan håndteres kollisjoner? Operativt: skop, tykkelse, diameter etc Våren 2004 TDT4285 Planl&drift IT-syst

248 Sikkerhetsmessige implikasjoner
TDT4285 Planl&drift IT-syst Våren 2004 Sikkerhetsmessige implikasjoner Funksjonelle navn kan avsløre informasjon Avvik fra standard kan avsløre informasjon Tilgang til endringer (også tillegg) i navnerom kan være et viktig trinn for å bryte seg inn. All info om navnerom kan være nyttig ifm innbruddsforsøk. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

249 TDT4285 Planl&drift IT-syst
Våren 2004 Forgiftning av cache Yme 3. Falsk svar Tor 1. Forespørsel Odin 5. Bruk av tjeneste Falsk tjeneste Frøya 4. Ekte svar 2. Oppslag Ekte tjeneste Trym Frøy Navnetjener Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

250 TDT4285 Planl&drift IT-syst
Prosedyrer Oppretting, endringer og sletting Sikkerhetskopiering Revisjonskontroll Pensjonering og utrenskning Karantenetid etter bruk Våren 2004 TDT4285 Planl&drift IT-syst

251 Generiske navn og aliases
Fordi navn lever lenge ... lengre enn du tror, så bruk følgende strategi: Navngi ressursene etter formel eller tema Lag alias for hver funksjon Koble hvert alias mot dagens aktuelle ressurs. (Merk at ikke alle systemer har mulighet for aliases.) Våren 2004 TDT4285 Planl&drift IT-syst

252 Sentralisering eller desentralisering
TDT4285 Planl&drift IT-syst Våren 2004 Sentralisering eller desentralisering TDT4285 Planlegging og drift av IT-systemer Anders Christensen Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

253 Tjener eller peer-to-peer
Peer-to-peer: Maskinene er autonome enheter som deler hverandres ressurser. Eks: Win workgroups, Mac Tjener: Sentrale deler av systemet er samlet på dedikerte maskiner. Eks NT og Novell Våren 2004 TDT4285 Planl&drift IT-syst

254 Fordeler med peer-to-peer
Enkelt å komme igang med Skalerer bra initielt Autonomt, trenger ikke felles organisering Basert på naturlige ’power users’ Adm kostnader er innbakt Våren 2004 TDT4285 Planl&drift IT-syst

255 Fordeler med sentrale tjenere
Styrbart (gjennom f.eks strategier) Klare ansvarsforhold Adm overhead blir synlig Gjenbruk og deling av ressurser Variantbegrensning Tillater arbeidsdeling/spisskompetanse Utnyttbart økonomisk Våren 2004 TDT4285 Planl&drift IT-syst

256 Lite og lokalt, eller stort og sentralt?
TDT4285 Planl&drift IT-syst Våren 2004 Lite og lokalt, eller stort og sentralt? Sentralisering er kanskje svaret, men hva var spørsmålet? Er det så sikkert at brukerne er best tjent med en stor sentral driftsorganisasjon? Denne stripa fanger inn poenget med at man ikke kan få i pose og sekk. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

257 Sentraliseringskandidater
Drift av distribuerte systemer som er like nok til at de kan håndteres fra en sentral stab som spesialiserer seg. Tjenerkonsolidering for å redusere antallet maskiner ved at flere tjenester kjører på samme maskin. Våren 2004 TDT4285 Planl&drift IT-syst

258 Sentraliseringskandidater
TDT4285 Planl&drift IT-syst Våren 2004 Sentraliseringskandidater Infrastruktur: tjenester som brukes som en standardtjeneste og som er ’transparente’ Kompetanse: ved sentralisering kan man ta ut desto større stordriftsfordeler. Det er en fare ved å sentralisere kompetanse: Dersom man samler de dyktigste folkene i en sentral gjeng som driver med datamaskinene, risikerer man å bli sittende med de minst dyktige lengst ute, der hvor brukerne er, og organisasjonen ser generelt inkompetent ut utenfra. Det er mange eksempler som kan illustrere dette. Til en viss grad kan sikkert dette kobles mot marxistisk tankegods rundt fremmedgjøring. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

259 Desentraliseringskandidater
TDT4285 Planl&drift IT-syst Våren 2004 Desentraliseringskandidater Sære spesialsystemer, som du trenger spesialkompetanse på Feiltoleranse: desentralisering er duplisering og redundans Tett brukeroppfølging/-tilpassing Strategisk viktige systemer som man må ha kontroll over. Når det gjelder feiltoleranse: dersom det er desentralisert, så svikter det ikke alt sammen samtidig. Dette er ikke det samme som at man ikke har single-point-of-feilure. Man har tvert i mot mange av dem, men ingen av dem er like kritiske som en stort, sentralt ett. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

260 IVT-modellen for sentralisering
TDT4285 Planl&drift IT-syst Våren 2004 IVT-modellen for sentralisering Oppgaver som er felles for flere avd sentraliseres Gruppe Printere Institutt Mail Brukerstøtte Backup Fakultet Må ikke tas som en fasit på hva som skal sentraliseres!. Ulempen her er er at ansvaret for tjenester kan splittes og tildels fragmenteres, slik at en lokal halvdel kan ligge lokalt og en annen halvdel sentralt fordi det er flere som bruker den. Det tvinger også frem en standardisering fordi man får en one-size-fits-all, og det forutsetter at behovene er rimelig like. Eksempel tekstbehandling og matematikk. Spesialprogrammer Oppgaver som er spesifikke for enkeltavdelinger desentraliseres NTNU Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

261 TDT4285 Planl&drift IT-syst
Våren 2004 Problemstilling Ansvars- deling Lokal brukerstøtte Sentral driftsorg Tett kommunikasjon Den tette kommunikasjonen mellom bruker og lokal brukerstøtte gjør at denne lettere får større kredibilitet enn en langt mer fjerntstående person. Benytter Datamaskiner Bruker Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

262 TDT4285 Planl&drift IT-syst
Våren 2004 Outsourcing Du må: Vite hva du har og hva du trenger, Kunne uttrykke hva du skal be om, Bruke tilstrekkelig tid på forhandlingene. Outsourcing-partneren din har ofte en fordel på alle disse tre områdene! Her er eksemplet fra boka ypperlig, ledelsen fryktet at de ansatte ville lage bråk og kullkaste planene om outsourcing dersom de visste om det, så det ble forhandlet frem i hemmelighet. Dermed fikk de en avtale som ikke var tilstrekkelig god, og som blant annet ikke omfattet backups og målinger av hva som ble levert, men som de ikke hadde mulighet til å reforhandle. Det er ALDRI en god ide at ledelsen tar beslutninger i hemmelighet for så å selge inn en løsning etterpå gjennom en guidet prosess mot det allerede utvalgte målet. Da vil selv ikke vektige tekniske argumenter mot telle, noe som seriøst kan skade organisasjonen senere. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

263 TDT4285 Planl&drift IT-syst
Fremgangsmåte Bruk vanlig utrullingsteknikk Forsøk å forstå brukernes behov og forsøk å dekke dem Gjør et godt førsteinntrykk Lytt til brukernes behov, men husk at ledelsen sitter med kontrollen Våren 2004 TDT4285 Planl&drift IT-syst

264 TDT4285 Planl&drift IT-syst
Våren 2004 Revisjonskontroll SIF8076 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

265 Endringshåndtering og revisjonskontroll
Endringshåndtering er de prosessene som tar systemet fra en normaltilstand til en annen, f.eks ifm oppgradering, oppskalering el.l. (fremover) Revisjonskontroll er de mekanismene som holder oversikt over hvilke endringer som er gjort, av hvem, når, hvorfor, (bakover). Våren 2004 TDT4285 Planl&drift IT-syst

266 TDT4285 Planl&drift IT-syst
Spissformulering ”Sviktende endringshåndtering forårsaker, forsterker eller medvirker til 90% av alle dataproblemer.” Våren 2004 TDT4285 Planl&drift IT-syst

267 Utfordringen: Skalering
Informere mange brukere? Koordinere mange sysadm’er? Håndtere mange avhengigheter? Holde oversikt over alle bivirkningene? Kunne rulle tilbake enhver endring? Unngå ”oops-effekten”? Våren 2004 TDT4285 Planl&drift IT-syst

268 TDT4285 Planl&drift IT-syst
Endringsprosess Endrings- møte Godkjennelse Endring Endrings- forslag Kom- muni- kasjon Brukere ”Værforhold” Våren 2004 TDT4285 Planl&drift IT-syst

269 TDT4285 Planl&drift IT-syst
Hva er RCS? ”Database” over alle versjoner av en tekstfil Lagrer endringene for hvert ledd i utviklingen Lagrer historikk, brukernavn og kommentarer Håndterer parallelle utviklingsløp Gir låsemekanismer Våren 2004 TDT4285 Planl&drift IT-syst

270 Multiple utviklingstrær
Avgrening Merging Hovedlinje For uttesting Våren 2004 TDT4285 Planl&drift IT-syst

271 TDT4285 Planl&drift IT-syst
Hva kan RCS brukes til? Forhindre samtidig redigering på en fil Kan gjenskape gamle versjoner Kan granske endringene over tid Angir hvem som har gjort endringene Angir når endringene er gjort Våren 2004 TDT4285 Planl&drift IT-syst

272 Informasjonsmekanismer
Målrettet ”push” ”rekommandert” Generelt ”pull” oppslag (underskriftsliste) Enveis Toveis med ack Våren 2004 TDT4285 Planl&drift IT-syst

273 Variasjoner i konfigfiler
tor odin yme trym konfigfil1 Samme sybsystem konfigfil2 konfigfil3 konfigfil4 Alle instanser av en konfigfil Våren 2004 TDT4285 Planl&drift IT-syst

274 Konfigfiler fra sentral DB
Målmaskin Konfigdatabase Preprosessering Komplett med metadata En instans av fila Konfigfil Miljøinfo Våren 2004 TDT4285 Planl&drift IT-syst

275 TDT4285 Planl&drift IT-syst
Modell med lokal DB Tor Trym Sentral oppdater av konfigdata Lokal konfigDB Yme Odin Spm: er de fire databasene like? Våren 2004 TDT4285 Planl&drift IT-syst

276 TDT4285 Planl&drift IT-syst
Problemstillinger Hvordan håndteres revisjonskontroll på binærfiler? Grense mellom varianter og ulike konfigurasjonsfiler. Sentral revisjonskontroll forteller lite om hva som er aktivt lokalt. Våren 2004 TDT4285 Planl&drift IT-syst

277 Informasjon til bruker
Synkronitet. Samtidighet mellom den som gir og den som mottar informasjon. Målrettethet. I hvor stor grad er budskapet rettet mot bestemte personer. Acknowlegdement. Kreves det kvittering på at budskapet er mottatt. En- eller toveis. Går informasjon bare en eller begge veier Våren 2004 TDT4285 Planl&drift IT-syst

278 Tre oppdateringsprofiler
Rutineoppdatering. Endrer trivielle data uten egentlig innflytelse på funksjonalitet Hovedoppdatering. Endrer viktig funksjonalitet, og brukere merker endringene. Sensitiv oppdatering. En endring som kan få store konsekvenser dersom det går galt. Våren 2004 TDT4285 Planl&drift IT-syst

279 Oppdateringsprofiler
Gir ny funksjonalitet Oppgradere programvare Oppgradere operativsystem Gir samme funksjonalitet Patche for feilretting Generell patching Rette problem Ikke rette problem Våren 2004 TDT4285 Planl&drift IT-syst

280 Oppdateringsstrategi
Planlegg endringen Testkjør system før endringer Gjennomfør endringen Testkjør for å verifisere funksjonalitet Vurder back-out Våren 2004 TDT4285 Planl&drift IT-syst

281 TDT4285 Planl&drift IT-syst
Hva med små endringer? Det er to motstridende syn: Små, trivielle endringer kan fikses der-og-da, for de har liten innvirkning på system og det er dyrt å gjøre det ”korrekt”. Alle endringer som kan gi bieffekter eller på andre måter innvirke på andre personer eller programmer må håndteres som en endring. Våren 2004 TDT4285 Planl&drift IT-syst

282 TDT4285 Planl&drift IT-syst
Våren 2004 Automatisering TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

283 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon Automatisering (i konteksten av IT-drift) er å konkretisere en oppgave, løsning eller rekasjon som startes av seg selv på et nærmere bestemt tidspunkt eller situasjon; uten manuell inngripen. Skille fra automatisering i f.eks bilindustri, der det går på at arbeidsoppgaver skal utføres av roboter. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

284 TDT4285 Planl&drift IT-syst
Motivasjon Ressursbruk: gjenbruk av løsninger Personell: unngå repetitive oppgaver Stabilitet: ordne problemet en gang for alle Skalerbarhet: håndtere mange samtidig Oppetid: time-to-fix går drastisk ned Konsistens: samme løsning hver gang Våren 2004 TDT4285 Planl&drift IT-syst

285 T. Limoncelli tre regler:
Automate! Fokus bort fra teknisk vedlikehold,for å frigjøre tid til å hjelpe brukere og bedre systemets funsjonalitet. Våren 2004 TDT4285 Planl&drift IT-syst

286 TDT4285 Planl&drift IT-syst
Våren 2004 Dimensjon 1: Metoder Scripting Kobler flere enkelthandlinger. Proceduralt ”Programmeringsspråk” Utfører et program Tilstandsbasert Regelbasert Komplekst Sammenlikner tilstander Tilpasningsdyktig Tenk deg at du skal automatisere å kjøre bil fra Trondheim til Værnes. Med en skriptingsmetode forsøker du å lage en algoritme som skal ta hensyn til alle eventualiteter på turen – som et program. Med en tilstandsbasert metode har du korrigerende aksjoner for alle uønskede situasjoner som måtte dukke opp: utrykningsbil, snøbyger, veisperring, tom for bensin osv osv. Men det viktige er at de korrigerende aksjonene er definert isolert og enkeltvis, men settes sammen etter behov utfra en tolkning av situasjonen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

287 TDT4285 Planl&drift IT-syst
Våren 2004 Dimensjon 2: Holdning Aggressivt Oppgavemål i fokus Få/ingen sjekker Vanligvis midlertidig Ignorerer spesialtilfeller Forventes brukt manuelt Ignorerer feilkoder Defensivt Kvalitet i fokus Kontrollerer avvik Sjekker assumptions Sjekker resultatene Avbryter hvis uklart Spesialbehandling av farlige operasjoner Kan her fortelle om tegge, som alltid programmerte defensivt. Det vil si at en kan anta at man har kommet ett skritt videre ikke fordi man har utført en aksjon, men fordi man har verifisert at alt som kan gå galt under den aksjonen ikke har skjedd. Aggressiv programmering er ok for one-shot oppgaver som skal kjøres manuelt og der man hurtig må komme i mål. Også til rask prototyping (selv om det er en tendens til at prototyper blir satt i produksjon!). Mens defensiv programmering er best når noe skal ha innebygget robusthet og stabilitet, når det skal utføres mange ganger (slik at produksjonskostnadene blir spredd). Det _kan_ være en sammenheng mellom defensiv og tilstandsbasert på den ene siden, og mellom aggressiv og skripting på den andre siden. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

288 TDT4285 Planl&drift IT-syst
Våren 2004 Dimensjon 3: Målskive Symptom For å få bort bieffekter Hvis midlertidig bruk Hvis ufarlig/uskadelig Hvis man ikke forstår hva som skjer Årsak For å løse problemer Permanent løsning Sikkerhetsrelatert Det er svært farlig å fikse noe man ikke vet helt hva er, og som kanskje bare er symptomer. Det er imidlertid fristende! Fortell om cronjobber, der vi stadig finner at output er sendt til /dev/null. Det er gjerne fordi jobben genererer en irrelevant statusoutput som vi ikke er interessert i å se. Men det betyr også at vi ikke får med oss viktige feilmeldinger dersom jobben feiler. Ideelt sett burde output av jobben sendes gjennom et program som filtrerer bort output bare dersom det eksakt matcher en mal. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

289 Dimensjon 4: Utgangspunkt
Tidsmessig Regelmessig Administrativt Ryddeoppgaver Korrektive/reaktive Gjenstarte noe Reaktivt til noe Ordne opp Som bieffekt av en situasjon Våren 2004 TDT4285 Planl&drift IT-syst

290 TDT4285 Planl&drift IT-syst
Dimensjon 5: Output Levering: Pull kontra push Push girt aktiv output Pull fordrer at man oppsøker output Innhold: Positiv kontra negativ Positiv dersom ok resultat meldes Negativ dersom feil resultat meldes Hvordan meldes manglende resultat? Våren 2004 TDT4285 Planl&drift IT-syst

291 TDT4285 Planl&drift IT-syst
Spissformulering: Ingenting er så permanent som en halvferdig, temporær løsning som ser ut til å fungere. Våren 2004 TDT4285 Planl&drift IT-syst

292 Automatiseringsoperasjon
Utvalg av oppgaver Implementering Igangsetting Monitorering Kontinuerlig forbedring Våren 2004 TDT4285 Planl&drift IT-syst

293 TDT4285 Planl&drift IT-syst
Utvalg av oppgaver Det som kan gjøres likt hver gang Det som må gjøres likt hver gang Det som kjøres regelmessig Der hvor noe må reagere umiddelbart Det som er ulønnsomt (eller umulig) å bruke gjentatt arbeidsinnsats på Våren 2004 TDT4285 Planl&drift IT-syst

294 TDT4285 Planl&drift IT-syst
Implementering Implementere før man igangsetter Generalisere den manuelle oppgaven Teste og peer-review’e Teste på levende eller isolert system? Defensiv programmering Bestemme hvor automatikken slutter og manuell håndtering starter Våren 2004 TDT4285 Planl&drift IT-syst

295 TDT4285 Planl&drift IT-syst
Igangsetting Ekstra, manuell overvåkning i en overgangsfase Innfasing som alle andre tjenster (etter en-noen-mange) Opplæring og igangsetting av rutiner Våren 2004 TDT4285 Planl&drift IT-syst

296 Monitorering (i driftsfasen)
TDT4285 Planl&drift IT-syst Våren 2004 Monitorering (i driftsfasen) Overvåke for feilresultat fortløpende Overvåke for manglende kjøring med jevne mellomrom Overvåke for skaleringsendringer over tid (f.eks har fått mer data å prosessere) Fortell om jobben som skulle sjekke hvor mye hver bruke hadde på hjemmekatalogen sin. Den brukte quot, som var et program som var O(antall brukere*antall filer). Det fungerte bra med noen hundre brukere, men holdt på til utover formiddagene når det ble noen tusen brukere. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

297 Kontinuerlig forbedring
Analysere Prioriteringsplan Loggdata Monitorere Konstruere 3.linje 1-2.linje Igangsette Installerbart system Kjørende system Våren 2004 TDT4285 Planl&drift IT-syst

298 TDT4285 Planl&drift IT-syst
Mulige problemer Undertrykke feilmeldinger Agressiv programmering La temporær fiksing bli permante løsninger Glemme at automatikken kjører Ikke merke at automatikken ikke kjører Inkludere for mange manuelle ledd. Våren 2004 TDT4285 Planl&drift IT-syst

299 TDT4285 Planl&drift IT-syst
Våren 2004 Logging TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

300 TDT4285 Planl&drift IT-syst
Våren 2004 Definisjon Logging er å lagre korte, informative data kronologisk på et standardisert format om hendelser (eller tilstander) på en datamaskin. Ordet kommer av ”logg” og ”logging”, dvs å føre en kronologisk fortegnelse over hendelser. Opprinnelig fra sjømannsspråk, der ’loggen’ var en treblokk som man brukte når man målte farten på skipet, og loggboka var boka der man noterte ned fartsmålingene. Kommer av låg, et liggende tre, et stykke tre. Her kan det være fornuftig å ta med eksempler av en logg, for å vise hvordan dette ser ut i praksis. Men det er viktig å huske at formatet på logger kan variere kolossalt Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

301 Monitorering og management
Logging er nødvendig for godt management Uten: Feilsøke og fikse etter at problemet er oppstått og symptomene er erfart Med: Være i stand til å fikse det før eller når hendelsen skaper problemer, eller til og med før hendelsen inntreffer. Våren 2004 TDT4285 Planl&drift IT-syst

302 Logging, monitorering og statistikk
TDT4285 Planl&drift IT-syst Våren 2004 Logging, monitorering og statistikk Analyse Statistikk Batch Aggregeres til Bruk Logg Monitorering Tolkes/filteres I denne sammenhengen så genereres loggdata av hendelser, videre vil oppaggregerte loggdata bli til statistikk som presenteres som ett eller annet sammenfattende data, gjerne som funksjon av tiden. Under monitorering blir loggdata tolket og/eller filtrert i real-time for å trigge varsling (gjennom f.eks SMS) eller for å vedlikeholde en oversikt over nåtilstanden på systemet. Til slutt har vi at loggdata kan brukes for å analysere systemet, f.eks i forbindelse med feilsøking. Real-time Vedlike- holder Trigger Genererer Varsling Nåtilstand Hendelser Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

303 TDT4285 Planl&drift IT-syst
Våren 2004 Metoder for å logge Polling – gjentatte ganger (regelmessig) hente inn data. Kvalitativt: teste funksjonalitet Kvantitativt: måle ytelse Hendelse – at loggingen foregår som en konsekvens av en hendelse. På et vis kan man si at polling er forhåndsdefinerte hendelser, dvs at man genererer en hendelse. Kan ta med noen eksempler: temperaturen på maskinrommet på IDI, der man genererer hendelsen ’mål temperaturen’ som genererer loggføring av temperaturen, og dette samles i statistikk. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

304 TDT4285 Planl&drift IT-syst
Våren 2004 Bruksverdi av logging Visualisere Gjenskape Fakturering Tilstand Overvåke Bruksdata Statistikk Hendelser Logger kan brukes til mange ting, men det koker gjerne ned til tre ting: Bruksdata for å kunne vite og og dokumentere hvordan og hvor mye systemet brukes; hendelser for å kunne finne feil og anormaliteter; og endringsdata for tilstand, slik at man (i realtime eller ettertid) kan gjenskape og presentere systemets tilstand. Feilsøking Trender Automatisk reparasjon Dokumentere SLA-mål Sikkerhet Varsling Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

305 TDT4285 Planl&drift IT-syst
Post mortem-analyse Andre subsystemer? Andre maskiner? Like før? Hva ville være normalt? Hva var feilmeldingen? Når skjedde det? Rekkefølge i feilene? ”Vi vet at systemet krasjet klokken 14.06, men hva skjedde i minuttene og sekundene før dette?” Våren 2004 TDT4285 Planl&drift IT-syst

306 Autodetektering og -reparasjon
Feil logges Filter overvåker loggene Når feil finnes, kan automatisk reparasjon (eller varsling) startes Komponent Logging Reparasjon Logg Filter Våren 2004 TDT4285 Planl&drift IT-syst

307 TDT4285 Planl&drift IT-syst
Prediktering Utfra kunnskap om tidligere mønstre, kan man forutsi hva som vil skje når disse mønstrene er i ferd med å gjenta seg. Komponent Prediksjon Indikasjoner Logg Filter Våren 2004 TDT4285 Planl&drift IT-syst

308 TDT4285 Planl&drift IT-syst
Analyse Tradisjonell: filterprogrammering – sysadmin preparerer filtre for å fange opp forhåndsdefinerte situasjoner. Utradisjonell: maskinell analyse – datamaskinen analyserer selv sine logger og ekstraherer informasjon basert på generelle regler. Våren 2004 TDT4285 Planl&drift IT-syst

309 ”Information overflow”
TDT4285 Planl&drift IT-syst Våren 2004 ”Information overflow” Volum og variasjon i loggene hindrer oversikt og gjør det umulig manuelt å se mønstre i hva som er loggført. Mange maskiner + Volum Mange programmer Volumet på logger øker med antall maskiner, antall ulike programmer/tjenester som kjører og for så vidt også bredden i bruken av programmene. På en stor site gir det så mye og varierte data at det er fullstendig umulig å monitorere alt sammen manuelt. Manuell bruk av logger begrenser seg stort sett til post-mortem debugging. Bredden i antall mulige loggmeldinger, samt endringsraten gjør at det i praksis er umulig å forutsi alle mulig loggformater og type meldinger som vil komme. Dersom man allikevel ville forsøke på det, så vil antallet nye formater og situasjoner stabilisere seg på et mer eller mindre jevnt nivå som det fordrer en viss arbeidsinnsats for å håndtere. Min påstand: du kommer aldri i mål med å skulle lagre filtre eller tolkningssystemer for logger. + Variasjon Endrings- rate Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

310 TDT4285 Planl&drift IT-syst
Våren 2004 Filtrering Filtrering av loggdata kan: Finne bestemte data Sammefatte Fjerne det irrelevante og lage en ”rest”-liste Krever: Programmering! Logg Filter Dersom du allikevel skal programmere logg-filtre, så er dette de vanligste angrepsvinklene. Man kan søke etter bestemte data og trigge på dem. Man kan lage statistikk og sammendrag. Man kan prune bort det som bestemt er irrelevant og vise resten, som presumptivt er viktig. De to første er mulig å gjøre for et subsett av data. Det siste må gjøres for alle data, og er i praksis umulig å svelge unna. Et av problemene er at filtrene må justeres, tunes og kalibreres hele tiden. De må gjerne skrives som regulære uttrykk og er ikke lesevennlige. Det er vanskelig å se hvilke regler i et filter som kan saneres. Treff Sammen drag Rest Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

311 Ønskeliste for filtrering
TDT4285 Planl&drift IT-syst Våren 2004 Ønskeliste for filtrering Se subsystemer i sammenheng Ignorere følgefeil av initiell feil Detektere mønstre utfra historikk Forutsi videre utvikling Være selvkonfigurerende Ikke trenge manuell oppdatering Prioritere meldinger Dette er vanskelig, og trolig mat for oppgaver på dr.nivå. Tenk på det som en politimann som patruljerer gatene, og som med (ikke-kunstig) intelligens er i stand til å se mønstre og sammenhenger, og som deretter kan fokusere på de viktigste tingene å se nærmere på. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

312 TDT4285 Planl&drift IT-syst
Hvem varsler? Tre fremgangsmåter: Feilende komponent varsler Uavhengig, monitorerende system varsler Kombinsjon av 1 og 2 Alltid: bør ha mer enn en varsling på kritiske komponenter. Våren 2004 TDT4285 Planl&drift IT-syst

313 TDT4285 Planl&drift IT-syst
Våren 2004 Elementer ifm logging Sirkulære logger Personvern Rotasjon antall kopier Backup anonymisering gjenbruk Dersom personvern er viktig for deg, så sørger du for ikke å logge persondata, eller du anonymiserer det umiddelbart. Husk at logger kan leve lenge på backup! Fortell om bibliotekarene i USA som makulerte lånekortene i bøkene i bibliotekene da Patriot-loven ble skrevet, slik at de skulle slippe å måtte utlevere slike data til myndighetene. Det som ikke finnes kan heller ikke utleveres, det som er slettet en masse før det er blitt bruk for enkeltdata er ikke slettet for å obstruere enkeltsaker. fjernlager Plassbruk Kondensering mindre Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

314 Momenter ifm monitorering
TDT4285 Planl&drift IT-syst Våren 2004 Momenter ifm monitorering Varsel til hvem Hvor mange varsles Varsling parallelt eller serielt Koordinering mellom dem som får varsel Eskaleringsregler og repetisjonsfrekvens Kvittering på varsel Er varslets innhold forstålig Oppdatering ved endring av tilstand Kan nevne at jeg får meldinger fra Teknisk avdeling med varsel om temperatur i maskinrommet. De kommer som en bokstavsuppe: BAS 337EL02XX04a PRI 5 ( :41). Husk at varsling utenfor arbeidstid betyr at man skal ha vaktordning. Det er dyrt. Man bør ikke ha reelle vaktordninger der man går oftere enn en uke på og to uker av. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

315 TDT4285 Planl&drift IT-syst
Fallgruver Synkronisering av klokkene! Tidssoner og sommertid Ikke stol på dem: de kan slettes og endre av en innbryter syslog bruker UDP, og kan miste data Diskene fylles, eller ... sirkulære logger overskrives Våren 2004 TDT4285 Planl&drift IT-syst

316 Spilleautomater og kortlåser
TDT4285 Planl&drift IT-syst Våren 2004 Spilleautomater og kortlåser Er geografisk spredd Skal slutte å virke hvis de blir stjålet Må ikke virke dersom de ble illegalt tømt Må si ifra hvis de må tømmes Må ikke tillate den som tømmer å stjele Mulig defekte tastaturer Dårlig/skitten kortleser Treg mekanikk i dørene gjør at de ikke går igjen Bør kunne detektere at kort er blitt duplisert Hvis minne på kortleser er fullt, kan ramler noen brukere ut. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

317 SIF8076 Planlegging og drift av IT-systemer Anders Christensen, IDI
Helpdesk SIF8076 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst

318 TDT4285 Planl&drift IT-syst
Våren 2004 Helpdesks rolle Single point of entry IT-drifts- stab Kunder Helpdesk Fysisk Telefon Web Chat Helpdesk skal fungere som et mellomledd mellom brukerne og Driftsstaben. Det forutsetter at du har en organisering som er stor nok til at det er mulig å spesialisere en del av staben til sliik førstelinje innsats. Dette viser en tradisjonell modell. I tillegg kan helpdesken out-sources, slik at man kjøper disse tjenestene inn fra noen som er professjonelle på det. Farene er at man ser på brukerkontakt som noe eksternt og lite sentralt, samt at det slett ikke er sikkert at første linje har tilstrekkelig kompetanse. Fortell om Knut Røe på arkitekt som hadde en skriver som var i ferd med å brenne opp. ”Har du sjekket at strømkabelen sitter i?” ”Jada!” ”Har du sjekket begge ender av strømkabelen?” ”Hør her, det ER strøm på skriveren, den ryker og gnistrer av den jo!” ”Men har du sjekket begge ender av strømkabelen?” osv osv Magni: ”disken er død, den klikker når jeg skal forsøker å boot’e”. Har du forsøkt å starte maskinen?” ”Ja” Har du forsøkt å boote fra Windows rescue-CD” Jeg kjører ikke Windows.” ”har du forsøkt å reinstallere Windows?” ”JEg kjører ikke Window!” ”Da må du forsøke å reinstallere Windows, for det er sannsynligvis det som er feil.”. Det er aldri et teknisk problem at noen er overkvalifisert, kun et økonomisk problem. Til gjengjeld er det både et teknisk og indirekte et økonomisk problem at noen er underkvalifisert. Prosjekt- arbeid Avbrudds- styrt Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

319 Single point of entry – hvorfor
TDT4285 Planl&drift IT-syst Våren 2004 Single point of entry – hvorfor Beholde kontroll over tempoet Gjøre det enklere/likere for brukerne Bedre prioritere mellom oppgaver Oversikt over hva som er utestående La avbrytelser bare ’ødelegge’ i en enkelt del av organisasjonen Samle ekspertise på brukerkomunikasjon Generelt to ting: Være lynavleder for det som er forstyrrende og ikke strømlinjeformet. Samle brukerkontakt ett sted for å ha bedre oversikt. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

320 TDT4285 Planl&drift IT-syst
Våren 2004 Momenter ifm helpdesk Ikke alle har passende personlighet Tenk på plassering og interiør Beregn en ”tilstrekkelig” bemanning Annonser aktivt og målrettet Monitorer ytelse og metrikker Ta i bruk relevante verktøy Dersom du skal sette opp en helpdesk for din lokale organisasjon Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

321 Egnede personligheter (?)
TDT4285 Planl&drift IT-syst Våren 2004 Egnede personligheter (?) ``If we stopped caring about the customers, maybe they would stop bothering us?’’ Fra et sett postere som skulle være det motsatte av slike positive motivasjonspostere som er vanlig å henge rundt om på arbeidsplassene. Demotivational poster Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

322 Plassering og interiør (hvis fysisk!)
TDT4285 Planl&drift IT-syst Våren 2004 Plassering og interiør (hvis fysisk!) Plassering Et område der mange passerer jevnlig Finn et ”nøytralt” område Interiør: Tilstrekkelig med rom og luft Vennlige farger og møbler Fjern ”hang-arounds” og ”gamle venner” Plasseringen er mindre relevant dersom de fleste henvender seg via telefon eller epost. Dvs at man har et callcenter. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

323 Hva er tilstrekkelig bemanning
TDT4285 Planl&drift IT-syst Våren 2004 Hva er tilstrekkelig bemanning Forholdet mellom helpdeskstillinger og brukere avhenger av situasjonen: Ansatte ved forskning/univ: Studenter: ISP: Merk: tallene er eksempler! Det er komplett umulig å si eksakt hvor mange du trenger. Det avhenger av en rekke faktorer, som blant annet: Bredden på brukerne dine, og hvor mye forskjellige og nye ting de driver med. Hvor selvhjulpne er brukerne dine Hvor mye klarer du å ”skremme” dem bort? Referer til helpdesk med lang ventetid og dumme spørsmålslister. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

324 Annonsering og informering
TDT4285 Planl&drift IT-syst Våren 2004 Annonsering og informering Plassering Fokusering ”Ingen” leser dokumentasjon Timing Korthet Dok’en må spesialdesignes Repetering Alle har en knapphet på fokus, derfor trenger du å være veldig målbevisst på den informasjonen som spres. Gi rett type informasjon til rett tid på en slik måte at den er iøynefallende når brukerne selv føler et behov for den. Vanligvis leter ikke folk etter instruksjonsboka før noe har sluttet å virke. Variasjon Relevans & nytteverdi Forståelighet Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

325 Metrikker for helpdesk
TDT4285 Planl&drift IT-syst Våren 2004 Metrikker for helpdesk Antall kunder pr helpdesk-stilling Henvendelsesvolum og endringer Oppfyllelse av SLA Persondifferensiert opplæringsbehov Hvor mange prosent av jobbene eskalerer? Det er egentlig ikke så lett å sammenligne kunder, for de kan være svært ulike. Det som er viktig å se på er ikke bare volum, men også endringer Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

326 TDT4285 Planl&drift IT-syst
Våren 2004 Måltall for tidsbruk Problem Lukking Symtom Endelig tilbakemelding Fiksing Feilmelding Kort tid til første tilbakemelding kan gis ved automatisk svar, men det blir gjerne upersonlig, og brukere hater ofte slikt, fordi det forteller dem at de skal stille i køen og ta det med ro. Når en bruker har et problem, ønsker de at noen skal vise den oppmerksomhet. Det er kanskje ikke mulig eller økonomisk fornuftig, men de har allikevel ønsket. Fortell om nettorganisasjonen der de hadde 5 eller ti minutter på seg til å analysere problemet, og dersom de bommet, så var det trekk i bonus. 1 minutt 1 time Første tilbakemelding NB: måltall er bare gitt som eksempler Analyse 10 minutter Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

327 TDT4285 Planl&drift IT-syst
Våren 2004 Saker i en helpdesk Prioritering Eierskap Kontakt/kundeinfo Tidsforbruk Hvilket utstyr Tilstand og status Graderinger Historikk Koble like saker Lukke saker Dele opp saker Ta ut statistikk Søking i saker Prioritere mellom saker Fordele saker Eskalere saker På venstresiden står informasjon som er knyttet til en sak På høyresiden står aksjoner som man måtte ønske å knytte til en sak. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

328 Parametre for prioritet
TDT4285 Planl&drift IT-syst Våren 2004 Parametre for prioritet Omfang – hvor mange er omfattet av feilen (1 – 5 – 100 – alle)? Alvor – hva er konsekvensen av ikke å rette den (skjønnhet – ubehag – feil – krise)? Hyppighet – hvor ofte oppstår det (kontinuerlig – daglig – månedlig – 1gang)? Status – hvor viktig er feilmelder (betalende – ikke-betalende) Det er viktig å skille mellom disse fire dimensjonene av prioritet. Det er vanlig at en bruker mener at sitt problem bør ha høyere prioritet enn hva som objektivt er tilfelle. Derfor kan prioritet settes etter kundes status alene. Det er lite heldig, og de ulike deldimensjonene kan brukes for å objektivt regne seg frem til en faktisk prioritet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

329 Tilstandsdiagram for saker
TDT4285 Planl&drift IT-syst Våren 2004 Tilstandsdiagram for saker Ny Analysert Slettet Åpen I arbeid Dette viser et tilstandsdiagram for saker i et troubleticketsystem. Det er ikke uvanlig at slike tilstander er delt mellom ulike disjunkte sett av tilstander. F.eks kan Lukket-Slettet-Andre, og Avventer, Mer-info Åpen og Ny (disse fire er mest relevante for ’Andre’-tilstanden. Det kan også finnes ulike varianter av slettethet: f.eks arkivert eller fysisk slettet. Lukket Mer info Avvente NB: store variasjoner mellom verktøyene Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

330 Definer helpdeskens dekning
TDT4285 Planl&drift IT-syst Våren 2004 Definer helpdeskens dekning Hvilke maskiner og applikasjoner? Hvem kan henvende seg? Hvorhen retter man feil (jobb/hjemme/reiser)? Når kan man henvende seg? Hvor lenge kan man regne med å vente? Hvordan eskaleres problemet? Dette må være definert på forhånd, slik at både bruker, kunde og person på helpdesk har en noenlunde lik oppfatning av hvilke måltall som gjelder for hver av disse emnene. Det er en oppskrift på katastrofe dersom bruker har høyere forventning enn helpdesk har tjenesteinnstilling Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

331 TDT4285 Planl&drift IT-syst
Våren 2004 Hjelpemidler Trendanalyse – for å forutsi fremtiden. Statistikk – for å si noe om et større antall maskiner/brukere. Kvalitativ feedback – hva mener de mest profilerte (og oftest flinkeste) brukerne? Referer til Runit og deres god-hjelp: ja/nei tilbakemelding. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

332 TDT4285 Planl&drift IT-syst
Brukerstøtte – faser Problem- identifisering Planlegging og utførelse Velkomst Verifisering Velkomst- hilsen Klassifisering Beskrivelse Verifisering Alternativer Løsningsvalg Gjennomføring Av drift Av kunde Lukking Våren 2004 TDT4285 Planl&drift IT-syst

333 TDT4285 Planl&drift IT-syst
Velkomstfasen Ofte undervurdert (”det er jo bare et hallo”). Kritisk fase (lett å avvise brukerne). Kan lette neste feilmelding. Våren 2004 TDT4285 Planl&drift IT-syst

334 Problemidentifisering
Klassifisering – innenfor hvilket område ligger problemet. Kan delautomatiseres. Beskrivelse – lag en kort, konsis beskrivelse av problemet. Verifisering – sjekk at problemet kan reproduseres etter behov. Våren 2004 TDT4285 Planl&drift IT-syst

335 TDT4285 Planl&drift IT-syst
Utførelsesfasen Ulike løsningsforslag – foreslå en temporær, list mulige permanente løsninger. Ekspertoppg. Løsningsvalg – prioriter mellom løsningene, ta med bruker; og velg et løsningssett. Utførelse – la en Sysadm iverksette den valgte løsningen. ”Håndverk”. Våren 2004 TDT4285 Planl&drift IT-syst

336 TDT4285 Planl&drift IT-syst
Verifiseringsfasen Sysadm-verifisering – den som har iverksatt løsningen må teste arbeidet sitt før tilbakemelding om at det virker. Bruker-verifisering – den som har feilmeldt må få sjansen til å teste og bør tilbakemelde om hvorvidt problemet er løst. Våren 2004 TDT4285 Planl&drift IT-syst

337 TDT4285 Planl&drift IT-syst
Feilaktige roller Trollet – skremme bort brukeren ved helpdesk Videresenderen – brukeren sendes i ring Antageren – vet hva feilen er før feilmeldingen er lest Ikke-verifisereren – feilsøker uten å verifiere problemet Ryktesprederen – som videresender feilmelding til andre Feil-retteren – som retter ting på konseptuell feil måte Feilskriveren – klarer å få inn skriveleifer i skripts og cmd Hit-and-run-Sysadm – kommer; taster; stikker (tester aldri) Ole Lukkøye – sysadm’en som lukker tickets i det stille Våren 2004 TDT4285 Planl&drift IT-syst

338 TDT4285 Planl&drift IT-syst
Våren 2004 Datasentre TDT4285 Planl&drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

339 Planlegging av maskinrom
Plassering Adgang Sikkerhet Strømforsyning Kabling av strøm Ventilasjon Brannslukning Skap (rack) Luftsirk/kjøling Kabelføringer Datagulv Merking Kommunikasjon Konsolltjenere Arbeidsplasser Verktøy Våren 2004 TDT4285 Planl&drift IT-syst

340 TDT4285 Planl&drift IT-syst
Plassering Vanligst: i en kjeller Helst ikke for mye sol (kjøleproblem) Bør være sikret for ulykker og skader Tung på infrastruktur Må tas med i planleggingen av bygget Våren 2004 TDT4285 Planl&drift IT-syst

341 TDT4285 Planl&drift IT-syst
Adgang og sikkerhet For sikkerhet (dvs begrensning) Færrest mulige dører og vinduer Alle dører skal ha kontrollert adgang Kontroll på hvem som har tilgang For tilgang Lasteramper og varemottak (og heis) Bredde/høyde på dørene Våren 2004 TDT4285 Planl&drift IT-syst

342 TDT4285 Planl&drift IT-syst
Strømforsyning Dimensjonere strømforbruk Oppdeling i kurser Plassering av sikringsskap Nødstoppknapp Strømforbruk ved oppstart Kjappe/trege sikringer UPS forbruk? Dieselaggregat Våren 2004 TDT4285 Planl&drift IT-syst

343 Uninterrupted power supply
Signallinje for automatisk shutdown UPS Offentlig strømforsyning Strøm til maskinrom Mulig diesel- aggregat Nødstopp Batterier Våren 2004 TDT4285 Planl&drift IT-syst

344 TDT4285 Planl&drift IT-syst
UPS Batterier har levetid, må skiftes Husk å koble på lys på UPS Monitorere ytelse Viktig med tørrtesting Hvor stor kapasitet (i minutter) Automatisk inn og utkobling? Våren 2004 TDT4285 Planl&drift IT-syst

345 TDT4285 Planl&drift IT-syst
Kabling av strøm Alternative løsninger: Uttak under datagulv Uttak fra skinne i tak Uttak fra kabelgate langs vegg Ved pr-rack-UPS trengs færre strømuttak Regel: mange kurser og mye overlapp Vurdere egne datauttak for strøm Våren 2004 TDT4285 Planl&drift IT-syst

346 TDT4285 Planl&drift IT-syst
Ventilasjon Lite behov for luftutskiftning Kan brukes for å regulere temperatur Bør ha filtrering for å redusere støv Våren 2004 TDT4285 Planl&drift IT-syst

347 TDT4285 Planl&drift IT-syst
Brannslukking Vann gir store skader! Halongassanlegg er ikke lengre tillatt CO2 er effektivt men skummelt Bør slå av strøm (også UPS) og kjølevifter (røyk/støv-skader) Våren 2004 TDT4285 Planl&drift IT-syst

348 TDT4285 Planl&drift IT-syst
Dataskap Vanligst med 19’’ datarack Kan ha UPS eller strømfordelere på racket Krever rackmonterbare maskiner Maskinkassene er dyrere Velg løsninger med enkelt vedlikehold Rack-løsninger: Sideplater, dører, bakplater, viftebrett Braketter, blindplater Våren 2004 TDT4285 Planl&drift IT-syst

349 TDT4285 Planl&drift IT-syst
Luftsirkulasjon Hovedregler Maskiner: inn foran og ut bak Rack: inn foran/nede og ut oppe/bak Romkjølere: inn oppe og ut nede/under datagulv Hvordan finne optimal sirkulasjon? Bruk markør (sigar?) og termometer Eksperimenter med sideplater Våren 2004 TDT4285 Planl&drift IT-syst

350 TDT4285 Planl&drift IT-syst
Kjøling Effekt i (omtrentlig) KWatt To typer: Isvannsanlegg med ekstern kaldtvann Egen kjøleenhet med ekstern radiator ”Isvannsanlegg”: rundt C Fungerer som avfuktere av lufta Våren 2004 TDT4285 Planl&drift IT-syst

351 Eksempel: luftsirkulasjon
Kjøleenhet Vifte Frontside Strøm Bakside Lukket kjøles- system Radiator Datagulv 19’’ rack Vannverket Våren 2004 TDT4285 Planl&drift IT-syst

352 TDT4285 Planl&drift IT-syst
Kabelføringer Etterstrev permanent kabling Lag kabler med perfekte lengder Strips (ikke tape!) fast til kabelføringsveier Gjør det ryddig og pent Ikke-intuitiv kabling merkes i begge ender Vurder patchings/koblingspaneler Bruk fargekoding for kabler med ulik bruk Våren 2004 TDT4285 Planl&drift IT-syst

353 TDT4285 Planl&drift IT-syst
Datagulv Dvs gulv med 60x60cm-plater Hull i platene gir: Luftføringsvei ifm ventilasjon Mulighet for kabelføring Sikkerhetsmargin ved vannskade For store datarom: navngi hver plate Hevet gulv eller undergulv Våren 2004 TDT4285 Planl&drift IT-syst

354 TDT4285 Planl&drift IT-syst
Merking Ulike typer merking Tyverimerking (eierskap, kan ikke tas bort) Funksjon (midlertidig, endres ved behov) Fjerne merking som ikke lenger er korrekt Merk ting på en pen måte Bruk indirekte merking: Funksjonsmerking som er nærmest permanent Våren 2004 TDT4285 Planl&drift IT-syst

355 TDT4285 Planl&drift IT-syst
Konsolltjenere Ha færre skjermer enn maskiner! Gir mindre varmeutvikling Gir bedre plassutnyttelse Gir mindre kabling (mus/kbd har løs kabling) Løsning: konsollvekslere Enkle vekslere: kobling mellom likt utstyr Komplekse: kobling mellom Sun, PC etc Formater: VGA, seriekonsoll Våren 2004 TDT4285 Planl&drift IT-syst

356 TDT4285 Planl&drift IT-syst
Kommunikasjon Ha telefon tilgjengelig (evt mobiltelefon) Calling-anlegg? Ringeklokke på utsiden av kontrollert sone Våren 2004 TDT4285 Planl&drift IT-syst

357 TDT4285 Planl&drift IT-syst
Arbeidsplasser Maskinrom er ikke en egnet arbeidsplass Brukes bare for kortere arbeid på hardware Hørselvern? Etabler operatørrom ved siden av Støyskjerming og bedre temperatur Konsoller fra konsollvekslere settes der Gjerne glassvegg imellom Må ha direkteadgang via dør Våren 2004 TDT4285 Planl&drift IT-syst

358 TDT4285 Planl&drift IT-syst
Verktøy Etabler en rullende verktøyvogn Hold orden på verktøyet: Merk alt verktøyet La alle ting ha sine faste plass Bruk skrujern fremfor bit-sett Mulighet: personlig verktøy Våren 2004 TDT4285 Planl&drift IT-syst

359 TDT4285 Planl&drift IT-syst
Andre ting Hørselvern Operatør-rom Dokumentasjonsamling Adgang for vogner og trillebord Våren 2004 TDT4285 Planl&drift IT-syst

360 Feilsøking og -retting
SIF8076 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst

361 Fasene i feilsøking og -retting
Reprodu- serbarhet Feil- isolering Verifisering Feilmelding Retting Testing Tilbake- melding Doku- ment- ering Deployment Tilpassing Våren 2004 TDT4285 Planl&drift IT-syst

362 TDT4285 Planl&drift IT-syst
Våren 2004 Feilmeldingsfasen Få tak i mest mulig info om problemet Skaff eksakte feilmeldinger Skaff skjermbilder/transaksjonslogg Hva sier egentlig feilmeldingen? Hva er det brukeren ønsker å gjøre? Hva mener brukeren burde ha skjedd? Hvilke kontekst skjedde det i? Hva er det brukeren allerede har gjort? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

363 To hovedtyper problemer
TDT4285 Planl&drift IT-syst Våren 2004 To hovedtyper problemer Reproduserbare. De som du på kommando kan reprodusere. Ikke-reproduserbare. De som opptrer mer eller mindre sporadisk, og som du ikke kan fremkalle på kommando. Reproduserbare feil er enkle, for du kan analysere deg frem til hva som er feil. Ikke-reproduserbare feil er det som skaper problemer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

364 Ikke-reproduserbare feil
TDT4285 Planl&drift IT-syst Våren 2004 Ikke-reproduserbare feil Monitorer dem over tid. Iverksett en stresstest. Analyser deg frem til feilen Sett opp alarmer/varsling Historien om maskinene som gikk ned klokken 07.00, fordi rengjøringshjelpen ’lånte’ stikkontakten. Med reproduserbare feil kan du Verifisere at du faktisk fant feilen Teste at fiksen fikser feilen i ettertid Analysere deg enklere frem til hva som er feil. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

365 Prinsipper for feilisolering
Eliminere enkeltkomponenter Suksessiv refinement Fotfølge sporet fra A til Å Statistisk analyse av loggdata Våren 2004 TDT4285 Planl&drift IT-syst

366 Tips til feilisolering
Kikk på mellomformat Introduser ’print-setninger’ Sjekk opp loggene Analyser symptomene Single-step gjennom programmet Endre parametre og observer Les dok’en enda en gang Våren 2004 TDT4285 Planl&drift IT-syst

367 TDT4285 Planl&drift IT-syst
Våren 2004 Ulike årsaker Direkte årsak. Det som umiddelbart gjør at det ikke virker. Indirekte årsak. Det som forårsaker den direkte årsaken. Eksempel: en prof kommer og spør etter et scsi-kort til sin PC. Du kan enten gi det til ham og bruke mye tid på å installere det, eller lirke ut hva han skal bruke det til. Så viser det seg at han ikke kjenner til at det er scannere tilgjengelig, og at han har funnet en gammel scanner som han vil ha opp å kjøre på sin egen PC. Direkte årsak Indir. årsak Årsak Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

368 TDT4285 Planl&drift IT-syst
Verifisering Rett feilen midlertidig Verifiser at den forsvant Fjern fiksen Verifiser at feilen er kommet tilbake Repeter etter behov Midl.- retting Testing Fjern fiksen Testing Våren 2004 TDT4285 Planl&drift IT-syst

369 Ha de riktige verktøyene
TDT4285 Planl&drift IT-syst Våren 2004 Ha de riktige verktøyene For å se interne tilstander For å se på mellomformat For å ta ut konfigurasjonsdata For å samle logg- og utdata For å kjøre trinnvis Kompetanse, forståelse og innsikt! Diagnose uten skikkelige verktøy er gjettverk Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

370 TDT4285 Planl&drift IT-syst
Eksempler verktøy... Traceroute – liste nettverkspath Ping – sjekke konnektivitet Truss – liste systemkall Tcpdump – dumpe nettdata Lastcomm – presentere prosessloggen Våren 2004 TDT4285 Planl&drift IT-syst

371 TDT4285 Planl&drift IT-syst
Våren 2004 Noe man ikke bør gjøre Undertrykke symptomene Rette feil uten å forstå årsak Rette bare midlertidig Rette en feil ved å introdusere nye Rette en feil ved å redesigne systemet. Den siste er systemisk, i den forstand at det er den aller verste. Den ser elegant ut, men er den som skaper aller mest problemer. Alle de andre er ingeniørmessige ... Best practice. Men den siste er prinsippiell. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

372 Feilsøking og -retting
Feilsøking krever: Kreativitet Verktøykunnskap Systemoversikt Teknisk innsikt Generell erfaring Feilretting krever: Nøyaktighet Systemforståelse Historisk kunnskap Lokal spesialkunnskap Våren 2004 TDT4285 Planl&drift IT-syst

373 Feilhåndtering og linjedelt drift
(Prosjekter) 3.linje Retting Testing (”Drift”) Tilpassing 2.linje Feil- isolering Verifisering Dokument- asjon Reprodu- serbarhet Deploy- ment (Rutiner og brukerstøtte) 1.linje Feil- melding Tilbake- melding Våren 2004 TDT4285 Planl&drift IT-syst

374 Hovedkategorier av feil
Brukerfeil, forvirring eller misforståelse hos brukeren Rutineoppgaver, f.eks brukeradm og restore og andre forutsigelige oppgaver Feilsituasjon som skal rettes, der systemet har fått en feil Konseptuell feil med systemet, må gis ny funksjonalitet for å klare oppgavene. Våren 2004 TDT4285 Planl&drift IT-syst

375 TDT4285 Planl&drift IT-syst
Retting av feil 1.linje 2.linje 3.linje Veiledes Brukerfeil Rutineoppgave Utføres Feilsituasjon Verifiseres Rettes Konseptuell feil Verifiseres Feilsøkes Redesignes Våren 2004 TDT4285 Planl&drift IT-syst

376 TDT4285 Planl&drift IT-syst
Våren 2004 Retting og testing Retting. Gjør rettingen permanent, Distribuer den til alle maskiner. Testing. Test på mer enn en måte, fokuser fra mer enn en vinkel. Dobbelttest og trippeltest. Dokumentasjon. Sluttfør dok på hva du har gjort, og gi tilbakemelding til bruker Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

377 Fire strategier for feilretting
Korrigere før feilen oppstår Automatisk korrigere idet feilen oppstår Manuell korrigering når de første symptomene melder seg Opprydding når problemet er blitt merkbart Våren 2004 TDT4285 Planl&drift IT-syst

378 TDT4285 Planl&drift IT-syst
Kostnader (anslag) 4 Når problemet melder seg Nede tid 3 Når symptomet melder seg Automatisk retting 2 1 Før feilen oppstår Initielle driftsutgifter Våren 2004 TDT4285 Planl&drift IT-syst

379 TDT4285 Planl&drift IT-syst
Våren 2004 Akkumulative feil En kritisk feilsituasjon har sjelden bare ett enkelt problem som årsak. Dersom problemer korrigeres ASAP, kan man hindre at de blir delårsaker i komplekse feilsituasjoner. Merk, også kombinasjonsfeil, som er blant de vanskeligste å takle, fordi ansvaret kan ligge delt over flere organisasjoner. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

380 TDT4285 Planl&drift IT-syst
Våren 2004 Backup TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

381 TDT4285 Planl&drift IT-syst
Definisjon Backup er å benytte redundant lagring av informasjon for å unngå at denne forsvinner ved en feiltagelse, et krasj el.l. (dvs for å nøytralisere single point of failure). Våren 2004 TDT4285 Planl&drift IT-syst

382 Dimensjoner for backup
Omfang – alle eller bare viktige data? Nivå – alle eller kun endrede data? Grader –filinnhold eller også metadata? Redundans – antall kopier av hver fil Granularitet – hvor ofte tas backup Versjonering – antall versjoner bakover Endringsrate - % endringer i fildataene Våren 2004 TDT4285 Planl&drift IT-syst