Perustiedot ja osallistujat

Aika: Torstai 17.11.2022 klo 12:30-13:30

Paikka: D250, Mukkulankatu 19, Lahti (https://360.lab.fi/mukkulankatu/D250)

Osallistujat:

Korkeakoulut:

  • Sami Ahlgren, Laurea
  • Juha Aliorvanen, JY
  • Tommi Ekholm, HY
  • Ilona Junninen, JY
  • Jouni Penttinen, JY
  • Stina Westman, XAMK

Digivisio:

  • Jaakko Marin

SMO:

  • Jussi Vestman
  • Anttoni Lehto
  • Anna Luoma
  • Marko Memonen
  • Maarit Saaresto

CSC:

  • Antti Mäki
  • Hanna-Mari Puuska

SMO:n esitys keskustelun pohjaksi

Tavoite

Lopullisena tavoitteena on toteuttaa Digivision arvoverkossa toimiva häiriöhallinnan (erityisesti tietoturvapoikkeamatilanteiden) hallinnan toimintatapa.

Työpaja toimii myös prosessikehityksen työpajatoiminnan metodipilottina.

Tavoitteena on selvittää:

  • Häiriöhallinnan nykytilan muodostamat reunaehdot Digivision häiriöhallinnalle
    • korkeakoulujen, toimittajien ja CSC:n olemassa olevat toimintatavat
  • Häiriöhallinnan (ja erityisesti Major Incident Management) tapausten
    • viranomaisvelvoitteet, -ohjeet ja -suositukset
    • prosessin pääkohdat, roolitus ja vastuut, sidosryhmät
  • Käytännön seuraavat askeleet?
    • prosessimäärittelyt, toimintakäsikirja
    • harjoitustoiminta

Läpivienti

AikaAsia
5 minTyöpajan avaus
  • Palveluintegraattorin työpajatoiminnan tausta ja tavoitteet
  • Osallistujien pikaesittelyt
5 minHäiriöhallinnan vastuunjako9 Häiriöidenhallinta ja palvelupyyntöjen hallinta Digivisio2030
5 minHäiriöhallinnan looginen prosessikuvausHäiriönhallinnan ja palvelupyyntöjen hallinta
5 minLaajavaikutteisen häiriön hallinnan prosessi
  • Laajavaikutteisen häiriön prosessikaavion läpikäynti
  • Viranomaisohjeet (Vahti)
5 minPalveluintegraattorin toimintakäsikirja laajavaikutteisessa häiriössä9. Häiriöidenhallinta ja palvelupyyntöjen hallinta - Laajavaikutteisten häiriöiden hallinta
5 minTapaustutkimus: häiriö Tarjottimen tunnistusratkaisussaSkenario 1: Tunnistautuminen jatkuvan ja joustavan oppimisen tarjottimeen ei toimi
20 min

Skenaarion käsittely ServiceDeskin näkökulmasta (pienryhmissä, mikäli tarpeen)

Paperille tulostettu A3-kokoinen prosessikaavio

10 min

Yhteenveto ja lopetus klo 13.25 mennessä


Muistiinpanot

  • Marin: Peruskysymyksenä, mihin häiriöilmoituksen tulisi saapua?
  • Penttinen: Käyttäjä ei välttämättä tiedä mihin laittaa tiketin ja se voi mennä mihin vaan. Epävarmaa myös, osataanko sitä laittaa oikeaan paikkaan eteenpäin ensimmäisestä paikasta.
  • Mäki: Asiat tulevat usein esiin ensin somen kautta.
  • Westman: Silloin tieto menee nopeasti sinne, joka palvelun omistaa.
  • Aliorvainen: Kuka on isäntä välitysratkaisun toimittajalle?
  • Mäki: Palveluintegraattori.
  • Aliorvainen: Pieni asia, mutta "tunnistautuminen"-sana pitäisi muuttaa "kirjautumiseksi".


  • Westman: Missä vaiheessa kirjautumisongelman tieto tulee sellaiselle taholle, joka tunnistaa ongelman oikein? Mistä tiedetään kuka on oikea taho korkeakoulussa?
  • Marin: Opintoasiain vai IT:n servicedesk? Tarkentavia kysymyksiä häiriön luonteesta tarvitaan ja niiden avulla asian tulisi optimaalisesti mennä eteenpäin.
  • Aliorvainen: Oman korkeakoulun häiriötiedottamisen malliin (jos sellainen on valmiina) tämä voisi periaatteessa tuoda vain yhden stepin lisää: ota yhteyttä SMO:hon. Parhaimmillaan SMO:ssa lähde- ja kohdejärjestelmien tilannekuva → konfiguraationhallinta
  • Marin: Miten Helsingin yliopistossa nähdään?
  • Ekholm: Esitetty prosessi ei vaikuta eroavan normista juurikaan. Tukiwikissä on yhteystiedot, jossa listattuna mihin otetaan yhteyttä. Käytännössä korkeakoulun SD vastaisi: soittakaa Digivisioon.
    • Marin: Ja soittajille vastattaisiin, että tästä on tehty tiketti ja asiaa viedään eteenpäin.
  • Ahlgren: Yhdyn aikasempiin, mutta käyttäjät eivät välttämättä osaa ottaa yhteyttä mihinkään servicedeskiin. Jos ottaa yhteyttä ihmiseen, joka on kiinni kokouksessa tai muualla asia voi siksikin seistä.
  • Penttinen: Lähtökohtaisesti ongelma, etä mihin ensimmäiset pyynnöt menevät eri/vääriin paikkoihin, jolloin kokonaiskuvaa on vaikea hahmottaa jo heti alkuvaiheessa.
  • Aliorvainen: Eskaloinnin hitaus haaste; jos yhteydenottoja tulee moneen eri paikkaan, ei välttämättä tunnisteta heti/nopeasti häiriön laajuutta.


  • Westman: Kuka siis kaaviossa on se, joka tunnistaa että kyseessä on laajavaikutteinen häiriö? Jokainen yksittäinen korkeakoulu erikseen vai yhteinen SMO? Mikä on SMO:n rooli tunnistaa, että koko korkeakoulujen kentässä on käynnissä laaja poikkeama/häiriö?
  • Saaresto: Tässä kuvasssa ei ole monitorointia kuvattu. Tässä ollaan jo tunnistettu häiriötilanne. Kuvassa olisi hyvä huomioida näkymä, kuinka monesta korkeakoulusta kyseinen case on tunnistettu. Jos kyseessä ei major incident, niin todennäköisesti katsotaan lokaalimpaa ratkaisua, eikä eskaloida DV:n SD:n tasolle. (Tästä löytyy toisesta, värillisestä kuvasta maininta presentaatiosta.)
  • Mäki: Takaisinkytkentä ja viestiminen myös muille korkeakouluillen on olennaista, jotta tiketti/tilanne on eskaloitu ja määritelty laajamittaiseksi.


  • Vestman: MInkälaisia odotuksia teillä on palveluintegraattorilta esim. välineiden ja toimintatapojen suhteen?
  • Ahlgren: Järjestelmän pitäisi pystyä poimimaan viesti siitä, että kyseessä on yhteinen ongelma → näkymä tähän tärkeä.
  • Penttinen: Sekä sähköpostinotifikaatio että yhteinen kuvaus tapahtuneesta.
  • Marin: Digivision kokonaisportaalin kautta on mahdollista tarjota kuva korkeakouluille.
  • Vestman: Turha juoksentelu korkeakouluissa pitäisi katkaista mahdollisimman lyhyeen, voidaanko keskitetystä suunnasta jotenkin tukea?
  • Ahlgren: Tieto olisi hyödyllistä kyetä luokitella, eli minne korkeakoulun sisällä häiriön tiedote kannattaa jakaa.
  • Penttinen: Oma häiriöprosessi tietenkin olemassa, mutta olisi mukavaa jos olisi valmista viestintämateriaalia tilannekuvan synnyttämiseen. Samalla viesti olisi näin yhtenäinen kaikissa korkeakoulussa. 
  • Ekholm: Esim. viestinä, että "jotain on rikki ja tiedotamme seuraavan kerran esim. klo 14.00", ja silloin sitten tiedotetaankin. Korkeakoulujen ei myöskään silloin tarvitse olla jatkuvasti päivittelemässä sitä, onko tullut lisätietoa, ja tukiajat tähän viestiin myös mukaan.
  • Westman: Aiempiin tilanteisiin viitaten tyypillisiä jatkokysymyksiä ovat olleet: Keihin kaikkiin tämä vaikuttaa? Mihin toimintaprosesseihin tämä meillä liittyy? Jonkinlainen linkki pitäisi olla palvelukuvauksessa ja palvelutasoon viittaaviin vaikutuksiin. Palvelukatalogiin olisi hyvä saada näkymä korkeakouluille, jotta asianomistajat saavat siellä tiedon (mihin palveluihin häiriö kulloinkin vaikuttaa). Pitää olla löydettävissä häiriöviestinnän träkistä, mihin palveluun tämä häiriö vaikuttaa (eli tiivistetty palvelukuvaus, mihin nyt ei pääse käsiksi).
  • Penttinen: Sähköpostiosoitteet eri osiin korkeakoulua, osoitteet tiedossa integraattorilla. Emme toimisi siten enää sisäisenä eskalaattorina – tähän toki vaaditaan tietämystä paikallisesta ekosysteemiviidakosta. Mielummin enemmän tietoa jakoon kuin vähemmän, erityisesti major incident -tilanteessa.

Tiivistelmä ja päätelmät

  • Lähdejärjestelmäviidakko + palvelupisteviidakot X 38 korkeakoulua –> myös (varsinkin viestinnälliset) takaisinkytkennät saatava toimimaan, jos/kun häiriöt eivät heti löydä oikeaa ratkaisukanavaa
    • korkeakouluilla ei ole näkymää koko kenttään, jolloin SMO:n täytyy tietää palvelujen keskinäisriippuvuuksista ja häiriöiden vaikutuksista → 
    • prosessin pitäisi heijastaa managerointia SMO:n taholla, jotta asia olisi jossain hallussa ja tilannetta saataisiin parannettua 
    • rooli- ja yhteyshenkilömatriisin (https://wiki.eduuni.fi/x/F6ocEw) yhdistyminen konfiguraationhallinnan prosessiin olennaista
  • Paikalliset ekosysteemiviidakot hyvä olla palvelunhallintatoimistolla hallussa, ei vain DV:n palvelut. →  2023-XX-xx työpaja korkeakoulujen palveluportfolioista ja arkkitehtuurikuvauksista
    • Minkäläinen näkymä korkeakoulujen sisäisiin insidenttiluokituksiin ja järjestelmiin on mahdollinen?
    • Palveluintegraattorin toiminnan rajan toisella puolella olevien riippuvuuksien ymmärtäminen olennaista ja tuottaisi korkeakouluille lisäarvoa
      • käsitys syntyy ja tuottaa signaaleja myös häiriönhallinnan prosessin ulkopuolelle muihin prosesseihin
  • SMO:ssa tarkastetaan häiriön luokittelu laajamittaisen häiriön suhteen, ennakoivaa dataa on monitoroinnin ja ongelmatietokannan kautta.
    • Päätöksenteko major incidentin määrittelyn suhteen mietittävä
    • Auttaisi, jos korkeakouluissa tunnistetaan, että tässä on tekeillä jotain isompaa ja ilmoitetaan Digivision service deskiin. → Nostetaan esille työpajassa: 2023-XX-xx Muutoksenhallinnantyöpaja ja muutoshallinta prosessissa: 12 Muutoksenhallinta
  • Olisi hyödyllistä laatia esimerkkejä käyttötapauksista.
  • Tietosuojahäiriön ollessa kyseessä tiedon tulisi kulkea myös rekisterinpitäjälle.
  • SMO:n tulee pystyä laatimaan viestintämateriaalia tilannekuvan synnyttämiseen korkeakouluissa, samalla viesti olisi näin yhtenäinen kaikissa korkeakoulussa. 
  • Olennaista saada tieto laajamittaisesta häiriöstä luotettavasti ja nopeasti niille henkilöille, joiden toimintaan se vaikuttaa, eikä vain panostaa häiriön ratkaisemiseen – tässä auttaisi palveluportfolion palvelukuvaukset, joihin tulisi päästä muodossa tai toisessa aina käsiksi ja niitä pitäisi pystyä linkittämään viestintään. → 1 Portfolionhallinta
  • SMO:n tulee pystyä pohtimaan häiriöprosessia akuuttivaiheen ratkaisemisen suhteen (ml. viestintä), keskipitkällä aikavälillä liittyen ongelmanhallintaan (plus incident DB:n hyödyntäminen tilannekuvan synnyttämisessä) sekä raportointiin liittyen.

Taustamateriaali

Työhypoteeseja

  • CSC:n ja korkeakoulujen viestintäfunktioita kytkettävä mukaan MIM/Poikkeamatilanteiden hallintaan
  • Määriteltävä tarkoituksenmukaiset ja skaalautuvat kommunikaatiokanavat poikkematilanteisiin

Mahdollisia skenaarioita työpajoihin ja harjoituksiin


  • No labels

Korkeakoulutuksen ja tutkimuksen yhteistyöalustan tietosuojaseloste