Pāriet uz galveno saturu
FromNine
Izvēlne

Inženierija

Mākoņa pamati, ar kuriem laidieni kļūst par ikdienu.

Mēs veidojam mākoņa pamatus un iekšējās izstrādātāju platformas, kurās vides ir kods, laidieni ir parakstīti un atkārtojami, un katram iztērētajam eiro ir īpašnieks.

Organizācijām, kas uztur vienu mākoņa pamatu uzņēmumiem vairākās ES valstīs, katrai ar savu uzraudzības iestādi.

Pieteikt sarunuApskatīt arhitektūru
Mākoņu un platformu inženierija: spēju slāņiČetri slāņi viens aiz otra. No augšas uz leju: produktu komandu darba slodzes, iekšējā izstrādātāju platforma, parakstītas piegādes plūsmas un pamatā bāzes vide ar identitāti, tīklu un politikām.01Produktu komandu slodzes02Izstrādātāju platforma03Parakstītas piegādes plūsmas04Bāzes vide un politikas
  1. 01Bāzes vides (landing zones) ar politikām kā kodu un datu glabāšanas vietu katrai darba slodzei
  2. 02Standarta izstrādes ceļi, kas jaunu pakalpojumu atkārtojamā veidā nogādā līdz ekspluatācijai
  3. 03Pakalpojuma līmeņa mērķi, pārbaudīta atjaunošana un izmaksas katram produktam, redzamas tiem, kas lemj

01 Problēmas

Pazīmes, ka pamati Jūs bremzē

  1. 01

    Katra vide ir unikāla

    Testa un ražošanas vide atšķiras veidos, ko neviens nav pierakstījis, un konsolē ar roku veiktie labojumi nākamajā pārbūvē pazūd.

  2. 02

    Laidienam vajadzīga sanāksme

    Izvietošana notiek reti, manuāli un vakaros. Komandas izmaiņas sakrāj, un tāpēc katrs laidiens kļūst riskantāks.

  3. 03

    Mākoņa rēķins pārsteidz visus

    Izmaksas redzamas pa abonementiem, nevis pa produktiem. GPU jaudu MI darbam rezervē tas, kurš paprasīja pirmais.

  4. 04

    Neviens nezina, vai atjaunošana darbojas

    Rezerves kopijas ir. Atjaunošana nav pārbaudīta, un atjaunošanas laika un datu zuduma mērķi nekad nav saskaņoti ar uzņēmumu.

02 Ko piegādājam

