ITÉlet

Korábban szó volt a performancia problémák kezeléséről, most Imre tanácsára a tűzoltás helyett a megelőzésről lesz szó.

Korábban szó volt a performancia problémák kezeléséről, most Imre tanácsára a tűzoltás helyett a megelőzésről lesz szó.

Vitathatatlan, hogy amikor ezek a problémák beütnek, akkor már túl késő (tipikusan az éles telepítés után futunk bele először), esetleg az egész projekt ezen a ponton fog megbukni.

Mit is csináljon az ember, hogy ne legyenek performancia problémái?

Standard technológiák: A magára valamit adó nagyvállalatnak vannak belső műszaki ajánlásai, „szabványos” technológiái. Amikor a szakértők kiválasztanak egy technológiát, akkor azt okkal teszik, tehát például megvizsgálják, hogy lehetséges-e az adott eszközökkel a cégnél előforduló számosságokat kezelni. Vagyis nem azért kell az ajánlást követni, mert különben az IT-rendőrség elkap, hanem mert biztosak akarunk lenni a dolgunkban.

Jól bevált eszközök: Ami már valahol bevált, az bizonyított, és emiatt megbízható. De nem csak megbízható, hanem rendelkezésre fog állni a tapasztalat, a szakértelem, a tudás. Meg lehet kérdezni valakit, lehet konzultálni.
Járt utat járatlanért el ne hagyj!

Nem funkcionális követelmények rögzítése: A performancia probléma tipikusan az üzemeltetés során fordul elő, az éles környezet által jelentett kihívások miatt. Ezen kihívások kezelése a szoftver fejlesztés és tervezés feladata, viszont a kihívásoknak a szoftver specifikáció fázisában nincs gazdája. Az ügyfél tipikusan csak a funkcionális követelményekben érdekelt, számára a többi dolog alacsony prioritású. Éppen ezért fontos a minél hamarabbi integráció az éles környezettel, és a majdani éles környezet kihívásainak rögzítése a projekt korai fázisában.

Zsenik szárnyainak lenyesése: A legtöbb esetben a gyenge teljesítmény abból fakad, hogy a tervezés vagy a fejlesztés során valakinek volt egy zseniális ötlete, amikor valamit a nem szokványos módon használt, és utána feltételezte, hogy minden rendben lesz. Próbáljunk meg zseniális megoldások helyett egyszerűket keresni.

Az üzemeltetés bevonása a projektbe: A szoftverfejlesztők tipikusan addig érdekeltek a szoftverfejlesztésben, amíg a szoftver el nem készül. Utána már nem annyira. Pedig a teljesítménnyel pont ezután lesznek gondok – amikor a szoftver élesben fut. Éppen ezért be kell hozni szereplőként az üzemeltetést a projektbe, akik nem csak tájékoztatást kapnak, hanem bele is szólhatnak a műszaki döntésekbe.
(Ez sértheti a fejlesztők érdekeit, de másképp nem megy)

Design review: Performancia szempontjából fontos az a mérföldkő, amikor a szakértők jóváhagyják a szoftver architektúráját, az alkalmazott műszaki megoldásokat. Az architektúra formális validálása azért fontos, mert sok különböző oldalról végig kell gondolni egy elgondolást ahhoz, hogy az ténylegesen megoldás legyen. Tévedés azt gondolni, hogy a fejlesztő úgy fejleszt, ahogy akar!

Proof of Concept: Ha másképp nem tudunk meggyőződni az elgondolás helyességéről (hogy képes-e a terhelést kezelni), akkor célszerű egy külön projektet indítani egy prototípus elkészítésére, ami a szükségesre hasonlító környezetben bizonyítja a design működőképességét.

Teljesítmény teszt: Ne csak funkcionálisan teszteljük le a rendszert, hanem az élessel megegyező teszt környezetben, a valós terhelést legjobb modellezésével! Minden komolyabb változtatás automatikusan teljesítmény tesztet jelent.
A teszt célja meggyőződni arról, hogy a módosítás vagy az új szoftver képes működni valós közegben.

Tisztességes teszt környezet: A teljesítmény teszt feltételezi, hogy a fejlesztés (dev), elfogadási (UAT/Test) környezet mellett létezik egy harmadik (nevezzük QA-nak), ami tökéletes másolata az élesnek. Ha nincs ilyen környezetünk, akkor nem fogunk tudni rendesen tesztelni, és minden telepítés orosz ruletté válik… márpedig tudjuk, mi lesz az orosz rulett vége…

Átadás-átvétel fejlesztés és üzemeltetés között: Az átadás-átvétel kiváló alkalom annak tisztázására, hogy milyen terhelésre van „hitelesítve” a rendszer, mekkora adatbázisra van szüksége, mekkora az éves növekedés, és a szoftver fejlesztők hogyan számolták ki ezeket.

Fallback plan és Post Implementation Review: Ha mégis valami balul sülne el a telepítéssel, és a rendszer összeomlik performancia hiba miatt, arra az esetre mindenképpen legyen egy terv az eredeti állapot visszaállítására. Mivel a teljesítmény hiba érzékelése nem triviális, ezért az éles indulás után érdemes egy review-t szervezni, ahol megvizsgáljuk a szoftver teljesítményét valós közegben, és az eredményt kiértékeljük (összehasonlítjuk a várt és a tesztelt eredménnyel).

Ha mi vagyunk az ügyfél, és meg szeretnénk bizonyosodni átvételkor a szoftver tökéletességéről, mit tegyünk? A válasz függ attól, hogy dobozos szoftvert vagy egyedi fejlesztést veszünk-e át, de adok néhány tippet:

Nem funkcionális követelmények rögzítése: Ahogyan már írtam, a nem funkcionális igényeket minél hamarabb írásban kell rögzíteni, már az információkérés fázisban.

Szerződés: A teljesítménnyel kapcsolatos elvárásokat (felhasználók száma, működési környezet) nem árt a szerződésben (is) rögzíteni.

Software as a Service (SaaS): Amennyiben ugyanaz a beszállító fejleszti, üzemelteti és hostolja a rendszert, úgy biztosan nem lesz vita a felelősségről.

Tesztelés, tesztelés, tesztelés: Minden, amit fent írtam a tesztelésről, kéretik nagyon komolyan venni – különösen a teljesítmény tesztet és a tisztességes teszt környezetet.

A teljesítés igazolása: Amennyiben kétséges vannak a szoftver teljesítményével, úgy átfogalmazhatjuk a munka teljesítését és a teljesítés igazolását – ne a szoftver átadása legyen ez a pont, hanem kössük sikeres bevezetéshez és megfelelő rendelkezésre álláshoz.

Garanciák: Bizonyosodjunk meg róla, hogy a megállapodásban szerepel a garanciákra vonatkozó kitétel, tehát a szoftver nem megfelelő működését (ide tartozik a performancia probléma) az átadás után is köteles a beszállító javítani.