Szeretném leírni pár gondolatomat a fenti témával kapcsolatosan, mivel rendszeresen beleakadok a napi munkám során a következő tipuskérdésekbe:

  • Lehet-e Service Manager workflow-val felhasználókat létrehozni (vagy valami hasonló infra közeli műveletet végezni) vagy arra Orcehstrator "workflow" kell-e?
  • Hogyan lehet az Orchestrator workflow-k adatait felhasználóktól (nem IT admin) bekérni?
  • Mi a különbség az SCSM és az SCO workflow (jobb esetben SCO runbook kifejezés hangzik el) között?

Nos, először is a terminológia: az SCSM rendszerben a helyes kifejezés a wokflow, az SCO rendszerben pedig a runbook. A képet két tény bonyolítja, kavarja meg:

  • egyrészt a lényeget nézve mindkét esetben nagyon hasonló a nevezett funkcionalitás: adott beviteli adatok megkapása vagy valamely, előre megadott kiváltó tényező hatására a rendszer egy adott (esetlegesen elágazásokat, feltételes végrehajtást, párhuzamos tevékenységeket stb...) lépéssorozaton megy keresztül
  • másrészt az SCSM rendszerbe Orchestrator connector-on keresztül bekerülhetnek az SCSM runbook-ok is

De akkor próbáljunk kicsit rendet tenni a terminológián túl: bár sokmindenben hasonlítanak, az alapvető céljuk más - amely meghatározza a képességeik és megközelítéseik különbségeit:

  • a runbook (SCO "workflow") tipikusan a "gépház" szintű, IT végrehajtás közeli folyamatok leképzésére született, melynek főbb jellemzői:
    • kevés, tényszerű beviteli adat és általában nem "end-user"-ektől vagy rendszer-közeli eseméyek által kiváltva
    • folyamat közben humán interakció hiánya: nem tipikus a jóváhagyási vagy újabb adatokat bekérő kommunikáció, mivel a rendszer sem felhasználói felületileg, sem vezérlés kontrol elven nincs erre felkészülve
    • a folyamat vége általában a konkrét végrehajtás (pl. felhasználó létrehozva, jogosultság beállítva, stb...)
  • a workflow (SCSM) tipikusan "üzleti" szintű, IT szolgáltatás közeli folyamatok leképzésére született, melyek általában:
    • több, igény jellegű beviteli adat gyakran az end-usertől vagy folyamat állapotok által kiváltva
    • folyamat közben gyakori akár a többlépcsős humán interakció: jóváhagyások (a főnök elfogadja az igényt), végrehajtási lépések (a technikus odamegy az eszközhöz és ellenőriz valamit), melynek okán a rendszer biztosítja ezen interakciók felületét (Self-Service web-alapú portál)
    • a folyamat vége bár itt is általában a konkrét végrehajtás, valójában a workflow szempontjából a közvetlenül kontrollált tevékenység vége a jóváhagyott, felparaméterezett, IT számára elvégezhető folyamat
    • (A teljességhez hozzátartozik, hogy az SCSM rendszerben a workflow-n kívül léteznek egyéb workflow típusú folyamatok, melyeket az adott Work Item-ek (Indicens, Change) activity lapjain vagy sablonjaiban lehet beállítani - ám a fent felsorolt karakterisztikák ezekre is igazak)

Nézzünk egy életszerű példát, ahol a fentiek "helyükre találhatnak": szeretnénk megoldani, hogy egy új munkatárs belépésénél az ő munkáját lehetővé tevő, inicializáló feladatok (felhasználó létrehozása, adott csoportokhoz adása (ezáltal jogosultságkörök megkapása), mailbox létrehozása, stb..) kerüljenek végrehajtásra. A következő ábrán szeretném szemléltetni a leegyszerűsített folyamatot és a komponensek helyét:

 

A képen narancssárgával az SCSM, lilával az SCO, szürkével pedig a külső rendszerek kerültek jelölésre (a folyamat lefutása fentről lefelé történik).

Természetesen ez csak egy példa - ennél kevesebb réteg és komponens segítségével is megvalósítható a folyamat, pár példa:

  • Készíthet valaki saját felületet, weblapot a felhasználói interakcióra, a folyamat indítására és az adatok bekérésére. Amiért a Service Manager Self-Service Portal-ja előnyösebb választás lehet az az, hogy a Sharepoint alapú megoldásban előre ki van alakítva az a keret, mely az IT szolgáltatás katalógusának nyilvános részét struktúráltan jeleníti meg a felhasználó felé, valamint az a képesség, hogy a Service Request / Request offering (későbbi blog postban részletezem) megoldás dinamikusan épülő web-formokon tudja az adatokat bekérni (újabb mező felvétele, mezőnevek változtatása egyszerű). Ráadásul mindezt szerepkör alapú jogosultság rendszerrel képes megtenni, azaz a felhasználói csoportoknak célzottan tudunk adott funkciükat kiajánlani
  • A saját felület vagy más technológia (pl. Sharepoint) lehetőséget is adhat / fejleszhető rá jóváhagyási folyamat. A Service Manager ehhez szabványos, többszereplős, naplózott és kontrollált (SLA)végrehajtást, több interfészes visszajelzési lehetőséget (portal, email) és dinamikus - aktuális adatokat tartalmazó CMDB-t tud hozzáadni. Ezen felül pedig azt a képességet is, hogy az Orchestrator Runbook-ok importálhatók, és a Workflow részeként kontrolláltan, direktben hívhatók
  • Akár a saját, akár más workflow engine-ből közvetlenül hívhatóak, címezhetőek lehetnének az IT rendszerek (szkriptek, stb.) Az Orchestrator ehhez redundáns környezetet, grafikus runbook tervezést és követést, többpéldányú futás kezelést, valamint interfész alapú csatlakozást biztosíthat mind "felfelé" / fogadó oldal felé (tipikusan Service Desk rendszerek) mind pedig "lefelé" / végrehajtási oldal felé (AD, Exhange Integration Pack)

Ha az eredeti témafelvetést ezen példán keresztül tekintenénk át, eljátszva a gondolattal, hogy felcseréljük az SCSM "workflow"-k és az SCO "runbook" rétegeket, a következő kérdésekre és válaszokra jutnánk:

  • Hogyan működne az SCO Runbook, mint "frontális" végfelhasználói interfész: nem lenne struktúrált weblap, az adatokat egyedi fejlesztésen vagy az Operator konzolon kellene begyűjteni (az utóbbi komoly biztonsági kockázat így elvethető), bár lehetne jóváhagyásokat és adatbekéréseket végrehajtani, azonban a válaszokra várás valamint a válasz feldolgozására egyedi megoldást kellene beüzemelni. Ezen felül nem lennének CMDB adatok, így azon végfelhasználói adatbekérések, ahol pl. adott szolgáltatást vagy eszközöket akarnánk kiválaszhtaó módon azonosítani egy igen nagy kihívás lenne.
  • Hogyan működne az SCSM Workflow, mint "frontális" végrehajtási interfész: itt talán kicsit jobb lenne a helyzet, de minden interfészt, szkriptet az IT rendszerek felé egyedileg kellene lefejleszteni, az éppen futó végrehajtási szálak követése sokkal bonyolultabb: vizualizálás, teljesítmény és hibatűrés szempontjából nem lenne optimális a dolog, az SCSM hardverigénye pedig az SCO fölött van, melyet fölöslegesen "pazarolnánk" el.

 

 V