Kommunikáció, mint kulcs a performancia problémák megoldásához
Miért kulcsfontosságú a kommunikáció a performance problémák feltárása során?
Egy valós történet tanulságai
A szoftverfejlesztés világában a teljesítményproblémák gyakran nem hibás kódra, vagy konfigurációra vezethetők vissza, hanem a kommunikáció hiányára vagy félreértésére. A performance engineering egyik legfontosabb, mégis gyakran alábecsült aspektusa a különböző csapatok és szereplők közötti hatékony közvetítés. Egy történet jól példázza, milyen következményekkel járhat ennek hiánya és milyen eredményeket hozhat, ha mégis sikerül hidat építeni.
A probléma, amely gazdátlan maradt
Egy összetett projekt záró szakaszában, az integrációs tesztek során egy kulcsfontosságú API rendre timeout-ra futott, ami miatt főbb funkciók nem működtek a frontend-en. A frontend-et és kapcsolódó API-kat ugyanaz a beszállító csapat fejlesztette és szerintük szerint minden rendben volt, hiszen az ő tesztjeik sikeresek voltak és náluk az API hibátlanul működött. A backend üzemeltető csapat szintén elhárította a felelősséget, mert nem történt módosítás az ő rendszerükön és szerintük így hiba sem lehetett náluk.
A projektvezetés patthelyzetbe került. A határidők szorítottak, de senki nem vállalta a probléma feltárását.
Közvetítés a sorok között
Külsős szereplőként bekerülni egy ilyen helyzetbe sosem egyszerű. Ilyenkor az egyik leghatékonyabb megközelítés az, ha azonnali hibaelemzés helyett párbeszédet kezdeményezünk. Itt is ez a lépés volt a kulcs a performancia probléma feltárása kapcsán. A fejlesztőcsapatok meghallgatása,valamint a helyzet megértése az ő szemszögükből a kezdeti bizalmatlanságot könnyen oldotta.
Hasonló nyitottsággal történt a kapcsolatfelvétel a backend üzemeltetőkkel is. A cél nem a hibás megtalálása, hanem a közös megoldás keresése volt.
A hiba, ami valójában nem is volt fejlesztői hiba
A vizsgálat során hamar világossá vált: a frontend oldal túlzott mennyiségű és szükségtelen adatot kért le a backendből, nagyságrendekkel többet, mint amire ténylegesen szükség volt. A rendszer nem volt erre felkészítve, így a válaszidők megnőttek, a kérések pedig timeout-oltak. A fejlesztőcsapat nem hibázott és a specifikáció alapján fejlesztette le az API-t.
Hogy lehetséges, hogy jól lett lefejlesztve, de mégsem működik?
A nyomozás során kiderült a performancia követelmények nem voltak egyáltalán kezelve a projekt tervezése során. Ennek eredményeként a fejlesztői környezeten minimális mennyiségű adat mellett megfelelően működött az API, viszont valós körülmények és mennyiségű adatok mellett már előjött a performancia probléma.
Habár a hiba megoldásához a végén kellett kódot is módosítani, de az egy tervezési hiányosságból fakadt.
A hibáztatás helyett együttműködés
A frontend fejlesztők érthetően kellemetlenül érezték magukat, mert nekik kellett javítani valamit, amit nem éreztek saját hibájuknak. Ilyenkor mint külsős szereplő érdemes felajánlani a mediátor szerepét és közvetíteni a fejlesztői csapatok és a vezetőség, megrendelő között. Ami szükséges volt még, hogy a fejlesztő és üzemeltető csapatok együtt közösen és átlátható módon kommunikálták és így elkerülhetővé vált az egymásra mutogatás.
Az együttműködés eredményeként a probléma megoldódott, a csapatok pedig konstruktívabb, nyitottabb munkakapcsolatot alakítottak ki.
A valódi tanulság
Ez a történet nem csupán egy performancia probléma feltárásáról szól. Sokkal inkább arról, hogy a performance engineering nem kizárólag eszközökről, metrikákról és optimalizálásról szól, hanem emberekről, párbeszédről és megértésről. A világos teljesítménykövetelmények, a korai egyeztetések és a közvetítő szerepek megléte nemcsak időt és pénzt takarítanak meg, hanem csökkentik a stresszt, és erősítik a bizalmat a csapatok között.
Performancia problémák feltárása során érdemes arra emlékezni, hogy az őszinte és nyitott kommunikáció ugyanúgy fontos, mint egy diagnosztikai eszköz.