Ko mēs piegādājam

  1. 01 Bāzes vides un suverenitātes iespējas

    Kontu un abonementu struktūra, identitāte, tīkls un aizsargnoteikumi pie lielajiem mākoņpakalpojumu sniedzējiem un ES suverēnā mākoņa piedāvājumos, ar politikām kā kodu un datu glabāšanas vietu katrai darba slodzei.

    Ko mēs darām

    • Organizācijas, pārvaldības grupu un kontu projektējums
    • Centrālais tīkls, izejošās plūsmas kontrole un privāti savienojumi
    • Politikas kā kods datu glabāšanas vietai, šifrēšanai un marķēšanai
    • Sasaiste ar mākoņpakalpojumu sniedzēju apliecinājumiem, ko prasa Jūsu klienti un iepirkumi

    Ko Jūs saņemat

    • Bāzes vide, pilnībā definēta kodā
    • Politiku bibliotēka ar izņēmumu procesu
    • Suverenitātes iespēju apraksts katrai darba slodžu klasei

  2. 02 Infrastruktūra kā kods un iekšējās izstrādātāju platformas

    Terraform vai OpenTofu un Bicep infrastruktūrai, GitOps izvietošanai, Kubernetes vai pārvaldītas izpildvides, kur tās der, un standarta izstrādes ceļi, lai komanda varētu sākt prasībām atbilstošu pakalpojumu bez pieteikumu rakstīšanas.

    Ko mēs darām

    • Infrastruktūras kā koda moduļu bibliotēka
    • GitOps ar pārvietošanu starp vidēm
    • Kubernetes platforma vai pārvaldītas alternatīvas
    • Pakalpojumu veidnes un izstrādātāju portāls

    Ko Jūs saņemat

    • Iekšējā izstrādātāju platforma ar standarta ceļiem
    • Pašapkalpošanās vides
    • Platformas ceļvedis, kas pieder platformas komandai

  3. 03 Piegādes plūsmas un piegādes ķēdes drošība

    Plūsmas, kas būvē vienreiz, paraksta artefaktus, pieraksta izcelsmi atbilstoši SLSA, pareizi pārvalda noslēpumus un pārvieto vienu un to pašu artefaktu no testa līdz ražošanai.

    Ko mēs darām

    • Plūsmu veidnes ar kvalitātes un drošības pārbaudēm
    • Artefaktu parakstīšana un izcelsmes apliecinājums
    • Noslēpumu pārvaldība un atslēgu rotācija
    • Pārvietošanas noteikumi un izmaiņu pieraksti

    Ko Jūs saņemat

    • Atkārtoti izmantojamas plūsmu veidnes
    • Parakstīti artefakti ar pārbaudāmu izcelsmi
    • Laidiena pierādījumi izmaiņu pārvaldībai

  4. 04 Novērojamība un SRE

    Pakalpojuma līmeņa mērķi (SLO), saskaņoti ar uzņēmumu, kļūdu budžeti, kas nosaka laidienu tempu, OpenTelemetry visā sistēmā un incidentu process, kas kalpo arī ziņošanas pienākumiem pēc Nacionālās kiberdrošības likuma un DORA, kur tie attiecas.

    Ko mēs darām

    • SLO definēšana kopā ar pakalpojumu īpašniekiem
    • OpenTelemetry instrumentācija un paneļi
    • Brīdinājumi par simptomiem, nevis cēloņiem
    • Incidentu pārvaldība un pēcincidenta pārskati

    Ko Jūs saņemat

    • SLO katalogs
    • Novērojamības rīki un paneļi
    • Incidentu un ziņošanas rokasgrāmatas

  5. 05 FinOps un MI jauda

    Izmaksu sadale pa produktiem un komandām, vienības ekonomika, piemēram, viena darījuma izmaksas, un GPU jaudas plānošana un izmaksu kontrole MI darba slodzēm.

    Ko mēs darām

    • Marķēšanas politika un sadales modelis
    • Vienības izmaksu rādītāji katram produktam
    • Saistību un rezervāciju plānošana
    • GPU plānošana, kvotas un pareizs izmērs

    Ko Jūs saņemat

    • Izmaksu paneļi katram produkta īpašniekam
    • Ietaupījumu saraksts ar īpašniekiem
    • MI jaudas plāns

  6. 06 Atjaunošana un izeja

    Rezerves kopijas un avārijas atjaunošana ar skaidriem atjaunošanas laika un atjaunošanas punkta mērķiem, kas regulāri pārbaudīti, un izejas stratēģija, kas izmanto pārslēgšanās tiesības pēc ES Datu akta.

    Ko mēs darām

    • RTO un RPO, saskaņoti katram pakalpojumam
    • Atjaunošanas un pārslēgšanas testi
    • Kritisko pakalpojumu atkarību kartēšana
    • Izejas plāns un datu pārnesamības pārbaudes

    Ko Jūs saņemat

    • Pārbaudītas atjaunošanas procedūras
    • Atjaunošanas testu pārskati
    • Dokumentēta izejas stratēģija

03 Arhitektūra

Ilustratīva atsauces arhitektūra

Kreisajā pusē ienāk kods, labajā iznāk darbojošās darba slodzes. Starp tiem plūsma paraksta to, ko būvē, reģistrs glabā tikai parakstītus artefaktus, un GitOps kontrolieris tos politiku ietvaros pārvieto cauri vidēm.

Apakšā ir bāzes vide: organizācijas struktūra, identitāte, tīkls, atslēgas, atjaunošana un izmaksu kontroles, vienreiz definētas kodā un kopīgas visām produktu komandām.

Slāņi zīmējumā

