Ceļvedis uzņēmuma mākoņarhitektūras izvēlei

Jauna mākoņvide var paātrināt uzņēmuma darbu, bet nepareizi izvēlēta arhitektūra rada ikmēneša izmaksas, sarežģītu pārvaldību un riskus darbības nepārtrauktībai. Šis ceļvedis uzņēmuma mākoņarhitektūras izvēlei ir paredzēts vadītājiem, kuriem jāpieņem pamatots lēmums ne tikai par tehnoloģiju, bet arī par datu aizsardzību, atbildībām un uzņēmuma spēju turpināt darbu incidenta laikā.

Mākoņarhitektūra nav viens produkts vai viena licence. Tā ir vide, kurā savienojas lietotnes, dati, lietotāju piekļuves, drošības kontroles, rezerves kopijas, integrācijas un atjaunošanas procesi. Tāpēc jautājums nav tikai par to, vai pāriet uz mākoni. Jautājums ir, kuras sistēmas tur izvietot, kā tās pārvaldīt un kā pierādīt, ka uzņēmums spēj atgūt kritiskos datus un pakalpojumus pēc traucējuma.

Sāciet ar biznesa prasībām, nevis platformu

Lēmumu nevajadzētu sākt ar konkrēta pakalpojuma sniedzēja vai tehniskā risinājuma izvēli. Vispirms jānosaka, ko uzņēmumam ir jānodrošina. Grāmatvedības sistēmai, klientu datubāzei, noliktavas risinājumam un e-pastam var būt ļoti atšķirīgas prasības attiecībā uz pieejamību, datu glabāšanas vietu un pieļaujamo dīkstāvi.

Vadības komandai ir vērts definēt divus rādītājus katrai kritiskajai sistēmai. Atjaunošanas laika mērķis nosaka, cik ātri sistēmai jāatsāk darbs pēc incidenta. Atjaunošanas punkta mērķis nosaka, cik daudz datu uzņēmums var atļauties zaudēt. Ja pasūtījumu sistēmas dīkstāve divas stundas nozīmē būtiskus ieņēmumu zaudējumus, bet dati nedrīkst būt vecāki par 15 minūtēm, ar vienu iknakts rezerves kopiju nepietiks.

Šajā posmā jāizvērtē arī izaugsmes plāni. Uzņēmumam, kas šodien apkalpo 30 darbiniekus, bet pēc gada atvērs filiāli citā valstī vai ieviesīs e-komerciju, nepieciešama cita pieeja nekā stabilai organizācijai ar paredzamu darba slodzi. Mākonis ir vērtīgs, ja tā elastība atbilst reālam uzņēmuma attīstības scenārijam, nevis tikai teorētiskai iespējai palielināt resursus.

Ceļvedis uzņēmuma mākoņarhitektūras izvēlei: izvērtējiet darba slodzes

Ne visām sistēmām jānonāk vienā vidē. Praktisks risinājums parasti sākas ar darba slodžu sadalīšanu pēc to kritiskuma, datu veida, lietojuma intensitātes un tehniskajām atkarībām.

Standarta sadarbības rīki, piemēram, e-pasts, dokumentu koplietošana un videokonferences, bieži ir piemēroti programmatūras kā pakalpojuma modelim. Uzņēmums saņem gatavu pakalpojumu, bet koncentrējas uz identitāšu pārvaldību, piekļuves tiesībām, datu klasifikāciju un lietotāju apmācību. Šeit bieži tiek pieļauta kļūda, pieņemot, ka pakalpojuma sniedzējs automātiski atrisina visas rezerves kopiju un datu saglabāšanas vajadzības.

Pielāgotas biznesa lietotnes vai datubāzes var būt piemērotas publiskajam mākonim, ja nepieciešama mainīga jauda, integrācijas vai ātra jaunu vidi izveide. Tomēr šāds modelis prasa disciplinētu konfigurāciju, izmaksu uzraudzību un kompetenci. Nepārraudzīti resursi, pārmērīgi plašas piekļuves un neizslēgtas testēšanas vides var kļūt par dārgu un nedrošu problēmu.

Savukārt sistēmas ar mantotu programmatūru, specializētu iekārtu integrācijām vai stingrām latentuma prasībām var nebūt piemērotas tūlītējai migrācijai. Tām dažkārt pamatotāks ir hibrīda modelis, kur daļa infrastruktūras paliek lokāli vai privātā vidē, bet rezerves kopijas, attālinātā piekļuve un daļa lietotņu darbojas mākonī. Hibrīdrisinājums nav kompromiss neveiksmes nozīmē. Tas var būt apzināts veids, kā samazināt pārejas risku un saglabāt kritisku procesu stabilitāti.

Drošība sākas ar atbildību sadalījumu

Mākoņpakalpojuma sniedzējs parasti nodrošina fiziskās infrastruktūras drošību un pakalpojuma pamatfunkcijas. Taču uzņēmums joprojām ir atbildīgs par saviem lietotājiem, parolēm, piekļuves tiesībām, datiem, konfigurācijām un daudzos gadījumos arī par lietotņu drošību. Šis atbildības sadalījums ir jāizprot pirms līguma noslēgšanas, nevis pēc incidenta.

Praksē drošas arhitektūras pamatā ir centralizēta identitāšu pārvaldība, daudzfaktoru autentifikācija un mazāko nepieciešamo tiesību princips. Administratīvajām piekļuvēm jābūt nodalītām no ikdienas lietotāju kontiem, un piekļuves žurnāliem jābūt pieejamiem incidentu izmeklēšanai. Īpaša uzmanība jāpievērš ārējiem piegādātājiem, bijušajiem darbiniekiem un koplietotiem kontiem, kas bieži kļūst par nepamanītiem riska punktiem.

