1 15. januar 2010 TDT4285 Planl&drift av IT-syst Forelesning 2: Utfordringene TDT4285 Planlegging og drift av IT-systemer Våren 2010 Anders Christensen, IDI

2 15. januar 2010 TDT4285 Planl&drift av IT-syst Historikk Minimaskiner IBM-PC ”Internettet” Mainframes Hjemmemaskinen Bærbare Regnesentre EDB-avd IT-avd Servicecenter Tynne klienter 2010 Cloud comp

3 15. januar 2010 TDT4285 Planl&drift av IT-syst Fagets karakter Fra aktivitet → yrke → fagfelt Mange ”midlertidige” og tilfeldige utøvere Er blitt en karrierevei Fremdeles litt vel mye ”kvakksalveri” Raske endringer (paradigmeskift) Både pragmatisk og religiøst/synsende Aldri kjedelig – alltid noe som skjer Grenseflater mot mange andre fag

4 15. januar 2010 TDT4285 Planl&drift av IT-syst 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 Globalt

5 15. januar 2010 TDT4285 Planl&drift av IT-syst 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 Detektiven Forslags- stilleren Den visjonære

6 15. januar 2010 TDT4285 Planl&drift av IT-syst 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?

7 15. januar 2010 TDT4285 Planl&drift av IT-syst Grenseflater mot andre fagområder IT-drift Informasjons- sikkerhet Prosjekt- styring Salg VVS Utvikling Datanett Ledelse Ytelses- vurdering Databaser

8 15. januar 2010 TDT4285 Planl&drift av IT-syst Tre store problemstillinger Drifts- problemer Endringshåndtering Skalerbarhet Person- kommunikasjon Tre komponenter som er forårsakende, deltakende eller forsterkende i 90% av alle dataproblemer

9 15. januar 2010 TDT4285 Planl&drift av IT-syst Problemstilling 1: Endringshåndtering Målrettet og nyttig endring Planlagt i forkant, bieffekter klarlagt Kontrollert gjennomføring Forhåndstestet og utprøvd Rekonstruerbart og reverserbart Sporbarhet i ettertid Evne til ferdigstilling

januar 2010 TDT4285 Planl&drift av IT-syst Problemstilling 2: Skalerbarhet Kapasitetsplanlegging Testing opp mot antatt full last Design av løsninger som lar seg skalere ”Organisatorisk” skalerbarhet Monitorering for å forstå hva som skjer Kan ta ut stordriftfordeler

januar 2010 TDT4285 Planl&drift av IT-syst Problemstilling 3: Personkommunikasjon 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

januar 2010 TDT4285 Planl&drift av IT-syst Ti utfordringer 1.Måldefinisjon – er behov avklart og målene definert? 2.Feilsøking og -retting – eller ren symptombehandling? 3.Endringer – planlagt, målrettet, dokumentert, reverserbart? 4.Sikkerhet – integrert i alt, eller isolert venstrehåndsarbeid? 5.Divergens – hva motvirker akumulerte småendringer? 6.Kompleksitet – er det mulig å ha oversikt? 7.Kommunikasjon – snakker man forbi hverandre? 8.Katastrofeplanlegging – kan driften reetableres? 9.Bevare eller forbedre – hvor går riktig balansen? 10.Læring – læres det i forkant eller etterkant?

januar 2010 TDT4285 Planl&drift av IT-syst Case 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? Semesterstart flyttes en uke tidligere på året enn hva som har vært vanlig: TT skifter ikke om fra sommerruter før en uke i semesteret, og SITS har kantinene på halv bemanning og mange ”stengte” bord.

januar 2010 TDT4285 Planl&drift av IT-syst Case 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? Bookmarksfil ”forsvinner” hyppig for mange brukere. I starten: det tas inn fra backup. Etter hvert: det lages skript for å ta ekstra mange kopier av disse. En stund senere: man finner feilen etter målrettet feilsøking.

januar 2010 TDT4285 Planl&drift av IT-syst Case 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? En bruker kommer med et ønske om endring av oppsett for skriverne, som høres enkelt ut, og derfor endres system ad hoc. Det viser seg å ha bieffekter for andre brukere, men man husker ikke helt hvordan endring ble gjort, og kan ikke reversere den.

januar 2010 TDT4285 Planl&drift av IT-syst Case 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 isolerte skippertak? I en stor org med fokus på sikkerhet ble det oppdaget at alle kunne lese hverandres filer. Da det ble påpekt, ble det innført forbud mot å gjøre dette, fremfor hindre mot at det var mulig å gjøre det, eller logger for å verifisere at det ikke ble gjort.

januar 2010 TDT4285 Planl&drift av IT-syst Case 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? Datasystemet som aldri kommer opp av seg selv etter strømstans: endringsrate og intervallene mellom strømstansene og det at system aldri restartes ’i utide’ gjør at nærmest er sikret at ’noe nytt’ går galt hver gang.

januar 2010 TDT4285 Planl&drift av IT-syst Case 6: Kompleksitet 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? Telling på IDI: 692 PC-er hadde til sammen 730 hardisker, fordelt på 132 ulike modeller (med stort og smått) – selv om de 7 hyppigste modellene utgjorde 50% av alle harddiskene.

januar 2010 TDT4285 Planl&drift av IT-syst Case 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? Brukerstøtte ifm en feil som en bruker har meldt inn, og sier ”Det ordner seg når maskinen blir bootet”. Brukeren tenker: ok, jeg får vente til de kommer og booter. Drift: nå vet brukeren at han skal boote sin egen maskin – case closed.

januar 2010 TDT4285 Planl&drift av IT-syst Case 8: Katastrofe- planlegging 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? Case: Hva vil NTNU gjøre dersom man kommer på jobb en mandag morgen og finner at Gløshaugen har sklidd ut og ligger på 200 meters dyp nesten ute ved Munkholmen?

januar 2010 TDT4285 Planl&drift av IT-syst Case 9: Bevare eller forbedre? Skal ressursene brukes på vedlikeholdsarbeid (dvs å holde ting flytende) eller å forbedre, øke og fornye systemet (dvs at man kommer videre)? En bruker påpeker en feil i et program. Det er korrigert i neste versjon. Du vurderer å finne en work-around, men velger å oppgradere. Dagen etter kommer ti brukere med problemer som er relatert til oppgraderingen.

januar 2010 TDT4285 Planl&drift av IT-syst Case 10: Læ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? Et fly har styrtet, og det er mistanke om teknisk svikt. Alle andre fly av samme type blir satt på bakken inntil man får avklart de mistankene man har og/eller får sjekket de flyene som har fått midlertidig flyforbud.