Piegāde
Repozitoriji, plūsmas, parakstīti artefakti un GitOps pārvietošana.
Platforma
Izstrādātāju platforma, politikas kā kods un izpildvide, kurā produktu komandas izvieto.
Bāzes vide
Organizācija, identitāte, tīkls, atslēgas, atjaunošana un FinOps kontroles.
Darbība
Telemetrija, SLO, kļūdu budžeti un incidentu reaģēšana visā sistēmā.
Ilustratīvs piemērs

  1. Piegāde

    • Koda un IaC repozitoriji
    • Būvēt, parakstīt, apliecināt
    • Parakstītu artefaktu reģistrs
    • GitOps pārvietošana

  2. Platforma

    • Izstrādātāju platforma un standarta ceļi
    • Politikas kā kods
    • Kubernetes un pārvaldīti pakalpojumi
    • Produktu komandu slodzes

  3. Bāzes vide

    • Pārvaldības struktūra
    • Identitāte un piekļuve
    • Centrālais tīkls un izeja
    • Atslēgas un noslēpumi
    • Rezerves kopijas un atjaunošana
    • Izmaksu sadale

  4. Darbība

    • OpenTelemetry, SLO un kļūdu budžeti, incidentu reaģēšana
Parakstīta piegāde politiku pārvaldītā bāzes vidē

Ilustratīva arhitektūra, nevis klienta sistēma.

Lasīt diagrammu kā tekstu

Galvenais ceļš ved no koda un infrastruktūras repozitorijiem caur plūsmām, kas būvē, paraksta un apliecina, uz artefaktu reģistru, tad uz GitOps kontrolieri un visbeidzot uz produktu komandu darba slodžu vidēm.

Iekšējā izstrādātāju platforma piedāvā standarta ceļus uz plūsmām. Politikas kā kods ierobežo GitOps kontrolieri. Izpildes platforma ar Kubernetes un pārvaldītiem pakalpojumiem mitina darba slodzes. Klienta pārvaldītas atslēgas papildina politiku slāni.

Apakšā esošā bāzes vide ietver pārvaldības struktūru, identitāti un piekļuvi, centrālo tīklu, atslēgas, rezerves kopijas un atjaunošanu, kā arī FinOps kontroles. Novērojamība ar SLO un incidentu reaģēšanu aptver visu platformu.

04 Apsvērumi un ierobežojumi

Inženierijas apsvērumi un ierobežojumi

  • Suverenitāte ir skala

    Kā mēs to risinām

    Darba slodzes klasificējam pēc jutīguma un katrai klasei piemeklējam iespēju: liela mākoņpakalpojumu sniedzēja ES reģionus, suverēnā mākoņa piedāvājumu vai privātu infrastruktūru. Kompromisus funkcijās, izmaksās un darbībā pierakstām.

    Ierobežojumi un atkarības

    Suverēnajos piedāvājumos bieži trūkst pārvaldītu pakalpojumu, arī MI pakalpojumu. Dažas darba slodzes tur maksās vairāk vai spēs mazāk, un tā ir uzņēmuma izvēle.

  • Platformai vajadzīgs produkta īpašnieks

    Kā mēs to risinām

    Iekšējo platformu uzskatām par produktu ar lietotājiem, ceļvedi un atgriezenisko saiti un palīdzam izveidot komandu, kas to uztur.

    Ierobežojumi un atkarības

    Platforma bez komandas kļūst par šauru vietu. Ja to nevarat nodrošināt ar cilvēkiem, ieteiksim pārvaldītus pakalpojumus un mazāk abstrakciju.

  • Regulējums veido darbību

    Kā mēs to risinām

    Incidentu klasifikāciju, ziņošanas termiņus un pierādījumu vākšanu iestrādājam incidentu procesā, ja uz Jums attiecas Nacionālās kiberdrošības likums vai DORA.

    Ierobežojumi un atkarības

    Noteikt, vai Jūs esat likuma darbības jomā un kā piemērojami nacionālie noteikumi, paliek Jūsu atbilstības un juridiskās komandas ziņā.

  • Izmaksu kontrole ir kopīga

    Kā mēs to risinām

    Padarām izmaksas redzamas katram produktam un pievienojam aizsargnoteikumus, piemēram, budžetus, kvotas un neizmantotu vidžu plānotu izslēgšanu.

    Ierobežojumi un atkarības

    Lielākie ietaupījumi parasti nāk no arhitektūras un lietošanas lēmumiem, ko pieņem produktu īpašnieki, nevis tikai no platformas.

05 Kā strādājam

Kā mēs strādājam

