Přejít k navigační liště

Zdroják » Různé » Provozujeme internetové aplikace bezpečně a dlouhodobě udržitelně

Provozujeme internetové aplikace bezpečně a dlouhodobě udržitelně

Články Různé

Vyvinutím a spuštěním internetové služby práce nekončí, ani zdaleka. Kromě nezbytných úprav a rozvoje jsou s vlastnictvím a provozováním takové služby spojené další náklady, práce a zodpovědnost. V článku nabízíme takový „checklist“ dlouhodobě udržitelného a bezpečného provozování internetových služeb.

V praxi se znovu a znovu setkáváme se zákazníky, kteří nechápou dvě hlavní věci nezbytné k provozování internetových aplikací bezpečně a dlouhodobě udržitelně:

  • vyvarování se vendor locku, a to jak u sw, tak případně u hw
  • že smlouvy, smluvní garance a pokuty nic neřeší (když přijdu o data teď, nezajímá mě až tak moc, jestli vysoudím náhradu škody za 3 roky)

Několik našich klientů např. poslalo svůj web do pekel tím, že si koupili web s líbivým CMS od nějaké české firmy a neuvědomili si, jak je ta firma za pár let začne, třeba i neúmyslně a nechtěně, omezovat a jak bude případně pracné se této závislosti zbavit a migrovat na jiné řešení.

Je dobré si proto uvědomit některé základní principy, kterými je třeba se řídit, pokud chceme, aby naše webová prezentace či aplikace byla dlouhodobě funkční, co nejvíc dostupná a bezpečně provozovaná.

Software a data

Právní vztah ke zdrojovým kódům aplikace

Licence, pod kterou vám autor umožní dílo užívat, by měla zejména umožňovat zásahy do díla vámi nebo jinou stranou, a také by měla umožňovat dílo šířit dále. Mnoho uzavřených licencí např. neumožňuje vytvořit více než dvě kopie – hlavní provozní a zálohu.Taková licence je příliš svazující.

Obecně se doporučuje přijmout dílo pod licencí GPL, BSD, MIT nebo některými z licencí Creative Commons (BY nebo BY-SA).

Umístění zdrojových kódů aplikace

Zdrojové kódy byste měli mít k dispozici v jakýkoliv okamžik. Bez ohledu na to, zda máte zdrojové kódy na svém serveru, na githubu nebo na serveru autora aplikace, měli byste mít vlastní zálohu (včetně historie).

Dostupnost vývojářů pro danou platformu

Ověřte si, že vždy dokážete sehnat vývojáře, který se orientuje v platformě, na které je váš systém postaven. Ověřte to zadáním reálné zakázky malého rozsahu, kterou zadáte jiné společnosti, než kdo je autorem.

Zálohování

Mějte vždy alespoň dvě zálohy dat svého systému. Pokud to okolnosti umožňují, zálohujte nejen uživatelské soubory a databáze, ale i celou aplikaci včetně logů a celý server (servery) včetně logů.

Zálohování databáze provádějte z repliky, minimalizujete tím výpadek (downtime) a zrychlíte samotné zálohování. Sekundární zálohu dělejte z primární zálohy; pokud je primární záloha vytvářena metodou push, sekundární dělejte metodou pull. Přístup k sekundární záloze by měla mít  jiná osoba, než kdo má přístup k primární záloze.

Zálohujte tak často, jak je to potřeba. Pokud máte málo dat, která jsou ale velmi variabilní, zálohujte třeba každou hodinu.

Plán pro případ katastrofy

Napište si plán disaster recovery. Naplánujte výpadek služby a zkuste disaster recovery podle tohoto plánu provést.

Počítejte s tím, že obnova dat ze záloh trvá dlouho. Možná zjistíte, že budete potřebovat do infrastruktury zahrnout hot-standby servery, do kterých pak jen dohrajete poslední změny.

Zkuste provést disaster recovery v neděli, ve svátek, na Silvestra nebo o Velikonocích.

Hardware a lidé

Výkon a zátěž

Používejte pro své webové služby proxy servery a balancery. Umožní vám to rychleji reagovat na nenadálé požadavky. DNS failover trvá o řád déle.

Dohled

