Innentől kezdve bevezetek egy jelölést a post címének a végére, mely jelzi, hogy az adott bejegyzésben a két fő terület közül elsődlegesen melyik kerül tárgyalásra, ennek a rendszernek alapján ezen blogbejegyzés a Szolgáltatás-szint mérés gondolatmenetét viszi tovább.

Az előző postban ott hagytuk abba, miszerint:

"De mi is ez a tranzakció alapú történet? Nem akarok "tippelni" és "jósolni" komponensekből, hanem az érdekel, hogy a felhasználók most mit éreznek, megy-e nekik amit szeretnének vagy nem. Ha a példaszolgáltatásunk az e-mail, akkor:

  •  "be tud-e lépni a különböző kliens ezsközökkel a mailboxba elvárt időn belül?"
  •  "tud-e levelet küldeni cégen belül / cégen kívül?"

Ezeket nyilván hitelesen úgy tudjuk megválaszolni, ha MEGPRÓBÁLJUK. Ez egyszerűnek hangzik, de nem az. Hogy miért és miben tud itt a SCOM segíteni?"

Hogy miért is nem egyszerű ez? Vegyünk pár kihívást példákon keresztül:

 

Tranzakció hitelessége

Nos, ez a mérjük/próbáljuk meg azt amit a felhasználó csinál/tapasztal a rendszerben nem mindig egyszerű.

Ha egy könnyű esetet veszünk példaképpen, egy weboldalt, mely egy adott cím beírása után bizonyos információkat megjelenít a felhasználó számára itt a tranzakció teljesen hiteles tud lenni - el tudjuk végezni és meg tudjuk mérni egy az egyben a felhasználói működést. Persze a kivitelezése csak akkor lesz egyszerű is, ha a felügyeleti rendszerünk hordozza ezt a képességet, pl. rendelkezik egy olyan könnyen paraméterezhető wen-motorral, melybe beadjuk a feltételeket és visszaadja az eredményt - jelen esetben az Operations Manager természetesen ilyen :) De ha a tranzakcionális hitelességre kanyarodunk vissza, vegyünk egy másik példát:

Van egy pénzügyi alkalmazás, melynek az egyik kritikus funkciója a havi zárás - mely mellesleg egy elég komplex, sok komponenses folyamat így nem triviális hogy mindig rendben lesz. Jó üzemeltetőként szeretnénk bebiztosítani, hogy észrevegyük még időben, ha gond van a funkcióval illetve mutathassuk, hogy a pénzügyi szolgáltatás rendelkezésre állási szintje hogyan alakul. Nyilván ennek az előző analógia szeeint egyszerű a megoldása - hajtsuk végre a műveletet és értékeljük ki, hogy minden rendben volt-e. Nos, ez könnyen belátható hogy nem feltétlen előnyös, pl. órás vagy még sűrűbb rendszerességgel lezárni a pénzügyi hónapot azért, hogy kiderítsük: "ha valaki most zárni szeretett volna, akkor tudott-e volna". Másik klasszikus példa erre a pénzforgalmi területek, ahol elméleti síkon egyszerű is lehetne az utalás ellenőrzése: az egyik számlámról 5 percenként átutalok 1 ft-ot a másik számlámra - de ennek lehetnek jogi/szabályozási akadályai.

Na de ilyenkor mit tudunk tenni? Közelítünk vagy lebontunk:

  • Közelítünk: nem pontosan azt tesszük, hanem egy ahhoz lehetőleg mindinkább hasonló, de ismételhető / nem destruktív dolgot: a havi zárás példánál valami olyat, mely ugyanazon modulokat, funkciókat szólítja meg, de nem zárja le ténylegesen a hónapot. Itt nyilvánvaló a kompromisszum: nem pont azt a tranzakciót mérjük, amit akarnánk, tehát ott a mérési hiba lehetősége.
  • Lebontunk: nem tudunk még csak közelítőt sem találni, jobb hiján elkezdjük az eredeti folyamat elvégzéséhez szükséges modulokat vizsgálni tranzakciókkal: pl. a weboldal/web service adott metódusa (havi zárás) válaszol-e + az adatbázis szükséges táblái tartalmaznak-e minden adatot és kiolvashatók-e. Itt is kompromisszumot kell kötni, nem mérjük végig az elejétő a végéig a folyamatot, nem "elsődleges" tranzakciókat vizsgálunk, hanem "másodlagos" résztranzakciókat

