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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Helter og teammedarbeidere
TDT4285 Planl&drift IT-syst Våren 2004 Helter og teammedarbeidere Heltemodellen Teammodellen Tett kommunikasjon 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

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

”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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kompleksitet og pålitelighet
Funksjon- alitet Brukers behov? Bugs (pålitelighet) Bredde i bruk Våren 2004 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

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

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

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

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

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

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

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

Overfasing til ny maskin
Begge tjenester operative en stund Gammel tjeneste Ny tjeneste Monitorering Bruker Våren 2004 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Skaleringsmodeller av drift
TDT4285 Planl&drift IT-syst Våren 2004 Skaleringsmodeller av drift Stor driftsorganisasjon 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

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

Definisjon Redundans er å bruke ekstra, overflødig kapasitet for å etablere en sikkerhetsmargin mot feil på systemet. Våren 2004 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

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

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

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

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

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

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

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

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

- 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

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

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

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

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

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

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

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

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

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

Diameter og tykkelse NTNU IDI Norge Mail Web Print Samba Våren 2004 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Endringsprosess Endrings- møte Godkjennelse Endring Endrings- forslag Kom- munikasjon Brukere ”Værforhold” Våren 2004 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

Multiple utviklingstrær
Avgrening Merging Hovedlinje For uttesting Våren 2004 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Automatiseringsoperasjon
Utvalg av oppgaver Implementering Igangsetting Monitorering Kontinuerlig forbedring Våren 2004 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

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

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

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

Analysere Prioriteringsplan Loggdata Monitorere Konstruere 3.linje 1-2.linje Igangsette Installerbart system Kjørende system Våren 2004 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

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

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

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

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

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

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

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

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

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

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

”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

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

Ø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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Uninterrupted power supply
Signallinje for automatisk shutdown UPS Offentlig strømforsyning Strøm til maskinrom Mulig dieselaggregat Nødstopp Batterier Våren 2004 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

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

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

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

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

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

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

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

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

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

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

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

Kommunikasjon Ha telefon tilgjengelig (evt mobiltelefon) Calling-anlegg? Ringeklokke på utsiden av kontrollert sone Våren 2004 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Våren 2004 Nivåer av backup Stor fil Basert på Basert på Filleting Nyfil Kjørefil Filleting Grov fil Inkr. backup Nivå 2 Inkr. backup Full backup Nivå 0 Nivå 1 Tid Tid Her er det viktig å få med forskjellen på full og inkrementell backup. I tillegg er det viktig å vise forskjellen mellom inkrementell på nivå 1 og nivå 2. Dersom vi hadde tatt en inkr nivå 1 i tilfellet lengst til høyre, så ville det tilsi at man baserer seg på den fulle backupen, og at man også får med nyfil. Ta med at dette fordrer at man kjører separate backupkjøringer, mens det er mulig at man vedlikeholder en backupdatabase, og da blir det helt annerledes. Stor fil Nyfil Stor fil Nyfil Stor fil Filleting Filleting Kjørefil Filleting Kjørefil Grov fil Grov fil Grov fil Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Full og inkrementell backup
Full backup: kopi av alle data Inkrementell backup nivå 1: kopi av alle nye/endrede data etter forrige fulle backup. Inkrementell backup nivå 2: kopi av alle nye/endrede data etter forrige backup på nivå 1. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Tre grader av backup 1. Speilkopi Innhold, metadata og ”implementasjon” 2. Alle data Index Filinnhold Index Innhold og metadata Filinnhold Det er tre grader å ta backup på, og i bunn og grunn skiller de seg kun på hvor mye kontekstdata man får med sammen med fildataene. De tre måtene er: Speilkopi tar kopi av alle data, inklusive hvordan dataene er lagret på harddisken. Denne tar til og med med seg framentering og harddisk-systemdata. Dette kan brukes for å rekonstruere en identisk harddisk. Kan brukes til sikre bevis og å lage ombyttbare kopier. Alle data, som tar med seg all informasjon som trengs for å rekonstruere en ny harddisk med ekvivalent innhold. Kan brukes til å ta vare på filene på et system. Fildata, som kun tar med seg innholdet i filene, samt noen metadata, spesielt filnavn, og oftest også dato. Dette kan brukes til å rekonstruere innholdet i filer, men ikke systemet. Kan brukes til å ta vare på brukerdata. Det er sjelden det er en ren backup av nivå nr tre, da man oftest har i det minste noen metadata. 3. Fildata Filinnhold Kun filinnhold Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Metadata som kanskje kopieres
TDT4285 Planl&drift IT-syst Våren 2004 Metadata som kanskje kopieres Access control lists (ACL) Eierskap og gruppetilhørighet Alle tidsstempler relatert til fila (typisk minst 3-4 for de fleste OS) Informasjon om ”hull” i filer Device-filer, spesialfiler og lenker Filattributter (R/O, skjulte, systemfiler...) Fortell om hull i filer og hvordan du kan drive en systemansvarlig til vanvidd ved å lage en diger fil med et hull, slik at den bruker få blokker på harddisken, men bruker en evighet for å tas backup av (fungerer kanskje ikke lengre når man har fått komprimerende tapestasjoner). Med mindre alle disse metadataene tas vare på, kan man ikke regne med å bruke en backup i en restoreoperasjon etter f.eks en diskkrasj, man kan få tilbake innholdet i filene, ikke ikke rekonstruere helheten. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Backupmetoder Bruker er selv ansvarlig for å ta sin egen backup Alle versjoner av hver fil lagres Bruker Versjonering Harddisk Full Den tradisjonelle er selvfølgelig backup til tape. Etterhvert har det kommet backupsystemer som vedlikeholder en database av filer. Dette er mer å regne som en slags remote lagring av filer, gjerne på et billig RAID-system, da det vanligvis ikke er ytelseskritisk. Merk at det finnes hybridversjoner av disse fire metodene. Oppdatering Backup- database Tape backup Inkrementell Alle data lagres 1 gang i en database Tapestasjon 1 tape pr dag Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Redundans og granularitet
TDT4285 Planl&drift IT-syst Våren 2004 Redundans og granularitet Anta schedule: Full hver mnd Inkr nivå 1 hver uke Inkr nivå 2 hver dag Taperotasjon 6mnd Worst case: en fil med en levetid på 1mnd finnes bare på en tape. For hver tape som blir defekt, hvor mange filer ”mistes” permanent? Sannsynlighet for restore gitt en fils levetid og et antall defekte taper? Kortvarige data er vanskelige å fange opp backup av. En fils sannsynlighet for restore er avhengig av antallet ganger den er blitt tatt backup av og faktisk kopiert (dvs antallet kopier som finnes). Den burde være avhengig av antallet backup-kjøringer den har vært igjennom, men de to har ikke nødvendigvis noe indre forhold. Hva skiller de to begrepene? Redundans sier noe om ekstrakopiering av en fil, mens granularitet sier noe om tidsluka mellom to backuper som en ny fil vil bli fanget opp av. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Må hele fila tas backup av?
TDT4285 Planl&drift IT-syst Våren 2004 Må hele fila tas backup av? Append Ford Juli Backup av hele fila Databasefil Opel Juni August Backup kun av tillagt post Mercedes Mai Backup kun av endret post Volvo April Jo dummere (eller mer fundamentalt) backupsystemet ditt er, jo oftere må du ta backup av hele filer selv når det er mindre data i den som endrer seg. Dette er tilfelle ved stor grad av ortogonaltet mellom programvaren som bruker filene og backupprogramvaren, og isolert sett regnes det som en fordel, selv om det skaper problemer her. Citroen Append-only loggfil Mars Update Backup av hele fila Rolls Royce Februar Mazda Lada Januar Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Backup - proaktivt eller reaktivt?
TDT4285 Planl&drift IT-syst Våren 2004 Backup - proaktivt eller reaktivt? Proaktiv fase Reaktiv fase Tape Rutine Tidsnød Restore Backup Restoret harddisk Original harddisk Krasj Backup er et kroneksempel på en aktivitet som har både en reaktiv og en proaktiv fase. Nettopp derfor er det at backup ”ikke fungerer” i organisasjoner som er ekstremt reaktive. Hver gang man trenger backup, viser det seg at de proaktive rutinene hadde feilet ... også denne gangen. Det ligger i backupens natur at man ikke kan oppveie den et underskudd på aktivitet i den proaktive fasen med ekstra innsats på den reaktive fasen. Tidsakse Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Lokasjon for lagring av tape
TDT4285 Planl&drift IT-syst Våren 2004 Lokasjon for lagring av tape Innbrudd Branntilløp Utbrenning Nedbrenning Leirras Samme bygning Nabobygg Samme rom Vær oppmerksom på at i taperoboten er tapen online, og derfor sårbar for angrep over nettet. 1 2 3 4 5 Taperobot Brannsafe Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Arkivbackup Ta et eget backupsett, som er separat fra daglig backup Plukk ut et sett taper fra daglig backup som utgjør et enkelt komplett sett Dobbeltlagre full backup av hvert disk til en egen arkiv-tapestasjon, og lagre som arkivbackup når den er komplett Våren 2004 TDT4285 Planl&drift IT-syst

Tidsaspekter ved backup
Tar backup oftere enn restoring, så det er viktig å automatisere backup Ofte tidsnød ved restore (reaktivt) Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Noen måltall Tid for nattlig backupkjøring Antall dager for en full backupsyklus Tid for å restore en enkelt, liten fil Tid for å restore største disk/RAID Overføringsrate ved restore Komprimeringsgrad for dataene Alle disse må overvåkes og monitoreres. Eksempelvis kan nattlig kjøring over tid vise seg å vokse og begynne å overlappe med arbeidstiden påfølgende dag. Det kan gi alvorlig degradering av ytelse. Det er også viktig å monitorere disse måltallene med jevne mellomrom, for å detektere trender, samt å monitorere for feil fra hver dags kjøring av backup. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Backup-schedule ved IDI
Full backup hver 10. dag Inkrementell backup hver dag Full/inkr tas vare på i 60 dager Arkivbackup 3-4 ggr pr år. Inkrementell Dager Full Partisjoner Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Noen ops!-faktorer Ingen har testet hvor lang tid en full restore tar Lisensen på backupprogramvaren har gått ut og ingen kan restore data Ingen hadde sjekket loggene, og alle tapene fra siste 5 mnd var tomme Fortell om den gangen noen på IDI mekket på backupsystemet, så den brukte rewinding device i stedet for nonrewinding, og at det tok uker før noen oppdaget det. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Case: Situasjonsbeskrivelse
Brevjournalen var korrupt Kjører på SQL-server Backup fra de to siste dagene korrupt Lignende har skjedd to ganger tidligere Måtte rekonstruere for to dager Journalen skulle vært faset ut Mange feil i liten del av systemet Våren 2004 TDT4285 Planl&drift IT-syst

Opprinnelig system Bruker Database Backup1 Backup2 Alarm! Våren 2004 TDT4285 Planl&drift IT-syst

Problemfaktor 1 Backupen er drevet rent reaktivt – det vil si at man korrigerer og justerter etter feil; men man er uten kvalitetskontroll før situasjonen har nådd en kritisk grense. Ingen brannøvelser. Våren 2004 TDT4285 Planl&drift IT-syst

Problemfaktor 2 Implementering og igangsetting av databasen skjedde ad hoc uten hensyn til innspill fra drift, innen områder som teknologivalg og driftskostnader. Databasen var ’gratis’. Våren 2004 TDT4285 Planl&drift IT-syst

Problemfaktor 3 Databasen måtte kjøre på et mer eller mindre selvstendig, isolert system – dels for å isolere dens egen ustabilitet, og dels fordi den forutsatte andre enn standard teknologivalg. Våren 2004 TDT4285 Planl&drift IT-syst

Problemfaktor 4 Kvaliteten på backup av databasen fikk lov til å bli redusert uten at det ble oppdaget og korrigert (hvis bare databasen selv fungerte). Man sjekket ikke kvaliteten før man trengte dataene fra backup. Våren 2004 TDT4285 Planl&drift IT-syst

Problemstilling 5 Ingen merket feilmeldingene fra den nattlige backupkjøringen i vrimmelen av andre daglige meldinger. Våren 2004 TDT4285 Planl&drift IT-syst

Mulig løsning 1 Introduser avhengighet! La databasen være avhengig av backup, slik at defekter i backup umiddelbart blir synlige. Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1a – diagram Trinn 2 bytte Bruker Database Backup Trinn 1 kopiering Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1a - momenter Tvinger evt backup til å være konsistent (ellers vil brukerne klage) Men: detekterer ikke hvorvidt backup faktisk er tatt Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1b – diagram Trinn 2 bytte Bruker Database Backup Trinn 1 kopiering Alarm2 Alarm1 Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1b – momenter Som løsning 1a, samt ... En alarm detekterer om backup ikke tas – og varsler brukerne For å sikre seg mot at alarmen slutter å virke, kan man legge til enda en alarm som sjekker den første. Men: kan ikke sikre seg at ikke alle alarmene slutter å virke på en gang Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1c – diagram Trinn 2: bytte Bruker Database Backup Trinn 1 kopiering Alarm2 Alarm1 Våren 2004 TDT4285 Planl&drift IT-syst

Løsning 1c – momenter Som løsning 1b, samt ... Alarmene er uavhengige av hverandre (helst på to ulike OS) Alarmene er symmetriske (dvs at de vokter på hverandre) Alarmene går til noen som vil reagere, dvs brukerne Våren 2004 TDT4285 Planl&drift IT-syst

