Preskočite na glavno vsebino
FromNine
Meni

Razvoj in oblak

Oblačne osnove, pri katerih so izdaje rutina.

Gradimo oblačne osnove in notranje razvojne platforme, v katerih so okolja zapisana kot koda, izdaje podpisane in ponovljive, vsak evro porabe pa ima svojega lastnika.

Za organizacije, ki eno oblačno osnovo uporabljajo za družbe v Sloveniji in drugih državah članicah, vsaka s svojim nadzornikom.

Opišite svoj projektOglejte si arhitekturo
Razvoj oblačnih platform: plasti zmogljivostiŠtiri plasti, naložene druga na drugo. Od zgoraj navzdol: delovne obremenitve produktnih ekip, notranja razvojna platforma, podpisani cevovodi za dostavo ter landing zone z identiteto, omrežjem in pravili na dnu.01Delovne obremenitve produktnih ekip02Notranja razvojna platforma03Podpisani cevovodi za dostavo04Landing zone in pravila
  1. 01Landing zone s pravili, zapisanimi kot koda, in lokacijo hrambe podatkov, določeno za vsako delovno obremenitev
  2. 02Preverjene razvojne poti, po katerih nova storitev na ponovljiv način pride v produkcijo
  3. 03Cilji ravni storitev, preizkušena obnova in strošek po izdelkih, vidni ljudem, ki odločajo

01 Težave

Znaki, da vas osnova zadržuje

  1. 01

    Vsako okolje je unikat

    Testno in produkcijsko okolje se razlikujeta na načine, ki jih ni nihče zapisal, ročni popravki v konzoli pa se ob naslednji ponovni postavitvi izgubijo.

  2. 02

    Za izdajo je potreben sestanek

    Namestitve so redke, ročne in načrtovane za večerne ure. Ekipe spremembe združujejo, zaradi česar je vsaka izdaja bolj tvegana.

  3. 03

    Račun za oblak preseneti vse

    Stroški so vidni po naročninah, ne po izdelkih. Zmogljivosti GPU za delo z UI si rezervira tisti, ki prvi vpraša.

  4. 04

    Nihče ne ve, ali obnova deluje

    Varnostne kopije obstajajo. Obnove niso bile preizkušene, ciljni čas obnovitve in dovoljena izguba podatkov pa nista bila nikoli dogovorjena s poslovno stranjo.

02 Kaj zagotovimo

