Page Comparison

🙅‍♀️ Fault

Describe how the change that was implemented didn't work as expected. If available, include relevant data visualizations.

USIT (UiO) hadde implementert en endring på sine servere:

Dette kommer av en generell innstramming av tilgang til UiO-servere fra omverdenen og inngående ssh er sperret. Vår kartlegging har dessverre ikke avdekket at w3prod-datasync02 ville bli rammet av endringen.

🥏 Impact

Describe how internal and external users were impacted during the incident. Include how many support cases were raised.

Alle 25 institusjoner som benytter integrasjonen var berørt. Sinne gjennomførte overføring til Canvas var 2022-03-28 kl 10:08 (altså dagen før).

Tjenesteansvarlig mottok 3 meldinger per e-post direkte. Ba de også melde til FS-support.

👁 Detection

Report when the team detected the incident and how they knew it was happening. Describe how the team could've improved time to detection.

Oppdaget ved melding fra sektoren. Den første meldingen om feil ble først lagt merke til ca kl 13:30.

🙆‍♀️ Recovery

Report how the user impact was mitigated and when the incident was deemed resolved. Describe how the team could've improved time to mitigation.

Feilen gjorde at 25 Canvas-institusjoner ikke fikk endringer fra FS inn i LMS i nesten et helt døgn.

Feil ble oppdaget tidlig av enkeltinstitusjoner, men det ble ikke klart at dette var en systematisk feil før flere timer etterpå.

Feilen ble ganske hurtig rettet da dette ble påpekt.

Bedre mulighet til å avdekke at dette var en systematisk feil som rammet alle 25 institusjoner, kunne redusert tiden man var uten FS-integrasjon til Canvas.

⏲ Timeline

Detail the incident timeline using UTC to standardize for timezones. Include lead-up events, post-impact event, and any decisions or changes made.

Kl. 09:49: Problemet ble oppdaget av USN som meldte fra om at de ikke hadde tilgang til serveren for å sjekke XML-eksport

Kl. 12:35: UiT melder om samme problem og spør hva som er rett kanal å varsle (tjenesteansvarlig LMS eller FS-support)

ca. kl 13:30: Tjenesteansvarlig verifiserer feilen (får ikke koblet til). Tjenesteanvarlig spør så Team lead på Studiegjennomføring om det er kjent til noen endringer hos USIT. Blir anbefalt å dobbeltsjekke med Kai.

kl. 13:42: Tjenestenansvarlig sender spørsmål (videresendt informasjon innmeldt fra sektor) til Kai om server. Kai melder om at han har tilgang, men sender straks sak til USIT.

kl 13:43: Tjenesteansvarlig sender varsel til sikkerhet@sikt.no og Marius Eide som beskrevet på Innsikt (fikk ikke respons på denne). Tjenesteansvarlig svarer også på henvendelsene fra sektoren og varsler på Teams for

kl: 14:00: Tråd startet

Kl. 14:30: Tjenesteansvarlig kontakter produkteier for FS for å etterspørre purring på USIT. Henvises til Thor Anti.

Kl. 14:33: Tjenesteansvarlig poster informasjon om at integrasjonen er nede i kanalen Change, Incident, Problem og Request i Teamet for

Kl. 14:36: Tjenesteansvarlig legger til Thor i

Kl 14:39: Tjenesteansvarlig kontakter leder av Servicesenteret for å melde fra om problemet (grunnet manglende reaksjon på post i Teams-kanal) og at det kanskje er lurt å vurdere en driftsmelding eller lignende.

ca Kl. 14:40: Tjenesteansvarlig etterspør på

Kl. 14:54: Leder av Servicesenteret ber om at Tjenesteansvarlig lage incident i RT. Tjenesteansvarlig svarer et situasjonen er hektisk og prioritet er å sikre at problemet blir sett på samme dag, og siden man ikke har erfaring med å registrere det i RT blir det ikke prioritert i denne omgang.

Kl. 15:00: Driftsmelding publisert på https://www.fellesstudentsystem.no/driftsmeldinger/2022/2022-03-29-canvas-integrasjon-nede.html

Kl. 15:16: USIT svarer om at de har gjennomført en endring og sperret inngående SSH, som er årsaken. De ser på løsning.

Kl. 15:16-17:15: Dialog frem og tilbake med USIT frem til det er verifisert at alle har fått gjenopprettet tilgang og import til Canvas går som normalt.

🔎 Five whys root cause identification

Run a 5-whys analysis to understand the true causes of the incident. 

1. USIT ønsker strengere sikkerhet for sine servere

2. USIT sperret for inngående SSH fra eksterne maskiner (ikke UiO-driftet), ble ikke kommunisert til riktige mottakere i Sikt/sektor

3. Ikke grundig nok kartlegging av hva som vil påvirkes

4. Mangelfull kommunikasjon(?)

5. Driftsavtalen/-modellen (?)skaper siloer

🤔 Lessons learned

Describe what you learned, what went well, and how you can improve.

Mangler oversikt over:

• Hvem Trenger bedre koordinering med driftsleverandør ved større endringer

• Mer detaljert prosedyre for hvem man skal kontakte (hvem gjør hva i Sikt; hvem i FS spør man om X?konkrete tema, hvem kobler på relevante ressurser?, hvem kan ringe USIT?, hvem kan poste driftsmelding?, hvilke kanaler skal man varsle?…)Hvem kan bistå?varsle…)

• Hvilken (og hvem sin) prosess skal man følge ?i Sikt - på mer detaljert nivå enn beredskapsplan:

  • Hvor man skal rapportere og hvordan (sikkerhet, avviksskjema, incidentregistrering i RT) - ingen sammenheng og ingen kommunikasjon på tvers

✍ Follow-up tasks

List the Jira issues created to prevent this class of incident in the future. Note who is responsible, when they have to complete the work, and where that work is being tracked.

1. Sjekke om Instructure kan få til en automatisk varsling av om import ikke går gjennom

2. Vurdere om institusjonene skal ha mer innsikt i driftsmeldinger i Sikt

3. Oppfølging med USIT om kartleggingsprosess og prosess for varsling av endring

4. Få én arbeidsflyt/prosess for incidents i Sikt, fremfor at hver avdeling har sin egen