Datu aizsardzības prasības jāvērtē pēc datu kategorijām. Personas dati, finanšu informācija, komercnoslēpumi un klientu līgumi var prasīt atšķirīgu šifrēšanu, glabāšanas termiņus un piekļuves kontroli. Eiropas Savienības regulējuma kontekstā svarīgi saprast, kur dati tiek apstrādāti, kā tiek pārvaldīti apakšapstrādātāji un kā uzņēmums spēs izpildīt savas saistības pret klientiem un uzraugošajām iestādēm.

Rezerves kopijas un atjaunošana nav viena un tā pati lieta

Daudzi uzņēmumi uzskata, ka datu kopija automātiski nozīmē gatavību krīzei. Tā nav. Rezerves kopija ir tikai viens elements. Atjaunošanas spēja nozīmē, ka ir skaidrs process, atbildīgie cilvēki, prioritāšu secība, pārbaudītas piekļuves un pietiekama infrastruktūras jauda, lai sistēmu atgrieztu darbā noteiktajā laikā.

Mākoņarhitektūrā rezerves kopijām jābūt nodalītām no primārās vides un aizsargātām pret nejaušu vai ļaunprātīgu dzēšanu. Izspiedējvīrusu uzbrukuma gadījumā nepietiek ar kopiju, kas ir pastāvīgi pieejama ar tiem pašiem administratora kontiem. Nepieciešamas nemainīgas vai citādi aizsargātas kopijas, regulāra atjaunošanas pārbaude un dokumentēts katastrofu atkopšanas plāns.

Testēšana ir izšķiroša. Ja uzņēmums nav izmēģinājis, cik ilgs laiks nepieciešams kritiskas lietotnes atjaunošanai un vai atjaunotie dati tiešām ir lietojami, plānotais atjaunošanas laiks ir tikai pieņēmums. Pārbaudes jāveic kontrolētā veidā, dokumentējot rezultātus, novirzes un nepieciešamos uzlabojumus.

Aprēķiniet kopējās izmaksas un pārvaldības slodzi

Mākonis ne vienmēr ir lētākais variants, īpaši stabilām un prognozējamām darba slodzēm. Tā stiprā puse bieži ir elastība, ātrāka ieviešana, attālināta pieejamība un iespēja samazināt sākotnējos kapitālieguldījumus. Tomēr lēmums jābalsta kopējās izmaksās, nevis tikai ikmēneša abonementā.

Aprēķinā jāiekļauj licences, datu glabāšana, datu pārraide, rezerves kopijas, drošības rīki, monitorings, atbalsts, migrācija un speciālistu darbs. Jāņem vērā arī izmaksas par neefektīvu resursu izmantošanu. Attīstības vide, kas darbojas visu diennakti bez vajadzības, vai nepareizi izvēlēts datu glabāšanas līmenis laika gaitā var radīt būtisku pārtēriņu.

Laba prakse ir noteikt izmaksu īpašniekus un regulāru pārskatīšanas ritmu. Tehniskajai komandai jāspēj skaidri skaidrot vadībai, kādas izmaksas rada konkrētas sistēmas un kāpēc. Savukārt vadībai jāapstiprina, kurām darba slodzēm augstāka pieejamība vai ātrāka atjaunošana ir biznesa prioritāte. Tas novērš situāciju, kur IT vide tiek veidota maksimālai veiktspējai visur, lai gan uzņēmumam tā nav nepieciešama.

Izvēlieties pārvaldības modeli, kas atbilst jūsu kapacitātei

Mākoņinfrastruktūra ir jāpārvalda nepārtraukti. Nepieciešams uzraudzīt drošības paziņojumus, pārskatīt piekļuves, instalēt atjauninājumus, sekot izmaksām, pārbaudīt rezerves kopijas un uzturēt dokumentāciju. Ja uzņēmumā nav pilna laika speciālistu ar šādu kompetenci, arhitektūras izvēlē jāparedz pārvaldīts pakalpojums vai ārējs partneris ar skaidri definētu atbildību.

Svarīgi nošķirt tehnisko atbalstu no stratēģiskas pārvaldības. Atbalsta komanda var novērst ikdienas incidentus, bet vadībai nepieciešams arī regulārs skatījums uz riskiem, dzīves ciklu, budžetu un nākamajiem attīstības soļiem. Tieši šajā līmenī ārējs IT vadības partneris var palīdzēt sasaistīt infrastruktūras lēmumus ar uzņēmuma mērķiem, nevis tikai reaģēt uz problēmām.

Pirms ieviešanas vienojieties par četriem jautājumiem: kurš apstiprina izmaiņas, kurš ir atbildīgs par drošības konfigurāciju, kā tiek mērīta pakalpojumu kvalitāte un kā notiek eskalācija incidenta laikā. Skaidras robežas samazina risku, ka kritiskā brīdī katra iesaistītā puse pieņem, ka rīkosies kāds cits.

Mākoņarhitektūras izvēle ir ieguldījums uzņēmuma spējā strādāt paredzami arī pārmaiņu un incidentu laikā. Sāciet ar vienu kritisku sistēmu, pārbaudiet pieņēmumus praksē un izveidojiet pārvaldības disciplīnu, kas aug kopā ar uzņēmumu. Tad mākonis kļūst par kontrolējamu biznesa resursu, nevis par vēl vienu neskaidru IT risku.