Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Våren 2004TDT4285 Planl&drift IT-syst1 Introduksjon TDT4285 Planlegging og drift av IT-systemer Våren 2004.

Liknende presentasjoner


Presentasjon om: "Våren 2004TDT4285 Planl&drift IT-syst1 Introduksjon TDT4285 Planlegging og drift av IT-systemer Våren 2004."— Utskrift av presentasjonen:

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

2 TDT4285 Planl&drift IT-syst 2 Faglærer og und.ass. Faglærer: Anders Christensen Telefon: (evt: ) E-post: Kontor: IT-Syd rom 234 Und.ass: Morten Werner Olsen

3 Våren 2004 TDT4285 Planl&drift IT-syst 3 Timeplan MandagTirsdagOnsdagTorsdagFredag Forel: F Forel: F Øving: F Forel: H1Øving: F

4 Våren 2004 TDT4285 Planl&drift IT-syst 4 Vekttall og timefordeling 3 timer 4 timer 2 timer

5 Våren 2004 TDT4285 Planl&drift IT-syst 5 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.

6 Våren 2004 TDT4285 Planl&drift IT-syst 6 Fjernstudenter 1. Fraråder å skulke forelesningene 2. Men: tilrettelegger for de som ikke være i Trondheim i semesteret. 3. Viktig: utenbys studenter må gi beskjed så fort som mulig

7 Våren 2004 TDT4285 Planl&drift IT-syst 7 Forelesningsplan 1. Introduserende (3) 2. Grunnleggende kunnskap (8) 3. Konsepter (9) 4. Konkrete områder (18) 5. Utsyn fremover (4)

8 Våren 2004 TDT4285 Planl&drift IT-syst 8 Pensumlitteratur Limoncelli & Hogan: Practice of System and Network Administration Diverse utfyllende papers Foiler fra forelesningene Obligatorisk øving

9 Våren 2004 TDT4285 Planl&drift IT-syst 9 Utfyllende litteratur Burgess: Principles of System and Network Administration. Nemeth & al: Unix System Administration Handbook. Mikalsen & al: Drift av lokalnettverk.

10 Våren 2004 TDT4285 Planl&drift IT-syst 10 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...

11 Våren 2004 TDT4285 Planl&drift IT-syst 11 Kommunikasjonsmidler (Forelesninger og øvingstimer) Ukentlig trefftid? Epostliste Pr epost Newsgruppe (ntnu.ime.idi.tdt4285) It’s learning?

12 Våren 2004 TDT4285 Planl&drift IT-syst 12 Rammer for faget O/S-agnostisk Langvarig, holdbar kunnskap Bygger på andre fag ved IDI Se på prinsippene i faget Ikke datasalsøvinger

13 Våren 2004 TDT4285 Planl&drift IT-syst 13 Plassering av TDT4285 ved IDI TDT4285 Programmering Datamod og database Datamask. og opsys Prosjekt Diplom Ytelsesvurdering

14 Våren 2004 TDT4285 Planl&drift IT-syst 14 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

15 Våren 2004 TDT4285 Planl&drift IT-syst 15 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

16 Våren 2004 TDT4285 Planl&drift IT-syst 16 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

17 Våren 2004 TDT4285 Planl&drift IT-syst 17 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

18 Våren 2004 TDT4285 Planl&drift IT-syst 18 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...

19 Våren 2004TDT4285 Planl&drift IT-syst19 Utfordringene TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

20 Våren 2004 TDT4285 Planl&drift IT-syst 20 Historikk Minimaskiner IBM-PC ”Internettet” Mainframes Hjemmemaskinen Bærbare Regnesentre EDB-avd IT-avd Servicecenter Tynne klienter

21 Våren 2004 TDT4285 Planl&drift IT-syst 21 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

22 Våren 2004 TDT4285 Planl&drift IT-syst 22 Hva er IT-drift? Profesjonell drift av storskala dataanlegg Mange maskiner Mange brukere Heltids- beskjeftigelse Indirekte oppgave Stabs- funksjon Stor kompleksitet Ressurs- utnytting For andre enn deg selv Datamaskiner Nettverk Programvare Brukere Funksjonalitet Stabilitet Kost- nader Bruker- behov Parallelle systemer Vedlikehold Infra- struktur

23 Våren 2004 TDT4285 Planl&drift IT-syst 23 Systemadministrators roller? Installatøren Reparatøren Vedlikeholderen Problem- forebyggeren Helten Infrastruktur- byggeren Policy- skriveren Rutine- utføreren Laboratorie- teknikeren Produkt- finneren Innkjøperen Løsnings- designeren Improvisatøren Nisje- område- eksperten Utdanneren Etterforskeren Avstrafferen Planleggeren Dommedags- profeten Prosjekt- lederen Budsjett- administratoren Bruker- forkjemperen Teknokraten Selgeren Leverandør- kontakten Den visjonære Overvåkeren Hønemor Tilretteleggeren Hjelperen Feil- søkeren Kvalitets- sikreren Sikkerhets- eksperten Vaktmesteren Nattevakta Skurken Prosjekt- arbeideren Psykologen Lytteren Team-med- arbeideren Lederen Brann- mannen Fikseren Syndebukken

24 Våren 2004 TDT4285 Planl&drift IT-syst 24 Terminologi Sysadmin (systemadministrator) person som er (del-)ansvarlig for drift av et datasystem. Drifte – noe man gjør med kyr.

25 Våren 2004 TDT4285 Planl&drift IT-syst 25 Tre store problemstillinger 1. Endringshåndtering 2. Skalerbarhet 3. (Person)kommunikasjon

26 Våren 2004 TDT4285 Planl&drift IT-syst 26 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

27 Våren 2004 TDT4285 Planl&drift IT-syst 27 Problemstilling 2 Skalerbarhet Kapasitetsplanlegging Testing opp mot antatt full last ”Organisatorisk” skalerbarhet Monitorering Kan ta ut stordriftfordeler

28 Våren 2004 TDT4285 Planl&drift IT-syst 28 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