Etikk for systemadminstratorer
TDT4285 Planl&drift IT-syst Våren 2004 Etikk for systemadminstratorer TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Sage Code of Ethics Satt sammen av Sage (System Administrators’ Guild Konteksten er amerikansk Snarere et ”credo” enn lover. Flere utgaver (utgaven som gis her er senere blitt utvidet) Etikk er prinsippene for som man oppfører seg etter, og som styrer en gruppe mennesker Moral er drøfting av hva som er rett og riktig Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

The integrity of a system administrator must be beyond reproach
Canon #1 Integritet The integrity of a system administrator must be beyond reproach Våren 2004 TDT4285 Planl&drift IT-syst

Canon #2 Brukerrettigheter
A system administrator shall not unnesessarily infringe upon the rights of users. Våren 2004 TDT4285 Planl&drift IT-syst

Canon #3 Kommunikasjon Communications of the system administrators with all whom they may come in contact shall be kept to the highest standards of professional behavior. Våren 2004 TDT4285 Planl&drift IT-syst

Canon #4 Etter- og videreutdanning
The continuance of professional education is critical to maintaining currency as a system administrator. Våren 2004 TDT4285 Planl&drift IT-syst

A system administrator must maintain an exemplary work ethic.
Canon #5 Arbeidsmoral A system administrator must maintain an exemplary work ethic. Våren 2004 TDT4285 Planl&drift IT-syst

Canon #6 Professionalitet
At all times system administrators must display professionalism in the performance of their duties. Våren 2004 TDT4285 Planl&drift IT-syst

Expanded Sage Code of Efthics
Fair treatment Privacy Communication System integrity Cooperation Honesty Education Social responsibility Quality Ethical responsibility Våren 2004 TDT4285 Planl&drift IT-syst

Om du blir bedt om noe ”ulovlig”
Be om skriftlig ordre Ta det opp med sjefen Drøft det med kolleger Snakk med fagforeninger Snakk med advokat Før nøyaktig logg over hva du gjør Nekt, men forklar hvorfor Våren 2004 TDT4285 Planl&drift IT-syst

Personvern og logger Persondata er data som kan knyttes til bestemte personer, men ikke Anonymiserte data Statistikk Trivielle data Data som ikke er persontilknyttbare Våren 2004 TDT4285 Planl&drift IT-syst

Behandling av personlige data
Be om lov til å se på dem først. Om mulig, filtrer ut bare de interessante delene og se kun på dem. Ha et vitne, gjerne brukeren selv. Logg hva som gjøres. Behandle dataene maskinelt om mulig. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Priviligerte konti Unngå felleskonti – bruk personlige passord Hold god passordhygiene Gi privs etter behov og kompetanse Logg hva som skjer Opplær admins, også i etikk Ha en AUP for admins Her er det i tillegg viktig at priviligerte konti ikke skal aksesseres fra upriviligert utstyr. Det kan være nødvendig å ha en dyr skjermsvitsj for å unngå å måtte logge seg på tjenere for administrativt arbeid over nettet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Disiplinærsaker Undersøk før du handler Før logg over hva du gjør Ta kopi av data – frys situasjonen Informer brukeren La brukeren forklare seg Hvis i tvil, dytt saken oppover Enkelte saker bør politiet ordne opp i Generelt er det lurt å undersøke før du handler, men i enkelte situasjoner må du allikevel handle der og da. Det som er viktig er å unngå å ende som aktør i noens vendetta mot noen andre. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Case #1 Bruker klager over at innlogging på Windows går tregt, og bruker flere minutter Enkel feilsøking viser 800MB med filer på brukers profil. Det er temmelig påfallende at de fleste av disse filene er mp3-filer og sannsynligvis av kommersiell musikk. Våren 2004 TDT4285 Planl&drift IT-syst

Case #2 Professor ringer og vil ha tilgang til alle filene på en katalog til en av sine stipendiater. Stipendiaten det er snakk om er i utlandet. Professoren sier at de skal levere inn en artikkel for publisering ”i går”. Våren 2004 TDT4285 Planl&drift IT-syst

Case #3 Bruker sender mail til support og klager på noe rundt bruk av e-post, f.eks. så som en returnert melding. Dette kan bare feilsøkes ved å se på brukers allerede mottatte . Det kan virke som om bruker antar og godtar at du ser på posten hans. Våren 2004 TDT4285 Planl&drift IT-syst

Case #4 Organisasjonen din er hardt plaget av spam. Du vet at du kan filtrere ut ca 60% av all spam ved å sette opp bestemte filtre. Men samtidig vil du minste rundt regnet 2-3 legale meldinger pr dag. Våren 2004 TDT4285 Planl&drift IT-syst

Case #5 Disken har relativt fort gått komplett full. Under feilsøking oppdager du en gruppekatalog der det er lagret veldig mye data. En rask fillisting av disse dataene indikerer at det er filmer og bilder, og at innholdet formodentlig er pornografisk. Våren 2004 TDT4285 Planl&drift IT-syst

Case #6 En epostmelding med intime betroelser er ved en feiltakelse sendt til deg, i stedet for til en annen bruker med forvekslbar adresse. Våren 2004 TDT4285 Planl&drift IT-syst

Case #7 Sjefen din har sterk mistanke om at en ansatt lekker opplysninger til en konkurrent. Sjefen din ber deg om å gå igjennom eposten til den ansatte for om mulig å finne indikasjoner som kan styrke denne mistanken. Våren 2004 TDT4285 Planl&drift IT-syst

Case #8 Sjefen din ønsker å vite hvem som surfer på Web på jobben. Han vil helst ha en liste over hvem som har surfet hvor mye på hvilke sites, aller helst sortert slik at de mest irrelevante sites listes først. Våren 2004 TDT4285 Planl&drift IT-syst

Case #9 Det kommer klage ”utenfra”, på en lokal bruker som har involvert seg på en epostliste med et etnisk tema. På denne lista har brukeren sendt hatmail, useriøse innlegg og store filer (core-dumps). Våren 2004 TDT4285 Planl&drift IT-syst

Case 10 En av brukerne dine er dypt uenig i amerikansk utenrikspolitikk. Etter en hendelse som opprørte ham, satte han opp en jobb som sender ca 4000 likelydende protestskriv pr time over epost til Våren 2004 TDT4285 Planl&drift IT-syst

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

Prosessen Analyse Brannøvelse Planlegging Forberedelse Bruk Review Våren 2004 TDT4285 Planl&drift IT-syst

Analysefasen Ypperlig for out-sourcing Bør håndtere alle relevante situasjoner Må identifisere viktige applikasjoner Mulighet for synergieffekt mellom ulike mottiltak for katastrofesituasjoner Vanligvis basert på historisk og retrospektiv kunnskap Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Kostnadsoverslag (KatKost – AvvergKost) x Sannsynlighet KatKost er kostnadene ved katastrofe AvvergKost er kostnadene til planlegging og avverging av katastrofen i tilfelle den inntrer. Sannsynlighet er sannsynligheten for at den bestemte katastrofen skal inntreffe. Og så er det i endel tilfeller aldri så enkelt. Av og til er kostnaden ved en katastrofe så høy, og/eller sannsynligheten så lav at denne utregningsformen blir vanskelig å sette opp, eller irrelvant. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Planleggingsfasen Et sikkert lager/maskinrom må finnes off-site Off-site lager må inneholde alt nødvendig Lagret utstyr må holdes oppdatert Oppdatert backup må lagres off-site Alternativ hardware må være tilgjengelig Planen må være testet Forsikring og økonomisk dekning må være ok Våren 2004 TDT4285 Planl&drift IT-syst

Nyttig informasjon Kontaktinfo til ansatte og leverandører Hvem kan autorisere kostnader Hvem leder arbeidet Oversikt over data og alternativ site Avtaler, lisenser og media Prioriteringer Hvem uttaler seg utad Våren 2004 TDT4285 Planl&drift IT-syst

Komplett eller billig? Katastrofeplan Oppgaveorientert Fullredundant Rutiner Uttestet Komplett ”Katastrofestrategi” Retningslinjer Målsetninger Hjelpeinfo Rammeverk Tilpassningsdyktig Enklere Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Skadestedsarbeid Kontakt innad (infoansvarlig) Lage ny løsning Skadestedsleder Og så skal man vel heller ikke glemme brukerne, sånn som det ser ut på denne modellen. Hva har skjedd? Linje organisasjon Kontakt utad (presse) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Skadestedslederen Hvem bestemmer hva som skal reetableres i hvilken rekkefølge. Tar bestemmelse om avvik fra planen etter behov. Allokerer ressurser til oppgaver, helst så hver har kun ett ”fokus” av gangen. Slår ned på ryktespredning, antagelser, handlingslammelser og synsing. Våren 2004 TDT4285 Planl&drift IT-syst

Håndteringsmåter Avverge – hindre at problemet oppstår Detektere – oppdage problemet tidligst mulig Dempe – sikre at effektene blir minst mulig Redundans – hindre at problemet slår deg ut Gjenoppbygge – planer for rask, ny oppstart Våren 2004 TDT4285 Planl&drift IT-syst

Eksempler BRANN! Gjenoppbygge Redundans Reetablering Duplikat i annet bygg Detektere Dempe Avverge Fokuserer På løsning Angriper problem Brannhemmende materialer CO2-anlegg Brannvarsling Våren 2004 TDT4285 Planl&drift IT-syst

Dempe eller avverge skader
TDT4285 Planl&drift IT-syst Våren 2004 Dempe eller avverge skader Alltid nyttig Detektere Avverge Dempe Er det alltid viktig å avverge problemer? Litt flåsete kan man si at dersom man avverger alle problemer, så vil brukerne tro at det ikke er noen problemerer. Det kan være både billigere og strategisk lurere å arbeide med å dempe virkningene av problemer, slik at brukerne merker at noe har skjedd, men samtidig opplever at drift raskt avklarer. Kostnader er viktig Oppetid er viktig Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

(Brann-)øvelser Må gjennomføres før planen kan sier å være operativ Bør holdes jevnlig Bør være realistiske Danner grunnlag for rafinering og forbedring av planene Våren 2004 TDT4285 Planl&drift IT-syst

Forslag til brannøvelse
Skru av strømmen til maskinrommet Skift lås på døra til maskinrommet Verifiser at staben klarer å få systemet operativt igjen innen planlagt tid. Ulempe: det er dyrt Ulempe: risikerer et avbrudd for brukerne Fordel: det er svært realistisk Våren 2004 TDT4285 Planl&drift IT-syst

Faser i en katastrofe Hendelsen Førstehjelp (initial response team) Skadeestimat (impact assessment team) Oppstart (startup team) Full drift Våren 2004 TDT4285 Planl&drift IT-syst

Hva er en katastrofe? Vann- lekkasje Meteor- nedslag Leirras Medarbeider som blir gal Gissel- aksjon Lyn- nedslag Krig Flystyrt Oversvømmelse Bombe 400V på nettet Politi- aksjon Gass Hundreårs- bølgen Brann Jordskjelv Acts of God Våren 2004 TDT4285 Planl&drift IT-syst

Det skjer aldri her … En fredag i juli 1987, Edmonton, Canada Kl det går ut tornado-varsling Kl syv døde, hundrevis skadet, dusinvis av bedrifter fantes ikke lengre. Våren 2004 TDT4285 Planl&drift IT-syst

Merk følgende: Ved katastrofer: Sikkerheten lider pga ad hoc løsninger Regnskap og logging får huller Kan misbrukes til innbrudd Planen må være innøvd Utfør en debrifing i etterkant Våren 2004 TDT4285 Planl&drift IT-syst

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

Gitt en faktura ... Revisjon – hvordan er pengene brukt. Dokumentasjon – vise at utstyret er en eget. Revisor Økonomer Internktrl Faktura Utstyr Tyveri Gjenbruk Garanti Våren 2004 TDT4285 Planl&drift IT-syst

Utfordringer Hvilket utstyr er angitt på en gitt faktura? Hvor står alt utstyret? Hvilket utstyr har vært reparert? Hvilket utstyr har hvor lang levetid? Hva er på reparasjon/utlån? Hvem er ansvarlig for hva? Hvilket utstyr er evt ikke i bruk? Våren 2004 TDT4285 Planl&drift IT-syst

Levetidssyklus for utstyr
TDT4285 Planl&drift IT-syst Våren 2004 Levetidssyklus for utstyr Tilbud Avhending Kassasjon Bestilling Reparasjon Deinstallasjon Dette er en sterkt en forenklet modell, men den fokusserer på det vesentlige: at det er en prosess for å anskaffe utstyr, og annen prosess for å avhende utstyr, og de befinner seg i hver ende av utstyrets livssyklus, i tillegg har man et løpende behov for oversikt i hele utstyrets levetid. Levering Installsjon Bruk Ta ut av drift Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Midler for oversikt Nettverkskort – fra switch’er Strekkodemerking – på bokser Serienummer – på alle komponenter Brennmerking – mot tyveri Inventory – automatisk innsamlet Databaser – manuelt oppdatert Elektronisk – via brikker Våren 2004 TDT4285 Planl&drift IT-syst

Viktig å kunne svare på Hva er typisk kostnad for ulike varianter av utstyr? Hva er feilrate for utstyrstyper? Hvilket utstyr kan gjenbrukes? Hvor mye av utstyret er overkill? Har vi nok lisenser (for få, for mange) Våren 2004 TDT4285 Planl&drift IT-syst

Levetidskostnader (TCO)
Innkjøpskost/levetid Personellkostnader Reservedeler Overkapasitet Brukt rekvisita HW-oppgraderinger SW-oppgraderinger Nettverkskostnader Tjenerkostnader Strøm/kjøling Opplæring Egenadministrasjon Ergonomiske kostn. Arealkostnader Våren 2004 TDT4285 Planl&drift IT-syst

Eksempler på TCO Typisk org: $7251 pr desktop pr år [Kauffman] Høyeste: $ pr år (finansanlytikere og valutahandlere) [Kauffman] NTNU NOK pr år (IDI) Våren 2004 TDT4285 Planl&drift IT-syst

Reservedelsstrategi Opprette og vedlikeholde et lager
av alle relevante reservedeler. Kort TTR Lavere transportkostnader Lagerkostnader Restlagre Fall i pris/ytelse Høyere forbruk JIT- innkjøp Minimale lagre Våren 2004 TDT4285 Planl&drift IT-syst

Garanti Garantitidens lengde? Relevant eller uegnet bruk? Hvem bestemmer om det er en garantisak? Garanti kontra reklamasjon Feilrapportering uten forsinkelse Hvem betaler frakt? Erstatnings/låneutstyr? On-site? Kjøper Selger Garantikrav Distributør Garantikrav Importør Garantikrav Produsent Dersom en av disse går konkurs? Garantikrav Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Avhending av utstyr Det kan være dyrt å selge! Garantiansvar Fakturering Annonsering Datautstyr er spesialavfall Husk at utstyret er merket! Pris: 80 kr/kg (?) Kan inneholde sensitive data Her er det i alle fall nå blitt slik at datautstyr skal kunne returneres til vilkårlig selger som selger slikt utstyr. Jeg er usikker på om dette også gjelder for større aktører. Fortell gjerne om skrotnissene som kommer for å få litt av alle de gamle maskinene, blant annet alle som kom og ville ha 32 bits minne ... Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Lagerhold Registrering av uttak Kvitt deg med defekte deler Minimaliser størrelsen på lageret Evt legg gjenbrukbare deler på lager, men test dem først Utnevn en eneveldig lagersjef Våren 2004 TDT4285 Planl&drift IT-syst

Innkjøp – ta vare på Kontakt med bruker Tilbud (helst flere) Bestilling – skriftlig Ordrebekreftelse – med lev.dato Fraktbrev ved levering Pakkseddel med vareliste – sjekk! Alle serienumre etc Faktura Listeskoder og betingelser Våren 2004 TDT4285 Planl&drift IT-syst

... og ikke glem ... Merkantile momenter Fraktutgifter Gebyrer Tollutgifter Merverdiavgift (!) Miljøavgift Faktureringsgebyr Ditt referansenr Tekniske momenter Kabler Batterier Rekvisita Distr.media Dokumentasjon Tomme media Vedlikeholdsavtaler Våren 2004 TDT4285 Planl&drift IT-syst

Selgere og andre rare dyr ...
Utnytter din iboende høflighet Tåkelegger egne kostnader Eksperter i å avslutte salg Advarsel: leverandørkjeder Er alltid villige til å selge Faresignal: hyppig bytte av arb.giver Våren 2004 TDT4285 Planl&drift IT-syst

Snubletråden: INCO-terms
EXW – ex works FCA – free carrier FAS – free alongside ship FOB – free on bord CFR – cost and freight CIF – cost, insurance and freight CPT – cost paid to CIP – cost and insurance paid to DAF – delivered at frontier DES – delivered ex ship DEQ – delivered ex quai DDU – delivered duty unpaid DDP – delivered duty paid Hvor? Forsikring? Frakt? Ansvar? Eierskap? Risiko? Våren 2004 TDT4285 Planl&drift IT-syst

Modeller for PC-kjøp Abonnere på det utstyret som en produsent kan levere (Dell, Compaq) Kjøpe ferdigbygde PC-er med standard tredjepartskomponenter (Hatelco, Mips) Kjøpe deler og bygge PC-ene selv (Kjøpe en-og-en hos til enhver tid ”billigste” leverandør) Våren 2004 TDT4285 Planl&drift IT-syst

Tåkelegging av kostnader
Bundling av ekstra varer, så som kurs, support, opplæring, installasjon Ekstragebyrer for f.eks transport Med eller uten MVA? Utdragning i tid? ’Fiktive’ goder du aldri får benyttet Sære betalingsordninger Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Variantbegrensning Reservedeler Ombytt- barhet Objektive brukerbehov Antall ulike systemer Kompetanse- behov Variasjon Skjult agenda? Subjektive brukerbehov Utstyrsvarianter Varantbegrensning vs tilpasning? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

To måter å få til variantbegrensning
Tvungen Bruk pisken! Planlegges i forkant Funderes hos ledelsen Må være klart for alle i org Må håndheves! Frivillig Bruk gulrota La dem selv betale Annonser/lokk med de OK løsningene Aksepter at ikke alle er med. Hold statistikk Våren 2004 TDT4285 Planl&drift IT-syst

Reklamasjon Avklar garanti på forhånd Ha papirene i orden Forlang skikkelig support Ved innsending: ta vare på fraktbrev! Ta tiden på dem, og før logg Ha oversikt over hva som er til rep Klag ved systematiske typefeil Våren 2004 TDT4285 Planl&drift IT-syst

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

Preliminært Område med mye skriftlig materiale Verd å søke profesjonell hjelp Må integreres i andre oppgaver Avveie sikkerhet mot funksjonalitet Ettermontert sikkerhet er dårlig Må funderes hos ledelsen Ikke sikrere enn det svakeste ledd Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Historikk Nettverk Andre Bruker Ressurs Brukere Bruker Ressurs Frem til ca 1970 (og PC’er frem til ca 1990) var det en-bruker-en-maskin, og resten av verden var utestengt pr def. Deretter ble det flere brukere på en maskin, men frem til rundt 1985 var det allikevel slik at hver maskin bare hadde et visst sett av brukere. Idag er alle maskiner og brukere koblet sammen i nett, slik at utfordringene er langt større. Bruker Maskin Maskin Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Avveininger... ? Sikkerhet Det et ingen iboende motsetning mellom disse, selv om det i praksis ofte kan virke slik. Funksjonalitet Strengt tatt er dette tre forskjellige dimensjoner, men det er ofte en motsetning mellom sikkerhet og brukers funksjonalitet, og mellom funksjonalitet og at ting er enkelt. Det er muligens også en motsetning mellom at ting er enkelt og at det er sikkert, for enkelt betyr ofte generelle, gjennomgående løsninger, mens sikkerhet betyr tilstramming av alt som ikke trengs. Ryddighet Enkelhet Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Sikkerhet bør bygges på
TDT4285 Planl&drift IT-syst Våren 2004 Sikkerhet bør bygges på Pålitelighet Oversikt Planlegging/design fra starten Integrasjon i infrastrukturen Skall-tankegang Konsistens Sikkerhet bør ikke bygges på reaktivitet, for det er å løpe etter problemene. Et annet problem er når sikkerhet bygges å sikre det som er lett å sikre, men ikke det som er vanskelig å sikre. Det er også et stort spørsmål mange ganger hvorfor man sikrer, er det for faktisk å sikre systemet, eller er det for utad å vise at man forsøker å gjøre noe med problemet. Til slutt er det viktig at man lar en rett holdning om sikkerhet gjennomsyre hele organisasjonen (og hele arbeidsdagen), så det ikke bare er sjefene eller sikkerhetsansvarlig som tenker sikkerhet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Analysefase Kan dataene reproduseres? Hvilke skadevirkninger har tap/endringer/etc? Hvor mye koster relevant sikring? Balanser pkt 1-3 Skade- virkning Fare Eksempler: Forsvarsplanene har det stor skadevirkning dersom blir kompromiterte, men de er sannsynligvis reproduserbare. Historiske loggdata er sannsynligvis ikke reproduserbare, men det er kanskje ikke så farlige om de faller i gale hender? Må vurderes fra tilfelle til tilfelle. Uproble- matisk Reproduser- barhet Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Hva beskytter vi oss mot?
TDT4285 Planl&drift IT-syst Våren 2004 Hva beskytter vi oss mot? Uautorisert tilgang til data Sletting Endring Innsyn Tjenestetilgjengelighet Ressurstyveri/misbruk Dårlig omtale Noen eksempler: Defacing av hjemmeside. Eksemplet der en republikansk ansatt i kongressen i flere måneder hentet ut interne dokumenter fra demokratene fordi det ikke var tilstrekkelig sikret på deres (felles?) tjener. Ved innbrudd på NTNU har man stort sett vært interessert i å sette opp tjenere for fildeling (pga kraftig nett). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Fysisk sikring av utstyret
TDT4285 Planl&drift IT-syst Våren 2004 Fysisk sikring av utstyret Klient Tjener Data Her er det den fysiske sikringen som er poenget. Romsikring Sonesikring Skallsikring Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Fire fasetter av sikkerhet
Vern mot innsyn (lås) Autentisering (nøkkel) Autorisering (lås-nøkkel-kopling) Integritet (datas bestandighet) Våren 2004 TDT4285 Planl&drift IT-syst

Vern mot innsyn (lås) (Data er beskyttet av en lås) Fysisk avlåsing (f.eks hengelås) Logisk avlåsing (f.eks kryptering) Adgangsmessig avlåsing (f.eks ACL) Våren 2004 TDT4285 Planl&drift IT-syst

Autentisering (nøkkel)
(Person må besitte en nøkkel) Passord som må huskes Engangspassord på fysisk gjenstand Privat nøkkel for krypteringsalgoritme Annet (irisskanning, fingeravtrykk, stemmegjenkjenning) Våren 2004 TDT4285 Planl&drift IT-syst

Autorisering (nøkkel-lås-kopling)
(Sikre at bare rett nøkkel passer) Fjerne bakdører Addere uavhengige låser Senke dirkbarhet Forsterke kopling person-nøkkel Våren 2004 TDT4285 Planl&drift IT-syst

Integritet (Ondsinnet eller tilfeldig korrupsjon av data) Duplisering av data Sjekksumming av data Geografisk spredning av data Ansvarsspredning for data Kontrollert lagring Våren 2004 TDT4285 Planl&drift IT-syst

Tre dårlige strategier ... I
TDT4285 Planl&drift IT-syst Våren 2004 Tre dårlige strategier ... I Security through obscurity. Gjør det så sært at ingen finner frem La være å dokumentere Kjør ustandard løsninger Hindrer ikke de som er virkelig oppsatt på å komme inn, selv om det er en terskel som skiller ut noen små angrep Men tross alt, statistisk sett så fungerer det. Men statistisk sett er ikke godt nok i tilfeller der det er absolutt påkrevet at folk ikke kommer inn. Eksempelvis: scriptkiddie på PVV som brøt seg inn på flipper, men stakk da han oppdaget at den kjørte DolphinOS. Motsatt: Windows er utsatt fordi det er så mange (og like) installasjoner av det. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Tre dårlige strategier II
TDT4285 Planl&drift IT-syst Våren 2004 Tre dårlige strategier II Honningkrukker Sett frem noe fristende Ta dem etterhvert som de dukker opp Egentlig bare en variant av ’security through obscurity’. Tar de små tidlig og hindrer kanskje gjentakelse. Avskrekking? Kan også tiltrekke. Igjen en strategi som reduserer problemet, men forutsetter at angriper ikke vet forskjell på honningkrukka og det som du forsøker å beskytte. Brukbart som suplement og for å monitorere, men trolig en dårlig eneste-strategi. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Tre dårlige strategier III
TDT4285 Planl&drift IT-syst Våren 2004 Tre dårlige strategier III Offerlam De ytterste maskinene er ukritiske Når de angreper kan de studeres Kan kombineres med honningkrukka Også bare en ’security through obscurity’, selv om prinsippet om flere forsvarslinjer er bra. Det forutsetter at du klarer å oppdage og håndtere angrep mot offerlammene. Dersom du ikke har tid eller kompetanse til det, kan det virke mot sin hensikt. Kan være et akseptabelt tillegg til en helhetlig strategi. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Mangler med disse strategiene
Styrker ikke sikkerheten direkte Svekker bare sikkerhet på enkelte kontrollerbare punkter Obscuritetssikkerhet virker ikke mot interne innbrudd Hever terskelen, men stopper ikke Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Noen gode strategier I CERT (Computer Emergency Response Team) Plassere ansvar og ressurser Proaktivt (ER?) Kjapp oppdatering av sikkerhetspatcher Full oppklaring av sære ting Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Noen gode strategier II
Forenkling Filtrer alt gjennom en sentral firewall Homogeniser datamaskinene Fjern unødvendig funksjonalitet Våren 2004 TDT4285 Planl&drift IT-syst

Noen gode strategier III
Monitorering Sett opp mange detektorer Følg systematisk opp symptomer Ta tilfeldige stikkprøver Følg med i loggene Våren 2004 TDT4285 Planl&drift IT-syst

Nettmessig sikring av utstyret
TDT4285 Planl&drift IT-syst Våren 2004 Nettmessig sikring av utstyret Sikret område Klient Tjener Data Sekundært angrep Sikret område Her er det den nettmessige sikringen som er poenget. I praksis vil du ende opp med en skallsikring også i dette tilfellet, der det er flere ’konsentriske’ ringmurer, med hver sin firewall (i praksis vil vel konfigurasjonen bli litt mer kompleks, men det gir den rette ideen). Tjener2 Tjener3 VPN Firewall Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

”Sikre” produktvalg Enkelhet Sikkerhet Åpen kildekode Brukbarhet Funksjonalitet Produsentrelatert Integrasjon TCO Produktfremtid Standarder Historikk Utbredelse Internkunnskap Våren 2004 TDT4285 Planl&drift IT-syst

Intern overvåkning Logging og loggprosessering Intern verifisering Prosjektspesifikk verifisering Fysisk sjekking Skanning av datanett Våren 2004 TDT4285 Planl&drift IT-syst

Sikkerhetsrelaterte roller
Sikkerhetsarkitekt Implementator Operatør ”Policy-writer” Revisor (auditor) Incident Response Team Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 CERT Operativ reaksjonspolitikk Juridisk reaksjonspolitikk Eskaleringspolitikk Ressursallokeringspolitikk Frakoblingspolitikk Pressehåndteringspolitikk Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Utfordringer innen sikkerhet
’Social engineering’ Bærbare maskiner med lokale data Skal jobbe fra hjemmemaskiner Egne ansatte Tempoet på utviklingen Overgang til black-box-funksjonalitet Skaleringsproblemene generelt Våren 2004 TDT4285 Planl&drift IT-syst

Konkrete sikkerhetsangrep
Lange ping-pakker Denial of Service (DoS) IP-spoofing SYN flooding TCP sequence guessing Teardrop (IP/UDP fragmentering) ICMP-flooding (smurf) DNS-Cache Poisoning Våren 2004 TDT4285 Planl&drift IT-syst

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

Våren 2004 Dekomponering Ideelt sett: En hver bruker kan benytte enhver applikasjon på ethvert system Brukerspace OS/HW-space Tradisjonelt er applikasjoner adskilt fra OS/HW. Applikasjoner skrives for å kunne kjøre på mange platformer og være portable. Men det er forskjeller i måten man håndterer applikasjonsrommet og OS-rommet. Ortogonalitet er noe som man bør trekke inn her og fortelle om nytteverdien av. Applikasjonsspace Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Forskjeller Applikasjonsrommet Konsistens på tvers av systemene Oppdeling i pakker Desentr, ukoordinert utviklingsmodell Alle kombiasjoner er ikke uttestet Sameksistens OS/HW-rommet Oppdeling i egne rom for hvert OS Monolittisk Sentralisert modell for utvikling/distr Vanligvis uttestet Konfigurasjon Våren 2004 TDT4285 Planl&drift IT-syst

Omfanget av innebygde appl
TDT4285 Planl&drift IT-syst Våren 2004 Omfanget av innebygde appl Kommersielt= få medfølgende applikasjoner Lokalt installerte applikasjoner Medfølgende applikasjoner O/S og basissystem Med de fleste kommersielle systemene får du en maskin som ikke har den programvaren du trenger ... Bare den programvaren du trenger for å kjøre den programvaren du egentlig trenger. Dermed er applikasjonene mer eller mindre løse enheter som installeres på toppen av systemet Stiplet linje er skille mellom måter å installere og oppgradere Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Inst- og driftssystemer
Økende nytteverdi av gjenbruk Scripts cfengine Sammen- satt Økende nytteverdi i vedlikehold Store Win install Keyboard recording Monolittisk Ghost Automagisitet Aksjons- basert Tilstands- basert Våren 2004 TDT4285 Planl&drift IT-syst

Push og pull ... Push er initiert fra sentral maskin. Gir oversikt, enkle nettverk og muliggjør en hierarkisk arbeidsform. Pull er initiert fra desentrale klienter. Gir lokal autonomitet, asynkronitet og muliggjør anarkistisk arbeidsform. Våren 2004 TDT4285 Planl&drift IT-syst

Hovedelementer push/pull
Initiativ til oppstart Tjener Klient Database over filer som skal distribueres Konfigura- sjonsfiler Våren 2004 TDT4285 Planl&drift IT-syst

Push/pull – diagram Push (Kontroll- problem) rdist Sentalt initiativ store Lokalt initiativ cfengine track (Kaotisk vedl.ansvar) Pull Lokale konfigfiler Sentrale konfigfiler Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel: Track Mekanisme: pull Domene: alle typer filer Autonome lokale systemer Lokal konfigurasjonsfil Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel: Rdist Mekanisme: push Domene: alle typer filer Sentralisert konfigurasjon Sentralisert fil-database Klienter må stole på tjener Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel: Store Mekanisme: pull Domene: kun tredjepartsapplikasjoner Støtter multiple versjoner/arkitekturer Autonome maskingrupper Distribuert fil-database Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel: Cfengine Mekanisme: pull Domene: alle typer filer Sentralisert fil-database Sentralisering av konfig-filer Innebygging av mekanismer Våren 2004 TDT4285 Planl&drift IT-syst

Andre pakkesystemer RPM for Linux Ports/packages for FreeBSD Pakkehåndtering for Solaris LUDE Depot Våren 2004 TDT4285 Planl&drift IT-syst

Nøkkelpunkter for depoter
TDT4285 Planl&drift IT-syst Våren 2004 Nøkkelpunkter for depoter Sentralisering. Ligger master-kopi av programvaren ett sentralt sted, eller finnes det mange desentrale små-mastre? Automatisering. Skjer distribusjon av filer automatisk eller kun på manuelt initiativ. Arkitekturer. Er det støtte for å håndtere forskjellige arkitekturer? Påstand: sentralisering i tradisjonell forstand er umulig utover en viss skala. Dersom man forsøker å dra det for langt, får man skaleringsproblemer og ender i en ’kommunistisk’ sentralstyrt modell. Ulike løsninger har øvre grenser for skalering. Det som kanskje er mest lovende er det driftsløse systemet, der utviklere lager et system som bruker ikke grenger å bruke administrativ tid på. Superskalering. Med arkitekturer: støtter man et endelig sett av arkitekturer? Kan det utvides og tilbaketilpasses? Dersom det er skalert stort nok, kan ulike delorganisasjoner støtte samme arkitektur uavhengig av hverandre? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Nøkkelpunkter Push/pull. Ved distribusjon av programvaren til andre maskiner, hvem tar initiativet? Regenererbarhet. Hvordan rekonstruerer du innholdet i et programvaredepot. Konfigurering. Hvordan og i hvilken grad støtter systemet lokale tilpassinger (f.eks. setting av domenenavn)? Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Nøkkelpunkter Oppdatering. Hvor enkelt er det å ta med et gammelt lokalisert oppsett til en ny versjon av programvaren. Versjonsprofiler. Kan systemet håndtere ulike versjoner av samme programpakka, f.eks for testmaskiner og stabile maskiner? Transport. Hvilke mekanismer brukes for å transportere programvare mellom maskiner? Våren 2004 TDT4285 Planl&drift IT-syst

Nøkkelpunkter Konvergens. Har pakkesystemet mekanismer for konvergens ifm entropi? Robusthet. Bygger systemet på ’bieffekter’. Eks intermediates i track. Sporbarhet. Kan man avgjøre hvilken pakke enhver fil tilhører? Og hvilke filer som evt ikke tilhører noen pakker? Våren 2004 TDT4285 Planl&drift IT-syst

Nøkkelpunkter Fokus. Er fokus på applikasjoner, OS eller også driftsrutiner? Skalerbarhet. Hvor stort system (geografisk, organisatorisk) kan man støtte? Hvor mange maskiner kan man støtte? Støtter det arbeidsdeling? Autonomitet. Er det sentralstyrt? Våren 2004 TDT4285 Planl&drift IT-syst

Nøkkelpunkter Deinstallasjon. Kan pakker deinstalleres, og i hvor stor grad ryddes det da opp? Uniformitet. Er det noen form for tvungen uniformitet (mellom pakkene) i hvordan dok, datafiler, include-filer etc blir lagret? Sikkerhet. Kan systemet håndtere trafikk over usikkert nettverk? Har det sjekksummer? Våren 2004 TDT4285 Planl&drift IT-syst

Nøkkelpunkter Avhengigheter. Håndterer systemet avhengigheter mellom ulike pakker? Tjenester. Hvordan håndteres tjenester og services som skal gå i bakgrunnen? ’Hi-score-filer’. Håndteres datafiler med dynamisk innhold og relevans som er videre enn hver enkelt depot-cache? Våren 2004 TDT4285 Planl&drift IT-syst

Vitenskap og teknikk Vitenskap Abstraksjon Teoretisk/empirisk Hypoteser Falsifisering Peer review Publisering Grunnforskning Teknikk Praktiske gjøremål Empirisk/heuristisk Kjørende kode “Det som virker” Akutte problemer Reaktivt Våren 2004 TDT4285 Planl&drift IT-syst

Komplekse systemer Statistisk analyse av pålitelighet Statistisk analyse av ytelse Evaluering av metoder Observasjoner av uforutsigbare hendelser Strategi og planlegging Systemets mål og mening (policy) Våren 2004 TDT4285 Planl&drift IT-syst

Gjeldende metodikk Verktøy Antakelser Omtrentlige, semi-felles erfaringer Anvendelse Observasjon Våren 2004 TDT4285 Planl&drift IT-syst

Mer vitenskapelig metodikk
Hypotese- testing Anvendelse og policy Verktøy Vitenskapelig kunnskap Observasjon Hypotese- bygging Modellering Våren 2004 TDT4285 Planl&drift IT-syst

Viktigheten av en “policy”
En “policy” definererer mål og mening for dataanlegget Bruker som rettesnor for å vurdere tiltaks hensiktsmessighet Påstand: gitt en policy, er egentlig hele systemets tilstand implisitt gitt Våren 2004 TDT4285 Planl&drift IT-syst

Policy-basert målstyring
Situasjon Problem? Policy Alternativ2 Løsnings- forslag Alternativ1 Måletall Måletall Konklusjon Konklusjon Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel med mp3 Situasjon: Tomt for disk pga mp3-filer Policy: ikke-faglig aktivitet må vike Problem? Ja, man får ikke arbeidet Alt1: Gjøre ingenting (nulltalternativet) Alt2: Sette opp en /etc/motd Alt3: Slette det hele Alt4: Sende oppfordringer til brukerne Våren 2004 TDT4285 Planl&drift IT-syst

Alternativ 1 (eks mp3) Forslag: ikke gjøre noe Måletall: Driftskostnader Stabilitet Får folk arbeidet? Volum av mp3-filer? Konklusjon: Oppfyller ikke policy Våren 2004 TDT4285 Planl&drift IT-syst

Alternativ 2 (eks mp3) Forslag: legge inn /etc/motd Måletall: Driftskostnader Hvor mange leser det? Hvor mange sletter Får folk arbeidet seriøst? Konklusjon: Litt bedre, men ikke nok Våren 2004 TDT4285 Planl&drift IT-syst

Alternativ 3 (eks mp3) Forslag: Slette mp3 “on sight” Måletall: Driftskostnader Hvor mye blir frigjort Hvor mye gjemmes unna Får folk arbeidet seriøst? Konklusjon: ??? Våren 2004 TDT4285 Planl&drift IT-syst

Eksempler på policies Hva skal systemet brukes til? Hvem er systemet til for? Prosentvis/lengde oppetid Utskriftskostnader/volum Nett: volum, accesstid, opptid Diskbruk: pr bruker, totalt Backup: hyppighet, testing, tid Våren 2004 TDT4285 Planl&drift IT-syst

Negativ/positiv policy
Negativ dersom den definerer det som ikke skal gjøres, som skal unngås og som ikke er ønskelig (lover) Positiv dersom den definerer det som er skal gjøres, oppnås og som er ønskelig (visjon) Våren 2004 TDT4285 Planl&drift IT-syst

Positiv måldefinisjon
Beskriver hvordan systemet er ment å fungere. Våren 2004 TDT4285 Planl&drift IT-syst

Negativ måldefinisjon
Probl Probl Probl Probl Probl Probl Probl Beskriver systemet Ved å spesifisere hvordan det ikke skal virke Probl Våren 2004 TDT4285 Planl&drift IT-syst

Målendring – utfordringer
Målene endres hele tiden Systemet må endres hele tiden Innsats blir generelt mindre Utfasing av foreldede neg tiltak Neg tiltak forutsetter at du oppdager problemet de skal løse, minst en gang Våren 2004 TDT4285 Planl&drift IT-syst

Brukerdimensjonen Uavhengig av tilgjengelige applikasjoner Uavhengig av hvilke maskiner som kjører hvilke OS og har hvilken HW Uavhengig av suborganisasjon Uavhengig av geografi Våren 2004 TDT4285 Planl&drift IT-syst

Lokale adminbrukere Gir bruker privs på én maskin En viss sikkerhetsrisiko Tidvis eneste utvei ’Privilegier under ansvar’ Gjør dem oppmerksom på sitt ansvar ... (og få det skriftlig) Våren 2004 TDT4285 Planl&drift IT-syst

Brukerdatabase Felles brukerkonto ’overalt’ Felles passord ’overalt’ Kobles til autorativ database, gjerne personaldatabasen Unngå upersonlige brukere Bør ikke inneholde klartekst-passord Våren 2004 TDT4285 Planl&drift IT-syst

Valg av passord Ha en minimum lengde Krev noen spesialtegn Forby bruk av ordliste-ord La brukeren selv velge passord Bruk vanskelige førstepassord Let etter gjettbare passord Tving frem regelmessige passordskift Våren 2004 TDT4285 Planl&drift IT-syst

Bør brukeren velge passord?
Ja: Lettere huske, unødvendig å skrive ned, kan gjenbrukes på flere systemer. Nei: Gjenbrukes på usikre systemer, Kan velge dårlige passord, kan beholde samme passord lenge. Våren 2004 TDT4285 Planl&drift IT-syst

Oppstartsmiljø Enkelt, er bare et startpunkt Utbyggbart for brukeren Må dekke de flestes behov Koble tilbake ifm feilsøking/retting Bør ligge lokalt (må for sysadm) Være adskilt fra OS Adskill programoppsett fra brukere Våren 2004 TDT4285 Planl&drift IT-syst

Typer av brukere Passive brukere. Godtar de de får. Aktive brukere. Bevisste om hva de vil ha. Eksperimenterer og konfigurerer. Finner feil og problemstillinger. Hjelpsomme brukere. Gir fornuftige feilmeldinger, og reparerer ting selv. Våren 2004 TDT4285 Planl&drift IT-syst

Hjemmekatalogpartisjoner
Geografisk nær bruker? Adskille etter brukerprofil Større adm overhead Mindre optimal diskutnyttelse Adskille brukergrupper som ellers kunne skape problemer for hverandre Våren 2004 TDT4285 Planl&drift IT-syst

Fjerning av filer Slette de største filene Slette de eldste (uleste) filene Slette de avledede filene Komprimere filene Flytte filene (se om noen klager) Kjøpe mer diskplass (dvs jukse :-) Våren 2004 TDT4285 Planl&drift IT-syst

Diskkvoter Hard-limits. Kan ikke bruke over denne grensen – får ikke laget nye filer. Soft-limits. Får bare advarsel når grensen overskrides. Peer pressure. Offentliggjør hvem som bruker hvor mye diskplass. La parisjonene begrense plassbruken. Våren 2004 TDT4285 Planl&drift IT-syst

Sletting av brukere Ta backup Gi en ’grace period’ Sett metadata (f.eks uid) i karantene Ta vare på metadata Sett opp evt forward – tidsavgrenset Våren 2004 TDT4285 Planl&drift IT-syst

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

Ytelsesforbedring og feilsøking
TDT4285 Planl&drift IT-syst Våren 2004 Ytelsesforbedring og feilsøking Feilsøking skal finne en feil som forårsaker bestemte symptomer. Ytelsesforbedring skal søke å forbedre (eller balansere) respons og through-put i et mer eller mindre fungerende system. På sett og vis ligger ytelsesforbedring mellom feilsøking og redesign av systemet. Det er ikke målet å endre på noe kvalitativt for brukerne, bare kvantitativt, men samtidig er det et poeng at man endrer på hvordan systemet fungerer internt, for det er ikke en feil man skal fikse, det er en mangel man skal søke å motvirke. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

TDT4285 Planl&drift IT-syst Våren 2004 Kontinuerlig forbedring Analysere Ytelses- forbedring Feilsøking og -retting Prioriteringsplan Monitorere Konstruere Loggdata 3.linje 1-2.linje I denne modellen ligger ytelsesforbedring på den høyre siden, der man redesigner og forbedrer systemet, men merk at det er uten at brukerbehovene har endret seg. Igangsette Installerbart system Drivbart system Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Hva er ytelse? Total through-put? Responstid for enkeltbruker? Optimal balansering av ressursbruk? Å få gjort jobben uten ”prakk”? Stabil funksjonalitet tilstrekkelig lenge? Ytelse har mange aspekter, og ulike personer vil vektlegge dem ulikt, derfor blir det også vanskelig å gi en god, entydig definisjon. Eksempelvis kan det komme brukere til drift og si at deres bærbare er blitt treg i det siste. Når du begynner å snakke om reinstallasjon eller noe slikt, så blir de bleke, klamrer seg til den og skriker at du ikke får lov til å røre den. Det er et eksempelpå ytelse som responstid og ytelse som stabilitet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Probl: snikende ytelsestap
TDT4285 Planl&drift IT-syst Våren 2004 Probl: snikende ytelsestap Nesten umerkelig degradering Brukerne ’lærer’ seg å leve med det Når en terskelverdi for frustrasjon Ytelse Grunnideen er at mennesket er tilpassningsdyktig, og at det ikke er gitt at de klager over fallende ytelse dersom det går sent nok. Et illustrende eksempel er opptaksfrist for NTNU, som var etter at eksamenspapirene var kommet fra videregående i ’min’ tid – ca st.hans. Med varsling et par-tre uker etter. Dersom man skal være beregnende, kan dette også brukes motsatt vei: dersom du vil fase ut en tjeneste, så sørg for at den blir litt mindre brukbar for hver uke ... Ikke merkbart, bare ørlite granne. Et annet godt eksempel her er pop-tjenere og mail. Dersom man etterlater posten på tjeneren, så akkumuleres den og det tar stadig lengre og lengre tid. Tid Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Probl: snikende ytelsestap
TDT4285 Planl&drift IT-syst Våren 2004 Probl: snikende ytelsestap Nesten umerkelig degradering Brått omslag i brukernes oppfatning Faktisk problemfiksing Ytelse Etterslep Dette her har å gjøre med hvordan brukere snakker sammen. Illustrasjon: Spam har vært et jevnt voksende problem, men utfra observasjoner på tilbakemeldinger fra brukerne, virker det som om det øker trinnvis. (forsåvidt rett som at volumet endrer seg over tid). Plutselig snakker ’alle’ brukerne om hvordan spam er et problem, og så er det lite eller ingen snakk om det en stund. Kanskje mekanismer som ligner på spredning av smitte? Der det kommer over en kritisk terskel dersom hver som prater om det trigger minst en annen, hjulpet av massetrigging gjennom massemedia. Reell kvalitet Oppfattet kvalitet Kritisk terskel Tid Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

”Usynlige” ressursdelinger
TDT4285 Planl&drift IT-syst Våren 2004 ”Usynlige” ressursdelinger Dette er ”usynlig” for brukeren: Ressursdeling (f.eks CPU) Degradert ytelse (f.eks virtuelt minne) Delt termtjener og termklienter Sentralisert RAID for hjemmekataloger Felles datanett mot omverden Viktig punkt: mange er vant med PC’er der det kun er dem selv (og evt virus og ormer) som kjører. Da er det ikke så viktig hva CPU-tiden blir brukt til – når de ikke bruker den selv. ”Hvis det går tregt, så lukker jeg bare noen programmer”. Det fungerer ikke med flerbrukerprogrammer – og i overført betydning alle delte ressurser. Fortell om da NextGenTel satte opp ytelsen til 2MB for alle ... Og jeg (som hadde det fra før) fikk dårligere ytelse. En god illustrasjon her er skjermsparere: dersom du ikke selv bruker CPU’en så kan vel skjermspareren bruke den? På en enbruker PC: Ja, på et flerbrukersystem:NEI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Probl: Avhengigheter Eks: mye diskaksess Eks: for lite minne Dårlig ytelse på andre ressurser Høyt forbruk av en ressurs Eks: paging Bieffekter En illustrasjon på dette er travelling salesman og lignende problemer, som er teoretisk løsbare, men algoritmene er slik at store forbedringer av hardware gir minimale praktiske forbedringer i ytelse – fordi det er i algoritmen ’problemet’ ligger. Fikse feil problem Eks: kjøpe raskere disk Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Angrepsvinkler Teoretiser. Vurder deg frem til hvor flaskehalsene er og hvordan de elimineres. Modellér. Bruk metodene fra ytelsesvurdering. Ofte altfor komplekst. Monitorér. Ha representative målepunkter som for ytelse, og følg med dem over tid. Teste. Bytt ut komponenter og se sjekk oppførsel under belastning. Merk at det er en økende grad av praktisk-het og minkende grad av teori nedover denne lista. Det siste punktet er det eneste som endrer, og de to siste er de eneste som ser på det faktiske systemet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Det svakeste ledd En prosess trenger flere typer ressurser Ressursene er tilgjengelig i ulike monn Den minst tilgjengelige ressursen setter tempoet. Motorvei Motorvei Her er det svært viktig at man angriper rett problem, i dette tilfellet kjerreveien, og at man ikke i stedet bygger flere felt på motorveiene. Ofte er det enklere å rette ’feil’problem, enten fordi det er lettere eller svarer til ens fordommer. Og dersom man har nok penger er det selvfølgelig mulig at man tidvis kan komme i mål med det. Kjerrevei Motorvei Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

”Flaskehalshåndtering”
Finn den svaktest dimensjonerte ressursen. Begrens belastning, og/eller ... ... øk ressursen. Iterer til punkt 1 dersom nødvendig. Analyser Finn det svakeste ledd Øk tilgjengelige ressurser Begrens belastning Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Fordeler Praktisk og enkel metode som er enkel å anvende. Kan brukes gjentatte ganger på eksisterende systemer (iterativt). Balanserer systemet slik at man går mot optimal utnyttelse av systemet. Generelt: praktisk metode. Viktig å stresse at den er enkel å bruke. Det som er involvert er kun dagens system og monitorering. Det første har man pr def, og det siste er non-intrusive og finnes sannsynligvis allerede (men ikke påslått), eller det kan lett kobles til. Dermed er det en metode som raskt kan brukes for å møte problemer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Ulemper Inkrementell forbedring uten ’kvantesprang’ Vanskelig å kombinere med proaktiv planlegging Vanskelig å bruke på systemer med sterk variasjon i belastning Ofte bare symptombehandling Probl med støy fra mange små effekter Rent overordnet: systemer med for mye tuning etter flaskehalsmetoden har en tendens til å bli komplekse, sære, lokaliserte og ’sedimentære’ (dvs at de er bygget opp av mange lag oppå hverandre, fordi man bare har gjort endringer ved å legge nye lag på toppen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Forbedring av ytelse Performance Forbedringer Velge relevante målepunkter Verifisere Monitorering Endringer Måle- periode Statistikk Gjøre antagelser om konsekvenser Observasjon: man gjør ikke noe før i de aller siste fasene av dette. Dessuten er det en indre konflikt mellom å gjøre noe for å fikse et problem som finnes her og nå; og å vente på relevante måledata – mens gresset gror dør kua. Sammenhenger Monitorerings- data Forståelse Trender Analyse Presentasjon Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Case 1: Java på introsalene
TDT4285 Planl&drift IT-syst Våren 2004 Case 1: Java på introsalene 130 maskiner av 150MHz; 48MB; 1,3GB Kompilering av javaprogram: 65 sek Lokalt lagret programvare: 20 sek Med 128MB minne: 6 sek På terminaltjener: 2 sek Det tok i praksis 4 timer å analysere problemet og få disse dataene på bordet, etter at vi satte en person med 100% fokus på å gjøre dette. Deretter tok – på bakgrunn av dataene – ca 10 sekunder å bestemme oss for hva vi trengte å gjøre: kjøre all kompileringen fra terminaltjener. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Case 2: Termtjener på intro
TDT4285 Planl&drift IT-syst Våren 2004 Case 2: Termtjener på intro 100 PC- og 100 ekte tynnklienter PC-tynnklientene har normal responstid ved bruk av Notepad De ekte tynnklientene har alvorlige tidsforsinkelser ved bruk av Notepad Merk at dette var et problem under Windows CE, og ble fikset i en senere bios-oppgradering, mens NT (og W2K/XP) har aldri hatt problemet). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Case 2: prosesser på vier
TDT4285 Planl&drift IT-syst Våren 2004 Case 2: prosesser på vier Prosesser som har løpt løpsk (read() -> -1) Bruker bare moderat med CPU Bruker maksimalt med systemkall Drukner i den generelle bruken Ofte flere samtidig Fortell om systemprogrammeringsfaget, der de skulle lage et program som simulerte et virutet minnesystem, og der en av løsningene var en enkeltlenket liste av pekere til minnesider med timestamp fra time(), slik at man sekvensielt søkte igjennom lista for å finne least-recently-used, og sammenlignet enhver mot time(). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

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

Fem problemstillinger
Uklarhet om initiativ Snakke ”forbi” hverandre ”Information underflow” Forvrengning av informasjon Filtrering av informasjon Våren 2004 TDT4285 Planl&drift IT-syst

Uklart initiativ – definisjon
Opphav: Minst en av partene glemmer eller misforstår at ”ballen er på deres egen banehalvdel”. Symptom: Begge/alle parter venter på hverandre. Konsekvens: Spill av tid. Krangling. Dårlige samarbeidsforhold. Det går prestise i ting. Våren 2004 TDT4285 Planl&drift IT-syst

Uklart initiativ – eksempler
Reinstallasjon av maskin ’A’ skal komme og installere maskinen min ’B’ skal ta med maskinen hit så jeg kan installere den. Arrangering av møte ’A’ skal sende en liste over mulige tidspunkt ’B’ skal sende meg liste over tidpunkter som ikke passer for ham. Våren 2004 TDT4285 Planl&drift IT-syst

Uklart initiativ – løsning
Faresignal: Tiden går og din side vet at det henger på motparten. Løsning: Kontakt motparten! Si følgende: ”Hei, vi skulle ha et møte. Jeg tror det var du som skulle foreslå noen mulig datoer. Jeg må sette av mye tid til noe annet i kalenderen min, og trenger å få blinket inn dette møtet. Hva passer for deg?” Avverge: Eksplisitt next-action; aktiv form Våren 2004 TDT4285 Planl&drift IT-syst

Forbisnakking – definisjon
Opphav: Manglende klarlegging av hva man snakker om. Antagelser av konteksten rundt samtalen. Symptom: Begge/alle parter tror de vet hva motparten snakker om. I ettertid blir det til: ”Du sa at ...” Konsekvens: Uenighet. Beskyldninger om løgn. Misforståelser. Spill av tid. Våren 2004 TDT4285 Planl&drift IT-syst

Forbisnakking – eksempler
Allokering av rom ’A’ sa vi kunne bruke et av de to kontorene Men ’A’ har jo allerede gitt meg de to kontorene, han kan ikke dobbetbooke dem! Reservasjon av maskin Men denne PC-en har ikke CD-spiller! Ja, du bad om en maskin, ingen sa noenting om en CD-spiller. Våren 2004 TDT4285 Planl&drift IT-syst

Forbisnakking – løsning
Faresignal: Man blir enige litt for glatt, samtalen går litt for fort. Løsning: dobbeltsjekk oppfatningen med motparten. Aktiv lytting Avverging: Bruk ekstra tid på å sjekke at dere snakker om det samme: ”Uff, har vi en dobbeltbooking... La oss sjekke etasjekartet. Skal vi se, vi snakker om rommet som ligger her, det er 017 og 020, ikke sant?” Våren 2004 TDT4285 Planl&drift IT-syst

Filtrering – definisjon
Opphav: Man ønsker å presentere saken på en litt penere måte; ’vinkling’ Symptom: Saken endrer karakter når den gjenfortelles Konsekvens: Viktig informasjon kommer ikke frem. Det pyntes. Ulike grupper for ulik informasjon. Feilinformasjon Våren 2004 TDT4285 Planl&drift IT-syst

Filtrering – eksempler
Om prosjektet kan fullføres Til sjefen: Ok, det skal vel la seg gjøre I lunsjen: Det er helt umulig, og en hver idiot ville ha innsett det! Om det nye, dyre programmet Til seg selv: jeg skal ikke kjøpe flere slike, for det var et dårlig kjøp Til andre: Det var nyttig å teste det ut Våren 2004 TDT4285 Planl&drift IT-syst

Filtrering – løsning Faresignal: Ulik, kontekstsensitiv oppfatning av ’samme’ informasjon. Løsning: Omgå mellomledd på veien, og snakk direkte med ’sluttleddet’. Avverging: Gi informasjon skriftlig, så det ikke er så lett å omskrive eller gjenfortelle den. Gi samme (skriftlige) informasjon til alle. Våren 2004 TDT4285 Planl&drift IT-syst

Forvrengning – definisjon
Opphav: Manglende forståelse eller vrangvilje Symptom: Informasjon blir mer uforståelig og har færre detaljer for hvert ledd. Konsekvens: Misforståelser, flere runder med oppklaringer, forsterking av interne konflikter. Våren 2004 TDT4285 Planl&drift IT-syst

Forvrengning – eksempler
Rapportering av feilmelding A: Jeg får feilmelding 403 på maskinen min B: maskinen til A fungerer ikke Status for ressurssituasjonen Vi er sprengt, og kan ikke ta flere oppgaver. De vil ikke gjøre noe mer, og kommer trolig til å kutte ut gamle oppgaver også. Våren 2004 TDT4285 Planl&drift IT-syst

Forvrengning – løsning
TDT4285 Planl&drift IT-syst Våren 2004 Forvrengning – løsning Faresignal: Du kjenner ikke igjen beskjeden i ’neste generasjon’. Løsning: Ta kontakt med sluttledd og gi saklig informasjon. Avverging: Gi dokumentasjon skriftlig, så det er mindre sannsynlighet for at den blir forvrengt på veien. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Information underflow – definisjon
Opphav: Alle tror at noen andre har sagt ifra før, så det er ingen grunn til å feilmelde Symptom: Mangel på tilbakemelding. Konsekvens: Irritasjon hos bruker. Avskriving av ansvar hos drift. Systemet blir ikke bedre. Krangling og dårlige samarbeidsforhold. ’Ruging’ på problemer. Våren 2004 TDT4285 Planl&drift IT-syst

Information underflow – eksempler
Tilstanden for en feature. Drift må jo se at dette er feil. Ingen har jo klaget, så da er alt i orden. Avvising av klage Denne saken er feil og veldig frustrerende. Vel, du er førstemann som klager, så det er vel ikke så frustrerende. Kanskje det er deg det er noe galt med ...? Våren 2004 TDT4285 Planl&drift IT-syst

Information underflow – løsning
Faresignal: Fravær av feilmeldinger. Løsning: Vektlegg ekstra de få feilmeldingen som kommer. Vis at du tar dem alvorlig. Avverging: Oppsøk brukerne aktivt, og la dem vite at det er lav terskel for å kunne si hva de mener. Vis interesse. Våren 2004 TDT4285 Planl&drift IT-syst

Case 1: den finske vinterkrigen
Fra den finske vinterkrigen: Kompanisjefens rapport om ånden i kompaniet: 'Krigstretthet, rotter, dårlig mat, høy sykeprosent, urolig stemning, sterkt behov for informasjon.' Bataljonsjefens rapport om samme kompani: 'Situasjonen normal, behovet for informasjon nærmest et utslag av nysgjerrighet, maten kunne vært bedre, mer DDT og aspirin.' Regimentsjefens rapport; 'Ånden den samme som i regimentet for øvrig. Mulig at litt mer mat vil styrke kampmoralen.' Divisjonsjefen til hovedkvarteret: 'Ånden god, intet spesielt å rapportere. Slutt på representasjonsbrennevinet.' Kilde: Rautavaara, Antero og Kock, Sven E.: Praktisk arbeidsledelse. Elingaard Brevskole, 1959 Våren 2004 TDT4285 Planl&drift IT-syst

Case 2: Alt er en katastrofe
Du får tilbakemelding fra en bruker om at ’ingenting virker’ på en del av anlegget. Du sjekker med systemansvarlig og han sier at alt er i orden og at ’mange brukere’ gir han positive tilbakemeldinger hver dag. Våren 2004 TDT4285 Planl&drift IT-syst

Case 3: Skipperen og solformørkelsen.
Fra den norske handelsflåten: Kapteinens ordre til overstyrmannen: I morgen klokken vil det inntreffe en total solformørkelse, der månen skygger for solen. Hele mannskapet må samles på akterdekket før middag for å se på dette, som er en ganske sjelden hendelse. Jeg vil tegne og fortelle om hvorfor dette skjer. Overstyrmannens ordre til førstestyrmannen: Klokken 16 i morgen, før middag, skal vi alle samles på akterdekket, der månen får solen til å forsvinne ifølge kapteinen. Han vil forklare. Dette er uvanlig. Førstestyrmannens ordre til båtsmannen: I morgen skal vi ikke møte i messa kl 16, men på akterdekket. Der vil kapteinen snakke og sola vil forsvinne; pga månen. Det er viktig at alle kommer, for dette er svært uvanlig. Båtsmannens ordre til mannskapet; I stedet for middag, skal vi i morgen samles på akterdekket klokken 16.00, der kapteinen (pga månen) vil snakke så solen forsvinner. Alle må komme for dette er svært uvanlig. Våren 2004 TDT4285 Planl&drift IT-syst

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

Våren 2004 Brukerdimensjonen Brukere er ideelt: Uavhengig av tilgjengelige applikasjoner Uavhengig av hvilke maskiner som kjører hvilke OS og har hvilken HW Uavhengig av suborganisasjon Uavhengig av geografi Problemet her er at organisasjoner splitter opp og slår seg sammen. Ofte kommer de da sammen med ulike datasystemer som skal tilpasses hverandre (eller den ene halvdelen skal konverteres til det som den andre halvdelen kjører). Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Lokale adminbrukere Gir bruker privs på én maskin En viss sikkerhetsrisiko Tidvis eneste utvei ’Privilegier under ansvar’ Gjør dem oppmerksom på sitt ansvar ... (og få det skriftlig) Problemet her er at endel programvare krever at du er lokal administrator for å kunne kjøre (eller de vil ha mye tilpassing Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Brukerdatabase Felles brukerkonto ’overalt’ Felles passord ’overalt’ Kobles til autorativ database, gjerne personaldatabasen Unngå upersonlige brukere Bør ikke inneholde klartekst-passord Det er forferdelig fristende å legge inn klartekstpassord, for det ”letter” konvertering til andre systemer senere. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

… et lite telefonfelt ’Alle’ brukerdatabaser har et tlf-felt.. Men dersom dette settes ... blir det oppdatert? er det konsistent mellom databaser? er det komplett? Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Valg av passord Ha en minimum lengde Krev noen spesialtegn Forby bruk av ordliste-ord La brukeren selv velge passord Bruk vanskelige førstepassord Let etter gjettbare passord Tving frem regelmessige passordskift Antallet passord har eksplodert med tiden, og med antallet datasystemer, spesielt systemer som er drevet av andre og tilgjengelige over nett. F.eks web-sites. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Bør brukeren velge passord?
TDT4285 Planl&drift IT-syst Våren 2004 Bør brukeren velge passord? Ja: Lettere huske, unødvendig å skrive ned, kan gjenbrukes på flere systemer. Nei: Gjenbrukes på usikre systemer, Kan velge dårlige passord, kan beholde samme passord lenge. Merk at ’før’ i tiden var det en no-no at man i det hele tatt skrev ned passord. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Typer av brukere Passive brukere. Godtar de de får. Aktive brukere. Bevisste om hva de vil ha. Eksperimenterer og konfigurerer. Finner feil og problemstillinger. Hjelpsomme brukere. Gir fornuftige feilmeldinger, og reparerer ting selv. Våren 2004 TDT4285 Planl&drift IT-syst

Oppstartsmiljø Enkelt, er bare et startpunkt Utbyggbart for brukeren Må dekke de flestes behov Koble tilbake ifm feilsøking/retting Bør ligge lokalt (må for sysadm) Være adskilt fra OS Adskill programoppsett fra brukere Våren 2004 TDT4285 Planl&drift IT-syst

Brukerdata omfatter Brukerdatabasedata Hjemmekatalog, og andre lageromr E-post (mottatt/ikke mottatt) Aliases i epost-system Profiler Grupper Våren 2004 TDT4285 Planl&drift IT-syst

Hjemmekataloger Utstyrskostnader Oversikt Oversikt Skalerbarhet Sikkerhet Driftskostnader Skille brukere Punktsikre lagring Lokalt? Sentralt? Nærhet til bruker Teknologi Tilpassing Nedetid Autonomi Er det mulig? Responstid Nettbrudd Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Sletting av filer Alternativer Slette de største filene Slette de eldste (uleste) filene Slette de avledede filene Komprimere filene Flytte filene (se om noen klager) Kjøpe mer diskplass (dvs jukse :-) Hver av disse har fordeler og ulemper, og det må i praksis kobles mot rammene for datasystemet og hva slags avtaler man har med brukerne. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Diskkvoter Hard-limits. Kan ikke bruke over denne grensen – får ikke laget nye filer. Soft-limits. Får bare advarsel når grensen overskrides. Peer pressure. Offentliggjør hvem som bruker hvor mye diskplass. La partisjoner begrense plassbruken. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Sletting av brukere Ta backup Gi en ’grace period’ Sett metadata (f.eks uid) i karantene Ta vare på metadata Sett opp evt forward – tidsavgrenset Tilbakelevering av gjenstander Skift passord som vedkommende har Det siste punktet gjelder spesielt for systemadministratorer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Hva får brukerne lov til?
TDT4285 Planl&drift IT-syst Våren 2004 Hva får brukerne lov til? Grenser Professjonell abuseavdeling Peer pressure Trivielt Policies AUP 1 10 100 1000 10000 Dette gjelder både ifm regelbrudd, men også i ressursutnyttelse. Grensesetting er proaktivt, mens opprydding etter misbruk er reaktivt (og fleksibelt og billigere). Det er også viktig å formidle klart til brukerne hva de får lov til, slik at det ikke oppstår noen form for misforståelse mht hva som er tillatt og hva som ikke er det (og hvor grensen går). Et viktig virkemiddel i så måte er å være konsistent, slik at man ikke sier en ting og gjør noe annet. Slike dobbeltbudskap virker nedbrytende for respekten. Fortell også om eskalering av abuseproblemer. Med økende brukermasse blir det flere brudd på regler og mindre mulighet for sosial kontroll Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

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

Nytteverdi Tilgang mens man er på tjenestereise Kunne arbeide hjemmefra Kunne jobbe mens man er hos kunder Kunne gjøre enkle men viktige ting fra ferie Kunne jobbe fra distriktskontorer Våren 2004 TDT4285 Planl&drift IT-syst

Brukers behov Fjerntilgangsbehovene er temmelig enkle: Lese og sende e-post Hente og lese egne dokumenter/filer Bruke intranett (Web) Fildeling med arbeidskolleger Innlogging på terminaltjener Våren 2004 TDT4285 Planl&drift IT-syst

Parametre for fjerntilgang
Økonomi Geografisk spredning Brukerstøtte koster Protokoll Design Sikkerhet Hva er mulig Velge rett Enkelhet Unngå prakk Hastighet Stabilitet Våren 2004 TDT4285 Planl&drift IT-syst

Mulige teknologier Modem – tradisjonell, gammel løsning ISDN – bare litt raskere enn modem Trådløst – på offentlig sted Mobiltlf.modem – temmelig sakte Satelittelefon – over alt, lang latenstid ADSL – foretrukne hjemmeløsning Radiolink – mest for faste strekk Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel: NTNU trådløst hj.nett
Alternativer var ikke mulig Ikke like godt som ADSL-løsningene Dyrt å holde det gamle utstyret i drift Ønsker ikke å bygge ut mer For brukeren: investering + kostnadsfri bruk Våren 2004 TDT4285 Planl&drift IT-syst

Trådløstnettet Sentralbygg2 Antenne Rundtstråle- antenne Radiomodem Radiomodem NTNUs nettverk Datamaskin Våren 2004 TDT4285 Planl&drift IT-syst

Sikkerhet ved fjernbruk
Ende-til-ende-kryptering Autentisering (engangspassord) Brannvegger (ofte i begge ender) En del av område/skallsikring Kanal for nedlastning av sensitive data Våren 2004 TDT4285 Planl&drift IT-syst

Omgåelse av skallsikring
Telefonlinje Maskinrom Bærbar Skall- sikring Sonesikring Brannmur Våren 2004 TDT4285 Planl&drift IT-syst

Virtual private nettvork (VPN)
Usikkert nett Opprett en vanlig nett-forbindelse Utveksle nøkler Opprett kryptert forbindelse tunnelert gj. vanlig forbindelse Rut all trafikk over kryptert forbindelse Bærbar VPN Sikkert nett Tjener Våren 2004 TDT4285 Planl&drift IT-syst

Passord ved fjernbruk Engangpassord Listegenererte (papir) Formelgenererte (’kalkulator’) Ende-til-ende-kryptering og VPN ’Vanlig’ passord og litt optimisme Våren 2004 TDT4285 Planl&drift IT-syst

Modembruk og kostnader
Oppringer bærer kostnader, evt: Ekstra installert tlf.linje eid av jobben Modem med call-back Refusjon av utgifter Fastlinje med faste kostnader 800-nummer Våren 2004 TDT4285 Planl&drift IT-syst

Observasjoner ... Rask utvikling, utstyret blir raskt utdatert Brukerne blir raskt fullstendig avhengig Tjenestene blir raskt kritiske Kan egne seg for out-sourcing Dersom du ikke lager løsningene for brukerne, så lager de sine egne (dårligere) løsninger Våren 2004 TDT4285 Planl&drift IT-syst

I tilfelle out-sourcing
Geografisk dekningsområde Teknologivalg og oppgraderingsmuligheter Direkte brukerstøtte eller via sysadmin? SLA: hva loves og hvordan måles det Faktureringsmodell Autentisering, bør ikke out-sources Sikkerhet Våren 2004 TDT4285 Planl&drift IT-syst

Internasjonale løsninger
Lokalt nettverk Lokal Internettleverandør Hotellets nett Via mobiltelefon til grønt nummer Opprette VPN Arbeide på ’jobbnettet’ Våren 2004 TDT4285 Planl&drift IT-syst

Kostnadsanalyser Når bruken er differensiert, hvordan kan deler av den håndteres billigere? At man detekterer når brukermassen av et gammelt system faller under kritisk masse. At man hele tiden vurderer ny teknologi, og i fall man velger det, har en aggressiv overfasing av brukere. Våren 2004 TDT4285 Planl&drift IT-syst

Oversikt over ITIL TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Hva er ITIL? Et rammeverk for strukturering av IT-driftsorganisasjoner Basert på erfaringer om best practice En tankemåte, som du ikke nødvendigvis må implementere slavisk, men som du kan la deg inspirere av. Offentlig og fritt tilgjengelig. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Historikken til ITIL ITIL Versjon 1 80-tallet 10+30 bøker ITIL Versjon 2 90-tallet 2+N bøker Engelsk statsforvaltning 2000-tallet Sannelig om jeg vet hva tiåret som starter på 2000 heter ... Det er mange historier om opphavet til ITIL, og de er ikke sanne, men er i alle fall gode historier, og inneholder sikkert alle en kjerne av sannhet. Den virkelige historien er at det startet internt i statsadministrasjonen, med en bottom-up tilnærming i Central Computer and Telecom Agency (CCTA), som senere ble svelget av OGC (Office og Government Commerce). Nederland Resten av verden Opphav (alle usanne): Thatcher-direktiv Falklandskrigs-IT-kaos IBM-outsourcing Google,april 2004: ITIL=357k, iso9000=1,94M Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Hvorfor bruke ITIL? Håndtere kompleksitet NEI Enklere JA Proaktivitet Billigere driftskostnader Dokumentasjon Forutsigbarhet Destillat av oppsamlet erfaringer Suboptimalisering Det er mange grunner for å velge ITIL, men de viktigste er nok helst at man trenger forutsigbarheten og kvaliteten som ligger i en godt styrt og drevet IT-tjeneste. Dernest kommer at man vil ha kontroll over en IT-tjenste som har ”løpt løpsk” og som ingen lengre har kontroll over. Den minst fornuftige grunnen er sannsynligvis å få ned driftskostnadene Reativitet Felles ”stammespråk” Avstemme forventninger Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

ITIL er prosessorientert
TDT4285 Planl&drift IT-syst Våren 2004 ITIL er prosessorientert Ledere Personer Mellomledere Roller ITIL Tradisjonelt Ansatte Deloppgaver Her kan vi nesten trekke sammenlikning med matriseorganisasjoner, som har noe av den samme frakoblingen fra linjeorganisasjonen som vi finner i en ITIL-inspirert organisasjon. Her kan man nevne noen eksempler på prosesser, som strengt tatt er ”saksbehandling”. Det kan være innkjøp av en PC, skaffe seg sertifikat for bil, få byggetillatelse for bolig. Merk at det er en fare i en prosessmodell at den enkelte får tunnellsyn utfra sitt eget ståsted, og ikke klarer å relatere sin egen situasjon til andre i organisasjonen eller til helheten. Dette må motvirkes! Sammenlign med fremmedgjøring generelt – fordrer at man har oversikt over helheten, ikke bare sin egen lille del av den. Prosesser Fagområder Oppgaveorienter, ikke-hierarkisk Top-down, kontroll, arbeidsområder Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 ITILs 10 hovedprosesser Service Desk Service Level mgmt Financial mgmt for IT-services Incident mgmt Problem mgmt ITIL Capacity mgmt Config. mgmt IT Services Continuity mgmt Og dersom man teller, så er det her elleve underområder. Det er fordi service desk ikke er en prosess, men en funksjon, men i ITILs beskrivelser er den ”opphøyet” til samme nivå som de andre. Change mgmt Availability mgmt Release mgmt Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Hva er ikke ITIL? ITIL er ikke: ...en ferdig byggetegning, men byggeklosser du selv kan sette sammen etter behov. ...noe du implementerer i en fei, men et sett med prosesser som du må igangsette, og deretter vedlikeholde og kontinuerlig endre og forbedre. ...noe du kjøper, men noe du må innarbeide i bevisstheten i driftsstaben din. ...simpelthen en styringsmekanisme, men en prosessmodell som du organiserer staben etter for at den skal ta tak i problemene på en hensiktsmessig måte. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Kunder og brukere... Service Delivery =rødboka Service Support =blåboka Service Desk Incident mgmt Problem mgmt Config. mgmt Change mgmt Release mgmt Service Level mgmt Financial mgmt for IT-services Capacity mgmt IT Services Continuity mgmt Availability mgmt ITIL Bruker Kunde ITIL deler de sentrale prosessene inn i to deler: Service support og Service delivery, der førstnevnte de er som retter seg mot brukerne, og sistenevnte er de som retter seg mot kunden. Forklar at kunden er den som kjøper tjenester, mens brukeren er den som benytter tjenester. Det er forskjell på dem (selv om det kan være overlapp). Men merk at det er overlapp mellom disse funksjonene, og at dette bare er de grove tendensene som er delt inn slik. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Service desk Målsetning: En service-desk er en ITIL funksjon som er et single point of contact (entry) som håndterer alle henvendelser fra brukerne. Oppgaver: Tar imot henvendelser, utfører oppgaver og etterforsker incidents, vanligvis innenfor incident mgmt. Foreslår endringer. Eskalerer. Våren 2004 TDT4285 Planl&drift IT-syst

Incident mgmt Målsetning å gjenopprette normale tjenester, evt minimalisere problemer ifm med et tjenesteavbrudd. Oppgaver: Ta imot, klassifisere, og følge opp innmeldte problemer. Hjelpe bruker. Eskalere vanskelige problemer. Detektere mønstre og identifisere når det er underliggende problemer. Våren 2004 TDT4285 Planl&drift IT-syst

Problem mgmt Målsetning: både proaktivt og reaktivt å redusere effekten og hyppigheten av incidents som reduserer tjenestene. Oppgaver: Finne underliggende årsaker til ukjente problemer. Lage work-arounds eller endringsforslag for kjente problemer; evt iverksette mekanismer for å dempe effekten av problemer/feil. Våren 2004 TDT4285 Planl&drift IT-syst

Configuration mgmt Målsetning: Vedlikeholde en database over alle ”enheter”, dels som støtte for andre prosesser, dels for å beskrive systemet i seg selv, og dels for å kunne konfigurere systemet korrekt. Oppgaver: innarbeide en database over alt utstyr mm, samt relasjoner mellom dette. Vedlikeholde denne. Våren 2004 TDT4285 Planl&drift IT-syst

Change mgmt Målsetning: Sørge for en strukturert og definert endringsprosess, der negative effekter er luket ut, og der alle relevante og impliserte parter er tatt med på råd. Oppgaver: Ta imot, behandle, prioritere, godkjenne, koordinere endringer. Håndtere endringslogging og historikk. Våren 2004 TDT4285 Planl&drift IT-syst

Release mgmt Målsetning: Å se sett av enkeltendringer i sammenheng, slik at de samles til releases. Oppgaver: Pakke sammen endringer som ”hører sammen”, planlegge og overvåke utrullingen av slike pakker. Teste. Lage backout-plan. Våren 2004 TDT4285 Planl&drift IT-syst

Service Level mgmt Målsetning: Være den primære kontakten med kunden, og stå for forhandlinger og revidering av avtaler. Oppgaver: Fremforhandle, følge opp og revidere SLA med kunde og OLA internt. Ha oversikt over hva som kan leveres til nye kunder, evt skaffe dette. Våren 2004 TDT4285 Planl&drift IT-syst

Financial mgmt for IT-services
Målsetning: Gi en sunn økonomisk basis for drift av utstyr og ressurser. Oppgaver: Utarbeide og foreslå økonomiske modeller for fakturering av kunder. Holde oversikt over kostnader ved driften av systemet. Hjelpe til i planlegging av økt kapasitet. Våren 2004 TDT4285 Planl&drift IT-syst

Capacity mgmt Målsetning: Gi grunnlag for å balansere tilgjengelige ressurser mot hva man har forpliktet seg til å levere. Oppgaver: Monitorere, igangsette tuning, influere på bruksvolum, estimere og regne ut trender. Produsere en capacity plan for planlegging av videre utvidelser. Våren 2004 TDT4285 Planl&drift IT-syst

IT Service Continuity mgmt
Målsetning: Sikre at leveransene av tjenester kan fortsette å betjene kundene selv ved alvorlige hendelser som setter deler av utstyret ut av funksjon. Oppgaver: Planlegge, analysere, implementere en katastrofeplan, teste, revidere, trene og oppdatere denne. Våren 2004 TDT4285 Planl&drift IT-syst

Availability mgmt Målsetning: Fremskaffe data som viser om ytelsen til de leverte tjenestene har tilstrekkelig høy kvalitet. Oppgaver: Finne relevante målepunkter, sette opp monitorering, analysere og lage trendrapporter, etterforske spesielle situasjoner, vedlikeholde en Availability Plan. Våren 2004 TDT4285 Planl&drift IT-syst

Service support CMDB The Business, Customer or User Config. mgmt
Kilde: OGC: BestPrcatice for Service Support Service support The Business, Customer or User Difficulties Queries Enquiries Communications Updates Work-arounds Mgmt tools Incidents Changes Releases Incidents Service desk Config. mgmt Incident mgmt Change mgmt Problem mgmt Release mgmt Service reports Incident statis Audit reports Problem stats Trend analysis Probl reps Problem revs Diag aids Audit reps Change sched CAB minutes Change stats Change revs Audit reps Release sched Release stats Release revs Secure library Testing std Audit reps CMBD reps CMDB stats Policy/std Audit reps CMDB Problems Known errs CIs and relations Incidents Changes Releases Våren 2004 TDT4285 Planl&drift IT-syst

Service delivery Business, Customer and Users Queries Enquiries
Kilde: OCG: Best Practice for Service Delivery Service delivery Business, Customer and Users Queries Enquiries Communication Updates Reports Availability mgmt Requirements Targets Achievement Capacity mgmt Service Level mgmt SLA, SLR, OLA Service reports Service catalogue SIP, Exception reports Audit report Avail Plan AMDB Design crit Targets Thresholds Reports Audit reps Capacity plan Capacity DB Targets/thresholds Capacity Reports Schedules Audit reports Financial Plans Types and models Cost and Charges Reports Budgets/Forecasts Audit reports IT Continuity Plans BIA and Risk analysis Requirements Def’s Control centers DR contracts Reports Audit reports Financial Mgmt for IT-services Alerts and Exception Changes IT Service Continuity mgmt Mgmt tools Våren 2004 TDT4285 Planl&drift IT-syst

ITIL og ISO9000 Lokalt Ditt lokale system ITIL rammeverk Best practice Globalt ISO9000 Erfaringer Spesifikt Generelt Våren 2004 TDT4285 Planl&drift IT-syst

Balanserende spissformuleringer...
TDT4285 Planl&drift IT-syst Våren 2004 Balanserende spissformuleringer... Kan man kanskje påstå at ITIL er... ... et gufs fra 70-tallet ... en metode for å få organisasjoner til å virke på tross av medlemmenes manglende kompetanse og koordinering ... siste nye mote blant IT-ledere ... et lokalt men ikke nødvendigvis et globalt maksima Siden vi har sagt så mye pent om ITIL til nå, så burde det være mulig å si noe negativt for å balansere bildet. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

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

E-post – Personvern Det forventes at e-post er privat Punkt til punkt-kryptering Signaturer Rammer er gitt i nasjonal lovgivning Ulike typer informasjon: E-post-innhold Info om avsender/mottaker Info om volum Våren 2004 TDT4285 Planl&drift IT-syst

Struktur for E-postsystemer
Epostklient Epostklient imap pop SMTP Eposttjener local (fs) SMTP Eposttjener Eposttjener DNS MX for idi.ntnu.no MX for whitehouse.gov Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Navnerom Navnerom for underorganisasjoner Navnerom for tjenermaskiner (aliases) Navnerom for personers adresser Fornavn.etternavn –format Brukernavn-format Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Pålitelighet Hovedprioritet: at e-post ikke mistes Vedlegg: At vedleggene kommer frem uten at endret innhold At vedleggene kan pakkes ut At posten kommer frem tidsnok Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel på headerfelt i epost
Return-Path: Delivery-Date: Wed Mar 26 15:06: Received: from trane.uninett.no (trane.uninett.no [ ]) by ray.idi.ntnu.no (8.12.8/8.12.8) with ESMTP id h2QE6ZAZ for Wed, 26 Mar :06: (MET) Received: from scar.als.ntnu.no (scar.als.ntnu.no [ ])by trane.uninett.no (Postfix) with ESMTP id 84318D9EE for Wed, 26 Mar :06: (CET) Date: Wed, 26 Mar :07: From: Hans-Petter Ulven X-Mailer: The Bat! (v1.62i) Personal Reply-To: Hans-Petter Ulven X-Priority: 3 (Normal) Message-ID: To: Anders Christensen Subject: NKUL 2003 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.8 required=6 X-Virus-Scanned: by amavisd-new-IDI hei igjen, NKUL nærmer seg, og jeg håper du er villig til å hjelpeoss litt også i år: Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Enkelhet Standardisering Mellom ”postkontorer” (dvs SMTP) Mellom ”leser” (mail-klient) og ”postkontor” Adskille funksjonalitet E-post-transport E-post-levering Listehåndtering Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Generelt oppsett
Single-point-of-entry All post til/fra en adresse (alias) Kan kommunisere med alle andre Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Automatisering
Håndtering av e-postlister Oppretting og sletting av konto Flytting av en konto mellom tjenere Sjekking av aktive konti Sjekking for virus Redirigering og forward’ing Våren 2004 TDT4285 Planl&drift IT-syst

E-post - Monitorering Volum, for rett skalering Sær bruk, detektering av misbruk Feilmelding til postmaster Oppetid og tjenestenivå Loggmeldinger for feil Våren 2004 TDT4285 Planl&drift IT-syst

E-post – Redundans Parallelle systemer for automatisk fall-back Alternative systemer for å dimensjonere for mulig bortfall. Redundans internt på mail-maskinene Våren 2004 TDT4285 Planl&drift IT-syst

E-post - Skalering Tilstrekkelig skalering overføring mellom posttjenere Levering til sluttbruker Listepost Gj.snittlig kontra rushtrafikk Polling kontra varsling (ifm ny post) Våren 2004 TDT4285 Planl&drift IT-syst

E-post - Sikkerhet Sikring mot innsyn Mens det er lagret Under transport (kryptering) Sikring at rett person får tilgang Mulighet for å spore bakover Våren 2004 TDT4285 Planl&drift IT-syst

E-post - spam Metoder Åpne relayer Epostlister Motmidler Svartelisting Stengning av relayer Scoring på bakgrunn av innholdsanalyse Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel på spam-headere
TDT4285 Planl&drift IT-syst Våren 2004 Eksempel på spam-headere Delivery-Date: Wed Mar 26 17:04: Received: from adsl dsl.snfc21.pacbell.net 4.dsl.snfc21.pacbell.net [ ]) by ray.idi.ntnu.no (8.12.8/8.12.8) with SMTP id h2QG3pAZ018184; Wed, 26 Mar :03: (MET) Received: from 0korj.5nmaeq.com [ ] by adsl dsl.snfc2 1.pacbell.net id ZBX55jmD268d; Wed, 26 Mar :58: Message-ID: From: "Lottie Barajas" To: Subject: Fw: Valium, Buspar, Zoloft, Vioxx and more! Date: Wed, 26 Mar 03 06:58:23 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4B_D874C5.DA23." X-Spam-Status: No, hits=5.9 {E9} required=6.0 tests=BIG_FONT,CLICK_BELOW,EXCUSE_3,HTML_FONT_COLOR_BLUE, MIME_HTML_NO_CHARSET,MISSING_MIMEOLE,NORMAL_HTTP_TO_IP, OUTLOOK_FW_MSG,REMOVE_PAGE,SPAM_PHRASE_08_13,USER_AGENT_OE X-Spam-Flag: No X-Virus-Scanned: by amavisd-new-IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

E-post – informasjon Brukerne må informeres om følgende: AUP for e-postsystemet Rutiner or sikkerhethetskopiering Personvern Våren 2004 TDT4285 Planl&drift IT-syst

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

Hva er en tynn klient? Få persistente data Kun grensesnitt (kbd/mus/skjerm) Ingen/få bevegelige deler Enkel/begrenset protokoll Benytter sentrale ressurser Uselvstendig datamaskin Angir tendeser, ikke krav! Våren 2004 TDT4285 Planl&drift IT-syst

Eksempler Seriekonsoller (70-80-tallet) X-terminaler (typisk 90-95) SunRay-terminaler (fra 99) RDP-terminaler (Microsoft) ICA-terminaler (Citrix) Våren 2004 TDT4285 Planl&drift IT-syst

Moores lov Pris/ytelse på minne (og CPU og disk) dobles hver attende måned. Gir ca tusendobling i løpet av 15 år. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Moores lov ... Gjelder ikke: Tastatur (~102) Mus (1-3) Skjerm (1,2Mpixel) Gjelder for: Harddisk (x1250) Minne (x1000) CPU-kraft (x750) Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Fordel: Ergonomi Bevegelses-løst Støyløst! Power-vifte Harddisk CPU-vifte Ventilasjonsanlegget blir det man klager på, ref VVS hos Teknisk avd. Merker ikke støyen før den forsvinner, ref til gamle PC’er Man merker ikke ’unormal’ støy fordi den drukner i den ’normale’ støyen. Diskettstasjon CD-ROM Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Fordel: Kortere reparasjonstid
Ingen bevegelige deler Enklere enheter Lavere repera- sjonstid Ingen brukerdata Bytte istf reparere Få/ingen konfigdata ”Primitiv” protokoll Omskiftbart brukerutstyr Våren 2004 TDT4285 Planl&drift IT-syst

Fordel: Lavere kompleksitet
Flere helt-like-maskiner Færre frihetsgrader på klientene Skille grensesnitt og ’maskinen’ Våren 2004 TDT4285 Planl&drift IT-syst

Fordel: Forenkelt arv Utgangspunkt: de viktigste brukerne vil ha det kraftigste utstyret. Problem: mye omflytting. Løsning: Tynne klienter Bytting kun på maskinrom Rask ombyttingstid Våren 2004 TDT4285 Planl&drift IT-syst

Fordel: Lite tyveriutsatt utstyr
Godsakene er på maskinrommet! Utstyret er ”billig”! Lite nyttig som selvstendig hjemmemaskin. Våren 2004 TDT4285 Planl&drift IT-syst

Nulladministrasjon Nulladm er når utstyr ikke trenger en administrativ overhead. Ved nulladm er ”adm” bakt inn i bruken Eksempler Kulepenner Brødristere SunRay1-terminaler Våren 2004 TDT4285 Planl&drift IT-syst

Fordel Mindre spredning av fokus
For 150 PC-er Fokus på 150 enheter For 10 tjenere og 150 tynne klienter Fokus på 10 tj. og en klientmodell (=11 enh.) Tjenerne er samlet: fysisk organisatorisk bruksmessig Våren 2004 TDT4285 Planl&drift IT-syst

Andre fordeler Lettere å bruke fra reise/hjemmet Tynne klienter divergerer ikke Ikke så hurtig omløp på nye komponenter Tar minutter (ikke timer) å sette opp Skalerer dynamisk lettere Våren 2004 TDT4285 Planl&drift IT-syst

Ubrukelige deler til overs!
Oppgrad av PC-er Idag 150 PC-er à 6.000,- ,- Sum 100 arb.pl idag +18mnd Masse arbeid Best Verst 150 CPU-er à 1250,- ,- N/A 75 RAM à 750,- 53.750,- ,- Harddisk à 500,- 37.500,- 75.000,- Sum 100 arb.pl om 18 mnd ,- Passer ikke til hovedkortet! 50 med 1 HD og 50 med 2 Ubrukelige deler til overs! Våren 2004 TDT4285 Planl&drift IT-syst

Oppgrad av tynne klienter
TDT4285 Planl&drift IT-syst Våren 2004 Oppgrad av tynne klienter Idag 150 Klienter à ,- ,- 10 Tjenere à ,- ,- Sum 100 arb.pl idag ,- 150 Gml klienter (har allerede) 0,- 10 Gml tjenere 5 Nye tjenere à ,- 75.000,- Sum oppgrad etter 18 mnd +18mnd 100% gjenbruk! Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Nytteverdi av arbeidsplass
Funksjon- alitet Antall år Våren 2004 TDT4285 Planl&drift IT-syst

Oppgradering av Term.tjener
O>alder>1 12 6 1>alder>2 2>alder>3 Våren 2004 TDT4285 Planl&drift IT-syst

Utstyrskostnad, PC ,- = Uten skjerm Levetid på 4 år Oppdatering etter to år: 150x2000,- Totalt: 8.000,- over 4 år, 2000/år Våren 2004 TDT4285 Planl&drift IT-syst

Utstyrskostnad, klient
,- = ,- Uten skjerm Levetid på 5 år ,- = ,- Tilsvarer 1000,- pr klient Oppdatering, 500,- pr år i neste 4 år Totalt: 6.000,- over 5 år, 1200/år Våren 2004 TDT4285 Planl&drift IT-syst

Diskusjon Levetid: 4 vs 5 år Lavere kostnader pr år Jevnere styrke pr arb.plass Gjenbrukbare tjenere etter 5 år Bedre fordeling av utgifter over årene Våren 2004 TDT4285 Planl&drift IT-syst

Ulempe: Tregere skjermoppdatering
Video Dersom svært rask oppdatering av skjermen er viktig, er tynne klienter et dårlig valg. Tenk millisekund, ikke mikrosekund! Grafikk Editorer Våren 2004 TDT4285 Planl&drift IT-syst

Ulempe: Fungerer dårlig for ...
Tung CPU-bruk Vanskelige programmer Priviligerte, lokale brukere Uttakbare media Video-streaming Høy grad av sikkerhet Våren 2004 TDT4285 Planl&drift IT-syst

Ulempe: Krav til stabilitet og konsistens
Tjenerne blir single-point-of-failure Fordrer høyere oppetid Fordrer redundante systemer Tjenerne bør være mest mulig like ULEMPE!? Våren 2004 TDT4285 Planl&drift IT-syst

Fremtid: Protokollisering
Noen få protokoller vil vinne frem De vil være hardt standardisert (åpne) ”Alle” vil støtte dem Historiske eksempler: ASCII og ISO-Latin-1 RS-232 SMTP Våren 2004 TDT4285 Planl&drift IT-syst

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

Skrivere på IDI Ca 30 skrivere Ca modeller Spredd på 4 (11) blokker i 3 (5) bygg Bruker 2 mill ark i året Toner/papir/etc for pr år Feil fra 1/100 til 1/ sider Våren 2004 TDT4285 Planl&drift IT-syst

Spørsmål ifm skriverbruk
Hvem skriver ut hvor mye? Hva koster hver side? Hva er MTBF? Hva er TTR? Har skriverne kvalitetssenkning? Hvor mye er feilutskrifter? Hvor mye er ’unødvendig’ utskrift? Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Kostnader Utgifter Initielt: innkjøpspris Drift: personalkost Rekvisita: papir og toner/blekk Service: slitedeler Inntekter fra bruk: Kostnad pr side Fastpris pr bruker Fastpris pr avd Kombinasjon av de overstående Fortell om kyocera-skriverne våre, der vi betalte 4,5 øre pr side i utskrift, og det omfattet slitedeler som skulle skiftets ut ved ca sider. Imidlertid ble skriverne mindre og mindre brukbare (og eldre og eldre) etterhvert som dette nærmet seg, og vi fikk i praksis aldri tatt ut denne oppsparte fordelen. Moral: Ikke betal i forkant av at noen skal levere noe, spesielt dersom de har kontroll på om og når det skal leveres. Samt ikke hopp på avtaler med ”fordelsprogrammer” som gir deg ting du trolig aldri kommer til å få bruk for. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Kompleksitet mht skriverne
TDT4285 Planl&drift IT-syst Våren 2004 Kompleksitet mht skriverne styre- spåk opsys Skriver- driver Skriverkø definisjoner nettverk Applikasjon konfigurasjon Skriver tilbakemelding Gjett hvor mange steder man her kan sette format til A4 eller letter? forståelse fikling mekanikk oversikt Bruker rekvisita Hardcopy Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Sentralt eller desentralt?
Store sentrale beist Robust løsning Hurtig Enkelt å vedlikeholde Få løsninger (gir bedre oversikt) Single point of failure Små desentale skrivere Nært til bruker Autonomt Tilgjengelig Redundant Tilpassningsdyktig Våren 2004 TDT4285 Planl&drift IT-syst

Skrivermodell 1 (gammel)
parallell Maskin3 Skriver3 Bruker nett Maskin2 Skriver2 Skriver koblet på en maskin Konfigurasjons- fil gav automagisk rett skriver serie Maskin1 Skriver1 Våren 2004 TDT4285 Planl&drift IT-syst

Skrivermodell 2 (mellomløsning)
Windows- bruker Unix- bruker Win-tjener Ferdig- melding Maskin2 Køer på både Windows og Unix Maskin1 Oppsettskollisjon Skriver3 Skriver1 Skriver2 Våren 2004 TDT4285 Planl&drift IT-syst

Skrivermodell 3 (dagens)
Unix- bruker Windows- bruker lpd ”samba” tilbakemelding Maskin vanlig datanett Skriver1 Skriver2 Skriver3 Våren 2004 TDT4285 Planl&drift IT-syst

Dagens skriverproblemer på IDI
Mange feilsendte utskrifter Forsidearket inneholder ikke eier Manglende monitorering Uavklart rekvisitaoppfølging Lite statistikk Kan skrive rett til skriverne Uklart om konfigurering er korrekt Våren 2004 TDT4285 Planl&drift IT-syst

Et vedlikeholdsmareritt
... hver datamaskin har en lokalt tilkoblet blekkskriver av varierende fabrikat og modell, som ikke bruker samme type blekk, som er uten vedlikeholdsavtaler, er kjøpt inn uten styring, og har laber kvalitet. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Multimaskiner Kopi, skriver og fax i en enkelt boks! Ulemper: Spesial purpose ”black box” Kollisjon i bruks-mønster Fordeler: Gjenbruk av utstyr Single point of service Mer kostnadseffektivt Kollisjon i bruksmønster: fortell om hvordan sekretærene blir fly forbanna når noen sender ut utskriftjobber midt inne i deres kopieringsjobber (som de tom har reservert srkiveren for) Spesial purpose black box: En spesial purpose windowsboks som styrer en skriver er ok, men det kan bli farlig å sette den på nett, fordi den kan ”tas” ved et innbrudd. Dersom den er isolert fra nettet er det mindre problemer. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Styrespråk og protokoller
Styrespråk (hvordan utskriften beskrives) Postscript PCL ”Windows-skrivere” Protokoller (hvordan man snakker til skriveren) lpd ftp TCP-port 9100 IPP (Internet printing protocol) Våren 2004 TDT4285 Planl&drift IT-syst

Papir er vel bare papir? Vekt i gram pr m² (A4=1/16 m²) Overflatens ruhet Papirets hvithet Fuktighets Utflytningsevne Oppsugningsevne Hvor mye støv avgir det Våren 2004 TDT4285 Planl&drift IT-syst

Systemdokumenter Generell skriverarkitektur Faktureringspolitikk Skriverutstyrsstandard Langsiktig støttede standarder Kortsiktig standardiserte modeller Navngivningspolitikk Skrivertilgangspolitikk Våren 2004 TDT4285 Planl&drift IT-syst

Brukerdokumentasjon Beskrivelse av hvordan man skriver ut, lister køer, sletter jobber, etc Liste over alle skrivere Merkelapper på hver skriver Våren 2004 TDT4285 Planl&drift IT-syst

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

Tre bruksmåter av monitorering
Historisk (fortid) Real-time (nåtid) Varsle driftsansvarlig/vakt Automatisk fikse problem Ekstrapolering (fremtid) Ressursestimering Vedlikeholdsplanlegging Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel 1 på statistikk
Temperatur på CPU og chipset målt hvert 5. minutt Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel 2 på statistikk
Bruk av en datasal fordelt over ukens dager. Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel 3: antall Epost
Vår 2003 Lokal feil Vår 2002 Antall epost Dager Våren 2004 TDT4285 Planl&drift IT-syst

Realtime monitorering
Oppdatering Statistikk Terskel- verdier Nåverdier Kontroll Logging Avlesing Varsling Historiske data Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel 3 (top) eos$ top -b 10 last pid: 13779; load averages: 14.19, 14.07, :44: processes:1963 sleeping, 14 running, 77 zombie, 5 stopped, 2 on cpu Memory: 4096M real, 5254M swap in use, 9015M swap free PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND 17122 bruker M 16M run H 11.15% java_vm 16840 bruker M 16M run H 8.32% java_vm 11691 bruker M 18M run H 8.31% java 10849 bruker M 4280K run H 7.83% 14836 bruker M 66M run 872: % mozilla-bin 11200 root M 44M sleep 854: % Xsun 17195 bruker M 17M run H 5.72% java_vm 21052 root M 18M cpu0 57: % Xsun 1146 root M 30M sleep 695: % Xsun 4317 bruker M 19M sleep 640: % opera Våren 2004 TDT4285 Planl&drift IT-syst

’Parallellvarsling’ Dvs at en gruppe varsles samtidig. Problemstillinger: ”De andre tar sikkert denne saken” Enkelte står på lista kun som interesserte, ikke for å håndtere feil. Flere starter å jobbe med samme feil uten å vite om hverandre. Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel 4 (vmstat) eos$ vmstat 5 procs memory page disk faults cpu r b w swap free re mf pi po fr de sr s0 s1 s6 -- in sy cs us sy id Våren 2004 TDT4285 Planl&drift IT-syst

Varsling ved feiltilstand
Hvem skal varsles Eskalering. Hvis person ikke responderer Hvis situasjonen forverrer seg Kanaler å varsle på Forståeligheten i varslet Testing og brannøvelser Våren 2004 TDT4285 Planl&drift IT-syst

Hvem skal varsles? Til personer eller til vakttelefon? Innenfor og utenfor arbeidstid? Har mottakerne betalt for å ta imot og håndtere feilmeldingene? Våren 2004 TDT4285 Planl&drift IT-syst

Eskaleringsregler Hvis situasjonen ikke bedrer seg, doble ventetiden før ny melding. Hvis ikke førstemann responderer, varsle også nestemann i parallell. Hva hvis situasjonen forverres? Våren 2004 TDT4285 Planl&drift IT-syst

De-eskaleringsregler
Dersom en tilbakemelder eierskap på et problem, send kontraordre til andre som måtte være varslet. Dersom problemet forsvinner, send kontrabeskjed til alle tidligere varlede. Våren 2004 TDT4285 Planl&drift IT-syst

Kanaler å varsle på Idag: SMS Mobiltelefon E-post (Personsøker) Tidligere: Høyttaleranlegg/callinganlegg Våren 2004 TDT4285 Planl&drift IT-syst

Alle varsel må være forståelige
Moteksempel: varsel om feil i maskinrommet til IDI BAS 337EL02XX04a PRI 5 ( :15) (men ’alle’ har fått word-dokument som beskriver hva hvert enkelt tegn i den kodede meldingen står for ...) Våren 2004 TDT4285 Planl&drift IT-syst

Testing To strategier: Systemet brukes ofte nok til at man har tillit til at det virker og at man ville oppdage om det brøt sammen. Aktiv testing med jevne intervaller som er bestemt på forhånd. Våren 2004 TDT4285 Planl&drift IT-syst

Mer om testing Kan være på forhåndsdefinerte tidspunkt, og mottaker varsler dersom han ikke får beskjed. Kan være ad hoc, der mottakere bare skal svare at de har fått meldingen. Kan være ’hemmelig’, for å se hvem som svarer, og hvor fort. Våren 2004 TDT4285 Planl&drift IT-syst

Hvordan detekteres det?
Tre ulike dimensjoner for monitorering Polling eller interrupt-basert? Teste funksjonalitet eller verifisere tilstand? Tilgjengelighet eller kapasitet? Våren 2004 TDT4285 Planl&drift IT-syst

Eksempler Polling: ping Interrupts: virusfilter på e-post Teste funksjonalitet: koble opp imap Verifisere tilstand: avmåle temp-sensor Tilgjengelighet: hente web-side Kapasitet: sjekke båndbredde Våren 2004 TDT4285 Planl&drift IT-syst

Nummerisk eller tekstlig?
Numeriske loggdata er en måleverdi eller frekvens av hendelser Tekstlige loggdata er en ”fritekst” melding som er logget på et gitt tidspunkt. Våren 2004 TDT4285 Planl&drift IT-syst

Eksempel på tekstlige loggdata
Apr 27 00:26:40 ts-stud13 MOUNT: stud OK=S:\\vier\bruker1 Apr 27 00:28:36 vier smbd[27240]: [ID daemon.error] [2004/04/27 00:28:36, 0, pid=55555, effective(0, 0), real(0, 0)] lib/util_sock.c:(342) Apr 27 00:28:36 vier smbd[27240]: [ID daemon.error] read_socket_data: recv failure for 4. Error = Connection timed out Apr 27 03:02:17 vier rpc.nisd_resolv[544]: [ID daemon.error] nres_gethost byaddr: mail.ade.az.gov != Apr 27 00:34:54 zapf cupsd[62584]: [Job 51650] Unable to connect to printer (retrying in 30 seconds): Operation timed out Apr 27 08:00:53 sb246 printer: offline or intervention needed Apr 27 08:00:53 sb246 printer: paper out Apr 27 08:01:32 sb246 printer: error cleared Apr 27 09:39:48 ask dhcpd: [ID daemon.error] Lease conflict at Våren 2004 TDT4285 Planl&drift IT-syst

Fremtidig utfordringer innen systemadm
TDT4285 Planl&drift IT-syst Våren 2004 Fremtidig utfordringer innen systemadm TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Fremtidsscenario ...? 2005: En stor leverandør legger seg på en ny paradigme for drift. Det blir en suksess. Alt begynte å virke sammen på skrivebordet. Driverproblematikken ble skikkelig løst. 2006: Sikkerhetsproblematikken løses ved grundig releaseengineering og automatisert, sentralisert patching fra leverandør. Datamaskiner overalt! 2007: Den nye paradigmen for datamaskiner vinner frem. De fleste tjenersystemene konverteres. 2008: Det papirløse samfunnet kommer, og virker! 2009: systemadministratorer blir arbeidsløse, fordi datamaskinene gjør akkurat det som brukerne ønsker. 2010: Fred i verden. Amazonas gror til igjen. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

... eller kanskje ikke? flere devices, men snakker de sammen? alt på nett, men hva med sikkerhet? datamaskinene kan gjøre alt, bortsett fra akkurat det du har behov for? kanskje datamaskinene ble mer intelligente, men hva med brukerne? datamaskinene er kraftige, men hvem passer på at du ikke mister siste kopi av data? Våren 2004 TDT4285 Planl&drift IT-syst

Ni utfordringer Ikke være walking overhead Kommunikasjon Takle fallende status Skalerbarhet Endringshåndtering Kompetanseoppdatering Organisering Effektivisering og målfokus Bli et eget fagfelt Våren 2004 TDT4285 Planl&drift IT-syst

1. Ikke være ’Walking Overhead’
TDT4285 Planl&drift IT-syst Våren 2004 1. Ikke være ’Walking Overhead’ Nå-situasjon: Sysadmin drift ses på som en administrativ overhead. Ses på som manuell stand-in for manglende teknologi. Problem: Blir en salderingspost for innsparinger, potensielt eliminerbar. Utfordring: Bli en kreativ del av organisasjonens primærviksomhet. En nødvendig ’del’ av produksjonen. Dersom du skal produsere biler, så er ikke gode dekk en overhead, men en investering, en ting man bruker penger på for å få en kost/nytte-effekt. Designeren er ikke en utgiftspost, men en nødvendig del av prosessen for å få et godt produkt. Men: IT-drift sees på som nødvendig bare fordi teknologien ikke er god nok, og driftspersonene som gisseltakere som ikke trengs lengre når teknologien har utviklet seg. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 ’Hobbydrifterne’ Professjonell IT-drift Helauto- matisk Avansert Hobbydrifterne ... Hjemmedrifterne ... Bærbardrifterne ... Lunsjpausedrifterne ... Har-lest-CWN-drifterne ... Paradigmeskifte Middels Riksmålsordboken har tre betydninger av ordet ’drifte’: 1) være ute på fangst (til havs) med fiskefartøy; 2) Føre dyr i drift (dvs: (større) flokk av dyr som drives samlet av sted ell holder sammen); 3) sj., farte, flakke frem og tilbake, fra sted til sted. Unnskylde at jeg sier stygge ting om CWN, det er ikke bladet som er problemet, men de leserne som tror de er verdensmestre bare de har lest ett nummer eller to. Kommer fra reklame. Paradigmeskifte: vanskelig begrep. Innenfor en størrelsesorden holder tommelfingerreglene; innenfor to størrelsesordner holder overordnet teori. Men når noe endrer seg mer enn tre størrelsesordner blir det et paradigmeskifte. Enkel 1 10 100 1000 10.000 Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Yrker som har ’forsvunnet’
TDT4285 Planl&drift IT-syst Våren 2004 Yrker som har ’forsvunnet’ Bøtker – bruker ikke fat lengre Kortpunchoper – overtall av bruker Skomaker – billigere å kjøpe nytt Konduktør – overtatt av sjåføren Tlf-bordoper – automatisert bort IT-driftsperson? Konduktør – også: telegrafist Kortpunchoper – også: skrivestuedame; ekspeditør bak disk, heisstoloperatør Bøtker – også: stråtaktekker, koppersmed Skomaker – også: skredder, datamaskinreperatør (lodder), Tlf-bordoper – også: kopist IT-driftspersoner i fremtiden: endres snarere enn forsvinne. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Har IT-drift en fremtid?
Ja, så lenge: man bruker datamaskiner, og ikke brukerne kan gjøre det selv, og det er dyrt å kjøpe nytt, og ikke en annen gruppe overtar, og ikke det kan automatiseres bort, så har IT-drift en fremtid. Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Missionstatement? IT-drift har en fremtid ved å inneha spesialkompetanse (både på teknologi og metodikk) som ingen annen gruppe har; ved å sørge for tilgjengeliggjøring og god ressursutnyttelse; og ved å fokusere på de oppgavene som ikke kan automatiseres – dvs være den som limer sammen løsrevne komponenter til et fungerende hele. Alternativer Holde brukeren fornøyd Holde systemet oppe Gi brukeren det de ville ønsket seg dersom de visste sitt eget beste. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 2. Kommunikasjon Nå-situasjon: Mange innen SA har ikke veldig gode sosiale antenner. Problem: Dårlig kommunikasjon skaper og forsterker problemer. Utfordring: Snakke så folk forstår en. Ta 100% ansvar for egen kommunikasjon. Dyrke frem sosiale antenner. Eksempel: (feilsøking) ... Å, maskinen må reinstalleres, bare jeg får den på kontoret mitt, så skal jeg fikse det. (drift tror: han bringer meg maskinen. Bruker tror: han henter maskinen.) Problemet: passiv form. Ansvaret for kommunikasjon er ikke på hver part, men på hver part. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Hva drepte regnesentrene?
TDT4285 Planl&drift IT-syst Våren 2004 Hva drepte regnesentrene? Var det: PC-en? Prisene? Brukerne? Kompetanse- mangel? Sentralisering? Administrativ overhead? Brukerne IT-drift PC PC-ene var den tekniske løsningen der drapet var mulig. At prisene ble lave nok var en forutsetning for å kunne gjøre det. Brukerne var de som utførte det. Kompetansemangelen var et symptom på at brukerne hadde andre prioriteringer enn det som IT-drift har. Sentraliseringen var bare en følge av den måten å se ting på. Adm overhead var en følge av sentraliseringen. Men det som forårsaket det var arrogansen til regnesenterne, der brukerne var brukere som måtte finne seg i å stå i kø og ta til takke med det som de allernådigst fikk. Den driftsorganisasjon som ikke klarer å sette prioriteringene til brukerne fremfor sine ønsker og synspunkter for datamaskinene er i praksis døende. For å klare å ta disse prioriteringene, trenger man å kommunisere med brukerne. Ingen maskin er så veldrevet som den som brukerne har forlatt. Datamaskinene Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 3. Fallende status Nå-situasjon: Drift er blir ’bare’ en høyteknologisk vaktmester, ikke en spesialisert mirakelmann. Problem: Statusen til drift er i fritt fall. Utfordring: Takle at datamaskinen ikke lengre er ’Gud’ og sysadmin hans yppersteprest. … Ellers reduseres man til dørvakta i Øystein Sundes sang ’du måkke komme her og komme her ... Denna døra er mi.’ Og det blir bare patetisk. Bofh er død. De out-sourcet oppgavene hans og sprettet champagnekorken da han forlot dem. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Been there, done that ... Andre som har ’mistet’ sin status Lokomotivføreren Læreren Presten Ingeniøren Skipskonstruktøren Urmakeren Flyveren Årsak: Det man holder på med mister glansen fordi det (eller tilsvarende og kulere ting) blir dagligdags, så som for lokomotivførerne. Og/eller man trenger ikke yrket som innfallsport for kontakt med det kule. Idag er disse yrkene kun for spesielt interesserte. Så la oss ikke stå igjen som en gretten has-been, og surmule over at resten av verden ikke ser lyset. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Hva gir status i fremtiden?
TDT4285 Planl&drift IT-syst Våren 2004 Hva gir status i fremtiden? Gir ikke status: Sjef for maskinen Eneste med ``Passordet’’ Systemadmin Ha monopol Kunne sanksjonere Makt Gir status: Å kunne noe Å hjelpe/karma Ha gjort noe som andre benytter Ha forståelse Kunne muliggjøre Innflytelse Systemadministrasjon er deregulert. Dette har med den gamle og den nye definisjonen av autoritet. Gammel definisjon, er den som er ledende i kraft av sin kunnskap og sine handlinger – det som i dag kalles naturlig autoritet. Den nye definisjonen er den som er ledende i kraft av sin utnevnelse eller uniform. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

