Forelesning 1: Introduksjon

1
Forelesning 1Introduksjon

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

2
Faglærer, øv.ans. og und.ass.

• Faglærer Anders Christensen
• Telefon [phone] (evt 918-97-181)
• E-post anders.christensen_at_idi.ntnu.no
• Kontor IT-Syd rom 234
• Øvingsansvarlig Norvald Ryeng
• Telefon [phone]
• E-post norvald.ryeng_at_idi.ntnu.no
• Kontor IT-Vest 256
• Und.ass Amir Zangeneh
• E-post zangeneh_at_idi.ntnu.no

3
Timeplan
Mandag Tirsdag Onsdag Torsdag Fredag
0815-0900
0915-1000
1015-1100
1115-1200
1215-1300 Forel F6
1315-1400 Forel F6
1415-1500 Forel F6
1515-1600 Øving F2
1615-1700 Øving F2
1715-1800
4
Vekttall og timefordeling
3 timer
4 timer
3 timer
2 timer
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
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.
4. Øvinger for fjernstudenter blir en utfordring

7
Forelesningsplan

1. Introduserende (3)
2. Grunnleggende kunnskap (9)
3. Konsepter (9)
4. Teknikk (18)
5. Utsyn fremover (3)
6. Gjesteforelesning med Stallman (1)

8
Pensumlitteratur

• Limoncelli Hogan Practice of System and
  Network Administration
• Diverse utfyllende papers/notater
• Foiler fra forelesningene
• Obligatorisk øving

9
Utfyllende litteratur

• Burgess Principles of System and Network
  Administration.
• Nemeth al Unix System Administration Handbook.
• Mikalsen al Drift av lokalnettverk.
• ITIL Service support
• ITIL Service delivery

10
Forelesninger

• Tilstedeværelse er ønskelig!
• Deltakelse i timene er også ønskelig!
• Foreleser kan spørre studentene.
• Diskusjon av mikrocases.
• Starter presis ...

11
Kommunikasjonsmidler

• (Forelesninger og øvingstimer)
• Ukentlig trefftid?
• Epostliste (tdt4285_at_idi.ntnu.no)
• Pr epost (tdt4285-admin_at_idi.ntnu.no)
• Newsgruppe (ntnu.ime.idi.tdt4285)
• Referansegruppe
• Its learning?

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
Plassering av TDT4285 ved IDI
Datamask. og opsys
Prosjekt
Datamod og database
Diplom
TDT4285
Ytelsesvurdering
Programmering
14
Eksamen (10. juni 2005 kl 09.00)

• Form er skriftlig
• Tid er 4 timer
• Kun kalkulator som hjelpemiddel
• Må ha godkjent obligatorisk øving
• Oppgaveformat likner trolig tidligere år
• Repetisjoner spiser ikke forelesningene

15
Synkroniseringsukene (9 og 10)

• Undervisningsfri i faget
• Obligatorisk øving deles ut før synkeukene
• Kanskje en seminarserie om ITIL, men det er ikke
  formelt relatert til faget, eller del av pensum

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
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
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
Forelesning 2Utfordringene

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

20
Historikk
Tynne klienter
IBM-PC
2000
1990
Mainframes
Servicecenter
1980
IT-avd
Bærbare
1970
EDB-avd
1960
Internettet
Regnesentre
Hjemmemaskinen
Minimaskiner
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/synsing
• Aldri kjedelig alltid noe som skjer

22
Hva er IT-drift?
Indirekte oppgave
Ressurs- utnytting
Funksjonalitet
For andre enn deg selv
Bruker- behov
Kost- nader
Stabs- funksjon
Stabilitet
Heltids- beskjeftigelse
Vedlikehold
Profesjonell drift av storskala dataanlegg
Mange maskiner
Datamaskiner
Brukere
Mange brukere
Nettverk
Stor kompleksitet
Programvare
Infra- struktur
Parallelle systemer
23
Systemadministrators roller?
Tilretteleggeren
Produkt- finneren
Team-med- arbeideren
Brann- mannen
Hjelperen
Prosjekt- lederen
Etterforskeren
Bruker- forkjemperen
Installatøren
Vedlikeholderen
Nisje- område- eksperten
Nattevakta
Leverandør- kontakten
Skurken
Improvisatøren
Prosjekt- arbeideren
Psykologen
Problem- forebyggeren
Rutine- utføreren
Infrastruktur- byggeren
Kvalitets- sikreren
Budsjett- administratoren
Sikkerhets- eksperten
Utdanneren
Dommedags- profeten
Den visjonære
Vaktmesteren
Feil- søkeren
Planleggeren
Reparatøren
Policy- skriveren
Selgeren
Hønemor
Overvåkeren
Fikseren
Laboratorie- teknikeren
Helten
Lytteren
Løsnings- designeren
Avstrafferen
Innkjøperen
Lederen
Teknokraten
Syndebukken
24
Terminologi

