Ugrás a fő tartalomra
FromNine
Menü

Fejlesztés

Felhőalapok, amelyekkel a kiadás rutinná válik.

Olyan felhőalapokat és belső fejlesztői platformokat építünk, ahol a környezetek kódként léteznek, a kiadások aláírtak és megismételhetők, és minden költségtételnek van gazdája.

Olyan szervezeteknek, amelyek egy felhőalapot működtetnek több ország jogi személyei számára, mindegyik a saját felügyeleti hatóságával.

Beszéljük meg a projektjétReferencia­architektúra
Felhő- és platform­fejlesztés: képességrétegekNégy egymásra épülő réteg. Fentről lefelé: a termékcsapatok munkaterhelései, a belső fejlesztői platform, az aláírt szállítási láncok, alul pedig a landing zone identitáskezeléssel, hálózattal és szabályokkal.01Termékcsapatok munkaterhelései02Belső fejlesztői platform03Aláírt szállítási láncok04Landing zone és szabályok
  1. 01Landing zone (alapozó felhőkörnyezet) kódként kezelt szabályokkal, munkaterhelésenként meghatározott adattárolási hellyel
  2. 02Golden path-ok, amelyek egy új szolgáltatást megismételhető módon visznek éles üzembe
  3. 03SLO-k, tesztelt helyreállítás és termékenkénti költség, láthatóan azoknak, akik döntenek

01 Problémák

Jelek, hogy az alapok visszafogják

  1. 01

    Minden környezet egyedi darab

    A teszt- és az éles környezet olyan módon tér el, amelyet senki sem írt le, és a konzolon kézzel végzett javítások a következő újraépítéskor elvesznek.

  2. 02

    Egy kiadáshoz értekezlet kell

    A telepítések ritkák, kézi munkával és esti időpontra ütemezve zajlanak. A csapatok összegyűjtik a változtatásokat, ami minden kiadást kockázatosabbá tesz.

  3. 03

    A felhőszámla mindenkit meglep

    A költség előfizetésenként látszik, nem termékenként. Az MI-munkához szükséges GPU-kapacitást az foglalja le, aki előbb kérte.

  4. 04

    Senki sem tudja, működik-e a helyreállítás

    Van mentés. A visszaállítást nem tesztelték, a helyreállítási időt és az elfogadható adatvesztést pedig soha nem egyeztették az üzleti területtel.

02 Szállítási tételek

