Přejít na hlavní obsah
FromNine
Nabídka

Vývoj

Cloudové základy, díky kterým je vydání rutina.

Stavíme cloudové základy a interní vývojářské platformy, kde jsou prostředí definovaná kódem, vydání podepsaná a opakovatelná a každá koruna nákladů má svého vlastníka.

Pro firmy a instituce v Česku, na které dopadá nový zákon o kybernetické bezpečnosti nebo DORA a které chtějí jeden cloudový základ pro všechny své společnosti.

Domluvit konzultaciZobrazit referenční architekturu
Cloud a platformní inženýrství: vrstvy schopnostíČtyři vrstvy nad sebou. Shora dolů: aplikace produktových týmů, interní vývojářská platforma, podepsané pipeline pro dodávky a v základu landing zóna s identitou, sítí a pravidly.01Aplikace produktových týmů02Interní vývojářská platforma03Podepsané pipeline dodávek04Landing zóna a pravidla
  1. 01Landing zóny s pravidly jako kódem a umístěním dat určeným pro každou aplikaci
  2. 02Ověřené cesty, po kterých nová služba opakovatelně dojde až do provozu
  3. 03SLO, otestovaná obnova a náklady na produkt, viditelné pro ty, kdo rozhodují

01 Problémy

Známky, že vás základy brzdí

  1. 01

    Každé prostředí je originál

    Test a produkce se liší způsobem, který nikdo nezapsal, a ruční opravy v konzoli se při dalším sestavení ztratí.

  2. 02

    Vydání vyžaduje poradu

    Nasazení jsou vzácná, ruční a plánovaná na večer. Týmy proto změny hromadí, a každé vydání je tak rizikovější.

  3. 03

    Účet za cloud všechny překvapí

    Náklady jsou vidět po předplatných, ne po produktech. Kapacitu GPU pro práci s AI si rezervuje ten, kdo se přihlásil první.

  4. 04

    Nikdo neví, jestli obnova funguje

    Zálohy existují. Obnova se netestovala a doba obnovy ani přípustná ztráta dat se s byznysem nikdy nedohodly.

02 Co dodáváme

Co dodáváme

  1. 01 Landing zóny a možnosti suverenity

    Struktura účtů a předplatných, identita, síť a mantinely u velkých poskytovatelů cloudu i u evropských suverénních nabídek, s pravidly jako kódem a umístěním dat pro každou aplikaci.

    Co děláme

    • Návrh organizace, skupin pro správu a účtů
    • Centrální síť, řízení odchozího provozu a privátní konektivita
    • Pravidla jako kód pro umístění dat, šifrování a štítkování
    • Mapování na osvědčení, která požadují vaši zákazníci, například BSI C5 v Německu nebo SecNumCloud ve Francii

    Co dostanete

    • Landing zóna definovaná celá v kódu
    • Knihovna pravidel s postupem pro výjimky
    • Přehled možností suverenity pro každou třídu aplikací

  2. 02 Infrastruktura jako kód a interní vývojářské platformy

    Terraform nebo OpenTofu a Bicep pro infrastrukturu, GitOps pro nasazení, Kubernetes nebo spravovaná běhová prostředí tam, kde se hodí, a ověřené cesty, díky kterým tým založí službu v souladu s pravidly bez zakládání tiketů.

    Co děláme

    • Knihovna modulů pro infrastrukturu jako kód
    • GitOps s povyšováním mezi prostředími
    • Platforma Kubernetes nebo spravované alternativy
    • Šablony služeb a vývojářský portál

    Co dostanete

    • Interní vývojářská platforma s ověřenými cestami
    • Prostředí v samoobsluze
    • Roadmapa platformy, kterou vlastní platformní tým

  3. 03 Pipeline dodávek a bezpečnost dodavatelského řetězce

    Pipeline, které sestavují jednou, podepisují artefakty, zaznamenávají původ v souladu se SLSA, správně spravují tajné klíče a povyšují stejný artefakt z testu do produkce.

    Co děláme

    • Šablony pipeline s kontrolami kvality a bezpečnosti
    • Podepisování artefaktů a atestace původu
    • Správa tajných klíčů a jejich rotace
    • Pravidla povýšení a záznamy o změnách

    Co dostanete

    • Znovupoužitelné šablony pipeline
    • Podepsané artefakty s ověřitelným původem
    • Podklady o vydání pro řízení změn

  4. 04 Pozorovatelnost a SRE

    Cíle úrovně služeb dohodnuté s byznysem, rozpočty chyb, které určují tempo vydávání, OpenTelemetry napříč celým stackem a proces řízení incidentů, který slouží i hlášení podle zákona o kybernetické bezpečnosti a DORA, pokud se na vás vztahují.

    Co děláme

    • Definice SLO s vlastníky služeb
    • Instrumentace pomocí OpenTelemetry a dashboardy
    • Upozornění na příznaky, ne na příčiny
    • Řízení incidentů a jejich následné vyhodnocení

    Co dostanete

    • Katalog SLO
    • Nástroje pozorovatelnosti a dashboardy
    • Provozní příručky pro incidenty a jejich hlášení

  5. 05 FinOps a kapacita pro AI

    Přiřazení nákladů produktům a týmům, jednotková ekonomika, například náklady na transakci, a plánování kapacity GPU a řízení nákladů pro aplikace AI.

    Co děláme

    • Pravidla štítkování a model přiřazení nákladů
    • Jednotkové náklady pro každý produkt
    • Plánování závazků a rezervací
    • Plánování GPU, kvóty a správná velikost zdrojů

    Co dostanete

    • Dashboardy nákladů pro každého produktového vlastníka
    • Backlog úspor s vlastníky
    • Plán kapacity pro AI

  6. 06 Obnova a odchod

    Zálohování a obnova po havárii s výslovně stanovenou dobou obnovy a přípustnou ztrátou dat, pravidelně testované, a strategie odchodu, která využívá práva na změnu poskytovatele podle nařízení o datech.

    Co děláme

    • RTO a RPO dohodnuté pro každou službu
    • Testy obnovy a přepnutí na záložní prostředí
    • Mapování závislostí kritických služeb
    • Plán odchodu a kontroly přenositelnosti dat

    Co dostanete

    • Otestované postupy obnovy
    • Zprávy z testů obnovy
    • Zdokumentovaná strategie odchodu

