Vlákno názorů k článku
Základní registry budou mít odstávku, nepůjde přihlašování přes Bank ID či Identitu občana od Robin77 - Digitalizace statu v ceskem podani…

Digitalizace statu v ceskem podani…

ale plánované odstávky mají i všude jinde, proč si myslíš, že to je pouze český problém? Nebo prostě potřebuješ hejtit?

Když stát nabízí (či u nás spíš vnucuje) e-služby, má je mít spolehlivé a fungující právně závazným způsobem. Za férové jednání bych považoval zákon, prodlužující automaticky termíny všech povinných podání o dny, kdy služba vinou státu nefunguje.
Tak aby ten, kdo se rozhodne využívat a spoléhat na e-služby od státu, se nemusel bát, že budou nedostupné a mohl na ně opravdu spoléhat.

Základní registry se běžně mění za běhu, samozřejmě to běží na clusteru, upgrade a opravy HW (např. disků) se dějí skoro na denní bázi.

Problém je, když potřebuješ udělat výraznější změnu, vyměnit HW a síťové prvky, migrovat model a upgradovat databázi.

Provozoval jsi někdy distribuovanou strong consistency databázi a máš zkušenosti s upgradem SW za běhu? Pochlub se s tím. Základní registry běží nad Oracle, tam toho prostě moc nevymyslíš.

Tady nastal velký problém v tom, že základní registry běží na nevyhovujícím HW a konečně dochází k jeho upgradu, což se pár let odkládalo. Udělat tyhle věci za běhu je velice obtížné, zejména, když nemůžeš přijít o žádná data. No a dodavatel řekl, že to neumí za běhu.

Google a další si k tomu vyvinuli vlastní databáze a vlastní síťové řešení, mají to jen pro sebe a na komerčním trhu ( a ani v open source) zase není tak velký výběr těhle distribuovaných technologií.

Na českém trhu neznám společnost, která by provozovala vysoko dostupné databázové systémy bez občasného plánovaného výpadku. A to se v tom oboru pohybuji a ty systémy buduji, také to neumí vždy bez výpadků.

jedná se o generační obměnu po 10 letech provozu, to není špatné, ne? Těžko lze systémy provozovat neomezeně bez výpadků, kdo to umí? Teď tam budou kontejnery, nový HW, upgrade DB o dvě generace a jedná se o kompletní obměnu.

Myslíš, ten Amazon, který v létě měl půl dne výpadek všech služeb najednou pro velkou část klientů? Nebo myslíš ten Amazon, který v prosinci 2021 byl dokonce dole celý den? A co Google, v roce 2020 kompletní výpadek na několik hodin, vloni výpadek řady služeb také několik hodin. V AWS nebo Google Cloudu řešíme plánovaná výpadky skoro každý měsíc a migrujeme služby.

Kdy naposled vypnul neco treba google? Nebo treba seznam? Nebo .... ???

Mimo jine provozuji jednu takovou pidisitku ... i v te pidisiti se kdokoli prihlasi 24/7/365. Proc? Protoze ty servery jsou dva.

Normalne se aktualizuji sem tam je treba vymenit jadro takze i nejaky ten restart ... chmm. Zazracna techniologie ze?

Oh jiste, stalo to par tisicovek ...

Mimochodem, kde si muzu precist nejake oficielni info na tema prodlouzeni lhut a odlozeni terminu? Ony totiz nejake lhuty konci v nasem kocourkove prakticky kazdy den, vcetne vikendu. A pochopitelne vubec nejlepsi napad je vypnout tyto systemy na novy rok, tam totiz nekonci vubec nic ...

15. 9. 2023, 17:30 editováno autorem komentáře

Kdo ví, jak tihle exoti (jako cokoliv státního) řeší nasazování..
Jestli tam je cluster, tak jen na běžný provoz.
Tam nemůžeš čekat, že běží týdenní buildy, CI/CD co to nasazuje, nějaký skvělý staging a bezvýpadkový přepínání, a tým programátorů, který to může řešit..
Spíš jim dodavatel dá nový build,, kde udělali tři změny, oni si udělají maintenance v sobotu a v neděli kontrolují, jestli jim to nesmazalo tabulky v DB…
Tak to prostě je, a je to tak nastavený.
Stát je OK s tím, že mu nejde login a neřeší to, když to není delší než týden.
—
Četl jsem i o hodinovém výpadku Alzy a jak se nad tím v komentářích někdo pohoršoval..
Vždyť to je úplně normální.
I v systémech pro 2Tbps trafficu a největší obsah na internetu.
10 min to jenom svítí v monitoringu, 20 min do toho hledí první admin, za půl hodiny máš přinejlepším asi odhad, co se děje a 30 min trvá nejvíc stresový zbastlený fix, rollback, úprava, .. a už to jede. Rapid response.
Já Alze tleskám.