Amit szállítunk

  1. 01 Landing zone-ok és szuverenitási lehetőségek

    Fiók- és előfizetési struktúra, identitáskezelés, hálózat és védőkorlátok a nagy felhőszolgáltatóknál és az uniós szuverén felhőkínálatokban, kódként kezelt szabályokkal és munkaterhelésenként meghatározott adattárolási hellyel.

    Amit csinálunk

    • A szervezet, a felügyeleti csoportok és a fiókok megtervezése
    • Központi hálózat, kimenőforgalom-szabályozás és privát kapcsolat
    • Kódként kezelt szabályok az adattárolási helyre, a titkosításra és a címkézésre
    • Leképezés a kiberbiztonsági audithoz és a vevői által kért egyéb igazolásokhoz szükséges bizonyítékokra

    Amit Ön kap

    • Teljes egészében kódban definiált landing zone
    • Szabálykönyvtár kivételkezelési folyamattal
    • Szuverenitási döntési javaslat munkaterhelés-osztályonként

  2. 02 Infrastruktúra kódként és belső fejlesztői platformok

    Terraform vagy OpenTofu és Bicep az infrastruktúrához, GitOps a telepítésekhez, Kubernetes vagy menedzselt futtatókörnyezetek, ahol illenek, és golden path-ok, hogy egy csapat jegykezelés nélkül indíthasson szabálykövető szolgáltatást.

    Amit csinálunk

    • Modulkönyvtár a kódként kezelt infrastruktúrához
    • GitOps környezetek közötti előléptetéssel
    • Kubernetes-platform vagy menedzselt alternatívák
    • Szolgáltatássablonok és fejlesztői portál

    Amit Ön kap

    • Belső fejlesztői platform golden path-okkal
    • Önkiszolgáló környezetek
    • Platformütemterv egy platformcsapat felelősségében

  3. 03 Szállítási láncok és ellátásilánc-biztonság

    Szállítási láncok, amelyek egyszer buildelnek, aláírják a csomagokat, az SLSA szerint rögzítik az eredetet, szakszerűen kezelik a titkokat, és ugyanazt a csomagot léptetik elő a tesztből az éles üzembe.

    Amit csinálunk

    • Láncsablonok minőségi és biztonsági kapukkal
    • Csomagaláírás és eredetigazolás
    • Titokkezelés és kulcsrotáció
    • Előléptetési szabályok és változási nyilvántartás

    Amit Ön kap

    • Újrahasznosítható láncsablonok
    • Aláírt csomagok ellenőrizhető eredettel
    • Kiadási bizonyítékok a változáskezeléshez

  4. 04 Megfigyelhetőség és SRE

    Az üzleti területtel egyeztetett szolgáltatási célok, a kiadási tempót irányító hibakeretek, OpenTelemetry a teljes rendszeren és olyan incidenskezelési folyamat, amely ott, ahol alkalmazandók, a kiberbiztonsági törvény és a DORA bejelentési kötelezettségeit is kiszolgálja.

    Amit csinálunk

    • SLO-k meghatározása a szolgáltatásgazdákkal
    • OpenTelemetry-mérőpontok és irányítópultok
    • Riasztás tünetekre, nem okokra
    • Incidenskezelés és incidens utáni áttekintés

    Amit Ön kap

    • SLO-katalógus
    • Megfigyelhetőségi eszközkészlet és irányítópultok
    • Incidenskezelési és bejelentési útmutatók

  5. 05 FinOps és MI-kapacitás

    Költségfelosztás termékenként és csapatonként, egységköltségek, például tranzakciónkénti költség, valamint GPU-kapacitástervezés és költségkontroll az MI-munkaterhelésekhez.

    Amit csinálunk

    • Címkézési szabályzat és felosztási modell
    • Egységköltség-mutatók termékenként
    • Kötelezettségvállalások és foglalások tervezése
    • GPU-ütemezés, kvóták és méretezés

    Amit Ön kap

    • Költség-irányítópultok termékgazdánként
    • Megtakarítási várólista felelősökkel
    • MI-kapacitásterv

  6. 06 Helyreállítás és kilépés

    Mentés és katasztrófa utáni helyreállítás kifejezett helyreállítási idő- és pontcélokkal, ütemezetten tesztelve, és olyan kilépési stratégia, amely az uniós adatrendelet szolgáltatóváltási jogaira épül.

    Amit csinálunk

    • RTO és RPO szolgáltatásonként egyeztetve
    • Visszaállítási és átállási tesztek
    • A kritikus szolgáltatások függőségeinek feltérképezése
    • Kilépési terv és az adathordozhatóság ellenőrzése

    Amit Ön kap

    • Tesztelt helyreállítási eljárások
    • Helyreállítási tesztjelentések
    • Dokumentált kilépési stratégia

03 Architektúra

Szemléltető referencia­architektúra

Bal oldalon kód megy be, jobb oldalon futó munkaterhelés jön ki. Közben a szállítási lánc aláírja, amit buildel, a tár csak aláírt csomagokat tárol, egy GitOps-vezérlő pedig szabályok szerint lépteti elő őket a környezeteken át.

Alul a landing zone áll: szervezeti struktúra, identitáskezelés, hálózat, kulcsok, helyreállítás és költségkontroll, egyszer kódban definiálva és minden termékcsapat számára közösen.

A rajz rétegei

