Pràctiques ITIL v4 de suport al servei

Elaboració pròpia: la font és de pagament i no es reprodueix

Enunciat oficial. Pràctiques ITIL v4 de suport al servei: gestió d'incidents, problemes i sol·licituds de servei.

1. Els quatre conceptes que no s'han de barrejar

ITIL (Information Technology Infrastructure Library) defineix quatre conceptes de suport al servei que no s'han de confondre entre si:

Regla d'or: la gestió d'incidents restaura, la gestió de problemes investiga. Un incident es pot tancar sense conèixer-ne la causa; el problema es manté obert fins que es troba.

2. Gestió d'esdeveniments (monitoring and event management)

Propòsit: observar sistemàticament els serveis i els components del servei, i registrar i informar dels canvis d'estat identificats com a esdeveniments, identificant i prioritzant els d'infraestructura, servei, procés de negoci i seguretat de la informació, i establint la resposta adequada.

Tres tipus d'esdeveniment:

• Informatiu: no requereix acció; es registra per a auditoria o estadística (un lot que acaba correctament, un usuari que es connecta).
• Advertència (warning): un llindar s'apropa al límit; permet actuar abans que hi hagi impacte (disc al 80 %).
• Excepció (exception): s'ha vulnerat un llindar o s'ha produït una fallida; normalment genera un incident.

Monitoratge i gestió d'esdeveniments no són sinònims: el monitoratge comprova l'estat d'un component encara que no es produeixi cap esdeveniment —per exemple, verificar que un servidor respon dins del llindar acceptable—; la gestió d'esdeveniments és la que genera i detecta les notificacions significatives sobre aquest estat i en decideix la resposta.

Dos eixos del monitoratge, independents l'un de l'altre:

• Actiu vs. passiu (com es capta la dada): actiu, el sistema consulta periòdicament l'estat dels elements (polling) i fa proves sintètiques; passiu, els elements envien els seus esdeveniments a la consola (traps SNMP, syslog, agents) i el sistema els correlaciona.
• Reactiu vs. proactiu (per a què serveix): reactiu és el monitoratge dissenyat per sol·licitar o provocar una acció després d'un determinat tipus d'esdeveniment o fallida ja produïts —per exemple, reiniciar automàticament un dispositiu quan deixa de respondre—; proactiu busca patrons en una sèrie d'esdeveniments per anticipar-se a una fallada futura i actuar abans que es produeixi.

Un monitoratge pot ser alhora actiu i reactiu, o passiu i proactiu: els dos eixos es combinen lliurement, no en formen un de sol.

Correlació: motor que agrupa esdeveniments relacionats, elimina duplicats i decideix quan crear un incident. Sense correlació, una caiguda genera centenars d'alarmes.

SNMP (Simple Network Management Protocol): el protocol que fa possible el monitoratge passiu — els agents envien esdeveniments (traps) al gestor, l'NMS (Network Management System), que els interpreta contra la MIB (Management Information Base) de cada dispositiu. SNMPv3 hi afegeix autenticació i xifratge, absents a les versions 1 i 2c, que només tenen community strings en clar. El detall del protocol —gestor, agent, MIB i notificacions— el desenvolupa la plataforma d'observabilitat..

3. Gestió d'incidents

Propòsit: minimitzar l'impacte negatiu dels incidents restaurant l'operació normal del servei al més aviat possible.

3.1 Cicle de vida

Detecció → registre → categorització → priorització → diagnòstic inicial → escalat (si cal) → investigació i diagnòstic → resolució i recuperació → tancament.

