Plexo: fintech platforma, kde je vše v kódu a každá změna prochází revizí
Plexo (plexo.global) je síť pro vypořádání plateb ve stablecoinech pro licencované finanční instituce. Od listopadu 2025 jejich platformu na AWS provozuje náš managed DevOps tým. Stejné postupy používáme u každého klienta.
Klient: PlexoObor: FintechCloud: AWSOd: listopadu 2025Naše role: managed DevOps tým
- V kódukaždý účet, síť, identita i pipeline je definovaná v Gitu
- Revidovánokaždá změna se do produkce dostane přes pull request
- Vyzkoušenoobnova produkce reálně otestovaná a zapsaná do runbooku
- Bez klíčůpipeline se přihlašují krátkodobými identitami, žádné uložené cloudové klíče
Výchozí situace
Co musí zvládnout platforma pro licencované instituce
Plexo spolupracuje s licencovanými finančními institucemi a kterákoli z nich může požádat o due diligence. Platforma musela na tyto otázky odpovídat v klidu, zatímco vývojový tým dál rychle dodával s pomocí AI nástrojů pro psaní kódu.
Připravenost na due diligence
Bezpečnostní tým banky se ptá, jak je řízen přístup, kde se zaznamenávají změny a jak se testuje obnova. Každá odpověď má ukazovat na něco, co existuje: kód, log nebo runbook.
Rychlé dodávky, které zůstávají bezpečné
Vývojáři nasazují často a zkoušejí nápady v izolovaných prostředích. Produkce se mění jen přes revizi.
AI nástroje pod kontrolou
AI tým zrychluje. Její práce prochází stejnou revizí a schválením jako práce člověka a riskantní rozhodnutí dělá člověk.
Co stavíme
Platforma vrstvu po vrstvě
Vše je definované jako kód a revidované v pull requestech. Nic nebylo naklikáno v konzoli.
Jak pracujeme
Sedm postupů, na kterých platforma stojí
Firmy, které obsluhují regulované instituce, dostávají od partnerů těžké otázky. Díky těmto postupům jsou odpovědi krátké, protože každá změna je zapsaná, revidovaná a otestovaná.
Landing zone
Workloady běží v oddělených cloudových účtech podle účelu. Lidé se přihlašují přes jednu centrální identitu s krátkodobým přístupem a data jsou ve výchozím stavu šifrovaná.
- Produkce je izolovaná od vývoje a testování.
- Přístup vede přes role a relace, které vyprší, ne přes osobní klíče.
- Šifrovací klíče patří klientovi a automaticky se rotují.
Infrastruktura jako kód, přes pull requesty
Nic se nenaklikává v konzoli. Každá změna je kód, revidovaný v pull requestu s viditelným plánem a aplikovaný pipeline po schválení.
- Revizor přesně vidí, co se změní, než to schválí.
- Pipeline se do cloudu přihlašují krátkodobými identitami, takže neexistují uložené cloudové klíče, které by mohly uniknout.
- Tajemství jsou v secrets manageru, nikdy v Gitu.
GitOps s preview prostředími
Běží to, co popisuje Git, takže nasazení je vidět a rollback je revert. Pull request může dostat vlastní dočasné prostředí, které zmizí, když se pull request uzavře.
- Image se sestaví jednou a do produkce se povyšuje tentýž image.
- Vyzkoušet riskantní nápad nestojí žádný úklid.
- Kdokoli vidí, která verze kde běží.
Observabilita
Metriky, logy, trasování a alerty na jednom místě a k tomu alerting, který se k člověku dostane, i když spadne samotná platforma.
- Alerty chodí do týmového chatu s dostatkem kontextu, aby se podle nich dalo jednat.
- Alarmy na úrovni cloudu a externí kontrola dostupnosti pokrývají případ, kdy platforma nemůže nic nahlásit.
- Metriky dodávek ukazují, jak často změny vycházejí a jak často selžou.
Cvičení obnovy po havárii
Obnovu ze zálohy provádíme naostro a měříme každý krok. Z výsledku vzniká runbook, podle kterého postupuje kdokoli, kdo má pohotovost.
- Cvičení je naplánované a ohlášené, pak proběhne na produkci.
- Každý krok a jeho trvání se zapíše do runbooku.
- Cokoli cvičení odhalí, se opraví v kódu a v runbooku.
Pravidla a třídy rizika pro AI agenty
Každý repozitář obsahuje psaná pravidla pro AI agenty. Každá změna je zařazená jako ohraničená, rozbíjející nebo nejasná. Rozbíjející změna potřebuje souhlas člověka a nejasná znamená zastavit se a zeptat. Změny aplikuje jen pipeline.
- Pravidla říkají, co zkontrolovat před změnou, jaké příkazy existují a co je zakázané.
- Agenti mohou změnu infrastruktury naplánovat. Její aplikace čeká na schválení člověkem v pipeline.
- Kde se agent potřebuje jen podívat, dostane přístup pouze pro čtení.
Záznamy rozhodnutí a post-mortemy
Architektonická rozhodnutí se zapisují vedle kódu i s odůvodněním. Každý incident dostane post-mortem bez hledání viníka a jeho poučení se promítnou do kódu a pravidel.
- Každá práce dostane krátký záznam: požadavek, rozhodnutí a proč, plán a co se skutečně stalo.
- Zapisují se i rozhodnutí o nákladech, aby se k nim dalo vrátit, jak platforma poroste.
- Další inženýr nebo další agent začíná s plným kontextem.
Měřená obnova produkce naostro
Záloha pomůže jen tehdy, když obnova funguje ve chvíli, kdy je potřeba. Naplánovali jsme cvičení, ohlásili ho, pak jsme produkční databázi skutečně obnovili ze zálohy a změřili každý krok.
Dodávky
Jedna cesta od nápadu do produkce
- PsaníInženýr pracuje ve větvi s AI nástroji, které dodržují pravidla repozitáře.
- KontrolaNa pull requestu běží automatické bezpečnostní a kvalitativní kontroly.
- PreviewŠtítek dá pull requestu vlastní plnohodnotné prostředí.
- MergeImage se sestaví jednou a vývojové prostředí se aktualizuje automaticky.
- PovýšeníTentýž image jde po schválení do produkce.
- SledováníMetriky, logy a trasování ukazují dopad změny.
Touto cestou jde každá změna, ať ji napsal člověk, nebo agent. Protože je cesta vždy stejná, otázka partnera, jak se změna dostala do produkce, má jednu odpověď.
Slovy klienta
„S AI agenty vyvíjíme každý den a nejtěžší bylo dát jim volnost, aniž bychom ztratili kontrolu nad infrastrukturou, která musí projít due diligence banky. Glebův tým to postavil jako systém: vše v kódu, každá změna přes pull request, psaná pravidla, která agenti opravdu dodržují. A pak průběžně dokazovali, že to funguje, až po měřenou obnovu produkce naostro. Chovali se jako naši vlastní inženýři, ne jako externí tým.“
Roman Shprenger, spoluzakladatel a CTO, Plexo
Otázky
K tomuto přístupu
Co dělá managed DevOps tým pro fintech?
Provozuje cloudovou platformu jako službu: infrastrukturu jako kód, delivery pipeline, monitoring, řešení incidentů, aktualizace a dokumentaci. Za výsledek odpovídá jeden vedoucí a práce se řídí dohodnutým rozsahem s garantovanými reakčními dobami, ne hodinami účtovanými za každého člověka.
Jak mohou AI agenti pracovat na infrastruktuře, aniž byste ztratili kontrolu?
Dejte jim psaná pravidla v každém repozitáři, každou změnu zařaďte podle rizika a změny nechte aplikovat jen pipeline po schválení člověkem. Kde se agenti potřebují jen podívat, dostanou přístup pouze pro čtení, a každé rozhodnutí se zapisuje vedle kódu.
Jak prokázat, že obnova po havárii funguje?
Obnovte data ze zálohy v reálném cvičení, změřte každý krok a výsledek zapište do runbooku. Partneři, kteří platformu prověřují, chtějí důkazy, a měřená obnova s runbookem jim je dává.
Na co se ptá banka při due diligence platformy?
Obvykle na to, jak je řízen přístup, jak se změny revidují a zaznamenávají, jak jsou data šifrována a jak se testuje obnova. Když je vše v kódu a každá změna prochází pull requestem, většina odpovědí ukazuje na soubor nebo log.