• Sysadmin (systemadministrator) person som er
  (del-)ansvarlig for drift av et datasystem.
• Drifte noe man gjør med kyr.
• System(s) administration en eller mange
  systemer?

25
Tre store problemstillinger

1. Endringshåndtering
2. Skalerbarhet
3. (Person)kommunikasjon

26
Problemstilling 1Endringshå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
Problemstilling 2Skalerbarhet

• Kapasitetsplanlegging
• Testing opp mot antatt full last
• Organisatorisk skalerbarhet
• Monitorering
• Kan ta ut stordriftfordeler

28
Problemstilling 3Personkommunikasjon

• At 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
Ti utfordringer

• Måldefinisjon
• Feilsøking og retting
• Endringer
• Sikkerhet
• Divergens

• Kompleksitet
• Kommunikasjon
• Katastrofeplanlegging
• Bevare eller forbedre?
• Læring

30
Utfordring 1Må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
Utfordring 2Feilsø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
Utfordring 3Endringer

• 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
Utfordring 4Sikkerhet

• 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
Utfordring 5Divergens

• 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
Utfordring 6Kompleksitet

• Har man oversikt over systemets kompleksitet og
  er kompleksiteten større enn hva brukernes behov
  tilsier? Jobbes det for å redusere kompleksiteten
  der den er høyere enn det som trengs?

36
Utfordring 7Kommunikasjon

• 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
Utfordring 8Katastrofeplanlegging

• 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? Er dette noensinne blitt testet?

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
Utfordring 10Læring

• Lærer man av feilene man gjør? Lærer man av
  andres feil? 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
Forelesning 3Løsningsskisser

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

41
Faser i en driftsorgs liv...
Områdebasert arbeidsdeling
Rollebasert arbeiddeling
Supermann
Datasenter
Radarpar
1.linje
Trekløver
Oppdeling av ansvars- område
ITIL
2.linje
3.linje
Prosessbasert arbeidsdeling
Heltemodellen
Teammodellen
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
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
Når kollapser områdebasert arb.deling?

• Det blir for mange grenseflater.
• Hver grenseflate blir for kompleks.
• Det ikke finnes flere naturlige gr.flater
• Vrient å avgjøre ansvar utfra gr.fl

Område1
Område2
Område3
Område4
Område5
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
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
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 på ikke-trivielle måter.

48
1. Linjes oppgaver (rutiner)

• ...bruker kartet som turguide, og utfører
  rutiner som er definert på forhånd.

Kart
Rutine-samling
Rutiner
1.linje
Terreng
49
2. Linjes oppgaver (drift)
Med feil

• ...med kartet som referanse retter terrenget der
  det er galt, samt utfører oppgaver som ikke er
  formulert som rutiner

Kart
Retting
Feilsituasjon
Feilretting
2.linje
Operasjon
Endringer innen samme kart
50
3. Linjes oppgaver (prosjekt)
3.linje
Prosjekt

• ...utvikling av systemet endring av kart og
  terrreng i parallell.

Kart
Kart
Stor endring
Stor endring
Terreng
51
Prosjekt, rutiner og drift
3.linje
Med feil
Prosjekt
Kart
Kart
Stor endring
Rutine-samling
Retting
Feilsituasjon
Rutiner
Feilretting
Stor endring
2.linje
1.linje
Terreng
Operasjon
Endringer innen samme kart
52
Arbeidsfokus og erstattbarhet
På lang sikt
3.linje
Erstatt- barhet
2.linje
1.linje
På kort sikt
På lang sikt
På kort sikt
Arbeidsfokus
53
Eksempler på oppgaver

