Pràctiques ITIL v4 de lliurament de serveis

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

Enunciat oficial. Pràctiques ITIL v4 de lliurament de serveis: gestió de canvis, versions, actius i configuració (CMDB).

1. Què cobreix aquest tema

L'ITIL (Information Technology Infrastructure Library) és el marc de bones pràctiques de gestió de serveis de TI (Tecnologies de la Informació). El títol diu «lliurament», però els quatre àmbits que enumera —canvis, versions, actius i configuració— són exactament els que l'ITIL v3 agrupava a la fase de transició del servei: el pont entre el disseny i l'operació.

Sonen a lliurament i no són d'aquí: incidents, problemes i peticions, el catàleg i l'SLA, la capacitat i la disponibilitat, la continuïtat, la cadena de valor i la canonada tècnica de desplegament. Aquí es tracta la pràctica de gestió: qui autoritza, què es registra, qui respon.

2. Control de canvis

Propòsit (ITIL 4): maximitzar el nombre de canvis de productes i serveis reeixits assegurant que els riscos s'avaluen adequadament, autoritzant els canvis a procedir i gestionant el calendari de canvis.

Canvi: addició, modificació o eliminació de qualsevol cosa que pugui tenir un efecte directe o indirecte sobre els serveis. A l'ITIL v3 la definició s'enuncia sobre el servei —no sobre el projecte ni sobre el programari— i els canvis poden ser estratègics, tàctics o operatius.

La sol·licitud formal que el dispara és la RFC (Request For Change, petició de canvi): descriu què es vol canviar, per què, amb quin impacte i amb quin pla de retorn. No s'ha de confondre amb la RFC de l'IETF (Internet Engineering Task Force), un document d'estandardització d'internet.

2.1 Els tres tipus de canvi

Un canvi d'emergència no és un canvi sense control: se'n redueix la burocràcia, no la traçabilitat.

El model de canvi és el procediment predefinit per a una categoria de canvis repetitius: passos, ordre, responsabilitats i terminis. Un canvi estàndard és, precisament, un canvi amb model aprovat.

2.2 Autoritat de canvi, CAB i calendari

• Autoritat de canvi (change authority): qui autoritza el canvi. L'ITIL 4 recomana descentralitzar l'autorització segons tipus i risc, per no crear un coll d'ampolla.
• CAB (Change Advisory Board, comitè assessor del canvi): òrgan assessor que ajuda a avaluar, prioritzar i planificar els canvis. No decideix per si mateix: assessora l'autoritat de canvi. Hi participen negoci, desenvolupament, operació, seguretat i proveïdors.
• Calendari de canvis (change schedule): agenda dels canvis aprovats i previstos; serveix per detectar col·lisions i per comunicar-los.
• Períodes de congelació (freeze): finestres on no s'admeten canvis (tancament comptable, eleccions, campanyes crítiques).
• Pla de retorn (back-out plan o rollback): obligatori; un canvi sense pla de retorn no s'hauria d'autoritzar.

2.3 Les set erres del canvi

Per avaluar l'impacte, els beneficis i els riscos d'un canvi, l'ITIL 2011 proposa set preguntes conegudes com les set erres. Cauen tal com estan escrites, en anglès i en aquest ordre:

• Raised: qui presenta el canvi.
• Reason: quina és la raó del canvi.
• Return: quin retorn s'espera del canvi.
• Risks: quins riscos comporta.
• Resources: quins recursos calen per lliurar-lo.
• Responsible: qui és el responsable de construir-lo, provar-lo i implementar-lo.
• Relationships: quina relació té amb altres canvis.

La distractora habitual substitueix la darrera per Report o la tercera per Rejoin. Les set són preguntes prèvies a l'autorització, no informes posteriors.

2.4 Avaluació del canvi i revisió posterior

L'avaluació del canvi és el procés que dona a l'autoritat de canvi un dictamen formal sobre l'efecte previst i real d'un canvi significatiu, contrastant el rendiment previst amb el real.