Monitorujte chod serverů ze dvou nezávislých míst. Kromě vlastního stavu běží/neběží sbírejte i performance data, umožní vám to minimalizovat náklady na infrastrukturu, nebo maximalizovat propustnost

Veďte si přehled problémů, které se s vaším systémem řešily (issue track). Můžete-li, dejte možnost vstupovat do tohoto trackeru vašim klientům.

How To…

Napište si návod k instalaci celého vašeho systému. Návod v pravidelných intervalech testujte a aktualizujte.

Hardware

Vyhněte se investicím do hardware, pokud pro vlastní hardware nemáte opravdu dobré důvody. Většina poskytovatelů IT služeb zároveň hardware prodává a hlavní motivací je pro ně provize z prodeje. Správnou konfigurací lze často snížit náročnost na hardware, v mnohých případech o více než polovinu.

Když už z nějakého důvodu musíte koupit hardware, ověřte si reálnou objednávkou dostupnost náhradních dílů. Často se vyplatí mít více obyčejných serverů než jeden super dokonalý, na který ovšem nikdo nemá náhradní díly skladem.

Příklad za všechny: v jedné firmě koupili server HP-Compaq za ranec peněz. Jelikož byl velmi drahý, byla investice počítaná na pět let. Po konci záruky odešel harddisk v poli. Tuzemské zastoupení bylo schopné dodat nový harddisk stejného typu za cca 10 000 CZK a v termínu 6 týdnů. Kdyby server byl obyčejný, jednak by bylo politicky možné ho po 2–3 letech vyměnit celý, a jednak by náhradní díl byl k dispozici do druhého dne.

Lidé

Důvěřujte lidem, kteří mají přístup do vašeho systému. Paranoidní přístupové systémy jsou extrémně drahé. Nemůžete-li z nějakého důvodu lidem důvěřovat, vyměňte je. 

Ideální stav je lidem umožnit prakticky vše, aby je omezení přístupu nebrzdilo v práci, avšak zároveň užívání přístupů logovat, aby nebylo obtížné případného pachatele škody dohledat. 

Pokud někomu nedůvěřujete, musíte mu sebrat všechny přístupy do systému a naráz. Často jich bývá mnoho a na různých místech. Je dobré mít aktuální seznam k dispozici, případně mít skript, který to řeší.

Logy

Při sběru logů kombinujte centrální a lokální ukládání. Centrální ukládání umožňuje rychlejší analýzu, lokální zajišťuje uložení dat i v případě potíží se sítí a pod.

Horizontální škálování

Naučte se rozumět horizontálnímu škálování a využívat jej. Údržba malého serveru vždy zabere méně času než údržba velkého serveru. Můžete také škálovat podle přihlášených uživatelů. Budete-li mít výpadek jednoho serveru, je velký rozdíl, jestli vám budou telefonovat všichni klienti, nebo jen každý desátý. Stejně tak v případě, že dojde k poškození souborového systému – je velký rozdíl, jestli oprava proběhne za 10 minut nebo za 100 minut. Navíc můžete (díky proxy) uživateli poslat přátelskou chybovou hlášku, ideálně s odhadem, za jak dlouho se má pokusit o přístup znovu.

Shrnutí

V článku jsme si představili některé základní body, které by měl mít každý provozovatel internetové služby rozmyšlené a podchycené. Zamyslete se nad tím, jestli vaše služba nemá někde slabé místo – především zda má funkční zálohování a disaster recovery scénář, které pomohou vyřešit většinu problémů. Je samosebou důležité katastrofám předcházet, ale spoléhat se na to, že se jim podaří předejít vždy, je čirá bláhovost.

Autor vám přeje, abyste ty katastrofické scénáře nemuseli nikdy použít!

Komentáře

Subscribe
Upozornit na
guest
22 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Ladislav Toral

Nerad bych se někoho dotknul, vím, že jsme na linuxovém serveru a tady je kacířstvím hlásat něco jiného než open source, ale vydávat to za jedinou správnou cestu je demagogie.
Spoustě zákazníků vyhovuje zákaznické řešení u stabilní firmy třeba právě proto, že je třeba systém uživatelsky přívětivější, že dokáže víc, že se o své zákazníky postarají lépe – právě proto, že za to všechno dostane někdo zaplaceno.
Kupodivu nepotřebuje zákazník každého půl roku jiného bastlíře, mnohem důležitější je pro ně spolehlivé zázemí.

