Mit csináljunk akkor, ha egy Web Service lassú?

Mit csináljunk akkor, ha egy Web Service lassú?

Szokványos történetnek indult. Adva volt egy nagy projekt, ahol a Marketing osztály egy internetes web site-ot épít, amire majd az ügyfelek belépnek és mindenfélét csinálnak. E web site elkészítését egy külső IT beszállítóra (nevezzük Uno-nak) bízták. A web site-on naprakész adatokat kellene megjeleníteni, amik a vállalat belső rendszerén vannak – e kapcsolat kiépítésére megbíznak egy másik IT beszállítót, Duót.

A belső rendszert Zétának nevezik, és egy másik csapat tartja karban – nevezzük őket Zéta Application Support-nak.

Összeült a kupaktanács az Enterprise Architect, a Network és a Security bevonásával, kitalálták hogy majd Duó épít egy ASP.Net-es Web Service-t Uno és Zéta között. Az ötlet tulajdonképpen jó volt, a döntést cselekvés követte, az új programkód ki lett tolva élesbe.

És itt jött a „hoppá”… a Web Service hívás átlagosan 3 másodperc vagy még több idő alatt futott le. Ügyfeleket kiszolgáló marketing célú web site-ról beszélünk, ahol nem várakoztathatjuk az ügyfeleket 3 másodpercig, amíg az oldal betölt.

(Apró szösszenet: VOLT stressz teszt, ahol előre látszott, ez lassú lesz. Az a magyarázat született, hogy az éles rendszeren majd gyorsabb lesz… telepíteni kell mert a határidőnek meg kell lenni…)

Jött a fejvakarás és a hibakeresés, de senki sem talált semmit. Mindenki megnézte a saját részét, és azt találta, hogy ott minden optimális.

Teltek a hónapok, a Marketing osztályon egyre jobban szorított a cipő, hogy akkor most mi lesz. Mert így nem lehetett elindulni a web site-tal, megoldás pedig nem mutatkozott. Ment az eszkaláció és a fenékberúgás körbe-körbe, dühödt levelek íródtak.

Végül aztán a bölcs vezetők kitalálták, hogy alakítsunk egy „kommandót” a probléma megoldására, és a kommandó vezetését bízzuk valakire… mondjuk rám.

Na így kerültem bele a történetbe.

Az egyszeri informatikus rögtön nekiesett volna az ASP.Net megoldásnak, azonban ez óriási hiba lett volna. A 3 másodperces válaszidő csak a felszín volt, a mélyben súlyosabb problémák húzódtak meg. Úgy döntöttem, hogy tüneti kezelés helyett rendbe rakom a projektet és a problémák gyökeréhez nyúlok. Mik voltak ezek a problémák:
- Nem volt tisztességes műszaki koordináció a résztvevők között, azaz nem volt rendszerintegrációs csapat. Menedzsment szinten volt koordináció a felek között, ami kevés.
- Nem volt integrációs teszt. Mindenki letesztelte a saját szoftverét (unit test), de ez kevés.
- Elmérgesedett a viszony a felek között, senki sem bízott senkiben.
- Mindenki defenzív volt, azaz csak odáig dolgozott, hogy bebizonyítsa, nem az ő rendszerében van a hiba.
- Igazából architektúrális tervezés sem volt. Nem volt részletes folyamatleírás, senki sem tudta hogy a folyamatban milyen komponensek, programok vesznek részt, hol fut a kód.

Azt javasoltam, hogy strukturált módon, tesztesetek segítségével teszteljük végig a teljes folyamatot, illetve a folyamat minden egyes részét. Az így előállt információ alapján szűkítsük le az okokat, ezeket vizsgáljuk meg, a feltárt hibákat javítsuk ki.

Az első kihívás a csapat összeállítása volt – lévén a felek nem voltak közreműködőek. Ehhez először szerveztem egy megbeszélést a Projekt Szponzorral és megszereztem a támogatását. Ezután a Projekt Menedzserrel beszéltem, aki örült, hogy segítséget kap. Ők ketten aztán értesítették a beszállítókat, hogy csatlakoztam a projekthez és a hiba feltárásán dolgozok.

