Mnoho českých e-shopů kdysi vznikalo na zelené louce, bez velkých analýz, bez metodiky, často ve spěchu, jen aby se už začalo prodávat.

E-shop pak rostl, měnily se potřeby a cíle, měnili se i vývojáři a časem vznikl různý spletenec, který sice nějak fungoval, ale nikdo pořádně nevěděl jak. Know-how vlastnil jeden člověk, který ve firmě již nepracuje. Dokumentace neexistuje.

Tohle je realita velkého množství českých e-shopů, které vznikly v kovbojských časech raného českého kapitalismu.

Není to žádná ostuda, ale spíše výsledek pragmatického přístupu podnikatele ušetřit a s minimem nákladů e-shop provozovat. Technický dluh je ovšem neuprosný a jednoho dne e-shop dožene. A pak vzniká problém.

Problém

Jak to tak bývá, téměř jakýkoli problém u e-shopu má dopad na obchodní výkon. A tady to nebylo jinak.

Web se velmi pomalu načítal, někdy se nenačetl vůbec. Zaznamenali jsme i výpadky uprostřed nákupu. Nešlo dokončit objednávku.

To jsou poměrně vážné problémy, které bylo nutné urgentně vyřešit.

Výchozí stav

Proti čemu jsme stáli?

Jak jsme zmínil v úvodu, šlo o vlastní e-shopové a serverové řešení, vyvíjené léta různými programátory, bez dokumentace, bez frameworku. K tomu na poměrně staré platformě bez aktualizací.

Muzikant.cz zkušebna

Analýza

Nepřítele je třeba dobře znát, než s ním začneme bojovat. Pustili jsme se do podrobného auditu všech součástí, které souvisí s e-shopem.

Co jsme analyzovali?

  • proveditelnost – nový e-shop nebo oprava?
  • serverová část (backend)
    • zdrojový kód e-shopu
    • audit nastavení a bezpečnosti serveru
    • zátěž serveru
    • datové toky
  • klientská část e-shopu (frontend)
    • kvalita kódu webu
    • rychlost načítání
    • technické seo
  • podpůrné nástroje
    • chatovací widget
    • rozhraní pro export/import dat (Heureka, Zboží apod.)
  • uživatelskou přívětivost
    • orientace na webu
    • vyhledávání produktů
    • nákupní proces
  • on-page a off-page faktory
  • audit analytických nástrojů – jak dobře měříme
  • bezpečnost
  • datové zdroje a datové toky

Analýza proveditelnosti v podstatě zahrnovala i část řešení. Museli jsme vytvořit přesné kopie obou strojů, provést zátěžový test a pak zkusit povýšit operační systémy na nejnovější verzi.

Analýza

Závěr analýzy

Vzhledem ke stáří e-shopu se dalo očekávat, že lze zlepšit téměř každou zkoumanou oblast. Rozhodli jsme se řešit problémy postupně dle priorit. První na řadě byla bezpečnost a rychlost načítání e-shopu.

Bezpečnost

Na e-shop se poměrně hodně útočí! Dokonce byly zaznamenány i nějaké průniky (masového charakteru), které se podařilo s úspěchem odstranit (data tedy zůstaly v bezpečí).

První poměrně složitý úkol, byla aktualizace e-shopového serveru na poslední Debian 9 (Stretch). Dalším oříškem byla záloha dat (replikace) na firemní server, kde rovněž byla poměrně stará verze linuxové distribuce Debian.

Okamžitá aktualizace na novější verzi nepřipadala v úvahu, takže jsme se museli poprat se stávajícím prostředím.

Revize odhalila několik desítek bezpečnostních průniků, které jsme většinou ručně museli vyřešit a následně zabezpečit. Když se zdálo, že nejhorší máme za sebou, objevili jsem zákeřný kód v síťovém segmentu, který si nakonec vynutil restart celého stroje. Bohužel k naší smůle stroj nenaběhl, což kolegovi málem způsobilo infarkt. Tím začala malá eskapáda se server housingem, který na naše požadavky vůbec nereagoval. Server tak naběhnul až v pondělí ráno. Migraci jsme samozřejmě prováděli o víkendu, kdy venku bylo krásných 40 stupňů a většina potenciálních zákazníků byla  po krk ve vodě.

Naše velké štěstí. Nicméně tímto „čištěním“ jsme strávili neuvěřitelné 2 dny práce!

Poučen, které z toho plyne je, že je potřeba předem získat autorizaci k server housingu a předem se ujistit, že reagují 24/7.

Rychlostní optimalizace

V průběhu analýzy si ukázalo, že je potřeba vyřešit nekompatibilitu zdrojového kódu e-shopu s novou verzí skriptovacího jazyka PHP. To se díky znalostem programátora povedlo vyřešit poměrně rychle.

