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.