Pereiti prie pagrindinio turinio
FromNine
Meniu

Inžinerija

Debesijos pagrindas, su kuriuo išleidimai tampa kasdienybe.

Kuriame debesijos pagrindus ir vidines kūrėjų platformas, kuriose aplinkos aprašytos kodu, išleidimai pasirašyti ir pakartojami, o kiekvienas išleistas euras turi savininką.

Organizacijoms, kurių debesijos pagrindas turi atitikti Kibernetinio saugumo įstatymą, DORA ar abu, ir grupėms su padaliniais keliose ES šalyse.

Aptarkime Jūsų projektąPeržiūrėkite etaloninę architektūrą
Debesija ir platformų inžinerija: gebėjimų sluoksniaiKeturi vienas po kito išdėstyti sluoksniai. Iš viršaus į apačią: produktų komandų darbo krūviai, vidinė kūrėjų platforma, pasirašyti diegimo konvejeriai ir pagrinde landing zone su tapatybe, tinklu ir politikomis.01Produktų komandų darbo krūviai02Vidinė kūrėjų platforma03Pasirašyti diegimo konvejeriai04Landing zone ir politikos
  1. 01Landing zone su politikomis kaip kodu ir duomenų buvimo vieta, nustatyta kiekvienam darbo krūviui
  2. 02Standartiniai keliai (golden paths), kuriais nauja paslauga pakartojamai pasiekia gamybinę aplinką
  3. 03SLO, išbandytas atkūrimas ir kiekvieno produkto kaina, matomi tiems, kurie priima sprendimus

01 Problemos

Ženklai, kad pagrindas Jus stabdo

  1. 01

    Kiekviena aplinka yra unikali

    Testinė ir gamybinė aplinkos skiriasi taip, kaip niekas nėra užrašęs, o konsolėje rankiniu būdu atlikti pataisymai dingsta kito perkūrimo metu.

  2. 02

    Išleidimui reikia susitikimo

    Diegimai reti, rankiniai ir planuojami vakarams. Komandos kaupia pakeitimus, todėl kiekvienas išleidimas tampa rizikingesnis.

  3. 03

    Debesijos sąskaita nustebina visus

    Išlaidos matomos pagal abonementą, o ne pagal produktą. GPU pajėgumus DI darbams rezervuoja tas, kuris paprašė pirmas.

  4. 04

    Niekas nežino, ar atkūrimas veikia

    Atsarginės kopijos yra. Atkūrimas nebuvo išbandytas, o atkūrimo trukmės ir leistino duomenų praradimo tikslai su verslu niekada nebuvo sutarti.

02 Ką pateikiame

