Forelesning 2: Utfordringene

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

2. Historikk Tynne klienter 2010 IBM-PC 2000 1990 Mainframes Servicecenter 1980 IT-avd Bærbare 1970 EDB-avd 1960 ”Internettet” Regnesentre Hjemmemaskinen Minimaskiner TDT4285 Planl&drift av IT-syst

3. 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 • Grenseflater mot mange andre fag TDT4285 Planl&drift av IT-syst

4. Hva er IT-drift? Ressurs- utnytting Indirekte oppgave 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 Infra- struktur Programvare Parallelle systemer TDT4285 Planl&drift av IT-syst

5. Systemadministrators roller? Produkt- finneren Nisje- område- eksperten Brann- mannen Hjelperen Prosjekt- lederen Etterforskeren Bruker- forkjemperen Installatøren Vedlikeholderen Nattevakta Leverandør- kontakten Policy- skriveren 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 Selgeren Hønemor Overvåkeren Fikseren Laboratorie- teknikeren Helten Detektiven Team-med- arbeideren Løsnings- designeren Innkjøperen Lederen Teknokraten Avstrafferen Lytteren Tilretteleggeren Syndebukken TDT4285 Planl&drift av IT-syst

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

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

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

9. 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 TDT4285 Planl&drift av IT-syst

10. Problemstilling 2:Skalerbarhet • Kapasitetsplanlegging • Testing opp mot antatt full last • ”Organisatorisk” skalerbarhet • Monitorering • Kan ta ut stordriftfordeler TDT4285 Planl&drift av IT-syst

11. 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 TDT4285 Planl&drift av IT-syst

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

13. 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. Case 1:Måldefinisjon TDT4285 Planl&drift av IT-syst

14. 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. Case 2:Feilsøking og -retting TDT4285 Planl&drift av IT-syst

15. 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. Case 3:Endringer TDT4285 Planl&drift av IT-syst

16. 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. Case 4:Sikkerhet TDT4285 Planl&drift av IT-syst

17. 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. Case 5:Divergens TDT4285 Planl&drift av IT-syst

18. 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. Case 6:Kompleksitet TDT4285 Planl&drift av IT-syst

19. 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 finner en som brukeren 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. Case 7:Kommunikasjon TDT4285 Planl&drift av IT-syst

20. 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? Case 8:Katastrofe-planlegging TDT4285 Planl&drift av IT-syst

21. 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. Case 9: Bevare ellerforbedre? TDT4285 Planl&drift av IT-syst

22. 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. Case 10:Læring TDT4285 Planl&drift av IT-syst