29 Våren 2004 TDT4285 Planl&drift IT-syst 29 Ti utfordringer Måldefinisjon Feilsøking og – retting Endringer Sikkerhet Divergens Kompleksitet Kommunikasjon Katastrofeplanlegging Bevare eller forbedre? Læring

30 Våren 2004 TDT4285 Planl&drift IT-syst 30 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?

31 Våren 2004 TDT4285 Planl&drift IT-syst 31 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?

32 Våren 2004 TDT4285 Planl&drift IT-syst 32 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?

33 Våren 2004 TDT4285 Planl&drift IT-syst 33 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?

34 Våren 2004 TDT4285 Planl&drift IT-syst 34 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?

35 Våren 2004 TDT4285 Planl&drift IT-syst 35 Utfordring 6 Kompleksitet Har man oversikt over systemets kompleksitet; og er kompleksiteten større enn hva brukernes behov tilsier?

36 Våren 2004 TDT4285 Planl&drift IT-syst 36 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?

37 Våren 2004 TDT4285 Planl&drift IT-syst 37 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?

38 Våren 2004 TDT4285 Planl&drift IT-syst 38 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)?

39 Våren 2004 TDT4285 Planl&drift IT-syst 39 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?

40 Våren 2004TDT4285 Planl&drift IT-syst40 Løsningsskisser TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

41 Våren 2004 TDT4285 Planl&drift IT-syst 41 Faser i en driftsorgs liv... Supermann Radarpar Trekløver Områdebasert arbeidsdeling Rollebasert arbeiddeling 1.linje 2.linje 3.linje Datasenter HeltemodellenTeammodellen Oppdeling av ansvars- område ITIL

42 Våren 2004 TDT4285 Planl&drift IT-syst 42 Helter, team og skalerbarhet 1. Heltemodell skalerer bra i små miljøer 2. Heltemodellen kollapser i store miljøer 3. Teammodellen skalerer bra i store miljøer 4. Teammodellen fungerer svært dårlig i svært små miljøer 5. Heltemodellen kan ”tynes” ved oppdeling

43 Våren 2004 TDT4285 Planl&drift IT-syst 43 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

44 Våren 2004 TDT4285 Planl&drift IT-syst 44 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åde2 Område4 Område1 Område5 Område3

45 Våren 2004 TDT4285 Planl&drift IT-syst 45 Trenivås rolledeling for drift 1.linje Brukerstøtte FAQ Enkel feilsøk Rutiner Enkel adm 3.linje Konfigurering Systemdesign Dyp feilsøking Sys.analyse Strategiarbeid 2.linje Feilsøking Feilretting Tyngre adm Monitorering

46 Våren 2004 TDT4285 Planl&drift IT-syst 46 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’

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

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

49 Våren 2004 TDT4285 Planl&drift IT-syst 49 2.Linjes oppgaver (drift)...med kartet som referanse: retter terrenget der det er ’galt’, samt utfører oppgaver som ikke er formulert som rutiner Kart’ Endringer innen samme kart Feilsituasjon Feilretting Retting Operasjon Med feil 2.linje

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

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

52 Våren 2004 TDT4285 Planl&drift IT-syst 52 Arbeidsfokus og erstattbarhet Avhengighet/arbeidsfokus På kort siktPå lang sikt Erstatt- barhet På lang sikt På kort sikt 1.linje 2.linje 3.linje

53 Våren 2004 TDT4285 Planl&drift IT-syst 53 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)

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

55 Våren 2004 TDT4285 Planl&drift IT-syst 55 Helter og teammedarbeidere HeltemodellenTeammodellen Fordeler Ulemper Person- avhengig Bruker- nærhet Form- fasthet Avstand, upersonlig Kort om- stillingstid Vagt og ullent Byråkratisk Konsistent Tett kom- munikasjon Utbrenthet Eierfølelse Personal- utskiftning Profesjonell avstand Ugjennom- trengelig Formelle kanaler Tidsfor- sinkelse

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

57 Våren 2004 TDT4285 Planl&drift IT-syst 57 ”Single point of entry” Alle henvendelser fra brukerne skal gå igjennom et ’call-center’. Helpdesk 2.linje 3.linje Operatør Brukere 1.linje

58 Våren 2004 TDT4285 Planl&drift IT-syst 58 Hvorfor ’SPOE’ Motvirke dobbeltrapportering Koordinere innsats Gi bedre oversikt og utestående oppg Skjerme mot avbrytelser Lette prioritering Sikre tilbakemelding til bruker

59 Våren 2004 TDT4285 Planl&drift IT-syst 59 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.

60 Våren 2004 TDT4285 Planl&drift IT-syst 60 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)

61 Våren 2004 TDT4285 Planl&drift IT-syst 61 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.

62 Våren 2004TDT4285 Planl&drift IT-syst62 Klienter TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

63 Våren 2004 TDT4285 Planl&drift IT-syst 63 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

64 Våren 2004 TDT4285 Planl&drift IT-syst 64 Evards livssyklus New CleanConfig’d Unknown Off Rebuild Update Entropy Debug Retire Build Initialize

65 Våren 2004 TDT4285 Planl&drift IT-syst 65 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

66 Våren 2004 TDT4285 Planl&drift IT-syst 66 Forfatterens hovedbudskap Tre viktige ting med klienter: 1. Automatisere installasjon 2. Håndtere oppdateringer 3. Konfigurere nettverksparametre

67 Våren 2004 TDT4285 Planl&drift IT-syst 67 Automatisere? Effektivitetsgrunner 1. Tillater at man kan utføre raske endringer 2. Utrulling må ikke være hinder for nødvendige oppdateringer 3. Erstatter feilsøking på en kostnadseffektiv måte. 4. Tillater å parallellisere mange maskiner 5. Kan bruke arb.kraft med mindre erfaring

68 Våren 2004 TDT4285 Planl&drift IT-syst 68 Automatisere? Konsistensen 1. Brukerne kjenner seg igjen fra maskin til maskin. 2. Fjerne slurvefeil (især sent om natta) 3. Kan være trygge på at alt er konsistent 4. Minsker holdningen om reinstaller-for-å- fjerne-feilen.