• Skifte passord (1)
• Restore slettede filer (1)
• Manglende toner (1)
• Ingen utskrift (12)
• Nettet er tregt (123)
• Installere ISDN på bærbar (2)
• Nytt backupsystem (3)

54
Kontinuerlig forbedring
Analysere
Prioriteringsplan
Loggdata
Konstruere
Monitorere
3.linje
1-2.linje
Igangsette
Installerbart system
Kjørende system
55
Helter og teammedarbeidere
Heltemodellen
Teammodellen
Tett kom- munikasjon
Formelle kanaler
Kort om- stillingstid
Konsistent
Fordeler
Bruker- nærhet
Form- fasthet
Profesjonell avstand
Eierfølelse
Tidsfor- sinkelse
Ugjennom- trengelig
Vagt og ullent
Byråkratisk
Ulemper
Avstand, upersonlig
Personal- utskiftning
Person- avhengig
Utbrenthet
56
Arbeidstitler

• 1.linje systemoperatør, operatør
• 2.linje systemadministrator
• 3.linje systemarkitekt, systemanalysator,
  systemintegrator

57
Single point of entry
Brukere

• Alle henvendelser fra brukerne skal gå igjennom
  et call-center.

1.linje
Helpdesk
Operatør
2.linje
3.linje
58
Hvorfor SPOE

• Motvirke dobbeltrapportering
• Koordinere innsats
• Gi bedre oversikt og utestående oppgaver
• Skjerme mot avbrytelser
• Lette prioritering
• Sikre tilbakemelding til bruker

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.
• Out-soursing at enkelte oppgaver innen drift er
  out-sourcet

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
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
Forelesning nr 4Klienter

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

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
Evards livssyklus
Rebuild
New
Update
Build
Entropy
Unknown
Clean
Configd
Debug
Initialize
Retire
Off
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
Forfatterens hovedbudskap

• Tre viktige ting med klienter
• Automatisere installasjon
• Håndtere oppdateringer
• Konfigurere nettverksparametre

67
Automatisere

• Effektiviserer arbeidet
• Bedrer konsistensen
• Automatisering gir bedre arbeid
• Automatisering er implisitt dokumentert
• Fullautomatisert betyr 100,00

68
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

69
Debugge eller gjenbygge

• Gjenoppbygge
• Hurtighet er viktig
• Viktig at ting er likt
• Har vært på utlån
• Motvirke tidens tann
• Når stabilitet ikke er essensielt.

• Debugge
• Sikkerhetsrelaterte problemer.
• Gjennomgående feil
• Alvorlige feil
• Dersom du ønsker å forstå sammenheng

70
The four holy Rs of brute force
Retry
Restart
Reboot
Reinstall
71
Oppdateringer

• En oppdatering er en målrettet endring på en
  allerede installert og brukbar maskin, og typisk
  omfatter sikkerhetsmessige, stabillitetssikrende
  eller konvergerende endringer.

72
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

73
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

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

75
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

76
Tommelfingerregler om platformer

• To er dobbelt så dyrt som en
• Prioriter noen få (first class citizens)
• Forsøk variantbegrensning
• Forsøk å kollapse to plattformer til varianter av
  samme platform
• Platformer er gode skillelinjer å områdedele
  driftsstaben etter.

77
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

78
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

79
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

80
Forelesning 5Tjenermaskiner

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

81
Definisjon

• En tjener er en datamaskin på hvilken tjenester
  som brukes av brukere eller andre maskiner er
  implementert, slik at andre i større eller mindre
  grad er avhengig av tjenermaskinen.

82
Hva skiller klienter og tjenere?

• Avhengighet andre maskiner og brukere er
  avhengig av den for å kunne kjøre
• Kostnader typisk større kostnader i innkjøp og
  drift, dyrere hardware
• Konfigurasjon annerledes konfigurert enn den
  vanlige klientmaskinen
• Bruk yter normalt felles tjenester

83
Tre hardware-markeder
Kostnad pr ytelse Infrastruktur Lav
MTTR Stabilitet
Rask CPU Ny HW Grafikk Billig Siste nytt Skifte
av OEM
Server markedet
Hjemme markedet
Forretnings markedet
TCO-fokus Var.begrensn Stabil teknologi
84
Valg av maskinvare

