Hrůza je, že zavedli něco, co podnikatelé nechtěli, zákazníkům to nepomůže a výhoda pro státní rozpočet je pouze slíbená. Kolik to mělo výpadků nevím, ale znepříjemňují život.
Podobně jako el. dálniční známka, u které základní otázka nezní, kolik měla stát, ale proč ji zavádět, jelikož výhody jsou marginální. A podobně u toho sčítání lidu - všechny podstatné údaje už v registrech jsou, takže jde o další zbytečné obtěžování lidí.
Co je zleho na el. dialnicnej znamke? Nebudete vy jeden z tych, co prelepovali rocnu znamku z auta na to? Vam nepride vyhoda to, ze ked kupite znamku v polku roku, takze bude platit rok od nakupu a nie len do konca kalendarneho roku? Myslim si, ze el. dialnicna znamka ma viac vyhod nez nevyhod, ked nebudeme pozerat na cenu celeho systemu.
Vyhodou el. dalnicni znamky by bylo, kdyby sla koupit na libovolny casovy usek rekneme od 2 do 365 dnu. Ze by cena za den klesala s poctem dnu je akceptovatelne.
Toto nelze.
Dale by vyhodou bylo, kdyby sla znamka vratit a ziskat tak zpet nejakou cast jeji ceny.
Toto nelze.
Takze mi u toho zbyva jen jedina vyhoda, ze znamka vzdy plati dany pocet dni bez ohledu na kalendarni rok.
Tato prkotina je vykoupena monitorovanim a sberem dat o pohybu vozidel.
Takze mi u toho zbyva jen jedina vyhoda, ze znamka vzdy plati dany pocet dni bez ohledu na kalendarni rok.
A pak taková „drobnost“, že kvůli té známce nemusíte chodit bůhvíkam, ale koupíte ji z domova klidně 10 minut před cestou.
Tato prkotina je vykoupena monitorovanim a sberem dat o pohybu vozidel.
Jasně. Protože se vybudovalo několik portálů s kamerami, které přečtou SPZ a – a k čemu by podle vás k monitorování byla potřeba elektronická dálniční známka?
Mezi námi, SPZ rutinně čte "každej druhej semafor" už drahně let a pro sebe si to nenechává (jestli se nepletu, tak se k tomu dostane rutinně i řadový policista, možná s vyjímkou pochůzkářů). Trochu zarážející tam byla informace která se tehdy proflákla "3 po sobě následující HD fotografie posádky" v původním zadání, od které se naše tajné služby okatě distancovaly že to nikdo z nich nechtěl a nepotřeboval.
+ to že silové složky mají rutinní face recognition vybudované dávno je taky takovým veřejným tajemstvím.
28. 3. 2021, 19:16 editováno autorem komentáře
Za druhou polovinu semaforů prohlašuji, že SPZ nezpracováváme. Primární detekční systém jsou smyčky, občas radar a občas kamera. Z kamery ale dopravní řadič vidí maximálně kategorii vozidla (osobní, autobus, ...) a rychlost.
Pokud už kamera má nějakou funkci čtení SPZ, tak se o ní nebaví s dopravním řadičem a policie komunikuje přímo s kamerami.
Mezi námi, SPZ rutinně čte "každej druhej semafor" už drahně let
Kdyby jen semafor... Stačí se zamyslet, jak asi fungují ty výjezdy z parkovišť, kde se závora otevře sama, aniž by bylo potřeba přikládat lísteček na scanner. Např. v pražském Paláci Flora to tu značku na lísteček dokonce vytiskne, aby člověk nebyl na pochybách; jednou tam byla s chybou a skutečně jsem při odjezdu lísteček přiložit musel.
A taky už jsem narazil na "výstražný radar", který pro zvýšení efektu kromě naměřené rychlosti zobrazí i načtenou SPZ.
JmJ: Ona snad kamera, která přečte SPZ a zkontroluje, zda má dotčené auto zaplaceno nebo ne, něčemu vadí? Pořád chceme, aby stát šetřil, aby doprava byla plynulá, aby policajti nikoho nezastavovali zbytečně – a pak si zase někdo vymyslí, že nejlepší jsou nalepovací známky, a že by měla Policie na dálnici dělat zátahy, kdy zastaví všechna auta a zkontroluje jim známky, aby odhalila i vejlupky, kteří si vyrábějí „přenosné“ dálniční známky.
Jenomže, příteli, víte, v čem je problém? V tom, že digitální totalita salámově zniká právě takhle. Taková digitální totalita, to není Orwell. To je stav, kdy jednou zapomenete, že jste si vlastně zapomněl koupit známku, okamžitý postih. Zapomenete na něco jiného jinde, okamžitý postih. Neuvědomíte si to či ono, okamžitý postih.
To je ve výsledku basa. Nikoliv pokrok. Protože člověk není stroj.
martinpoljak: Digitální totalita by vznikala tím, že někteří budou řvát naprosto na cokoli. Jenže pak už stížnosti na bezpečnost či soukromí nebude brát nikdo vážně – a pak konečně může bez povšimnutí projít skutečné ohrožení bezpečnosti nebo soukromí.
O žádnou salámovou metodu se nejedná, každou technologii je možné zneužít. Takže není možné stavět se proti každé technologii, ale je potřeba hlídat to překročení hranice.
Řvát na všechno je tedy kontraproduktivní (i když je to primitivně jednoduché). Reálně je ale potřeba umět rozlišovat a (pracně) hledat tu hranici, kdy ještě soukromí ohrožováno není a kdy už ohrožováno je.
Okamžitý postih za to, že jste si zapomněl koupit známku, nijak nesouvisí s technologiemi. Úplně stejně jste za to mohl být postižen i v době nalepovacích známek. Technologie vám naopak umožňuje, když na to zapomenete, vyřešit to třeba ještě před nájezdem na dálnici – někde zaparkujete a koupíte známku přes mobil. Dříve byste se prostě musel dálnici vyhnout a počkat, než narazíte třeba na otevřenou benzínku.
To je těžký... U nás je pořád status autíčka že já jsem nejdůležitější na silnici a ostatní jsou idioti. Automat je pro blbce a než se kolona kvedlacu kremu a slapacu zeli rozjede uz to zas stojí. Nebo to prodluzuje manipulaci Mezitím nekdo preslapne spojku a napali to zadkem do auta v kopecku za nim.
Blokovani pojezdu auta pri zastaveni v kolone se take u nás neuci.
Co se tyce silnicni dopravy...
Začal bych s registrem značek a dopravního značení a z toho poskytovat otevřená data. Také dotáhnout fungující celostátní informacni infosystem o dopravních omezenich.
Propojení semaforu na ridici dispečink dopravy. Tohle není ani samozřejmé pro Prahu.
Tady je možností pro několik generací Jirsáků jak udělat ve státní sféře kariéru.
Kosmetické výhody to má, ale (nevím jak na Slovensku, bavím se o Česku) když se na tom samém autě změní SPZ, musí majitel auta hlásit změnu, aby známka dál platila. Ta skvělá digitalizace je takovým přínosem, že lidem práci přidává tam, kde by člověk čekal, že to úřady zařídí automaticky. Nalepená známka platila i po změně SPZ.
Navíc já jsem kupoval známku každý rok, takže výhoda je to opět jenom symbolická, že platí od poloviny roku. Jo, kdyby ti géniové umožnili zaplatit známku třeba jenom na 24 hodin, to by pro někoho výhoda byla. Ale ani tohle to nepřineslo. Prostě se někdo nažral, Babiš si udělal čárku, jaký je moderní a konec.
@Michal Kubeček
Tady je odkaz, když je ta neděle: https://www.mtx.cz/faq/dalnicni-kupony/
Tak ale to směšujete dvě naprosto různé věci. Jestli je daný systém (resp. to co a pro koho zpracovává) na houby je otázka čistě politická, ve které s Vámi budu plně souhlasit.
Ale s technickou (ne)schopností státu udělat něco pořádně opravdu nesouvisí. Ať se nám celé EET nelíbí jak chce, tak po technické stránce po pár počátečních problémech se mu toho zrovna moc vytknout nedá. (na druhou stranu, ten backend je v principu na venek o složitosti blogíííšku, takže by bylo dost umění ho pokazit)
I když je to výjímka potvrzující pravidlo. Všechno ostatní bylo totálně zpackané, nefunkční, děravé a předražené.
ad elektronická dálniční známka - no ona se loni v dubnu potichu během nouzáku v prakticky nezměněné podobě schválila. Spekulace o tom, kterak se do prvního zadání dostaly požadavky na 3 HD snímky posádky, ke kterým se následně nikdo nechtěl hlásit, a zda tam jsou v současné době naimplementovány ponechme ct. čtenáři k vlastní úvaze.
27. 3. 2021, 17:57 editováno autorem komentáře
Tak technicky to je taky paskvil. Hlásit dobírku jako virtuální tržbu je trochu mimo mísu. Stejně tak hlásit uplatnění tržby při platbě "kreditem", kdy je to z pohledu Dal nulový účetní pohyb, takže nemůžete to volat při pohybu na financích a na MD nemůžete, jelikož to máte hlásit v čase ještě před jeho vystavením (který se technicky vystaví až při potvrzení převzetí zboží).
No prostě jedna hezká implementace za druhou....
Nejen že ta známka jde koupit deset minut před cestou, ona jde koupit i až na cestě. Třeba když člověk vyjíždí z Prahy a až na okruhu si uvědomí, že si chtěl koupit známku. Tak někde na nějakém odpočívadle zastaví, sjede na nějakou odbočku - a ani nemusí hledat žádnou čerpací stanici (nebo poštu - ono těch otevřených třeba o víkendu je také spousta, že). A dá se to vyřídit rovnou z mobilu, aniž bych vystupoval z auta.
Jinak seškrabávání starých známek z čelního skla byl také dost opruz,
Pokud někdo výhody elektronických známek nevidí, asi je vidět nechce. Já je Slovákům záviděl už několik let a nechápal jsem, proč to tu není už dávno. Pro stát to nakonec bude také levnější - i když třeba na začátku se muselo zainvestovat do implementace - ale pak už tam jsou jen provozní náklady, které nemusí být tak velké. Každopádně odpadají náklady na tisk a distribuci, která musela být každý rok.
Ale na to co funguje bezchybně, na to se strategicky zapomnělo např. EET.
Jednak i EET měla své výpadky, jednak jsem uváděl příklady státních webových aplikací spuštěných v posledních měsících, což EET není.
A přesto mělo a má velmi negativní mediální prezentaci.
Ta ale až na výjimky nekritizuje špatné fungování, ale buď to, že by ten systém v téhle podobě neměl vůbec existovat, nebo že proklamovaný účel stejně neplní. (Případně oboje najednou.) To je ale otázka politicko-ekonomického přesvědčení, funkčnost nebo nefunkčnost v tom nehraje roli.
Hold když nebyl někomu přiklepnut monopol a každý schopný programátor si mohl vyvinout vlastního klienta to se netoleruje.
A co způsob, jakým byl vybrán dodavatel na serverovou část?
"spuštěných v posledních měsících" - tuto informaci o jste ovšem ve vašem původním příspěvku taky zapomněl vzpomenout
"výjimky nekritizuje špatné fungován" - ve svém původním příspěvku jste mluvil pouze o technickém fungování a to EET skutečně takové nemá
"vybrán dodavatel na serverovou část" - o dodavateli v tomto případě IBM bylo rozhodnuto nějakou smlouvou z období roku 2010-2012 Nečasova vláda (mimochodem tehdy to v medií dost propírali). Argumentovalo se tím, že sjednocením dodavatele bude zrušen ten bordel co na ministerstvech, úřadech mají(navzájem nekompatibilní a různé systémy od různých firem). Myšlenka to zjevně byla dobrá a zjevně fungovala ale MALÁ DOMŮ spřáteleným podnikatelům a provize děla zase svoje. Ale nenalhávejme si iluze že i IBM nemusela poslat všimné. Babiš tehdy "asi" jako ministr financí prostě nechtěl riskovat tvz. české kvalitní programátory co jsou zaměstnáni co jsou zaměstnáni v českých spřátelených firmách např. OKsystem, apod.. jenž mají přiklepnuty monopolky od státu a radši šel do jistoty tržní IBM.
Faktem je že s technického hlediska a z pohledu programátorů je EET naprostá hvězda. Kdyby všechno fungovalo jako EET tak úřady v ČR jsou celosvětový leader v IT.
Já si vždycky říkám, proč podobné aplikace nenajíždějí postupně? Mohli to přece v tichosti otevřít několik dní před oficiálním termínem a odladit si to v testovacím provozu - stačilo by třeba nechat možnost si formulář předvyplnit a uložit, nápor by se tak zvyšoval postupně a měli by více času to vyladit. To oni né, oni raději budou s ostudou pracovat celý víkend.
Ještě více se to hodilo u registrací k očkování, kdy to měli otevírat postupně pro jednotlivé ročníky. Metoda kdo dřív přijde, ten se dřív očkuje, zcela jasně musí vést k totálnímu přetížení a kolapsu, to byla naprostá jistota.
Kolik že tato aplikace stála miliard?
Sčítání lidu mohla být hodně pokroková věc za Marie Terezie, nyní už je to jen činnost ze setrvačnosti a způsob jak rozhazovat další peníze. I když už za Marie Terezie byla jednou z hlavních motivací výběr daní a odvod do armády.
Zrovna dneska ráno jsem při čtení novin uvažoval, že kdyby tohle rozjeli v Azure, nemusel být žádný problém, nastavíte si automatické škálování, pár front, na pozadí třeba tu jejich slavnou cosmosdb a je hotovo. Více méně je to jen formulář, kde zadáte údaje a ty uložíte a maximálně to ověří jestli jste to už nevyplnili, ale pak jsem uvažoval, dál a více méně nejbližší region je k nám asi West Europe, takže 90% lidí bude spojení tranzitovat mimo ČR, takže to asi v Azure nebude. A ejhle najednou se zjistí, že to tam opravdu je...
Tak pry to zabili naseptavacem adres. Tedy dost pravdepodobne hodne busili selecty do na tento ucel neoptimalizovane tradicni SQL databaze. A v dusledku stacilo par tisic lidi, aby to cele polozili. Ocividne kvalitne provedene zatezove testy, kdyz neodhali slabinu v komponente, ktera bude dost 'na rane'.
Navíc je to ještě v napovídači adres (jestli ty zveřejněné údaje jsou ok). Klasika - interaktivní záležitost, která se špatně testuje, a navíc může utavit jinou komponentu.
Jediné jak by se tomu dalo předejít by bylo masivnější testování - a možná chytřejším návrhem - ale to se nedá uhlídat - v době, kdy se používají komponenty, a nikdo pořádně neví, co komponenta dělá uvnitř.
Takových chyb je mraky - u nekritického sw se tomu s dnešní komplexitou nedá zabránit. Co je problém, a nechápu, že se nedokáží poučit, je start projektu metodou velkého třesku z nuly naráz na 100%.
U takových chyb si škálováním nepomůžete. Ty systémy se nechovají lineárně - museli byste umět horizontálně škálovat na všech komponentách, a to je pouze vlhký sen. Jedna neoptimální komponenta může utavit CPU, utavit síťové prvky, monitoring. Tady pomůže jen správné řízení projektu, které nekončí předáním projektu, ale počítá ještě s náběhem projektu do plného provozu.
Připomíná mi to jednu firmu, kde měli hodně kritické performance problémy. Když jsem se jich ptal, jak testovali zátěž aplikace pro zhruba 20K aktivních uživatelů, tak mi bylo řečeno, že celá firma (cca 30 lidí) si naráz sedla a proklikala aplikaci.
Všechno jde, když víte, že to musíte ošetřit. Pro ten našeptávač by stačil dobře nadimenzovaný cluster elastic searche. Ale musíte vědět dopředu, že to je problém. Těch adres v ČR je tak málo, že se to vejde do pár GB možná i MB
U komplikovanějších systémů otestovat všechny aspekty dá stejně nebo možná víc práce než ten systém napsat. Ty systémy nejsou lineární, a bohužel málokdo se při testování dívá na zátěž komponent. Takže můžete udělat test s 200 uživateli, a může to fungovat, ale pokud se nepodíváte na CPU, tak neuvidíte, že vlastně už jste na hranici s výkonem, a s reálnou zátěží to fungovat nebude.
Abych pravdu řekl, nikdy by mne nenapadlo směrovat pro takovou aplikaci našeptávač vůči hlavní databázi. Finální ověření může být vůči cílové databázi, ale našeptávání pro potenciálně velkou zátěž by mělo jít na specializovanou dedikovanou databázi. Jinak si to fakt koleduje o malér. Našeptávání můžete přetížit, a nic se nestane. Pokud přetížíte cílovou databázi, tak končíte.
Chápu, že to musí být zabezpečené, ale v prvé řadě to musí být funkční.
Zkuste tohle říct před právníkem, který řeší ochranu osobních údajů, a pak nám povyprávějte, co se dělo, když ho vzkřísili…
Samozřejmě, že to musí být technicky funkční – jenom některá technicky dobrá řešení někdy není možné použít kvůli netechnickým požadavkům. Nevím, jestli to byl tenhle případ, ale těch netechnických požadavků tam bylo určitě spousta, protože požadavky na ochranu dat jsou v tomhle případě značné.
A tak v pripade komponenty naseptavace, ktery realne obsahuje jinak verejne dostupne udaje (aka RUIAN).... co konkretne je za bezpecnostni problem? Jestli tohle vsechno posilaji na tradicni SQL databazi (muzeme spekulovat, ale z ruznych vyjadreni to tak vypada), tak jim to logicky na hubu padat muze a bude - a pritom zcela zbytecne. Tam zadny problem tam z pohledu ochrany osobnich udaju nevidim, naopak tam cucham nevhodne technicke reseni.
Já neříkám, že v tomto případě tam je problém. Ale vím o případech, kdy data, která jsou legálně volně dostupná na internetu, musela být v systému uložena šifrovaně. Protože podle klasifikace dat spadla do kategorie, která musela být šifrovaná. Že je to nesmysl všichni věděli, ale nebyl to velký problém, takže nebyla motivace pustit se do byrokratického kolečka a vyjednat pro ta data výjimku.
Ono je nejsnazší něco odsoudit, když o tom člověk vůbec nic neví. Ale já nepotřebuju mít vše snadné, takže si stejně jako u dálničních známek nebo registrací na očkování dovolím ten luxus nedělat si názor v okamžiku, kdy o tom nic nevím, ale počkám si.
Myslím, že jdete s kanónem na vrabce. Adresní místa podle https://nahlizenidokn.cuzk.cz/StahniAdresniMistaRUIAN.aspx z celé ČR mají v zip archívu necelých 60 MB, dekomprimované necelých 350 MB a hodně informací mi tam z hlediska našeptávače připadá redundantní, takže to bude reálně určitě 50% nebo i méně z toho.
Konverze do UTF-8 lze udělat takto:
for f in *; do iconv -f ISO-8859-2 -t UTF-8 -o ../converted/$f $f; done
Hledání pomocí grepu např. "Vod" jako Vodičkova, trvá v tom výsledném datasetu na mém laptopu asi 0,1 sekundy takto hloupě nad textem (s výpisem do konzole by to bylo 1,1 sekundy)
Osobně bych nejdřív naivně jako programátor hodil ta relevantní data jako mapu seznamů map do Clojurového atomu s klíči podle počátečního písmena ulice, potom to klíč s městem a potom podle PSČ. Podle toho, co by uživatel zadal bych hledal v jedné z těchto map. Věřím, že by to bylo rychlé dost a pokud ne, tak bych tohle nějak optimalizoval pomocí vyhledávacích stromů nebo tak.
Jestli hledání bude v takové mapě seznamů map trvat milisekundu, tak to bude hodně. (Je to necelých 3 Mio. záznamů). Každý uživatel asi nebude potřebovat moc víc, než třeba 20 hledání. Takže třeba 20 ms na uživatele pokud by opravdu každý znak způsobil okamžité hledání. Při současných dejme tomu 250 000 spojení by to tedy bylo potřeba 5 000 sekund na obsloužení všech hledání současně - v jednom threadu. To je asi nepoužitelné. Na skromném serveru (v poměru ke sčítání lidu) o 8 jádrech by ale všechna hledání bylo možné uspokojit v rozmezí asi 10-15 minut. Nepřijde mi, že by se v rámci 15 minut na sčítání nahrnulo 2,5% populace ČR, ale muselo by se to změřit nebo třeba organizačně ošetřit.
Můj odhad je poměrně přesný, (počítejte zhruba 1/20 těchto časů, protože bych problém rozsekal podle počátečních písmen) a tohle je fakt nástřel tak, jak jsem to napsal, pracovalo by se se strukturovanými daty atd.:
(dotimes [_ 10] (time (dotimes [_ (* 3 1e6)] (str/includes? "Starý Jičín;33260;Dub;č.p.;2;74101" "Vod"))))
"Elapsed time: 34.488828 msecs"
"Elapsed time: 30.82285 msecs"
"Elapsed time: 27.632666 msecs"
"Elapsed time: 27.926483 msecs"
"Elapsed time: 28.222405 msecs"
"Elapsed time: 27.998212 msecs"
"Elapsed time: 29.083514 msecs"
"Elapsed time: 28.84451 msecs"
"Elapsed time: 29.308315 msecs"
"Elapsed time: 29.250055 msecs"
Jak jsem psal, nejsou tam žádná překvapení, možná až na debilní kódování znaků podle ISO-8859 (hádám, že konkrétně ISO-8859-2) místo UTF-8.
Děkuji za odpověď, ale můžete psát prosím konkrétněji?
Potřebuju rychle vyhodit adresy, které určitě nejsou to, co občan hledá. Proto redukce podle prvního písmene - lidi asi ví, kde bydlí. Zbytek je buď hledání regexpem/ contains nebo něčím nad poměrně omezeným počtem (části) adres s tím, že třeba prvních 10 výsledků pošlu klientovi ke zvážení do našeptávače samozřejmě strukturovaně - držím si mapy těch polí, která jsou pro aplikaci důležitá.
Ano, můžu tam mít nějaký fuzzy search nebo tak, ale myslím, že u adres to není zase tak špatné, když kladu větší důraz na správně napsanou aspoň počáteční část ulice/ města nebo správné PSČ.
Rád se nechám překvapit, jestli nabídnete aspoň nějaký nástřel Vašeho řešení/ uvažování, které by podle Vás obstálo při zátěži dejme tomu 250 000 spojení.
Adam Kalisz: Na první problém byste narazil už při implementaci:
Podle toho, co by uživatel zadal bych hledal v jedné z těchto map.
Uživatel zadal „pra“. Budete to hledat v mapě ulic nebo v mapě obcí?
Na druhý problém byste narazil při testování. Třeba taková Vinohradská ulice v Praze má nějakých 230 domů, a to k ní přiléhají dva hřbitovy, tři náměstí a dva sady. To by vám uživatel poděkoval, vybírat to ručně, bez zadání domovního čísla. Ostatní vámi uvedené případy (obec a PSČ) mají typicky ještě daleko víc domů. Největší selektivitu má ulice a domovní číslo (zejména popisné), to vám ve většině případů dá pár výsledků.
Řešení není potřeba nastřelovat, protože řešení jsou hotová a dávno se používají – ve vláknu před vámi se o nich dokonce diskutuje. Adresa se vypíše ve formátu na řádek (tj. ulice a čísla, část obce, obec, PSČ), v místě mezer, čárek a lomítek se rozdělí na tokeny a vloží se do fulltextového indexu. Když řešíte jenom ty adresy, je ideální nějaký fulltextový index, třeba ElasticSearch nebo Solr. Škálování se pak řeší počtem instancí strojů s tím indexem. Když si s tím chcete dál hrát, můžete přidat třeba synonyma jako n. = nám. = náměstí.
Některá zadání ale mohou být komplikovanější, než jak jste ho napsal vy.
Žil jsem v přesvědčení, že ulice, obec, PSČ jsou tři různá políčka. Případně tam je i políčko na číslo domu. Žadatel může začít vyplňovat cokoliv z toho první a podle toho můžu zúžit výběr.
Možná je lepší takovou věc nechat třeba na tom Apache Solr nebo ElasticSearch (prostě Apache Lucene + něco navíc) ale kdybych měl tyto věci nasazovat jenom kvůli doplňování adres, tak mi přijde jako komplikace nad kterou třeba nemám dobrou kontrolu. Přesně z toho důvodu se třeba v OrgPadu spíše díváme směrem k LIKE nad PostgreSQL, ale to je ještě trochu hudba budoucnosti.
Podle mě je lepší mít méně komponent, které znám dobře a znám jejich chování v produkci, i když jsou na určitý use case třeba trochu slabší. Někdy je možná lepší napsat tu komponentu (obyčejně je to několik desítek řádků kódu na ten konkrétní úkol) sám a mít nad tím plnou kontrolu včetně třeba dobrých logů a metrik, než nasazovat projekt velikosti několik stovek tisíc řádků kódu, který má vlastní názor na konfiguraci, vlastní DSL na ovládání atd. Když zjistím, že moje komponenta nestačí, tak ji buď rozšířím/ zlepším a nebo zkusím zaintegrovat cizí. V tu dobu už mám ale zase víc zkušeností, třeba zjistím už, jaký je o to zájem/ zátěž komponenty apod.
Vždycky, když slyším "škálování se pak řeší počtem instancí strojů" u něčeho, jako je našeptávač k formulářové appce, tak si říkám, že je něco špatně. Jako nemám nic proti failover/ redundanci. Dnes se ale řeší až příliš věcí horizontálním škálováním s vysoce stoupající komplexitou místo aby se radši chvíli škálovalo vertikálně, než uvidím, že mi takové škálování stačit nebude. Možná to v tomto případě dává smysl, ale spíš si myslím, že by to měl nějaký tučnější i virtuální stroj utáhnout.
Očividně i OKSystems byli schopní chybu ještě ten den opravit nebo obejít projevy té chyby do dostatečné míry, tak to asi nebyla taková hrůza.
Start je daný zákonem. Mezi lidmi z IT, které napadne, že start velkým třeskem není dobrý nápad, a poslanci, kteří ten zákon schvalují, je strašně moc mezičlánků. Navíc lidi, kteří ten start budou řešit, se k tomu dostanou typicky až po té, co už je zákon schválen. Takže by to znamenalo předložit novelu, ta by musela projít Parlamentem. Navíc v téhle době, kdy Parlament nezvládá řešit ani věci související s Covidem. To je nereálné, bohužel.
Tak bohužel zdrojáky asi neuvidíme (takže nezištnou pomoc od ajťáků nedostanou) ale pokud skutečně na každý KeyUp při zadávání adresy posílali přes AJAX dotaz a nějak ho vyhodnocovali pomocí LIKE, tak to je hodně overkill (navíc to asi má smysl posílat po třech a více písmenech, ne dřív).
Snad to všechno nenacpali do jedné nenaškálované DB :-)
Těžko říct. Nemám přístup k neoficiálním informacím, a nevím vůbec nic, jak je to udělané. Z toho, co bylo zveřejněné, si nedokážu udělat vůbec žádnou představu. Možná použili jazyk pro laiky, možná mlží, ale v podstatě neřekli nic konkrétního. Ale je to možné. Pán Bůh ví na čem to běží a jak je to udělané.
To asi nemají, když jim to nestíhá :-) Jinak co jsem zdálky sledoval pár statních zakázek (resp. ne pár, ale tři), tak tam se jelo Oracle nebo DB/2, protože prachy na to byly a nikdo nebrblal, že je to nějaký divný opensource (a samozřejmě by to ve všech třech případech, o kterých vím, PostgreSQL naprosto bez problémů ustíhala).
Je dobré vědět, že LIKE je v pohodě... nevidím u hodně věcí důvod duplikovat velkou část infrastruktury pro hledání, když už člověk databázi má. Vidím nějaké výhody v cache pro nejvýše zatíženou část, např. jak jsem nastínil výše s našeptávačem adres.
Nevidím důvod, proč by cokoliv z aplikačního kódu muselo být napsáno v C. Je pár lidí, kteří to umí a může to být bezpečné. Ten zbytek ať radši použije třeba Javu a ti osvícenější třeba Clojure... výkonu bude pořád ještě dostatek a nebo se v cloudu naklikne o facku větší server. Nemá smysl řešit něco na co nejvyšší efektivitu, když je to jednorázovka na sčítání lidu a za 10 let bude nejspíš úplně jiná technologie.
Záleží na zátěži - pro 10K přihlášených uživatelů na dnešních strojích nemusíte nic vymýšlet. Pro 100K přihlášených uživatelů to ani dnešní hw nemusí utáhnout, pokud by se objevil jakýkoliv problém. U předpokládané velké zátěže chcete dekompozici, navíc když se nabízí oddělit kritickou komponentu od nekritické, tak je hloupé to nevyužít.
A ty komponenty musíte mít na jiném železe. Můžete mít všechno perfektně vymyšlené, ale jedna nekritická a tudíž ne tak důkladně otestovaná komponenta vám utaví CPU, a jakmile se dostanete na 80% výkonu CPU, tak ten systém se může začít chovat nepredikovatelně - některé operace se silně zpomalí, začnou problémy s timeouty, mohou se vám objevit chyby na síťové úrovni. Věřte mi, že jsem tyto problémy viděl ne nejlepším železe, které můžete v cloudu mít.
Já udělám dotaz s LIKEM s trigramovým indexem za 2-5 ms i na velkých datech (pokud data budou v RAM). Na dedikované mašině s správným algoritmem máte garantováno, že data budete mít v RAM, a můžete se dostat na 10us. To třeba u napovídání výrazně zvyšuje uživatelský komfort. Pomalé napovídání tam nemusí být.
Efektivitu samozřejmě má smysl řešit - zvlášť u aplikací, které oslovují velký počet uživatelů a kde dopředu nevíte, jaká bude zátěž. První dojem je první dojem, a ostudu kterou utržíte už neodčiníte. Pokud máte relativně efektivní systém (není to realtime), tak můžete mít velkou rezervu v hw, a lépe překonáte případný problémy. Bez výkonnostní rezervy vás i malá prkotina rozhodí.
Ty mašiny mají brutální výkon - ale roste komplexnost aplikací (používají se komponenty, o kterých pouze předpokládáte, že se nějak chovají), a klesá technická zdatnost a odbornost vývojářů - a ty aplikace jsou hodně pomalé. Jako školitel i jako konzultant potkávám hodně vývojářů, a se znalostmi technologie je to čím dál tím horší. Pokud si ti vývojáři plavou ve svém rybníku, a píší aplikace na které jsou zvyklí, tak se to odehrává relativně bez průserů. Aplikace jsou sice pomalé, ale všichni si zvykli. Pokud se potkají s něčím novým, a problémem, tak nemají tušení, co se děje, a co je špatně. Problém je, že hw výkon ani neroste lineárně - a náročnost některých algoritmů, úloh může být exponenciální.
Jako u velkých systémů apod. určitě máte minimálně z pohledu DB mnohem větší zkušenosti než já. Fakt se mi ale nezdá, že by na sčítání lidu nemohl stačit stroj typu m6g.metal (64 jader Graviton 2, 256 GB RAM, 2 x 1900 NVMe SSD) za 5500 $ na dva měsíce, dejme tomu, že pro redundanci tam bude ještě jeden v hot-standby a taky se zaplatí za traffic apod. Myslím, že ~ 20 000 $ za ty dva měsíce by mohly stačit. To je ani ne půl milionu korun - ano, to je hodně peněz. Za tým rozumných 3-4 inženýrů v Praze dám ale za měsíc jako firma asi víc.
Možná by stačilo několik strojů CCX51 u Hetznera za ~ 330 € na měsíc (32 dedikovaných vCPU, 128 GB RAM, 600 GB NVMe SSD + pár TB SSD block storage (50 €/ TB/ měsíc)). Prostě ty stroje jsou fakt strašná děla na formulářovou appku.
Pokud máte nějaký konkrétnější příklad, kde by 100 000 spojení "tavilo" servery, tak sem s ním. U formuláře, klidně i s našeptávačem, to ale podle mě bude spíše nezajímavá zátěž.
Ve špičce jste schopný takovou mašinu utavit. To není problém - několik neoptimálních dotazů vykonávaných paralelně v 400 procesech vám vyžere veškerý výkon. Není problém mít dotaz 500 ms a po úpravách a přidání správných indexů tentýž dotaz má 5 ms (na 100GB databázi a data jsou v RAM). 64 core takových dotazů zvládne 120 za sec (zvládnete obsloužit 200 uživatelů za sec - ale ve frontě jich máte 1000).
Samozřejmě, že když se ta aplikace vyladí, tak nepotřebujete ani desetinový stroj, a ještě budete mít rezervu. Jenže na to vyladění potřebujete určitý čas v režimu hodně podobném provozu. Napsat složitější aplikaci, která funguje na první dobrou je velice drahá záležitost - jsou provozy, kde to je nutné, a náklady jsou 10x až 100x větší než u běžných komerčních aplikací (jaderná energetika, letectví, ..).
Vemte si automobilový sport - tam na vyladění konkrétního vozu potřebujete odjezdit závodně jednu sezónu - a nikomu to nepřijde divné. Jenom v IT se očekávají snad zázraky, a čeká se, že aplikace poběží od 1 minuty na plný výkon - přičemž dopředu neznáte a ani nemůžete znát zátěž. A co se týká software, tak to je mnohem větší hromada sraček než to, s čím se musí potýkat strojaři a konstruktéři. Máte nad sebou desítky vrstev, desítky různých heuristik a optimalizací, a nikdo nemůže seriózně říct, jak se to bude chovat pod skutečnou zátěží.
Bohužel, ke všem problémům, kam se dostanu, podepisuji NDA, takže nesmím sdělovat detaily. I 100K uživatelů by se za normálních okolností mělo nějak rozumně rozprostřít v čase. Nicméně, když máte někde nějaké úzké hrdlo nebo například zámek, který uživatele sesynchronizuje, tak mohou udělat velký tlak na některé komponenty. Pokud je možné použít fronty, tak se vám requesty naštosují do front, což je ook, může ale dojít k timeoutům, a k lagování. Pokud nemáte fronty, a otevřete příliš mnoho vláken nebo procesů, tak vám mohou CPU vyžrat zámky (spinlocky) nebo context switch a průchodnost celého systému dramaticky klesne - o několik řádů.
Na databázích je hodně hezky vidět nelineární chování - do určitého násobku počtu paralelně vykonávaných dotazů vůči CPU cores se roste výkon databáze. Pak stagnuje, a pak dramaticky klesá. Bohužel v praxi se ukazuje, že je dost těžké odhadnout jaká bude zátěž, a je to těžké i nasimulovat. Třeba i proto, že to drahé železo z brutálním výkonem máte jen jedno, a rozhodně vám nikdo nekoupí druhé pro testy. Další problém je, že těch opravdových špiček je málo, a nemáte moc příležitostí vidět systém při extrémní zátěži. Navíc dost problémů je způsobeno souhrou určitých faktorů - od úplně pitomého návrhu, přes problémy s virtualizací, problémů s výkonem hw, špatné diagnostiky. Většina problémů s kterými jsem se setkal jsou a byly řešitelné. Ale potřebujete čas na to aby se projevily, abyste je mohl identifikovat, a aby se daly opravit.
Díky moc za výživnou odpověď.
Ano, za něco přes rok jsme měli přesně jeden dotaz nad PostgreSQL, který byl problematický a nevíme přesně proč:
-- :name get-shared-orgpages :? :*
-- :doc gets all orgpages shared with a given user
SELECT orgpages.id, orgpages.val, orgpages.owner, permissions_token.token FROM orgpages
INNER JOIN permissions ON orgpages.id=permissions.resource
INNER JOIN permissions AS permissions_token ON orgpages.id=permissions.resource
WHERE permissions.user_id = :user AND permissions_token.token IS NOT NULL AND permissions_token.permission = 'V'
Tohle je nyní v pohodě:
-- :name get-shared-orgpages :? :*
-- :doc gets all orgpages shared with a given user
-- We are using inner query because joining two permission tables at the same
-- moment causes the server CPU usage to blow up. Unsure why.
SELECT orgpages.id, orgpages.val, orgpages.owner, permissions.token FROM (
SELECT * FROM orgpages
INNER JOIN permissions ON orgpages.id=permissions.resource
WHERE permissions.user_id = :user
) AS orgpages
INNER JOIN permissions ON orgpages.id=permissions.resource
WHERE permissions.token IS NOT NULL AND permissions.permission = 'V'
V podstatě je tohle jediné místo, kde je něco jako "unsure" v komentáři. Ano, v Clojure apod. jsou taky určité pasti/ méně očividná místa, kde by něco mohlo vybouchnout, ale je jich fakt hodně málo a obyčejně jsou dost známá. Mám pocit ještě z předchozí práce, že ale s SQL přeci jen bojuje víc lidí.
Máte tip na nějaké dobré knihy/ jiné materiály, které byste doporučil programátorům a administrátorům SQL, klidně s větším ohledem na PostgreSQL? Mám pocit, že buď jsou obecně o SQL se skoro nulovým vhledem do konkrétní implementace z administrátorského hlediska (nebo je to o MySQL, Oracle, MSSQL) a nebo jsou to špeky pro ty servery s 100k+ spojeními, o kterých se bavíme. Možná je taky prostě psát čtivé a přitom výkonné SQL těžké.
S SQL bojuje víc lidí, protože jim chybí absolutní základy, a vůbec netuší, jak SQL databáze fungují - a přitom je to docela snadné.
Dobrá je knížka https://use-the-index-luke.com/ a ta je hodně útlá. Kdysi jsem jí recenzoval na rootu. Četl jsem chválu na https://theartofpostgresql.com/ - autor umí psát a perfektně rozumí Postgresu (a pár důležitých věcí do pg napsal).
Jinak k Postgresu - podívejte se na český web a přečtete si alespoň Desatero
https://postgres.cz/wiki/Desatero
případně volně dostupné podklady k mým školením https://postgres.cz/wiki/%C5%A0kolen%C3%AD
permissions_token.token IS NOT NULL AND permissions_token.permission = 'V'
Tam budete mít patrně silnou závislost mezi sloupci, tudíž je možné, že tam podstřelují odhady a padá to do nested loopu - základ je podívat se na EXPLAIN ANALYZE - a zkontrolovat odhady. Řešením bývá buďto vícesloupcový index nebo podmíněný index - střílím to od stolu CREATE INDEX ON permission_token(perminssion) WHERE permission_token.token IS NOT NULL
Moc děkuji za materiály a radu.
To desatero vypadá, že je místy poměrně aktuální, jinde ale mluví o PSQL řad 7, 8 a 9. Nejsem si jistý, jestli tyto připomínky platí i u PSQL 12, 13 apod. a nebo to je již jinak. (Asi není potřeba na toto odpovídat, určitě si ještě během následujících týdnů a měsíců desatero projdu vícekrát.)
To desatero se postupně vyvíjelo, - tak jak se vyvíjel Postgres a jak já jsem získával zkušenosti s Postgresem. Snažím se to udržovat aktuální. Ty fundamenty Postgresu se moc nemění - MVCC je v Postgresu +/- stejné 20 let. Zlepšuje se výkon - zlepšuje se chování na aktuálním železu, ale na druhou stranu dost se zvedá velikost dat - dnes 100GB databáze už je skoro běžná záležitost a není to díky blobům, a klesá obecný přehled vývojářů, což je daň za specializaci. Dřív chca nechca se aplikace musela podřídit databázi - jinak to nefungovalo. Dneska se už dá databáze znásilnit.
Když jsem před 25 roky začínal, tak člověk byl prostě programátor (nerozlišoval se jazyk, nerozlišoval se backend/frontend - ani to tehdy na PC neexistovalo) - a skoro se dalo rozumět všemu. To už dneska moc nejde.
S tou specializací máte pravdu. Problémem také je, že je prakticky všechno přesložitěné. Od webu po assembler je prakticky všude konzistentní jen to, že jsou věci nekonzistentní :-) a možná zbytečně složité.
To, co by mělo poskytovat robustní základ poskytuje spíše takové lešení. Programátoři a administrátoři se točí kolem nedodělků a ztrácí čas podružnostmi, které by ve spoustě případů mohl vyřešit program/ počítač automaticky a neotravovat.
Mimochodem PostgreSQL není úplně výjimkou. Je v něm několik věcí, při kterých musím prakticky server odstavit, protože se změnilo nějaké nastavení, přidal modul nebo tak něco, sám to určitě víte mnohem lépe kde všude a co všechno nejde dělat při produkčním použití a je potřeba údržba. Nevím, jak moc se vývojáři zamýšlí nad tím, jestli by nešlo náhodou více těchto zásahů řešit za běhu včetně třeba aktualizace/ upgrade serveru. Přechod mezi verzemi by tak byl nejspíš mnohem hladší.
Jinak jsou místa, kde si člověk ještě šáhne na všechno od frontendu a financí až po backend a administraci serverů. Jsou to typicky malé startupy, kde prostě musí všichni umět do jisté míry všechno. Ano, i zde je specializace, ale často umí programovat jak CEO tak CTO a CFO, CTO obyčejně s odstupem nejlépe. CEO by ale podle dokumentace uměl asi v případě nějaké nehody třeba po telefonu s CTO rozjet produkci. Bylo by to vyčerpávající, ale kdyby nic jiného nezbývalo, tak by to asi zvládl.
Všechno tohle jde aspoň po nějaký čas typicky na úkor osobního života... to je holt podnikání (taky nejspíš znáte dobře).
Postgres byla databáze pro fabriky, univerzity a státní instituce, kde se nejelo 24x7. To, že dnes se v tomto módu používá neznamená, že je pro to psaná. Na druhou stranu, co se bavím se zákazníky, tak vždy mají nějaké servisní okno. A zase díky architektuře postgres je držák. Hromada vlastností vychází z možností přelomu 80/90 let, kdy Postgres vznikal, a kdy jste se snažili využít výkon železa do maxima. A je to také dáno možnostmi komunity, která na vývoj nemá tolik prostředků, jako komerčního sw (i když vývoj je dnes dobře zajištěný). Až cca 10 let zpátky byl Postgres čistě hobby projekt.
Samozřejmě, že vývojáři se hodně zamýšlejí nad údržbou - ale jde o kompromis mezi složitostí vývoje, údržby, používání, výkonem. Nemůže být všechno. Něco je dáno architekturou (založenou na procesech) - a vlastnostmi sdílené paměti v operačním systému. Pokud chcete stejnou adresaci sdílené paměti, tak ji musíte alokovat pouze při startu. Ale to je minimum extenzí. Většinu extenzí můžete bez problémů přidat a odebrat bez restartu. Zase dost adminů ten Postgres restartuje zbytečně, protože netuší, co potřebuje restart a na co stačí reload. A co vidím, tak i admini, kteří používají Postgres roky a považují se za seniory nemají ani základní znalosti. A bez znalostí je všechno těžké.
Já abych se dostal na nějaký level, tak jsem 10 let nedělal nic jiného. Platí pravidlo 10 000 hodin, aby se člověk dostal na expertní úroveň. Znalosti a zkušenosti samy od sebe nepřijdou. Člověk jim musí jít naproti. Na běžných projektech se člověk tady nic moc nenaučí, je to taková navoněná bída (a v cizině je totéž - technologicky zdatných firem je málo - ale jedině tam se člověk něco naučí). Teprve když jsem se nachomýtl k vývoji Postgresu, a začal dělat i support a řešit nejen svoje problémy, tak se člověk mnohem rychleji posouvá.
Interaktivní věci není nutně tak těžké testovat. Rozhodně ne pitomý našeptávač... což bych nejspíš rozchodil na prakticky libovolně špatné webovce za odpoledne. Tady si ale oni systém navrhovali sami. Vygenerovat si ze začátku bydlišť (což je dostatečně podobné reálné zátěži) nějakou sadu řetězců, které pustím proti databázi je hodně podobná věc a dá se to měřit fakt jednoduše.
Jinak tohle je typická chyba špatného návrhu, pokud by to šlo proti nějaké SQL databázi. Adresy se mi během sčítání asi nezmění, to znamená, že je to read-only. Všechny adresy v Čr budou mít pár MB dohromady. Tohle se dá držet klidně v aplikačním serveru, do kterého se to hned po startu aplikace načte jako nějaký hledací strom/ množina nebo něco a hledá se v tom. Alternativně se dá použít něco jako Redis... asi není potřeba na tohle nasazovat Solr nebo ElasticSearch.
Jako všech 170 000 lidí asi najednou nevyplňuje adresy a i kdyby, tak mnou popisované řešení škáluje horizontálně bez problému s počtem aplikačních serverů.
Nejsem si jistý, ale pokud v dnešní době jakékoliv sčítání lidu utaví síťové prvky nebo monitoring tak asi děláme něco špatně. Jako 170 000 současných spojení by asi šlo řešit jedním serverem, který by ani nemusel být za load-balancerem, kdyby se tam necpaly nesmysly. Nakonec je to záležitost asi na měsíc nebo dva a potom se to dá zase vypnout nebo zmenšit na minimum... ideál pro cloud.
Jiný kolega zde v diskuzi měl také pravdu, že všechna potřebná data stát již má v mnohem lepší kvalitě z různých úkonů se státní správou. Takovéto explicitní sčítání lidu je v roce 2021 s velkou pravděpodobností mimo mísu. Musíme se tedy ptát, proč se ještě realizuje a kdo je zodpovědný za to, že se systém ještě neupravil, aby méně otravoval občana.
> Jiný kolega zde v diskuzi měl také pravdu, že všechna potřebná data stát již má v mnohem lepší kvalitě z různých úkonů se státní správou.
Nezapomínejte, že ve společnosti jsou - za mne oprávněné - obavy ze spojování databází ve státní správě.
Proto radši sčítání lidu jednou za deset let, než online provázání do detailu ...
Tohle je separátní téma, jestli stát potřebuje na všechno informace, jestli nestačí nějaký statistický souhrn (který anonymizuje) apod.
Tady šlo čistě o to, že státní zaměstnanci si ulehčují práci, protože prostě zadají plošné sčítání místo aby si data posháněli z jednotlivých úřadů. Nikdo neříká, že by potom tyto úřady mohly resp. měly moct jen tak ke všem těmto datům přistupovat. Další výhodu by mělo, že kdyby se potil ČSÚ se všemi úřady, možná by byl větší tlak mít data v nějakém rozumném, konzistentním formátu a z toho by vyplývalo mít možná od ČSÚ nebo jiných orgánů odpovídající nástroje.
Na druhou stranu po zkušenosti s vyplňováním statistiky o nově vzniknuvší firmě ve formuláři ČSÚ je možná jediná realistická varianta zůstat u toho plošného sčítání a radši po nich nic nechtít. UX tam byl absolutně otřesný, formulace dotazů byla horší než kdyby člověk četl nějaký obskurní zákon. Hlavně ale musí otravovat subjekty, které mají plnou hlavu jiných věcí.
Adam Kalisz:
– Občan ČR: Nebudu si měnit trvalé bydliště, stát to nepotřebuje vědět, počty obyvatel přece zná ze sčítání.
– Tentýž občan ČR: Proč musím ve sčítání uvádět bydliště, vždyť ho stát eviduje v evidenci obyvatel.
Sčítání se dělá právě proto, aby se podchytily i ty případy, kdy má stát v registrech špatná nebo žádná data. To, že se stejná data sbírají různými způsoby, je běžné – je to známý způsob, jak předcházet chybám a systematickému zkreslení. Je možné, že si jednou řekneme, že ta existující data už jsou tak dobrá, že sčítání nepotřebujeme – ale asi to zatím není případ ČR. Ale zrovna evidence obyvatel před sebou podle mě má ještě dlouhou cestu.
Nestanovují se na základě toho náhodou třeba senátní volební obvody? Také jsou to informace o migraci, třeba zda a jak se vylidňuje venkov, zda se lidé stěhují do větších měst nebo rovnou do Prahy apod. Že si Praha udělá odhad na základě mobilů je hezké, ale není to zjištěné pro celou ČR a nepozná se z toho, odkud do Prahy ti lidé přicházejí.
@PQK
Nezapomínejte, že ve společnosti jsou - za mne oprávněné - obavy ze spojování databází ve státní správě.
Jestli problém není jinde, protože spojení databází se nabízí jako správná varianta z pohledu systému. Možná to bude tím, že stát toho "ví" a organizuje až moc a to ještě ke všemu často používá paradoxně tato data proti občanům. Tak si říkám, jestli to řešení neleží pak úplně jinde ...
Ano, IPv4 (IPv6 scitaní.cz nepodporuje) adresy patří očividně MS Azure. Není mi jasné, odkud Rojíček bere, že data "Jsou na území ČR v cloudu, který provozuje stát. Přístup je umožněn jen vybraným pracovníkům statistického úřadu". [0] Data jsou snad ukládána šifrovaně... možná je to tedy o něco složitější:
"Vámi poskytnuté údaje jsou ukládány šifrovaně, a to ve vysoce zabezpečeném prostředí Státní pokladny Centra sdílených služeb na území České republiky. Státní pokladna Centra sdílených služeb disponuje vlastními bezpečnými datovými centry s nejmodernější architekturou. Data jsou následně v tomto zabezpečeném prostředí zpracovávána za účelem vytvoření statistických informací" [1]
[0] https://denikn.cz/minuta/591813/?ref=mpm (konkrétní odkaz na ČTK tam bohužel nedali)
[1] https://www.irozhlas.cz/zpravy-domov/scitani-lidu-2021-formular-data-bezpecnost_2103251044_ako
Samozřejmě, je otázka, jestli je šifrování asymetrické hned na klientovi (asi ne) a jak se s klíči dále pracuje, když už se tím šifrováním kasají. Nic proti tomu nemám, ale je také dobrá otázka, proč už frontend nemohl být "ve vysoce zabezpečeném prostředí Státní pokladny Centra sdílených služeb" (asi protože se s těmi lidmi/ rozhraním nedá moc dobře pracovat? protože to prostě nebude skutečný cloud ale glorifikované datacentrum nejspíš nad typickým VMWare stackem, ale to hledat nebudu.)
Nejaky naznak IPv6 na scitani precijen je... realne jen nekdo neumi poradne nastavit DNS.
www.onlinescitani.cz is an alias for csu-prod.azurefd.net. csu-prod.azurefd.net is an alias for star-azurefd-prod.trafficmanager.net. star-azurefd-prod.trafficmanager.net is an alias for dual.t-0009.t-msedge.net. dual.t-0009.t-msedge.net is an alias for t-0009.t-msedge.net. t-0009.t-msedge.net is an alias for Edge-Prod-PRG01r3.ctrl.t-0009.t-msedge.net. Edge-Prod-PRG01r3.ctrl.t-0009.t-msedge.net is an alias for standard.t-0009.t-msedge.net. standard.t-0009.t-msedge.net has address 13.107.246.19 standard.t-0009.t-msedge.net has address 13.107.213.19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:46::19 standard.t-0009.t-msedge.net has IPv6 address 2620:1ec:bdf::19
Já jsem nakonec vlatně rád, že v tom má stát elektronický bordel. Jenom by zase získali další vektor člověka něčím prudit. Kdykoliv stát něco někde propojí nebo zprovozní, tak je to jenom k dalším problémům a otravování. Nechť se zeptají na co chtějí, aspoň je vidět, co zas provádí ...
Ve webařině jsem 10 let a s porovnáním co jsem viděl za poslední roky, tak toto bych ještě označil za zdařilý projekt a maximálně tak lehké komplikace ... pokud jim to teda pod náporem neshořelo ;-)
Kdyby jen Marie Terezie.Taky cesar Augustus by mohl vypravet. No coz. Treba bychom meli vanoce trochu jinak...
To ze se museli lide presunout do sveho trvaleho bydliste je takova libustka kterou urednicka pakaz tak nejak stale tech 2000 let opakuje.
V minulosti ridicaky, stale nutnost navstivit yrvale bydliste nebo mit volicsky prukaz na volby jinde atd.
Podle vyjádření mluvčí, která se nejvíc soustředí na "žádný únik dat nebyl a nehrozí", "údaje jsou dokonale zabezpečeny" a "SAMOZŘEJMĚ k ohrožení bzpečnosti systému nedošlo", ... tak je mi naprosto jasné, že jim zase někdo hacknul wordpressový plugin. Státní IT je fakt mazec :D
Na druhou stranu jsem rád. Ráno to potvrzovalo nevalidní formulář, takže jsem úspěšně sečtený, aniž bych vyplnil cokoli jiného, než jméno a op :) (více informací nežádali)
Sorry, chlapci a děvčata. Zkusil jsem to, nefunguje to... tak zase za 10 let.
Už jsem to psal výše, ono to ráno opravdu potvrzovalo sečtení jen na jméno a OP.
Za mě jsem to vyřešil poděkováním ČSÚ, že to mají tak dokonale podchycené a protože už o mě ví, tak nevyžadují žádné duplicitně vyplňované doplňující údaje. :) Já nejsem povinen pátrat, jestli to byla "chyba". Dostal sjem naprosto jasné potvrzení, že jsem v pořádku sečten, tím to pro mě na dalších 10 let padlo :) (ale v opačném případě, když by jim to jméno a op nestačilo, tak bych raděj dobrovolně zaplatil pokutu, než se nechat takto ochočit a sdělovat někomu soukromé osobní informace. Ty raděj svěřím facebooku, než českému vládnímu IT)
Tak zrovna u takového registru vozidel se stačí zeptat, kolik toho do teď vyřizují denně či měsíčně a získáte představu o tom, o jakém provozu je řeč. Větší poskytovatelé a poskytovatelé cloudových služeb nabízejí load balancery a škálování v podstatě v základu a pak, podle očekávání musíte zvolit odpovídající datové uložiště. Třeba takové, které umí fronty ... s tím ale souvisí to, o čem aplikace je. Např. odeslat sčítací formulář, zobrazit uživateli "Odesláno, občane", dát do fronty a nechat zpracovat by neměl být takový problém. Např. Elasticsearch zpracovává požadavky jako fronty by default a horizontální škálování je přímo usage by design. Pokud uděláte standardní web něco jako LAMP a vrazíte to na 4GB + SSD virtual u Wedosu, doškáloval jste ...
Ďábel se skrývá v detailech, takže záměrně nepíši nějaký seznam technologií - v práci používáme v této krajině AWS S2, Elalsticbeans a RDB + Elasticsearch (AWS), ale já nejsem sysadmin, takže úplné detaily neznám. Různá zákoutí jsou šílená, ale funguje to i na poměrně nárazové a objemné operace.
Základ je zjistit parametry - jinak budete škálovat Facebook v 150 zemích po planetě a jinak budete škálovat registr vozidel z poměrně jasnou a specifickou zátěží ... a nebo ne ;-)
27. 3. 2021, 12:27 editováno autorem komentáře
Problém je, když něco musíte ověřovat jinde. Ten registr vozidel (kromě diletantské chyby v nastavení DNS) havaroval na ověřování VIN v databázi kradených vozidel (provozuje PČR). Registr vozidel tu databázi položil
No a sčítání má údajně problém s ověřováním adres - to je taky něco, co provozuje někdo jiný.
Dá se předpokládat, že lidi a byty budou při sčítání součástí získávaných dat. Sčítání je ze zákona, tyhle data mít můžou, ať si právníci říkají cokoliv.
Pokud ty data mám, můžu je hodit do cache. To už je věc architektury a implementace.
Pokud je backend zabezpečený, další stroj nebo virtuálka uvnitř, schovaná za web serverem, by měla být z pohledu bezpečnosti OK, pokud si do ní nějaký hovado na home office neudělá přístup po telnetu a podobný hovadiny.
Odhadnout se to taky dá - pokud předpokádám 10k klientů současně a počítám, že normálně člověk dá 3 znaky/s, nemám cokoliv pod 30k hledání/s smysl. V těch ani ne gigabytech by to nějaká rozumná cache dala s prstem v nose, klidně i o řád nebo dva víc.
Takže za tohle může jen a pouze dodavatel. Sorry
Na slovensku je to velmi podobne. Ja som sa napr. scital 3x. Nedostal som na vystup ziadnu hlasku, ze moje rodne cislo uz maju v databaze ani nic podobne. Proces aj na treti krat dobehol uspesne do konca.
Samozrejme v kazdom scitani som odpovedal na otazky trochu inak a teraz neviem, ci budem scitany skutocne 3x, alebo ktory zcitaci harok budu povazovat za spravny.
Proste tie nove apky co robia studaci su nedokonale. Resp. analitici, ktori zadavaju programatorom ulohy su asi nedostudovany a banicku fakultu opustili po tretom semestri.
A co sa tyka vypadnutia serveru (niekto pisal, ze to bezi v azure). Je mozne, ze to testovali na raspberry a ked to fungovalo, tak to spustili. Avsak pozabudli na to, ze to nechali na raspberry aj v produkcii, zatial co si mysleli, ze je to v azure :-D
Neviem sice kde bezia statne servery, ale urcite budu mat prenajate nejake datove centra, kde bude dobra konektivita, ale aj dost vypoctoveho vykonu a zvladnu napor aj desiatky-tisic pripojeni.
Alebo si objednaju docker s 500Mhz CPU a 256MB RAM ?
Mám takový dotaz... pokud to celé běží v cloudovém Azure, jak je zajištěno, že data nikdy neopustí jurisdikci ČR? Nebo se prostě courají internetem a zpracovávají tu někde, tu jinde?
Za prvé, u všech provozovatelů cloudu si můžete smluvně zajistit, že data neopustí EU. Za druhé, cloud Azure nebo jeho části můžete provozovat i na svém hardwaru. U cloudových aplikací typicky komunikujete jen s nějakou bránou, zbývající infrastruktura aplikace je za ní schovaná a z venku nevidíte, kde je.
Věřte, že bezpečnost těch dat si ČSÚ velice pečlivě hlídá.
Hmm, Proč tedy Microsoft coby provozovatel Azure, na jehož infrastruktuře to prokazatelně je, není uvedený jako smluvní zpracovatel? https://scitani.cz/csu/scitani2021/ochrana-osobnich-udaju
Smlouvu máte? A můžeme ji vidět?
Pokud je vlastni databaze u SPCSS (a vypada to tak), tak se primo v Azure zadne udaje zpracovavat nutne nemusi.
Počkejte, to že vezmu tls provoz a dešifruju ho, tak už teď mám citlivá osobní data v plně čitelné podobě a i to že je nějakým způsobem zabalím do jiného requestu pošlu dál do "vysoce zabezpečeného datacentra" je jejich zpracování (nejsouce právník tak odhadnu že do "předáváná" os. údaje to zapadá), kde předpokládám že je povinností správce zajistit jejich ochranu - tedy aby neskončily někde v logu a ten log někde kde nemá, etc.
V případě opačného výkladu by si každý státní úřad mohl dovolit nechat zakončovat šifrovaný traffic u evil.org, což zcela jistě zákonodárce v úmyslu neměl.
Pokud si státní správa u nás hlídá data, tak pro to má jeden ze tří pádných důvodů:
1) Slíbili kamarádovi, že je nikdo jiný nedostane - jízdní řády pro CHAPS, příprava legislativy na míru,...
2) Protože se dá na datech rejžovat - normy, historie meteorologických dat, kolky za všemožný výpisy
3) Protože po zveřejnění by měl nějaký papaláš průšvih - data o epidemii, výběrka,...
Jinak na cokoliv ohledně zabezpečení dat kaká alík
Taková klasická twitterová podpásovka. Na vývoji jsou angažované subjekty SPCSS_sp, OK systém, ICZ , Komix, Good at IT. Některé znám a nepovažuje je za nazdárky typu "studenti X a Y". O to víc mě zajímá odpověď na otázku, jak je možné, že i když na produktu spolupracují dejme tomu subjekty, které mají know-how a historii, vznikne šmejd.
Ten uvedený řetězec byl samozřejmě obecný příklad.
Když už uvádíte konkrétní jména společností, tak v tom případě by řetězec mohl vypadat asi následovně: Stát - Firma A (registrovaná bůhvíkde) - Firma B (z vašeho seznamu) - Firma C (další solidní česká firma) - student/ičař X (kterého třeba firma C podpoří dalšími svými pracovníky).
Většina peněz se odfiltruje na začátku řetězce a na konci řetězce se odvádí práce odpovídající financím, jež tam dotekly.
nmap -sV scitani.cz
Starting Nmap X.XX ( https://nmap.org ) at XXX-XX-XX XX:XX XXX
Nmap scan report for scitani.cz (13.107.246.19)
Host is up (0.014s latency).
Other addresses for scitani.cz (not scanned): 13.107.213.19
Not shown: 997 filtered ports
PORT STATE SERVICE VERSION
53/tcp closed domain
80/tcp open upnp Microsoft IIS httpd
443/tcp open https Windows-Azure-Web/1.0 Microsoft-HTTPAPI/2.0
Nmap done: 1 IP address (1 host up) scanned in 19.05 seconds
"Z preventivních důvodů jsme přikročili k uzavření formuláře do chvíle, než situaci důsledně vyhodnotíme a podnikneme kroky nutné k dalšímu bezpečnému provozu." (archive.org).
Sním či bdím?
V souvislosti se sčítáním mě napadla jedna otázka netechnického rázu. Kdyby nenastaly problémy, asi bych o žádném sčítání ani nevěděl. Možná za to může Covid, možná to, že nemáme doma televizi, ale nevíte někdo jaký byl oficiální kanál, kterým se lidé měli dozvědět informaci o tom, že nějaké sčítání bude?
Všemožnými médii (mj. lupou) to probíhá už nějakou dobu *. A po konci online části bude chodit papírový formulář klasicky do schránky.
[*]: takže jestli si cíleně zacpáváš uši... nebude ti pomoci
take jsem o tom netusil, nebyt vypadku - a to posloucham cesky rozhlas, kdyz jedu zrovna autem
ale jinak dobra taktika, jak to bez medialni masaze v dobe masaze covidem a hlasovanim o prodlouzeni nouzoveho stavu sdelit celemu narodu i na samotu, ze scitano prave zaclo a kazdy je povinnem se secist, na mne to zafungovalo - ac rano jsem o scitani vubec nemel zadnyho tucha, tak nyni jsem jiz par minut secten
Ja mel nejake matne povedomi, ze letos to bude. Presny cas jsem zjistil az cca pred tydnem nahodou na lupe. Dnes jsem to videl na twitteru a nyxu, kde bych to zaregistroval i bez padu systemu.
Udajne jsou nejake reklamy na YT a jinde, ale ty se mi pres placene YT a reklamoblock nezobrazily...
Dovedu si snadno predstavit, ze bych se to nedozvedel vubec (TV nemame, radio take ne, obcas si dam neco jako suchy unor bez vetsiny mimopracovniho internetu). Ve schrance na sneci postu letak nebo formular zadny.
Já právě dnes ještě na Twitteru ani nyxu nebyl, a žádné hlášení jsem dnes nezaznamenal, ale je dost snadné ho přeslechnout, já běžně teď v "zimě" mívám zavřená okna a navíc často bývám v pokoji směrem do zahrady a tam není rozhlas slyšet... české rádio poslouchám jen v autě a jak nám teď zavřeli okresy tak moc nejezdím, takže to taky padlo...
Ale jako asi bych se to dřív nebo později nějak od někoho dozvěděl. Spíš bych čekal, že u něčeho takového přijde nějaké oznámení do (fyzické) pošty třeba...
“... je zpráva považována za doručenou desátým dnem po dodání zprávy do datové schránky...”
https://www.mojedatovaschranka.cz/static/ISDS/help/page3.html
Jo, toho jsem si všiml ráno, když se tam ještě dalo přihlásit. Tohle řval FF po přihlášení do toho formuláře (dál jsem se nedostal, v té době to spadlo):
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://dc.services.visualstudio.com/v2/track. (Reason: CORS request did not succeed).
Tak jsem kus vyplnil, dal uložit a... překvapení
27. 3. 2021, 18:34 editováno autorem komentáře
Tak sem to celý komplet vyplnil a nakonci to spadlo ;).
Asi to pánové stále nemají ok ...
Asi jsem měl štěstí jak vidím ostatní reakce. Každopádně když jsem slyšel ve zprávách jak je to hrozně přetížený a jak doporučují se sečíst později, tak jsem to na truc vyzkoušel (včera v cca. 19:15).
Žádný pád ani zpomalené reakce webu jsem nepozoroval a už jsem sečtený. Jinak přihlášení přes NIA a mojeID také fungovalo jak mělo, jen jsem pak nepochopil proč se to ptalo na číslo dokladu když to bylo předvyplněný a zašedlý.
Když pominu přetíženost, tak UX je taky špica - než se člověk probojuje k formuláři, musí snad milionkrát kliknout, přitom polovinu času úplně zbytečně - google vás pošle na https://www.scitani.cz/, to vás přesměruje na https://onlinescitani.cz/, kde jsou ta samá tlačítka "Chci se sečíst" na těch samých místech. Pak se probojovat přes bankovní identitu nebo e-občanku, když už ji teda mám,... nebo najít doklad, opsat čísílka,... - a jsme na nějakých 10-15 kliknutích, než se vůbec přihlásíme. Chudáci babičky a dědečkové.
Jo, dík za tip: já to zkoušel přes bankovní identitu, přes MojeID a teď jsem vytáhl e-občanku - až mě napadlo, že jiná metoda nebude znovu přes NIA. Zkusil jsem přes datovou schránku, a kromě toho, že jsem musel zadat číslo občanky (které NIA poskytl), tak to bylo šup-šup, vyplněno, odesláno a odkaz pro ostatní členy domácnosti taky odeslán.
Tak by mě zajímalo, čím to může být.
Už vloni s DPFO jsem narazil: Datová schránka poskytla bydliště s částí obce dle katastru, zatímco DPFO očekávalo to, co je na občance (městská část). Že by byl zakopán pes tady?
Tohle se týká řady oblastí v Brně a Praze - jestli je to tím, muselo na to narazit dost lidí.
Ale to je čistě spekulace, co by mohlo být špatně na formuláři, kde vše zadané má správný formát.
29. 3. 2021, 15:51 editováno autorem komentáře