Sobotní ráno, první den sčítání lidu, nefunkční online formulář a následující nečekané vyjádření do TV.

Tyto události a snaha doplnit mé krátké vyjádření v TV, mě přiměly k napsání tohoto článku. Berte to jako můj osobní subjektivní pohled na projekt Sčítání, a co/jak/proč bych u takového řešení navrhoval udělat jinak. Myšlenky mě pak zavedly i do úvah kolem kooperace IT firem, roztříštěné odpovědnosti či negativních dopadů “cloudového myšlení”. Na závěr jsem si neodpustil i pár zbožných přání a to nejen v oblasti IT, ale i u lidí či médií.

Včera (v sobotu 27. 3. 2021) začalo po 10 letech další sčítání lidu. Chtěl jsem online formulář vyplnit v průběhu dne, abych to mohl pustit z hlavy. Ráno jsem si ale na sociálních sítích všiml posměšků na stranu vlády a autorů online formuláře, který prý nefungoval. Ze zvědavosti jsem nastartoval záznam všech požadavků prohlížeče a chtěl se do sčítání zapojit, abych zjistil, kde přesně problém je a vzal si z toho nějaké ponaučení i do své práce. Bohužel už bylo pozdě - celý formulář byl skrytý, takže jsem procesem projít nemohl.

Prověřil jsem ale chování samotného webu www.scitani.cz, zjistil jsem si používané FE technologie (doporučuji Chrome plugin Wappalyzer) a udělal si obrázek o kvalitě zpracování webu i s pohledem na serverovou odezvu, viditelnou bezpečnost, rychlost zobrazení, dostupnost nebo best practices. V rychlosti jsem viděl pár pozitiv i nedostatků, ale nic zásadního. Web využívá brotli kompresi, ale nevyužívá WebP ani základní lazy-loading obrázků. Web využívá CDN s HTML cache, ale nepodporuje TLSv1.3. U webu scitani.cz chybí i základní bezpečnostní HTTP hlavičky, ale u onlinescitani.cz naštěstí jsou, a to včetně CSP či HSTS. DNS překládají na 2 IP adresy, co značí HA řešení, i když pouze u jednoho (ale věřím spolehlivého) poskytovatele.

Řekl jsem si… docela OK, ale počkám, až bude znovu fungovat. Odhadoval jsem výkonnostní problém nikoliv v samotné aplikaci formuláře, ale spíše v nějakém dalším systému, ze kterého si formulář při vyplňování stahuje související data (např. vlastníky z katastru nemovitostí) a je na něm přímo závislý.

V sobotu kolem oběda nás oslovila redakce CNN Prima NEWS, zda bychom jim neposkytli vyjádření/názor na tuto již mnohokrát se opakující situaci se státním IT systémem.

Sám nejsem zastánce neustále kritiky na vládu a státní IT (i když velmi často, bohužel oprávněné) a zvažoval jsem, jestli možnost vyjádření vzít. Obvykle z rychlých vyjádření “IT expertů” v televizi nadšený nejsem - teď už chápu, proč a také vím, že není lehké tak široký problém vysvětlit v jedné větě. Taky jsem reportéra upozornil na to, že jsem sice v ČR 17 let, ale mám slovenský přízvuk a nerád bych lidi iritoval touto podobností s premiérem ČR :)

Nakonec jsem to vzal i bez toho, abych dobře znal kontext a pojetí výsledné reportáže, nebo přesnou příčinu problému. První vyjádření odpovědných vedly k problému s našeptávačem adres. Říkal jsem si, že z mé 18 leté dev/devops praxe odhadnu možnou příčinu problémů a nastíním i doporučení, co příště nepodceňovat. Můj cíl byl autory trošku obhájit a zároveň předat pohled a informace, které mohou jiné vývojáře alespoň trošku inspirovat při budoucí stavbě podobných řešení.

Jedním z rozhodujících faktorů proč jsem si myslel, že k tomu můžu něco veřejně říct je fakt, že našeptávač adresních míst pro ČR a SR jsme si v SiteOne sami vyvinuli u jednoho z našich produktů MapsOne, takže máme reálnou představu o tom, co to obnáší. Kde může být nejslabší místo a jak je možné službu dále škálovat. V tento moment sice naše služba na zátěž jako u celorepublikového projektu Sčítání dimenzována není, ale to by byla otázka 1-2 dnů práce a přesně víme, co pro to musíme udělat.