69 Våren 2004 TDT4285 Planl&drift IT-syst 69 Automatisering? Kvalitetsgrunnene 1. Prosessen er iboende ”dokumentert” 2. Automatiserte prosesser er repeterbare 3. Setter en baseline for hvordan ting gjøres 4. Muliggjør review av fremgangsmåte fra andre parter

70 Våren 2004 TDT4285 Planl&drift IT-syst 70 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!

71 Våren 2004 TDT4285 Planl&drift IT-syst 71 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

72 Våren 2004 TDT4285 Planl&drift IT-syst 72 The four holy Rs of brute force Retry Reboot Reinstall Restart

73 Våren 2004 TDT4285 Planl&drift IT-syst 73 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

74 Våren 2004 TDT4285 Planl&drift IT-syst 74 Hvordan utføre etterkontroll? 1. Nullalternativ: ignorer 2. Monitorere bruken av maskinen en periode 3. Stikke innom og sjekke den manuelt 4. La installasjonen utføre en egen ettertest og melde ifra om resultatet 5. Be om tilbakemelding fra første bruker

75 Våren 2004 TDT4285 Planl&drift IT-syst 75 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.

76 Våren 2004 TDT4285 Planl&drift IT-syst 76 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

77 Våren 2004 TDT4285 Planl&drift IT-syst 77 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

78 Våren 2004 TDT4285 Planl&drift IT-syst 78 Konfigurerbarhet og automatikk Automatikk Gjenbruk- barhet StorLiten Kostbart Billig Helmanuell installering Automatisk installering Kloning Avspilling av tasttrykk

79 Våren 2004 TDT4285 Planl&drift IT-syst 79 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

80 Våren 2004 TDT4285 Planl&drift IT-syst 80 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

81 Våren 2004 TDT4285 Planl&drift IT-syst 81 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

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

83 Våren 2004 TDT4285 Planl&drift IT-syst 83 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

84 Våren 2004 TDT4285 Planl&drift IT-syst 84 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 Korriger og gå tilbake til pkt 1 hvis nye feil Repeter forrige to punkt til alle er dekket

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

86 Våren 2004 TDT4285 Planl&drift IT-syst 86 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.

87 Våren 2004 TDT4285 Planl&drift IT-syst 87 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

88 Våren 2004 TDT4285 Planl&drift IT-syst 88 Valg av maskinvare 1. ”Standard” hyllevare Billig! 2. Spesiell tjener-maskinvare Pålitelig og med høy kvalitet Redundante løsninger Overvåkningsmuligheter Feilkorrigering

89 Våren 2004 TDT4285 Planl&drift IT-syst 89 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

90 Våren 2004 TDT4285 Planl&drift IT-syst 90 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?

91 Våren 2004 TDT4285 Planl&drift IT-syst 91 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

92 Våren 2004 TDT4285 Planl&drift IT-syst 92 Reaktiv og proaktiv vedlikehold Reaktivt Servicekontakt Reservedeler Garantiordninger Etterbestille deler Reservemaskin Backup/restore Proaktivt Overkapasitet Planlagt utfasing Automatisk failover Monitorering Redundans Diskspeiling

93 Våren 2004 TDT4285 Planl&drift IT-syst 93 Sikkerhetmodell tj2 tj1 tj3 tj4 Viktige maskiner Kontormaskiner Hjemmemaskiner Eksterne maskiner

94 Våren 2004 TDT4285 Planl&drift IT-syst 94 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

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

96 Våren 2004 TDT4285 Planl&drift IT-syst 96 Spesialtjenere (server appliances) Fordeler: Spesialkonfigurasjon Fintunet til bestemt oppgave Frigjør tid (fra å konfigurere egne spesialmaskiner) Lite ekstra funksjonalitet/kompleksitet Ulemper: Øker antall platformer

97 Våren 2004 TDT4285 Planl&drift IT-syst 97 Redundans Følgende dimensjoner finnes: 1. Kapasitet: ibruk/ekstra – speilende – av 2. Aktivisering: manuell – automatisk 3. Bytting: hotswap – reset – slå-av 4. Toleranse: enkeltfeil – dobbeltfeil – etc

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

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

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

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

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

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

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

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

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

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

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

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

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

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

112 Våren 2004 TDT4285 Planl&drift IT-syst 112 Ytelsesplanlegging Estimer ressursbruk (initielt og full bruk) Test for å kunne estimere skalering Skaff nok ressurser Skaff nok kompetanse Gjør det skikkelig fra starten!

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

114 Våren 2004 TDT4285 Planl&drift IT-syst 114 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!

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

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

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

118 Våren 2004TDT4285 Planl&drift IT-syst118 Statisk dokumentasjon TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

119 Våren 2004 TDT4285 Planl&drift IT-syst 119 Hva er dokumentasjon? 1. Forklaring av systemet? 2. Blueprint for systemet? 3. Infrastruktur for komm. mellom sysadmins? 4. Byråkratisk herk og evig stilskriving? System Dok Implementerer Forklarer

120 Våren 2004 TDT4285 Planl&drift IT-syst 120 Målsetting Formidle kunnskap mellom sysadmins (kommunikasjon) Sette et utgangspunkt for systemet (endringshåndtering) Felles referansepunkt for samarbeid (skalering)

121 Våren 2004 TDT4285 Planl&drift IT-syst 121 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å.

122 Våren 2004 TDT4285 Planl&drift IT-syst 122 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)

123 Våren 2004 TDT4285 Planl&drift IT-syst 123 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å

124 Våren 2004 TDT4285 Planl&drift IT-syst 124 Hva kjennertegner god dok? Forventninger til format Forventninger til plassering Forventninger til fokus Forventninger til innhold Forventninger til tilgjengelighet Forventninger til oppdaterthet

125 Våren 2004 TDT4285 Planl&drift IT-syst 125 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.

126 Våren 2004 TDT4285 Planl&drift IT-syst 126 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

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

128 Våren 2004 TDT4285 Planl&drift IT-syst 128 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

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

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

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

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

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

134 Våren 2004 TDT4285 Planl&drift IT-syst 134 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

135 Våren 2004 TDT4285 Planl&drift IT-syst 135 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

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

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