Kaj zagotovimo

  1. 01 Landing zone in možnosti suverenosti

    Struktura računov in naročnin, identiteta, omrežje in varovala pri velikih ponudnikih oblačnih storitev in v ponudbah evropskega suverenega oblaka, s pravili, zapisanimi kot koda, in lokacijo hrambe podatkov za vsako delovno obremenitev.

    Kaj naredimo

    • Zasnova organizacije, upravljavskih skupin in računov
    • Osrednje omrežje, nadzor izhodnega prometa in zasebne povezave
    • Pravila kot koda za lokacijo hrambe, šifriranje in označevanje
    • Preslikava na dokazila, ki jih zahtevajo vaše stranke, na primer ISO/IEC 27001 ali pri strankah v Nemčiji BSI C5

    Kaj prejmete

    • Landing zone, v celoti opredeljena v kodi
    • Knjižnica pravil s postopkom za izjeme
    • Dokument o možnostih suverenosti za vsak razred delovnih obremenitev

  2. 02 Infrastruktura kot koda in notranje razvojne platforme

    Terraform ali OpenTofu in Bicep za infrastrukturo, GitOps za namestitve, Kubernetes ali upravljana izvajalna okolja, kjer so smiselna, in preverjene razvojne poti, po katerih ekipa začne skladno storitev brez zahtevkov.

    Kaj naredimo

    • Knjižnica modulov za infrastrukturo kot kodo
    • GitOps s promocijo med okolji
    • Platforma Kubernetes ali upravljane alternative
    • Predloge storitev in portal za razvijalce

    Kaj prejmete

    • Notranja razvojna platforma s preverjenimi potmi
    • Okolja v samopostrežbi
    • Načrt razvoja platforme, za katerega je odgovorna ekipa platforme

  3. 03 Cevovodi za dostavo in varnost dobavne verige

    Cevovodi, ki zgradijo enkrat, podpišejo artefakte, zabeležijo izvor v skladu s SLSA, pravilno upravljajo skrivnosti in isti artefakt prenesejo iz testnega v produkcijsko okolje.

    Kaj naredimo

    • Predloge cevovodov s preverjanji kakovosti in varnosti
    • Podpisovanje artefaktov in potrjevanje izvora
    • Upravljanje skrivnosti in menjava ključev
    • Pravila promocije in zapisi sprememb

    Kaj prejmete

    • Ponovno uporabne predloge cevovodov
    • Podpisani artefakti s preverljivim izvorom
    • Dokazila o izdajah za upravljanje sprememb

  4. 04 Opazljivost in SRE

    Cilji ravni storitev, dogovorjeni s poslovno stranjo, proračuni napak, ki usmerjajo tempo izdaj, OpenTelemetry v celotnem skladu in postopek za incidente, ki podpira tudi obveznosti poročanja po ZInfV-1 in uredbi DORA, kjer veljajo.

    Kaj naredimo

    • Opredelitev ciljev ravni storitev z lastniki storitev
    • Instrumentacija OpenTelemetry in nadzorne plošče
    • Opozorila na simptome, ne na vzroke
    • Upravljanje incidentov in pregledi po incidentih

    Kaj prejmete

    • Katalog ciljev ravni storitev
    • Sklad za opazljivost in nadzorne plošče
    • Navodila za incidente in poročanje

  5. 05 FinOps in zmogljivosti za UI

    Razporejanje stroškov po izdelkih in ekipah, stroški na enoto, kot je strošek na transakcijo, ter načrtovanje zmogljivosti GPU in nadzor stroškov za delovne obremenitve UI.

    Kaj naredimo

    • Pravila označevanja in model razporejanja stroškov
    • Meritve stroška na enoto za vsak izdelek
    • Načrtovanje zavez in rezervacij
    • Razporejanje GPU, kvote in prilagajanje velikosti

    Kaj prejmete

    • Nadzorne plošče stroškov za vsakega lastnika izdelka
    • Seznam prihrankov z lastniki
    • Načrt zmogljivosti za UI

  6. 06 Obnova in izhod

    Varnostne kopije in obnova po nesreči z izrecno določenim ciljnim časom obnovitve in ciljno točko obnovitve, redno preizkušene, ter izhodna strategija, ki uporablja pravice do zamenjave ponudnika iz Akta o podatkih.

    Kaj naredimo

    • RTO in RPO, dogovorjena za vsako storitev
    • Preizkusi obnove in preklopa
    • Popis odvisnosti za kritične storitve
    • Izhodni načrt in preverjanje prenosljivosti podatkov

    Kaj prejmete

    • Preizkušeni postopki obnove
    • Poročila o preizkusih obnove
    • Dokumentirana izhodna strategija

03 Arhitektura

Ponazoritvena referenčna arhitektura

Koda vstopi na levi, delujoče obremenitve izstopijo na desni. Vmes cevovod podpiše, kar zgradi, register hrani samo podpisane artefakte, krmilnik GitOps pa jih po pravilih prenaša skozi okolja.

Pod tem je landing zone: organizacijska struktura, identiteta, omrežje, ključi, obnova in nadzor stroškov, enkrat opredeljeni v kodi in skupni vsem produktnim ekipam.

Plasti na sliki