Měl jsem na přípravu cca 1,5 hodiny času. Po rychlé konzultaci s panem redaktorem mělo jít o 30-60 s vyjádření. Dal jsem si dokupy myšlenky, zkouknul ještě narychlo web scitani.cz a chvilku googlil, zda už o technickém problému není více informací. Nebylo. Sepsal jsem si kratší a delší variantu vyjádření (viz. níže), abych měl v hlavě alespoň nějaký scénář, utříděné myšlenky a nevařil jsem úplně z vody. Nakonec šlo o 7 minutový rozhovor, ze kterého redakce použila 10 vteřin. 10 vteřin, které bych s labelem “IT expert” moc nespojoval. Publikovali to v reportáži hned večer ve hlavních zprávách. Hrdý na to nejsem a mého naivního cíle jsem nedosáhl, ale každá zkušenost dobrá a příště bych šel do toho znovu - jenom bych se lépe informoval o formátu výsledné reportáže i formátu samotného rozhovoru, ze kterého se materiál použije. Navíc je mi jasné, že redakce dělala vše pro to, aby zvolená část vyjádření do výsledného formátu reportáže zapadla, co nejlépe.

„Dobrý den,

funkčnost elektronického sčítacího formuláře jsem hned ráno ze zvědavosti technicky prověřoval. Samotné webové stránky scitani.cz jsou na nápor připravené velmi dobře - to je ale vždy ten jednodušší úkol.

Z dostupných vyjádření plyne, že problém souvisí s nějakou formou našeptávače adres. To je dynamická část bez možnosti efektivní cache, vyžadující práci s databázi.

Právě podceněni škálováni databáze je obvykle nejslabším místem podobných aplikací. Databáze adresních míst je ale v kontextu 2 týdnů běhu Sčítání statická, také je potřeba Škálovat pouze čtení, co je vždy relativně jednoduchý úkol, na rozdíl od škálování zápisu, řešení zámků, atp.

Věřím, že zátěžové testy našeptávače autoři prováděli, ale pravděpodobně se jim nepovedlo dostatečně nasimulovat reálný provoz. Mohli např. synteticky otestovat, že našeptávač zvládá desetitisíce požadavků za vteřinu, ale ne pro tak různorodá data a adresy, jaké zadávají lidé z celé republiky a nelze tam efektivně využívat cache.

Vnímám v tom tato ponaučení do budoucna:

• Při testování být důsledný a nepodcenit ani malé, zdánlivě nenápadné, ale dynamické funkcionality (i selhání nefunkčnosti jednoho formulářového prvku ze 100, způsobí kolaps celého řešení).

• Používat osvědčené služby, které již v minulosti podobnou celorepublikovou zátěž úspěšně zvládly.

• U zátěžových testů simulovat co nejlépe reálný provoz a soustředit se i na různorodá data.
  TIP: archivovat z volání našeptávače všechny reálně hledané výrazy z aktuálního Sčítání a používat je při dalších zátěžových testech (tzn. sbírat reálný provoz a to co do vstupních dat, tak frekvence volání/zátěže).

• Sbírat výkonnostní metriky a umět je interpretovat s cílem předvídat max. možnou zátěž a možná rizika

• Nespoléhat tolik na falešné sliby "výkonu cloudu", ale mít v tymu opravdové profesionály, kteří databázím rozumí od nastavení vzhledem k HW, detailnímu monitoringu, návrhu datové architektury, škálování a po optimalizaci práce s databázi v samotné aplikaci.

• A na závěr nepopulární možnost, když selhávají jiné možnosti - rozložit zátěž doporučením (ale ne příkazem), aby se první den zapojili lidé s příjmením začínajícím na A-D, druhy den E-H, atd.

Každopádně ale držím autorům palce, aby problém co nejrychleji vyřešili a příště to zvládli lépe.“

