Správa a rozvoj webových aplikací a databází

Otázka 1

Náš callback platební brány vrací HTTP 500. Co uděláte jako první?

Nejprve zajistíme u současného poskytovatele přístup k chybovým logům Apache a PHP. Podle času požadavku a identifikátoru transakce dohledáme konkrétní chybu, místo v kódu a dostupný zásobník volání.

Test ze zadání zužuje hledání na zpracování nalezené objednávky. V logu a kódu ověříme, zda selhává zápis do databáze, změna stavu nebo některá navazující operace. Chybu potom zopakujeme na testovací kopii s vypnutým ostrým odesíláním a platbami. Výstupem bude konkrétní příčina, oprava a test, který zachytí její opakování.

Otázka 2

Brána opakuje notifikaci třikrát a pak ji zahodí. Jak zajistíte, že se informace o platbě neztratí?

Ověřenou notifikaci nejprve uložíme do trvalé fronty a bráně potvrdíme přijetí kódem HTTP 200. Teprve potom změníme stav objednávky a spustíme navazující úkony. V PHP v bloku try/catch zachytíme výjimky i další chyby typu Throwable, zaznamenáme je a zpracování zopakujeme. Chyba navazující operace nesmí zmařit potvrzení už přijaté zprávy.

Uložíme diagnosticky potřebný obsah požadavku, čas a identifikátor transakce. Parametr secret a nepotřebné osobní údaje do logu nepatří. Duplicity i souběžná doručení ošetříme transakčně, aby jedna platba nezpůsobila opakovanou změnu objednávky nebo odeslání výsledku.

Nezávislá kontrola bude podle evidence založených transakcí dotahovat jejich stav z API Comgate. Zachytí i platbu, jejíž notifikace vůbec nedorazila.

Z požadavku kapitoly 3.2 C na potvrzení každé notifikace navrhujeme jedinou výjimku: selhání trvalého uložení zprávy. V takovém případě vyvoláme upozornění a necháme bránu doručení opakovat. Potvrzení HTTP 200 by jinak ukončilo opakování, přestože zprávu nemáme bezpečně uloženou. Tuto výjimku s vámi vyjasníme před úpravou rozhraní; chyby při následném zpracování již uložené zprávy potvrzení příjmu neovlivní.

Podle kapitoly 4.2 porovnáme také evidenci brány s objednávkami, abychom zachytili i platby chybějící v místní evidenci. Předáme seznam rozdílů a provedených oprav, včetně kontroly, že se znovu nestrhla platba ani neodeslal výsledek.

Otázka 3

Endpoint se dostal ke zpracování objednávky i s neplatným parametrem „secret“. Co to pro nás znamená?

Je to bezpečnostní riziko s možným dopadem na stav objednávky a vydání výsledků. Nejprve prověříme pořadí kontrol: neplatný požadavek se nesmí dostat k žádné operaci, která mění objednávku nebo spouští její vyřízení.

Comgate používá secret jako sdílené heslo. Před zpracováním ověříme tento údaj, zdrojovou IP adresu podle dokumentace brány a příslušnost transakce ke správnému obchodníkovi. Serverovým dotazem přes HTTPS ověříme úspěšnou odpověď API (code=0) a shodu objednávky, částky, měny a testovacího režimu. Za zaplacenou uznáme pouze platbu ve stavu PAID; samotná autorizace nestačí.

V testovacím prostředí ověříme neplatné i opakované požadavky a souběh notifikací. Rozsah případného zneužití posoudíme podle logů, historie změn a evidence brány. Samotný rozdíl mezi objednávkou a platbou ještě nedokazuje útok.

Otázka 4

Popište, jak u nás bude vypadat nasazení změny, od zadání po produkci.

Zadání a kritéria převzetí zapíšeme do evidence úkolů. Změnu připravíme ve větvi Gitu v repozitáři pod vaším účtem, zkontrolujeme a otestujeme na odděleném stagingu. Testovací scénáře pokryjí dotčené funkce, včetně chybových stavů objednávek a plateb.

Po vašem schválení nasadíme označenou verzi v dohodnutém čase. Předem připravíme ověřenou zálohu, postup návratu a podmínky, při kterých jej spustíme. Po nasazení ověříme funkce a monitoring; záznam uvede verzi, autora, schválení a výsledky kontrol.

Před databázovou změnou ověříme postup návratu a způsob ochrany objednávek a plateb vzniklých po nasazení. Změnu nasadíme až po ověření postupu návratu i ochrany nových objednávek a plateb na testovací kopii. Přímé úpravy souborů přes FTP na produkci nepoužíváme.

Otázka 5

Jak řešíte zálohy a kdy jste naposledy testoval obnovu ze zálohy?