• Standard hyllevare
• Billig!
• Lav terskel for å bytte
• Kan kjøpe flere gir redundans
• Spesiell tjener-maskinvare
• Pålitelig og med høy kvalitet
• Redundante løsninger
• Overvåkningsmuligheter
• Feilkorrigering

85
Momenter ved maskinvalg

• Romslig utvidbar kasse
• Kraftige CPUer
• Høy I/O-ytelse
• Støtte for utvidelse/oppgrad
• Monterbar i 19 rack
• Tilgang fra bakside

• Enkle og billige
• Kan stables i høyden
• Kompakte
• Ikke spesielt utvidbare
• Må ha støtte for fjerndrift

86
Vedlikeholdskontrakter
Eskalering
Reservedeler?
Responstid
Pris
Onsite/ Offsite?
Feil oppstår
Avtaleinngåelse
Timekost
87
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

88
Reaktivt og proaktivt vedlikehold

• Reaktivt
• Servicekontakt
• Reservedeler
• Garantiordninger
• Etterbestille deler
• Reservemaskin
• Backup/restore
• Ad hoc
• Konkret og reellt

• Proaktivt
• Overkapasitet
• Planlagt utfasing
• Automatisk failover
• Monitorering
• Redundans
• Diskspeiling
• Planmessig
• Analytisk

89
Driftskostnader vs kvalitet

• Proaktivitet er dyrere enn reaktivitet i rene
  driftskostnader (for du skal sikre deg mot alt
  som kan skje)
• Reaktivitet er enklere enn proaktivitet (for du
  tenger bare å forholde deg til de faktiske,
  konkrete feilsituasjonene)
• Reaktiv drift er tidvis ikke tilstrekkelig for å
  oppnå høy nok kvalitet på datatjenestene.

90
Sikkerhetsmodell
Bastioner
Eksterne maskiner
Ytre skall
tj4
Midtre skall
Indre skall
tj3
tj2
tj1
Tillatt
Viktige maskiner
Krever auth
Kontormaskiner
Gjestemaskiner
91
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

92
Harddisker servicestrategier

• Monitorere loggdata
• Tidvis speiling av viktige data
• Kontinuerlig speiling
• RAID-løsninger med feiltoleranse
• Backup

93
Spesialtjenere (server appliances)

• Fordeler
• Spesialkonfigurasjon
• Fintunet til bestemt oppgave
• Frigjør tid (fra å konfigurere egne maskiner)
• Lite ekstra funksjonalitet/kompleksitet
• Ulemper
• Øker i praksis antall platformer
• Dersom produsenten går konk
• Ofte tidsforsinkelse på sikkerhetsoppdateringer

94
Redundans

• Følgende dimensjoner finnes
• Kapasitet ibruk/ekstra speilende av
• Aktivisering manuell automatisk
• Bytting hotswap reset slå-av
• Toleranse enkeltfeil dobbeltfeil etc
• Håndtering deteksjon korreksjon
• Type redundans n1 n2 2n

95
Forelesning nr 6Tjenester

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

96
Definisjon

• Tjenester er kontinuerlig kjørende programmer som
  tilbyr en standardisert funksjonalitet, basert på
  en protokoll, overfor brukere eller
  klientprogrammer, ofte over nettverk.

97
Eksempler på tjenester

• DNS navnetjenester
• lpd utskrift over nettet
• DHCP dynamisk tildeling av IP-addr
• NIS autorisasjon og annet
• Web-tjener
• ftp deling av filer over nettet

98
I dette kapitlet

• Brukers/kundes/SAs behov
• Arkitekturvalg
• Pålitelighet og kompleksitet
• Navnevalg
• Skalerbarhet
• Monitorering
• Brukerstøtte

99
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

100
Behov for en SLA?

• Liste tjenester
• Spesifisere hver tjenestes nivå
• Tilgjengelighet
• Ytelse
• Brukersupport
• Reponstid for ulike problemer
• Eskaleringsregler
• Bøter, priser, ekstra arbeid

101
Operative behov

• Administrative grensesnitt
• Interoperabilitet og integrerbarehet
• Skalerbarhet
• Oppgraderbarhet
• Implementerbarhet av pålitelighet
• Nettverk (latenstid og båndbredde)
• Budsjettering