Dnes je 2. den sčítání - neděle 28. 3. 2021 a web www.scitani.cz znovu obsahuje informace o přetížení. Včera odpoledne již autor řešení (společnost OKsystem) vydala prohlášení, ve kterém problém popisuje technicky i lehce detailněji a můj odhad příčiny byl správný - proběhlé, ale nedostatečně reálné zátěžové testování v kombinací s nevhodným řešením vyhledávání.

Adresní místa pro našeptávač jsou podle vyjádření umístěné ve stejné databázi, jaká se používá pro zápis informací ze Sčítání. To není samo sebou špatně. Nechci kritizovat, ale čekal bych, že si architekti a vývojáři v OKsystem uvědomí a reálně změří workload aspekty vyplňování formuláře a budou vědět poměry zápisů a čtení jednoho běžného uživatele a podle toho uzpůsobí i architekturu řešení a databáze. Chápu, že adresní místa mají v relační databázi kvůli referenční integritě (např. na majitele nemovitostí v katastru), ale způsob a z toho plynoucí zátěž na hledání v nich, měl být od začátku vyřešený důmyslněji, aby nemohlo dojít k omezování výkonu hlavní databáze.

V tomto konkrétním případě bych jako architekt volil jedno z následujících řešení. U našich projektů je často volíme i v případě, že očekáváme pouze tisíce uživatelů v jeden moment (řekněme v rozsahu 1 minuty). U projektů, kde se očekávají statisíce návštěvníků, by to měl být naprostý základ. Je to pouze o uvědomění si reálného workloadu, zkušenostech, dobrém rozhodnutí a pak o max. jednotkách dní práce navíc.

Možnost 1: pro hledání v textech nepoužívat relační databázi, ale na to vhodnější technologie, jako např. ElasticSearch či Solr nebo Sphinx. Zdrojová data ať jsou pochopitelně i v relační databázi, ale samotné vyhledávání ať probíhá u vhodnějších technologií, které navíc neovlivní výkon samotné databáze pod zátěží. A to obzvláště u jednoduchého scénáře jako tady, kde je databáze adresních míst prakticky statická a v období 2 týdnů (co Sčítání poběží) nedojde k žádné změně, nebo maximálně pár krát za den/týden.

Možnost 2: používat replikovanou databázi s více SLAVE servery a hledání (tedy čtení) v adresních místech provádět nad více SLAVE servery, aby to neomezovalo výkon zápisu MASTER databáze. V SiteOne pro vysokou dostupnost a škálování zápisů/čtení používáme primárně databázi MariaDB a MaxScale proxy, která nám umožňuje rozkládat čtení přesně podle potřeb jednotlivých projektů. A to všechno transparentně, bez jakéhokoliv zásahu do kódu samotné aplikace. Stejná řešení existují i pro databáze Oracle, MSSQL, PostgreSQL a další.

Možnost 3: nejsem velkým příznivcem všech rozkladů monolitů na mikroslužby (které jsem v praxi zažil), ale právě u takových funkcionalit jako je našeptávání adresních míst, bych čekal, že bude mít státní správa a IT firmy kolem ní, perfektně zvládnuté, zdokumentované, vysoce dostupné a naškálované sdílené mikroslužby, které se budou používat napříč různými státními systémy - a našeptávač adresních míst by měl být jedna z nich. Adresní místa pro celou ČR jsou jenom jedny a dává obrovský smysl je mít jako spolehlivou mikroslužbu s procesem na pozadí, který bude spolehlivě databázi adresních míst neustále aktualizovat (ať už z openaddresses.io jako v našem případě, či ideálně z nějakého interního a více aktuálního státního systému, např. katastru nemovitostí či ČSU).

Další netechnické možnosti popíšu i mezi zbožnými přáními na konci článku.

V sobotu večer se mi již podařilo “sečíst”. Formulář i proces jinak fungoval docela hezky a je vidět, že na tom UI/UX tým odvedl kus dobré práce. Jedna UX nepříjemnost mě ale potkala u 1. kroku - při výběru typu dokumentu. Jako cizinci (SK) mi nebylo jasné, jaký typ dokumentu tam mám vybrat. Nakonec jsem metodou pokus-omyl zjistil, že cestovní pas ani občanský průkaz tam zadávat nemůžu (to předpokládám mohou pouze občané ČR). Musel jsem vybrat dokument vydaný cizincům, kde to již akceptuje číslo průkazu přechodného/trvalého pobytu.