100% SLA neexistuje.

Státní outage je extrém, ale co si nastavili a co si platí, tak to maj. Určitě nemaj takový resources jako komerční sektor, i když jsou jejich systémy 10-100x dražší, lol.

Jak rikam, spatne navrzeny sw. Vymena sitovych prvku se dnes dela za provozu, minimalne bych to od projektu za miliardy ocekaval. Nemam velikou firmu ale HA na urovni sitovych prvku kluci umi.

Vyhoda digitalizace statu ma byt to, ze si vecer nebo o vikendu vyridim agendu se statem. Pokud to mam delat v urednich hodinach tak se na to muzu vyprdnout. Takhle dlouha odstavka ukazuje ze dany system nebyl navrzen pro dostupnost 24/7 coz za ty miliardy je problem. A planovane aktualizace a udrzbu maji vsude ale ze by treba google nebo amazon vypnul na den sve sluzby se neda rict.

15. 9. 2023, 23:36 editováno autorem komentáře

Obcas to ten google vypne neplanovane ;-) A ani dalsim velkym hracum se vypadky nevyhybaji. A samozrejme ani Seznam neni bez poskvrny. Asi byste tam mel jit se svym knowhow a vysvetlit jim, ze tam jsou taky blbci, kdyz to neudrzi v chodu... kdyz vy to tak dobre umite :D

Cekal bych ze takovy vypadek bude opodstatnen zmenou architektury kdy se proti predeslemu stave vetsina da za behu udelat.

1. Vymenovat HW se da za behu. Vcetne komponent pole a u lepsich masin lze tahat karty z backplane za behu
2. Sitove prvky se daji vymenovat za behu,
3. Databaze chapu, ale napr se zamknutim zapisu do a provozem jen audit logu by slo a pak to jen shodit a pustit na druhy strane
4. Cele storage se daji prepinat za behu i pokud je shared storage
4. Old school nedistribuovany cluster - byva problem a je treba pocitat i s DR kdyz se to vysype. Tam celkem chapu kdyz se predpokladana odstavka nasobi cislem 3.

Takze kde je problem? Na aplikacni bazi kde nejde zamknout registr do rezimu udrzby / read-only?

I ten google má občas odstávky, na úrovní AZ poměrně často a musíme aplikace migrovat. Jeho rozpočet je ale nesrovnatelný. Seznam je blbej příklad, ten plánované výpadky ve svých službách dělá (jenže kdo pozná, že mu v noci přišel email o hodinu později, že?) a neplánovaných má ještě více

Nebude právě rozdíl v tom, že provozuješ jen pidi sít? Myslíš, že základní registry jindy ani neaktualizují? Jsi na omyl, běžně se za provozu aktualizují, pokud jde o bezpečnostní updaty a drobné změny. Výpadek je kvůli nutnosti zavést nové verze SW, migraci modelu a mění se síťové prvky.

Největším problémem je ale cena a riziko selhání, prostě takhle to je pro stát dnes jednodušší a levnější.

když měníš kus za stejný kus, tak ano, ale zkoušel jsi někdy upgradovat cisco nexus řadu 7000 na 9000 při zachování mlacp? To jsou prostě věci, které bez výpadků nejdou. Nebo mi tady snad tvrdíš, že jsi schopný každou změnu sítě udělat bez výpadků?

Ideální je mít druhou lokalitu, přesunou provoz na ní a tu první si vyměnit. Pokud nemáš třetí, během výměny jdeš do rizika, že při nehodě příjdeš o vše, což je někdy neakceptovatelné a kupovat vše trojmo by zase už dost prodražilo státní IT zakázky. Vždyť např. ani banky nemají systémy trojmo, ale jednou vesměs dvojmo a stejně KB si teď dělá pro jistotu víkendový výpadek bankovnictví a to její finančí možnosti jsou flexibilnější než u státní zprávy.

To by mne vskutku zajimalo, k cemu je infrastruktura, ktera nefunguje.

Umim vymenit libovolny sitovy prvek, za chodu, za libovolny jiny ktery podporuje prislusne technologie, bez toho aby z pohledu aplikaci doslo k jakemukoli vypadku.... ostatne presne toto je ucel.

Ve skutecnosti umim udelat totez i v pripade, ze bude nutne vymenit ten HW za takovy, ktery s tim stavajicim neni kompatabilni. Asi pouzivam zazracne technologie.