Tomáš Herceg

Přesně tak – u open source projektů je daleko větší pravděpodobnost, že se přestanou vyvíjet (stačí, když na to hlavní protagonista přestane mít čas), a pokud to není projekt z TOP 10, málokdy je komunita tak silná, že v jeho vývoji pokračuje.

Čelo

To je prostě takový hippiesácký přístup.

František Kučera

1) do komunity počítej i sebe, resp. uživatele – je hloupost o té komunitě mluvit jako o někom třetím, kdo na tebe ideálně má pracovat zadarmo a posluhovat ti – komunita jsme my všichni, každý se může zapojit.

2) Pravděpodobnost, že se na to původní autor vykašle je jak u uzavřeného, tak u svobodného softwaru přibližně stejná. V čem je ale rozdíl je, co se stane potom – v případě nesvobodného softwaru zmizí ten program někde v černé díře, autor si ho vezme do hrobu. V případě svobodného softwaru a programu, o který je zájem*, se vždycky najde pokračovatel.

*) snad se shodneme na tom, že je nesmyslné vyvíjet software, o který zájem není, nebo o který má zájem jen pár subjektů a kde náklady na uživatele/zákazníka jsou enormní.

paja

Taky mě to překvapilo, že jediná správná cesta je open source nebo mít přístup ke zdrojovým kódům aplikace.

Je mi jasné, že pro autora článku jako správce serveru je lepší mít zdrojové kódy a možnost si aplikaci sám upravit nebo sehnat někoho jiného, kdo to udělá.

To ale neni pohled většiny zákazníků. Přesně jak píšeš, spousta zákazníků raději sáhne po firemní aplikaci se smlouvou o údržbu.

František Kučera

Ad „To ale neni pohled většiny zákazníků.“

Dostupné zdrojáky ještě nikoho nezabily ;-)

Ad „raději sáhne po firemní aplikaci se smlouvou o údržbu.“

To se přece nevylučuje – naopak – u svobodného softwaru je častější platit za služby (podpora, záruky), protože za licence se neplatí. Naopak u nesvobodného softwaru mají zákazníci často pocit, že když zaplatí za licenci, více už není třeba – jenže v tom je chyba – zaplacením licenčního poplatku nemají žádnou záruku, že program bude fungovat, jak očekávají, mají dokonce mnohem méně práv než uživatelé svobodného softwaru, kteří si ho stáhli zadarmo z Internetu.

sidik

Nemluvě o tom, že pokud jako firma dodáme řešení, tak vážně nejsme zvědavi na nějakého šťourala, který začne hrabat do kódu a aplikaci odstřelí. Klient totiž neřekne „neměl ses v tom hrabat“ ale „ta vaše aplikace je rozbitá, opravte to nebo odstoupíme od smlouvy“.

Pokud chce klient systém spravovat sám, tak není problém na to sepsat smlouvu a zaškolit jejich programátora. Ale dávat přístup ke zdrojákům jen tak, to je nesmysl. A platí to i pro open source. Zásadně nedávat klientovi přístup do míst, kam ho nepotřebuje.

ondra.novacisko.cz

Zdroják klientovi dám, ale pokud chce úpravu, tak pracuji se svou kopií a ne s jeho. Pokud si tam nějaké úpravy udělal a chce po mě nějakou další úpravu, pak je třeba do toho zahrnout i čas nutný na analyzu již upraveného kódu a patřičnou diskuzi na téma, jak požadovaná úprava je kompatibilní s jejich úpravou. To si samozřejmě započítám do ceny.

Mennion

Jo jo, tenhle přístup se mi též velice líbí.

Dokonce to někdy dojde tak daleko, že klietni si sami implementují úpravu, kterou ale nikdo jiný už nechce = spokojeně využívají svojí fičurku + zároveň dostávají dál „globální“ aktualizace.

Josef Liška

Ano, toto je naprosto logické a správné řešení a klient to pochopí, pokud není tupec.

