User Tools

Site Tools


yr:endringshaandtering

Endringshåndtering

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.

  1. 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….
  1. 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?
yr/endringshaandtering.txt · Last modified: 2019-09-10 12:12:21 by janip