2010. április 20. fontos dátum lesz az informatikai üzemeltetés történetében. A Microsoft kiadta a System Center Service Manager 2010 terméket – a Service Manager első változatát. Na végre! – mondhatja bárki, aki követte a szoftver életútját. Nagyjából éppen két évet késett az eredeti tervekhez képest. Ott voltam azon a belső konferencián, amikor bejelentették, hogy az eredetileg 2007. év végére tervezett megjelenés 2010 első félévére csúszik. A 2 év csúszás az lényegében azt jelentette, hogy majdnem előről kezdték a fejlesztést. No, ez persze így nem igaz, hiszen a kód és az architektúra jelentős része közös az Operations Managerrel, de azért jócskán hátradőlt a csapat, hogy végiggondolja a hogyan továbbot. Volt miért. Az eredeti Béta1 kb. 200 gép kezelése környékén bedőlt, nem lehetett tovább terhelni. A minap megjelent RTM 50 000 desktopig skálázható. Ennél ugyan lennének nagyobb rendszerek is, de az ügyfelek többségének ez elfogadható nagyságrend.
Azt hiszem, kevés olyan System Center termék van, amelyhez ekkora várakozások fűződnek. Ha a Microsoft belép egy piacra, ott többnyire drasztikusan leszorítja az árakat. Ez most is így van, még akkor is, ha a szokásos SC árakhoz képes a Service Manager jóval drágább. (Na ja, a Remedy-hez meg a CA ServiceDesk-hez kell ezt nézni). Az alacsonyabb ár segít túllépni a kevesebb referencia problémáján, átbillenti a költségekre érzékenyebb ügyfeleket, no meg azokat, akik a korábbi megoldásokat egyszerűen nem érhették fel. Nem utolsó sorban óriási a várakozás azon üzemeltetési vezetők körében, akik bevásároltak (és bevezettek) egy csomó más System Center terméket, és most azt gondolják, hogy a Service Manager rendbeteszi majd a folyamataikat is. Arra való, nem?
De egyáltalán mit tud a Service Manager? Ezt részben a Microsoft Operations Frameworkkel lehet megmérni. Elvégre ez az az üzemeltetési módszertan, amelyet a Microsoft ajánl, s amely módszertan gyakorlatba ültetését épp a Service Manager hivatott a jövőben a leginkább segíteni. A MOF – ahogy az ábrából is látható – három fázisból (Plan, Deliver, Operate), egy rétegből (Manage), ezeken belül pedig egymással kereszben kasuló összefüggő Service Management Fuction-ökből (SMF) áll. Minden egyes SMF-en belül folyamatok (Process), azon belül pedig feladatok (Task) vannak. A fázisokat, és néha egy-egy SMF-et ún. Review-k választják el egymástól. Rögtön szögezzük le, hogy a Service Managernek nem feladata minden SMF támogatása, hiszen bizonyos üzemeltetési feladatokat esetleg nem is lehet rendszerfelügyeleti szoftverrel lefedni – pl. Business/IT Aignment – vagy éppenséggel más termékek végzik azt. Hogy mást ne mondjak, a “Service Monitoring and Control” SMF rendszerfelügyeleti eszközökkel támogatható folyamatait a SCOM segíti. No, szóval, ha a MOF egy térkép, akkor a Service Manager alapképességei közé az alábbi SMF-ek támogatása tartozik:
- Operations(*)
- Customer Service
- Problem Management
- Change and Configuration
- Gvernance, Risk and Compliance – GRC (**)
Két SMF támogatást is megcsillagoztam. Az első az Operations, amelyben az üzemeltetési leírások készülnek, vagy finomodnak. A Service Manager tartalmaz egy tudásbázist (Knowledge base), s bár persze másképp is lehet, én mégis ebben tárolnám az üzemeltetési feladatok leírását – már persze azokat, ahol emberi munkára van szükség. A második megjegyzés a GRC-t illeti. Jelenleg még nem része a terméknek, külön, Solution Accelerator formában jelenik meg a “Governance, Risk and Compliance” Management Pack, az azonos nevű SMF támogatására. Hogy pontosan mikor, azt nem tudni. Jelenleg beta1 állapotban van a Management Pack, ez még csak az SM béta 2-vel működik jól. Május végén várható egy Béta 2, amely telepíthető lesz a Service Manager RTM kiadásra. A GRC RTM talán őszre lesz kész, de pontos dátm még nem ismert.
Mindez nem tűnik soknak, de ne feledjük, hogy a fenti SMF-ek végrehajtása során rengeteg információ keletkezik a Service Managerben, így a Management Review-k közül jónéhány (Policy & Control, Operational Health, Service Alignment) főleg az SM-ől nyert adatokból, kimutatásokból és jelentésekből táplálkozhat. A folyamatok legfontosabb teljesítmény-indikátoraihoz (Key performance Indicator KPI) külön beépített jelentések találhatók, de SQL Report Builder segítségével tetszőleges más jelentés is elkészíthető. Önmagában ez még mindig kevés lehet. Szerencsére a Service Manager egy kiterjeszthető platform, pontosan olyan könnyen, ahogy az Operations Managerbe importálunk egy új MP-t. Ilyen Management Pack formájában jelenik meg a Provance cég IT Asset Management megoldása, amely több SMF-en is átívelve az IT eszközök (hardver, szoftver, licenc(!)) életciklusát hivatott támogatni. Mindezen képességekkel a Service Manager több is, meg kevesebb is, mint a konkurrensei. Egy példa: a Remedy bizonyosan szofisztikáltabb és összetettebb Helpdesk megoldást biztosít, de nem valószínű, hogy GRC tevékenységeket is támogat.
Amiben – megkockáztatom – erősebb lehet a Service Manager a versenytársainál, az az integráció (és persze első körben a System Center termékekkel való integráció). A 250 PC-nél többel rendelkező szervezetek többségének van Microsoft Enterprise Agreement (vagy más, nagyvállalati) szerződése. Ezen szerződések közel kétharmadában van System Center Configuration Managre (SCCM) CAL. Még ha a megvásárolt és a telepített példányok nem is esnek egybe, azt nem mi mondjuk, hanem a Gartner állítja rólunk, hogy az SCOM és az SCCM a legtöbb példányban használt rendszerfelügyeleti eszköz. Ha ez így van, akkor a Service Managerrel jól járhatnak a korábbi SC termékeket már használó szervezetek: a System Center Service Managerben ugyanis a CMDB (CMS) felépíthető adat-importálással is. Az Active Directoryból a felhasználók és felhasználói csoportok, a Configuration Managerből a hardver és szoftver (+ szoftver frissítési) információk, az Operations Managerből pedig a riasztások kerülhetnek át az SM-be, hogy aztán különböző folyamatokat indíthassanak el, vagy azok hathassanak rájuk. Aki épített már CMDB-t, az tudja értékelni az ilyen kapcsolatokat. Emellett integrációnak tartom azt, hogy SQL szervert használ a termék, azon belül SQL reporting service-t, az önkiszolgáló portál Sharepointtal integrálható, a SM konzol mögött ülők látják az incidens kezdeményezők vagy éppen a támogató mérnökök jelenlét információit az Office Communications Server segítségével stb. stb.
Ez idáig a technológia. A cikket azzal kezdtem, hogy a terméket nagy várakozások előzték meg. E mögött a várakozás mögött sokszor az az elgondolás húzódik meg, hogy a Service Manager implementálása jobbá teszi majd a folyamatokat, mert kikényszeríti azok végrehajtását. Rossz hírem van! A Service Manager csak technológia. Nem képes a folyamatok kialakítására. Nem képes a MOF félig elméleti félig gyakorlati javaslatainak implementálására. Sőt, a helyzet még ennél is rosszabb. Nem képes a rossz technológiából jót csinálni. Ha az én SCOM rendszerembe ömlenek a felesleges riasztások, akkor a Service Managerben mérhetetlen mennyiségen fognak keletkezni a felesleges incidensek, és értéktelenek lesznek az incidensekről szóló kimutatások. Ha nem tiszta a AD adattartalma, és rég kidobott számítógépek, távozott felhasználókkal van tele a címtár, akkor hibás lesz a hardver leltárunk és rosszul fog kalkulálni a felhasználók számát figyelembe vevő licence modell. Hadd ne folytassam.
Isten ments, hogy valaki Service Manager-t implementáljon! Tűzze ki célul, hogy egy üzemeltetési vagy támogatási mutatót javítani fog, hogy SLA-t mér, hogy incidens számot csökkent. A Service Manager segíteni fog a mutató kiszámításában, az SLA mérésében. De a Service Manager nem lehet cél. l’art pour l’art “bevezetésével” semmi nem változik, semmi sem javul, semmi sem lesz jobb. “A fool wth a tool is just a fool”, ahogy az angol mondja. (Egy bolond egy szerszámmal, az csak egy bolond!)
Szóval hajrá MOF, hajrá ITIL, itt van végre egy viszonylag olcsó, friss architektúrával rendelkező, jól integrálódó és az üzemeltetési feladatokat sokrétűen támogató eszköz. De csak egy eszköz, semmi más.
Lepenye Tamás webnaplója 