Zálohovat budeme databáze, soubory i konfiguraci potřebnou k obnově. Vedle provozní kopie bude šifrovaná záloha mimo server a jeho lokalitu, s oddělenými přístupy. S vámi stanovíme četnost, dobu uchování, přípustnou ztrátu dat a dobu obnovy; dohled bude hlásit i neúspěšnou zálohu.

Poslední doložený test obnovy jsme provedli 26. 8. 2026 u katalogové aplikace s databází SQLite. Po obnově jsme ověřili integritu databáze, přítomnost 106 produktů a shodu všech 488 odkazů na média s obnovenými soubory. Test prošel bez chyby. Obnovu databáze MariaDB jsme ověřili také 15. 4. 2026: importem zálohy deseti tabulek testovacího webu a následným spuštěním aplikace.

Při převzetí obnovíme vaše zálohy do zabezpečeného odděleného prostředí a změříme dobu obnovy. Ověříme vazby dat, objednávky a dostupnost výsledkových souborů, s oddělením ostrých plateb a odesílání zpráv. Protokol uvede použitou zálohu, datum, rozsah a výsledek. Test zopakujeme nejméně jednou ročně a po zásadní změně obnovovacího postupu.

Otázka 6

Co se stane, když budete týden nedostupný a náš objednávkový systém přestane fungovat?

Výpadek zachytí nepřetržitý monitoring a upozorní hlavního řešitele i technický zástup. Při nedostupnosti hlavního řešitele incident převezme zástupce ve stejné reakční době podle oddílu 5. Zahájí diagnostiku, navrhne postup obnovy a po zásahu ověří dostupnost služby i funkčnost objednávek.

Zakázku zajistí tříčlenný tým, který pokrývá vývoj a integrace, technickou správu, kybernetickou bezpečnost a monitoring. Členové týmu získají vlastní účty s oprávněními podle své role a přístup k potřebné dokumentaci, repozitáři a evidenci incidentů. Ověříme předání správy mezi hlavním řešitelem a zástupcem. Kontakty a rozdělení odpovědností uvedeme v předávacím protokolu; dokumentaci a správcovské přístupy budete mít průběžně i vy.

Otázka 7

Naše aplikace zpracovává údaje o zdravotním stavu pacientů. Jaká opatření to podle vás vyžaduje?

Údaje o zdravotním stavu patří do zvláštní kategorie podle čl. 9 GDPR. Před přístupem k nim uzavřeme zpracovatelskou smlouvu podle čl. 28 a NDA; zahrneme také subdodavatele, zálohy a zpracování výhradně v EU/EHP.

Budeme šifrovat přenos, uložené údaje i zálohy. Šifrovací klíče budeme spravovat odděleně. Přístupy budou jmenné, omezené podle role, chráněné vícefaktorovým ověřením a zaznamenávané. Prověříme doručování výsledků z laborator@kliste.cz, určíme dobu uchování jednotlivých druhů dat a postup výmazu. Připravíme technické podklady pro posouzení rizik a případné posouzení vlivu podle čl. 35.

Porušení zabezpečení vám jako zpracovatel oznámíme bez zbytečného odkladu. Dodáme podklady pro rozhodnutí správce o ohlášení úřadu podle čl. 33 a informování dotčených osob podle čl. 34. Odpovědnosti a postup sepíšeme předem.

Otázka 8

Jak zajistíte, že vaši pracovníci nemají zbytečný přístup k produkční databázi?

Vývoj a běžné testování poběží na syntetických nebo ověřeně anonymizovaných datech. Produkční databázi nebudeme kopírovat na notebooky vývojářů.

Přístup do produkce bude jmenný, s vícefaktorovým ověřením a pouze v rozsahu potřebném pro konkrétní úkol. Běžná diagnostika dostane oprávnění jen ke čtení; zásah do dat bude zvlášť schválený a zaznamenaný. Přístupy budeme pravidelně kontrolovat a při odchodu člověka ze zakázky zrušíme jeho přístupy a změníme servisní přihlašovací údaje, které znal.

Zkouška migrace s reálnými daty smí proběhnout jen ve zvlášť zabezpečeném prostředí v EU/EHP, po vašem schválení a s určenou dobou uchování. Pseudonymizovaná data budeme nadále chránit jako osobní údaje.

Otázka 9

Kdo bude po dobu spolupráce vlastnit doménu, hosting, repozitář a přístupy?

Domény, hosting, repozitář, kód a data budou od začátku pod vaší kontrolou. Domény budou vedené na vás a hosting na vaši smlouvu. Repozitář bude pod vaším účtem; nám přidělíte pouze pracovní oprávnění.

Budete mít vlastní správcovské přístupy a možnost naše oprávnění odebrat nebo přizvat dalšího dodavatele. Smlouva upraví práva k dodanému kódu tak, abyste jej mohli dál provozovat, měnit a předat nástupci. Použité knihovny a jejich licence budou uvedené v dokumentaci.