102
Arkitekturvalg
Protokoll
De facto
Komite
Dynamisk
Statisk
Utvidelser
Kompati- bilitet
Produkt
103
Navnevalg
mail.idi.ntnu.no
zevs.idi.ntnu.no
s/n 2163726091
Maskin- navn
Generiske navn
Hardware- navn
Tung rekonfig
Enkel dynamikk
104
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

105
Fjerninnlogging
Mulig innlogging
Dvs minst mulig fjerninnlogging på
tjenestemaskiner
Aktiviserer bugs
Støy
Avlytting?
Aktivitet
Kompleks bruk
Fyller loggene
106
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

107
Ytelsesplanlegging

• Estimer ressursbruk (initielt og full bruk)
• Test for å kunne estimere skalering
• Skaff nok ressurser
• Skaff nok kompetanse
• Gjør det skikkelig fra starten!

108
Monitorering

• Monitorer for følgende
• Snikende ytelsesdegradering
• Tilgjengelighet
• Alvorlige feilmeldinger
• Kapasitetsproblemer
• Brukers subjektive oppfatning
• Omfang og mønster av bruk

109
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!

110
Feller ifm skalerbarhet

• Inkrementell utvikling istedetfor inkr. utrulling
• Manglende ressursutnyttelse
• For lite ressurser
• For lite utvidbarhet

111
Overfasing til ny maskin
Begge tjenester operative en stund
Gammel tjeneste
Ny tjeneste
Monitorering
Bruker
112
Avhengigheter

• Tjeneste som mest avhenger av DNS
• Tjeneste som flest avhenger av (bl.a)
• Utskrift
• Fildeling
• E-mail
• Kjenn til avhengighetene!

113
Forelesning nr 7Statisk dokumentasjon

• TDT4285 Planlegging og drift av IT-systemer
• Vår 2005
• Anders Christensen, IDI

114
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
Implementerer
Forklarer
Dok
115
Målsetting

• Formidle kunnskap mellom sysadmins
  (kommunikasjon)
• Sette et utgangspunkt for systemet
  (endringshåndtering)
• Felles referansepunkt for samarbeid (skalering)

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

117
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)

118
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å

119
Hva kjennertegner god dok?

• Forventninger til format
• Forventninger til plassering
• Forventninger til fokus
• Forventninger til innhold
• Forventninger til tilgjengelighet
• Forventninger til oppdaterthet

120
Tommelfingerregler for dok

• Skap en struktur
• Jevnlige reviews og audits
• Skap tilgjengelighet
• La dok være en del av loopen
• Oppdater! (helst før endring)
• Eliminer det som ikke vil bli brukt eller
  oppdatert.

121
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

122
Dok-typerSystemdokumentasjon

• Format manualer
• Innhold referansedokumentasjon
• Når for alle leverte systemer
• Fare for mye og for generelt
• Skriver leverandør
• Bruker alle

123
Dok-typerBrukerdokumentasjon

• 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

124
Dok-typerSystembeskrivelse

• Format tekstlig
• Innhold overordnet beskrivelse
• Når felles for hele systemet
• Fare gjentaking av info fra subdok.
• Skriver 3.linje
• Bruker alle

125
Dok-typerSystemoversikt

• Format diagram, skisser, tabeller
• Innhold lokal referanseinformasjon
• Når for alle delsystemer
• Fare manuell oppdatering
• Skriver automatisert av 3.linje
• Bruker alle

126
Dok-typeSubsystembeskrivelse

• 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

127
Dok-typeStandard 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

128
Dok-typeTest-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

129
Dok-typeHW-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

130
Dok-typeKommentarer 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

131
Dok-typeHjernemessig 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

132
Sammenheng mellom dok-typer
Systembeskrivelse
Systemoversikt
HW- logg
Subsystembeskrivelse
SOP
Testrutiner
Systemdokumentasjon
133
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

134
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

135
Dok er nødvendig for å

• Anonymisere arbeidsoppgaver
• Muliggjøre peer review
• Spesifisere en normaltilstand
• Identifisere forbedringsområder
• Angir basis for endringer.

136
Forelesning nr 8Dynamisk dokumentasjon

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