Ką pateikiame

  1. 01 Landing zone ir suverenumo galimybės

    Paskyrų ir abonementų struktūra, tapatybė, tinklas ir apsauginės ribos didžiųjų debesijos paslaugų teikėjų ir ES suverenios debesijos aplinkose, su politikomis kaip kodu ir duomenų buvimo vieta kiekvienam darbo krūviui.

    Ką darome

    • Organizacijos, valdymo grupių ir paskyrų projektavimas
    • Centrinis tinklas, išeinančio srauto kontrolė ir privatus ryšys
    • Politikos kaip kodas duomenų buvimo vietai, šifravimui ir žymėjimui
    • Susiejimas su saugumo reikalavimais, kurių prašo Jūsų pirkėjai ir priežiūros institucijos, pavyzdžiui, Vyriausybės patvirtintais kibernetinio saugumo reikalavimais

    Ką gaunate

    • Landing zone, visiškai aprašyta kodu
    • Politikų biblioteka su išimčių procesu
    • Suverenumo galimybių analizė kiekvienai darbo krūvių klasei

  2. 02 Infrastruktūra kaip kodas ir vidinės kūrėjų platformos

    Terraform arba OpenTofu ir Bicep infrastruktūrai, GitOps diegimams, Kubernetes ar valdomos vykdymo aplinkos ten, kur jos tinka, ir standartiniai keliai, kad komanda galėtų sukurti reikalavimus atitinkančią paslaugą neteikdama užklausų.

    Ką darome

    • Modulių biblioteka infrastruktūrai kaip kodui
    • GitOps su perkėlimu tarp aplinkų
    • Kubernetes platforma ar valdomos alternatyvos
    • Paslaugų šablonai ir kūrėjų portalas

    Ką gaunate

    • Vidinė kūrėjų platforma su standartiniais keliais
    • Savitarnos aplinkos
    • Platformos planas, už kurį atsako platformos komanda

  3. 03 Diegimo konvejeriai ir tiekimo grandinės saugumas

    Konvejeriai, kurie surenka vieną kartą, pasirašo artefaktus, fiksuoja jų kilmę pagal SLSA, tinkamai valdo slaptus duomenis ir perkelia tą patį artefaktą iš testinės į gamybinę aplinką.

    Ką darome

    • Konvejerių šablonai su kokybės ir saugumo patikromis
    • Artefaktų pasirašymas ir kilmės patvirtinimas
    • Slaptų duomenų valdymas ir raktų keitimas
    • Perkėlimo taisyklės ir pakeitimų įrašai

    Ką gaunate

    • Pakartotinai naudojami konvejerių šablonai
    • Pasirašyti artefaktai su patikrinama kilme
    • Išleidimo įrodymai pakeitimų valdymui

  4. 04 Stebėsena ir SRE

    Paslaugų lygio tikslai, sutarti su verslu, klaidų biudžetai, lemiantys išleidimų tempą, OpenTelemetry visuose sluoksniuose ir incidentų valdymo procesas, kuris taip pat padeda vykdyti Kibernetinio saugumo įstatymo ir DORA pranešimo pareigas, kai jos taikomos.

    Ką darome

    • SLO apibrėžimas su paslaugų savininkais
    • OpenTelemetry instrumentavimas ir skydeliai
    • Įspėjimai pagal simptomus, ne pagal priežastis
    • Incidentų valdymas ir peržiūros po incidentų

    Ką gaunate

    • SLO katalogas
    • Stebėsenos sistema ir skydeliai
    • Incidentų ir pranešimų vadovai

  5. 05 FinOps ir DI pajėgumai

    Išlaidų paskirstymas pagal produktus ir komandas, vieneto ekonomika, pavyzdžiui, vienos operacijos kaina, ir GPU pajėgumų planavimas bei išlaidų kontrolė DI darbo krūviams.

    Ką darome

    • Žymėjimo politika ir paskirstymo modelis
    • Vieneto kainos rodikliai kiekvienam produktui
    • Įsipareigojimų ir rezervacijų planavimas
    • GPU planavimas, kvotos ir tinkamas dydžio parinkimas

    Ką gaunate

    • Išlaidų skydeliai kiekvienam produkto savininkui
    • Taupymo priemonių sąrašas su savininkais
    • DI pajėgumų planas

  6. 06 Atkūrimas ir pasitraukimas

    Atsarginės kopijos ir atkūrimas po avarijų su aiškiais atkūrimo trukmės ir atkūrimo taško tikslais, reguliariai išbandomi, ir pasitraukimo strategija, kuri naudoja ES Duomenų akte numatytas teises keisti paslaugų teikėją.

    Ką darome

    • RTO ir RPO, sutarti kiekvienai paslaugai
    • Atkūrimo ir perjungimo į atsarginę aplinką testai
    • Kritinių paslaugų priklausomybių žemėlapis
    • Pasitraukimo planas ir duomenų perkeliamumo patikros

    Ką gaunate

    • Išbandytos atkūrimo procedūros
    • Atkūrimo testų ataskaitos
    • Dokumentuota pasitraukimo strategija

03 Architektūra

Iliustracinė etaloninė architektūra

Kairėje patenka kodas, dešinėje išeina veikiantys darbo krūviai. Tarp jų konvejeris pasirašo tai, ką surenka, registras saugo tik pasirašytus artefaktus, o GitOps valdiklis pagal politikas perkelia juos per aplinkas.

Apačioje yra landing zone: organizacijos struktūra, tapatybė, tinklas, raktai, atkūrimas ir išlaidų kontrolė, vieną kartą aprašyti kodu ir bendri visoms produktų komandoms.

Brėžinio sluoksniai