4. Skalerbarhet Nå-situasjon: Antallet maskiner øker, likeså deres kompleksitet, bruksområde og sammenkobling Problem: Det er forbydende dyrt å skalere IT-drift lineært. Utfordring: Generalisere driften så mange, varierte maskiner kan drives billig. Våren 2004 TDT4285 Planl&drift IT-syst

Kostnader ved to driftsformer
innsats Storskaladrift Driftsform: en-og-en Ant maskiner Våren 2004 TDT4285 Planl&drift IT-syst

Tendens ved adm overhead
Arbeids- innsats Restinnsats Innsats Adm overhead Ant personer Våren 2004 TDT4285 Planl&drift IT-syst

Uniformering av kundes behov
TDT4285 Planl&drift IT-syst Våren 2004 Uniformering av kundes behov Ønsket kvalitet Levert kvalitet Også viktig å ta med spesialbehov som ulike brukere har. Det er i samme problemstilling, for differensiert kvalitetsbehov er bare en av mange dimensjoner av behov. Enkeltkunder Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 5. Endringshåndtering Nå-situasjon: Endringer som skaper ’like mange’ problemer som de løser. Problem: Kaotiske endringer er opphav til problemer. Utfordring: Håndtere endringer på en planlagt, etterprøvbar, dokumentert og reversibel måte. Verdens første driftsperson var greker og uttalte ’penta rei’. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Analysere Prioriteringsplan Loggdata Monitorere Konstruere 3.linje 1-2.linje Igangsette Installerbart system Drivbart system Våren 2004 TDT4285 Planl&drift IT-syst

