HTML

ITÉlet

Egy multinacionális cégnél dolgozó informatikai manager szakmai blogja. Észrevételek, tapasztalatok szoftver fejlesztésről, vezetésről, managementről és hatékonyságról itthoni és külföldi példákon keresztül. Az informatikáról másképp...

Utolsó kommentek

  • sagabona: szia... elég régen született ez a bejegyzés, én csak most akadtam rá véletlenül. Érdekes dolgokat írsz, részben egyetértek az általad gondoltakkal, azonban pár dologban messze más a véleményem - ez ... (2018.10.19. 11:14) Gondolatfoszlányok a pályaválasztásról
  • Simon Géza: "A következő forradalmi áttörés, nagy dobás, ami megint tőzsdei felfutáshoz vezet, az nem valamilyen informatikai dolog lesz, hanem egészen más." Ha a generic AI nem informatikai, akkor igazad van.... (2018.02.19. 07:01) Az IT jövője
  • pggp: @AnyTink: Köszi, de én csak egy blog olvasó vagyok, aki jól tudja használni a keresőt ;-) (2017.10.17. 07:19) Milyen volt hazaköltözni?
  • AnyTink: @pggp: :) Gratulálok a család bővüléséhez és a sikeres 'hazatelepedéshez'. Mi most gondolkodunk a hazaköltözésen és jó olvasni mások élményéről! Köszönöm az írásod :) (2017.10.16. 18:49) Milyen volt hazaköltözni?
  • pggp: Tulajdonképpen igen, alakult valami: akocsis.com "2017 április, Dália eloször Szentesen" ;-) (2017.06.06. 21:51) Milyen volt hazaköltözni?
  • Utolsó 20

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.

Címkék: performancia

A bejegyzés trackback címe:

https://akocsis.blog.hu/api/trackback/id/tr555211465

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.