La PIR (Post Implementation Review, revisió posterior a la implementació) es fa després de desplegar i comprova que el canvi ha assolit l'objectiu i no ha causat efectes col·laterals. Quan el canvi venia justificat per un cas de negoci, el que es torna a mirar en una anàlisi post mortem són els riscos i les contingències que s'hi van declarar: si es van materialitzar i si les contramesures van funcionar. L'abast, els costos i els beneficis es revisen amb la realització de beneficis, no amb l'anàlisi de la fallida. El cas de negoci sencer és a prospecció de solucions.

3. Gestió de versions i desplegament

Definicions que es pregunten literalment i que cal no confondre:

• Versió o release: una o més modificacions d'un servei de TI que es construeixen, es proven i es despleguen conjuntament. És la unitat lògica del que s'entrega: el paquet, el conjunt de components i la seva documentació.
• Desplegament o deployment: el moviment de maquinari, programari, documentació o processos cap a un entorn productiu (o a un entorn de prova). És l'acte tècnic de posar els components allà on han d'anar.

Diferència: la release és què s'allibera —un conjunt coherent de canvis, provats i empaquetats junts, amb la decisió de negoci de posar-los a disposició—; el deployment és com i on s'instal·la tècnicament. Es pot desplegar sense alliberar (desplegar el codi a producció amb la funcionalitat desactivada per feature flag) i es pot alliberar sense desplegar de nou (activar una funcionalitat ja desplegada).

Una diferència de versió entre l'ITIL v3 i l'ITIL 4: la v3 tenia un sol procés, «gestió de versions i desplegaments», dins la transició del servei. L'ITIL 4 el parteix en dues pràctiques separades, amb propòsits diferents:

• Gestió de versions: fer disponibles serveis i funcionalitats, nous o modificats, per al seu ús.
• Gestió del desplegament: moure components de maquinari, programari, documentació, processos o qualsevol altre component nous o modificats als entorns productius.

Aquesta separació és la base del desplegament continu: el desplegament passa a ser un acte tècnic freqüent i de baix risc, i l'alliberament una decisió de negoci independent.

Models de desplegament: big bang (tothom alhora), per fases (phased), continu*, pull (l'usuari se'l baixa quan vol) i push* (l'organització l'empeny). Les estratègies avançades —blau-verd, canari, rolling, A/B— són a DevOps i CI/CD.

Entorns: desenvolupament → integració → proves o QA (Quality Assurance, assegurament de la qualitat) → preproducció (staging) → producció.

Repositoris autoritzats, que cauen com a parella:

• DML (Definitive Media Library, biblioteca definitiva de mitjans): repositori segur de les versions autoritzades de tot el programari i les seves llicències, incloent-hi suports físics i documentació.
• DSL (Definitive Software Library): el nom que rebia a l'ITIL v2, limitat al programari. La DML és la successora i té l'abast més ampli.

3.1 La posada en marxa

Desplegar els components no és posar el servei en marxa. El pla de formació es té a punt abans o durant, mai després: ajornar-lo fins a l'acceptació tècnica de l'equip d'operació —que no és el final de la posada en marxa— és la distractora clàssica. El pla de suport s'executa durant i després (early life support). La documentació de lliurament inclou la funcional, el disseny tècnic, els manuals d'usuari, tècnics i d'administració i el full d'escalats per al servei d'atenció. I la instal·lació «cega» —desplegar a producció sense publicar l'accés, per comprovar configuració i components— és correcta: és el cas concret de «desplegar sense alliberar».

4. Validació i proves del servei

Propòsit (ITIL v3): assegurar que un servei nou o modificat coincideix amb el disseny i satisfà les necessitats del negoci, proporcionant la confiança que una entrega crearà un servei que lliurarà els resultats i el valor esperats dins dels costos i restriccions previstos.

Objectiu del disseny de les proves: desenvolupar models de proves i casos de prova que mesurin els aspectes correctes, per establir si el servei complirà amb el seu ús pretès dins de les restriccions especificades. És a dir, el disseny de proves decideix què s'ha de mesurar, no els límits tècnics d'una màquina ni el nombre de peticions per minut d'una base de dades.

