Muudatuste halduse eeskirja kinnitamine

KORRALDUS Tallinn 20.03.2025 nr 1-9/65 Muudatuste halduse eeskirja kinnitamine Tuginedes Tallinna Tehnikaülikooli põhikirja § 13 lõike 2 punktile 2: 1. Kinnitan muudatuste halduse eeskirja (lisatud). 2. Korraldus jõustub allkirjastamisel. (allkirjastatud digitaalselt) Tea Trahov kantsler  KINNITATUD kantsleri 20.03.2025 korraldusega nr 1-9/65 Muudatuste halduse eeskiri 1. Üldine 1.1. Muudatuste haldus (Change Management) on protsessi eesmärk on tagada, et infosüsteemides ja muudes infotehnoloogilistes varades tehtavad muudatused toimuvad sihipäraselt ja kontrollitult. Hästi juhitud muudatuste haldusprotsess tagab, et kõik muudatused on nõuetekohaselt dokumenteeritud, läbi vaadatud ning seotud osapooled on teavitatud. Samuti võimaldab see tuvastada ja maandada võimalikke riske, vähendades muudatustega kaasnevaid vigu ning tagades organisatsiooni sujuva ja tõhusa toimimise. 1.2. Muudatuste haldus kehtib kõikidele ülikooli infosüsteemidele ja infotehnoloogilistele varadele, aidates tagada nende töökindluse, turvalisuse ja jätkusuutlikkuse. Käesolev eeskiri lähtub üldiselt ITIL-i (Information Technology Infrastructure Library) põhimõtetest ja terminoloogiast, et tagada rahvusvaheliste heade tavade järgimine muudatuste halduses. 2. Muudatuste tüübid 2.1. Rutiinne tööülesanne (Operational Task or Routine Task) on IT-teenustega seotud korduv tegevus, mis ei mõjuta infosüsteemide või teenuste toimimist ega vaja muudatuste halduse protsessi läbimist. Sellisteks tegevusteks võivad olla näiteks tööjaama installeerimine kasutajale või standardsete tulemüürireeglite rakendamine vastavalt eelnevalt kinnitatud protseduuridele. Kuna rutiinsed tööülesanded ei mõjuta teenuste kättesaadavust ega lõppkasutaja kogemust, siis neid ei registreerita muudatusena. 2.2. Standardmuudatus (Standard Change) on eelnevalt heaks kiidetud, madala riskiga ja korduv muudatus, mis tugineb kindlaksmääratud ning testitud protseduuridele. Kuna standardmuudatusel on infosüsteemile või teenusele minimaalne mõju, ei vaja see eraldi kooskõlastamist, kuid selle registreerimine on kohustuslik. Näidetena võib tuua rutiinsed tarkvarauuendused, mille mõju on eelnevalt testitud ja teada. Tavamuudatus (Normal Change) on muudatus, mis ei ole standardmuudatus ega hädavajalik muudatus ning vajab enne rakendamist hindamist ja heakskiitu. Tavamuudatus võib omada infosüsteemile mõõdukat kuni suurt mõju, mistõttu määratakse selle riskitase muudatuste halduse protsessi käigus. Näiteks võib see hõlmata uue tarkvaramooduli juurutamist, serveri või võrgu konfiguratsiooni muutmist, mis mõjutab mitut süsteemi, või süsteemi versioonitäiendusi, millel on kasutajatele märgatav mõju. 2.3. Hädavajalik muudatus (Emergency Change) on kiireloomuline muudatus, mis on vajalik olulise intsidendi lahendamiseks või kriitilise riski maandamiseks, mille mittelahendamine võib põhjustada tõsiseid häireid ülikooli infosüsteemide või teenuste töös. Selliste muudatuste hulka kuuluvad näiteks kriitilise turvapaiga viivitamatu rakendamine või süsteemi taastamine tehnilise tõrke või turvaintsidendi järgselt. 3. Muudatuste protsess 3.1. Tavamuudatused 3.1.1. Tavamuudatuse taotluse pileti loomine ja esitamine 3.1.1.1. Tavamuudatuste halduse protsessi algatab ülikooli IT-osakonna töötaja või infotehnoloogilise vara omanik, koostades tava muudatuse taotluse (Request for Change – RFC) tugiportaalis (tööde halduslahenduses JIRA-s). Taotlus tuleb esitada vähemalt kolm tööpäeva enne muudatuse rakendamist, et tagada piisav aeg selle hindamiseks ja kooskõlastamiseks. 3.1.1.2. Tava muudatuse taotlus peab sisaldama järgmist teavet: 3.1.1.2.1. Muudatuse kirjeldus, prioriteet, mõju ja riskihindamine – Mida muudetakse ja miks see on vajalik? Milline on muudatuse kriitilisus (nt kriitiline, kõrge, keskmine, madal) ning kuidas see mõjutab infosüsteeme, teenuseid ja kasutajaid? Kuidas aitab muudatus parandada teenuseid, turvalisust või tööprotsesse? Millised on võimalikud riskid ja kuidas neid maandatakse?  2 3.1.1.2.2. Rakendamise, tagasipöördumise ja testimise plaan – Kuidas muudatus rakendatakse? Millised on selle läbiviimise etapid, ajakava ja vajalikud ressursid? Milline on tagasipöördumise plaan juhuks, kui muudatus tuleb tagasi võtta? Kuidas muudatust testitakse ning hinnatakse selle edukust? 3.1.1.3. Testimine ja valideerimine – kuidas muudatust on testitud ja kuidas hinnatakse selle edukust. 3.1.2. Tava muudatuse taotluse kinnitamine 3.1.2.1. Tavamuudatuse algataja koostab muudatuse taotluse ja esitab selle infotehnoloogilise vara omanikule kooskõlastamiseks. Vara omanik vastutab muudatuse mõju hindamise eest, veendumaks, et see vastab organisatsiooni tehnilistele, ärilistele ja infoturbe nõuetele ning ei tekita ootamatuid riske. 3.1.2.2. Kui muudatusel on oluline mõju infosüsteemidele, teenustele või kasutajatele, võib vara omanik kaasata täiendavaid osapooli, et tagada muudatuse sobivus kõigi seotud süsteemide ja protsessidega. 3.1.3. Tavamuudatuse taotluse üle vaatamine, ajakava kinnitamine ja ettevalmistamine 3.1.3.1. Kui tavamuudatuse taotlus on esitatud ja vara omaniku poolt kinnitatud, suunatakse see muudatuste haldurile ülevaatamiseks. Muudatuste haldur (IT kasutajatoe juht) kontrollib, kas taotlus vastab protsessinõuetele, on korrektselt vormistatud, kõik vajalikud kooskõlastused on tehtud ning riskihindamine on läbi viidud. 3.1.3.2. Kui taotluses esineb puudusi või puudub kriitiline teave, suunatakse see tagasi muudatuse algatajale täiendamiseks. Muudatuste haldur ei vastuta muudatuse sisulise õigsuse ega tehnilise põhjendatuse eest, vaid tagab, et muudatuse haldusprotsessi nõuded on täidetud ja kogu vajalik informatsioon on esitatud. Muudatuse sisulise täpsuse, vajalikkuse ja tehnilise teostatavuse eest vastutab muudatuse algataja ja vara omanik, kes peab enne taotluse esitamist tagama, et kõik tehnilised ja ärilised aspektid on põhjalikult läbi mõeldud. 3.1.3.3. Kui tavamuudatus vastab kõigile nõuetele, lisatakse see muudatuste ajakavasse JIRA keskkonnas. Muudatuste haldur vastutab ka muudatuste ajastamise kooskõlastamise eest, et vältida suuremate muudatuste kattumist ja süsteemi ülekoormamist. 3.1.3.4. Muudatuse elluviija ja vara omanik vastutavad muudatuse planeerimise ja rakendamise ettevalmistamise eest, järgides kinnitatud ajakava. Ettevalmistus hõlmab vajalike ressursside ja tööülesannete määramist, testimist ning tehnilise rakendamise planeerimist, et tagada muudatuse sujuv ja edukas elluviimine. 3.1.4. Muudatusest teavitamine 3.1.4.1 Muudatuste haldur (IT kasutajatoe juht) vastutab tavamuudatuse teavitamise eest, tagades, et kõik mõjutatud osapooled saavad õigeaegse ja piisava teabe muudatuse mõju ja ajakava kohta. Teavitamine toimub kokkulepitud teavituskanalite kaudu ning selle ulatus ja detailsus sõltuvad tavamuudatuse keerukusest ja mõjust. Muudatuste haldur hindab, milline teavitamisviis on kõige sobivam, et tagada selgus ja valmisolek kõikide seotud osapoolte jaoks. 3.1.5. Tavamuudatuse rakendamine ja tagasipöördumine 3.1.5.1. Tavamuudatus rakendatakse vastavalt eelnevalt kinnitatud rakendusplaanile, mis määrab kindlaks muudatuse teostamise ajakava, tegevused ja vastutajad. Tavamuudatus tuleb ajastada viisil, mis minimeerib mõju infosüsteemidele, teenustele ja kasutajatele, tagades võimalikult sujuva ülemineku. 3.1.5.2. Muudatuse teostaja vastutab tavamuudatuse elluviimise eest, tagades, et kõik tegevused viiakse läbi kooskõlas rakendusplaani ja ajakavaga. Rakendamise käigus tuleb jälgida süsteemi seisundit reaalajas, registreerida muudatuse teostamise käik ning kasutada võimalusel automatiseeritud monitooringulahendusi, et kiiresti tuvastada kõrvalekaldeid. Pärast muudatuse rakendamist peab muudatuse teostaja jälgima süsteemide ja IT-varade tööd, et tagada muudatuse stabiilsus ning reageerida operatiivselt tekkivatele probleemidele. 3.1.5.3. Kui tavamuudatus põhjustab ootamatuid probleeme või ei anna soovitud tulemust, rakendatakse eelnevalt määratletud ja testitud tagasipöördumise plaan. Tagasipöördumise kriteeriumid peavad olema määratletud tavamuudatuse taotluses ning nende täitmist hinnatakse süsteemi seisundi ja äriliste vajaduste põhjal. Tagasipöördumise otsustab muudatuse teostaja, lähtudes muudatuse taotluses kirjeldatud tingimustest. Kui muudatus mõjutab kriitilisi süsteeme või  3 kui tekib ebakindlus tagasipöördumise vajalikkuse osas, peab muudatuse teostaja konsulteerima vara omanikuga. 3.1.5.4. Kõik tavamuudatuse rakendamise ja tagasipöördumisega seotud tegevused dokumenteeritakse ning vajadusel eskaleeritakse vastavatele osapooltele. Mõjutatud osapooli teavitatakse muudatuse staatusest ja võimalikest kõrvalekalletest, et tagada selge kommunikatsioon ja võimalike probleemide kiire lahendamine. 3.1.6. Muudatuse edukaks tunnistamine ja sulgemine 3.1.6.1. Tavamuudatus loetakse edukaks, kui see on rakendatud vastavalt kinnitatud rakendusplaanile ning infosüsteemide ja IT-varade töö toimub ootuspäraselt. Kui muudatuse teostaja on veendunud muudatuse edukuses, märgitakse tavamuudatuse pilet teostatuks, misjärel saavad seotud osapooled automaatse teavituse muudatuse edukast lõpuleviimisest. 3.1.6.2. Suure mõjuga tavamuudatuste puhul võib enne lõplikku sulgemist kehtestada täiendava hindamisperioodi, mille jooksul jälgitakse süsteemi stabiilsust ja veendutakse, et muudatus on saavutanud soovitud tulemuse ilma ootamatute kõrvalmõjudeta. Hindamisperioodi lõppedes tehakse vajadusel täiendav ülevaatus ning dokumenteeritakse muudatuse lõplik mõju ja saavutatud tulemused. 3.1.6.3. Kui tavamuudatus ei anna soovitud tulemust või põhjustab ootamatuid probleeme ning on rakendatud tagasipöördumise plaan, jääb tavamuudatuse pilet avatuks. Sellisel juhul tehakse täiendav analüüs, et määrata probleemi põhjus ning kavandada uus muudatus vastavalt analüüsi tulemustele. 3.2. Standard- ja hädavalikud muudatused 3.2.1. Standardmuudatused 3.2.1.1. Standardmuudatused on eelnevalt heaks kiidetud, madala riskiga ja korduvad muudatused, mille teostamiseks on juba määratletud tööülesanne või töökäsk infotehnoloogilise varaga seotud JIRA projektis. Kuna muudatuse sisu ja vajalikud tegevused on tööülesandes kirjeldatud, ei looda eraldi muudatuse dokumentatsiooni. Standardmuudatuse algataja täidab JIRA piletis vajalikud muudatusega seotud väljad, mis tagab muudatuse registreerimise ja nähtavuse muudatuste kalendris, võimaldades paremat planeerimist ja jälgitavust ilma liigse halduskoormuseta. 3.2.1.2. Muudatuse teostaja vastutab muudatuse elluviimise eest ning dokumenteerib selle JIRA tööülesandes, tagades, et muudatuse töökäik ja olulised detailid on pärast teostamist kirjas. Vajadusel ajakohastatakse ka seotud dokumentatsiooni. Kui standardmuudatus ebaõnnestub või tekivad ootamatud probleemid, hinnatakse olukorda ning vajadusel eskaleeritakse muudatus intsidendiks. 3.2.2. Hädavajalikud muudatused 3.2.2.1. Hädavajalikud muudatused tehakse reaktiivselt kriitiliste intsidentide lahendamiseks, mistõttu on need tavaliselt seotud olemasoleva intsidendipiletiga JIRA-s. Kui muudatus on ellu viidud, dokumenteerib muudatuse teostaja või intsidendi lahendaja samas piletis, kirjeldades, mida muudeti ja kuidas muudatus rakendati. Vajadusel uuendatakse ka seotud süsteemide dokumentatsiooni, et tagada muudatuse hilisem leitavus ja jälgitavus ilma eraldi muudatuspiletit loomata. 3.2.2.2. Kui hädavajalik muudatus oli tingitud süsteemi tõrkest või turvariskist, võib muudatuste haldur või vara omanik algatada järelanalüüsi, et hinnata, kas tulevikus on võimalik sarnaseid intsidente ennetada.  4 4. Rollid ja nende ülesanded Roll Ülesanded ja vastutus Muudatuse algataja Koostab tavamuudatuse taotluse JIRA keskkonnas, kirjeldab muudatuse eesmärki, mõju ja riskihindamist ning esitab selle vara omanikule kinnitamiseks. Tagab, et taotlus on korrektselt vormistatud ja sisaldab kogu vajalikku informatsiooni. Infosüsteemi või Hindab tavamuudatuse mõju ärilistele, tehnilistele, infotehnoloogilise vara kasutajamugavuse, jõudluse ja infoturbe aspektidele. Kinnitab omanik muudatuse vastavuse organisatsiooni nõuetele ja vajadusel kaasab täiendavaid osapooli. Muudatuste haldur (IT Kontrollib, kas tavamuudatuse taotlus vastab protsessinõuetele ja kasutajatoe juht) kas vajalikud kooskõlastused on tehtud. Lisab muudatuse ajakavasse JIRA tööde halduslahenduses, koordineerib ajastamist ja teavitab osapooli. Tagab muudatuste protsessi pideva jälgimise ja parendamise. Muudatuse elluviija Rakendab tavamuudatuse vastavalt kinnitatud rakendusplaanile ja ajakavale. Jälgib süsteemi seisundit, registreerib muudatuse teostamise käigu ning kasutab vajadusel monitooringulahendusi. Vajadusel käivitab tagasipöördumise plaani ja ajakohastab dokumentatsiooni. 5. Järelevalve Muudatuste haldur teostab järjepidevat järelevalvet muudatuste halduse protsessi üle, tagades selle pideva jälgimise ja parendamise. Muudatuste haldur hindab regulaarselt muudatuste halduse protsessi efektiivsust ja vastavust organisatsiooni vajadustele. LISA 1 Näited muudatuste tüüpidest 1. Rutiinne tööülesanne (Operational Task or Routine Task) -Rutiinne tööülesanne on IT-teenustega seotud korduv tegevus, mis ei mõjuta infosüsteemide või teenuste tööd ega vaja muudatuste halduse protsessi läbimist. Need ülesanded põhinevad eelnevalt kinnitatud protseduuridel ning on osa tavapärasest IT-haldusest ja kasutajatoest. 1.1. Näited rutiinsetest tööülesannetest: 1.1.1.Kasutaja tööjaama installeerimine koos standardsete tarkvaradega. 1.1.2.Standardsete tulemüürireeglite rakendamine. 1.1.3.Printeri draiverite uuendamine kasutajatoe poolt tööjaamades. 1.1.4.E-posti konto parooli lähtestamine vastavalt kasutaja päringule. 1.1.5.Varunduste igapäevane kontrollimine ja haldamine. 1.1.6.Regulaarsete logianalüüside ja monitooringute läbiviimine. 1.1.7.Uue kasutajakonto loomine ja tavapäraste õiguste määramine AD-s või muus identiteedihaldussüsteemis. 2. Standardmuudatus (Standard Change) - Standardmuudatus on eelnevalt heaks kiidetud, madala riskiga ja korduv muudatus, mis põhineb kindlaks määratud ning testitud protseduuridel. Kuna standardmuudatusel on infosüsteemile või teenusele minimaalne mõju, ei vaja see eraldi kooskõlastamist, kuid registreerimine on kohustuslik. Standardmuudatus registreeritakse ja hallatakse JIRA keskkonnas, kus muudatuse algataja täidab vajalikud muudatusega seotud väljad, mis tagab selle planeerituse ja jälgitavuse muudatuste kalendris. 2.1. Näited standardmuudatustest: 2.1.1.Rutiinsed tarkvarauuendused, mille mõju on testitud ja teada (nt Windowsi turvapaigad, Office 365 uuendused). 2.1.2.Teenuse tavapäraste sertifikaatide uuendamine (nt veebiserveri TLS-sertifikaadi pikendamine). 2.1.3.Logide arhiveerimine ja puhastamine vastavalt säilituspoliitikale. 3. Tavamuudatus (Normal Change) - Tavamuudatus on muudatus, mis ei ole standardmuudatus ega hädavajalik muudatus ning vajab hindamist ja heakskiitu enne rakendamist. Tavamuudatus võib mõjutada süsteemide ja teenuste tööd, mistõttu selle riskitase määratakse muudatuste halduse protsessi käigus. Muudatus registreeritakse JIRA-s, kus toimub selle ülevaatus, kooskõlastamine ja planeerimine. 3.1. Näited tavamuudatustest: 3.1.1.Uue tarkvaramooduli juurutamine ärikriitilises süsteemis (nt uue funktsiooni lisamine). 3.1.2.Serveri või võrgu konfiguratsiooni muutmine, mis mõjutab mitut süsteemi. 3.1.3.Süsteemi versioonitäiendused, millel on kasutajatele märgatav mõju (nt ERP süsteemi versiooniuuendus). 3.1.4.Uue süsteemi või teenuse integreerimine olemasoleva IT-taristuga. 3.1.5.Teenuste ümberkonfigureerimine ressursikasutuse optimeerimiseks (nt andmebaasi jõudluse parandamine). 3.1.6.Pilveteenuste migratsioon (nt andmebaasi viimine AWS-i või Azure'i keskkonda). 4. Hädavajalik muudatus (Emergency Change) - Hädavajalik muudatus on kiireloomuline muudatus, mis on vajalik olulise intsidendi lahendamiseks või kriitilise riski maandamiseks. Selle mittelahendamine võib põhjustada tõsist häiret infosüsteemide või teenuste töös. Kuna hädavajalikud muudatused tehakse kiire reageerimise korras, registreeritakse need tavaliselt intsidendipiletina JIRA-s. 4.1. Näited hädavajalikest muudatustest: 4.1.1.Kriitilise turvapaiga viivitamatu rakendamine (nt äsja avastatud nullpäeva turvanõrkuse sulgemine). 4.1.2.Süsteemi taastamine pärast suuremat tehnilist tõrget (nt rikutud andmebaasi taastamine). 4.1.3.Kiire serveri asendamine, kui kriitiline riistvaraseade on ootamatult rikkis. 4.1.4.Võrgurünnaku või lunavararünnaku leevendamiseks vajalike tulemüürireeglite kiire rakendamine.  2 4.1.5.Kasutajate juurdepääsu ajutine blokeerimine süsteemile turvariskide tõttu.