138 Våren 2004 TDT4285 Planl&drift IT-syst 138 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

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

140 Våren 2004 TDT4285 Planl&drift IT-syst 140 Dok er nødvendig for å: Anonymisere arbeidsoppgaver Muliggjøre peer review Spesifisere en normaltilstand Identifisere forbedringsområder Angir basis for endringer.

141 Våren 2004TDT4285 Planl&drift IT-syst141 Dynamisk dokumentasjon TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

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

143 Våren 2004 TDT4285 Planl&drift IT-syst 143 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

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

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

146 Våren 2004 TDT4285 Planl&drift IT-syst 146 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

147 Våren 2004 TDT4285 Planl&drift IT-syst 147 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

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

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

150 Våren 2004 TDT4285 Planl&drift IT-syst 150 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.

151 Våren 2004 TDT4285 Planl&drift IT-syst 151 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

152 Våren 2004 TDT4285 Planl&drift IT-syst 152 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.

153 Våren 2004 TDT4285 Planl&drift IT-syst 153 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...

154 Våren 2004 TDT4285 Planl&drift IT-syst 154 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.

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

156 Våren 2004TDT4285 Planl&drift IT-syst156 Tjeneroppgraderinger TDT4285 Planlegging og drift av IT-systemer Anders Christensen, IDI

157 Våren 2004 TDT4285 Planl&drift IT-syst 157 Tjeneroppgradering 1. Lag en tjeneste-sjekkliste 2. Verifiser kompatibilitet 3. Lag verifiseringsverktøy 4. Lag en backout-plan 5. Velg et vedlikeholdsvindu 6. Informer brukerne 7. Gjennomfør testene 8. Gjennomfør oppgraderingen 9. Gjennomfør ettertesting 10. Ved feil, gjennomfør backout-planen 11. Informer brukerne

158 Våren 2004 TDT4285 Planl&drift IT-syst 158 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?

159 Våren 2004 TDT4285 Planl&drift IT-syst 159 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

160 Våren 2004 TDT4285 Planl&drift IT-syst 160 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.

161 Våren 2004 TDT4285 Planl&drift IT-syst 161 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.

162 Våren 2004 TDT4285 Planl&drift IT-syst 162 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?

163 Våren 2004 TDT4285 Planl&drift IT-syst 163 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

164 Våren 2004 TDT4285 Planl&drift IT-syst 164 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.

165 Våren 2004 TDT4285 Planl&drift IT-syst 165 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.

166 Våren 2004 TDT4285 Planl&drift IT-syst 166 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.

167 Våren 2004 TDT4285 Planl&drift IT-syst 167 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.

168 Våren 2004 TDT4285 Planl&drift IT-syst 168 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.

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

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

171 Våren 2004 TDT4285 Planl&drift IT-syst 171 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.

172 Våren 2004 TDT4285 Planl&drift IT-syst 172 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.

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

174 Våren 2004 TDT4285 Planl&drift IT-syst 174 Definisjon Et vedlikeholdsvindu er et forhåndsdefinert, varslet tidsrom der dataanlegget kan tas ned for å gjennomføre vedlikehold og oppgraderinger, typisk flere i parallell.

175 Våren 2004 TDT4285 Planl&drift IT-syst 175 Vedlikeholdsvinduer PlanleggingOppgradering Planlegging Oppgrad1 Oppgrad2Oppgrad4 Oppgrad3 Nedtaking Oppgrad5 Oppgrad6 Oppstart Vedlikeholdsvindu 1)Forrige forelesning 2.Denne forelesningen

176 Våren 2004 TDT4285 Planl&drift IT-syst 176 Gangen i et vedl.vindu ForberedelseGjenstartGjennomføring 1.Endringsforslag 2.Schedulere vinduer 3.Velge én flight director 4.Bygge en masterplan 1.Fjerne tilgang 2.Ta systemet kontrollert ned 3.Gjennomføre oppgradere 4.Utføre testing 1.Ta systemet opp 2.Åpne tilgang 3.Annonsere tilgjengelighet 4.Være tilstede for brukerne 5.Være obs på evt problemer

177 Våren 2004 TDT4285 Planl&drift IT-syst 177 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

178 Våren 2004 TDT4285 Planl&drift IT-syst 178 Oppetid og nytteområde 90%99%0% ,9% 99,99% 99,999% Vedlikeholds- vinduer Kan tas ned ad hoc Kan ikke tas ned Sporadisk oppetid

179 Våren 2004 TDT4285 Planl&drift IT-syst 179 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

180 Våren 2004 TDT4285 Planl&drift IT-syst 180 Regelmessighet av vedl.vinduer PositivtNegativt Etter behovFleksibelt Lite koordinering Serialisering På faste tidspunkter Brukeren kan tilpasse sitt arbeide Bedre planlegging Miste status hvis den ikke brukes

181 Våren 2004 TDT4285 Planl&drift IT-syst 181 Regelmessighet – eksempler 1. Første mandag pr mnd fra til klokken neste morgen 2. Fra fredag 1800 til mandag 0800, én gang i hver av juni, juli, august, desember og januar.

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

183 Våren 2004 TDT4285 Planl&drift IT-syst 183 Endringsforslag 1. Hvilke endringer skal gjøres? 2. Hvilke maskiner er involvert i arbeidet? 3. Hva må gjøres i forkant før man kan utføre endringen? 4. Avhengighet av andre systemer/maskiner? 5. Hva blir berørt? 6. Hvem utfører/har ansvar for endringen? 7. Hvor lang tid tar det (klokketid og arb.tid)? 8. Hva er testproc. og hva trengs av utstyr? 9. Hva er back-out, og hvor lang tid tar det?

184 Våren 2004 TDT4285 Planl&drift IT-syst 184 Saksgang ved endringsforslag Endrings- utkast Peer- review Frysing Gjennom- føring Flight- director I tilfelle endringer Siste uka

185 Våren 2004 TDT4285 Planl&drift IT-syst 185 Masterplanen Masterplanen settes opp at flight director: Gir en schedule av aktivitetene Tar hensyn til avhengigheter Realistisk mht tidsrammene/ressurser