Viktig ifm endringer Må være: Reversible Planlagte Peer-reviewed Repeterbare Kommuniserte Under kontroll Arbeids-/rolledelt Dokumentert Må ikke være: Forvekslet med reparasjoner Inkrementelle på et ’live’ system Et forsøk på å løpe etter realitetene Våren 2004 TDT4285 Planl&drift IT-syst

6. Kompetanseoppdatering
TDT4285 Planl&drift IT-syst Våren 2004 6. Kompetanseoppdatering Nå-situasjon: Utviklingen går fortere, og sysans får mindre tid. Problem: Det blir ’umulig’ å holde følge, bredde og dybde samtidig. Utfordring:Klare å følge med – i riktig dybde og bredde. Endringer Hvis vi antar at oppmerksomheten vår har et endelig volum, så må vi redusere på en av dimensjonene for å styre en av de andre. Tenk deg å samle på frimerker. Du kan samle på norske førkrigs- posthornmerker – ikke mye som skjer der, og du kan virkelig gå i dybden! Eller du kan samle på seilskipsfrimerker fra hele verden, stadig nye merker, men fokus er på et snevert område. Dybde Bredde Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Kompetanseforvaltning
TDT4285 Planl&drift IT-syst Våren 2004 Kompetanseforvaltning Delta på konferanser/seminarer Gå på messer Lese tidsskrifter, bøker og artikler Delta i diskusjonsfora Følge med produktlinjer Eksperimentere Egen observasjon: Hver gang jeg setter meg skikkelig inn i noe, får jeg relativt fort bruk for det. Kanskje fordi jeg har fått en ny hammer og ser nye spiker, men kanskje også fordi jeg mentalt ignorerer ting jeg ikke forstår. Også viktig med ’inkompetanseforvaltning’. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