El que NO és propòsit d'aquest procés: registrar els canvis dels actius i elements de configuració al sistema de gestió de la configuració —això és de la gestió de la configuració—, aprovar el canvi o mesurar la satisfacció de l'usuari en producció.

4.1 El model V del servei

A cada nivell d'especificació li correspon un de prova, i es dissenyen alhora, no un després de l'altre:

4.2 Tipus de prova

Provar no és només l'acceptació d'usuari:

• Funcionals i d'acceptació d'usuari: fa el que ha de fer, segons qui ho ha demanat.
• De càrrega i de rendiment: aguanta el volum previst. És la prova que falta quan un servei nou cau el dia de la difusió massiva → capacitat i disponibilitat.
• De seguretat: confidencialitat, control d'accés, vulnerabilitats.
• De regressió: el que ja funcionava continua funcionant.
• De continuïtat i de retorn: els plans de recuperació i de retorn s'han provat de veritat.
• De preparació operativa (operational readiness): els equips de suport tenen documentació, coneixement i eines per operar-lo.

4.3 Què passa si no es prova prou

Introduir a producció un servei insuficientment provat incrementa les incidències del propi servei i genera impactes en altres serveis que comparteixen infraestructura, amb costos de correcció més alts i pèrdua de confiança. La confiança i la identificació anticipada de riscos són el resultat de provar, no de no provar: aquesta inversió de sentit és la distractora clàssica.

5. Gestió d'actius de TI

Propòsit: planificar i gestionar el cicle de vida complet de tots els actius de TI, per maximitzar-ne el valor, controlar-ne els costos, gestionar riscos, donar suport a la presa de decisions sobre compra, reutilització i retirada, i complir els requisits legals i regulatoris.

Actiu de TI: qualsevol component financerament valuós que pugui contribuir al lliurament d'un producte o servei de TI. La pràctica es coneix com ITAM (Information Technology Asset Management).

Cicle de vida de l'actiu: planificació → adquisició → desplegament → operació i manteniment → retirada i disposició segura. A cada baula hi ha una decisió econòmica: comprar o llogar, quan amortitzar, quan surt més a compte substituir que mantenir. El número que es compara entre alternatives és el TCO (Total Cost of Ownership, cost total de propietat) → gestió financera.

Àmbits:

• HAM (Hardware Asset Management): maquinari, garanties, ubicació, obsolescència.
• SAM (Software Asset Management): programari i llicències, normalitzat per la ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 19770.
• Gestió de contractes, d'actius al núvol i d'actius de dades.

Auditoria de llicències: revisió —interna o del fabricant— que compara les llicències adquirides amb les instal·lacions i els usos reals. Un dèficit es paga amb regularització i sovint penalització; un excedent vol dir que s'ha pagat de més.

Altres riscos que cobreix l'ITAM: maquinari fora de suport, actius fantasma (pagats i no localitzats) i fuita de dades en la retirada, que exigeix esborrat segur o destrucció certificada.

6. Gestió de la configuració del servei i la CMDB

Propòsit: assegurar que hi ha disponible informació precisa i fiable sobre la configuració dels serveis i sobre els elements de configuració que els suporten, quan i on calgui, incloent-hi informació sobre com estan configurats els CI i sobre les relacions entre ells.

6.1 Conceptes