186 Våren 2004 TDT4285 Planl&drift IT-syst 186 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å

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

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

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

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

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

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

193 Våren 2004 TDT4285 Planl&drift IT-syst 193 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

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

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

196 Våren 2004 TDT4285 Planl&drift IT-syst 196 Utrullingsstrategi En Noen Mange Deg selv SA-kolleger Andre Gammel Ny Overlapp Gammel Ny Avbrudd SømløstBrudd Gammel Ny Flash-Cut

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

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

199 Våren 2004 TDT4285 Planl&drift IT-syst 199 Lagdeling og søyler Kunde1Kunde2Kunde3Kunde4 Applikasjon ProtokollLagdelt Tjener DatalagerSøyle Op.sys Lagdeling – dersom sømløs overgang er mulig Søyler – dersom man man får funksjonsbrudd

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

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

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

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

204 Våren 2004 TDT4285 Planl&drift IT-syst 204 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

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

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

207 Våren 2004 TDT4285 Planl&drift IT-syst 207 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.

208 Våren 2004 TDT4285 Planl&drift IT-syst 208 Kostnader og ytelse Kostnader kan være Proporsjonale med bruk Kreve en initialkostnad Ytelse Kostnad

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

210 Våren 2004 TDT4285 Planl&drift IT-syst 210 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

211 Våren 2004 TDT4285 Planl&drift IT-syst 211 Geografisk eller oppgavemessig arbeidsdeling Delorg1 Delorg2 Delorg3 Delorg4 Delorg5 Skrivere Unix Windows Epost Web Nettverk Mac Backup

212 Våren 2004 TDT4285 Planl&drift IT-syst 212 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. Dybde Bredde Endringsrate Versjon1 Versjon2 Versjon3 Drift Brukerstøtte Ekspertinnsikt Utvikling Forskning Skrivere Unix Windows Nettverk

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

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

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

216 Våren 2004 TDT4285 Planl&drift IT-syst 216 Klasser av kvalitetsnivåer Kvalitet Enkeltkunder Kundene grupperes i tre klasser som får ulik grad av kvalitet. ”Ekstrafordel”

217 Våren 2004 TDT4285 Planl&drift IT-syst 217 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.

218 Våren 2004 TDT4285 Planl&drift IT-syst 218 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

219 Våren 2004 TDT4285 Planl&drift IT-syst 219 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

220 Våren 2004 TDT4285 Planl&drift IT-syst 220 Skaleringsmodeller av drift Bruker System- produsent Drift? Brukerne driver sine egne maskiner Liten, lokal driftsorganisasjon Stor drifts- organisasjon som tar ut stordriftsfordeler Drift er inkludert i systemet. Produsenten håndterer Økende skalering Drift flyttes nærmere bruker Ingen drift Lokal drift Stordrift Superskalert drift

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

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

223 Våren 2004 TDT4285 Planl&drift IT-syst 223 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

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

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

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

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

228 Våren 2004 TDT4285 Planl&drift IT-syst 228 Eksempel: RAID5 Disk1Disk2Disk3Disk4Disk5Disk6Disk7 ”Data””Paritet”Ekstra Gjenoppbygging Av harddisk2 NB: forenklet modell!

229 Våren 2004 TDT4285 Planl&drift IT-syst 229 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

230 Våren 2004 TDT4285 Planl&drift IT-syst 230 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”

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

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

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

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

235 Våren 2004 TDT4285 Planl&drift IT-syst 235 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)

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

237 Våren 2004 TDT4285 Planl&drift IT-syst 237 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.

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

239 Våren 2004 TDT4285 Planl&drift IT-syst 239 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.

240 Våren 2004 TDT4285 Planl&drift IT-syst 240 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.

241 Våren 2004 TDT4285 Planl&drift IT-syst 241 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?

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

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

244 Våren 2004 TDT4285 Planl&drift IT-syst 244 Tommelfingerregler 1. Flate navnerom skalerer dårlig, og krever en sentral navneautoritet. 2. Dynamiske navnerom er praktisk, men kan ha implikasjoner for sikkerhet og overhead. 3. Hierarkiske navnerom som skal skaleres tilstrekkelig opp, krever en distribuert database. 4. Planlegg godt, for navn lever veldig lenge!

245 Våren 2004 TDT4285 Planl&drift IT-syst 245 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

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

247 Våren 2004 TDT4285 Planl&drift IT-syst 247 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

248 Våren 2004 TDT4285 Planl&drift IT-syst 248 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.

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

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

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

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

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

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

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

256 Våren 2004 TDT4285 Planl&drift IT-syst 256 Lite og lokalt, eller stort og sentralt?

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

258 Våren 2004 TDT4285 Planl&drift IT-syst 258 Sentraliseringskandidater Infrastruktur: tjenester som brukes som en standardtjeneste og som er ’transparente’ Kompetanse: ved sentralisering kan man ta ut desto større stordriftsfordeler.

259 Våren 2004 TDT4285 Planl&drift IT-syst 259 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.

260 Våren 2004 TDT4285 Planl&drift IT-syst 260 IVT-modellen for sentralisering Gruppe Institutt Fakultet NTNU Oppgaver som er felles for flere avd sentraliseres Printere Mail Backup Oppgaver som er spesifikke for enkeltavdelinger desentraliseres Brukerstøtte Spesialprogrammer

261 Våren 2004 TDT4285 Planl&drift IT-syst 261 Problemstilling Lokal brukerstøtte BrukerDatamaskiner Sentral driftsorg Benytter Tett kommunikasjon Ansvars- deling

262 Våren 2004 TDT4285 Planl&drift IT-syst 262 Outsourcing Du må: 1. Vite hva du har og hva du trenger, 2. Kunne uttrykke hva du skal be om, 3. Bruke tilstrekkelig tid på forhandlingene. Outsourcing-partneren din har ofte en fordel på alle disse tre områdene!

263 Våren 2004 TDT4285 Planl&drift IT-syst 263 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

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

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

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

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

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

269 Våren 2004 TDT4285 Planl&drift IT-syst 269 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

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

271 Våren 2004 TDT4285 Planl&drift IT-syst 271 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

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

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

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

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

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

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

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

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

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