137
Prosjekt, rutiner og drift
3.linje
Med feil
Prosjekt
Kart
Kart
Stor endring
Rutine-samling
Retting
Feilsituasjon
Rutiner
Feilretting
Stor endring
2.linje
1.linje
Terreng
Operasjon
Endringer innen samme kart
138
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

139
Arbeidsplan for CCF
Baseline
CCF
Workplan v1
Opplæring
Test på testsystem
Kundereview
Roller
Workplan v2
Ledelsesreview
Test på preprod.
Ansvar
Workplan v3
Review av kolleger
Implementering
140
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

141
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

142
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

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

144
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?

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

146
CCF innhold (IV)

1. Revalideringplan hvordan (og med hvilke tester)
   verifiserer man at systemet er operativt etter
   endringen.
2. Backout-plan hvordan kan man reversere
   endringen underveis dersom det slår feil
3. Status hvilket steg i prosessen har denne
   CCFen kommet

147
CCF innhold (V)

1. Merknader diverse informasjon, kommentarer,
   fotnoter og advarsler fra personer i prosessen.
   Ting som ikke passer inn i de øvrige punktene.
2. Tilhørende dokumentasjon liste med referanser
   til annen relevant dok, deriblant
   systemdokumentasjon.

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

149
CCF innhold (VII)

1. Testplan hvordan tester man den nye
   funksjonaliteten, plan med testskripts som
   etterpå kan legges inn i baseline.
2. Implementasjonsmerknader tekniske merknader.
3. Administrativ informasjon så som dato,
   forfattere, versjonsnummer etc.

150
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

151
Forelesning nr 9Tjeneroppgraderinger

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

152
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

153
Punkt 1Lag 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?

154
Punkt 2Verifiser 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

155
Punkt 3Lag 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.

156
Punkt 4Lag en backout-plan

• En backoutplan er en plan for hvordan du
  reverserer endringen, slik at du kommer tilbake
  til det opprinnelig systemet.

157
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?

158
Punkt 6Informer 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

159
Punkt 7Gjennomfø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.

160
Punkt 8Gjennomfø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.

161
Punkt 9Gjennomfø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.

162
Punkt 10Ved 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.

163
Punkt 11Informer 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.

164
Oppgradere eller nyinstallere

• Oppgradere
• Bevarer mye av det gamle oppsettet
• Tar korter tid

• Nyinstallere
• Ekskluderer grums fra tidligere inst
• Lettere å sikre at det virker

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

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

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

168
Forelesning nr 10Vedlikeholdsvinduer

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

169
Definisjon

• Et vedlikeholdsvindu er et forhåndsdefinert,
  varslet tidsrom der dataanlegget kan tas ned for
  å gjennomføre vedlikehold og oppgraderinger,
  typisk flere i parallell.

170
Vedlikeholdsvinduer
Planlegging
Oppgradering

1. Tidligere forelesning

Vedlikeholdsvindu

1. Denne forelesningen

Oppgrad1
Oppgrad5
Planlegging
Planlegging
Oppgrad2
Oppgrad4
Oppgrad6
Planlegging
Nedtaking
Oppstart
Planlegging
Oppgrad3
171
Gangen i et vedl.vindu
Forberedelse
Gjenstart
Gjennomfø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

172
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

173
Oppetid og nytteområde
Kan tas ned ad hoc
Vedlikeholds- vinduer
Kan ikke tas ned
Sporadisk oppetid
1
2
3
4
5...
0
90
99
0
99,9
99,99
99,999
174
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

175
Regelmessighet av vedl.vinduer
Positivt Negativt
Etter behov Fleksibelt Lite koordinering Serialisering
På faste tidspunkter Brukeren kan tilpasse sitt arbeide Bedre planlegging Miste status hvis den ikke brukes
176
Regelmessighet eksempler

1. Første mandag pr mnd fra 18.00 til klokken 08.00
   neste morgen
2. Fra fredag 1800 til mandag 0800, én gang i hver
   av juni, juli, august, desember og januar.

177
Planlegging i forkant
Avhengigheter
Rekkefølgen innen en masterplan
Leveringstid på utstyr
Planlegging i forkant av et vedl.vindu
Lisenser
Innhente kompetanse
Annonsering
Endrings- planer
178
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?