Dostava
Repozitoriji, cevovodi, podpisani artefakti in promocija GitOps.
Platforma
Razvojna platforma, pravila kot koda in izvajalno okolje, v katerega nameščajo produktne ekipe.
Landing zone
Organizacija, identiteta, omrežje, ključi, obnova in nadzor stroškov FinOps.
Delovanje
Telemetrija, cilji ravni storitev, proračuni napak in odziv na incidente na vseh ravneh.
Ponazoritveni primer

  1. Dostava

    • Repozitoriji kode in IaC
    • Gradnja, podpis, potrditev
    • Register podpisanih artefaktov
    • Promocija GitOps

  2. Platforma

    • Razvojna platforma in preverjene poti
    • Pravila kot koda
    • Kubernetes in upravljane storitve
    • Obremenitve produktnih ekip

  3. Landing zone

    • Upravljavska struktura
    • Identiteta in dostop
    • Osrednje omrežje in izhodni promet
    • Ključi in skrivnosti
    • Varnostne kopije in obnova
    • Razporejanje stroškov

  4. Delovanje

    • OpenTelemetry, cilji ravni storitev, proračuni napak, odziv na incidente
Podpisana dostava na landing zone, ki jo upravljajo pravila

Ponazoritvena arhitektura, ne sistem stranke.

Preberite diagram kot besedilo

Glavna pot vodi od repozitorijev kode in infrastrukture prek cevovodov, ki gradijo, podpisujejo in potrjujejo, v register artefaktov, nato do krmilnika GitOps in na koncu do okolij produktnih ekip.

Notranja razvojna platforma zagotavlja preverjene poti do cevovodov. Pravila kot koda omejujejo krmilnik GitOps. Izvajalna platforma s Kubernetes in upravljanimi storitvami gosti delovne obremenitve. Ključi, ki jih upravlja stranka, napajajo plast pravil.

Landing zone spodaj vsebuje upravljavsko strukturo, identiteto in dostop, osrednje omrežje, ključe, varnostne kopije in obnovo ter nadzor stroškov FinOps. Opazljivost s cilji ravni storitev in odzivom na incidente pokriva celotno platformo.

04 Premisleki in omejitve

Tehnični premisleki in omejitve

  • Suverenost ima več stopenj

    Kako to rešujemo

    Delovne obremenitve razvrstimo po občutljivosti in vsakemu razredu priredimo možnost: regije EU velikega ponudnika oblačnih storitev, ponudbo suverenega oblaka ali zasebno infrastrukturo. Kompromise pri funkcijah, stroških in delovanju zapišemo.

    Omejitve in odvisnosti

    Suvereni oblaki pogosto zaostajajo pri upravljanih storitvah, tudi pri storitvah UI. Nekatere obremenitve bodo tam dražje ali bodo zmogle manj, in to je poslovna odločitev.

  • Platforma potrebuje lastnika izdelka

    Kako to rešujemo

    Notranjo platformo obravnavamo kot izdelek z uporabniki, načrtom razvoja in povratnimi informacijami ter vam pomagamo vzpostaviti ekipo, ki jo upravlja.

    Omejitve in odvisnosti

    Platforma brez ekipe postane ozko grlo. Če ekipe ne morete zagotoviti, vam bomo priporočili upravljane storitve in manj abstrakcij.

  • Predpisi oblikujejo delovanje

    Kako to rešujemo

    Razvrščanje incidentov, roki za poročanje in zbiranje dokazov so vgrajeni v postopek za incidente, kjer za vas veljata ZInfV-1 ali DORA.

    Omejitve in odvisnosti

    Ali spadate v obseg zakona in kako se uporablja nacionalni prenos direktive, ostane odločitev vaše službe za skladnost in pravnih svetovalcev.

  • Nadzor stroškov je skupna naloga

    Kako to rešujemo

    Stroške naredimo vidne po izdelkih in dodamo varovala, kot so proračuni, kvote in načrtovan izklop nedejavnih okolij.

    Omejitve in odvisnosti

    Največji prihranki običajno izhajajo iz odločitev o arhitekturi in uporabi, ki jih sprejemajo lastniki izdelkov, ne le iz platforme.