Vispirms pamati, tad viena komanda uz standarta ceļa, tad visi pārējie.

  1. 01

    Novērtēt un klasificēt

    Darba slodzes, datu jutīgums, pašreizējās izmaksas un kontroles, ko sagaida Jūsu auditori.

    RezultātsDarba slodžu klasifikācija un mērķa iespējas

  2. 02

    Izveidot bāzes vidi

    Viss kā kods, pārskatīts kopā ar drošības komandu, ar izņēmumu procesu.

    RezultātsBāzes vide ekspluatācijā

  3. 03

    Pieslēgt pirmo komandu

    Viena produkta komanda pāriet uz standarta ceļu; tās grūtības veido platformu.

    RezultātsPirmais pakalpojums platformā

  4. 04

    Paplašināt un nodot

    Pievienojas citas komandas, platformas komanda pārņem atbildību, un atjaunošanu regulāri pārbauda.

    RezultātsPlatformas ceļvedis un atjaunošanas testu pārskati

06 Cilvēka kontrole

Kur kontrole paliek cilvēkiem

Platformu darbina automatizācija. Lēmumi, kas nes risku vai izmaksas, pieder cilvēkiem.

  • Ražošanas izmaiņas ir izsekojamas

    Katra izmaiņa ražošanas vidē nāk no pārskatīta koda iesūtījuma, tāpēc vienmēr ir pierakstīts, kas ko mainīja un kas to apstiprināja.

  • Ārkārtas piekļuve ir reta un žurnālēta

    Ārkārtas piekļuve ir laikā ierobežota, prasa pamatojumu un pēc tam tiek pārskatīta.

  • Politiku izņēmumiem ir īpašnieks

    Ja darba slodzei vajadzīgs izņēmums no aizsargnoteikuma, to apstiprina konkrēts riska īpašnieks, un izņēmumam ir beigu datums.

  • Mērķus nosaka pakalpojumu īpašnieki

    Atjaunošanas mērķus un pakalpojuma līmeņus saskaņo ar katra pakalpojuma īpašnieku uzņēmumā, nevis nosaka tikai platformas komanda.

07 Tehnoloģijas

Tehnoloģijas, ar kurām strādājam

Mākonis
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • ES suverēnā mākoņa piedāvājumi
Infrastruktūra un piegāde
  • Terraform un OpenTofu
  • Bicep
  • Argo CD un Flux
  • GitHub Actions, GitLab CI un Azure DevOps
Izpildvide
  • Kubernetes un pārvaldītie varianti
  • Bezservera un konteineru platformas
  • Pakalpojumu tīkls (service mesh), kur tas atmaksājas
  • GPU mezglu grupas MI darba slodzēm
Darbība
  • OpenTelemetry
  • Prometheus un Grafana
  • Mākoņa iebūvētā uzraudzība
  • Politiku dzinēji, piemēram, OPA

Tehnoloģijas nosaukums šajā sarakstā apraksta mūsu inženierijas pieredzi. Tas nenozīmē partnerību ar tās piegādātāju vai tā atbalstu.

08 Piemērs

Ilustratīvs piemērs

Ilustratīvs piemērs

Kopīga bāzes vide loģistikas grupai trijās Baltijas valstīs

01Situācija
Kravu ekspedīcijas grupas meitasuzņēmumi Latvijā, Lietuvā un Igaunijā darbina atsevišķas mākoņa vides ar atšķirīgām kontrolēm. Latvijā grupa ir Nacionālās kiberdrošības likuma darbības jomā, un katras valsts iestāde sagaida incidentu ziņojumus pēc saviem noteikumiem, bet neviens nevar parādīt grupas drošības stāvokli vienā skatā.
02Ko mēs izveidotu
Viena bāzes vide kodā ar politiku kopām katram uzņēmumam, kopīgu žurnālēšanu un incidentu procesu, kas klasificē ziņojumus un nosūta tos katras valsts iestādei.
03Kur lemj cilvēki
Katra uzņēmuma drošības vadītājs apstiprina politiku izņēmumus savām darba slodzēm; grupas informācijas drošības vadītājs atbild par kopīgo bāzes līmeni.
04Ko mēs mērītu
Laiks no incidenta atklāšanas līdz klasifikācijai, politikām pakļauto darba slodžu daļa un ceturksnī izturētie atjaunošanas testi.

09 Nozares skatījums