Miután ez megvolt, létrehoztam a kommandót. Minden csapatból kértem egy szakértőt, aki az adott részhez ért, illetve műszaki menedzserek is csatlakoztak. A kemény magot 7 fő alkotta, ehhez csatlakozott még 6 menedzser, akik valamilyen módon érintve voltak. Ez a 13 fő 6 országból jött össze.

Az első megbeszélés volt a leghosszabb és a legkritikusabb: meg kellett győznöm mindenkit, hogy vágjunk bele egy strukturált integrációs tesztbe. Ez sikerült is. Az adott helyzetben senki sem tehette meg azt, hogy nem mutat – legalább a felszínen – együttműködést. A menedzsment mögöttem állt.

Fontos volt a beszállítók segítségének megszerzése, hiszen a fejlesztést ők végezték. Az egyik beszállítóval már korábban is dolgoztam együtt. Általában ügyelek arra, hogy pozitív benyomásokat hagyjak magam mögött, ezért most könnyű volt velük együtt dolgozni.
A másik cég először nekiállt vitatkozni, hogy nekik a kommandós munkáért adjak pénzt – kb 10 perc alatt lerendeztem őket, de ez egy másik történet. Nem volt több vita.

A munka nagy része az elején rám várt: összeszedni a fellelhető információkat, összesíteni azokat egy dokumentumba, és utána a kommandó tagjaival közösen átnézni, pontosítani, véglegesíteni.

Elkészült a folyamatleírás és az architektúra.

Ezek alapján csináltam egy teszt tervet, kidolgoztam az egyes teszt eseteket, vagy legalábbis meghatároztam az irányelveket, és a csapat kidolgozta a részleteket.

Hetente 2-szer volt 1 órás telefonkonferenciánk, amit nagyon szigorúan vezettem, és mindenről jegyzőkönyv készült. E jegyzőkönyvek a menedzsmenthez is eljutottak (nem csak a projektben, hanem mindegyik csapatnál), és az alapján képezték a folyamatos munkának.

Senkit sem utasítgattam, hanem csak ötleteket dobtam fel, javaslatot tettem, és hagytam, hogy a szakértők elmondják a véleményüket. Ha bármiben is döntöttünk, akkor kikértem mindenki véleményét, hogy a döntést mindenki sajátjának érezze.

Igyekeztem mindenkit egyenrangú félként kezelni, mert mindenki tudott valamit, amiben hasznos tagja volt a csapatnak. Akadtak hangosabb és kevésbé hangosabb emberek.
Hasznos tanulság: ha valaki csendben van, az nem biztos hogy azért, mert nincs véleménye. Érdemes időnként a munkatársakkal külön-külön is beszélgetni. A közös beszélgetések során pedig tudatosan figyelni kell, hogy mindenki megszólaljon.

Ahogy a teszteket sikerült végrehajtani és jöttek az adatok, egyre több összefüggésre derült fény. A teszt eredményeket mindig a teljes csapat megkapta, és igyekeztem következtetéseket készíteni.

Amikor nekivágtunk a dolognak, azt vártuk, hogy majd megtaláljuk a lassúság okát, kijavítjuk, és minden jó lesz. Ezzel szemben az az igazság, hogy a folyamat sok lépésből áll, és minden lépés, minden hálózati elem okoz valamennyi lassulást. Ez megváltoztathatatlan tény, a hibát nem lehet véglegesen „megoldani”, csak javítani a helyzeten.

Tehát igyekeztünk olyan pontokat azonosítani a folyamatban, ahol lehet redukálni a válaszidőn, és elsősorban azokra a helyekre összpontosítottunk, ahol ez a redukció a legnagyobb.

Ilyen volt a web szerver, amely konfigurációját egy szakértővel közösen átnéztük, és pár dolgot átállítottunk.

Másik ilyen lehetőség volt a .Net-es WS projekt konfigurációja. A .Net sajátossága, hogy azonnal nem gépi kódra, hanem CRL-re fordít – ami viszont futás időben lassuláshoz vezet. A megfelelő beállításokkal ez megkerülhető és azonnal futtatható kódot lehet készíteni.