05 Kako delamo

Kako delamo

Najprej osnove, nato ena ekipa na preverjeni poti, nato vsi ostali.

  1. 01

    Ocena in razvrstitev

    Delovne obremenitve, občutljivost podatkov, sedanji stroški in kontrole, ki jih pričakujejo vaši revizorji.

    RezultatRazvrstitev obremenitev in ciljne možnosti

  2. 02

    Postavitev landing zone

    Vse kot koda, pregledano z varnostno službo, s postopkom za izjeme.

    RezultatLanding zone v produkciji

  3. 03

    Prva pilotna ekipa

    Ena produktna ekipa preide na preverjeno pot; njene težave oblikujejo platformo.

    RezultatPrva storitev na platformi

  4. 04

    Širitev in predaja

    Pridružijo se nove ekipe, ekipa platforme prevzame odgovornost, obnova pa se redno preizkuša.

    RezultatNačrt razvoja platforme in poročila o preizkusih obnove

06 Človeški nadzor

Kje odloča človek

Avtomatizacija poganja platformo. Ljudje so odgovorni za odločitve, ki prinašajo tveganje ali strošek.

  • Spremembe v produkciji so sledljive

    Vsaka sprememba v produkciji izhaja iz pregledanega vnosa v repozitorij, zato je vedno zapisano, kdo je kaj spremenil in kdo je to odobril.

  • Izredni dostop je redek in zabeležen

    Dostop v sili je časovno omejen, potrebuje utemeljitev in se naknadno pregleda.

  • Izjeme od pravil imajo lastnika

    Ko delovna obremenitev potrebuje izjemo od varovala, jo odobri imenovani lastnik tveganja, z datumom poteka.

  • Cilje določijo lastniki storitev

    Cilje obnove in ravni storitev dogovorimo s poslovnim lastnikom vsake storitve, ne določi jih le ekipa platforme.

07 Tehnologije

Tehnologije, s katerimi delamo

Oblak
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Ponudbe evropskega suverenega oblaka
Infrastruktura in dostava
  • Terraform in OpenTofu
  • Bicep
  • Argo CD in Flux
  • GitHub Actions, GitLab CI in Azure DevOps
Izvajalno okolje
  • Kubernetes in upravljane različice
  • Platforme brez strežnikov in za vsebnike
  • Storitvena mreža, kjer se izplača
  • Skupine vozlišč GPU za obremenitve UI
Delovanje
  • OpenTelemetry
  • Prometheus in Grafana
  • Spremljanje z orodji oblačnih ponudnikov
  • Pogoni pravil, kot je OPA

Navedba tehnologije opisuje naše inženirske izkušnje. Ne pomeni partnerstva z njenim ponudnikom ali njegove podpore.

08 Primer

Ponazoritveni primer

Ponazoritveni primer

Skupna landing zone za industrijsko skupino z družbami v treh državah

01Izhodišče
Industrijska skupina z družbami v Sloveniji, na Hrvaškem in v Avstriji ima ločene oblačne najemnike z različnimi kontrolami. Družba v Sloveniji je pomemben subjekt po ZInfV-1, vsak nacionalni organ pričakuje poročanje o incidentih po svojih pravilih, varnostnega stanja skupine pa nihče ne zna prikazati v enem pogledu.
02Kaj bi zgradili
Ena landing zone v kodi z nabori pravil za vsako družbo, skupnim beleženjem in postopkom za incidente, ki poročila razvrsti in usmeri glede na državo.
03Kje odloča človek
Varnostni pooblaščenec vsake družbe odobri izjeme od pravil za njene obremenitve; za skupno izhodišče je odgovoren vodja informacijske varnosti skupine.
04Kaj bi merili
Čas od zaznave incidenta do razvrstitve, delež obremenitev pod pravili in število uspešnih preizkusov obnove na četrtletje.