Szállítás
Tárolók, szállítási láncok, aláírt csomagok és GitOps-előléptetés.
Platform
A fejlesztői platform, a kódként kezelt szabályok és a futtatókörnyezet, amelyre a termékcsapatok telepítenek.
Landing zone
Szervezet, identitáskezelés, hálózat, kulcsok, helyreállítás és FinOps-kontrollok.
Üzemeltetés
Telemetria, SLO-k, hibakeretek és incidenskezelés az egészre kiterjedően.
Szemléltető példa

  1. Szállítás

    • Kód- és IaC-tárolók
    • Build, aláírás, igazolás
    • Aláírt csomagok tára
    • GitOps-előléptetés

  2. Platform

    • Fejlesztői platform és golden path-ok
    • Szabályok kódként
    • Kubernetes és menedzselt szolgáltatások
    • Termékcsapatok munkaterhelései

  3. Landing zone

    • Felügyeleti struktúra
    • Identitás és hozzáférés
    • Központi hálózat és kimenő forgalom
    • Kulcsok és titkok
    • Mentés és helyreállítás
    • Költségfelosztás

  4. Üzemeltetés

    • OpenTelemetry, SLO-k és hibakeretek, incidenskezelés
Aláírt szállítás szabályozott landing zone-ra

Szemléltető architektúra, nem ügyfélrendszer.

Az ábra szöveges változata

A fő útvonal a kód- és infrastruktúra-tárolóktól a buildelő, aláíró és eredetet igazoló szállítási láncokon át egy csomagtárba, onnan egy GitOps-vezérlőbe, végül a termékcsapatok munkaterheléseihez vezet.

Egy belső fejlesztői platform golden path-okat ad a szállítási láncokhoz. Kódként kezelt szabályok korlátozzák a GitOps-vezérlőt. A munkaterheléseket egy Kubernetesből és menedzselt szolgáltatásokból álló futtatókörnyezet fogadja. Az ügyfél által kezelt kulcsok a szabályréteget látják el.

Alul a landing zone tartalmazza a felügyeleti struktúrát, az identitás- és hozzáféréskezelést, a központi hálózatot, a kulcsokat, a mentést és a helyreállítást, valamint a FinOps-kontrollokat. Az SLO-kkal és incidenskezeléssel kiegészített megfigyelhetőség az egész platformot átfogja.

04 Szempontok és korlátok

Mérnöki szempontok és korlátok

  • A szuverenitás skála, nem igen vagy nem

    Hogyan kezeljük

    A munkaterheléseket érzékenység szerint osztályozzuk, és minden osztályhoz egy lehetőséget rendelünk: egy nagy felhőszolgáltató uniós régióit, egy szuverén felhőkínálatot vagy saját infrastruktúrát. A funkciók, a költség és az üzemeltetés közötti kompromisszumokat leírjuk.

    Korlátok és függőségek

    A szuverén kínálatok menedzselt szolgáltatásai, köztük az MI-szolgáltatások, gyakran lemaradnak. Egyes munkaterhelések ott többe kerülnek vagy kevesebbet tudnak, és ez üzleti döntés.

  • Egy platformnak termékgazda kell

    Hogyan kezeljük

    A belső platformot termékként kezeljük, felhasználókkal, ütemtervvel és visszajelzési körökkel, és segítünk felállítani az azt működtető csapatot.

    Korlátok és függőségek

    Csapat nélkül a platform szűk keresztmetszetté válik. Ha nem tud csapatot rendelni hozzá, menedzselt szolgáltatásokat és kevesebb absztrakciót javaslunk.

  • A szabályozás alakítja az üzemeltetést

    Hogyan kezeljük

    Ahol a kiberbiztonsági törvény vagy a DORA vonatkozik a szervezetére, az incidensek besorolását, a bejelentési határidőket és a bizonyítékgyűjtést beépítjük az incidenskezelési folyamatba.

    Korlátok és függőségek

    Annak megállapítása, hogy szervezete a hatály alá tartozik-e, és hogyan alkalmazandó rá a hazai szabályozás, a megfelelési és jogi csapatainál marad.

  • A költségkontroll közös feladat

    Hogyan kezeljük

    Termékenként láthatóvá tesszük a költséget, és védőkorlátokat adunk hozzá, például kereteket, kvótákat és a tétlen környezetek ütemezett leállítását.

    Korlátok és függőségek

    A legnagyobb megtakarítás általában a termékgazdák architektúra- és használati döntéseiből jön, nem önmagában a platformból.

05 Hogyan dolgozunk