Otázka 10

Jak bude vypadat předání, pokud spolupráci ukončíme?

Aktuální kód s historií, konzistentní export databází a souborů, přístupy, přehled služeb a dokumentaci nasazení i obnovy předáme nejpozději do 5 pracovních dnů od doručení vaší písemné žádosti o předání. Tuto lhůtu i součinnost s novým dodavatelem zakotvíme ve smlouvě.

Připojíme seznam otevřených úkolů a známých závad. S nástupcem ověříme přístupy a převzetí provozu; výsledek zapíšeme do protokolu. Dokumentaci a repozitář budete mít k dispozici po celou dobu spolupráce.

Po převzetí odebereme naše přístupy a svěřená data vrátíme nebo odstraníme podle zpracovatelské smlouvy, včetně dohodnutého vyřazení záloh.

Otázka 11

Máme několik jazykových mutací, každou jako samostatný web s vlastní databází. Jak byste postupoval při jejich sjednocení?

Začneme porovnáním kódu, databázových struktur a chování kliste.cz, kliest.eu a zeckenhilfe.com. Sepíšeme rozdíly v objednávkách, platbách, zákaznících, administraci a výsledkových dokumentech. Vazby na protean.bio a analyza-dna.cz posoudíme samostatně.

Navrhujeme společnou PHP aplikaci a datovou základnu, jednu administraci a centrální správu překladů. Při prvním přechodu doporučujeme zachovat stávající domény i adresy. Sjednocení vnitřního systému samo o sobě nevyžaduje stěhování webů a zachování adres sníží počet souběžných změn.

Každou mutaci nejprve převedeme nanečisto. Po úspěšných kontrolách přepneme jednu mutaci a ověříme objednávky, platby i doručování výsledků. Teprve potom přejdeme k další. Zvlášť ošetříme rozpracované objednávky a notifikace k platbám založeným před přechodem.

Analýza určí konečný datový model, způsob přenosu změn, postup návratu a závaznou cenu i harmonogram etap. Pro každou etapu ověříme, jak při návratu ochráníme nové objednávky a platby. Úspěšná zkouška bude podmínkou ostrého přechodu.

Otázka 12

Při slučování databází se potkají objednávky se stejnými identifikátory a titíž zákazníci ve více databázích. Jak to vyřešíte?

Každému záznamu přiřadíme nový identifikátor a uchováme mapu zdrojové databáze, typu záznamu a původního ID. Podle ní převedeme vazby mezi zákazníkem, vyšetřovanou osobou, objednávkou, platbou a výsledkem. Původní čísla dokladů i identifikátory transakcí Comgate zůstanou dohledatelné.

Pravidla slučování zákazníků schválíme s vámi. Shodný e-mail označí kandidáta na duplicitu, sám však neprokazuje totožnost. Sporné záznamy ponecháme oddělené; zákazník, plátce a vyšetřovaná osoba se nesmějí automaticky sloučit do jedné identity.

Migrační skript půjde opakovaně spustit, aniž vytvoří další kopie záznamů. Ke stejnému okamžiku porovnáme počty záznamů, kontrolní součty významných polí, částky podle měn, vazby a přiřazení výsledků. Přemapovaná ID a schválené sloučení zákazníků zohledníme podle mapy změn. Stejné kontroly proběhnou při zkoušce i po přenosu posledních změn.

Během přechodu bude pro každou objednávku určen jediný systém, který smí měnit její stav. Přenos průběžných změn zahrne i opožděné platby; přepnutí a návrat ověříme předem. Dokud nesouhlasí data a neprojde kontrola objednávky od založení po výsledek, mutaci nepřepneme.

Otázka 13

Jak zachováte dohledatelnost webů ve vyhledávačích a funkčnost odkazů z tištěných materiálů?

Při prvním sjednocení doporučujeme zachovat stávající domény a adresy. Z map stránek, logů, Search Console a vašich tiskovin včetně QR kódů připravíme mapu původních a cílových adres. Změněné adresy přesměrujeme kódem 301 přímo na odpovídající obsah.

Jazykové vazby hreflang doplníme mezi odpovídající české, slovenské a anglické stránky včetně zpětných odkazů. Každá jazyková stránka bude mít vlastní správnou kanonickou adresu. Mapy stránek opravíme a aktualizujeme na platné cílové HTTPS adresy.

Před přepnutím ověříme staré odkazy, přesměrování a jejich cíle, přístupnost pro vyhledávače a to, že v produkci nezůstal příznak noindex. Po přechodu budeme v Search Console a logách sledovat indexaci, chyby 404 a návštěvnost. Domény a odkazy použité v tiskovinách zachováme dlouhodobě; změny pozic budeme porovnávat se stavem před migrací.