Diegimas
Saugyklos, konvejeriai, pasirašyti artefaktai ir GitOps perkėlimas.
Platforma
Kūrėjų platforma, politikos kaip kodas ir vykdymo aplinka, į kurią diegia produktų komandos.
Landing zone
Organizacija, tapatybė, tinklas, raktai, atkūrimas ir FinOps kontrolė.
Eksploatavimas
Telemetrija, SLO, klaidų biudžetai ir reagavimas į incidentus visoje sistemoje.
Iliustracinis pavyzdys

  1. Diegimas

    • Kodo ir IaC saugyklos
    • Surinkimas, pasirašymas, kilmė
    • Pasirašytų artefaktų registras
    • GitOps perkėlimas

  2. Platforma

    • Kūrėjų platforma ir standartiniai keliai
    • Politikos kaip kodas
    • Kubernetes ir valdomos paslaugos
    • Produktų komandų darbo krūviai

  3. Landing zone

    • Valdymo struktūra
    • Tapatybė ir prieiga
    • Centrinis tinklas ir išeinantis srautas
    • Raktai ir slapti duomenys
    • Atsarginės kopijos ir atkūrimas
    • Išlaidų paskirstymas

  4. Eksploatavimas

    • OpenTelemetry, SLO ir klaidų biudžetai, reagavimas į incidentus
Pasirašytas diegimas į politikomis valdomą landing zone

Iliustracinė architektūra, ne kliento sistema.

Skaityti diagramą kaip tekstą

Pagrindinė trasa veda nuo kodo ir infrastruktūros saugyklų per konvejerius, kurie surenka, pasirašo ir patvirtina kilmę, į artefaktų registrą, tada į GitOps valdiklį ir galiausiai į produktų komandų darbo krūvių aplinkas.

Vidinė kūrėjų platforma teikia standartinius kelius į konvejerius. Politikos kaip kodas riboja GitOps valdiklį. Vykdymo platforma su Kubernetes ir valdomomis paslaugomis talpina darbo krūvius. Kliento valdomi raktai teikiami politikų sluoksniui.

Apačioje esanti landing zone apima valdymo struktūrą, tapatybę ir prieigą, centrinį tinklą, raktus, atsargines kopijas ir atkūrimą bei FinOps kontrolę. Stebėsena su SLO ir reagavimu į incidentus apima visą platformą.

04 Aspektai ir ribos

Inžineriniai aspektai ir ribos

  • Suverenumas turi daug pakopų

    Kaip tai sprendžiame

    Darbo krūvius klasifikuojame pagal jautrumą ir kiekvienai klasei parenkame galimybę: didžiojo teikėjo ES regionus, suverenios debesijos paslaugą ar privačią infrastruktūrą. Funkcijų, kainos ir eksploatavimo kompromisai užrašomi.

    Ribos ir priklausomybės

    Suverenios debesijos paslaugos dažnai atsilieka valdomų paslaugų, taip pat DI paslaugų, srityje. Kai kurie darbo krūviai ten kainuos daugiau arba galės mažiau, ir tai yra verslo pasirinkimas.

  • Platformai reikia produkto savininko

    Kaip tai sprendžiame

    Vidinę platformą laikome produktu su naudotojais, planu ir grįžtamuoju ryšiu ir padedame suburti ją eksploatuojančią komandą.

    Ribos ir priklausomybės

    Platforma be komandos tampa butelio kakleliu. Jei negalite jai skirti žmonių, rekomenduosime valdomas paslaugas ir mažiau abstrakcijų.

  • Reguliavimas formuoja eksploatavimą

    Kaip tai sprendžiame

    Incidentų klasifikavimas, pranešimų terminai ir įrodymų rinkimas įtraukiami į incidentų valdymo procesą, jei Jums taikomas Kibernetinio saugumo įstatymas ar DORA.

    Ribos ir priklausomybės

    Ar patenkate į taikymo sritį ir kaip taikomos nacionalinės taisyklės, sprendžia Jūsų atitikties ir teisės komandos.

  • Išlaidų kontrolė yra bendra atsakomybė

    Kaip tai sprendžiame

    Išlaidas padarome matomas kiekvienam produktui ir pridedame apsaugos priemones, tokias kaip biudžetai, kvotos ir neveikiančių aplinkų išjungimas pagal grafiką.

    Ribos ir priklausomybės

    Didžiausias sutaupymas paprastai kyla iš architektūros ir naudojimo sprendimų, kuriuos priima produktų savininkai, o ne vien iš platformos.

05 Kaip dirbame

Kaip dirbame

