Kā plānot mākoņmigrācijas projektu bez dīkstāves

Pārcelšana uz mākoni reti ir tikai tehnisks uzdevums. Tā ietekmē lietotāju darbu, klientu apkalpošanu, datu pieejamību, izmaksas un uzņēmuma spēju turpināt darbu incidenta laikā. Tāpēc jautājums, kā plānot mākonī migrācijas projektu, nav par viena pakalpojuma izvēli. Tas ir par kontrolētu pārmaiņu procesu, kurā tehnoloģiskie lēmumi ir sasaistīti ar biznesa prioritātēm.

Nepietiekami sagatavota migrācija var radīt neplānotu dīkstāvi, dubultas izmaksas vai situāciju, kurā dati ir pārvietoti, bet piekļuves, rezerves kopijas un atbildības nav skaidri definētas. Savukārt labi plānots projekts ļauj pāriet pakāpeniski, pārbaudīt kritiskos procesus un saglabāt vadības kontroli pār riskiem.

Sāciet ar biznesa mērķi, nevis ar platformu

Pirms izvēlēties publisko mākoni, privāto mākoni vai hibrīdo infrastruktūru, jāatbild uz vienkāršu jautājumu: kādu biznesa problēmu migrācija risina? Vienam uzņēmumam galvenais mērķis būs samazināt serveru uzturēšanas slogu. Citam - nodrošināt attālinātu darbu, ātrāk atvērt jaunu filiāli vai uzlabot atkopšanu pēc kiberincidenta.

Mērķim jābūt izmērāmam. Piemēram, kritiskajām sistēmām jābūt pieejamām 99,9% laika, atkopšanai pēc incidenta jānotiek četru stundu laikā vai jaunam darbiniekam jāspēj droši piekļūt nepieciešamajiem resursiem pirmajā darba dienā. Šādi kritēriji vēlāk palīdz izvērtēt gan arhitektūru, gan pakalpojuma sniedzēju, gan projekta rezultātu.

Migrācija uz mākoni nav obligāti pareizā atbilde visām sistēmām. Iekārtu vadības risinājumi, sistēmas ar ļoti zemu aiztures prasību vai lietojumprogrammas ar specifiskām licencēm dažkārt ir piemērotākas hibrīdā modelī. Stratēģisks lēmums nav pārcelt visu uzreiz, bet izvietot katru darba slodzi tur, kur tā ir droša, ekonomiski pamatota un pārvaldāma.

Izveidojiet pilnu esošās vides karti

Daudzi migrācijas projekti kļūst dārgi nevis tāpēc, ka mākonis ir dārgs, bet tāpēc, ka uzņēmums laikus nezina, kas tam patiesībā pieder un no kā ir atkarīgas kritiskās sistēmas. Inventarizācijai jāietver ne tikai serveri un lietojumprogrammas, bet arī datu plūsmas, lietotāju grupas, integrācijas, licences, domēni, sertifikāti, rezerves kopijas un piegādātāju piekļuves.

Īpaša uzmanība jāpievērš sistēmu savstarpējām atkarībām. Grāmatvedības programma var izmantot failu koplietošanu, kas savukārt balstās uz lokālu identitātes pārvaldību. Klientu portāls var būt atkarīgs no datubāzes, e-pasta paziņojumiem un ārēja maksājumu pakalpojuma. Ja pārvieto tikai vienu komponenti, neizprotot pārējo ķēdi, problēma parasti parādās pirmajā darba dienā pēc pārslēgšanās.

Inventarizācija ir arī piemērots brīdis IT higiēnai. Novecojušas virtuālās mašīnas, neizmantoti lietotāju konti, neskaidras administratora tiesības un serveri bez īpašnieka nav jāpārnes uz jauno vidi automātiski. Migrācija dod iespēju samazināt tehnisko parādu, taču tas jādara apzināti, lai tīrīšanas darbi nekavētu kritisko pāreju.

