Megyünk előre ész nélkül?

A technológia rohamosabban változik mint valaha, megérkeztünk a konténerizáció, a microservice-ek és a CI/CD világába. Az üzleti igények a lehető legmagasabb minőségű és leggyorsabb megvalósítását várják el a fejlesztőktől, de közben az üzemeltetés sem maradhat ki az elvárásoknak való megfelelésből. Jelentős közreműködése és hozzájárulása van az üzleti igények teljesítéshez mindkét félnek, közös metszetként egyre több helyen a DEVOPS csapatnak.

Míg az üzembeállításra fókuszálunk, elfelejtkezhetünk arról, hogy az alkalmazások életciklusa nem ér véget az élesítéssel. Hibás megközelítés, hogy addig tervezünk és addig van fókuszban egy fejlesztés, amíg az élesítésre nem kerül. Emellett azonban a működtetésnek és a korszerű üzemeltetésnek legalább akkora figyelmet kellene kapnia már a tervezéskor és az implementáláskor, mint magának a funkcionalitás megvalósításának.

Ami elromolhat, az lehet, hogy már el is romlott?

A startpisztoly eldördülését követően jön el a puding igazi próbája. Élesbe állt a fejlesztés, elkezdték használni, várjuk a boldog felhasználókat, szeretnénk értéket (és pénzt) teremteni. Mindenki találkozott már informatikai rendszerhibákkal – akár felhasználóként az elszenvedője volt, akár a javítását végezte vagy annak koordinálásáért felelt. A hibák bekövetkezése után egyáltalán nem mindegy, hogy mennyi idő azt felderíteni, behatárolni, megérteni és végül javítani.

A bevezetőben szereplő elvárások növekedése (time-to-market csökkentése, kurrens technológiák használata, stb.) összefügg a felhasznált technológiák megválasztásával, ami egyben a kiszolgálókörnyezetet is érinti. A meglévő, korábbi technológiákat jól monitorozó eszközök már nem feltétlenül alkalmasak kielégíteni az új igényeket vagy egyszerűen csak a használatuk vált körülményessé az új felállásban. Ha a tervezéskor nem fordítottunk elegendő figyelmet az üzemeltetés elősegítésére, akkor komoly bajban lehetünk a hétköznapokban.

Nem csak az eszközön múlik!

Ahhoz, hogy az új érát magunkévá tegyük, értenünk kell benne az összefüggéseket és a mögötte húzódó filozófiát. A konténerizáció, a microservice architektúra, a magasfokú skálázás lehetősége – vagy akár a felhőszolgáltatások – gyökeresen más megoldásokat biztosítanak a folyamatosan változó igényekre.

Az IT architektúránk komplexebb lett, megnőtt az egyes szolgáltatások egymás közötti függősége. Az alkalmazás-példányok száma folyamatosan változik a terheléstől függően, konténerek indulnak és állnak le akár néhány másodpercen belül, amit a klasszikus monitoring rendszerek nem tudnak lekövetni. Már nem elfogadható annyival megelégedni, hogy alapszintű, mintavételezett információnk van a ránk bízott összetett rendszer működéséről (vagy nem működéséről..), többre van szükség: az egész rendszert a naplóállományoktól a tranzakciókig figyelő átfogó megoldás a célravezető.

Nőjünk fel fejben is!

Ahogy a SOA (Service Oriented Architecture) tekintetében, úgy a jellemzően konténereket használó microservice architektúrában is erősen javasolt egy APM (Application Performance Monitoring) eszköz megléte, ami a tranzakciókról, az alkalmazásaink belső működéséről és állapotáról adnak információt közel online módon. Azonban a SOA kapcsán elterjedt APM eszközök nem feltétlenül alkalmasak a fentebb említett újabb technológiák teljeskörű kiszolgálására.

Egy jelenleg modern monitoring rendszer már egyben elemzi a működés közben keletkezett naplóállományokat az online tranzakciókkal vagy veszi figyelembe a microservice-ek közötti függőségeket azok konfigurációival.

A dinamikusan változó alkalmazás-példányok és konténerek automatikus figyelése az azokra releváns metrikák függvényében szintén elengedhetetlen, hiszen nem várható el egyetlen üzemeltetőtől sem az a szuperképesség, hogy a folyamatosan változó környezethez „near-online módon utána húzza” a monitoring rendszert. Igen, ez valóban a kontextusba helyezett monitoring, ami képes előre jelezni a problémák bekövetkeztét, ezáltal segítve az idejekorán történő elhárítást vagy még jobb esetben az incidensek elkerülését. 

Ha beütött a baj, a monitoring feladata lehet a jövőben a hiba  felderítésének és elhárításának segítése, hogy csökkenjen a szolgáltatás-kieséssel járó idő.

És valóban, itt és ebben a pontban nem ér(het) véget a történet: gondoskodnunk kell arról, hogy kétszer ugyanaz a probléma ne üssön be, ezért a sokak számára aprólékos szöszmötölésnek tűnő gyökérok elemzés (RCA) megkönnyítésének és felgyorsításának alapvető igénynek kell lennie.

Remek munkát végezni csak pompás szerszámmal lehet!

Az Intalionnál számtalan monitoring megoldást bevetettünk már projektjeink során, mindig az adott igényekhez maximálisan igazodó alkalmazást keresve. Emellett nem győzzük hangsúlyozni partnereinknek, hogy a meglévő monitoring eszközök alkalmassága egy új projekt esetén mindig kérdéses. De az üzemeltethetőségre való felkészülés – beleértve annak tervezését is – minden új fejlesztési igénynél jó apropó arra, hogy megvizsgáljuk, a megfelelő eszközzel dolgozunk-e.

Tapasztalataink alapján az IBM Instana képes az aktuális, magas technológiai elvárásoknak megfelelni, azokon túlmenően az auto-discovery funkciója a bevezetéskori és működés közbeni favágó (aka. manuális) munkát jelentősen csökkenti, fejlett mechanizmusainak köszönhetően a szűk keresztmetszeteket előre jelzi.

Épp ezért bátran mondhatjuk, hogy az IBM Instana teljeskörű megoldás az alapinfrastruktúra monitorozásától kezdve az elemi tranzakciókig a naplókon át legyen szó felhőről, on-premise rendszerről, de akár a meglévő nem konténer / microservice alapú architektúráig.

Profi segítség a monitoring-tervezéshez

Az Intalionnál nem csak az egyes szoftvereszközök leszállítására fókuszálunk, hanem a teljes képet nyújtjuk, melynek része az üzemeltetési és monitoring eszközrendszer kialakításán túl a megfelelő módszertan biztosítása és adaptálása az ügyfeleink specifikus működési környezetére is.

Tervezz előre velünk: ha felülvizsgálnád meglévő monitoring rendszered vagy egy új fejlesztés küszöbén állsz, kérd szakértőink segítségét!

[Az Intalion megbízásából készített, fizetett anyag.]