• Registre: tots els incidents s'han de registrar, també els resolts al primer contacte i els detectats per monitoratge.
• Categorització: permet dirigir l'incident i, després, analitzar tendències; l'esquema de categories ha de ser compartit amb la gestió de problemes, perquè totes dues pràctiques treballin sobre les mateixes dades a l'hora de buscar patrons.
• Priorització: prioritat = impacte × urgència. L'impacte és l'abast del dany (nombre d'usuaris, criticitat del servei, pèrdua econòmica, reputació); la urgència és la rapidesa amb què el negoci necessita la resolució. La matriu típica és de 3×3 o 5×5 i dona prioritats de 1 (crítica) a 5 (planificació).
• Escalat: funcional (a un grup amb més coneixement tècnic — nivell 2, nivell 3, proveïdor) i jeràrquic (a la línia de comandament, per manca de recursos o per la gravetat). No són alternatius: sovint es fan tots dos.
• Model d'incident: procediment predefinit per a tipus d'incident coneguts i recurrents.
• Solució temporal (workaround): mitjà per reduir o eliminar l'impacte d'un incident sense resoldre'n la causa. Es documenta al registre d'errors coneguts.
• Tancament: només amb confirmació de l'usuari que el servei està restaurat, i amb la categorització i la solució documentades.

3.2 Incidents que afecten múltiples serveis i usuaris

La bona pràctica davant un incident d'alt impacte (incident major):

1. Declarar-lo formalment com a incident major i activar el procediment específic.
2. Assignar un gestor d'incident major i un equip dedicat, separat del flux ordinari.
3. Convocar una sala de crisi (war room) amb els especialistes necessaris.
4. Comunicar proactivament a usuaris i interessats: què passa, què n'està afectat, quina és l'estimació i quan hi haurà la propera actualització. La comunicació és periòdica i pautada, no a demanda.
5. Restaurar el servei com a prioritat absoluta, encara que sigui amb un workaround.
6. Registrar un problema associat per investigar la causa arrel després de la restauració.
7. Revisió post-incident (post-incident review) sense buscar culpables (blameless), amb accions de millora.

La resposta correcta a l'examen combina coordinació centralitzada, comunicació proactiva i restauració prioritària, obrint un problema per a la causa. Les distractores solen proposar tractar-lo com un incident ordinari, o aturar la restauració fins a trobar la causa — que és exactament el que no s'ha de fer.

3.3 Mètriques

Pròpies de la gestió d'incidents: MTTA (Mean Time To Acknowledge, temps mitjà d'acceptació — quant triga a agafar-se la incidència), MTBF (Mean Time Between Failures, temps mitjà entre fallides — la fiabilitat d'un component) i MTBSI (Mean Time Between Service Incidents, temps mitjà entre incidents de servei — si les fallides s'acumulen o s'espaien). La resta —FCR (First Contact Resolution), compliment de l'SLA (Service Level Agreement, acord de nivell de servei), incidents reoberts, backlog— són les mateixes mètriques del Service Desk (tema 25).

4. Gestió de problemes

Propòsit: reduir la probabilitat i l'impacte dels incidents identificant-ne les causes reals i potencials i gestionant els workarounds i els errors coneguts.

4.1 Les tres fases

1. Identificació del problema: anàlisi de tendències d'incidents, detecció de problemes recurrents, informació dels proveïdors, anàlisi d'incidents majors.
2. Control del problema: anàlisi del problema per determinar-ne la causa arrel i documentar solucions temporals i errors coneguts. Un error conegut és un problema que ha estat analitzat però no resolt: no és el mateix que el workaround —el workaround és l'acció que redueix l'impacte; l'error conegut és l'estat del problema, ja diagnosticat, que aquell workaround documenta. Pot haver-hi workaround sense diagnòstic (davant un incident aïllat); no hi ha error conegut sense diagnòstic.
3. Control de l'error: gestionar els errors coneguts, reavaluar-ne l'impacte i, quan es justifiqui, promoure una sol·licitud de canvi per a la solució definitiva.

4.2 Reactiva i proactiva

• Gestió de problemes reactiva: parteix d'incidents ja ocorreguts.
• Gestió de problemes proactiva: analitza dades i tendències per evitar incidents futurs. És on hi ha el valor real de la pràctica.

Un cop adreçada l'obertura de problemes amb un procediment clar —equips formats i eines adaptades als nous procediments—, el pas que cal abordar és implementar-lo de manera regular: analitzar les incidències i problemes per identificar tendències, no aturar-se ni parlar encara de la imputació de costos, que és prematur. És l'efecte esperat de fer-ho bé: un cop redreçada la situació, fent-ne el seguiment corresponent, el nombre d'incidències repetitives es reduirà.

4.3 Tècniques d'anàlisi de causa arrel

No totes serveixen per al mateix cas: els cinc perquès funcionen quan la cadena de causes és lineal i cal arribar-hi de pressa; el diagrama d'Ishikawa (espina de peix), quan les causes possibles s'agrupen per categories (persones, procés, tecnologia...); l'anàlisi de Pareto, quan cal prioritzar entre moltes causes candidates i atacar primer les que més pesen; i l'aïllament per bisecció, quan el sistema es pot dividir per parts i descartar-ne la meitat a cada pas. Menys freqüents: l'anàlisi cronològica, la de Kepner-Tregoe, l'FTA (Fault Tree Analysis, arbre de fallides) i l'FMEA (Failure Mode and Effects Analysis, anàlisi de modes de fallida i efectes).

Davant d'incidències recurrents, la pràctica correcta és obrir un problema i fer anàlisi de causa arrel, no seguir resolent els incidents un per un. Aquesta és la pregunta literal de l'examen.

Relació amb la gestió del coneixement: cada workaround i cada error conegut alimenta la KEDB (Known Error Database, base de dades d'errors coneguts) i el SKMS (Service Knowledge Management System, sistema de gestió del coneixement), i redueix el temps de resolució dels incidents futurs.

5. Gestió de peticions de servei

Propòsit: donar suport a la qualitat acordada del servei gestionant totes les peticions de servei predefinides i iniciades per l'usuari d'una manera efectiva i amable.

Característiques:

• Les peticions són part de la prestació normal del servei: no són incidents, no hi ha degradació.
• Han d'estar estandarditzades i automatitzades tant com sigui possible, amb fluxos de treball predefinits i, si escau, aprovacions i autoritzacions.
• Es publiquen al catàleg de serveis amb els seus temps de lliurament compromesos.
• Es beneficien de l'autoservei: portal amb formularis, aprovació automàtica i provisió automatitzada.
• Exemples: alta d'usuari, sol·licitud d'accés, petició d'un equip, instal·lació d'un programari estàndard, canvi de contrasenya, sol·licitud d'informació, reserva d'una sala.

Peticions vs canvis estàndard: el que l'usuari viu com una petició de servei, per dins pot tramitar-se com un canvi estàndard —preautoritzat, de risc baix— si toca un element de configuració (instal·lar programari, obrir un port); si no en toca cap (una consulta, una reserva), es queda en petició. El detall dels tipus de canvi és al tema 19.

6. Model integrat de suport

Nivells de suport: nivell 1 (Service Desk, resolució al primer contacte), nivell 2 (especialistes per àmbit), nivell 3 (experts, desenvolupament, arquitectura) i nivell 4 (proveïdors i fabricants). El Service Desk manté la titularitat de l'incident encara que l'escali: és el responsable davant l'usuari fins al tancament. → tema 25.

Gestió del coneixement: la pràctica que manté i millora l'ús efectiu, eficient i convenient de la informació i el coneixement a tota l'organització. SKMS i KEDB en són els repositoris.

Front a una fusió de departaments —dos edificis o organitzacions que s'integren—, la bona pràctica és centralitzar, no duplicar: establir un únic Service Desk sota un únic responsable, i nomenar un únic responsable tècnic central per als equips de Suport Tècnic dels dos edificis, en lloc de mantenir estructures separades per ubicació o externalitzar-ho tot per evitar la complexitat.

Per sostenir una operació 24×7, cal també assignar responsables de torn que es facin càrrec de la cobertura contínua a cada franja horària —no n'hi ha prou amb centralitzar la titularitat si ningú respon fora d'horari—. És un canvi organitzatiu diferent d'acotar un rol a la integració puntual (un gestor de problemes només per als incidents de la fusió) o de traslladar la responsabilitat operativa fora de l'equip (superusuaris externs, o canviar de marc de treball sencer per un problema puntual d'organització).

7. L'Operació del Servei: fase en ITIL v3, sense fase en ITIL v4

7.1 El domini de l'Operació del Servei (ITIL v3)

ITIL v3 organitza la gestió del servei, com a metodologia, en cinc fases del cicle de vida: Estratègia, Disseny, Transició, Operació i Millora Contínua del Servei. Cada un dels processos pertany a una fase concreta, i en aquest context és fonamental saber a quina: la gestió d'esdeveniments, la gestió d'incidents, la gestió de problemes i la gestió de peticions —el domini d'aquest tema— juga el seu paper dins l'Operació del Servei, la fase que s'encarrega d'implementar i operar el servei ja en producció, dia a dia. La gestió de la disponibilitat i de la capacitat pertanyen a Disseny del Servei perquè es planifiquen abans de posar-se en marxa (→ tema 21), i la gestió del canvi i de versions pertanyen a Transició del Servei (→ tema 19).

ITIL v4 no té fases: la metodologia les substitueix per un conjunt de pràctiques que s'activen des de qualsevol punt de la cadena de valor del servei (SVC, Service Value Chain), sense estar lligades a una seqüència fixa. Per això el títol d'aquest tema parla de «pràctiques» i no de «processos de l'Operació del Servei»: és la nomenclatura v4. → tema 17.

7.2 Equilibris de l'Operació del Servei

L'Operació del Servei (ITIL v3) manté quatre tensions en equilibri constant:

• Visió interna de TI vs. visió externa de negoci: gestionar bé els components tecnològics no és el mateix que gestionar el servei que aquests fan possible.
• Estabilitat vs. capacitat de resposta: canviar el servei quan el negoci ho demana sense perdre'n la fiabilitat.
• Qualitat del servei vs. cost del servei: més qualitat sol implicar més cost; cal el nivell acordat, no el màxim possible.
• Reactiu vs. proactiu: reaccionar davant els incidents i, alhora, anticipar-se'ls.

8. Gestió d'accessos

Propòsit (ITIL v3): concedir als usuaris autoritzats el dret a utilitzar un servei, alhora que se n'impedeix l'accés als usuaris no autoritzats. Executa, no defineix, les polítiques que marca la gestió de la seguretat de la informació.

Les seves activitats pròpies són verificar la identitat de qui sol·licita l'accés i concedir els drets que li corresponen segons el rol autoritzat —la sol·licitud arriba normalment via la gestió de peticions de servei. El que no li pertoca: definir les polítiques de seguretat (és gestió de la seguretat de la informació, que la gestió d'accessos només executa) ni monitorar la disponibilitat dels sistemes (és gestió de la disponibilitat). El detall de l'autenticació, l'autorització i els seus protocols és al tema 64.

Claus d'examen

• Actiu/passiu (com es capta la dada) i reactiu/proactiu (per a què serveix) són eixos independents del monitoratge: la descripció «dissenyat per sol·licitar o provocar una acció després d'un esdeveniment» és reactiu, no proactiu (TS-TIC 2023 específic, p. 33).
• Monitoratge ≠ gestió d'esdeveniments: el monitoratge també vigila quan no hi ha esdeveniment; la gestió d'esdeveniments és la que genera i detecta les notificacions significatives (TS-TIC 2023 pràctica, p. 14).
• L'equilibri de l'Operació del Servei combina qualitat de servei acordada i requisits canviants de negoci i tecnologia: no és un únic parell aïllat, sinó els quatre equilibris junts (TS-TIC 2018 pràctica, p. 22).
• L'objectiu de la gestió d'incidents és restaurar; el de la gestió de problemes és eliminar la causa i prevenir, no la rapidesa. Per això, davant incidències recurrents, la resposta correcta és sempre obrir un problema i fer anàlisi de causa arrel, mai seguir resolent-les una a una (TM-TIC 2021-OP pràctica, p. 7-9, p. 26 i p. 30).
• Gestió d'accessos: verifica identitat i concedeix permisos; no defineix polítiques de seguretat ni monitora la disponibilitat (TS-TIC 2018 específic, p. 47).
• En un supòsit pràctic, la resposta correcta sol ser la que estabilitza primer, sense prometre xifres taxades: considerant la problemàtica del cas descrit i tenint en compte el marc de referència d'ITIL, el principal problema d'una organització pública no és la percepció interna, sinó l'impacte extern —caigudes en aplicacions crítiques causant un greu perjudici a la imatge d'Operacions i de tot TI en general, que en resta molt baixa—; i, com a responsable d'Operacions, cal focalitzar i centrar-se en els aspectes operacionals, que és la teva responsabilitat en aquell moment, no ampliar infraestructura sense diagnosticar-ne abans la causa (TS-TIC 2018 pràctica, p. 1 i p. 2).

Per recordar

• Incident = interrupció o degradació no planificada; problema = causa d'un o més incidents; error conegut = problema analitzat però no resolt; workaround = redueix l'impacte sense resoldre la causa.
• Prioritat = impacte × urgència.
• Escalat funcional (més coneixement tècnic) vs escalat jeràrquic (línia de comandament).
• Davant un incident major: coordinació centralitzada, comunicació proactiva i periòdica, restaurar primer (fins i tot amb workaround) i obrir un problema per a la causa.
• Davant incidències recurrents: gestió de problemes i anàlisi de causa arrel.
• Tres tipus d'esdeveniment: informatiu, advertència i excepció (la que genera incident).
• Monitoratge actiu = consulta (polling); passiu = rep esdeveniments. Reactiu = actua després de l'esdeveniment; proactiu = s'hi anticipa. Són dos eixos independents.
• Les peticions de servei no són incidents: són part de la prestació normal i s'han d'estandarditzar i automatitzar.
• El Service Desk manté la propietat de l'incident encara que l'escali.
• Equilibris de l'Operació del Servei: visió interna/externa, estabilitat/resposta, qualitat/cost i reactiu/proactiu, tots quatre alhora.
• Gestió d'accessos: verifica identitat i concedeix drets; no defineix polítiques de seguretat ni monitora la disponibilitat.