Navíc, pokud je aplikace kvalitní, má mít vysoké pokrytí testy, takže pokud udělá změny třetí strana, můžete spustit testy a pokud nevyjdou, je jasné, že je něco špatně a někdo (jiný než vy) odvedl špatnou práci.

pexxi_sk

Podla mna je mylne rozdelovat projekty na ‚open-source‘ a ‚stabilne firemne‘. A predovsetkym zrovnavat ‚open-source‘ = ‚zadarmo‘.

Velmi casto su ‚stabilne firemne‘ produkty zalozene na open-source rieseni, pricom firma k nemu poskytuje plateny support/rozsirenia a stara sa o svojich zakaznikov.

Spokojny klient mnohokrat ani netusi (a zazil som to uz viackrat), ze jeho web bezi na ‚nejakom open-source‘ a v klude si masti ego, ze open-source je zlo a ‚on to ma od profi-firmy‘ (v suvislosti s tym, obcas dochadza aj k porusovaniu OS licencie dodavatelom).

Dalsou moznostou je, ze open-source projekt zadarmo ma svoju enterprise odnoz, ktora je, povedzme, tiez open-source, avsak pod nejakou restriktivnejsou licenciou, s podporou, rozsirenymi funkciami, pristupom do zakaznickej sekcie na webe, etc…

Cize, ako tu uz bolo spomenute – ak sa na to clovek pozrie ako na sluzbu, resp. pridanu hodnotu a zahodi tu paranoiu, ze kazdy klient mu chce ukradnut zdrojove kody ;-), da sa krasne s open-source pracovat, prispievat do komunity a zaroven zarabat.

ubx

– zdrojove kody – predpokladam, ze clanok pojednava o aplikaciach „na mieru“, nie o seriovkach typu uctovnictvo a podobne – ci uz ide o „lokalne“ aplikacie s hrubym klientom alebo weboviny, lisi sa pristup podla velkosti firmy (hrubo povedane). mala firma je rada, ze ma aplikaciu za rozumne peniaze. ale vsetci nasi velki zakaznici zasadne ziadaju aj kompletne zdrojaky a dokumentaciu, aby bolo mozne v pripade problemov s nami odovzdat udrzbu aplikacie dakomu dalsiemu. a naopak aj my sme preberali viacero bankovin s komplet zdrojakmi. pravne formulacie v zmluvach som nevidel, ale v tomto duchu to zjavne muselo byt koncipovane.
– HW – tu by som bol trocha opatrnejsi – my sme napriklad museli svojho casu zrusit prave lacne servery (ok, nadpriemerne vykonne), kde za porovnatelne bubaky ako stala znacka, bol stale problem udrzat ich v chode – co s tym, ze som do hodiny zohnal nahradu za pokazenu RAM, ked nova zasa blbla? a naozaj to bola RAMka, nie board alebo daco ine. Takze ked ide o firmu otec & syn & 10MB dat, tak samozrejme skladacka, ale pokial ide o vacsiu firmu s desiatkami serverov, tak jednoznacne znacka a zaplateny onsite servis s predlzenymi zarukami. kazda sranda daco stoji, ale ked vrazim do aplikacie par milionov a data maju hodnotu este vacsiu, tak predsa nemozem skrblit na serveroch.

František Kučera

Ad „ale vsetci nasi velki zakaznici zasadne ziadaju aj kompletne zdrojaky a dokumentaciu, aby bolo mozne v pripade problemov s nami odovzdat udrzbu aplikacie dakomu dalsiemu.“

Přesně, větší zákazníci mají už trochu přehled a nenechají se balamutit – nejsou zvědaví na nějakého vykuka, který se těší, jak jim bude další roky prodávat aktualizace a namastí si na nich pořádně kapsu (první verzi jim dá klidně pod cenou – ale na dalších si přijde na své, protože má „monopol“ a jako jediný má přístup ke zdrojákům a právo je upravovat). Aneb nejsem tak bohatý, abych si mohl kupovat levné věci.

Josef Liška

Máte pravdu, se zdrojovými kódy
a máte pravdu s vlastním hardware v odůvodněných případech.

Znám ale mnoho projektů, které řeší vlastní servery a přitom by mohli laciněji a často trochu paradoxně i spolehlivěji běžet v cloudu.

Michal Zahradnicek