03 Architektura

Ilustrativní referenční architektura

Vlevo vstupuje kód, vpravo vycházejí běžící aplikace. Mezi tím pipeline podepisuje, co sestaví, registr ukládá jen podepsané artefakty a kontrolér GitOps je podle pravidel povyšuje mezi prostředími.

Pod tím leží landing zóna: organizační struktura, identita, síť, klíče, obnova a řízení nákladů, definované jednou v kódu a sdílené všemi produktovými týmy.

Vrstvy v diagramu

Dodávky
Repozitáře, pipeline, podepsané artefakty a povyšování přes GitOps.
Platforma
Vývojářská platforma, pravidla jako kód a běhové prostředí, do kterého produktové týmy nasazují.
Landing zóna
Organizace, identita, síť, klíče, obnova a řízení nákladů.
Provoz
Telemetrie, SLO, rozpočty chyb a reakce na incidenty napříč celým prostředím.
Ilustrativní příklad

  1. Dodávky

    • Repozitáře kódu a IaC
    • Sestavit, podepsat, atestovat
    • Registr podepsaných artefaktů
    • Povýšení přes GitOps

  2. Platforma

    • Vývojářská platforma a ověřené cesty
    • Pravidla jako kód
    • Kubernetes a spravované služby
    • Aplikace produktových týmů

  3. Landing zóna

    • Struktura správy
    • Identita a přístup
    • Centrální síť a odchozí provoz
    • Klíče a tajné údaje
    • Zálohování a obnova
    • Přiřazení nákladů

  4. Provoz

    • OpenTelemetry, SLO a rozpočty chyb, reakce na incidenty
Podepsané dodávky do landing zóny řízené pravidly

Ilustrativní architektura, nikoli systém klienta.

Zobrazit diagram jako text

Hlavní trasa vede z repozitářů kódu a infrastruktury přes pipeline, které sestavují, podepisují a atestují, do registru artefaktů, potom ke kontroléru GitOps a nakonec do oddělených prostředí produktových týmů.

Interní vývojářská platforma nabízí ověřené cesty k pipeline. Pravidla jako kód omezují kontrolér GitOps. Aplikace hostuje běhová platforma s Kubernetes a spravovanými službami. Klíče spravované zákazníkem napájejí vrstvu pravidel.

Landing zóna pod tím obsahuje strukturu správy, identitu a přístup, centrální síť, klíče, zálohování a obnovu a řízení nákladů. Pozorovatelnost se SLO a reakcí na incidenty pokrývá celou platformu.