Remélem a fenti példák jól érzékeltetik ezen aspektus nehézségeit. A tranzakció hitelességét tekintve az Operations Manager sem képes nem destruktív módon lejátszani egy destruktív folyamatot, azonban a megvalósításban nagyon sokat tud segíteni az alábbiak mentén:

  • Sok technológia felügyeleti csomagja (pl. Exchange, Lync) magában hordoz KÉSZ és paraméterezhető szintetikus tranzakciókat (pl. levélmegfordulás, videóhívás) így ezeket nem nekünk kell kifejleszteni
  • Ha nincs technológia specifikus megoldás, képes segíteni mind elsődleges tranzakciók lejátszásában (pl. web alkalmazás / web service, session recorder, stb..) bizonyos típusú web frontend-el rendelkező szolgáltatásoknál
  • Ha nem tud az elsődleges tranzakcióban segíteni, sok beépített, potenciálisan másodlagos tranzakciók alapját szolgáló megoldás található benne (SQL, port-scan, windows service, stb..)
  • Ha másodlagos tranzakció sincs, keretet biztosít tetszőleges mérőmegoldás (pl. Powershell, VBScript vagy JavaScript) használatára

 

A mérés helye(i)

Tételezzük fel, hogy megvan a szuper kis tranzakciónk. A következő kérdés: honnan mérjünk? A válasz elsőre egyszerű: ahonnan a felhasználó használja. Na de mi van, ha mondjuk a levelezést akarjuk mérni és a "tuti" tranzakciónk egy levélmegfordulásos mérés... Ezt hány felhasználó használja? 20-100-5000? Akkor mérjünk mind az 500 felhasználó gépén? És melyik gépen/eszközön - ha több is van neki? Vagy válasszuk a másik végletet, mérjünk magáról a levelezési szerverről levélmegfordulást - hiszen ott is kiderül, ha nem megy...

Nyilván itt a produkció az egyensúly megtalálása, a felhasználók felhasználási terület/szokások szerinti csoportosítása, az egypontos hibalehetőségek megtalálása és a folyamat pontos megértése (pl. nem kell minden eszközről komplett levélmegforsulást mérni, elég az egyikről és a többiről csak megnézni, hogy elérjük-e a mailboxot - azaz fel tudunk-e levelet adni, mely ettől a ponttól kezdve ugyanazon utat járja be).

Az sem reális, hogy még ha csak egy eszközről is, de minden felhasználótól mérünk. Nyilván érdemes pl. hálózati kapcsolatok vagy egyéb szempontok alapján tipizálni ezeket és "kollektív" mérőpontokat lerakni. Esetleg felismerni, hogy ez a folyamat valójában elsősorban a Mailbox kiszolgálókról indul, elég azokat nézni és alternatív módon vizsgálni, hogy azokat elérhetjük-e?

Bármit is választunk, meg kell kötni a kompromisszumot ismét. Hiszen nem mérhetünk minden felhasználó minden eszközéről, hogy per felhasználó legyenek "hiteles" mérési adataink...

Amiben itt az Operations Manager a segítségünkre tud sietni:

  • rugalmas lehetőség újabb mérőpontok beüzemelésére / kivonására, akár fél- vagy teljes automatizmusok használatával is
  • felülírási rendszer kapcsán esetlegesen mérőpontonként eltérő határértékek használatával közelíteni a képet

És még egy ráadás téma: mi van akkor, ha "publikus" szolgáltatást akarunk mérni? Azaz valójában a felhasználóink a cégen / biztonsági határainkon túl vannak? Tudok kintről mérni? A válasz igen, ha Operations Managert használunk, mert az:

  • képes tanusítvány alapú hitelesítés alapon biztonságos kommunikációt folytani olyan gépekre helyezett ügyfél-komponenssel, mely nem tagja a tartománynak/erdőnek

 

A mérés gyakorisága

Ha megvan a jó kis tranzakciónk és megvannak a mérési helyek is, akkor jön a következő kérdéskör: milyen gyakran mérjünk? Erre rá lehetne vágni, hogy "mivel nem tudjuk a felhasználó mikor hívja meg a funkciót, minnél gyakrabban mérünk, annál jobb". És ez igaz is. Itt csak bizonyos technológiai / méréstechnikai kötöttségeket kell figyelembe venni:

  • Minden mérés kis-közepes (komplexitás függvényében) terhet ró mind a mérőgépre, mind a mért rendszerre. Nem lenne szerencsés, ha azáltal, hogy 3 másodpercenként mérünk azt ugyan tudhatjuk, hogy el tudná-e végezni szinte bármely időpillanatban a felhasználó a műveletet, valójában nem tudja, mert nem jut rá processzoridő a sok teszteléstől :)
  • Egy tranzakciónak van átfutási ideje is, pl. levélmegfordulásnál az elvárt "még jó" időhatárt pl.120 másodpercben határozzuk meg. Ebben az esetben a mérésnek meg kell várnia ezen időszakot, hogy megállapítsa, tényleg nem zajlott-e le a tranzakció az elvárt időben. Ha viszont egy ilyen mérést percenként ellövűnk, egymásra futások lesznek és könnyen belátható, hogy hiába futtatjuk percenként, a kiesést csak két perc elteltével tudjuk majd detektálni

