Debesijos problema retai būna vien netinkamas instancijos dydis. Rizika atsiranda, kai niekas negali parodyti aktualios architektūros, privilegijuotų prieigų, atkūrimo įrodymo, kaštų savininko ar saugaus pakeitimo kelio. Peržiūriu AWS arba Azure kaip produkto operacinę sistemą, o ne atskirų paslaugų sąrašą.
Signalai, kad infrastruktūrą reikia peržiūrėti
- Perimate cloud aplinką iš tiekėjo arba darbuotojo ir nežinote, ar valdote visas paskyras bei paslaptis.
- Kaštai didėja, tačiau negalite jų priskirti produktui, aplinkai ar konkrečiai apkrovai.
- Atsarginės kopijos egzistuoja, bet niekas neparodė sėkmingo atkūrimo bandymo.
- Produkcijos pakeitimai atliekami rankomis, o aplinkos ir teisės laikui bėgant išsiskyrė.
- Planuojamas augimas, migracija ar duomenų bazės pakeitimas, tačiau nėra talpos ir grįžimo plano.
Apčiuopiami rezultatai
Ką gaunate po cloud peržiūros
Aktuali architektūros schema
Aplinkos, tinklai, instancijos, serverless komponentai, duomenų bazės, saugyklos, integracijos ir kritinės priklausomybės.
Prieigų matrica
Paskyros, rolės, privilegijuoti naudotojai, paslaugų tapatybės, paslaptys ir teisės, kurios neatitinka mažiausios privilegijos principo.
Duomenų ir atkūrimo patikra
Atsarginės kopijos, šifravimas, saugojimo terminai, replikacija, atkūrimo tikslai ir realaus bandymo įrodymai.
Operacijų būklė
Stebėsena, perspėjimai, žurnalai, incidentų kelias, diegimas, grįžimas ir atsakomybės už produkciją.
Kaštų veiksniai
Didžiausios sąnaudų grupės, nenaudojami resursai, aplinkų dubliavimas ir vietos, kur optimizacija nekeičia patikimumo.
Prioritetinis planas
Kritinės rizikos, greiti pataisymai, architektūriniai darbai, savininkai ir aiškios prielaidos augimo ar migracijos sprendimui.
Darbo eiga
Peržiūra pagal produkto riziką
- 01
Kritiniai verslo srautai
Nustatome, kurios paslaugos, duomenys ir SLA tiesiogiai veikia klientus, pajamas ar teisinius įsipareigojimus.
- 02
Konfigūracijos ir įrodymai
Tikrinamos faktinės paskyros, teisės, resursai, kaštai, logai ir atkūrimo duomenys — ne tik architektūros skaidrė.
- 03
Gedimo ir augimo scenarijai
Vertinama, kas nutinka praradus komponentą, tiekėją, regioną, raktą ar galimybę diegti.
- 04
Remediacijos seka
Pirmiausia uždaromos didelio poveikio ir lengvai išnaudojamos spragos, tada planuojami ilgesni architektūriniai pakeitimai.
Aiški atsakomybė
Ką vertinu, o ko nežadu
AWS ir Azure, ne logotipų sąrašas
Paslaugos parenkamos pagal apkrovą, komandos gebėjimus ir operavimo kainą; multi-cloud nėra tikslas savaime.
Kaštai kartu su patikimumu
Pigiausias resursas nėra optimizacija, jei jis didina incidentų, duomenų praradimo ar rankinių operacijų riziką.
Įrodytas atkūrimas
Backup būsena konsolėje nėra pakankamas įrodymas. Svarbu, ar komanda gali atkurti sistemą per verslui priimtiną laiką.
Praktinė patirtis
Produkcinė infrastruktūra, o ne vien konsultacinės skaidrės
5+ metų AWS ir AzureInstancijų, prieigų, duomenų bazių ir cloud įrankių kūrimas bei valdymas kartu su aplikacijos architektūra ir produkto paleidimu.
Peržiūrėti atvejįFAQ
Dažniausi klausimai
Ar tai AWS/Azure kaštų optimizavimas?+
Kaštai yra viena peržiūros dalis. Vertinu juos kartu su talpa, atsparumu, duomenų rizika ir operavimo darbu, kad sutaupymas nepablogintų sistemos patikimumo.
Ar galite perimti tiekėjo valdomą infrastruktūrą?+
Taip. Pirmiausia inventorizuojamos paskyros, domenai, prieigos, paslaptys, duomenys, diegimo kelias ir kritinės trečiųjų šalių paslaugos; tik tada planuojamas saugus nuosavybės perdavimas.
Ar peržiūrite IAM ir naudotojų teises?+
Taip. Tikrinamos privilegijuotos paskyros, rolės, paslaugų tapatybės, paveldėtos teisės, paslapčių valdymas ir procesas, pagal kurį prieiga suteikiama bei atšaukiama.
Ar padedate įgyvendinti pataisymus?+
Taip. Peržiūros rezultatas atskiria greitus konfigūracijos pataisymus nuo architektūrinių darbų, kuriuos galima įgyvendinti etapais ir perduoti komandai.