Nosakiet prioritātes un izvēlieties migrācijas pieeju

Kad vide ir kartēta, sistēmas jāsadala pēc biznesa kritiskuma. Pirmajā grupā parasti ir finanšu, klientu apkalpošanas, ražošanas, loģistikas un identitātes sistēmas. Otrajā - iekšējie rīki, kuru īslaicīga nepieejamība ir neērta, bet neaptur uzņēmuma darbu. Trešajā grupā ir sistēmas, kuras var aizvietot, arhivēt vai slēgt.

Praktiski drošākais risinājums bieži ir migrēt pa viļņiem. Sāk ar mazāk riskantām darba slodzēm, pārbauda piekļuves, veiktspēju, uzraudzību un izmaksu uzskaiti, pēc tam pāriet pie svarīgākajām sistēmām. Šāda pieeja pagarina projektu salīdzinājumā ar vienu lielu pāreju, toties būtiski samazina kļūdas cenu.

Katrai sistēmai jāizvēlas atbilstoša metode. Dažkārt pietiek ar esošā servera pārvietošanu uz mākoņa vidi. Citreiz lietojumprogrammu ir vērts pārkonfigurēt vai aizvietot ar programmatūru kā pakalpojumu. Trešais variants ir sistēmu atstāt lokāli, bet mākonī izvietot rezerves kopijas un avārijas atkopšanas vidi. Izvēli nosaka ne tikai tehniskā iespējamība, bet arī licences, drošības prasības, datu atrašanās vieta, lietotāju skaits un ilgtermiņa uzturēšanas izmaksas.

Drošība un atkopšana jāprojektē pirms datu pārvietošanas

Mākonis pats par sevi neatceļ kiberdrošības riskus. Pakalpojuma sniedzējs nodrošina infrastruktūras fizisko un pamatplatformas drošību, bet uzņēmums joprojām atbild par lietotāju kontiem, piekļuves tiesībām, konfigurāciju, datiem un lietojumprogrammām. Tieši nepareizas konfigurācijas bieži kļūst par nopietnāko ievainojamību.

Pirms migrācijas jānosaka, kā tiks pārvaldītas identitātes un administratora tiesības. Vairāku faktoru autentifikācijai jābūt obligātai administratīviem kontiem un, ja iespējams, visiem lietotājiem. Jāievieš mazāko nepieciešamo tiesību princips, regulāra piekļuves pārskatīšana un atsevišķi konti ikdienas darbam un administrēšanai.

Rezerves kopijas nedrīkst uzskatīt par pašsaprotamu mākoņa funkciju. Jābūt skaidram, kuri dati tiek kopēti, cik bieži, cik ilgi kopijas glabājas un cik ātri tās iespējams atjaunot. Vienlīdz būtiski ir testēt atjaunošanu. Dublējums, kuru nav izdevies atjaunot kontrolētā pārbaudē, nav pierādīta aizsardzība pret izspiedējvīrusu, kļūdainu dzēšanu vai sistēmas bojājumu.

Šeit jādefinē arī RPO un RTO rādītāji. RPO nosaka pieļaujamo datu zuduma periodu, piemēram, 15 minūtes vai viena diena. RTO nosaka pieļaujamo sistēmas atjaunošanas laiku. Ambiciozāki rādītāji parasti prasa dārgāku arhitektūru, tādēļ tiem jābalstās reālā biznesa ietekmes novērtējumā, nevis pieņēmumā, ka visam jābūt pieejamam nekavējoties.

Izmaksas jāpārvalda kā pastāvīgs process

Mākoņpakalpojumu izmaksas ir elastīgas, bet tas nenozīmē, ka tās automātiski būs zemākas. Maksājot par patēriņu, uzņēmums var ietaupīt uz neizmantotas jaudas, taču var arī nepamanīt pieaugošas izmaksas par datu glabāšanu, datu pārsūtīšanu, rezerves kopijām, licencēm vai pārāk lieliem resursiem.