04 Úvahy a limity

Technické úvahy a limity

  • Suverenita má mnoho stupňů

    Jak to řešíme

    Aplikace třídíme podle citlivosti a každé třídě přiřadíme možnost: regiony EU velkého poskytovatele cloudu, suverénní cloudovou nabídku, nebo vlastní infrastrukturu. Kompromisy ve funkcích, nákladech a provozu zapíšeme.

    Limity a závislosti

    Suverénní nabídky často zaostávají ve spravovaných službách, včetně služeb AI. Některé aplikace tam budou stát víc nebo umět méně, a to je obchodní rozhodnutí.

  • Platforma potřebuje produktového vlastníka

    Jak to řešíme

    Interní platformu řídíme jako produkt s uživateli, roadmapou a zpětnou vazbou a pomůžeme vám sestavit tým, který ji provozuje.

    Limity a závislosti

    Platforma bez týmu se stane úzkým hrdlem. Pokud ji nemůžete personálně zajistit, doporučíme spravované služby a méně abstrakcí.

  • Regulace formuje provoz

    Jak to řešíme

    Klasifikaci incidentů, lhůty pro hlášení a sběr podkladů zabudujeme do procesu řízení incidentů tam, kde se na vás vztahuje zákon o kybernetické bezpečnosti nebo DORA.

    Limity a závislosti

    Zda pod tato pravidla spadáte a v jakém režimu povinností, posuzují vaše týmy pro compliance a vaši právníci.

  • Řízení nákladů je společná věc

    Jak to řešíme

    Náklady zviditelníme pro každý produkt a přidáme mantinely, jako jsou rozpočty, kvóty a plánované vypínání nevyužitých prostředí.

    Limity a závislosti

    Největší úspory obvykle přinášejí rozhodnutí o architektuře a využití, která dělají produktoví vlastníci, ne samotná platforma.

05 Jak pracujeme

Jak pracujeme

Nejdřív základy, potom jeden tým na ověřené cestě, pak všichni ostatní.

  1. 01

    Posoudit a klasifikovat

    Aplikace, citlivost dat, současné náklady a kontroly, které očekávají vaši auditoři.

    VýstupKlasifikace aplikací a cílové možnosti

  2. 02

    Postavit landing zónu

    Vše jako kód, revidované s bezpečností, s postupem pro výjimky.

    VýstupLanding zóna v provozu

  3. 03

    Zapojit pilotní tým

    Jeden produktový tým přejde na ověřenou cestu; to, co ho brzdí, utváří platformu.

    VýstupPrvní služba na platformě

  4. 04

    Rozšířit a předat

    Přidávají se další týmy, platformní tým přebírá vlastnictví a obnova se pravidelně testuje.

    VýstupRoadmapa platformy a zprávy z testů obnovy

06 Kontrola člověkem

Kde rozhoduje člověk

Platformu řídí automatizace. Rozhodnutí, která nesou riziko nebo náklady, vlastní lidé.

  • Změny v produkci jsou dohledatelné

    Každá změna v produkci pochází z revidovaného commitu, takže je vždy zaznamenáno, kdo co změnil a kdo to schválil.

  • Nouzový přístup je výjimečný a zaznamenaný

    Nouzový přístup je časově omezený, vyžaduje zdůvodnění a následně se prověřuje.

  • Výjimky z pravidel mají vlastníka

    Když aplikace potřebuje výjimku z mantinelu, schvaluje ji určený vlastník rizika, a to s datem platnosti.

  • Cíle určují vlastníci služeb

    Cíle obnovy a úrovně služeb se dohodnou s vlastníkem každé služby z byznysu, ne jen s platformním týmem.

07 Technologie

Technologie, se kterými pracujeme

Cloud
  • Microsoft Azure
  • Amazon Web Services
  • Google Cloud
  • Evropské suverénní cloudové nabídky
Infrastruktura a dodávky
  • Terraform a OpenTofu
  • Bicep
  • Argo CD a Flux
  • GitHub Actions, GitLab CI a Azure DevOps
Běhové prostředí
  • Kubernetes a jeho spravované varianty
  • Serverless a kontejnerové platformy
  • Service mesh tam, kde se vyplatí
  • GPU uzly pro aplikace AI
Provoz
  • OpenTelemetry
  • Prometheus a Grafana
  • Cloudový monitoring
  • Nástroje pro vyhodnocování pravidel, například OPA