Licence, pod kterou vám autor umožní dílo užívat, by měla zejména umožňovat zásahy do díla vámi nebo jinou stranou, a také by měla umožňovat dílo šířit dále. Mnoho uzavřených licencí např. neumožňuje vytvořit více než dvě kopie – hlavní provozní a zálohu.

No ja osobne nemam problem s tym, ze ak si chce klient robit vlastne zasahy do diela, ktore mu dodam – potom samozrejme neberiem zodpovednost za jeho dalsiu funkcnost.

Ohladom sirenia diela uz je moj postoj jednoznacne iny. V tomto pripade totiz dielo je vlastne moje know-how a moje myslienkove pochody pretavene do zdrojovych kodov. Prave preto som proti tomu aby klient lubovolne siril dodane dielo(pokial samozrejme nie je dohodnute inak).

Ide o to ze ked si kupite mercedes, tak k nemu nedostanete kompletnu dokumentaciu vyrobnych postupov a cele know-how firmy s tym, ze ich mozete lubovolne sirit a pouzivat.

To iste je ked napr. spravim E-shop, alebo nejaky portal, tak klient skratka plati iba za ten dodany vyrobok. Skratka tak ako zaplati za auto, ktore moze lubovolne pouzivat, tak zaplati za software, ktory moze pouzivat. To ze sa da kopirovat a nasadit niekde inde je iba vlasnost softwaru ako takeho.

Tolko moj nazor na vec. Software je komodita ako kazda ina…

Rhinox

Jo, to s tim prirovnanim k autaku znam, a povazuju za peknou blbost. Srovnavas totiz nesrovnatelne! Zakaznik koupil tvoje zdrojaky, ne? Jednou ti uz za ty tve myslenkove pochody zaplatil, a ty zdrojaky (nebo aplikace) mu patri. Kdyz ty same zdrojaky chce jinej clovek, nemusis je vyvijet znova. Mezi vyvojem, a skopirovanim je sakra rozdil! Vyvoj muze byt drahej, a nekdo te za to musi zaplatit. Skopirovani hotoveho dila je prakticky bez nakladu…

A pokud jde o auta: koncovej zakaznik si nekupuje auto s vyrobnim postupem, aby jej mohl skopirovat a dat nekomu jinemu. Kdyz si ovsem firma A zaplati vyvoj auta (nebo nektere soucastky) u jine firmy B, firma A dostane pak od firmy B kompletni vyvojovou dokumentaci s popisem vyrobniho postupu, a muze si s ni delat co chce. Treba odevzdat kopii jine firme C, ktera to auto pro nej bude vyrabet. Takhle to je, a to rikam jako clovek ktery zrovna zakaznickej vyvoj automobilu a jejich komponentu dela. Pochopitelne, opet neco jineho je, kdyz si firma jenom objedna hotovou soucatku, tam si neplati za vyrobnej postup, nybrz za hotove kusy. V nich je ovsem ten vyvoj zohlednenej, ovsem jenom jednou! Proto jednotkova cena u zakazky 10 kusu je jina, nez jednotkova cena u zakazky na milion kusu…

Michal Zahradnicek

No mozno to prirovnanie s autom nie je uplne na mieste, ale zober si napriklad taku automobilku Morgan – ti robia len auta na zakazku. Ked u nich kupis auto, tak sa stanes jeho vlastnikom, ale urcite k nemu nedostanes vyrobne plany.

No ale v tvojom pripade si firma A dala vypracovat koncepciu tvorby auta a nie auto na mieru. Tak isto aj software si mozes dat vypracovat na to aby si ho dalej predaval(v tom pripade kupujes myslienkove postupy a know-how), alebo kupujes software za ucelom pouzivania – napr. chcem Eshop aby som predaval.

Ja som narazal viac-menej na mensie projekty. Pri velkych informacnych alebo bankovych systemoch je situacia samozrejme trochu ina a aj sa pohybuju v inych cenovych relaciach. Tam si klient to know-how aj zaplati.

P.S: Netvrdim o sebe ze som najvacsi genius a moje zdrojaky maju nevycislitelnu hodnotu. Len som vyjadril svoj nazor na vec.

Ad „Software je komodita ako kazda ina…“