281 Våren 2004 TDT4285 Planl&drift IT-syst 281 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.

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

283 Våren 2004 TDT4285 Planl&drift IT-syst 283 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.

284 Våren 2004 TDT4285 Planl&drift IT-syst 284 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

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

286 Våren 2004 TDT4285 Planl&drift IT-syst 286 Dimensjon 1: Metoder Scripting Kobler flere enkelthandlinger. Proceduralt ”Programmeringsspråk” Utfører et program Tilstandsbasert Regelbasert Komplekst Sammenlikner tilstander Tilpasningsdyktig

287 Våren 2004 TDT4285 Planl&drift IT-syst 287 Dimensjon 2: Holdning Defensivt Kvalitet i fokus Kontrollerer avvik Sjekker assumptions Sjekker resultatene Avbryter hvis uklart Spesialbehandling av farlige operasjoner Aggressivt Oppgavemål i fokus Få/ingen sjekker Vanligvis midlertidig Ignorerer spesialtilfeller Forventes brukt manuelt Ignorerer feilkoder

288 Våren 2004 TDT4285 Planl&drift IT-syst 288 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

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

290 Våren 2004 TDT4285 Planl&drift IT-syst 290 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?

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

292 Våren 2004 TDT4285 Planl&drift IT-syst 292 Automatiseringsoperasjon 1. Utvalg av oppgaver 2. Implementering 3. Igangsetting 4. Monitorering 5. Kontinuerlig forbedring

293 Våren 2004 TDT4285 Planl&drift IT-syst 293 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å

294 Våren 2004 TDT4285 Planl&drift IT-syst 294 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

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

296 Våren 2004 TDT4285 Planl&drift IT-syst 296 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)

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

298 Våren 2004 TDT4285 Planl&drift IT-syst 298 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.

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

300 Våren 2004 TDT4285 Planl&drift IT-syst 300 Definisjon Logging er å lagre korte, informative data kronologisk på et standardisert format om hendelser (eller tilstander) på en datamaskin.

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

302 Våren 2004 TDT4285 Planl&drift IT-syst 302 Logging, monitorering og statistikk Hendelser Logg Monitorering Varsling Statistikk Aggregeres til Trigger Genererer Tolkes/filteres Nåtilstand Vedlike- holder Real-time Batch Analyse Bruk

303 Våren 2004 TDT4285 Planl&drift IT-syst 303 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.

304 Våren 2004 TDT4285 Planl&drift IT-syst 304 Bruksverdi av logging Bruksdata Hendelser Tilstand Visualisere Gjenskape Varsling Automatisk reparasjon Fakturering Statistikk Trender Feilsøking Dokumentere SLA-mål Overvåke Sikkerhet

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

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

307 Våren 2004 TDT4285 Planl&drift IT-syst 307 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 Logg Indikasjoner Filter Prediksjon

308 Våren 2004 TDT4285 Planl&drift IT-syst 308 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.

309 Våren 2004 TDT4285 Planl&drift IT-syst 309 ”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 Mange programmer Endrings- rate Volum Variasjon + +

310 Våren 2004 TDT4285 Planl&drift IT-syst 310 Filtrering Filtrering av loggdata kan: Finne bestemte data Sammefatte Fjerne det irrelevante og lage en ”rest”-liste Krever: Programmering! Logg Filter Rest Sammen drag Treff

311 Våren 2004 TDT4285 Planl&drift IT-syst 311 Ønskeliste for filtrering 1. Se subsystemer i sammenheng 2. Ignorere følgefeil av initiell feil 3. Detektere mønstre utfra historikk 4. Forutsi videre utvikling 5. Være selvkonfigurerende 6. Ikke trenge manuell oppdatering 7. Prioritere meldinger

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

313 Våren 2004 TDT4285 Planl&drift IT-syst 313 Elementer ifm logging Personvern Plassbruk Kondensering Rotasjon Backup anonymisering gjenbruk fjernlager mindre antall kopier Sirkulære logger

314 Våren 2004 TDT4285 Planl&drift IT-syst 314 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

315 Våren 2004 TDT4285 Planl&drift IT-syst 315 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

316 Våren 2004 TDT4285 Planl&drift IT-syst 316 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.

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

318 Våren 2004 TDT4285 Planl&drift IT-syst 318 Helpdesks rolle Helpdesk IT-drifts- stab Kunder Single point of entry Fysisk Telefon Web Chat Prosjekt- arbeid Avbrudds- styrt

319 Våren 2004 TDT4285 Planl&drift IT-syst 319 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

320 Våren 2004 TDT4285 Planl&drift IT-syst 320 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

321 Våren 2004 TDT4285 Planl&drift IT-syst 321 Egnede personligheter (?) ``If we stopped caring about the customers, maybe they would stop bothering us?’’ Demotivational poster

322 Våren 2004 TDT4285 Planl&drift IT-syst 322 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”

323 Våren 2004 TDT4285 Planl&drift IT-syst 323 Hva er tilstrekkelig bemanning Forholdet mellom helpdeskstillinger og brukere avhenger av situasjonen: Ansatte ved forskning/univ: Studenter: ISP: Merk: tallene er eksempler!

324 Våren 2004 TDT4285 Planl&drift IT-syst 324 Annonsering og informering ”Ingen” leser dokumentasjon Dok’en må spesialdesignes Plassering Timing Repetering Variasjon Fokusering Korthet Forståelighet Relevans & nytteverdi

325 Våren 2004 TDT4285 Planl&drift IT-syst 325 Metrikker for helpdesk Antall kunder pr helpdesk-stilling Henvendelsesvolum og endringer Oppfyllelse av SLA Persondifferensiert opplæringsbehov Hvor mange prosent av jobbene eskalerer?

326 Våren 2004 TDT4285 Planl&drift IT-syst 326 Måltall for tidsbruk Problem Symtom Feilmelding Første tilbakemelding Analyse Fiksing Endelig tilbakemelding Lukking 1 minutt 10 minutter 1 time NB: måltall er bare gitt som eksempler

327 Våren 2004 TDT4285 Planl&drift IT-syst 327 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