Uvedení technologie popisuje naše inženýrské zkušenosti. Neznamená partnerství s jejím dodavatelem ani jeho doporučení.

08 Příklad

Ilustrativní příklad

Ilustrativní příklad

Společná landing zóna pro skupinu pod novým zákonem o kybernetické bezpečnosti

01Situace
Tři dceřiné společnosti provozují oddělená cloudová prostředí s různými kontrolami. Dvě z nich podle vlastního posouzení spadají pod zákon o kybernetické bezpečnosti, jedna v režimu vyšších a jedna v režimu nižších povinností, a nikdo neumí ukázat bezpečnostní stav skupiny v jednom pohledu.
02Co bychom postavili
Jedna landing zóna v kódu se sadami pravidel pro každou společnost, sdíleným logováním a procesem řízení incidentů, který klasifikuje události a připravuje podklady pro hlášení NÚKIB podle režimu dané společnosti.
03Kde rozhoduje člověk
Bezpečnostní manažer každé společnosti schvaluje výjimky z pravidel pro své aplikace; CISO skupiny vlastní společný základ.
04Co bychom měřili
Čas od zjištění incidentu po jeho klasifikaci, podíl aplikací pod pravidly a počet úspěšných testů obnovy za čtvrtletí.

09 Podle odvětví

Ve vašem odvětví

  • Veřejná správa

    Možnosti suverenity podle třídy dat, bezpečnostní opatření podle zákona o kybernetické bezpečnosti a plány odchodu, které obstojí i při příští veřejné zakázce.

  • Finanční služby

    Provozní odolnost podle DORA pod dohledem České národní banky: otestovaná obnova, dohled nad poskytovateli ICT služeb a hlášení incidentů zabudované do provozu.

Česko

Podklady jednou, pro každý orgán dohledu

Zákon č. 264/2025 Sb., o kybernetické bezpečnosti, je účinný od 1. listopadu 2025. Rozlišuje režim vyšších a nižších povinností, každý s vlastní vyhláškou o bezpečnostních opatřeních, a regulované subjekty se registrují samy přes Portál NÚKIB. Finanční instituce mají navíc DORA s vlastním hlášením incidentů a dohledem nad třetími stranami, s Českou národní bankou jako příslušným orgánem dohledu. Skupina se společnostmi v dalších zemích EU k tomu potkává jiná národní provedení směrnice NIS 2.

Navrhujeme landing zóny, kde jsou umístění dat, logování a klasifikace incidentů pravidly, ne projekty, takže novou společnost nebo zemi připojíte konfigurací. Plány odchodu stojí na právech na změnu poskytovatele podle nařízení o datech a testují se, ne jen sepisují.

Časté dotazy ke cloudu a platformnímu inženýrství

Kterého poskytovatele cloudu doporučujete?

Toho, který odpovídá vašim aplikacím, stávajícím smlouvám a požadavkům na suverenitu. Pracujeme s velkými poskytovateli cloudu i s evropskými suverénními nabídkami a kompromisy zapisujeme, aby se volba dala obhájit ve veřejné zakázce i později přehodnotit.

Potřebujeme Kubernetes?

Ne vždy. Kubernetes se vyplatí, když provozujete mnoho služeb a máte tým, který platformu udrží. Pro několik služeb bývají spravované kontejnerové nebo serverless platformy jednodušší a levnější na provoz.

Jak přistupujete k bezpečnosti?

Bezpečnost je zabudovaná do landing zóny a do pipeline: identity s minimálními oprávněními, pravidla jako kód, podepsané artefakty a tajné klíče, které nikdy neleží v kódu. Společnost FromNine je certifikována podle ISO/IEC 27001 pro řízení bezpečnosti informací.

Dokážete snížit naše náklady na cloud?

Obvykle ano, ale procenta neslibujeme, dokud neuvidíme data. Začneme tím, že náklady zviditelníme pro každý produkt, a potom s vlastníky, kteří mohou jednat, procházíme backlog úspor.

Jak se vyhnout závislosti na jednom poskytovateli?

Vědomou volbou, kde se spolehnout na služby konkrétního poskytovatele, infrastrukturou v kódu a zdokumentovaným, otestovaným plánem odchodu. Nařízení o datech posiluje vaše práva na změnu poskytovatele; plán odchodu je dělá použitelnými.

Ukažte nám svá příští tři vydání

Řekneme vám, co by z nich udělalo rutinu a kolik by takový základ stál postavit a provozovat.

Domluvit konzultaciArchitektura a poradenství