Ara el tema de DevOps està a la moda. Integració contínua i canalització de lliurament tothom l'està implementant. Però la majoria no sempre presta la deguda atenció a garantir la fiabilitat dels sistemes d'informació en les diferents etapes del pipeline CI/CD. En aquest article m'agradaria parlar de la meva experiència en l'automatització de controls de qualitat del programari i la implementació de possibles escenaris per a la seva "autocuració".
Treballo com a enginyer al departament de gestió de serveis informàtics d'una empresa . La meva àrea principal d'expertesa és la implementació de diversos sistemes de monitorització del rendiment i la disponibilitat d'aplicacions. Sovint em comunico amb clients informàtics de diferents segments de mercat sobre temes actuals relacionats amb el seguiment de la qualitat dels seus serveis informàtics. L'objectiu principal és minimitzar el temps del cicle d'alliberament i augmentar la freqüència dels llançaments. Això, per descomptat, està bé: més llançaments, més funcions noves, usuaris més satisfets, més beneficis. Però en realitat, les coses no sempre surten bé. Amb taxes de desplegament molt altes, sorgeix immediatament la pregunta sobre la qualitat de les nostres versions. Fins i tot amb un pipeline totalment automatitzat, un dels reptes més grans és traslladar els serveis de les proves a la producció sense afectar el temps de funcionament de l'aplicació i l'experiència de l'usuari.
A partir dels resultats de nombroses converses amb clients, puc dir que el control de qualitat de l'alliberament, el problema de la fiabilitat de l'aplicació i la possibilitat de la seva "autocuració" (per exemple, tornar a una versió estable) en diverses etapes de l'IC /CD pipeline es troben entre els temes més interessants i rellevants.
Recentment, jo mateix he treballat al costat del client: al servei de suport de programari d'aplicacions de banca en línia. L'arquitectura de la nostra aplicació utilitzava un gran nombre de microserveis escrits per compte propi. El més trist és que no tots els desenvolupadors van poder fer front a l'elevat ritme de desenvolupament; la qualitat d'alguns microserveis va patir, fet que va donar lloc a sobrenoms divertits per a ells i els seus creadors. Hi havia històries sobre quins materials estaven fets aquests productes.
"Formulació del problema"
L'alta freqüència de llançaments i un gran nombre de microserveis dificulten la comprensió del funcionament de l'aplicació en el seu conjunt, tant en l'etapa de prova com en l'etapa operativa. Els canvis es produeixen constantment i és molt difícil controlar-los sense unes bones eines de seguiment. Sovint, després d'un llançament nocturn al matí, els desenvolupadors s'asseuen com en un barril de pólvora i esperen que no es trenqui res, tot i que totes les comprovacions van tenir èxit en l'etapa de prova.
Hi ha un punt més. En l'etapa de prova, es comprova la funcionalitat del programari: la implementació de les funcions principals de l'aplicació i l'absència d'errors. Les avaluacions qualitatives del rendiment falten o no tenen en compte tots els aspectes de l'aplicació i la capa d'integració. És possible que algunes mètriques no es comprovin en absolut. Com a resultat, quan es produeix una avaria en un entorn de producció, el departament de suport tècnic només se n'assabenta quan els usuaris reals comencen a queixar-se. M'agradaria minimitzar l'impacte del programari de baixa qualitat en els usuaris finals.
Una de les solucions és implementar processos de comprovació de la qualitat del programari en les diferents etapes del Pipeline CI/CD, i afegir diversos escenaris per restaurar el sistema en cas d'emergència. També recordem que tenim DevOps. Les empreses esperen rebre un producte nou el més aviat possible. Per tant, totes les nostres comprovacions i scripts han d'estar automatitzats.
La tasca es divideix en dos components:
- control de qualitat dels conjunts en l'etapa de prova (per automatitzar el procés de captura de conjunts de baixa qualitat);
- control de qualitat del programari en l'entorn de producció (mecanismes de detecció automàtica de problemes i possibles escenaris per a la seva autocuració).
Eina de seguiment i recollida de mètriques
Per assolir els objectius marcats, es requereix un sistema de monitorització que pugui detectar problemes i transferir-los a sistemes d'automatització en diverses etapes del pipeline CI/CD. També serà positiu que aquest sistema proporcioni mètriques útils per a diversos equips: desenvolupament, proves, funcionament. I és absolutament meravellós si també és per negocis.
Per recollir mètriques, podeu utilitzar un conjunt de sistemes diferents (Prometheus, ELK Stack, Zabbix, etc.), però, al meu entendre, les solucions de classe APM són les més adequades per a aquestes tasques (), que pot simplificar molt la teva vida.
Com a part del meu treball al servei de suport, vaig començar a fer un projecte similar utilitzant una solució de classe APM de Dynatrace. Ara, treballant per a un integrador, conec força bé el mercat dels sistemes de monitorització. La meva opinió subjectiva: Dynatrace és el més adequat per resoldre aquests problemes.
Dynatrace proporciona una visió horitzontal de cada operació d'usuari a un nivell granular fins al nivell d'execució del codi. Podeu fer un seguiment de tota la cadena d'interacció entre diversos serveis d'informació: des dels nivells frontals d'aplicacions web i mòbils, servidors d'aplicacions de fons, bus d'integració fins a una trucada específica a la base de dades.
. Construcció automàtica de totes les dependències entre components del sistema
. Detecció automàtica i construcció de la ruta d'operació del servei
També recordem que hem d'integrar-nos amb diverses eines d'automatització. Aquí la solució té una API convenient que us permet enviar i rebre diverses mètriques i esdeveniments.
A continuació, passem a una visió més detallada de com resoldre aquests problemes mitjançant el sistema Dynatrace.
Tasca 1. Automatització del control de qualitat de conjunts en fase d'assaig
El primer repte és trobar problemes tan aviat com sigui possible en el canal de lliurament d'aplicacions. Només les compilacions de codi "bones" haurien d'arribar a la producció. Per fer-ho, el vostre pipeline en l'etapa de proves hauria d'incloure monitors addicionals per comprovar la qualitat dels vostres serveis.
Fem una ullada pas a pas a com implementar-ho i automatitzar aquest procés:
La figura mostra el flux dels passos automatitzats de les proves de qualitat del programari:
- desplegament d'un sistema de monitorització (instal·lació d'agents);
- identificar esdeveniments per avaluar la qualitat del vostre programari (mètriques i valors de llindar) i transferir-los al sistema de monitorització;
- generació de proves de càrrega i rendiment;
- recollida de dades de rendiment i disponibilitat al sistema de seguiment;
- transferència de dades de proves basades en esdeveniments d'avaluació de la qualitat del programari del sistema de seguiment al sistema CI/CD. Anàlisi automàtica de conjunts.
Pas 1. Desplegament del sistema de seguiment
Primer heu d'instal·lar els agents al vostre entorn de prova. Al mateix temps, la solució Dynatrace té una característica agradable: utilitza l'agent universal OneAgent, que s'instal·la en una instància del sistema operatiu (Windows, Linux, AIX), detecta automàticament els vostres serveis i comença a recopilar-hi dades de supervisió. No cal que configureu un agent independent per a cada procés. La situació serà similar per a les plataformes de núvol i contenidors. Al mateix temps, també podeu automatitzar el procés d'instal·lació de l'agent. Dynatrace encaixa perfectament en el concepte "infraestructura com a codi" (): Hi ha scripts i instruccions ja fets per a totes les plataformes populars. Incrusteu l'agent a la configuració del vostre servei i, quan el desplegueu, rebeu immediatament un servei nou amb un agent que ja funciona.
Pas 2: defineix els teus esdeveniments de qualitat del programari
Ara heu de decidir sobre la llista de serveis i operacions comercials. És important tenir en compte exactament aquelles operacions dels usuaris que són crítiques per al vostre servei. Aquí us recomano consultar amb analistes empresarials i de sistemes.
A continuació, heu de determinar quines mètriques voleu incloure a la revisió per a cada nivell. Per exemple, pot ser el temps d'execució (dividit en mitjana, mediana, percentils, etc.), errors (lògics, servei, infraestructura, etc.) i diverses mètriques d'infraestructura (munt de memòria, col·lector d'escombraries, recompte de fils, etc.).
Per a l'automatització i la facilitat d'ús per part de l'equip de DevOps, apareix el concepte de "Monitorització com a codi". El que vull dir amb això és que un desenvolupador/provador pot escriure un fitxer JSON senzill que defineix les mètriques de garantia de la qualitat del programari.
Vegem un exemple d'aquest fitxer JSON. Els objectes de l'API de Dynatrace s'utilitzen com a parells clau/valor (la descripció de l'API es pot trobar aquí ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}El fitxer és una matriu de definicions de sèries temporals:
- timeseriesId: la mètrica que s'està comprovant, per exemple, el temps de resposta, el recompte d'errors, la memòria utilitzada, etc.;
- agregació: nivell d'agregació de mètriques, en el nostre cas, mitjana, però podeu utilitzar qualsevol que necessiteu (mitjana, mínima, màxima, suma, recompte, percentil);
- etiquetes: etiqueta d'objecte al sistema de monitorització, o podeu especificar un identificador d'objecte específic;
- severa i advertència: aquests indicadors regulen els valors llindar de les nostres mètriques; si el valor de la prova supera el llindar sever, la nostra compilació es marcarà com a no reeixida.
La figura següent mostra un exemple de l'ús d'aquests llindars.
Pas 3: generació de càrrega
Un cop hem determinat els nivells de qualitat del nostre servei, hem de generar una càrrega de prova. Podeu utilitzar qualsevol de les eines de prova amb les quals us sentiu còmode, com ara Jmeter, Selenium, Neotys, Gatling, etc.
El sistema de monitorització de Dynatrace us permet capturar diverses metadades de les vostres proves i reconèixer quines proves pertanyen a quin cicle de llançament i a quin servei. Es recomana afegir capçaleres addicionals a les sol·licituds de prova HTTP.
La figura següent mostra un exemple on, utilitzant la capçalera addicional X-Dynatrace-Test, indiquem que aquesta prova es refereix a provar el funcionament d'afegir un article al carretó.
Quan executeu cada prova de càrrega, envieu informació contextual addicional a Dynatrace mitjançant l'API d'esdeveniments des del servidor CI/CD. D'aquesta manera, el sistema pot diferenciar diferents proves.
. Esdeveniment al sistema de monitorització sobre l'inici de les proves de càrrega
Pas 4-5. Recollida de dades de rendiment i transferència de dades al sistema CI/CD
Juntament amb la prova generada, es transmet al sistema de seguiment un esdeveniment sobre la necessitat de recollir dades sobre la comprovació dels indicadors de qualitat del servei. També especifica el nostre fitxer JSON, que defineix les mètriques clau.
Esdeveniment sobre la necessitat de comprovar la qualitat del programari generat al servidor CI/CD per enviar-lo al sistema de monitorització
En el nostre exemple, s'anomena l'esdeveniment de control de qualitat perfSigDynatraceReport (Actuació_Firma) -Això està llest per a la integració amb Jenkins, que va ser desenvolupat pels nois de T-Systems Multimedia Solutions. Cada esdeveniment de llançament de prova conté informació sobre el servei, el número de compilació i el temps de prova. El connector recopila els valors de rendiment en el moment de la creació, els avalua i compara el resultat amb les versions anteriors i els requisits no funcionals.
Esdeveniment al sistema de monitorització sobre l'inici d'un control de qualitat de construcció.
Un cop finalitzada la prova, totes les mètriques per avaluar la qualitat del programari es tornen a transferir a un sistema d'integració contínua, per exemple, Jenkins, que genera un informe sobre els resultats.
El resultat de les estadístiques de muntatges al servidor CI/CD.
Per a cada compilació individual, veiem les estadístiques de cada mètrica que vam establir durant tota la prova. També veiem si hi ha hagut infraccions en determinats valors de llindar (avís i llindars greus). D'acord amb les mètriques agregades, la compilació sencera es marca com a estable, inestable o fallada. A més, per comoditat, podeu afegir indicadors a l'informe que comparen la construcció actual amb l'anterior.
Consulteu les estadístiques detallades dels conjunts al servidor CI/CD.
Comparació detallada de dos conjunts
Si cal, podeu anar a la interfície de Dynatrace i allà podreu veure les estadístiques de cadascuna de les vostres compilacions amb més detall i comparar-les entre elles.
Comparació d'estadístiques de compilació a Dynatrace.
Troballes
Com a resultat, obtenim un servei de "monitoring as a service", automatitzat en el pipeline d'integració contínua. El desenvolupador o provador només ha de definir una llista de mètriques en un fitxer JSON i tota la resta passa automàticament. Rebem un control de qualitat transparent dels llançaments: totes les notificacions sobre rendiment, consum de recursos o regressió arquitectònica.
Tasca 2. Automatització del control de qualitat del programari en un entorn de producció
Per tant, hem resolt el problema de com automatitzar el procés de monitorització en l'etapa de proves a Pipeline. D'aquesta manera minimitzem el percentatge de conjunts de baixa qualitat que arriben a l'entorn de producció.
Però què fer si s'acaba venent un programari dolent o simplement es trenca alguna cosa. Per una utopia, volíem mecanismes per detectar automàticament els problemes i, si és possible, el propi sistema per restablir la seva funcionalitat, almenys de nit.
Per fer-ho, necessitem, per analogia amb l'apartat anterior, preveure controls automàtics de qualitat del programari en l'entorn de producció i basar-los en escenaris per a l'autocuració del sistema.
Correcció automàtica com a codi
La majoria de les empreses ja disposen d'una base de coneixement acumulada sobre diversos tipus de problemes comuns i una llista d'accions per solucionar-los, per exemple, reiniciar processos, netejar recursos, revertir versions, restaurar canvis de configuració no vàlids, augmentar o disminuir el nombre de components en el clúster, canviant el contorn blau o verd, etc.
Si bé aquests casos d'ús són coneguts des de fa anys per molts dels equips amb els quals parlo, pocs han pensat o han invertit en automatitzar-los.
Si ho penseu, no hi ha res massa complicat a l'hora d'implementar processos per al rendiment de l'aplicació d'autocuració; heu de presentar els escenaris de treball ja coneguts dels vostres administradors en forma d'scripts de codi (el concepte de "correcció automàtica com a codi"). , que heu escrit per endavant per a cada cas concret. Els scripts de reparació automàtica haurien d'estar dirigits a eliminar la causa principal del problema. Tu mateix decideixes les accions correctes per respondre a un incident.
Qualsevol mètrica del vostre sistema de monitorització pot actuar com a activador per llançar l'script, el més important és que aquestes mètriques determinen amb precisió que tot és dolent, ja que no voldríeu obtenir falsos positius en un entorn productiu.
Podeu utilitzar qualsevol sistema o conjunt de sistemes: Prometheus, ELK Stack, Zabbix, etc. Però donaré alguns exemples basats en una solució APM (Dynatrace tornarà a ser un exemple) que també us ajudaran a fer-vos la vida més fàcil.
En primer lloc, hi ha tot el relacionat amb el rendiment pel que fa al funcionament de l'aplicació. La solució proporciona centenars de mètriques a diversos nivells que podeu utilitzar com a activadors:
- nivell d'usuari (navegadors, aplicacions mòbils, dispositius IoT, comportament de l'usuari, conversió, etc.);
- nivell de servei i operacions (rendiment, disponibilitat, errors, etc.);
- nivell d'infraestructura d'aplicacions (mètriques del sistema operatiu amfitrió, JMX, MQ, servidor web, etc.);
- nivell de plataforma (virtualització, núvol, contenidor, etc.).
Monitorització dels nivells a Dynatrace.
En segon lloc, com he dit abans, Dynatrace té una API oberta, la qual cosa facilita la integració amb diversos sistemes de tercers. Per exemple, enviar una notificació al sistema d'automatització quan es superen els paràmetres de control.
A continuació es mostra un exemple per interaccionar amb Ansible.
A continuació, donaré alguns exemples de quin tipus d'automatització es pot fer. Aquesta és només una part dels casos; la seva llista al vostre entorn només es pot limitar per la vostra imaginació i les capacitats de les vostres eines de supervisió.
1. Implementació incorrecta: retrocés de versió
Fins i tot si ho provem tot molt bé en un entorn de prova, encara hi ha la possibilitat que una nova versió pugui matar la vostra aplicació en un entorn de producció. El mateix factor humà no s'ha cancel·lat.
A la següent figura veiem que hi ha un fort salt en el temps d'execució de les operacions al servei. L'inici d'aquest salt coincideix amb el moment del desplegament a l'aplicació. Tota aquesta informació la transmetem com a esdeveniments al sistema d'automatització. Si el rendiment del servei no torna a la normalitat després del temps que hem establert, llavors es crida automàticament un script que torna la versió a l'antiga.
Degradació del rendiment de les operacions després del desplegament.
2. Càrrega de recursos al 100%: afegiu un node a l'encaminament
A l'exemple següent, el sistema de monitorització determina que un dels components està experimentant una càrrega de CPU del 100%.
Càrrega de la CPU al 100%
Hi ha diversos escenaris diferents possibles per a aquest esdeveniment. Per exemple, el sistema de monitorització també comprova si la manca de recursos està associada a un augment de la càrrega del servei. Si és així, s'executa un script que afegeix automàticament un node a l'encaminament, restaurant així la funcionalitat del sistema en conjunt.
Escalada després d'un incident
3. Falta d'espai al disc dur - neteja del disc
Crec que molta gent ja ha automatitzat aquests processos. Amb APM, també podeu supervisar l'espai lliure al subsistema de disc. Si no hi ha espai o el disc s'executa lentament, cridem a un script per netejar-lo o afegir-hi espai.
Càrrega del disc 100%
4. Baixa activitat dels usuaris o baixa conversió: canvi entre branques blaves i verdes
Sovint veig clients que utilitzen dos bucles (desplegament blau-verd) per a aplicacions en un entorn de producció. Això us permet canviar ràpidament entre branques quan entreu nous llançaments. Sovint, després del desplegament, es poden produir canvis dramàtics que no es noten immediatament. En aquest cas, és possible que no s'observi una degradació del rendiment i la disponibilitat. Per respondre ràpidament a aquests canvis, és millor utilitzar diverses mètriques que reflecteixin el comportament de l'usuari (nombre de sessions i accions de l'usuari, conversió, percentatge de rebots). La figura següent mostra un exemple en què, quan baixen les taxes de conversió, es produeix un canvi entre branques de programari.
La taxa de conversió baixa després de canviar entre branques de programari.
Mecanismes per a la detecció automàtica de problemes
Finalment, us donaré un exemple més de per què m'agrada més Dynatrace.
A la part de la meva història sobre l'automatització de controls de qualitat dels conjunts en un entorn de prova, vam determinar tots els valors de llindar manualment. Això és normal per a un entorn de prova; el mateix verificador determina els indicadors abans de cada prova en funció de la càrrega. En un entorn de producció, és desitjable que els problemes es detectin automàticament, tenint en compte diversos mecanismes de referència.
Dynatrace té incorporades interessants eines d'intel·ligència artificial que, a partir de mecanismes per determinar mètriques anòmales (baselining) i construir un mapa d'interacció entre tots els components, comparant i correlacionant esdeveniments entre si, determinen anomalies en el funcionament del vostre servei i proporcionen detalls. informació sobre cada problema i causa arrel.
En analitzar automàticament les dependències entre components, Dynatrace determina no només si el servei problemàtic és la causa principal, sinó també la seva dependència d'altres serveis. A l'exemple següent, Dynatrace supervisa i avalua automàticament la salut de cada servei dins de l'execució de la transacció, identificant el servei Golang com a causa arrel.
Un exemple per determinar la causa principal d'una fallada.
La figura següent mostra el procés de seguiment dels problemes amb la vostra aplicació des de l'inici d'un incident.
Visualització d'un problema emergent amb visualització de tots els components i esdeveniments sobre ells
El sistema de seguiment va recollir una cronologia completa dels fets relacionats amb el problema sorgit. A la finestra de sota de la línia de temps veiem tots els esdeveniments clau de cadascun dels components. A partir d'aquests esdeveniments, podeu establir procediments per a la correcció automàtica en forma d'scripts de codi.
A més, us aconsello que integreu un sistema de monitorització amb Service Desk o un rastrejador d'errors. Quan es produeix un problema, els desenvolupadors reben ràpidament informació completa per analitzar-la a nivell de codi a l'entorn de producció.
Conclusió
Com a resultat, vam acabar amb un pipeline CI/CD amb controls de qualitat de programari automatitzats integrats a Pipeline. Minimitzem el nombre de muntatges de baixa qualitat, augmentem la fiabilitat del sistema en conjunt i, si el nostre sistema encara falla, posem en marxa mecanismes per restaurar-lo.
Sens dubte, val la pena invertir esforços en l'automatització del control de la qualitat del programari; no sempre és un procés ràpid, però amb el temps donarà els seus fruits. Us recomano que, després de resoldre un nou incident a l'entorn de producció, penseu immediatament en quins monitors s'han d'afegir per a les comprovacions a l'entorn de prova per tal d'evitar que entri en producció una mala compilació, i també creeu un script per corregir automàticament aquests problemes.
Espero que els meus exemples us ajudin en els vostres esforços. També m'interessarà veure els vostres exemples de mètriques utilitzades per implementar sistemes d'autocuració.
Font: www.habr.com