Hogyan dolgozunk

Először az alapok, aztán egy csapat a golden path-on, aztán mindenki más.

  1. 01

    Felmérés és besorolás

    Munkaterhelések, adatérzékenység, jelenlegi költségek és az auditorai által elvárt kontrollok.

    EredményMunkaterhelés-besorolás és céllehetőségek

  2. 02

    A landing zone felépítése

    Minden kódként, az információbiztonsággal átvizsgálva, kivételkezelési folyamattal.

    EredményLanding zone éles üzemben

  3. 03

    Egy mintacsapat bevonása

    Egy termékcsapat átáll a golden path-ra; az általa tapasztalt súrlódások formálják a platformot.

    EredményAz első szolgáltatás a platformon

  4. 04

    Kiterjesztés és átadás

    Újabb csapatok csatlakoznak, a platformcsapat átveszi a felelősséget, a helyreállítást pedig ütemezetten teszteljük.

    EredményPlatformütemterv és helyreállítási tesztjelentések

06 Emberi kontroll

Ahol az ember dönt

A platformot automatizálás működteti. A kockázattal vagy költséggel járó döntések emberekhez tartoznak.

  • Az éles változások visszakövethetők

    Az éles környezet minden változása egy átnézett commitból származik, így mindig rögzítve van, ki mit változtatott, és ki hagyta jóvá.

  • A vészhozzáférés ritka és naplózott

    A vészhelyzeti hozzáférés időkorlátos, indoklást igényel, és utólag felülvizsgáljuk.

  • A szabály­kivételeknek gazdája van

    Ha egy munkaterhelésnek kivétel kell egy védőkorlát alól, egy megnevezett kockázati gazda hagyja jóvá, lejárati dátummal.

  • A célokat a szolgáltatás­gazdák határozzák meg

    A helyreállítási célokat és a szolgáltatási szinteket minden szolgáltatás üzleti gazdájával egyeztetjük, nem egyedül a platformcsapat határozza meg őket.

07 Technológiák

Technológiák, amelyekkel dolgozunk

Felhő
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Uniós szuverén felhőkínálatok
Infrastruktúra és szállítás
  • Terraform és OpenTofu
  • Bicep
  • Argo CD és Flux
  • GitHub Actions, GitLab CI és Azure DevOps
Futtatókörnyezet
  • Kubernetes és menedzselt változatai
  • Serverless és konténerplatformok
  • Service mesh, ahol megtérül
  • GPU-csomópontkészletek MI-munkaterhelésekhez
Üzemeltetés
  • OpenTelemetry
  • Prometheus és Grafana
  • Felhőnatív monitorozás
  • Szabálymotorok, például OPA

Egy technológia felsorolása a mérnöki tapasztalatunkat írja le. Nem jelent partnerséget a gyártóval, és nem jelenti azt, hogy a gyártó ajánlana minket.

08 Példa

Szemléltető példa

Szemléltető példa

Közös landing zone egy, az SZTFH által felügyelt szervezetnek

01Helyzet
Egy gépgyártó vállalat fontos szervezetként a kiberbiztonsági törvény hatálya alá tartozik, és az SZTFH felügyeli. Három üzletága külön felhőkörnyezetet használ eltérő kontrollokkal, és az első kiberbiztonsági auditnál a bizonyítékokat kézzel kellett összegyűjteni.
02Amit építenénk
Egyetlen kódban definiált landing zone üzletágankénti szabálykészletekkel, közös naplózással és olyan incidenskezelési folyamattal, amely besorolja az incidenseket, és előkészíti a bejelentéseket. Az auditbizonyítékokat a platform folyamatosan állítja elő.
03Ahol ember dönt
Az üzletágak informatikai biztonsági felelősei hagyják jóvá a saját munkaterheléseikre vonatkozó szabálykivételeket; a közös alapszabályokért a vállalat információbiztonsági vezetője felel.
04Amit mérnénk
Az incidens észlelésétől a besorolásig eltelt idő, a szabályok alá vont munkaterhelések aránya és a negyedévente sikeresen lefutott helyreállítási tesztek száma.

