Supportból bizonyított megoldás: egy intenzív Columbia Games nap a checkouttól a digitális könyvtárig

A helyzet

A Columbia Games rendszerében a fejlesztési és supportfeladatok egy napon belül több rétegen futottak össze: vevői könyvtári jogosultságok, szállítási díjszabás, PayPal-fizetés, katalógusadatok, régi PDF-fájlok, admin konfigurációs kontextus, média-cache és levelezési egyeztetés. A külön e-mailthreadekben visszatérő kérdések közül sokat már érintett fejlesztés, másokat éppen teszteltünk, némelyikhez pedig még ügyféloldali döntés hiányzott. A cél nem az volt, hogy mindent 'késznek' mondjunk, hanem hogy minden állításhoz legyen visszakereshető technikai bizonyíték, és a csapat mindig tudja, mire várunk.

A megoldási út

A napot supportkérések leltározásával indítottuk, majd a legkockázatosabb eseteket a megfelelő rétegben ellenőriztük: GitHub PR és commit, Dockerben futó source, read-only PostgreSQL, fájlrendszer, Nginx-konfiguráció és valós HTTPS-végpont. A javításokat külön, tesztelhető egységekben kezeltük; az üzleti döntést igénylő elemekhez lépésről lépésre követhető tájékoztatást készítettünk. Az alábbi kilenc történet együtt mutatja, mennyi munka van a 'megjavítottuk' szó mögött.

1. A postaládából mérnöki feladatlista

A nap első problémája nem egy exception volt, hanem az információ szétszóródása. Ugyanabban az időszakban érkeztek retailer-szállítási kérdések, vásárlói jogosultsági panaszok, fizetési eltérések, PDF-es kérések, adminisztrációs hibajelzések és release-visszajelzések. Egy hosszú e-mailváltásban könnyű összekeverni a felhasználói elvárást a már kész fejlesztéssel, a nyitott hibát egy korábbi javítással vagy a tesztet a tényleges production eredménnyel. Ezért témakörönként rendszereztük az ügyeket: mi az üzleti kérdés, melyik kódrészhez és környezethez tartozik, mi ellenőrizhető most, mi igényel változtatást, és melyik választ melyik levelezési szálba kell visszaírni. Az állapotok nem puszta jelzők voltak: külön kezeltük a vizsgálat alatt álló, javított, productionön ellenőrzött és üzleti jóváhagyásra váró eseteket. A válaszlevelek jellemzően piszkozatban készültek el, nem állítottuk be őket elküldöttnek.

2. Production mint bizonyíték, nem mint kísérleti homokozó

Több ügyet közvetlenül az éles Columbia Games környezetében kellett diagnosztizálni. A terminálos vizsgálatoknál tudatosan elkülönítettük a Gitben szereplő forrást, a Docker-konténerben ténylegesen futó PHP-kódot, az adatbázis aktuális állapotát és a publikus HTTP-végpont eredményét. Hash-ellenőrzésekkel vizsgáltuk, hogy az admin- és API-fájlok megegyeznek-e a release-ben várt változattal. Az adatbázis-lekérdezéseknél read-only tranzakciót, időkorlátot és célzott szűréseket használtunk, mert egy diagnosztikai parancsnak nem szabad véletlenül módosítania ügyféladatot. A health check is tanulságos volt: a gyökér alatti /health 404-et adott, a rendszer tényleges /api/health útvonala viszont HTTP 200-at. Nem a hibásan megválasztott URL-ből vontunk le következtetést, hanem a valódi alkalmazásútvonalat ellenőriztük.

3. Retailer checkout: szabályok, nem varázskapcsolók

