Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
yr:endringshaandtering [2019-09-10 12:10:23] janip |
yr:endringshaandtering [2022-05-31 09:29:32] (current) |
||
---|---|---|---|
Line 2: | Line 2: | ||
====== Endringshåndtering ====== | ====== Endringshåndtering ====== | ||
- | Innholdet slettet | + | [[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, | ||
+ | |||
+ | - 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 | ||
+ | * 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, | ||
+ | |||
+ | |||
+ | ===== 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? | ||
+ | * Hva kan gå galt etter intallasjon? | ||
+ | |||
+ | Spørsmål som Driftsstyret? | ||
+ | |||
+ | |||
+ | --- | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | * 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/ | ||
+ | |||
+ | 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/ | ||
+ | * minne fullt på server | ||
+ | * minnelekasje | ||
+ | * treg backend | ||
+ | * Hva gjør vi for å detektere kjente/ | ||
+ | |||
+ | Årsak | ||
+ | |||
+ | Generelt: | ||
+ | |||
+ | * Hvordan fjerne alle varslene ved behov? |