09 Ágazati nézőpont

Az Ön ágazatában

  • Közszféra

    Szuverenitási lehetőségek adatosztályonként, a kiberbiztonsági törvény követelményeihez illesztett bizonyítékok az NKI által felügyelt szervezeteknek és kilépési tervek, amelyek a következő közbeszerzést is túlélik.

  • Pénzügyi szolgáltatások

    Működési reziliencia a DORA szerint, amelynek hazai végrehajtását a Magyar Nemzeti Bank látja el: tesztelt helyreállítás, a harmadik fél IKT-szolgáltatók felügyelete és az üzemeltetésbe épített incidensbejelentés.

Magyarország

Egyszer előállított bizonyíték minden felügyeletnek

Magyarországon a NIS2-irányelvet a kiberbiztonsági törvény (2024. évi LXIX. törvény) ülteti át, amely 2025. január 1. óta hatályos: a magánszféra alapvető és fontos szervezeteit az SZTFH, a közigazgatást és az állami szervezeteket az NKI felügyeli. A meglévő szervezeteknek 2025. február 15-ig kellett bejelentkezniük az SZTFH-nál, az első kiberbiztonsági auditot pedig 2025. december 31-ig kellett lezárniuk. A pénzügyi szervezeteknél ehhez jön a DORA a saját incidensbejelentési szabályaival és a harmadik fél IKT-szolgáltatók felügyeletével, amelynek hazai végrehajtását a Magyar Nemzeti Bank látja el.

Egy több országban működő csoportnak olyan platform kell, amely minden hatóság számára elő tudja állítani a kért bizonyítékot. Olyan landing zone-okat tervezünk, ahol az adattárolási hely, a naplózás és az incidensek besorolása szabály, nem projekt, így egy új jogi személy vagy ország konfigurációval csatlakozik. A kilépési tervek az uniós adatrendelet szolgáltatóváltási jogaira épülnek, és teszteljük őket, nem csak leírjuk.

Kérdések a felhő- és platform­fejlesztésről

Melyik felhőszolgáltatót ajánlják?

Azt, amelyik illik a munkaterheléseihez, a meglévő szerződéseihez és a szuverenitási követelményeihez. A nagy felhőszolgáltatókkal és uniós szuverén kínálatokkal egyaránt dolgozunk, és dokumentáljuk a kompromisszumokat, hogy a választás egy közbeszerzésben megvédhető és később felülvizsgálható legyen.

Szükségünk van Kubernetesre?

Nem mindig. A Kubernetes akkor térül meg, ha sok szolgáltatást futtat, és van csapata a platform üzemeltetésére. Néhány szolgáltatáshoz a menedzselt konténer- vagy serverless platformok gyakran egyszerűbbek és olcsóbbak.

Hogyan közelítik meg a biztonságot?

A biztonság a landing zone-ba és a szállítási láncokba van beépítve: legkisebb jogosultságú identitások, kódként kezelt szabályok, aláírt csomagok és titkok, amelyek soha nem kerülnek a kódba. Maga a FromNine ISO/IEC 27001 szerint tanúsított információbiztonsági irányítási rendszerrel működik.

Csökkenteni tudják a felhőköltségeinket?

Általában igen, de százalékot nem ígérünk, amíg nem láttuk az adatokat. Azzal kezdjük, hogy termékenként láthatóvá tesszük a költséget, majd a cselekedni képes gazdákkal végigmegyünk a megtakarítási várólistán.

Hogyan kerüljük el a szolgáltatói kötöttséget?

Tudatos döntéssel arról, hol támaszkodunk szolgáltatóspecifikus szolgáltatásokra, az infrastruktúra kódban tartásával és egy dokumentált, tesztelt kilépési terv fenntartásával. Az uniós adatrendelet erősíti a szolgáltatóváltási jogait; a kilépési terv teszi őket használhatóvá.

Mutassa meg a következő három kiadását

Megmondjuk, mi tenné őket rutinná, és mennyibe kerülne ennek az alapnak a felépítése és működtetése.

Beszéljük meg a projektjétArchitektúra és tanácsadás