Jak plyne i z tohoto vyjádření, společnost OKsystem vyvíjí samotnou aplikaci a infrastrukturu zajišťuje společnost SPCSS (Státní pokladna Centrum sdílených služeb).

Taková skladba “realizačního týmu” vždy vyžaduje velmi zkušené lidi na obou stranách, kteří spolu umí komunikovat o řešení i o očekávané zátěži. Ideálně, když jsou na obou stranách, jak vývojáři a architekti, tak zkušený správci serverů a databázových řešení. Minimálně aby měli dostatečné odborné přesahy a chtěli, uměli hledat a vést odborný dialog nad nejslabšími místy daného řešení a možnostmi jejich eliminování.

Většinou takové “chování a jednání” nemá ani aplikační vývojář, ani správce serverů, ani tester, ani analytik, ani žádný IT manažér - musí tam být uprostřed někdo se silným multi-skillem a s citem pro vnímání a predikci reálného provozu i možných negativních dopadů některých zvolených řešení. Abych dal konkrétnější příklad ke vztahu k projektu Sčítání - musí to být někdo se schopností vidět formulářový prvek na zadání adresy a upozornit např. na chybějící debounce (co bude přetěžovat prohlížeč ale i backend a databázi), ale zároveň zkontrolovat např. existenci správných databázových indexů, nebo zkontrolovat, že je zvolené vhodné řešení pro samotné textové vyhledávání.

Prostě někdo, komu dochází co se děje od samotné akce v prohlížeči až po nastavení databáze či zátěž HW a zároveň si to umí vynásobit počtem současných uživatelů a riziky spojenými se souběhem zápisů/čtení/zámků, atp. Někdo, kdo si zároveň umí spočítat datové toky typických požadavků mezi interními technologiemi a definovat, kde je jednoduchou matematikou zátěžový strop aktuálního řešení. Někdo, kdo si dokáže při zátěžovým testování spojit chování uživatele v UI aplikace s grafy detailních HW/SW metrik, chování jednotlivých technologií "po cestě" a extrapolací předvídat zátěžový strop, či lokalizovat potenciálně riziková místa. Někdo, kdo za svojí praxi spoustu takových řešení i sám vyvinul, odpovídal i za jejich provoz, má silně vyvinutou intuici a zná i oblíbené vývojářské "zkratky" a obvyklé nedomyšlenosti. To jsou obvykle komplexní super-multi-skill IT role, které v IT firmách hodně chybí. Realita je taková, že "systém" očekává, že tu potřebu pokryje 5-10 úzce profilovaných IT rolí, ale ne - nepokryje. Implementaci ano, ale efektivní fine-tuning pro perfektní celkový výsledek, ne. Vídám to v malých IT firmách i ve velkých IT či ne-IT korporátech, které mají i svůj menší IT tým pro nějaké interní projekty.

Velmi často jsou taky hlavním dorozumívacím prostředkem této mezi-firemní kooperace stohy dokumentů s popisem řešení, specifikací, požadavků, atd. Rádo se soustředí na různé detaily a zátěžové specifikace nějakých “systémových jednotek”, ale rizika spojená se souběhem a workflow či chováním vysokého počtu uživatelů, se podceňují. Nebo o nich jako vývojáři neumíme dobře mluvit, jelikož je to sdílená odpovědnost táhnoucí se přes několik IT rolí a každý vnímá odpovědnost pouze za tu svojí část.

Obvykle to pak končí tak, že odpovědnost přesouvá jedna strana na druhou, a to např. tvrzeními a návrhy řešení, jako i v tomto případě - je potřeba navýšit výkon databáze (tedy škálovat vertikálně). To je ale obvykle chyba v architektonických, či vývojářských rozhodnutích a výkon zlepší pouze o desítky procent, v lepším případě o 3 - 4 násobky (když se použije extrémně předražený HW). Hlavní příčinu to ale nevyřeší, pouze problém lehce oddálí. To je koneckonců vidět i na případu aplikace Sčítání - výkon navýšili (určitě za nemalé náklady), formulář znovu spustili a za pár hodin to znovu kolabovalo, a i po celý dnešní den (neděli 28. 3. 2021) to není v kondici.