Ok, a fentiek alapján ráér ritkábban is. Itt a következőkre kell figyelni:

  • Ha mondjuk valamit csak 15 percenként mérünk, ennyi lesz a mért minimális kiesés is (független attól, hogy a tényleges kiesés esetleg csak 1 percig tartott). Hiszen ha egy mérés kapcsán "rosszba" billenünk, legközelebb csak 15 perc múlva mérünk újra és billenhetünk vissza

Amiben az Operations Manager segíteni tudja a kialakítást

  • rugalmas felülírási szabályrendszerrel akár mérőhelyenként külön-külön határértékek beállítása

 

A mérés redundanciája

Ha a fentiekből mindent jól kitaláltunk, akkor sem dőlhetünk még hátra: mi van abban az esetben, ha a mérőgépünk meghibásodik vagy újraindításra szorul? Ez egy black-out lenne, ezen időszak alatt nem tudunk mérni és ezt se "jó" se "rossz" időszaknak nem lenne jó elszámolni, igazából az lenne a legszerencsésebb, ha nem lenni ilyen időszak. Na de ez nem lehetséges reálisan, így be kell biztosítanunk magunkat: "mi jobb egy mérőgépnél? KÉT mérőgép".

Redundancia kialakítására illetve kommunikációs hiba túlélésére több lehetőséget is biztosít az Operations Manager:

  • Minden ügynök alapértelmezetten store-and-forward elven működik, azaz jelen esetben ha pl. kiesik a hálózati kapcsolat a mérőgép és az Operations Manager kiszolgáló között de a mérőgép és a ért szolgáltatás között továbbra is van kapcsolat, a mérések folytatódnak, az eredmények tárolódnak majd a kapcsolat felépülése után felküldésre/feldolgozásra kerülnek
  • Egy ügynök komponens több kiszolgálóval is kapcsolatban állhat, automatikusan átáll az egyik kiesése esetén
  • Több mérőgép mérési adatait tudjuk különböző aggregációk kapcsán összefuttatni - kizárni a mérőgép kiesések negatív hatásait

 

Rakjuk össze: mérésekből szolgáltatások

Egy-egy adott szolgáltatás leírásához több mérés is szükséges lehet. Gondoljunk csak bele: ha különböző felhasználói típusok használják különböző funkciókon / tranzakciókon keresztül.

Végig kell gondolni az adott szolgáltatás:

  • Interfészeit és azok elérési metódusait
  • Kulcstranzakcióit
  • Felhasználói köreit, kritikus csoportjait, lokációit

Ha azon egyedi mérések megvannak, melyek a fenti esetek egy részt vagy adott részeit fedik, "már csak" össze kell rakni a szolgáltatást.

Vegyünk például egy levelezési szolgátatást és annak mérési absztrakcióját:

  • Mérjük a kliens-elérési protokollokat (MAPI, POP3, IMAP4, Web Access)
  • Mérjük a levélmegfordulást
  • Mérjük a postaláda életképességét

Mit mondunk a levelezési szolgáltatásra ha mondjuk:

  • Minden OK, de nem megy a Web Access?
  • A postaládák 85%-a érhető csak el?
  • A levélmegfordulási idő adott kiemelt levelezési célok felé határértéken túl van, a többi felé nem?

Ezekre a kérdésekre már nem lehet általános választ adni így nem is kísérlem meg - megfelelő konzultáció, forrásadatok (KPI, SLA) mentén határozható meg.

Amit biztos tudunk, az az, hogy az Operations Manager segít a kívánt eredmény elérésében azáltal, hogy:

  • Elemi mérések adott aggregációs relációkba állíthatóak
  • Ebből fastruktúra építhető
  • A "faágakon" is állíthatóak az aggregációk működései
  • Grafikus megjelenítési és szerkesztési felületet biztosít ehhez
  • Többféle vizualizációs megoldás segít az eredmény áttekinthetővé tételében

 

V