A retailer- és alapértelmezett konfiguráció közötti váltás első pillantásra egyszerű adminműveletnek látszott. Aztán előkerült az egyik legbosszantóbb felhasználói élmény: az admin a retailer konfigurációra váltott, másik oldalra navigált, majd visszatérve a fejlécben ismét a cg/default konfiguráció jelent meg. Ez nem kozmetikai hiba, hanem veszélyes kontextusvesztés: könnyű rossz szabálykészletben dolgozni. A kiválasztott konfiguráció megőrzését javítottuk; a módosítás a GitHub-előzményben külön commitként szerepel, a felületi működést pedig visszaellenőriztük. Ezzel párhuzamosan megvizsgáltuk a retailer shipping szabályokat, készítettünk adatbázis-mentést a célzott konfigurációs munka előtt, és szétválasztottuk a technikai lehetőséget az üzleti döntéstől. A minden retailer számára ingyenes szállítás nem magától értetődő alapbeállítás: a kívánt díjakat, országokat és kivételeket a megrendelőnek kell jóváhagynia. A kapcsolódó #351 feladat ezért nem kapott hamis 'kész' státuszt; a végső checkout UAT a konkrét tarifaszabályoktól függ.

4. PayPal, országkódok és a fizetési regressziók

A fizetési útvonalnál több különböző hiba hatott egymásra: a checkout által elvárt payment type, a régi adatok reprezentációja és a PayPalnak továbbított szállítási országkód. A célzott javításnál a támogatott országokat kanonikus ISO alpha-2 formára képeztük le, a hibás vagy nem támogatott értékeket pedig nem engedtük csendben továbbjutni. A legacy CAN alias kezelése közben arra is figyelni kellett, hogy ne sérüljön az alpha-2 országlista következetessége. A hotfix külön PR-ben készült, célzott regressziós ellenőrzésekkel és productionös QA-val. Az ilyen javítás nem akkor jó, ha egy korábbi tesztvásárlást átenged, hanem akkor, ha a rendes és a hibás bemenetre is kiszámítható választ ad, és közben a többi pénzforgalmi útvonal nem sérül.

5. Digitális könyvtár: a jogosultság, az adatbázis és a fájl három külön igazság

Egy megvásárolt PDF esetében nem elegendő, hogy az adatbázisban létezik egy termékkód; a vásárlónak megfelelő jogosultsággal és ténylegesen letölthető állománnyal is rendelkeznie kell. A HarnQuest 2026.3 ügyben két hiányzó digitális könyvtári tételt azonosítottunk. A javító műveletet előzetes ellenőrzés és konkrét terv után, védett tranzakcióban hajtottuk végre, majd visszaolvastuk, hogy a tételek valóban megjelentek a jogosult könyvtárában. Más esetekben a termék-SKU, a downloadable_filename mező, a fájlrendszerbeli útvonal és a fájlszignatúra egyezését vizsgáltuk; a PDF fejlécének és a Windowsos letöltések formátumának ellenőrzése jóval erősebb bizonyíték, mint egy sikeres HTTP-válasz önmagában. A Harn térképek, a Kaldor- és Melderyn-mintafájlok, valamint a letöltési útvonalak körül külön kellett választani a régi és az új tárolási helyeket. A kiadott PDF-eknél a licenc-lábléc és a watermark kérdését is célzottan auditáltuk: nem minden hasonló fájl ugyanazt a terméket vagy publikálási útvonalat jelenti.

6. Képek és /pix: célzott cache-frissítés globális takarítás helyett

A képtárolás és a böngészőcache is kapott önálló fejlesztést. Az admin felületen egy-egy kép cache-ének állapotát és frissítését kezelő funkció készült, amelyhez API-végpontok, jogosultsági ellenőrzések és regressziós tesztek kapcsolódnak. A trükkös rész a domainaliasok közötti egység volt: ugyanazt a képet a kanonikus és a www hoston keresztül is megfelelő cache-generációval kell kiszolgálni. Nginx-konfigurációt, rövid, ötpereces böngészőcache-szabályt, idempotens fejléckorrekciót és visszaállítási szempontokat is vizsgáltunk. A megoldás lényege az, hogy egyetlen hibás kép miatt ne kelljen a teljes médiaszolgáltatást megrázni. A kapcsolódó változtatások külön PR-ben kerültek a kiadási folyamatba, és nem álltunk meg annál, hogy az új admin gomb látszik.

