ITÉlet

Mi történik azután, hogy a felhasználó bejelentett egy problémát?

Mi történik azután, hogy a felhasználó bejelentett egy problémát?

A Corporate IT sorozat 4. része (korábbi postok 1. rész, 2. rész és 3. rész) betekintést enged abba, mi történik a hibabejelentés során.

A védelem első vonalát a helyi rendszergazdák jelentik. Triviális problémákat le tudnak kezelni, rá tudnak nézni a felhasználó számítógépére.

Mint szó volt róla, minden centralizált multinak van 24/7 központi helpdesk-e, vagy egy központosított hibabejelentő rendszere. A központi helpdesk képes megoldani alapvető hibákat (pl. elfelejtett jelszó). Amennyiben a probléma bonyolultabb, úgy belekerül a ticketing rendszerbe, meghatározzák a prioritást (mennyi égető a probléma), illetve a leírás alapján hol lehet a hiba, és ezzel rögtön el is postázódik a megfelelő csapathoz.

Már említettem, hogy csak a főbb szoftverekből van úgy kb 150 darab, tehát támogató csapatból is akad olyan 100. Központi Helpdesk-ből van 1 darab, és ők passzolják a ticket-et a megfelelő helyre, illetve végzik az előzetes bekategorizálást.

A támogató csapatok 8/5 dolgoznak, illetve vészhelyzet esetén on-call elérhetők. Elvileg minden csapatban van valaki, aki fél szemét a ticketing rendszeren tartja, és minden bejövő hibajegyre rápillant. (Legtöbbször itt lassul le a folyamat – a szakember elsőre nem érti a hibát, nem ér rá, vagy nem fogja fel a súlyosságát)

Ha a probléma mégsem ide tartozik, akkor emberünk tovább pattintja a megfelelő csapathoz. Például lassú a szoftver, elsőre a bejelentés a szoftvereseknél landol, akik viszont továbbküldik a szervert felügyelő rendszergazdának – legyen szíves nézze meg, minden rendben van-e a szerverrel.

Ha a probléma egyszerű, akkor emberünk megpróbálja megoldani. Ha bonyolult, akkor a csapat idősebb tagjainak továbbítja, akik szükség esetén újabb szakértőket vonnak be – egészen addig, amíg el nem jutunk az alkalomhoz szükséges legjobb szakértőig.

A folyamat ugyanúgy működik ha in-house vagy ha vendor supported szoftverről van szó.

A reakcióidőket és a nyújtandó támogatás szintjét SLA megállapodás rögzíti, azaz a csapatnak adott időn belül meg kell kezdenie a munkát és adott időn belül be is kell fejeznie azt.
Globális támogatás esetén figyelembe kell venni a támogatott időzónákat, tehát a csapat nem 8/5-ben hanem mondjuk 12/5-ben dolgozik. (pl. nem fordulhat elő az, hogy az orosz felhasználó nem kap segítséget, mert az angol mérnök már hazament)

Amennyiben egy magyar fejlesztő csapat nyújt támogatást egy multinak, akkor a támogatási szerződésük a nagyjából a következőket fogja tartalmazni:
- Kommunikációs módok, azaz ki milyen email címeken/telefonszámokon érhető el, hova és hogyan lehet bejelentést tenni, ki jelenthet be hibát
- A felhasználók nem direktben fogják hívogatni a fejlesztőket, hanem egy belső helpdesk-en  keresztül. Ezt elrendezni a multi felelőssége.
- A fejlesztő cég munkanapokon mettől meddig áll rendelkezésre, és hogy mit értünk munkanap alatt (pl. augusztus 20-án a magyar fejlesztő szabadságon van, a szlovák, francia, angol és japán felhasználók viszont nem)
- Kommunikáció nyelve angol – fordítást a multi Helpdesk-e végez
- SLA, reakcióidők (munka megkezdésére, munka befejezésére)
- Reporting
- Eszkalációs folyamat
- Megengedett hibalehetőség, büntetés
- Mi a teendő munkaidőn kívüli munkavégzés esetén (pl mennyibe kerül)

A ticketing rendszernek hála a felhasználó „rálát” a bejelentésére, tudja hol kinél jár és milyen státuszban van.

A globális támogatás egyik sajátossága, hogy ha a problémánk nem súlyos, akkor jó eséllyel csak másnapra lesz kész.

Mi a teendő, ha a hiba nem hárult el, nem halad, vagy a helyzet súlyosbodik? Egyrészt rá lehet kérdezni a központi Helpdesk-nél vagy a kijelölt csapatnál, hogy mi a helyzet. Másrészt lehet eszkalálni a kijelölt csapat vezetőjéhez.

Mit tegyünk, ha a szoftvert az egész világon használják? Álljunk-e napi 24 órában készenlétben?
Nem feltétlenül. Szükség van egy napi 24 órában elérhető Helpdesk-re, de erre megteszi a multi központi helpdesk-e is. A fejlesztő csapat csak kiemelt esetben ad 24 órás support-ot, az esetek többségében elég a napi 8 órás munka. A hibabejelentések összegyűlnek az éjszaka folyamán, és majd reggel kijavítjuk őket. Ezzel együtt persze szükség van ügyeletre/ügyeletesre, felkészülve a váratlan eseményekre.
Azon elv mentén kell dolgozni, hogy a szoftver átadás előtt alaposan le lett tesztelve, a szakértők kellően sokat hümmögtek és vitatkoztak, mire engedélyezték az átadást. Tehát nem lesznek rendszeresen súlyos problémák, nem kell nap mint nap tüzet oltani. Ami lesz, azt pedig le lehet kezelni másnap reggel.

Mi a teendő katasztrofális rendszerleállás/adatvesztés esetén?
Ennek az eshetősége rendkívül csekély, hiszen
a) A szoftvereket alaposan leteszteltük, mielőtt átadtuk
b) Az éles rendszerekhez a rendszergazdán kívül más nem igazán fér hozzá, tehát nem fognak belenyúlkálni

Ha mégis adódik valami (az ördög nem alszik), akkor csak elővesszük a napi mentést, és szépen mindent visszaállítunk.

Nyelvi és kulturális problémák: az üzlet hivatalos nyelve az angol. Support korra, nemre, származásra való tekintet nélkül mindenkinek jár.

Hogyan tud a támogató csapat további információt gyűjteni a bejelentett eseményről:
- Felhívják a felhasználót
- Megkérik a szerver rendszergazdáját, nézzen meg azt vagy azt
- Esetleg szólnak a DBA-nak
- Megnézik a log-okat
- Vagy a hálózati statisztikákat

Ami nem szokott működni:
- Direktben éles rendszerben matatni
- Külső cég számára nem elérhető a felhasználó desktop-ja