Sokszor és sokféleképpen kerül szóba napjaink IT megbeszélésein a CMDB fogalma. Sokan – sajnos – nem jól használják és éppen ezért nem beszélünk egységes nyelvet e témában sem. Éppen ezért mielõtt nekifognék ezen cikksorozatnak (mert annak tervezem, remélem idõm és energiám is lesz rá), álljon itt a CMDB definíciója ahogy a wikipedia.com látja:

A configuration management database (CMDB) is a repository of information related to all the components of an information system. Although repositories similar to CMDBs have been used by IT departments for many years, the term CMDB stems from ITIL (Information Technology Infrastructure Library). In the ITIL context, a CMDB represents the authorized configuration of the significant components of the IT environment. A key goal of a CMDB is to help an organization understand the relationships between these components and track their configuration. The CMDB is a fundamental component of the ITIL framework’s Configuration Management process. CMDB implementations often involve integration with other systems, such as Asset Management Systems. These integrations may make use of either a real-time, federated design or an ETL (extract, transform, load) solution.

A fenti definíció a saját véleményemmel is megegyezik, bár azért ha a konkrét értelmezés kifejtését nézzük biztos vagyok benne, hogy nem pontosan így magyaráznám.

Természetesen aki az informatikában számít – és aki nem az is – készített CMDB alkalmazást, amivel “könnyen” és “gyorsan” tudjuk saját cégünkre, üzemeltetési környezetünkre a CMDB-t kialakítani. Nos mostantól ezzel a “könnyen” és “gyorsan” kérdéssel szeretnék foglalkozni, mert

  • bár mindenki errõl papol, de kevés a fellelhetõ valódi infó a mikéntrõl
  • mindenki szerint 1-2 kattintás, egy feltérképezõ motor, aztán szalad a szekér (kérdés merre :))
  • nem találtam gyors megoldást, az átgondolás nélküli változat pillanatokon belül bedõl, a tervezés, elõre átgondolás meg ugyebár idõt, energiát és természetesen a CMDB-vel kapcsolatos ismereteket (nem is keveset) igényel

Remélem sikerül megmutatnom miért nem szabad “ész nélkül”, egyedül, mélyebb ismeretek nélkül belevágni.

Elsõ lépések – Egy rendszer telepítése

Jómagam – mint a CA megoldásszállító – a CA CMDB alkalmazását érem el és tudom használni. Tekintettel arra, hogy ezen rendszer a vonatkozó felmérések alapján jelenleg még mindig a legjobbnak minõsül, úgy gondoltam ebben állok neki és viszem végig a CMDB bevezetését. Lényegesnek tartom leszögezni, hogy bár sok gyártó a CMDB-t mint abszolúte önálló valamit kezeli, szerintem jellegénél és szolgáltatásainál fogva csak akkor használható jól, ha az összekapcsolódik egy Service Desk rendszerrel. Természetesen a CA megoldása is ilyen, de számos további gyártó (általában a nagyok, vetélytársak) is ilyen megoldásokkal rukkolnak elõ.

A CA CMDB megoldása véleményem szerint azért emelkedik ki az összes többi közül, mert e megoldás minden különösebb probléma nélkül, már dobozos korában sincs meg Service Desk nélkül. Nem integrálni kell, nem külön termék, hanem azzal teljesen egyé vált valami, olyan mint a Windows Explorere, amit hiába akarnak kihagyni belõle, igazából nem lehet a két dolgot szétválasztani.

Nos akkor lássunk hozzá. Elsõre nekiállva a telepítés vár ránk. A CA megoldása ebbõl a szempontból nagyon szépen kivitelezett valami, mert bár összetett rendszer nagyon szépen felköltözik és “kicsomagol” az adott rendszeren.

Második lépés – Ismerkedjünk a rendszerrel

A frissiben telepített rendszer nem alkalmas azonnal a mûködésre, elõször még fel kell töltenünk a szükséges információkkal. Annak érdekében, hogy ezt a lehetõ legjobban tegyük szükségünk van a rendszerrõl némi ismeretre és egy vagy több szakértõ segítségére. Ez utóbbi nem kötelezõ, de számos felesleges kört és idõkidobást tud megspórolni, ha segít. Számos olyan rendszert látni, amin azonnal látszik az elõzetes mély ismeretek hiányából fakadó rossz úton való elindulás, amit késõbb már nehéz, vagy egyáltalán nem lehet korrigálni.

Szóval, nézzegessük és ismerkedjünk a rendszerrel, a kapott dokumentációkkal. Gondolkodjunk el mit is akarunk beletenni a rendszerbe és azt miképp szeretnénk felhasználni! Ezek nélkül a késõbbi tervezéskor, adatfeltöltéskor sokkal nehezebb lesz kitalálni mit is szerethetnénk.