09 Panoge

V vaši panogi

  • Javni sektor

    Možnosti suverenosti za vsak razred podatkov, dokazila za varnostne zahteve naročnika in izhodni načrti, ki zdržijo tudi naslednje javno naročilo.

  • Finančne storitve

    Digitalna operativna odpornost po uredbi DORA: preizkušena obnova, nadzor tretjih ponudnikov storitev IKT in poročanje o incidentih, vgrajeno v delovanje.

Slovenija

Dokazila enkrat, za vsakega nadzornika

Direktivo NIS 2 v Sloveniji prenaša Zakon o informacijski varnosti (ZInfV-1, Uradni list RS, št. 40/25), ki velja od 19. junija 2025. Pristojni nacionalni organ in enotna kontaktna točka je Urad Vlade Republike Slovenije za informacijsko varnost (URSIV). Nacionalni prenosi direktive se med državami razlikujejo po obsegu in podrobnostih poročanja, zato skupina z družbami v več državah potrebuje platformo, ki pripravi dokazila za vsak organ.

Za finančne subjekte velja še uredba DORA. Uredba o izvajanju uredbe (EU) o digitalni operativni odpornosti za finančni sektor (Uradni list RS, št. 25/25), ki velja od 26. aprila 2025, določa pristojne organe: Banko Slovenije, Agencijo za trg vrednostnih papirjev in Agencijo za zavarovalni nadzor. Večje incidente, povezane z IKT, finančni subjekti sporočajo svojemu pristojnemu organu in skupinam CSIRT.

Landing zone zasnujemo tako, da so lokacija hrambe podatkov, beleženje in razvrščanje incidentov pravila, ne projekti, zato novo družbo ali državo dodamo s konfiguracijo. Izhodni načrti se opirajo na pravice do zamenjave ponudnika iz Akta o podatkih in so preizkušeni, ne le zapisani.

Vprašanja o oblaku in platformah

Katerega ponudnika oblačnih storitev priporočate?

Tistega, ki ustreza vašim delovnim obremenitvam, obstoječim pogodbam in zahtevam glede suverenosti. Delamo z velikimi ponudniki oblačnih storitev in s ponudbami evropskega suverenega oblaka, kompromise pa dokumentiramo, da je izbiro mogoče utemeljiti v javnem naročilu in jo pozneje ponovno pretehtati.

Ali potrebujemo Kubernetes?

Ne vedno. Kubernetes se izplača, ko poganjate veliko storitev in imate ekipo za upravljanje platforme. Za peščico storitev so upravljane platforme za vsebnike ali platforme brez strežnikov pogosto preprostejše in cenejše.

Kako pristopate k varnosti?

Varnost je vgrajena v landing zone in cevovode: identitete z najmanjšimi potrebnimi pravicami, pravila kot koda, podpisani artefakti in skrivnosti, ki nikoli niso v kodi. FromNine ima certifikat ISO/IEC 27001 za upravljanje informacijske varnosti.

Ali lahko zmanjšate naše stroške oblaka?

Običajno da, vendar ne bomo obljubljali odstotka, preden vidimo podatke. Najprej naredimo stroške vidne po izdelkih, nato z lastniki, ki lahko ukrepajo, obdelamo seznam možnih prihrankov.

Kako se izognemo vezavi na enega ponudnika?

Tako, da premišljeno izberete, kje boste odvisni od storitev, značilnih za ponudnika, infrastrukturo vodite v kodi in vzdržujete dokumentiran in preizkušen izhodni načrt. Akt o podatkih krepi vaše pravice do zamenjave ponudnika, izhodni načrt pa omogoči, da jih lahko uporabite.

Pokažite nam svoje naslednje tri izdaje

Povedali vam bomo, kaj bi jih naredilo rutinske in koliko bi stala postavitev in delovanje takšne osnove.

Opišite svoj projektArhitektura in svetovanje