1. Hva blir berørt?
2. Hvem utfører/har ansvar for endringen?
3. Hvor lang tid tar det (klokketid og arb.tid)?
4. Hva er testproc. og hva trengs av utstyr?
5. Hva er back-out, og hvor lang tid tar det?

179
Saksgang ved endringsforslag
Siste uka
Endrings- utkast
Peer- review
Frysing
Gjennom- føring
I tilfelle endringer
Flight- director
180
Masterplanen

• Masterplanen settes opp at flight director
• Gir en schedule av aktivitetene
• Tar hensyn til avhengigheter
• Realistisk mht tidsrammene/ressurser

181
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å

182
CCF versus endringsforslag

• Change control forms
• Fokus kommunikasjon
• Peer review
• Endringshåndtering
• Genererer et spor (historikk)
• Kvalitetssikring

• Endringsforslag
• Schedulering
• Timing
• Gjennomføring
• Koordinering

183
Case IDI flytter (I)
2x2p
2p
Lade
Elektro
Demontere gml utstyr
Demontere gml utstyr
1psjåfør
Transport på vei
2(1)p
Midlertidig plassering
Transport på tralle
IT-Vest
4x2p
Midl. Plassering utenfor mask.rom
Montering
184
Case IDI flytter (II)
8
9
11
15
17
23
Nedtaging
Demontering
Transport
Oppmontering
Mat
Gjenstart
Alle
De fleste
Noen
185
Koordinering under driftstans

• Scheduler forstyrrende aktiviteter samtidig, og
  helst først i vedl.vinduet
• Sørg for enkel kommunikasjon mellom
  systemadminene, f.eks via radio.
• Ha en tilgjengelighet neste dag
• Monitorer systemet neste dag
• Gjennomfør en post mortem-granskning

186
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

187
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

188
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

189
Forelesning nr 11Tjenstekonvertering

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

190
Tjenestekonvertering

• En eksisterende tjeneste skal skiftes ut med en
  ny, enten ved oppgradering software, skifte av
  hardware, protokoll eller endring i infrastruktur.

191
Utrullingsstrategi
Gammel
En
Gammel
Gammel
Deg selv
Noen
Flash-Cut
SA-kolleger
Ny
Overlapp
Avbrudd
Ny
Ny
Mange
Andre
Sømløst
Brudd
192
Kommunikasjon
Gammel tjeneste
Er helpdesk informert?
Har du full kontroll på hvordan brukerne
benytter tjenesten?
Avbrudd ved konverteringen?
Bruker
Konvertering
Bruker
Bruker
Må noe gjøres på hver brukes maskin?
Ny tjeneste
Er ny tjeneste fullstendig Kompatibel med den
gamle?
193
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

194
Lagdeling og søyler
Lagdeling dersom sømløs overgang er mulig
Søyler dersom man man får funksjonsbrudd
Kunde1 Kunde2 Kunde3 Kunde4
Applikasjon
Protokoll Lagdelt
Tjener
Datalager Søyle
Op.sys
195
Rioting mob technique
Unix-team B
PC-team B
HØYRE KONTORREKKE
Senior troubleshooters
VENSTRE KONTORREKKE
PC-team A
Unix-team A
196
Avbrudd