7. PostgreSQL és jogosultságkezelés: ahol a teszt a javítás része

A kapcsolódó termékek importja PostgreSQL alatt paramétertípus-ütközésbe futott. A javításnak egyértelművé kellett tennie az INSERT paramétereinek típusát, de ennél fontosabb volt annak bizonyítása, hogy az import idempotens marad, a hozzáférés-szabályozás működik, és hiba esetén a tranzakció visszagörgethető. Ezért izolált adatbázisos regressziós teszt és CI-ellenőrzés is készült. A napi adminisztrátori QA-ban emellett az ügyfélmódosítás, a katalógus, az árkedvezmények és a konfigurációs jogosultságok kódját és productionös viselkedését is ellenőriztük. Egy kódfájl jelenléte önmagában még nem bizonyítja, hogy az összes szerepkör helyesen működik; a jogosultságot a konkrét művelet határán kell vizsgálni.

8. Számlázás, SMTP és az e-mail mint üzleti interfész

A support egy része nem klasszikus backend-bug volt. A legacy számlázás és a fizetési állapotok esetében összesítettük, hogy mely tranzakciók tekinthetők rendezettnek és melyek igényelnek utánkövetést, majd a megfelelő érintettnek előkészítettük a tényalapú tájékoztatást. Másik szálon az e-mailküldési környezet nyilvános DNS- és szolgáltatási jeleit vizsgáltuk: MX, SPF, DMARC és a ténylegesen ismert DKIM selectorok, valamint az SMTP korlátai külön kérdések. Nem kevertük össze az üzenet megírását, piszkozatba mentését, SMTP-átvételét és végső kézbesítését. A FortiGuard kategorizálási felülvizsgálatát is külön külső függőségként tartottuk számon: a review beküldése után a szolgáltatói válaszra várni kell, a jóváhagyást nem lehet kóddal 'kikényszeríteni'.

9. Release-fegyelem: mi kész, mi kint van, mire várunk?

A nap jelentős részét nem új funkciók írása, hanem korábbi fejlesztések éles visszaellenőrzése töltötte ki. A forráskód-hash, a konténerfájl, a read-only adatbázis-lekérdezés és a HTTP smoke négy különböző ellenőrzési réteg. A merge, a deploy, az alkalmazás elindulása és egy konkrét üzleti folyamat sikeres végigtesztelése szintén négy külön állapot. Az e-mailekhez ezért nem általános 'everything is fixed' választ írtunk, hanem ügyenként pontosan elmondtuk, mit javítottunk, mit ellenőriztünk, és mit kell még az ügyfélnek konfigurálnia vagy visszajeleznie. Ahol még hiányzik egy üzleti tarifa, külső visszaigazolás vagy reprodukálható teszteset, ott az ügyet nyitva hagytuk. A sok különálló beszélgetés végül egy kezelhető, bizonyítékokra épített supportlistává állt össze.

Mi lett belőle

A napi munka kézzelfogható eredményei közé tartozik a retailer konfiguráció kiválasztásának megőrzése, a PayPal szállítási országkód-javítás, a célzott kép-cache frissítés, a PostgreSQL kapcsolódótermék-import típuskezelésének és regressziós tesztjeinek javítása, valamint a hiányzó HarnQuest digitális jogosultságok ellenőrzött pótlása. Külön production QA-t végeztünk a letöltési fájlok, PDF-ek, admin jogkörök, katalógus, fizetési állapotok és egészségellenőrzési útvonalak körül. Az e-mailes megkereséseket témánként rendeztük, és megfelelő threadekhez készítettünk piszkozatokat. Nem zárult le automatikusan minden ügy: a retailer-díjak és a végső checkout UAT üzleti döntésre, a FortiGuard-felülvizsgálat külső válaszra vár.