====== Endringshåndtering ====== [[testlenker|Lenker til test før utrulling]] Utkast til endringsrutiner for met.no og NRK ved endringer som kan få konsekvenser for yr.no. To typer endringer: Endringer som medfører betydelig nedetid, og endringer med svært kort eller ingen nedetid. - Endringer m/ planlagt nedetid på over 2 minutter: * Tidsintervall for disse endringene er mellom kl. 01:00 - kl. 06:00 norsk tid. * Varsling pr. epost senest kl.12:00 dagen i forveien. Epost sendes til Erik Bolstad, nynett-devel, Roar Skålin.... - Endringer m/ planlagt nedetid på 2 minutter eller mindre: * Kan utføres når som helst på døgnet. * Varsling pr. epost senest 2 timer før endringen skal utføres. Epost sendes til Erik Bolstad, nynett-devel. \\ Varsling om endring skal inneholde: * Endringsbeskrivelse * Tidspunkt for endring * Forventet nedetid. * Worst-case beskrivelse ( inkl. estimat av nedetid ved tilbakerulling ). * Kontaktinfo ( mobiltlf. ) v/ oppdagelse av feil. Endringer bør planlegges slik at det vil gi minst mulig nedetid. Spesifisere hva man mener med nedetid: hele yr.no, hele yr.no utenom forsidene, wms-tjenestene, wscache.met.no ...osv. ===== Spørsmål ===== Spørsmål som Driftsgrupper må kunne gi Driftsstyret svar på før ny versjon kan bli installert: * Hva kan gå galt ved installasjon? ( -> ulike feilscenarier) * Hva kan gå galt etter intallasjon? Spørsmål som Driftsstyret? må finne svar på: --- En endring er å sette i drift en annen versjon av en komponent i løsningen eller å forandre på konfigurasjonen for en komponent. Spørsmål som driftsstyret må finne/vedlikeholde svar på: * Hva er kriteriene for at vi sier at endringen gikk bra? * Hva er ønsket funksjonalitet og kvalitet? * Hvem skal varsles og hvordan? * Hvem beslutter at en endring kan gjennomføres? * Hva er regnet som klasse A, B og C-feil for yr.no * Hva er kjente/erfarte symptomer ved feil? Spørsmål som driftsgruppa må kunne svare på (og som utviklerne derfor må tenke på): * Hvordan verifiserer vi at endringen gikk bra? * Hva kan gå galt i forbindelse med endringen? * Hvordan vil ulike feilscenarier bli håndtert? * Hvordan er ulike feilscenarier søkt avverget? * Hvordan er det undersøkt om tidligere kjente feil ikke er tilstede? * Hvordan er det undersøkt om ønsket funksjonalitet er tilstede med ønsket kvalitet? * Hvordan er endringen planlagt gjennomført? * Hva er kriteriene for å rulle tilbake? * Hvem beslutter at man eventuelt skal rulle tilbake? * Hvordan er eventuell tilbakerulling planlagt gjennomført? * Hvordan er tilbakerulling testet? * Hvordan verifiserer vi at eventuell tilbakerulling gikk bra? * Hva er kjente feilsituasjoner/-kilder? * minne fullt på server * minnelekasje * treg backend * Hva gjør vi for å detektere kjente/erfarte symptomer på feil? Årsak -> symptom -> fix Generelt: * Hvordan fjerne alle varslene ved behov?