Doba cloudu přinesla jistá zjednodušení, ale nese sebou i jistá rizika. Já sám jsem pragmatik. Z overengineeringu jsem snad vyrostl a obvykle volím jednodušší a spolehlivé řešení u kterého znám velmi dobře jeho silné i slabé stránky, než za každou cenu robustní řešení, které se snaží být do budoucna super-rozšiřitelné. Moje zkušenost (a popisuje i moje první roky v IT) je spíš taková, že jako vývojáři často předvídáme jiný budoucí rozvoj vyvíjené aplikace než jsou pak skutečné business potřeby. Pak ve finále tvoříme větší množství kódu “pro lepší budoucnost”, který je ale do budoucna naopak hůře udržitelný a implementaci reálných potřeb spíše komplikuje, než usnadňuje. Když si nejsem jistý, doporučuji být raději přízemnější a držet se pravidla KISS (Keep It Simple Stupid).

Stejné úsilí jako být dobrým programátorem, jsem dlouhodobě dával tomu, být i dobrým architektem, analytikem, databázistou, správcem serverů, síťařem, bezpečákem, optimalizátorem procesů, kolegou a mediátorem mezi těmito světy a týmy. Kolem sebe mám lidi, kteří jsou jako jednotlivci lepší v jednotlivým oblastech, ale troufnu si říct, že díky multi-skillu jsem si vybudoval intuici, která mi umožňuje dělat obecně lepší vývojářská či architektonická rozhodnutí.

Tam, kde vnímám, že bychom obecně jako vývojáři jakéhokoliv SW měli dávat více úsilí než do “dokonalého kódu” (který stejně neexistuje) nebo prvo-plánovému budování “robustní architektury”, je budování citu pro vnímání a předvídání reálných stávajících i budoucích potřeb, rizik, chování uživatelů či provozních aspektů a jakákoliv architektonická či jiná rozhodnutí tomu přizpůsobovali. S tím souvisí i umění komunikace a schopnosti ptát se správných lidí na správné otázky.

Další cit, který bychom se měli učit pestovat, by mohl být o samotných rozumných architektonických rozhodnutích. Naučit se vidět a nepodcenit ty opravdu zásadní věci, ale zase naopak, neoverengineerovat věci, u kterých je to naprosto zbytečné a naopak to přinese komplikace v budoucnu, nebo neopodstatněné vysoké režijní náklady.

Dnešní cloudová doba, overengineeringu obrovsky nahrává - vývojáři si rádi hrají a na pár kliknutí si zprovozní i jinak provozně komplikovaná řešení. Architekty (kteří výše zmíněný cit moc vyvinutý nemají nebo nenesou dlouholetou zodpovědnost za svá rozhodnutí) to pak rychle svádí k tomu každé řešení vyskládat z mnoha zajímavých krabiček (služeb a technologií), a to často bez toho, aby jejich použití uměli řádně obhájit a podložit. Nebo, co je možná ještě horší, aby to po nich někdo vůbec chtěl. V UML diagramech a na prezentacích to vypadá sexy a tváří se robustně. Někteří z nich působiště často a rychle mění a vůbec tak nemají zpětnou vazbu na dopady vlastních rozhodnutí. Když pak řešení nezvládá očekávanou zátěž či se objeví jiné problémy, obvykle nikdo neumí za pár vteřin přesně lokalizovat příčinu a často nemají ani ponětí o nastaveních a provozních charakteristikách použitých technologií a odpovědnost přehazují na poskytovatele/správce, či rychle naklikávají vyšší parametry služby a měsíční náklady rostou do nesmyslných částek. O to více si vážím lidi a firem, které ke “klaudizací” přistupují s citem, odborným podložením jednotlivých rozhodnutí a pořád mají v hlavě to, že jsou za provoz odpovědní oni a nikoliv poskytovatel cloudu.

Tuto kapitolu navrhuji uzavřít obdobou citátu Petra Druckera:

Sepsání tohoto článku mě přivedlo k několika zbožným přáním:

1. Aby IT týmy ve státní správě usilovali o dlouhodobou systematizaci a jednou z aktivit by mohla být implementace perfektně odladěných a zdokumentovaných sdílených funkcionalit (technicky mikroslužeb), které jsou masivně používané ve velké části různých systémů. Především se jedná o funkcionality, které jinak každý IT systém implementuje po svém a často jsou achillovou patou celého řešení. Buď nemají aktuální či správná data, nebo trpí výkonnostními problémy. Dívat se na státní data a státní datové potřeby hodně zezhora, vnímat v nich souvislosti a modelovat systémy podle toho. Vedle projektů jako https://opendata.gov.cz/ data nejenom poskytovat (obvykle formou statických souborů), ale ideálně poskytovat i funkční a vysoce výkonné a odolné služby pro efektivní práci s těmi nejvíce používanými otevřenými daty ve státních systémech. Přináší to zefektivnění vývoje budoucích IT systémů, možnost dohledu a vnímání důležitosti jednotlivých typů dat (entit), míru jejich užívání jednotlivými systémy, atp. Pochopitelně to ale klade vysoké nároky na dostupnost a prevenci selhání takových služeb, aby nedošlo kaskádou k ještě větším škodám.

2. Aby se státní správě dařilo tvořit dobré podmínky a zdravé podnebí pro výběrová řízení, která osloví a zaujmou více potenciálních dodavatelů. Vím, že práce pro státní správu je o dost náročnější než pro soukromé společnosti a málokomu se to chce za stávajících podmínek podstupovat (včetně nás). O to více si přeju, aby se to kompetentním dařilo zlepšovat.

3. Aby IT firmy, které dodávají státní zákazky, dodávali opravdu kvalitní a domyšlená řešení odpovídající ceně. Aby dodávali řešení, která zlepšují mínění o státním IT. Aby když zklamali veřejnost s prvním projektem, tak měly hrdost a nedopustili, že se to bude opakovat i u dalšího projektu. Na druhou stranu ale musím přiznat a uznat, že spuštění velkých celostátních projektů musí fungovat perfektně vždy na první pokus a je velmi obtížné v rámci testování simulovat reálný provoz. Je to nelehký úkol, ale s dostatečným budgetem, časem a týmem profesionálů, by měl být splnitelný. Vůbec ale nepochybuji o tom, a plyne to i z vyjádření, že tomu věnují nemalé úsilí.

4. Aby někdo kompetentní zvážil možnost, zda ve finalizaci projektů podobného rozsahu (kdy je možné uživatelsky otestovat a navnímat hlavní funkčnost projektu za desítky minut) neoslovit nějaký další nestranný subjekt, který by dostal přístup na předprodukční prostředí a v průběhu pár dní by dokázal sepsat a odprezentovat potenciálně problémová místa aplikace. A zároveň by dokázal formulovat otázky a vést osobní diskuzi týkající se způsobu přípravy na očekávanou zátěž u jednotlivých, potenciálně rizikových funkcionalit. Cíl by byl jasný - externě, nestranně a velmi efektivně vypomoci primárním dodavatelům s problematikou zátěže. Když to dělají pouze týmy, které to i vyvíjejí, často nemají dostatek prostoru, energie a odstupu na to, aby byl výsledek 100%. Nepochybuji, že se najde spousta IT firem na našem trhu, včetně nás, které by to rádi udělali a to za minimální náklady. Pochopitelně by pak v případě problémů měli nést spolu-odpovědnost.

5. Aby měli IT firmy pro státní projekty povinnost v podobných selháních sepsat a veřejně publikovat alespoň 3-5 stránkovou post-mortem zprávu s technickým popisem problému i přijatými změnami a opatřeními. Hlavní cíl je ten, aby si z toho mohli vzít jiní IT pracovníci ponaučení - obzvláště ti, kteří navrhují, vyvíjí a provozují hodně zatěžované systémy pro občany.

6. Aby pracovníci v IT obecně vnímali naše řemeslo jako nástroj, kterým můžeme a máme pomáhat společnosti, digitalizaci procesů a celkově zpříjemňování života. Aby prohlubovali svojí odbornost, ale zároveň aby si uvědomovali potřebu přesahů do dalších souvisejících oblastí a mohli tak dělat lepší rozhodnutí a lépe se dorozumívat. Aby v práci vyvažovali fun-factor a neustálou touhu po nových technologiích s reálným užitkem a hodnotou jejich práce. Aby vnímali a přijali společnou sdílenou odpovědnost za výsledný produkt a nehleděli pouze na svojí část skládačky.