Právě že není – software se dá nekonečněkrát kopírovat, aniž by utrpěl na kvalitě nebo to bylo drahé – v tom se zásadně liší od hmotných výrobků a většiny služeb.

U softwaru proto dává větší smysl založit obchodní model na službách – a tyto služby prodávat za férovou cenu, která pokryje náklady dodavatele – než účtovat za licence a pak stavět nějaké umělé bariéry proti kopírování.

Lweek

Článek sem ani nedočetl protože mi přijde ujetý. Webový software je licencovaný různě, často je licencovaný na doménu. To je přece logucké, když vývojář stráví měsíce vývoje aplikace, tak ji přece nebude rozdávat zadarmo, musí z něčeho žít. Zálohovat web můžete, můžete i zasahovat do kódu (čímž teda přijdete o záruku), ale nesmíte tu stejnou aplikaci použít na XY webech. To mi přijde fér a správné. V případě GPL software jde buďto o nadšenecký studentský projekty a nebo o něco za čím stojí komunita. Takový soft není špatný, ale je to často slepenec, který se stává ještě větším slepencem když ho vezme nějaký „vývojář“ a amatérsky upraví tak aby to nějak vyhovovalo požadavkům klienta. Což je víc než častý případ. Je na každým čemu bude důvěřovat, jestli otevřenosti a nebo zavřenosti. To samo o sobě nic neříká o kvalitě programu ani o tom jestli ten kdo s ním manipuluje se nás chystá natáhnout nebo ne. Obojí se dá, třeba tím že udělá práci za 2 hodiny, ale naúčtuje si třeba 6 tisíc. Takových se taky najde hromada.

Tenhle článek je fakt zmatený bulvární výkřik do tmy. Vemte vidle a jdeme upálit zlou čarodějnici.

František Kučera

Ad „Je na každým čemu bude důvěřovat, jestli otevřenosti a nebo zavřenosti. To samo o sobě nic neříká o kvalitě programu…“

Pak ale není důvod důvěřovat uzavřenému softwaru – i kdyby se člověk rozhodl, že bude „důvěřovat uzavřenému“, nic mu nebrání se na svobodný software dívat jako na uzavřený – to že jsou někde na Internetu dostupné zdrojáky ho vůbec nemusí trápit – ať se chová, jako by tam nebyly, když o ně nestojí.

Josef Liška

Dobrý večer, vážení kolegové,

těší mě, že jsem vzbudil jistou kontroverzi, ale všimněte si, že některým Vašim názorům neodporuji.

Například nemám nic proti tomu si raději najmout na vývoj SW firmu, než použít nějaký existující opensource balík. Pokud si však najmu firmu, chci abych s jejím produktem mohl zacházet jako s opensource a jsem si vědom rizik ale i výhod.

Dokonce to není ani nic proti tomu, že si k software mohu od firmy, která ho vyvinula koupit i SLA smlouvu na jeho údržbu.

Pokud si však koupím vendor lock, tak mě ani SLA smlouva nezachrání. Jde o to, aby firma šla změnit, pokud nevyhovuje. Nejde o to, aby se v kódu rýpalo deset různých firem/lidí.

Díky za pozornost.

Tomas

Mam dojem, ze vsichni mluvime o tom samem, jen z ruznych uhlu pohledu. Pokud mam relativne uzkoprofilovy software, ktery vyuziva par zakazniku nebo je dokonce na miru, tak je jednoznacne nutne z hlediska bezpecnosti mit k dispozici zdrojove kody. To ovsem neznamena, ze nemusim platit za licenci, za podporu, za dalsi vyvoj. Naopak. Je to jen bezpecnostni opatreni.
Pokud mam obavy o sve dusevni vlastnictvi (IP), resi se problem u velkych zakazek s pomoci takzvanych „escrow tapes“, ktere jsou ulozeny u „escrow agent“. Escrow tape obsahuje cely software vcetne prostredi nutneho k zkompilovani/ses­taveni aplikace. Escrow agent je specializovana nezavisla firma, ktera vyda escrow tape uzivateli v pripade, kdy dojde ke splneni predem definovanych podminek, napr. ukonceni podpory, vyvoje, nesplneni nasmlouvanych pozadavku nebo krach autora.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.