Folytatás

A következõ részben elmesélem miképp lehet a CI-ket összeszedni úgy, hogy azok ne csak egy nagy kupacot, hanem használható adatokat, információkat jelentsenek.

Nekikezdtem és összeállítottam mindazt amit most e pillanatban a Service Desk és Knowledge Tools termék kapcsán a CA most megosztott velem. Az anyag eleje – 2-5 slide – a Service Management termékvonal kapcsán még szóbakerülõ termékekkel is foglalkozik, de aztán belecsapok az SD és az SDKT rejtelmeibe. A bemutató igencsak sûrû és megpróbáltam csak az újdonságokkal és a lényeges változásokkal foglalkozni, de így is 48 slide állt össze, azaz a magyarázatok és a kérdések függvényében 1,5 – 2 óra terjedelmû bemutató lett belõle.

Service Desk & Knowledge Tools r12

Azt alapvetõen kijelenthetem, hogy a CA mostani termékfejlesztése valóban a napi gyakorlatban felmerült kérdésekre és problémákra ad választ. Az elõadások alatt láthattuk a már mûködõ Alfa verziót – ami néhány megállástól eltekintve – valóban impozáns és nagyratörõ szolgáltatásokat mutatott. Mik is az új extrák? Nézzük csak!

CMDB r11.2

  • Fejlesztett megjelenítés
  • Kibõvített platformok

Service Desk r12

  • Role Based UI
  • Web Based Reporting
  • Egyszerüsített Multi-Tenant megoldás

Knowledge Tools r12

  • Fórumok
  • Keresés csatolmányokban

Support Bridge r12

  • Mélyebb Service Desk Integráció
  • Újratervezett UI

Sajnos ennél több jelenleg még nem publikálható, de a Service Desk és a Knowledge Tools r12 Beta tesztelõknek is elérhetõ változata 2008 áprilisára várható, már csak addig kell várni…

Egyéb kérdések, érdekességek

Az új eljárási logika tovább folytatódik, aminek keretében évente egyszer jelenik meg a termékek „New Features” bõvített változata. Negyedévente jelenik meg az úgynevezett „Maintenace Patch”, és tovább folytatódik a „Cummulative Patch” kiadása. Mindez miért? Azért, mert így – s ez az elmúlt idõszakban már érezhetõ volt – fokozottan ellenõrzött minõségû kód kerül csak kiadásra, megelõzve a javítások javításának kiadását (hát volt biza régebben ilyennel is gond).

Másik fontos és számomra is lényeges információ, hogy az újabb verziók nem lesznek elérhetõek Ingress-en (sõt végre a fejlesztések sem ezen történnek).

A fejlesztések során egységes platformra hozzák e termékvonal valamennyi elemét, ennek keretében egységesen TomCat szervert és Java Aplet alapú megoldásokat használnak a szerver oldalon. Egységes DB létrehozása és alkalmazása (ebben az esetben MS SQL és Oracle támogatással lehet számolni).

Érdekes információ volt, hogy a CA Workflow nem mindenhol lesz továbbra sem alkalmazható! Ilyen kivétel a jelenleg a termékvonalból kilógó CA Change Manager. E termék teljes egészében JAVA alapú webes alkalmazás (!), és saját egyéni workflow motort használ… Wink

CA Europe HQ, LondonMa kezdtem egy érdekes konferenciát Londonban a CA Europe, Middle East and Africa HQ-nál (a képen a CA központi épülete Ditton Manor-ban, de ez az egész hely egy külön misét – akarom mondani – blog bejegyzést is megér a késõbbiekben). Két napig arról fogok elõadásokat hallgatni (az én szekciómban), hogy a Service Management folyamatokat miképp értelmezi, látja a CA és milyen termékekkel kívánja ezeket kiszolgálni.

Az alap logika szerint itt a Service Desk-rõl, a CMDB-rõl lesz elsõsorban szó, de minden kapcsolódó érdekesség már kiadott és még csak fejlesztés alatt álló termékek és szolgáltatásaik is a porondon lesznek. A párhuzamos szekciók természetesen a CA termékpaletta egyéb ágait is teljes egészében kezelik, de idõ és az osztódási képesség hiányában én csak ezen irányvonallal fogok foglalkozni. Az eredményekrõl és egyéb infókról a késõbbiekben természetesen beszámolok.
(Annyi azért kiderült a kezdeti key note hallgatása alapján, hogy valódi információcsere és érdekes elõadások elé nézünk… Big Grin)