Guides - Hyvä
Mentenanță Magento: 3 teste pe care le poți face azi
- Alexandru-Manuel Carabus
Nu vrei încă un articol generic despre mentenanța Magento. Vrei să știi dacă magazinul tău are nevoie de intervenție chiar acum. Trei teste concrete pe care le rulezi din browser sau SSH, în 30 de minute, plus povestea Vitacom, cu TTFB de la 15,814ms la 12ms.
Din experiența noastră de onboarding, majoritatea magazinelor Magento pe care le preluăm rulează cu cel puțin un patch de securitate lipsă. Multe au un TTFB de peste trei secunde. O parte notabilă nu mai au un cron care să ruleze cum trebuie de luni de zile. Nu vorbim de "e loc de mai bine". Vorbim de magazine care pierd bani chiar în timp ce citești rândul ăsta.
Majoritatea articolelor despre mentenanță Magento îți recită aceeași listă: fă patch-urile, curăță baza de date, monitorizează. Adevărat și inutil în același timp. Pentru că nu răspunde la singura întrebare care contează pentru un merchant: magazinul meu are nevoie de mentenanță chiar acum sau pot să mai aștept trei luni?
Postul ăsta răspunde la asta. Trei teste concrete, treizeci de minute în total, din browser sau din SSH. Vineri seară știi exact unde stai și ce urmează.
Testul 1: TTFB (verifici dacă serverul răspunde uman)
TTFB (Time To First Byte) e primul semnal că motorul e sănătos sau blocat. Merchantul care nu are habar de infrastructură simte lentoarea sub forma unor sesiuni pierdute fără explicație în Analytics și a unei senzații vagi că "astăzi magazinul e greu".
Cum îl măsori:
- Deschide DevTools în Chrome (F12), tab Network
- Încarcă pagina de listing a categoriei cu cele mai multe produse
- Citește valoarea TTFB pentru documentul principal
Ce înseamnă cifrele:
- Sub 200ms, sănătos
- 200 la 800ms, există gâtuiri, dar nu e urgent
- Peste 1 secundă, problemă reală, pierzi conversii
- Peste 3 secunde, magazinul e în cădere liberă
Pentru o citire mai clară, rulează webpagetest.org de trei ori pe zi (dimineața, la prânz, seara). Media contează mai mult decât un singur snapshot, pentru că Magento poate arăta bine la 4 dimineața și se poate prăbuși la 11:00 când cronul și traficul real se ciocnesc.
Când am preluat Vitacom, TTFB era 15,814ms. Aproape treisprezece secunde numai pe server, înainte ca browserul să înceapă randarea. După un refactor complet pe Hyvä și un overhaul de DevOps, TTFB a coborât la 12ms. Cifră reală, verificabilă în studiul de caz Vitacom.
Testul 2: Nivelul patch-urilor de securitate
Adobe publică patch-uri de securitate Magento în fiecare trimestru. Sunt magazine în producție azi care rulează pe 2.4.4, out of support din 2023. Fiecare patch publicat este și un vector de atac publicat: lista CVE spune exact ce vulnerabilități rezolvă, deci în momentul în care patch-ul apare, orice magazin nepatch-uit devine țintă documentată. Instalarea ta Magento este vizibilă prin instrumente publice precum BuiltWith sau Wappalyzer, deci un atacator nu trebuie să ghicească care magazine rulează Magento. Dacă al tău e nepatch-uit, atacurile automate nu sunt o ipoteză. Sunt statistica.
Cum verifici:
- Logheăză-te în admin-ul Magento ca administrator.
- Deschide orice pagină din backend. Versiunea Magento este afișată în colțul din dreapta jos al footer-ului.
- Dacă ai acces SSH, `bin/magento --version` din rădăcina Magento îți dă același răspuns.
- Compară versiunea cu pagina oficială de release-uri Magento
Ce urmărești:
- Ești pe un minor version curent (2.4.7 sau mai nou)?
- Ai aplicate toate patch-urile de securitate ale acelui minor?
- Există artefacte de dev (Sample Data, developer mode, pagini de setup expuse) lăsate în producție?
Un bonus care nu costă nimic: rulează `bin/magento setup:db:status`. Dacă îți iese "Some modules are out of date" sau warning-uri de schema drift, tot ai un indiciu concret despre ce ar trebui să atingă următoarea sesiune de mentenanță.
Testul 3: Log-ul de cron (unde se ascunde datoria tehnică)
Cronul face aproximativ nouăzeci la sută din munca invizibilă a unui magazin Magento: reindexare, curățare cache, mail-uri tranzacționale, integrări, generare de PDF-uri de facturi. Dacă cronul se oprește, magazinul îți pare OK trei zile, apoi începe să se comporte ciudat și nimeni nu știe de ce.
Cum verifici:
- SSH pe server
- `tail -f var/log/cron.log`
- Sau, mai vizual, mergi la Stores > Configuration > Advanced > System > Cron
Semne că totul e OK:
- Log-ul crește cu intrări noi la fiecare minut
- Nu apar mesaje "job stuck" sau "missed schedule"
- Coada de consumers (`bin/magento queue:consumers:list`) e mișcată de un supervisor
Semne de alarmă:
- Ultima intrare în log e de acum două zile
- "Consumer XYZ has been running for 4 days", memory leak clasic
- Niciun log de cron, ceea ce înseamnă că crontab-ul de OS nu a fost niciodată configurat corect
Ce înseamnă mentenanța concret
Dacă ai picat la unul din cele trei teste, mentenanța reală (nu discursul de pe pagina de servicii) arată așa:
- Patching lunar: patch-urile de securitate aplicate în 5 zile de la anunț, testate pe staging, deployate în producție
- Housekeeping bază de date: curățare sales_order_grid, quote-uri abandonate mai vechi de 90 de zile, log-uri orfane
- Monitorizare cron și queues: alertă când un consumer e blocat mai mult de 10 minute, nu o dată pe trimestru
- DevOps continuu: kernel updates, reînnoire TLS, verificare backup (un backup netestat nu e backup)
- Audit trimestrial: cineva chiar se uită la Sentry, la New Relic, la ce a scăpat monitorizării zilnice
Prețurile pentru genul ăsta de muncă în piața românească variază între 500 și 4000 EUR pe lună, în funcție mai ales de cât de onestă e agenția cu facturarea. La LIQUIDLAB, suportul și dezvoltarea Hyvä se facturează la oră, cu SLA contractual (2h răspuns pentru critical, 4h pentru major) și ticketing în ClickUp. Nu e abonament fix pentru că nu suntem cutie neagră. Plătești orele reale lucrate și vezi exact ce s-a lucrat.
Povestea Vitacom
Vitacom.ro a venit la noi cu un magazin Magento 2 pe Luma, aproximativ 180 de module third-party stivuite peste ani, TTFB de 15,814ms și un PageSpeed score de 12. Nu era o relicvă abandonată. Era un magazin live, care lua comenzi în fiecare zi.
Ce am făcut, pe scurt:
- Refactor complet pe frontend Hyvä
- Curățare module: de la aproximativ 180 module la aproximativ 20 esențiale
- Redesign infrastructură: de la 64 CPU cores și 256GB RAM la 8 cores și 32GB RAM, o reducere de 8x pe hardware
- Rescrierea query-urilor GraphQL problematice
- Setup DevOps cu observability reală (Sentry, log-uri centralizate, alerting)
Rezultatul public, măsurabil:
- TTFB: 15,814ms la 12ms, o reducere de 99,92 la sută, aproximativ 1,300x mai rapid
- PageSpeed: de la 12 la 100
- Hardware: 8x mai mic
- Costuri infrastructură: proporțional în jos
Detaliile complete și metricile verificabile sunt în studiul de caz Vitacom. Nu rotunjim cifrele, nu le parafrazăm.
Ce faci săptămâna asta
Plan concret, un test pe zi:
- Marți: rulează Testul 1 (TTFB). Dacă e peste o secundă, marchează-l ca prioritate.
- Miercuri: rulează Testul 2 (versiunea Magento și patch level). Dacă ești sub 2.4.6, ai o problemă de securitate deschisă, nu o chestiune de planificare.
- Joi: rulează Testul 3 (cron log). Cinci minute pe SSH îți spun dacă rulează sau a murit în tăcere.
- Vineri: pune cele trei rezultate într-un singur document (Google Doc, Notion, un mesaj Slack către tine). Trei probleme? E destul pentru o conversație reală cu un partener tehnic.
Dacă vineri ai constatări pe care nu le poți interpreta, cel mai direct pas următor e analiza de cod și server: 999 EUR one-time, cu 30 de zile de suport incluse. Livrăm document scris cu constatări, prioritizare (Critical, Major, Minor) și plan concret de remediere. Nu vindem ore în plus, nu semnezi contract lunar obligatoriu. Vezi ce ai, apoi decizi ce repari și cu cine.
Stai de vorbă cu un dezvoltator senior Magento
Dacă vrei să discuți rezultatele testelor cu un dezvoltator senior Magento înainte să cheltui un euro pe remediere, rezervă o discuție de strategie gratuită. Treizeci de minute, fără presiune de vânzare, fără secvență automată de follow-up. Vii cu întrebările, pleci cu ghidaj clar despre ce urmează.