ContacteIntroducció
Les proves de rendiment són un element clau per garantir la qualitat i la fiabilitat dels sistemes d’informació del Departament de Salut. Aquest document estableix el marc i el procediment per planificar, executar i validar aquestes proves, assegurant que les aplicacions compleixin els requisits de temps de resposta, capacitat i escalabilitat abans de la seva posada en producció.
El CTTI disposa d’informació addicional referent als requeriments i cicle de vida d’execució de proves de rendiment:
https://qualitat.solucions.gencat.cat/procediments/realitzar_proves/
Motivació de l’informe de proves de rendiment
Les proves de rendiment són essencials per garantir que un sistema informàtic funcioni de manera eficient i fiable sota diferents condicions de càrrega. Permeten identificar colls d’ampolla i punts crítics, validar l’escalabilitat dels components i assegurar l’estabilitat i la resiliència del sistema, contribuint així a una millor experiència d’usuari i a una optimització dels recursos.
Un document de proves de rendiment ben estructurat facilita la coordinació entre els equips tècnics i funcionals i permet detectar i corregir problemes de manera proactiva, reduint riscos abans de la posada en producció. Per aquest motiu, la definició, preparació, execució i anàlisi de les proves han de complir els nivells d’exigència necessaris per garantir una implantació adequada del sistema en entorns productius.
Característiques desitjables de les proves
Reproductibilitat
Les proves de rendiment han de produir resultats consistents quan s’executen sota les mateixes condicions. Això assegura que els problemes detectats són reals i no fluctuacions aleatòries, permetent una identificació precisa i efectiva de possibles afectacions en el rendiment sota una determinada càrrega d’operacions.
Representativitat
Les proves han de reflectir escenaris d’ús realistes, representatius del comportament dels usuaris a l’entorn de producció.
Automatització
Automatitzar les proves de rendiment permet realitzar-les de manera eficient i repetitiva, sense intervenció manual, assegurant consistència i simulació de càrrega concurrent d’usuaris realitzant transaccions.
Monitoratge i mesura
Durant les proves de rendiment cal recopilar les mètriques clau de l’aplicació i de la infraestructura que la suporta, com ara consum de CPU i memòria, temps de resposta, nombre de crides, percentatge d’errors, usuaris concurrents o tràfic de xarxa. Aquesta monitorització permet analitzar el comportament del sistema sota càrrega i identificar colls d’ampolla, riscos de fallida o oportunitats d’optimització.
També és necessari disposar de mètriques de serveis externs i components de suport (com bases de dades o solucions SaaS), atès que poden tenir un impacte significatiu en el rendiment global. El lot d’aplicacions és responsable de garantir la disponibilitat d’aquestes dades durant les proves i, quan intervinguin infraestructures gestionades per tercers o pel CPD, caldrà coordinar-ne la recopilació segons correspongui.
Requeriments no funcionals per les aplicacions
Load Runner
L’eina per executar les proves de rendiment fixada per CTTI és Load Runner, amb els corresponents injectors de càrrega que simulen els usuaris virtuals (VUser):
https://qualitat.solucions.gencat.cat/eines/alm-loadrunner/
Gestió de la capacitat
S’estableixen uns llindars de pics màxims del 65% de CPU o memòria en solucions aprovisionades en modalitats PaaS, IaaS o hosting dedicat, i de 85% en solucions en contenidors. Superats aquests llindars, caldrà donar una justificació de quina ha estat la causa del comportament observat durant la prova de rendiment.
L’entorn de PRE on s’executen les proves hauria de tenir una arquitectura idèntica a l’entorn de PRO (elasticitat, autoescalabilitat, alta disponibilitat,…) però pot tenir un dimensionament vertical i horitzontal menor.
En execucions d’escenaris asíncrons, caldrà tenir en compte el throughput màxim de generació d’esdeveniment o missatges als tòpics abans de saturar els possibles consumidors d’aquests.
Requeriments relacionats amb el temps de resposta
S’entén que el temps de resposta mesurat comprèn:
-
Interoperabilitat síncrona: des de la invocació del client a un servei de l’API de negoci fins la recepció de la resposta esperada o error per part d’aquest.
-
Interoperabilitat asíncrona: des de la consumició d’un missatge d’un tòpic fins la finalització de les operacions relacionades en el tractament d’aquest.
Per avaluar els temps de resposta d’una prova, prendrem com a referència els llindars definits en el document de Descripció d’Arquitectura (DA) de la solució, en l’apartat “Rendiment i escalabilitat”.
Tanmateix, com a normal general en els casos que aquests llindars no estiguin especificats explícitament en el DA, establirem aquests requeriments respecte operacions sobre el sistema transaccional de l’aplicació:
| Operació | Màxim acceptat |
|---|---|
| Alta, baixa i modificació de registres únics | 60ms (mil·lisegons), dins d’un percentil 95 |
| Consulta d’un registre concret per identificador o clau primària | 40ms (mil·lisegons), dins d’un percentil 95 |
Latència en el temps de resposta en núvol públic
En arquitectures en núvol públic o híbrides és imprescindible identificar i mesurar la latència de xarxa entre origen i destí per interpretar correctament els resultats de les proves de rendiment, especialment tenint en compte que els desplegaments del CTTI en núvol públic es troben en diferents regions europees (AWS a Irlanda, Azure a Alemanya o Holanda, i Google Cloud a Alemanya).
La connectivitat amb els CPD on-premise es realitza a través de la capa de networking NET0 gestionada per NUS (DirectConnect, ExpressRoute o InterConnect segons el proveïdor de núvol). És responsabilitat del lot d’aplicacions entendre aquesta arquitectura i optimitzar els fluxos de comunicació amb components on-premise. Per a més detall sobre els fluxos de la NET0, es pot consultar la guia corresponent del CTTI.https://canigo.ctti.gencat.cat/plataformes/public_cloud/estandards/
Especificació de les proves de rendiment a Salut
El Departament de Salut ens basem en el marc de proves de rendiment definit per CTTI en el seu model de Qualitat de Solucions, que ha de ser de coneixement del proveïdor d’aplicació abans de definir i dissenyar els seus escenaris d’execució:
https://qualitat.solucions.gencat.cat/guies/proves-rendiment/
Existeixen diverses tipologies de proves de rendiment amb objectius específics:
- proves de línia base
- proves d’estrès
- proves de càrrega
- proves d’estabilitat
Prova de línia base
La prova de línia base és una execució inicial amb un únic VUser i una duració curta (5 minuts ), que ens serveix per verificar que l’script simulador de l’escenari és correcte, i tenir un primer punt de referència sobre l’estat del sistema, comparatiu per la resta de proves a executar.
Prova d’estabilitat
La finalitat d’aquesta prova és validar l’estabilitat de l’aplicació amb la càrrega esperada contínua de Producció durant un temps prolongat (entre 4 i 6 hores). És la prova més descriptiva del rendiment de la aplicació en condicions normals i en la que cal fer focus per trobar punts de millora.
Ens serveix per observar el comportament del sistema en una jornada complerta, identificant possibles problemes com memory leaks, connexions sense tancar, o altres degradacions que només afloren amb l’aplicació en hores en funcionament.
Prova de càrrega
La prova de càrrega analitza el comportament del sistema en condicions de pics superiors a les condicions normals mitjanes de Producció.
Primer, s’arriba de manera controlada a les condicions normals, i després de mantenir una fase estable, es continua augmentant aquesta càrrega de forma progressiva fins assolir les condicions de pics màxim. El seu objectiu és identificar com evoluciona el rendiment a mesura que la càrrega creix, observant els temps de resposta, el consum de recursos i l’estabilitat del sistema, i detectant possibles degradacions quan ens anem acostant als moments màxims de l’aplicació.
El valor principal d’aquesta prova rau a validar quins punts comencen a degradar-se primer quan se supera la càrrega esperada del sistema.
La duració d’aquesta prova hauria de ser suficient amb 1 hora.
Prova d’estrès
La prova d’estrès, en canvi, verifica el comportament de l’aplicació en situacions per sobre de les condicions de pic, buscant intencionadament provocar la fallida del sistema degut a un desbordament de peticions, per determinar quin són components que poden saturar.
Consisteix en un augment controlat de la càrrega fins a assolir la capacitat prevista d’una prova de càrrega, i a continuació una pujada pronunciada i agressiva d’usuaris virtuals, fins acabar forçant el sistema al seu punt de trencament.
La seva durada sol ser breu, ja que el propòsit és identificar ràpidament el límit real de capacitat del sistema, observant primer la degradació progressiva d’aquesta (com en la prova de càrrega), fins detectar en quin punt i component es produeix la fallida: bé per saturació de recursos, temps de resposta disparats, o increment notable de les taxes d’error de peticions.
Això ens permetrà anticipar la reacció del sistema davant situacions inesperades o extremes, o escalar de manera més eficient els recursos per aconseguir que el punt de trencament de l’aplicació sigui superior.
La duració d’aquesta prova hauria de ser suficient amb menys d’una hora.
Presentació del informe amb els resultats de les proves
Les plantilles per presentar aquest informe es troben a la documentació del CTTI:
https://qualitat.solucions.gencat.cat/procediments/proves/informe_resultat_proves/
Definició dels casos d’ús i escenaris
Les proves de rendiment es definiran a partir d’escenaris proposats pel proveïdor i validats per l’equip funcional o responsables de solució. Aquests escenaris han de simular la càrrega d’usuaris virtuals (VUsers) per a cada tipus de prova (línia base, càrrega, estrès i estabilitat), indicant de forma clara la volumetria prevista: transaccions per segon, nombre inicial d’usuaris i ritme d’increment fins al màxim establert.
Cada escenari pot incloure un o diversos casos d’ús, executats de manera seqüencial o concurrent. Es recomana documentar-los mitjançant un diagrama de seqüència amb els components implicats i una breu descripció funcional, que permeti estimar i justificar els temps de resposta objectiu. L’aplicació ha de disposar de mètriques suficients per mesurar aquestes interaccions; si no és possible, caldrà justificar-ho i preveure millores d’observabilitat.
Execució de les proves
Per a cada prova cal identificar les mètriques que permetin avaluar el compliment dels requisits no funcionals de l’arquitectura de referència. Els resultats de les proves (línia base, càrrega, estrès i estabilitat) s’han de presentar amb les dades principals de Load Runner: total de crides i percentatge d’èxit/error, temps de resposta (mínim, mitjà, p95 i màxim) i gràfiques d’evolució de VUsers, transaccions i temps de resposta.
A més, cal incloure mètriques d’infraestructura (CPU i memòria com a mínim) i dels components implicats: en núvol públic, a partir de les eines de monitorització pròpies; en entorns on-premise o núvol privat, coordinant-ne la recopilació amb el CPD; i, si escau, mètriques de negoci o de components transversals (com plataformes d’esdeveniments) mitjançant els dashboards corresponents
Conclusions
Cal presentar conclusions sobre el comportament del sistema en les diferents proves, justificant els casos en què no s’hagin assolit els temps de resposta previstos. En aquests casos, s’han de proposar possibles mesures correctores, com ara optimitzacions tècniques, ajustos d’escalabilitat o millores en la implementació.
Aquest apartat ha de permetre al responsable de la solució determinar si el sistema està preparat per a la seva posada en producció en condicions adequades.
Flux d’execució d’una prova de rendiment i acceptació o rebuig d’aquesta
El proveïdor de l’aplicació ha de planificar la realització de les proves de rendiment com a pas previ a la posada en producció, assegurant-se que es disposa del temps i dels recursos necessaris sense condicionar el calendari d’implantació.
Cal utilitzar les eines i infraestructures fixades per el Servei de Qualitat de Solucions de Salut. Inclou la preparació dels scripts i sets de dades inicials per executar els escenaris.
Un cop finalitzades les proves de rendiment, i completat el document amb els resultats obtinguts, el gestor de solucions pot sol·licitar-ne la seva revisió, adjuntat el informe a la bústia de correu qualitatsolucions.salut@gencat.cat.
Les oficines d’Arquitectura de Solucions i Servei de Qualitat de Solucions de Salut revisaran la documentació, i es completarà una checklist amb els principals punts verificats, observacions i possibles comentaris sorgits durant la revisió.
Un cop revisada la checklist, el Servei de Qualitat de Salut emetrà una valoració al responsable de la solució, que és qui finalment decidirà si es pot continuar amb la posada en producció o si cal aplicar millores o repetir les proves.
El document de valoració s’haurà d’incorporar a la documentació de qualitat del projecte i quedarà disponible per a futures auditories.
Responsabilitats dels equips implicats
Amb l’objectiu de garantir una correcta execució i valoració de les proves de rendiment, s’estableixen les responsabilitats següents per als equips participants:
Equip de Desenvolupament
L’equip de desenvolupament és responsable de definir els casos d’ús crítics que formaran part dels escenaris de prova, assegurant que siguin representatius de la càrrega real de producció. També ha de preparar les dades necessàries per a l’execució de les proves, garantint-ne la validesa, volumetria i variabilitat adequada.
Durant les proves, haurà d’analitzar i resoldre les incidències detectades, aportar conclusions sobre els punts de degradació (interns o externs) i proposar millores tant a nivell d’observabilitat com d’optimització de l’aplicació i del consum de recursos.
Gestor o Responsable de la solució
És responsable de garantir que les proves de rendiment es planifiquin dins del calendari del projecte i que els escenaris definits siguin representatius de l’ús real en producció. També ha de revisar la checklist i el document de resultats per decidir la posada en producció de l’evolutiu.
Així mateix, ha de valorar la incorporació al backlog de les millores identificades arran de les proves.
Arquitectura de Solucions de Salut
És responsable de revisar que la documentació de les proves justifiqui adequadament els temps de resposta estimats i de validar el compliment dels llindars de rendiment definits a la Descripció d’Arquitectura.
També ha de completar la checklist amb les observacions necessàries per facilitar la presa de decisions del gestor de la solució i identificar possibles millores o ajustos a l’Arquitectura de Referència de Salut a partir dels resultats obtinguts.
Servei de Qualitat de Solucions de Salut
És responsable d’identificar les entregues que han d’incloure proves de rendiment, d’acord amb les polítiques establertes, i d’assegurar que aquesta exigència es traslladi als equips implicats.
També ha de verificar que la checklist d’arquitectura i la documentació associada estiguin completes, i dur a terme les auditories corresponents quan es consideri necessari.
Contingut de la checklist
La checklist es completa després de la revisió del informe de proves. Està estructurada en blocs diferenciats amb els criteris de validació corresponents. Per cada ítem, s’indicarà el compliment o no compliment, i si escau, s’afegiran comentaris rellevants.
Bloc 1: Definició dels casos d’ús
- Inclou una descripció funcional de cada cas d’ús.
- Inclou el diagrama de seqüència de tots els casos d’ús.
- Els temps de resposta esperats per a cada cas d’ús respecten els llindars establerts per transacció segons els principis d’arquitectura.
- Si el cas d’ús interactua amb sistemes externs: el temps d’aquesta interacció es pot obtenir de les mètriques de l’aplicació. Si no es pot obtenir de les mètriques, es disposa d’una estimació justificada.
Bloc 2: Proves de línia base
- S’han executat proves de línia base per a tots els casos d’ús afectats per la release.
- S’inclou en el document el resum de resultats de l’eina de proves.
- S’inclou en el document l’histograma de resultats de l’eina d’observabilitat.
Bloc 3: Proves d’estrès
- S’han executat proves d’estrès per a tots els casos d’ús afectats per la release.
- El document inclou la identificació dels colls d’ampolla o punts de trencament detectats.
- S’inclou en el document el resum de resultats de l’eina de proves.
- S’inclou en el document l’histograma de resultats de l’eina d’observabilitat.
Bloc 4: Proves de càrrega
- S’han executat proves de càrrega per a tots els casos d’ús afectats per la release.
- S’inclou en el document el resum de resultats de l’eina de proves.
- S’inclou en el document l’histograma de resultats de l’eina d’observabilitat.
- Es compleixen els requeriments relacionats amb la gestió de la capacitat.
- Si no es compleixen els requeriments de gestió de la capacitat, s’inclou una justificació en el document.
- Es compleixen els requeriments relacionats amb el temps de resposta.
- Si no es compleixen els requeriments de temps de resposta, s’inclou una justificació en el document.
Bloc 5: Proves d’estabilitat
- S’han executat proves d’estabilitat per tots els casos d’ús afectats per la release.
- S’inclou en el document el resum de resultats de l’eina de proves.
- S’inclou en el document l’histograma de resultats de l’eina d’observabilitat.
- Es compleixen els requeriments relacionats amb la gestió de la capacitat.
- Si no es compleixen els requeriments de gestió de la capacitat, s’inclou una justificació en el document.
- Es compleixen els requeriments relacionats amb el temps de resposta.
- Si no es compleixen els requeriments de temps de resposta, s’inclou una justificació en el document.