Endringshåndtering

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?