1. Få men store er bedre enn mange og små.
2. La brukeren få vite på forhånd hva han tjener på
   avbruddet. (Whats 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.

197
Overfasing av tjenester
Gammel
På forhånd
Logging
redirekt
Gammel
Ny
Overgang
Ny
Gammel
I etterhånd
Feilmelding m/info
Ny
Etterpå
198
Avbruddstrategier
Sentralt Hos brukeren
Sømløst Trivielt En-noen-mange
Avbrudd Vedlikeholds- vinduer Rioting mob på isolerte delsystemer
199
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

200
Viktige momenter
Back-out- plan
Trippel- testing
Dobbelt- testing
Peer- review
Opplæring
Planlegging
Testing
Tilstede- værelse
Informasjon
Annonsering
Kommunikasjon
201
Forelesning nr 11Tjenstekonvertering

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

202
Tjenestekonvertering

• En eksisterende tjeneste skal skiftes ut med en
  ny, enten ved oppgradering software, skifte av
  hardware, protokoll eller endring i infrastruktur.

203
Utrullingsstrategi
Gammel
En
Gammel
Gammel
Deg selv
Noen
Flash-Cut
SA-kolleger
Ny
Overlapp
Avbrudd
Ny
Ny
Mange
Andre
Sømløst
Brudd
204
Kommunikasjon
Gammel tjeneste
Er helpdesk informert?
Har du full kontroll på hvordan brukerne
benytter tjenesten?
Avbrudd ved konverteringen?
Bruker
Konvertering
Bruker
Bruker
Må noe gjøres på hver brukes maskin?
Ny tjeneste
Er ny tjeneste fullstendig Kompatibel med den
gamle?
205
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

206
Lagdeling og søyler
Lagdeling dersom sømløs overgang er mulig
Søyler dersom man man får funksjonsbrudd
Kunde1 Kunde2 Kunde3 Kunde4
Applikasjon
Protokoll Lagdelt
Tjener
Datalager Søyle
Op.sys
207
Rioting mob technique
Unix-team B
PC-team B
HØYRE KONTORREKKE
Senior troubleshooters
VENSTRE KONTORREKKE
PC-team A
Unix-team A
208
Avbrudd

1. Få men store er bedre enn mange og små.
2. La brukeren få vite på forhånd hva han tjener på
   avbruddet. (Whats 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.

209
Overfasing av tjenester
Gammel
På forhånd
Logging
redirekt
Gammel
Ny
Overgang
Ny
Gammel
I etterhånd
Feilmelding m/info
Ny
Etterpå
210
Avbruddstrategier
Sentralt Hos brukeren
Sømløst Trivielt En-noen-mange
Avbrudd Vedlikeholds- vinduer Rioting mob på isolerte delsystemer
211
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

212
Viktige momenter
Back-out- plan
Trippel- testing
Dobbelt- testing
Peer- review
Opplæring
Planlegging
Testing
Tilstede- værelse
Informasjon
Annonsering
Kommunikasjon
213
Forelesning nr 12Oversikt over ITIL

• TDT4285 Planlegging og drift av IT-systemer
• Våren 2005
• Anders Christensen, IDI

214
Hva er ITIL?

• Et rammeverk for strukturering av
  IT-driftsorganisasjoner
• Basert på erfaringer om best practice
• En tankemåte, som du ikke nødvendigvis må
  implementere slavisk, men som du kan la deg
  inspirere av.
• Offentlig og fritt tilgjengelig.

215
Historikken til ITIL
ITIL Versjon 1
80-tallet
1030 bøker
ITIL Versjon 2
90-tallet
2N bøker
Engelsk statsforvaltning
2000-tallet
Nederland
Resten av verden
Opphav (alle usanne) Thatcher-direktiv
Falklandskrigs-IT-kaos IBM-outsourcing
Google april 2004 ITIL357k, iso90001,94M febr
2005 ITIL1,13M, iso9000796k
216
Hvorfor bruke ITIL?
Håndtere kompleksitet
NEI
Enklere
JA
Proaktivitet
Billigere driftskostnader
Dokumentasjon
Forutsigbarhet
Destillat av oppsamlet erfaringer
Suboptimalisering
Reativitet
Felles stammespråk
Avstemme forventninger
217
ITIL er prosessorientert
Ledere
Personer
Mellomledere
Roller
ITIL
Tradisjonelt
Ansatte
Deloppgaver
Prosesser
Fagområder
Top-down, kontroll, arbeidsområder
Oppgaveorienter, ikke-hierarkisk
218
ITILs 10 hovedprosesser
Service Desk
Service Level mgmt
Financial mgmt for IT-services
Incident mgmt
Problem mgmt
Capacity mgmt
ITIL
Config. mgmt
IT Services Continuity mgmt
Change mgmt
Availability mgmt
Release mgmt
219
Hva er ikke ITIL?

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

220
Kunder og brukere...
Bruker
Kunde
Service Delivery rødboka
Service Support blåboka
221
Service desk

• Målsetning En service-desk er en ITIL funksjon
  som er et single point of contact (entry) som
  håndterer alle henvendelser fra brukerne.
• Oppgaver Tar imot henvendelser, utfører oppgaver
  og etterforsker incidents, vanligvis innenfor
  incident mgmt. Foreslår