Budžetā jāiekļauj ne tikai ikmēneša infrastruktūras maksa. Jāparedz migrācijas darbi, konsultācijas, drošības rīki, tīkla savienojumi, lietotāju apmācība, paralēlās vides uzturēšana pārejas periodā un iespējamās lietojumprogrammu izmaiņas. Vadībai ir lietderīgi pieprasīt trīs skatījumus: sākotnējās projekta izmaksas, ikmēneša darbības izmaksas un trīs gadu kopējās īpašumtiesību izmaksas.

Pēc pārejas jāievieš resursu marķēšana pēc nodaļas, projekta vai sistēmas īpašnieka. Tas ļauj redzēt, kas rada izdevumus, un pieņemt lēmumus par jaudas samazināšanu, rezervēšanu vai nevajadzīgu resursu slēgšanu. Bez šādas disciplīnas mākonis var kļūt par vidi, kurā izmaksas aug ātrāk nekā biznesa vērtība.

Sagatavojiet pārslēgšanās un atgriešanās plānu

Kritiskās migrācijas nedrīkst balstīt uz pieņēmumu, ka viss izdosies ar pirmo reizi. Katram migrācijas vilnim ir vajadzīgs pārslēgšanās plāns ar konkrētu logu, atbildīgajiem, darbību secību un lietotāju informēšanas kārtību. Jāzina, kurš apstiprina pāreju, kurš pārbauda tehniskos testus un kurš pieņem lēmumu apturēt procesu.

Tikpat svarīgs ir atgriešanās plāns. Ja veiktspēja neatbilst prasībām, integrācija nedarbojas vai datos konstatēta neatbilstība, komandai jāspēj saprotami atbildēt, kā atgriezt darbu iepriekšējā vidē un cik ilgi tas prasīs. Atgriešanās scenārijs nav neveiksmes pazīme. Tas ir profesionālas risku vadības elements.

Pirms katras pārslēgšanās jāveic lietotāju pieņemšanas tests. Tehniska komanda var apstiprināt, ka serveris darbojas, bet tikai biznesa lietotājs var pārbaudīt, vai var izrakstīt rēķinu, apstrādāt pasūtījumu, atrast dokumentu vai pieslēgties klientu sistēmai. Šie testi jāplāno ar reāliem darba scenārijiem, nevis tikai ar pieteikšanās pārbaudi.

Pārvaldība pēc migrācijas ir daļa no projekta

Migrācija nav pabeigta brīdī, kad lietotāji pieslēdzas jaunajai videi. Pēc pārejas ir jāuzrauga veiktspēja, pieejamība, drošības žurnāli, rezerves kopiju statuss un izmaksu novirzes. Pirmajās nedēļās ir vērts noteikt paaugstinātas uzraudzības periodu, kurā incidenti tiek ātri analizēti un konfigurācijas labotas pirms tie kļūst par ikdienas problēmām.

Jānosaka arī ilgtermiņa atbildība. Kurš apstiprina jaunus mākoņa resursus? Kurš pārskata administratora tiesības? Cik bieži tiek testēta avārijas atkopšana? Kā tiek vērtētas izmaksas pret budžetu? Mazos un vidējos uzņēmumos šīs funkcijas bieži ir lietderīgi uzticēt ārējam partnerim ar skaidri definētu pārvaldības modeli un regulāru vadības atskaiti. KSK IT šādu pieeju var nodrošināt, apvienojot tehnisko izpildi ar stratēģisku IT pārraudzību.

Labs mākoņmigrācijas plāns nedod tikai jaunu infrastruktūru. Tas rada skaidrību par datiem, atbildību, atkopšanu un izmaksām - četrām jomām, kas nosaka uzņēmuma spēju turpināt darbu arī tad, kad tehnoloģijas neuzvedas kā plānots.