Následoval další zátěžový test, který ukázal kritické problémy s výkonem kódu a přetěžováním databáze.

Museli jsme dát hlavy dohromady a najít řešení, které bude rychlé a efektivní, aniž bychom museli přepsat celý e-shop, což nebylo finančně ani časově schůdné. Vypomohli jsme si velmi rychlou databází Redis. Přepsali jsme kritické části kódu e-shopu tak, abychom nejkritičtější dotazy mohli přesměrovat právě do databáze Redis. Zjednodušeně řečeno jsme tím ukládali výsledky z databáze MySQL do Redis. Takže při každém dalším stejném dotazu jsme nemuseli obtěžovat databázi MySQL, ale rovnou jsme vrátili celý výsledek z Redisu. Tím jsme výrazně ulehčili databázi MySQL. Zrychlení bylo obrovské.

Zátěžový test nyní dopadl výrazně lépe, byť to nevyřešilo všechno problémy.

Replikační bolehlav

Kromě e-shopu běžel přímo ve firmě další server, který měl pravidelně zálohovat data z eshopu (replikace). Na tom není nic mimořádného, dokud se ty data nezálohují oběma směry.

Proč to tak bylo?

Z velmi pragmatického důvodu a tím je obsluha objednávek v reálném čase. K tomu časté výpadky internetu. E-shopový server totiž leží fyzicky úplně jinde než sídlo firmy. A pokud vypadnul internet, neměli zaměstnanci přístup k objednávkám.

Proto programátoři vymysleli obousměrnou synchronizaci dat mezi e-shopem a lokálním firemním serverem. K tomu vyvinuli specialní aplikaci skrze kterou mohli zaměstnanci vyřizovat objednávky z e-shopu. A ta samozřejmě četla data z lokálního firemního serveru (kvůli výpadkům internetu).

Aby návštěvník e-shopu rovněž viděl stav své objednávky, bylo rovněž nutné, poslat stav objednávky zpět do e-shopu.

Výhodou takového řešení je, že je rychlé, protože server leží fyzicky ve firmě. Nevýhodou je, že se databáze synchronizují oběma směry, což není ideální. Jakmile obousměrná synchronizace dat selže, nevíte, kde vlastně leží aktuální data.

Dále je nutné, aby obě databáze, jak e-shopová, tak firemní měly úplně stejné parametry, jinak se celý proces záloh zhroutí.

A my jsme samozřejmě potřebovali obě databáze aktualizovat na poslední stabilní verzi.

Za provozu jsme experimentovat nemohli,  takže nám nezbylo než zkusit proces nanečisto. Na kopii firemního stroje jsme zkusili aktualizaci starého Debianu na poslední verzi Debian 9. Zabralo nám to celý den. Výsledkem byl krásně funkční operační systém. Bohužel jen do té doby než kolega restartoval stroj, který již nenaběhnul. Takže celý den práce přišel vniveč.

Na řadu přišel plán B. Nainstalovali jsme zcela nový stroj, na který jsme přesunuli kritické data a nastavení z původního stroje. Nečekejte, že to zabralo výrazně méně času. Neexistovala žádná dokumentace, takže jenom zjistit, co se vlastně má přesunout, bylo na pár hodin práce. K tomu všemu se zjistilo, že nejde jen o data, ale i podpůrné aplikace a jejich nastavení. Například nutný webový server, mailový server, speciální ftp server pro data třetích stran, skriptovací podpora pro zpracování XML feedů atd. K tomu nekompatibilita starých a nových konfiguračních souborů..

Nakonec tedy nešlo jen o replikace. Zabralo nám to jeden pracovní den.

Zdá se, že se povedlo. V provozu se ale zjistilo, že nová databáze MariaDB, která je náhradou MySQL nemá takový výkon (při stejném nastavení), jako měla starší databáze MySQL.

Museli jsme tedy strávit další pracovní den pokusy nad komplexními SQL dotazy a zjišťovat, co se změnilo a jak dostat stejný výkon.

Závěr

Není vždy nutné utrácet stovky tisíc za nový e-shop. Někdy lze výrazně levněji vyřešit zásadní problémy. A teprve pak, když máte přesně popsány chyby stávajícího řešení, uvažovat o novém.

Pokud Vás naše řešení zaujalo, neváhejte nás kontaktovat.

Patrik Šíma
Patrik ŠímaMajitel Scheema Digital
T: +420 777 287 451
M: patrik@scheemadigital.com

Jsme tady, abychom vám pomohli!

Prostřednictvím nápadů, zkušeností a inovací