328 Våren 2004 TDT4285 Planl&drift IT-syst 328 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)

329 Våren 2004 TDT4285 Planl&drift IT-syst 329 Tilstandsdiagram for saker Ny Åpen Mer info Slettet Lukket Avvente I arbeid Analysert NB: store variasjoner mellom verktøyene

330 Våren 2004 TDT4285 Planl&drift IT-syst 330 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?

331 Våren 2004 TDT4285 Planl&drift IT-syst 331 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?

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

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

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

335 Våren 2004 TDT4285 Planl&drift IT-syst 335 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”.

336 Våren 2004 TDT4285 Planl&drift IT-syst 336 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.

337 Våren 2004 TDT4285 Planl&drift IT-syst 337 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

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

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

340 Våren 2004 TDT4285 Planl&drift IT-syst 340 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

341 Våren 2004 TDT4285 Planl&drift IT-syst 341 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

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

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

344 Våren 2004 TDT4285 Planl&drift IT-syst 344 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?

345 Våren 2004 TDT4285 Planl&drift IT-syst 345 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

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

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

348 Våren 2004 TDT4285 Planl&drift IT-syst 348 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

349 Våren 2004 TDT4285 Planl&drift IT-syst 349 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

350 Våren 2004 TDT4285 Planl&drift IT-syst 350 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

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

352 Våren 2004 TDT4285 Planl&drift IT-syst 352 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

353 Våren 2004 TDT4285 Planl&drift IT-syst 353 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

354 Våren 2004 TDT4285 Planl&drift IT-syst 354 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

355 Våren 2004 TDT4285 Planl&drift IT-syst 355 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

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

357 Våren 2004 TDT4285 Planl&drift IT-syst 357 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

358 Våren 2004 TDT4285 Planl&drift IT-syst 358 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

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

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

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

362 Våren 2004 TDT4285 Planl&drift IT-syst 362 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?

363 Våren 2004 TDT4285 Planl&drift IT-syst 363 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.

364 Våren 2004 TDT4285 Planl&drift IT-syst 364 Ikke-reproduserbare feil Monitorer dem over tid. Iverksett en stresstest. Analyser deg frem til feilen Sett opp alarmer/varsling

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

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

367 Våren 2004 TDT4285 Planl&drift IT-syst 367 Ulike årsaker Direkte årsak. Det som umiddelbart gjør at det ikke virker. Indirekte årsak. Det som forårsaker den direkte årsaken. Årsak Direkte årsak Indir. årsak

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

369 Våren 2004 TDT4285 Planl&drift IT-syst 369 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!

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

371 Våren 2004 TDT4285 Planl&drift IT-syst 371 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.

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

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

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

375 Våren 2004 TDT4285 Planl&drift IT-syst 375 Retting av feil 1.linje2.linje3.linje Feilsituasjon Konseptuell feil Rutineoppgave Brukerfeil Veiledes Utføres VerifiseresRettes Verifiseres FeilsøkesRedesignes

376 Våren 2004 TDT4285 Planl&drift IT-syst 376 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

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

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

379 Våren 2004 TDT4285 Planl&drift IT-syst 379 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.

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

381 Våren 2004 TDT4285 Planl&drift IT-syst 381 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).

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

383 Våren 2004 TDT4285 Planl&drift IT-syst 383 Nivåer av backup Stor fil Grov fil Kjørefil Filleting Nyfil Grov fil Kjørefil Filleting Stor fil Grov fil Filleting Stor fil Grov fil Kjørefil Filleting Full backup Tid Stor fil Inkr. backup Nyfil Inkr. backup Filleting Basert på Tid Nivå 0 Nivå 1 Nivå 2

384 Våren 2004 TDT4285 Planl&drift IT-syst 384 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.

385 Våren 2004 TDT4285 Planl&drift IT-syst 385 Tre grader av backup Filinnhold Index 1. Speilkopi 2. Alle data 3. Fildata Innhold, metadata og ”implementasjon” Innhold og metadata Kun filinnhold

386 Våren 2004 TDT4285 Planl&drift IT-syst 386 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...)

387 Våren 2004 TDT4285 Planl&drift IT-syst 387 Backupmetoder Harddisk Tapestasjon 1 tape pr dag Oppdatering Backup- database Alle data lagres 1 gang i en database Inkrementell Full Versjonering Alle versjoner av hver fil lagres Tape backup Bruker Bruker er selv ansvarlig for å ta sin egen backup

388 Våren 2004 TDT4285 Planl&drift IT-syst 388 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?

389 Våren 2004 TDT4285 Planl&drift IT-syst 389 Må hele fila tas backup av? Ford Opel Mercedes Volvo Citroen Rolls Royce Lada Databasefil Mazda Juli Juni Mai April Mars Februar Januar August Append-only loggfil Backup av hele fila Backup kun av endret post Backup av hele fila Backup kun av tillagt post Update Append

390 Våren 2004 TDT4285 Planl&drift IT-syst 390 Backup - proaktivt eller reaktivt? Original harddisk Tape Tidsakse Restoret harddisk Krasj Backup Restore Proaktiv faseReaktiv fase Rutine Tidsnød

391 Våren 2004 TDT4285 Planl&drift IT-syst 391 Lokasjon for lagring av tape Samme bygning Samme rom TaperobotBrannsafe Leirras Nabobygg Nedbrenning Utbrenning Branntilløp Innbrudd

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

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

394 Våren 2004 TDT4285 Planl&drift IT-syst 394 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

395 Våren 2004 TDT4285 Planl&drift IT-syst 395 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. Partisjoner Dager Full Inkrementell

396 Våren 2004 TDT4285 Planl&drift IT-syst 396 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

397 Våren 2004 TDT4285 Planl&drift IT-syst 397 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

398 Våren 2004 TDT4285 Planl&drift IT-syst 398 Opprinnelig system DatabaseBrukerBackup1 Backup2 Alarm!

399 Våren 2004 TDT4285 Planl&drift IT-syst 399 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.

400 Våren 2004 TDT4285 Planl&drift IT-syst 400 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’.

401 Våren 2004 TDT4285 Planl&drift IT-syst 401 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.

