Enterprise Drupal / 2026. április
Production hibánál az első commit gyakran az, amit nem írunk meg
Support közben többször az bizonyult a leggyorsabb útnak, hogy előbb összegyűjtöttük a tényleges futási bizonyítékot, és csak utána nyúltunk a kódhoz.
A helyzet
Amikor productionban valami rosszul működik, erős a nyomás, hogy legyen gyors fix. Egy ismert stackben már néhány perc után van három valószínű hipotézis, és könnyű valamelyikre patch-et írni. A gond az, hogy egy tünetet több réteg is előidézhet: cache, adat, config, külső szolgáltatás vagy tényleges kódhiba.
A megoldási út
A hibakeresést reprodukálható megfigyeléssel kezdtem: pontos request, időpont, log-korreláció, érintett konfiguráció és a legutóbbi változások. Csak ezután állítottam fel hipotézist. Ha ideiglenes diagnosztika kellett, célzott és eltávolítható logolást használtam, nem általános debug módot productionban.
Mi lett belőle
Több esetben kiderült, hogy az elsőre kézenfekvő kódfix rossz rétegbe került volna. A valódi ok megtalálása után kisebb, biztonságosabb változtatás elég volt, vagy egyáltalán nem kellett kódot módosítani. A későbbi RCA-hoz is megmaradt a tényalapú eseménysor.