Ahojte, eDoklady padly a sbiram nazory na to proc se tak stalo a jak by se to dalo delat jinak. Mate nejake hypotezy?
Tady myslím nejsou potřeba hypotézy, oni to tam docela jasně píšou (respekt za stručný a otevřený popis problémů bez vytáček).
Ono je obecně relativně těžké dělat software tak, aby zvládal špičkovou zátěž. Když nadimenzuješ hardware, architekturu i procesy tak, aby všechno zvládlo například stonásobek běžně plánované návštěvnosti, tak budeš drtivou většinu času platit neúměrné náklady – systém bude „nachystaný na spartakiádu“, ale reálně bude chodit cvičit pár lidí. Naproti tomu když tam dáš rozumnou rezervu, třeba na desetinásobek běžně očekávané zátěže, tak zas není tak těžké vyrobit špičku návštěvnosti, která i tuhle rezervu hravě vyčerpá. Například tím, že dopředu avizuješ přesné datum spuštění a systém si přijde vyzkoušet pár desítek tisíc zvědavých lidí 
Jeden způsob, jak to vyřešit, je připravit ten systém na možnost posílení hardwaru předem v očekávaných špičkách. Tohle ale musí umožňovat architektura systému, takže v některých případech můžeš narazit na technický dluh, který ti tohle nedovolí.
Další způsob je udělat systém úplně „nafukovací“, aby se zátěží prostě jen třeba rostly náklady, ale jinak ten systém škáloval transparentně. Tohle jde dobře udělat v těch různých cloudových infrastrukturách, jako jsou například AWS, Azure nebo Google Cloud. Ty firmy mají vlastně „nekonečnou“ zásobu hardwaru i dalších kapacit, ze kterých si ten systém s rostoucí zátěží automaticky ukrajuje podle potřeby. I na to ale musí být ta architektura připravená předem, takže to není magické řešení například pro starší, zděděné systémy. A samozřejmě to není řešení pro systémy veřejné správy, nebo rozhodně ne všechny – museli bychom mít nějaký „národní cloud“.
Taky jde problém vyřešit „pořadníkem“, tedy tím, že tu vlnu nových uživatelů rozložíš v čase. Pořadníky, postupně uvolňované zvací kódy a podobně.
Subjektivně mně tyhle porodní bolesti nových systémů přijdou docela v normě s ohledem na to, jakou popelkou ta digitalizace u nás doposud reálně byla. DIA musí narážet na brutální technický, organizační i legislativní dluh, jak ostatně popisuje třeba Martin Mesršmíd ve výborném rozhovoru pro Rozhlas. Podle mě je potřeba dát jim šanci, z té reakce, kterou cituješ, vypadá, že jsou si problému adekvátně vědomi.
3 Likes
Krasne receno, dekuji za odpoved, z technickeho hlediska to dava perfektni smysl. Take chapu ze ‘porodni bolesti’ jsou neodmyslitelne, jen bych si dovolila dodat, ze toto nejsou porodni bolesti vyvoje a release technologii, ale porodni bolesti digitalni transformace CR a lidi / instituci za to zodpovednych.
Na co ale nemame manual, je jak provest digitalni transformaci verejne spravy produkt po produktu, sluzbu po sluzbe, instituci po instituci, a prave toto verim jsou root cause techto veci, ktere vyplavou na povrh. Proto bych to chtela nazvat porodnimi bolestmi statu, ktery se snazi vyuzivat potencialu technologii, ne porodni bolesti technologii.
Kdyz bych se divala do budoucna, koukala bych se na par veci:
Bariery technologie
Otazka co nas omezuje ve vyuzivani technolgoii? Jsou to integrace s 3rd party systemy a jejich SLA? Je to tech debt? A jak s nim pracujeme (ignorujeme jej a delame jen nove krasne veci nebo je soucasti naseho seznamu veci na kterych pracujeme?)
Uzivani spravnych metodickych postupu
Pouzivame osvedcene metody implementace technologii (load testing, QA, scalability, robustness, deployability, aj.). Testujeme tak jak mame? Mame nachystane plany pri katastrofe? Mame plan B? Delame pokusne release do produkcniho prostredi? Kontinualni vylepsovani a delivery?
Minimalizovani rizika
Tohle byl hodne riskantni ‘release’, mel velkou publicitu a byl to velky projekt. Takoveto projekty se vetsinou nepublikujou v jednom velkem BUUUUM, ale postupne a az s otestovanym softwarem a planem B.
Login je produkt, ne projekt
V Singapuru i v UK je identita obcana samostatny produkt, ktery trva mnoho let aby se vyvinul do kvalitniho zakladniho produktu (spolehlivy, bezpecny, atd.). Neni to projekt, ale produkt. Projektovy mindset ma docasne tymy, vytvorit-jednou mentalitu, uzivatelska zpetna vazba jen jednou a to na konci, jeden release, uspech se meri dorucenim na cas a rozpocet. Produktovy mindset ma dlouhodobe zajisteni tym, testovat-a-ucit-se mindset, zpetna vazba behem vyvoje (ne na konci), release kontinualne, uspech se meri uzivatelskou spokojenosti. Takhle fundamentalni sluzba statu musi byt produkt o ktery se starame s velkou laskou a pozornosti.
Kdyz se na to divam z uzivatelskeho hlediska, tak chapu proc jsou lide zklamani (my tech lidi vime, ze to nekdy vrze, ale uzivatele jen tezce sympatizuji), dnesni svet uz funguje jinak a verejna sprava ma co dohanet. Ale taky to beru jako uzitecne ponauceni pro DIA i dalsi, digitalni transformace je cesta, ne projekt. Moc chvalim PR DIA, zvladli to skvele (uzasna transparentnost), myslim ze tim to zachranili.
Rada bych tady dala jeden velky dovetek. Tohle jsou me nazory z venku, nediskutovala jsem s DIA jaky to melo prubeh ci priciny, tohle jsem jen pohledy zvenku a hypotezy kolem pricin. Zaroven verim, ze DIA udelala vse co bylo v jejich silach v danou dobu, s danymi moznostmi a prostredky, ktere meli v tu dobu k dispozici.
2 Likes
Velmi souzním s tím, že ten problém není primárně technologický. Udělat systém, který hladce škáluje, není dneska vesměs až takový problém. Předmětem aktivního výzkumu, abych tak řekl , je udělat to v prostředí stávající české veřejné správy.
Takže i v případě podobných výpadků je potřeba rozlišovat, jestli to padlo kvůli nějakým vysloveným chybám na straně DIA, anebo prostě proto, že ten nový systém spoléhá na řadu starších řešení, která nejdou předělat všechna najednou. Kdybychom trvali na tom, že všecko nové musí běžet bez chyby, budeme tady čekat na mesiáše do tepelné smrti vesmíru.
Ale zcela konkrétně by tady býval pomohl postupný rollout, ano. (Abych se přidal k zástupu generálů po bitvě :–)
2 Likes
Pravda pravda, jedno je spojene s druhym, dekuji za pripominku.
Kdyz v UK delali transformacni program 25 sluzeb verejne spravy, ktere jsou nejvice pouzivane obcany, meli dorucit 25 MVP za 400 dni, tak uspesnost byla 40%, jakoze dorucili 25 MVP sluzeb, ale 60% melo nejaky bug. Takze nemuzeme ocekavat dokonalost, I give you that (skoda 
)
1 Like
My jsme behem prace na Covid portalu videli dva problemy ceske infrastruktury (nerikam, ze jsou nutne jedine). Ale fakticky ani jeden z nich neni moc resitelny ze strany produktoveho tymu, ac to ma na vysledny produkt dopad.
- Jednotlive casti infrastruktury jsou propojene a maji ruzne vlastniky. Tedy statni infrastruktura neni jeden celek, ale navzajem propletena sit dodavatelu, kteri jsou k sobe navzajem treti strany. Minimalne tim, ze maji kazda vlastni rozpoctovani.
- Infrastrukturni tymy pracuji s danou sadou nastroju. Pridat nastroj je velka bariera. Tohle nerikam ve spatnem slova smyslu. Pridani nastroje ma byt za zdi, i ja jsem se naucil z pohledu architekta stavet zdi proti rozsirovani stacku.
Na (1) jsme narazili napriklad u gov.cz “cloudu”, kde neslo nasadit ipv6 pro Covid portal. Ac to vsecky casti “cloudu” NAKITu podporovali. Neslo to proto, ze gov.cz ma jednotnou gateway (hardwarovy switch na tajnem miste, asi) pres ktery tece veskere prvotni routovani domeny gov.cz a nepodporuje to ipv6. Je to choke point cele infrastruktury => ano. Jde to snadno nahradit => ne. Na konkretni technologii toho switche je zadratovano strasne moc veci, ktere by se museli updatovat zaroven.
Na (2) jsme narazili pri snaze Covid portal cachovat. NAKIT nemel na Azure cloudu nativni CDN (cache). Vsechny requesty sly nazivo na infrastrukturu a cachoval je tam nginx (tusim, nebo apache). Pridat moznost cachovat ten staticky web na cloudove CDN byl pro infrastrukturare porod (nejspis). Nastesti to proslo, protoze jinak by spusteni covid portalu dopadlo jako eDoklady. A ted uz je jeji vyuziti jednodussi.
Umim si predstavit, ze tohle je problem uplne vsude. V UK i Singapuru. Rozdil muze byt ve vuli to po castech posouvat a pripadne i v lepsim personalnim obsazeni architektu, kteri v tom umi chodit, tu infrastrukturu znaji a vedi, jak se problemum vyhnout.
2 Likes
K tématu výšel dobrý rozhovor na Lupě. Zmiňujou se tam konkrétní příčiny problému, mluví se o té škálovatelné architektuře a mimo jiné tam zazní, že postupný rollout služby nebyl možný kvůli legislativě – když má občan na službu nárok, nejde mu ji odepřít pořadníkem. To myslím dobře ilustruje složitost prostředí, ve kterém se pohybujeme:
Bylo by to naprosto skvělé, v IT je to běžná dobrá praxe. Bohužel narážíme na legislativní limity a momentálně to přesně takhle udělat nesmíme. Protože buď to právo občana existuje, nebo neexistuje. Nemůžeme občany rozdělovat do nějakých kategorií a říct, vy jste si vylosoval, že můžete, a tady paní si nevylosovala, protože má třeba liché rodné číslo, a my jsme to spustili jen na sudá rodná čísla nebo jenom po okresech. Muselo by to přesně takhle být napsáno v zákoně.
Do budoucna, až budeme dělat nějakou další podobnou akci, si možná na nějaké přechodné období zkusíme do příslušného zákona propašovat možnost testování. Bylo by to velice dobré a bylo by skvělé, abychom třeba mohli využít dobrovolné testery, takže by se ještě před platností zákona mohla nějaká skupina lidí, early adopters, přihlásit do testu. Mohly by jich možná být i desítky tisíc, protože lidí, kteří mají zájem, je opravdu hodně.
K tomu bychom ale potřebovali do zákona dostat, že naše oprávnění existuje ještě před zákonným termínem spuštění služby a že třeba dva měsíce před tím už můžeme zapojit občany a můžeme s nimi aplikace testovat. Bylo by to skvělé, ale je to opravdu práce v první řadě pro legislativce, aby nám do zákona propašovali, že to smíme udělat.
1 Like
Paneboze, vetsi blbost snad jeste nikdo nikdy nerek. Chapu, ze nemuzou delat canary deployment po terminu, kdy to ma byt nasazene pro vsecky (za coz by se vyhazovalo i ve firemnim prostredi). Ale predtim to testovali jak? Najali tisic Polaku?
Viz treba EET, ktere spustili 2 mesice pred zakonym datem a od te doby se lide dobrovolne pripojovali a evidovali. Ve vsech vlnach. To rikam jako EETak s cislem 0000000004.
Proste to ladili do posledni minuty a nebyla tam zadna sance na to nekoho onboardovat ani den predem. Nejake “propasovani” do zakona at si necha od cesty.
1 Like
Tohle už je podle mě diskuze, ke které bychom potřebovali právníka. Taky si dovedu představit, že to omezení půjde nějak rozumně obejít, ale nepřijde mně fér označovat to za blbost, pokud neznáme detaily toho prostředí včetně (zejména) právních aspektů. To EET nemusí být srovnatelná situace právě kvůli odišnostem v zákonech.
A tady ještě rozhovor s Martinem Mesršmídem pro Enko, probírá se tam do detailu škálování služby NIA, která byla tím úzkým hrdlem při nasazení eDokladů (odemčený odkaz):
2 Likes