A hálózati címfordító szerver is kapott egy új firmware-t, illetve a terheléselosztó konfigurációját is módositottuk a HP ajánlása szerint.

Az is kiderült, hogy a teszt környezetben mért válaszidők nem relevánsak az éles környezettel, ugyanis a két környezet nem teljesen azonos.

Amikor minden tesztet lefuttatunk, minden lehetőséget végignéztünk és minden kérdésre választ kaptunk, akkor az összes módositást éles környezetben telepítettük és teljesítmény tesztnek vetettük alá.

Az átlagos válaszidőt sikerült 1 másodperc alá csökkenteni.

Szerveztem egy vezetői értekezletet a munka lezárására, ahol ismertettem az elvégzett munkát és az eredményeket. A Projekt Szponzor elégedett volt és a jóváhagyta web oldal minél hamarabbi indulását.

(A vezetői értekezlet egyébként nem sikerült tökéletesen: műszakilag korrekt leírást akartam adni az elvégzett munkáról, viszont így egy szót sem értettek belőle a marketingesek – azon kívül persze, hogy a válaszidő mennyi.)

Ezen felül javaslatot tettem egy optimálisabb architektúra kialakítására, azaz a WS újrafejlesztésére. A történet eredetileg 1 darab Web Service-ről szólt, azonban kiderült, hogy valójában a WS további WS-eket hívogat. 1 hívás esetén még kérdés, hogy miért nem 1 másodperc, de több egymásba fűzött hívás esetén már nem csoda a hosszú válaszidő. A folyamatot átszervezve, az architektúrát újragondolva sokkal gyorsabb megoldást lehet készíteni.

Milyen képességekre volt szükség a történet sikeres lezárásához?
- Technológiai ismeret: .Net, WS és hálózati ismeretek, hogy egy nyelvet lehessen beszélni a szakértőkkel (kérdezni tudjak és értsem a választ)
- Tapasztalat korábbi informatikai projektekből: hogy értsem a problémát - a valódi problémát
- Koordinációs és kommunikációs ismeret: összefogni és koordinálni a csapat munkáját
- Multinacionális cég működése: menedzsment támogatást szerezni és megfelelően riportálni
- IT folyamatok és eljárások ismerete

Milyen tanulságokat lehet levonni?

- Ha valaki egy ilyen komplexitású informatikai projektet próbál meg informatikai ismeret nélkül levezényelni, akkor ott könnyen bajok lehetnek.

- Habár a probléma műszaki jellegű volt, de a komplexitása miatt inkább a kereteken és a munkaszervezésen volt a hangsúly. Kellett valamilyen tervet csinálni, ami átfogó, könnyen érthető és követhető.

- Fontos volt az emberek megnyerése és motiválása. Hinniük kellett abban, hogy jó irányba megyünk.

- A történetben szerepelt 2 beszállító. Nekik fontos az, hogy a megrendelő előtt ne hibázzanak. Úgy kellett terelgetni őket a megoldás felé, hogy jól tudjanak belőle kijönni. Ha bűnbakot keresek vagy ujjal mutogatok, akkor átmennek sündisznóba és akadályozzák a munkát.

- Mivel nem volt egyetlen ok a lassúságra, mindig lehetett volna mutogatni a másikra, hogy ott a hiba. Ezt meg kell előzni, ami itt sikerült is.

- Az átfogó tesztelésnek igazából az volt a szerepe, hogy a szakértők újra átgondolják a folyamatot, és felfedezzék azokat a pontokat, amiket korábban elhanyagoltak vagy rosszul csináltak. A megfigyelés maga megváltoztatja a megfigyelt tárgyat.

- Jól látható, mennyi plusz munkát és költséget okoz az, ha a munka elején az architect és a PM nem elég alapos.

- A szoftverfejlesztés csapatmunka.

- A történetből kiderül, mit csinál egy informatikai menedzser munkaidőben (mármint blog íráson kívül).