Jūsu nozarē

  • Publiskais sektors un valsts pārvalde

    Suverenitātes iespējas katrai datu klasei, pierādījumi Nacionālās kiberdrošības likuma prasībām un izejas plāni, kas izturēs nākamo iepirkumu.

  • Finanšu pakalpojumi

    Darbības noturība saskaņā ar DORA: pārbaudīta atjaunošana, ar trešo personu saistītā IKT riska uzraudzība un incidentu ziņošana, iestrādāta ikdienas darbībā. Latvijā kompetentā iestāde DORA prasību uzraudzībā ir Latvijas Banka.

Latvija

Pierādījumi vienreiz, katrai uzraudzības iestādei

NIS2 ir viena direktīva ar nacionāliem transponējumiem, kas atšķiras darbības jomā, reģistrācijā un ziņošanas detaļās. Latvijā to pārņem Nacionālās kiberdrošības likums, kas ir spēkā kopš 2024. gada 1. septembra. Būtisko un svarīgo pakalpojumu sniedzējus uzrauga Nacionālais kiberdrošības centrs (NKDC) Aizsardzības ministrijas pakļautībā, izņemot IKT kritisko infrastruktūru, ko uzrauga Satversmes aizsardzības birojs, un incidentu novēršanā darbojas CERT.LV, Latvijas Universitātes Matemātikas un informātikas institūta struktūrvienība.

Finanšu sektoram papildus ir DORA ar savu incidentu ziņošanu un ar trešo personu saistītā IKT riska pārvaldību; Latvijas Banka uzrauga finanšu tirgu un ir kompetentā iestāde DORA prasību uzraudzībā. Grupai, kas darbojas vairākās valstīs, vajadzīga viena platforma, kas var sagatavot katras iestādes prasītos pierādījumus.

Mēs projektējam bāzes vides, kurās datu glabāšanas vieta, žurnālēšana un incidentu klasifikācija ir politikas, nevis projekti, tāpēc jaunu uzņēmumu vai valsti pievieno ar konfigurāciju. Izejas plāni balstās uz pārslēgšanās tiesībām pēc ES Datu akta, un tos pārbauda, nevis tikai uzraksta.

Jautājumi par mākoņu un platformu inženieriju

Kuru mākoņpakalpojumu sniedzēju iesakāt?

To, kas atbilst Jūsu darba slodzēm, esošajiem līgumiem un suverenitātes prasībām. Mēs strādājam ar lielajiem mākoņpakalpojumu sniedzējiem un ES suverēnā mākoņa piedāvājumiem un dokumentējam kompromisus, lai izvēli varētu pamatot iepirkumā un vēlāk pārskatīt.

Vai mums vajadzīgs Kubernetes?

Ne vienmēr. Kubernetes atmaksājas, ja darbināt daudz pakalpojumu un Jums ir komanda platformas uzturēšanai. Dažiem pakalpojumiem pārvaldītas konteineru vai bezservera platformas bieži ir vienkāršākas un lētākas.

Kā tiek risināta drošība?

Drošība ir iebūvēta bāzes vidē un piegādes plūsmās: identitātes ar minimālām tiesībām, politikas kā kods, parakstīti artefakti un noslēpumi, kas nekad neatrodas kodā. Uzņēmumam FromNine ir ISO/IEC 27001 sertificēta informācijas drošības pārvaldība.

Vai varat samazināt mūsu mākoņa izmaksas?

Parasti jā, bet procentus nesolām, kamēr neesam redzējuši datus. Sākam ar to, ka padarām izmaksas redzamas katram produktam, un tad kopā ar īpašniekiem, kas var rīkoties, ejam cauri ietaupījumu sarakstam.

Kā izvairīties no piesaistes?

Apzināti izvēloties, kur paļauties uz konkrēta sniedzēja pakalpojumiem, glabājot infrastruktūru kodā un uzturot dokumentētu, pārbaudītu izejas plānu. ES Datu akts stiprina Jūsu tiesības mainīt pakalpojumu sniedzēju; izejas plāns padara šīs tiesības izmantojamas.

Parādiet mums savus nākamos trīs laidienus

Mēs pateiksim, kas tos padarītu par ikdienu un cik izmaksātu šādu pamatu izveide un uzturēšana.

Pieteikt sarunuApskatīt konsultācijas