SCSM "workflow" kontra SCO "workflow/runbook"

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

• Lehet-e Service Manager workflow-val felhasználókat létrehozni (vagy valami hasonló infra közeli muveletet 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, eloszö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, elore megadott kiváltó tényezo 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 alapveto 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" szintu, IT végrehajtás közeli folyamatok leképzésére született, melynek fobb jellemzoi:
  • kevés, tényszeru beviteli adat és általában nem "end-user"-ektol 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éro 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" szintu, IT szolgáltatás közeli folyamatok leképzésére született, melyek általában:
  • több, igény jellegu beviteli adat gyakran az end-usertol vagy folyamat állapotok által kiváltva
  • folyamat közben gyakori akár a többlépcsos humán interakció: jóváhagyások (a fonök elfogadja az igényt), végrehajtási lépések (a technikus odamegy az eszközhöz és ellenoriz 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égezheto 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 életszeru példát, ahol a fentiek "helyükre találhatnak": szeretnénk megoldani, hogy egy új munkatárs belépésénél az o munkáját lehetové tevo, 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övetkezo ábrán szeretném szemléltetni a leegyszerusí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ülso rendszerek kerültek jelölésre (a folyamat lefutása fentrol 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 elonyösebb választás lehet az az, hogy a Sharepoint alapú megoldásban elore 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ésobbi blog postban részletezem) megoldás dinamikusan épülo web-formokon tudja az adatokat bekérni (újabb mezo felvétele, mezonevek változtatása egyszeru). 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) lehetoséget is adhat / fejleszheto rá jóváhagyási folyamat. A Service Manager ehhez szabványos, többszereplos, naplózott és kontrollált (SLA)végrehajtást, több interfészes visszajelzési lehetosé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-bol közvetlenül hívhatóak, címezhetoek 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övetkezo kérdésekre és válaszokra jutnánk:

• Hogyan mukö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 begyujteni (az utóbbi komoly biztonsági kockázat így elvetheto), 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 mukö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 hibaturé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