’Brannslukkeren’ Mangler tid Kompetanse- oppbygging Får ikke lært nye ting Lang- siktig Brannslukking Inneffektiv drift Prokrastrinatoren Kort- siktig Spill av tid Uvesentlig Viktig Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 7. Organisering Nå-situasjon: Alle IT-organisasjoner ser ut til å lete etter den perfekte organiseringen. Problem: Stadige omorganiseringer kan gi manglende stabilitet Utfordring: Klare å isolere de tekniske aspektene ved drift fra organiseringen. Det er også et aspekt ved skalering av organisasjonen at man klarer å anonymisere systemet, slik at det ikke er avhengig enkeltpersoner. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Sentralt eller desentralt?
TDT4285 Planl&drift IT-syst Våren 2004 Sentralt eller desentralt? NB: bare skisse over tendensene! Terminal- tjenere og -klienter Sentralt Regnesentrene med mange og store annlegg 2000 Desentralt 1990 PC-er i nettverk 1980 PC-ene kommer IT-drifts sin versjon av spørsmålet ’To be or not to be’. De aller første driftsorg. 1970 Brukermiljøene får egne minimaskiner 1960 Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

Våren 2004 Hva skjer fremover? Strategisk viktighet Fallende priser Hjemme- nettverk Styring Alt kommer på nettverk Bærbare År 2004 Kostnads- fokusering Desentralisering Sentralisering Mobiltelefoner Åpne standarder Med eksklusiv infrastruktur menes infrastruktur som ikke det er mulig (eller overkommelig rimelig) å duplisere; enten fordi det er et begrenset navnerom, eller fordi det bare er plass (eller penger) til en. Sikkerhet PDA-er Vektlegging av stabilitet ’Personal network’ Eksklusiv infrastruktur Trådløst nettverk Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