402 Våren 2004 TDT4285 Planl&drift IT-syst 402 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.

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

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

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

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

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

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

409 Våren 2004 TDT4285 Planl&drift IT-syst 409 Løsning 1c – diagram DatabaseBrukerBackup Trinn 1 kopiering Trinn 2: bytte Alarm1Alarm2

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

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

412 Våren 2004 TDT4285 Planl&drift IT-syst 412 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)

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

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

415 Våren 2004 TDT4285 Planl&drift IT-syst 415 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.

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

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

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

419 Våren 2004 TDT4285 Planl&drift IT-syst 419 Expanded Sage Code of Efthics 1. Fair treatment 2. Privacy 3. Communication 4. System integrity 5. Cooperation 6. Honesty 7. Education 8. Social responsibility 9. Quality 10. Ethical responsibility

420 Våren 2004 TDT4285 Planl&drift IT-syst 420 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

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

422 Våren 2004 TDT4285 Planl&drift IT-syst 422 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.

423 Våren 2004 TDT4285 Planl&drift IT-syst 423 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

424 Våren 2004 TDT4285 Planl&drift IT-syst 424 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

425 Våren 2004 TDT4285 Planl&drift IT-syst 425 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.

426 Våren 2004 TDT4285 Planl&drift IT-syst 426 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”.

427 Våren 2004 TDT4285 Planl&drift IT-syst 427 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.

428 Våren 2004 TDT4285 Planl&drift IT-syst 428 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.

429 Våren 2004 TDT4285 Planl&drift IT-syst 429 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.

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

431 Våren 2004 TDT4285 Planl&drift IT-syst 431 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.

432 Våren 2004 TDT4285 Planl&drift IT-syst 432 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.

433 Våren 2004 TDT4285 Planl&drift IT-syst 433 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).

434 Våren 2004 TDT4285 Planl&drift IT-syst 434 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

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

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

437 Våren 2004 TDT4285 Planl&drift IT-syst 437 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

438 Våren 2004 TDT4285 Planl&drift IT-syst 438 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.

439 Våren 2004 TDT4285 Planl&drift IT-syst 439 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

440 Våren 2004 TDT4285 Planl&drift IT-syst 440 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

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

442 Våren 2004 TDT4285 Planl&drift IT-syst 442 Skadestedsarbeid Hva har skjedd? Lage ny løsning Kontakt utad (presse) Kontakt innad (infoansvarlig) Skadestedsleder Linje organisasjon

443 Våren 2004 TDT4285 Planl&drift IT-syst 443 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.

444 Våren 2004 TDT4285 Planl&drift IT-syst 444 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

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

446 Våren 2004 TDT4285 Planl&drift IT-syst 446 Dempe eller avverge skader Detektere Avverge Dempe Oppetid er viktig Kostnader er viktig Alltid nyttig

447 Våren 2004 TDT4285 Planl&drift IT-syst 447 (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

448 Våren 2004 TDT4285 Planl&drift IT-syst 448 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

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

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

451 Våren 2004 TDT4285 Planl&drift IT-syst 451 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.

452 Våren 2004 TDT4285 Planl&drift IT-syst 452 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

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

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

455 Våren 2004 TDT4285 Planl&drift IT-syst 455 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?

456 Våren 2004 TDT4285 Planl&drift IT-syst 456 Levetidssyklus for utstyr Tilbud Bestilling Levering InstallsjonBrukTa ut av drift Deinstallasjon Kassasjon Avhending Reparasjon

457 Våren 2004 TDT4285 Planl&drift IT-syst 457 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

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

459 Våren 2004 TDT4285 Planl&drift IT-syst 459 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

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

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

462 Våren 2004 TDT4285 Planl&drift IT-syst 462 Garanti Kjøper Selger Distributør Importør Produsent Dersom en av disse går konkurs? Garantikrav 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? Garantikrav

463 Våren 2004 TDT4285 Planl&drift IT-syst 463 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

464 Våren 2004 TDT4285 Planl&drift IT-syst 464 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

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

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

467 Våren 2004 TDT4285 Planl&drift IT-syst 467 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

468 Våren 2004 TDT4285 Planl&drift IT-syst 468 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?

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

470 Våren 2004 TDT4285 Planl&drift IT-syst 470 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

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

472 Våren 2004 TDT4285 Planl&drift IT-syst 472 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

473 Våren 2004 TDT4285 Planl&drift IT-syst 473 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

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

475 Våren 2004 TDT4285 Planl&drift IT-syst 475 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

476 Våren 2004 TDT4285 Planl&drift IT-syst 476 Nettverk Historikk Bruker Maskin Andre Brukere Maskin Bruker Ressurs

477 Våren 2004 TDT4285 Planl&drift IT-syst 477 Avveininger... ? Det et ingen iboende motsetning mellom disse, selv om det i praksis ofte kan virke slik. Sikkerhet Ryddighet Enkelhet Funksjonalitet

478 Våren 2004 TDT4285 Planl&drift IT-syst 478 Sikkerhet bør bygges på Pålitelighet Oversikt Planlegging/design fra starten Integrasjon i infrastrukturen Skall-tankegang Konsistens

479 Våren 2004 TDT4285 Planl&drift IT-syst 479 Analysefase 1. Kan dataene reproduseres? 2. Hvilke skadevirkninger har tap/endringer/etc? 3. Hvor mye koster relevant sikring? 4. Balanser pkt 1-3 Reproduser- barhet Skade- virkning Fare Uproble- matisk

480 Våren 2004 TDT4285 Planl&drift IT-syst 480 Hva beskytter vi oss mot? Uautorisert tilgang til data Sletting Endring Innsyn Tjenestetilgjengelighet Ressurstyveri/misbruk Dårlig omtale

481 Våren 2004 TDT4285 Planl&drift IT-syst 481 Fysisk sikring av utstyret Skallsikring Sonesikring Romsikring Tjener Data Klient

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

483 Våren 2004 TDT4285 Planl&drift IT-syst 483 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)

484 Våren 2004 TDT4285 Planl&drift IT-syst 484 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)

485 Våren 2004 TDT4285 Planl&drift IT-syst 485 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