Ja tyhle statni veci moc nepouzivam, takze nemam prehled, ale ted jsem treba zkusil rychle hledani: "Ve dnech 15. 4. 2023 od 14:00 do 16. 4. 2023 20:00 hod. bude provedena odstávka systému základních registrů v rizikové skupině kategorie „C“. V uvedeném termínu nebudou dostupné základní registry, tudíž nebude možné využívat ani služeb elektronické identifikace prostřednictvím národního bodu pro identifikaci a autentizaci (NIA)."
Je toho samozrejme vic: https://www.szrcr.cz/cs/archiv-novinek/odstavky-a-omezeni-provozu Ono je jiste mozne, ze kazda z tech odstavek ma padny duvod a ten duvod je po mnoha letech, je samozrejme mozne, ze jako danovy poplatnik mohu byt rad, ze se to resi odstavkou, protoze naklady na provoz zcela bezodstavkoveho systemu by byly vyrazne vyssi nebo by to vedlo k vice neplanovanym vypadkum, ale kazdopadne se nema smysl tvarit, ze odstavka nastava maximalne jednou za deset let.
To srovnani s vypadky neni uplne spravne. Vypadek a odstavka jsou dve naprosto rozdilne veci.

máš pravdu, s tím jednou za deset let jsem přestělil, oni to dělají častěji a pokaždý k tomu je naprosto jiný důvod.

V plánu je tu frekvenci výpadků snížit a snad se jim to povede.

Někdy ty peníze za bezvýpadkové řešení jsou dost vysoké a je těžké některé systémy na to připravit.

Co by take clovek za ty drobne ... miliardy ... chtel.

Sory, ale uvedené příklady nemluví o plánované odstávce. Tak znova.

Tak on i Seznam ma odstavky a obcas i delsi. Ze o nich nevite neznamena, ze nejsou :-)

Teprve loni nebo predloni, soud judikoval, ze automaticke doruceni v DS nemuze probehnout o vikendu, predtim k tomu stat pristupoval tak, ze se o vikendu automaticky doruci. A takovych situaci jsou stovky.

Dobre ale takovy vypadek urcite nezabere 24 hodin. Odstavky se daji taky rozsekat na vice mensich. Na ty bez predpokladaneho vypadku a s vypadkem. Nekde dokonce neni zadouci udelat vice veci behem velkeho okna nebot nasledny plan navratu muze vnaset vetsi mnostvi promennych.

Navic v pripade kritickych veci budete mit dvojtou nezavislou konektivitu bez spof a bez vzajemne zavislosti.A to plati jak storage cast site tak pro normalni traffic. Takze budete mit dva oddelene segmenty site od switchu az na vlakno a do serveru povedou oba smery. Jinak je architektura blbe navrzena. Mozna to firmu vyleci z pouzivani problematickych protokolu a vendor specific implementaci.
Spravny architekt ma pri navrhu architektury zhodnocovat i snadnost upgrade. Pripadne prehodnotit architekturu protoze ne kazdy ma kristalovou kouli.

Pripad ktery popisujete bych vsak zaznamenal do deniku provozni zkusenosti a probral s architektem k prehodnoceni architektury.

Urcite je to jedna z vyhod. Na druhou stranu, i kdyby to bylo tak dramaticke, ze by opravdu statni digital fungoval jen v urednich hodinach, tak stale lepsi vyridit agendu online, nez cestovat na urad nebo postu a stat tam frontu. Navic to samozrejme tak dramaticke neni, planovane odstavky zdaleka nejsou kazdy vecer ani kazdy vikend. Prusvih samozrejme je, pokud nekomu behem odstavky konci termin a nestiha podat drive. Osobne doufam, ze vetsina terminu konci ve vsedni den, ale ruku do ohne za to, ze nektere nevyprsi o vikendu, nedam.

Tak ono kazdej pristup ma sve vyhody a nevyhody. I ten rapid deployment neni az tak dokonalej, kdy dusledkem nedostatecneho testovani pred nasazenim muze byt klidne nejaka bezpecnostni dira, ze? ;-) Vsak presne tohle bylo bylo vysledkem i onoho slavneho hackatonu k dalnicnim znamkam, ze? Poctivy bezpecnostni audit aplikace a dopady zmen v kodu na bezpecnost za hodinu neudelate...

A dopady kvapne nasazene veci, kde se spravuji elementarni udaje o obcanech CR muzou byt opravdu fatalni, coz u zakladnich registru realne hrozi. Takze better safe than sorry. Ze by na to mela pamatovat legislativa je druha vec, protahnout nejakou lhutu o den - dva by nemuselo byt ani spravne slozite vyresit, nehlede na to, ze v prostredi kde i statni sprava beztrestne nedodrzuje lhuty by se ojedinele nekolikadenni zpozdeni v nejakem podani trestat asi nutne nemuselo - minimalne v ramci nejake reciprocity.