Pirmiausia pagrindai, tada viena komanda standartiniame kelyje, tada visos kitos.

  1. 01

    Įvertiname ir klasifikuojame

    Darbo krūviai, duomenų jautrumas, dabartinės išlaidos ir kontrolės priemonės, kurių tikisi Jūsų auditoriai.

    RezultatasDarbo krūvių klasifikacija ir tikslinės galimybės

  2. 02

    Sukuriame landing zone

    Viskas aprašyta kodu, peržiūrėta su saugumo specialistais, su išimčių procesu.

    RezultatasLanding zone gamybinėje aplinkoje

  3. 03

    Prijungiame pavyzdinę komandą

    Viena produkto komanda pereina į standartinį kelią, o jos patirti sunkumai formuoja platformą.

    RezultatasPirmoji paslauga platformoje

  4. 04

    Plečiame ir perduodame

    Prisijungia daugiau komandų, platformos komanda perima atsakomybę, o atkūrimas tikrinamas pagal grafiką.

    RezultatasPlatformos planas ir atkūrimo testų ataskaitos

06 Žmogaus kontrolė

Kur sprendžia žmonės

Platformą valdo automatizavimas. Sprendimus, susijusius su rizika ar išlaidomis, priima žmonės.

  • Gamybinės aplinkos pakeitimai atsekami

    Kiekvienas gamybinės aplinkos pakeitimas kyla iš peržiūrėto įrašo saugykloje, todėl visada užfiksuota, kas ką pakeitė ir kas tai patvirtino.

  • Avarinė prieiga reta ir registruojama

    Avarinė prieiga ribojama laiku, jai reikia pagrindimo, o vėliau ji peržiūrima.

  • Politikų išimtys turi savininką

    Kai darbo krūviui reikia apsauginės ribos išimties, ją su galiojimo pabaigos data patvirtina konkretus rizikos savininkas.

  • Tikslus nustato paslaugų savininkai

    Atkūrimo tikslai ir paslaugų lygiai sutariami su kiekvienos paslaugos verslo savininku, o ne nustatomi vien platformos komandos.

07 Technologijos

Technologijos, su kuriomis dirbame

Debesija
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • ES suverenios debesijos paslaugos
Infrastruktūra ir diegimas
  • Terraform ir OpenTofu
  • Bicep
  • Argo CD ir Flux
  • GitHub Actions, GitLab CI ir Azure DevOps
Vykdymo aplinka
  • Kubernetes ir valdomi jo variantai
  • Serverless ir konteinerių platformos
  • Paslaugų tinklas (service mesh), kai jis atsiperka
  • GPU mazgų telkiniai DI darbo krūviams
Eksploatavimas
  • OpenTelemetry
  • Prometheus ir Grafana
  • Debesijos teikėjų stebėsenos įrankiai
  • Politikų varikliai, pavyzdžiui, OPA

Technologijos paminėjimas apibūdina mūsų inžinerinę patirtį. Tai nereiškia partnerystės su jos gamintoju ar gamintojo pritarimo.

08 Pavyzdys

Iliustracinis pavyzdys

Iliustracinis pavyzdys

Landing zone šilumos tiekimo įmonei, kuriai taikomas Kibernetinio saugumo įstatymas

01Situacija
Įmonės sistemos veikia keliuose debesijos abonementuose ir senuose serveriuose su skirtingomis kontrolės priemonėmis. Incidentų klasifikavimo įrodymai renkami rankiniu būdu, o bendro saugumo būklės vaizdo niekas negali parodyti.
02Ką kurtume
Viena kodu aprašyta landing zone su politikų rinkiniais kiekvienai sistemų grupei, bendru žurnalų registravimu ir incidentų procesu, kuris klasifikuoja incidentus ir surenka pranešimams reikalingus įrodymus.
03Žmogaus kontrolė
Už kibernetinį saugumą atsakingas įmonės darbuotojas tvirtina politikų išimtis savo sistemoms, o vadovybė tvirtina bendrą saugumo bazę.
04Ką matuotume
Laikas nuo incidento aptikimo iki jo klasifikavimo, politikomis valdomų darbo krūvių dalis ir per ketvirtį sėkmingai atliktų atkūrimo testų skaičius.

09 Sektoriaus požiūriu