8 Effektivisering og målfokus
Nå-situasjon: SA gjør mye som det allerede finnes ferdige løsninger for. Problem: Slik fokus er ikke optimal bruk av ressurser. Det blir mindre ressurser i fremtiden. Utfordring: Slippe oppgaver som kan elimineres, out-sources eller automatiseres. Våren 2004 TDT4285 Planl&drift IT-syst

Sysadmin skvises fra to sider
Automagisk oppatching Lokaladmin på bærbar Brukerne gjør mer og mer på egne enheter Produsenten kan styre mer og mer over nett fra egen site Sysadministrators tradisjonelle arbeidsområde Storskala oppgaver Småskala oppgaver Våren 2004 TDT4285 Planl&drift IT-syst

9. Eget fagfelt Nå-situasjon: Mange personer med ’utradisjonelle’ bakgrunner Problem: SA er en ad hoc aktivitet som man tilfeldigvis havner i mens man venter på en ’skikkelig’ jobb. Utfordring: SA må være et yrke, noe man utdanner seg til, en karrierevei. Ikke bare en aktivitet. Våren 2004 TDT4285 Planl&drift IT-syst

Kjennetegn på et fagfelt
Etablert body of knowlegde Etablert terminologi Konferanser Tidsskrifter Undervisning Sertifisering Bransjeorganisasjoner Felles forståelse av etikk Våren 2004 TDT4285 Planl&drift IT-syst

Våren 2004 Konklusjon Systemadministrasjon står foran store endringer. De største utfordringene er de ikke-teknologiske. Dette er ikke utfordringer som kan møtes med den rådende metode for problemløsing: ad hoc brannslukking. Våren 2004 TDT4285 Planl&drift IT-syst Anders Christensen, IDI

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:

Liknende presentasjoner

Om prosjektet

Tilbakemelding

Logg inn

Logg deg på via sosiale nettverk:

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:

Liknende presentasjoner

Om prosjektet

Tilbakemelding