7. Aby si IT firmy uvědomovali potřebu výše zmíněné super-multi-skill role pro fine-tuning projektů a vytvářeli prostor pro její zrod a zapojení do (alespoň finální fáze) projektů. IT senioři mají obvykle další kariérní schod směrem k manažmentu, nebo dalšímu prohlubování své odbornosti. Bylo by fajn, kdyby si část z nich vybrala i cestu, být tím zkušeným multi-skillem, který perfektně rozumí webovým aplikacím a jejich obvyklým provozním nedostatkům a problémům v oblasti FE i BE. Ty jsou často zcela nezávislé na používaných programovacích jazycích a opakují se pořád dokola. Dobře se orientovat v problematice FE a rozumět tomu, co se děje u aplikace v prohlížeči a jak/kdy/proč komunikuje se serverem. Samozřejmě taky znát obvyklé přístupové patterny v oblasti BE a jejich silné a slabé stránky – různé formy databází, cache, procesů na pozadí, front, zabezpečení, komunikačních protokolů, atd. Být prostě někým, kdo není zatížený implementačními detaily, ale má dlouhou praxi z mnoha projektů a dokáže předvídat a dohlédnout na to, že dodaná webová aplikace funguje skvěle po všech stránkách. Takové zužitkování 10+ leté IT praxe z mnoha realizovaných projektů, vnímám jako jednu z nejpřínosnějších možných rolí ve vývoji IT projektů.

8. Aby média, které nejvíce ovlivňují veřejné mínění a svým způsobem i náladu společnosti, všeobecně hledaly cesty jak šířit dobro a dobrou náladu ve společnosti. Vážím si objektivity a práce všech poctivých novinářů, obzvláště těch investigativních - je potřeba poukazovat na hříchy a slabá místa “systému”, ale někdo by měl z toho plynoucí negativitu vyvažovat. Jinak má celá společnost pocit, že je všechno kolem nás špatně a ono to přitom není ve všem pravda. Ve spojení i se sociálními sítěmi a šířením dezinformací pak spousta lidí ztrácí naději, že se to zlepší.

9. Aby lidi spoustu věcí nebrali tak vážně, měli zdravý rozum, nevěřili žádným extrémním názorům (pravda je obvykle beztak někde uprostřed), hledali svůj osobní vnitřní pokoj, šířili dobrou náladu ve svém nejbližším okolí a neměli potřebu se negativně vyjadřovat ke všemu, co někdo napíše na internetu :)

Nakonec jsem v článku zabruslil do oblastí, do kterých jsem původně vůbec nechtěl. Věřím ale, že si z toho alespoň část čtenářů něco odnese a promítne to v něco dobré ve své práci. Pokud s mými pohledy na věc někdo souhlasí či nesouhlasí, klidně ať se podělí o svůj pohled či o své zkušenosti v diskuzi.

Redakci CNN Prima NEWS a redaktorovi p. Kolinovi děkuji za možnost se k projektu Sčítání vyjádřit. I když to v mém případě nemělo takovou hodnotu, jakou bych si přál, všeobecně považuji za přínosné, aby se k IT problematice ve státní správě vyjadřovali i kolegové ze soukromého sektoru. My bychom ale neměli tolik kritizovat, ale pomáhat hledat cesty, jak situaci zlepšit.

Na závěr chci ještě poděkovat Michalu Bláhovi, který vytrvale svými, řeknu až dobročinnými aktivitami a projektem HlídačStátu, dlouhodobě usiluje o zlepšení situace u státních IT i ne-IT zakázek. Myslím, že je to osobnost ze soukromého sektoru, která toho pro zlepšení situace kolem IT ve státní správě, dělá nejvíc. Je to běh na dlouhou trať, ale už to nosí ovoce a o to víc má za to můj obdiv a respekt. Díky!

Autor: Ján Regeš, vedoucí vývoje a infrastruktury, SiteOne, s.r.o.