Jūsų sektoriuje

  • Viešasis sektorius

    Suverenumo galimybės kiekvienai duomenų klasei, nacionaliniai kibernetinio saugumo reikalavimai ir pasitraukimo planai, kurie išlieka galioti ir po kito pirkimo.

  • Finansinės paslaugos

    Skaitmeninės veiklos atsparumas pagal DORA: išbandytas atkūrimas, IRT paslaugas teikiančių trečiųjų šalių priežiūra ir pranešimai apie incidentus, įtraukti į kasdienį eksploatavimą.

Lietuva

Įrodymai vieną kartą, kiekvienai priežiūros institucijai

TIS 2 direktyva (NIS2) yra viena, tačiau kiekviena valstybė narė ją perkėlė savaip. Lietuvoje tai padarė Kibernetinio saugumo įstatymas, pakeistas 2024 m. liepos 11 d. ir galiojantis nuo 2024 m. spalio 18 d.; kibernetinio saugumo reikalavimus Vyriausybė patvirtino 2024 m. lapkričio 6 d. nutarimu, o priežiūrą vykdo Nacionalinis kibernetinio saugumo centras (NKSC). Įstatymas taip pat numato papildomas atsakingų asmenų pareigas, kurių pati direktyva nereikalauja.

Finansų įstaigoms nuo 2025 m. sausio 17 d. papildomai taikomas DORA su savais pranešimų apie incidentus ir trečiųjų šalių priežiūros reikalavimais. Lietuvos bankas prižiūri finansų rinkos dalyvius, o pagal DORA finansų sektoriaus subjektai jam teikia IRT registrą ir pranešimus apie didelius su IRT susijusius incidentus. Grupei, veikiančiai keliose šalyse, reikia vienos platformos, galinčios pateikti kiekvienos institucijos prašomus įrodymus.

Projektuojame landing zone, kuriose duomenų buvimo vieta, žurnalų registravimas ir incidentų klasifikavimas yra politikos, o ne projektai, todėl naujas juridinis asmuo ar šalis prijungiama konfigūracija. Pasitraukimo planai remiasi ES Duomenų akte numatytomis teisėmis keisti paslaugų teikėją ir yra išbandomi, o ne tik parašomi.

Klausimai apie debesiją ir platformų inžineriją

Kokį debesijos paslaugų teikėją rekomenduojate?

Tą, kuris tinka Jūsų darbo krūviams, esamoms sutartims ir suverenumo reikalavimams. Dirbame su didžiaisiais debesijos paslaugų teikėjais ir ES suverenios debesijos paslaugomis, o kompromisus dokumentuojame, kad pasirinkimą būtų galima pagrįsti pirkimo metu ir vėliau peržiūrėti.

Ar mums reikia Kubernetes?

Ne visada. Kubernetes atsiperka, kai veikia daug paslaugų ir turite komandą platformai eksploatuoti. Kelioms paslaugoms valdomos konteinerių ar serverless platformos dažnai yra paprastesnės ir pigesnės.

Kaip užtikrinate saugumą?

Saugumas įdiegtas į landing zone ir konvejerius: mažiausių teisių tapatybės, politikos kaip kodas, pasirašyti artefaktai ir slapti duomenys, kurie niekada nebūna kode. Pačios įmonės FromNine informacijos saugumo valdymas sertifikuotas pagal ISO/IEC 27001.

Ar galite sumažinti mūsų debesijos išlaidas?

Paprastai taip, tačiau procentų nežadame, kol nepamatėme duomenų. Pirmiausia išlaidas padarome matomas kiekvienam produktui, tada kartu su savininkais, galinčiais imtis veiksmų, einame per taupymo priemonių sąrašą.

Kaip išvengti priklausomybės nuo teikėjo?

Sąmoningai pasirenkant, kur remtis konkretaus teikėjo paslaugomis, laikant infrastruktūrą kode ir palaikant dokumentuotą, išbandytą pasitraukimo planą. ES Duomenų aktas sustiprina Jūsų teisę keisti paslaugų teikėją, o pasitraukimo planas leidžia ja realiai pasinaudoti.

Parodykite mums tris artimiausius išleidimus

Pasakysime, kas juos paverstų kasdienybe ir kiek kainuotų tokį pagrindą sukurti ir eksploatuoti.

Aptarkime Jūsų projektąArchitektūra ir konsultavimas