• Element de configuració (CI, Configuration Item): qualsevol component que calgui gestionar per lliurar un servei de TI. Poden ser maquinari, programari, documentació, serveis, persones, edificis i contractes.
• Model de configuració: model lògic que representa els serveis, els actius i la infraestructura, i com es relacionen entre si. És el model que dona la vista extrem a extrem d'un servei: quins components el sostenen i de què depenen.
• CMDB (Configuration Management Database, base de dades de gestió de la configuració): base de dades on es registren els CI i, sobretot, les seves relacions. No hi van ni el pressupost ni les factures: hi van els actius de TI i les relacions entre ells.
• CMS (Configuration Management System, sistema de gestió de la configuració): conjunt d'eines i bases de dades —pot haver-hi diverses CMDB federades— que integren, mantenen i presenten la informació de configuració. La CMDB és el magatzem; el CMS és el sistema que el fa útil.
• SKMS (Service Knowledge Management System, sistema de gestió del coneixement del servei): la capa superior, que integra el CMS, la KEDB (Known Error Database, base de dades d'errors coneguts), la cartera de serveis i tot el coneixement del proveïdor.
• Línia base de configuració (baseline): configuració formalment revisada i acordada, que serveix de referència per a activitats futures i com a punt de retorn.
• Instantània (snapshot): estat de la configuració en un moment donat, registrat per comparació posterior.

6.2 Activitats

Identificació dels CI i del seu model de dades → control (cap CI canvia sense un canvi autoritzat) → registre i informe de l'estat → verificació i auditoria, que compara la CMDB amb la realitat. El descobriment automàtic (discovery) escaneja la infraestructura i l'alimenta; sense ell, la deriva de configuració creix sola.

6.3 Diferència entre actiu i element de configuració

Un mateix element pot ser actiu i CI alhora; però hi ha CI que no són actius (un procés documentat, una relació entre components) i actius que no són CI rellevants (una llicència en desús, una impressora sense paper al magatzem). A l'ITIL v3 les dues coses anaven juntes en un únic procés, la SACM (Service Asset and Configuration Management).

6.4 Per a què serveix la CMDB

• Anàlisi d'impacte dels canvis: quins serveis cauran si toco aquest servidor.
• Diagnòstic d'incidents: quins components suporten el servei afectat.
• Disponibilitat i continuïtat: identificar punts únics de fallida.
• Compliment i seguretat: inventari per a l'anàlisi de riscos de l'ENS i el registre d'activitats de tractament del RGPD, art. 30.
• Planificació de capacitat i gestió financera.

6.5 Reptes i riscos de la gestió d'actius i configuració

Els reptes que fan fracassar les implantacions reals, i que l'examen recull:

• Falta de compromís de la direcció, que no entén el paper que hi juga la pràctica.
• Resistència del personal tècnic a treballar amb registre i autorització, perquè ho percep com a burocràcia que frena la resposta.
• Falta de finançament, perquè el benefici no és visible per a qui paga.
• Sobrecàrrega de dades: recollir-ho tot «perquè es pot», amb un volum desproporcionat i impossible de mantenir.

El risc que se'n deriva és la degradació de l'exactitud de la informació amb el temps, cara i difícil de corregir. Una CMDB desactualitzada és pitjor que no tenir-ne: indueix decisions errònies amb aparença de fonament.

7. La transició del servei a l'ITIL v3

Propòsit de la fase: construir, provar i desplegar els serveis nous o modificats, assegurant que compleixen els requisits documentats a l'etapa de disseny, i gestionar el risc del canvi per minimitzar-ne l'impacte en l'operació.

7.1 Els set processos

1. Planificació i suport a la transició
2. Gestió de canvis
3. Gestió d'actius de servei i configuració (SACM)
4. Gestió de versions i desplegament
5. Validació i proves del servei
6. Avaluació del canvi
7. Gestió del coneixement

Pregunta habitual: quin procés NO forma part de la Transició del Servei? Les distractores són incidents i esdeveniments (Operació), capacitat i nivell de servei (Disseny) i demanda (Estratègia).

El seu lloc al cicle de vida: la transició se situa entre el disseny del servei i l'operació del servei. No entre el projecte i l'operació: el projecte no és una fase del cicle de vida de l'ITIL.

7.2 Beneficis

La resposta correcta ajunta sempre tres coses: satisfacció del client i de l'usuari, reducció de les taxes d'incidències i errors dels serveis en transició i reducció dels costos de la transició.

7.3 Riscos i reptes

Els riscos documentats són l'alienació del personal de suport —canvien responsabilitats i pràctiques, i això desmotiva—, costos excessius per una pràctica exageradament aversa al risc i endarreriments inacceptables per al negoci. La resposta correcta és aquesta terna, no cap versió que negui que hi hagi riscos. Els reptes principals: cadena de subministrament complexa, equilibri entre estabilitat i capacitat de resposta, processos dispars i sistemes heretats.

7.4 Què mesurar quan els recursos són limitats

L'ITIL demana decidir explícitament què és més important, la velocitat de la transició o el cost, i establir després una jerarquia aplicable de mesures: velocitat, diners i funcionalitat. I s'ha de conscienciar i implicar tota l'organització dels requisits: sense això cada equip optimitza el seu paràmetre i cap prioritat es compleix.

Claus d'examen

• La transició és el bloc que més cau. Al pràctic de 2018 hi ha un supòsit sencer sobre la transició del servei: processos, beneficis, riscos, mesures i les set erres (TS-TIC 2018, pràctic, supòsit 2). No l'estudiïs com a història de la v3.
• «Model de configuració» és la resposta a la vista de serveis, actius i infraestructura. Ha caigut dues vegades amb el mateix enunciat i les mateixes distractores (TS-TIC 2021, p. 46; TM-TIC 2021-OP, pràctic, p. 29).
• Release i deployment es pregunten com a parella. La release és el conjunt de canvis que es lliuren junts; el deployment, l'acte físic d'instal·lar-los (TS-TIC 2025, p. 26). Que la v4 les separi és la variant moderna.
• Validació i proves = «confiança que l'entrega lliurarà el valor esperat». Aquesta formulació identifica el procés (TS-TIC 2023, p. 67); la pregunta següent demana l'objectiu del disseny de proves: models i casos que mesurin els aspectes correctes (TS-TIC 2023, p. 68).
• A la CMDB hi van actius i relacions. Ni pressupost, ni factures, ni plantilla del centre d'atenció: són les distractores fixes (TS-TIC 2018, p. 46).
• Compte amb la RFC. Aquí és Request For Change; en un tema de xarxes és un document de l'IETF.

Per recordar

• Canvi estàndard = preautoritzat; normal = avaluat i autoritzat; d'emergència = procediment abreujat però documentat, amb ECAB.
• El CAB assessora; l'autoritat de canvi decideix. La RFC és la sol·licitud que ho engega tot.
• Les set erres: Raised, Reason, Return, Risks, Resources, Responsible, Relationships. És l'única llista del tema que cal saber literalment i en anglès.
• Release = què s'allibera; deployment = moviment tècnic a un entorn. Es pot desplegar sense alliberar. La v3 les tenia en un sol procés; la v4 les separa.
• La DML és el repositori de versions autoritzades i llicències; la DSL és el seu antecessor de la v2, només de programari.
• Validació i proves = confiança que l'entrega lliurarà el valor esperat; el disseny de proves decideix què es mesura. No provar prou = més incidències i impacte en altres serveis.
• CI = component que cal gestionar per lliurar el servei; la CMDB registra els CI i les seves relacions; el CMS integra CMDB federades; el SKMS hi afegeix el coneixement.
• ITAM = què tinc i què val (financer i contractual); configuració = com està muntat i de què depèn (tècnic i relacional). Un element pot ser les dues coses, o només una.
• L'auditoria de llicències compara el comprat amb l'instal·lat: és el risc que sosté el SAM, normalitzat per la ISO/IEC 19770.
• Una CMDB desactualitzada és pitjor que cap. Reptes de la SACM: direcció, resistència tècnica, finançament i excés de dades.
• Processos de Transició: planificació i suport, canvis, SACM, versions i desplegament, validació i proves, avaluació del canvi i coneixement. Incidents, capacitat, demanda, nivell de servei i esdeveniments NO hi són. Va entre disseny i operació.
• Amb recursos limitats: decidir velocitat o cost i establir la jerarquia velocitat, diners, funcionalitat. Els riscos de la transició són alienació del personal, costos excessius i endarreriments.