IT Service Management Forelesning uke 11 Innhold Release & Deployment Hensikt og mål Lage klare og forståelige utrullingsplaner så kunder og foretaket kan legge sine aktiviteter etter disse. Sørge for at nye versjoner kan bli bygget, installert, testet, og rullet ut effektiv og etter planlagte tidspunkt. Typer av utrulling Big Bang vs. Inkrementell. Push & Pull. Automatisert vs. Manuell. Big bang vs Inkrementell Big bang utrulling er når man installerer den nye versjon på alle enhetene i en stor oppgradering på relativ kort tidsperiode. Inkrementell utrulling er når man bruker en lengre tidsperiode på å ta installasjonene enkeltvis eller i mindre grupper av gangen. Big bang -utrulling Brukes helst ved innføring av veldig viktige tjenester eller oppgraderinger (alle eller ingen) Krever mye mer testing og verifisering før utrulling. Gir høyere risiko for feilsituasjoner Krever bedre og mer planlagte tilbakerullingsplaner. 1
Kan gi betydelig høyere press på Service Desk i en periode. En prosjekt som bruker big bang vil kunne ta like lang til som et som bruker inkrementell utrulling, men brukeren oppfatter det ikke slik. Inkrementell-utrulling Gir en tryggere men lengre utrulling, siden feil kan oppdages og rettes før de omfattes så mange brukere. Gir mulighet til å optimalisere i selve utrullingsfasen. Siden den gir lengre utrullingsperioder kan den oppfattes som ineffektiv og treg av brukere (og ledere) Andre inkrementelle modeller Deler av tjenesten rulles ut til alle i faser inntil hele tjenesten er rullet ut. Lokasjon for lokasjon (Oslo, Bergen, Gjøvik, Trondheim), avdeling for avdeling (IT, personal, økonomi, salg). Maskinvareoppgradering, Brukeropplæring, så Programmvareutrulling Push vs Pull Push utrulling er når en sentral enhet tvinger på og dytter en installasjon ut til klienten. Pull er når må gjør en pakke tilgjengelig sentralt, men klienten selv må initiere selve utrullingen. Push-utrulling Gir en bedre kontroll på hvem som får hva til enhver tid. Stiller høyere krav til styring på selve klienten (som mange ikke liker) Gir mulighet til å styre oppgraderingen til da det passer best for systemet (f.eks. natt). Kan være en utfordring på klienter som ikke følger standard, eller sjelden er online på LAN et (mobile brukere). Gir brukeren inget valg for når en oppgradering passer i timeplanen. Pull-utrulling Kan være veldig uforutsigbar både på lengde, tidspunkt og mengde. Kan gi stormer av oppgraderinger på gitte tidspunkt (f.eks. alle oppgraderer samtidig mandag kl 9) Noen klienter og brukere oppgraderer aldri uten å bli tvunget. 2
Push/Pull kombinasjon Et alternativ kan være å kombinere Push/Pull En bruker får lov å selv initiere installasjonen i en periode, men installasjonen tvinges over etter en viss dato. En bruker får et spørsmål om man ønsker å utføre en viss installasjon, og kan avvise inntil tre ganger, før den tvinges. Automatisert vs Manuell Automatisert utrulling foregår helt uten interaksjon verken fra admin eller bruker. Manuell installasjon kan være komplett manuell eller semi-manuell (f.eks. autoinstallasjon m/manuelle innstiller etterpå) Automatisert utrulling When in doubt: Choose Automation! Automatisert utrulling gir en konsistent, repeterbar, og etterprøvbar installasjon, som er enklere og feilsøke. En automatisert utrulling føles mye bedre og profesjonelt ut av brukeren. Manuell utrulling Det vil kunne finnes tilfeller (usannsynlig men umulig å utelukke) der en automatisert utrulling ikke er mulig enten pga. av størrelsen på utrullingen eller tidspress Merk at manuelle utrullinger er notorisk sårbare for feil og ineffektivitet. Manuelle utrullinger skalerer ikke, og vil fort kunne virke som en flaskehals for hele IT-organisasjonen. Release & Deployment (modeller) Testing og bygging av pakker bør gjøres i et kontrollert testmiljø som er så likt som overhodet mulig produksjonsmiljøet. En permanent fysisk eller virtuell testlab er det beste. Husk at test og produksjonsmiljø alltid vil ha forskjeller som man må ta hensyn til. 3
Release & Deployment (planer) Hva er avhengighetene? Hvem er brukerne? Er lokale faktorer? Hvor er brukerne? Hvem trenger å være informert? Når må utrullingen ferdigstilles? Hva er de kritiske suksessfaktorene? Hvordan gjør vi tilbakerulling? Pass/Fail kriterier Planlegg tidlig hva en ny release absolutt må passere av forutsetninger for å kunne godkjennes for produksjon. F.eks: Service Desk har ikke kompetanse eller resurser til å supportere de nye tjenesten eller versjonen. Maskinvarekrav. Må fungere på maskiner med 512MB RAM og 20GB disk. Hele installasjonen må fullføres på maks 20 minutter. Tjenesten må fungere funsjonslikt på både Linux, Mac, og Windows. Pilottesting Pilottesting er et meget nyttig hjelpemiddel. Velg en gruppe brukere som representerer et utsnitt av brukermassen. Ikke ha for stor pilotgruppe, det hindrer raske endringer. Såkalte vanskelige brukere er verdt sin vekt i gull når det kommer til pilottesting. Piloter bør være mer privilegerte enn vanlige brukere, og bør ha mer direkte kommunikasjon mot prosjektgruppa. Tving dine IT-ansatte til å være piloter. Opplæring av brukere Opplærling av brukere er en del av utrullingen, glem ikke den menneskelige faktoren. Suksess eller fiasko kan ofte finnes igjen i hvor god opplærlingen har vært. Ha en klar plan for hvordan opplæring skal gjøres allerede under planleggingen. Opplærling kan være alt fra enkel brukerdokumentsjon til obligatoriske kurs. 4
Verifisere utrullingen Verifisere at brukerne får tilgang på tjenesten. Verifisere at tjenesten er levert etter avtaler og bestilling (SLA, RFC) Verifisere at dokumentasjonen er oppdatert og tilgjengelig. Verifisere at konfigurasjondatabasene er oppdatert. Early Life Support I begynnelsen av utrullingen bør de ansvarlige prosjektet selv ta ansvar og aktivt delta i å løse saker med Service Desk personale. Etterhvert som man har verifisert at utrullingen har gått som planlagt, leveres supporten over til Service Desk og vanlig drift. En vanlig fallgruve er at de ansvarlig for utrulling skriver fra seg ansvaret for support. Utrulling av arbeidstasjoner En arbeidstasjon er et stykke datamaskin som i hovedsak er disponert av en person. Det kan være en bærbar, eller stasjonær PC. Man kan definere statusen til en arbeidstasjon på følgende måte: Ny Helt ny maskin uten noe konfigurert operativsystem Ren Operativsystemet er installert, men ingen spesiell programvare eller konfigurasjoner er gjort Konfigurert Arbeidstasjonen er ferdig konfigurert med riktig programvare og klar til bruk. Ukjent Arbeidstasjonen er miskonfigurert eller utdatert. Av Arbeidstasjonen er tatt ut av drift og er avslått. Livsyklusen til arbeidstasjoner Det er flere måter å komme til de ulike stadiene i livsyklusen. Initiell installering og konfigurering er som oftest en automatisert en-stegsprosess. I løpet av levetiden skjer de en stadig forringelse som setter arbeidstasjonen i en ukjent tilstand, som vanligvis vil tilbakestilles med debugging. Fra tid til annen vil de være best å reinstallere hele arbeidstasjonen. Enten pga. for lang debug - tid, eller at det skal betydelige endringer på installasjonen. Til slutt er maskinen definert for som gammel og fases ut. Enten pga. for lave maskinkrav, for mange feil, eller utløpt garantitid. 5
Repeterbare installasjoner Med en automatisert prosess vet vi at vi leverer hver eneste arbeidstasjon i en ferdig konfigurert tilstand. Manuelle endringer er notorisk sårbar for feil og mangler. Minimum tre ting bør gjøres helautomatisert: Initiell installasjon av operativsystem og programvare Oppdateringer av systemprogramvare og applikasjoner. Konfigurasjon av nettverskinnstillinger. Automatisering kan være vanskelig å forsvare i små organisasjoner, men konsekvensene kan være katastrofale senere om den begynner å vokse. Standardisering vs brukerfrihet Fra et rent kostperspektiv vil det virke effektiv å standardisere og styre all maskin og programvare. Brukere kan faktisk bli forhindret fra å være så effektive som mulig ved for sterkt styring. For mye frihet vil kunne skape kaos, økt arbeidsmengde, og uforutsigbarhet. Balanse er viktig. Utfordringer med mobile brukere Mobile brukere (selgere, ledere, prosjektledere) utgjør en ekstra utfordring. Mobile brukere har det alltid travelt, er så og si aldri på lokal LAN-forbindelse, og gjør aldri oppdateringer. I tillegg er avbrudd av tjenester mye større krise for mobile brukere. Vurdèr VIP -tjenester for visse mobile brukere. Utrulling og oppgradering av servere Fundamental regel: Alle tjenester som fungerer før oppgradering skal også virke etter oppgradering. Noen ganger vil en oppgradering legge til til funksjonalitet, men den bør helst ikke ta vekk noen funksjonalitet. 6
Sjekkliste for serveroppgradering 1. Lag en komplett sjekkliste for hver eneste server Hvilke tjenester går på serveren? Hvem bruker disse tjenestene? Hvilken programvare leverer disse tjenestene? 2. Verifiser at hver programpakke virker på det oppgraderte systemet, og hvis ikke lag en oppgraderingsplan også for programvaren. 3. For hver tjeneste, lag en test for å verifisere funksjonalitet. 4. Lag en konkret back-out plan, men helt spesifikke triggere. 5. Finn et oppgraderingstidspunkt. 6. Annonser oppgraderingen. 7. Før testene like før oppgraderingen for å verifisere at de fortsatt er riktige 8. Steng ute brukerne! 9. Gjør oppgradering (helst med noen som kikker deg over skulderen). 10. Gjenta testene, og verifiser at alle tjenesten virker etter oppgraderingen. 11. Hvis testene feiler, eller andre triggere utløses, gjennomfør back-ut planen 12. Slipp tilbake brukerne. 13. Kommuniser oppgraderingen/back-out til kundene (brukerne) 14. Gjennomfør en analyse over hva som gikk bra eller galt. Software for release and deployment Det finnes en utrolig mengde programvare innen denne kategorien, noen eksempler er: Microsoft Active Directory (Windows) Microsoft System Management Service (Windows) Intel LANdesk (Windows) Novell ZENworks (cross-platform) WPKG (Windows) cfengine (Unix) Apple Remote Desktop (OSX) IBM Tivoli (cross-platform) 7