Vam pensar en crear un sistema de seguiment en l'etapa de formació d'equips de producte. Va quedar clar que el nostre negoci -l'explotació- no recau en aquests equips. Per què això?
El fet és que tots els nostres equips es construeixen al voltant de sistemes d'informació, microserveis i fronts individuals, de manera que els equips no veuen la salut general de tot el sistema en conjunt. Per exemple, és possible que no sàpiguen com una petita part del backend profund afecta el front end. El seu àmbit d'interès es limita als sistemes amb els quals està integrat el seu sistema. Si un equip i el seu servei A gairebé no tenen connexió amb el servei B, aquest servei és gairebé invisible per a l'equip.
El nostre equip, al seu torn, treballa amb sistemes molt integrats entre ells: hi ha moltes connexions entre ells, aquesta és una infraestructura molt gran. I el funcionament de la botiga online depèn de tots aquests sistemes (dels quals en tenim, per cert, un gran nombre).
Així doncs, resulta que el nostre departament no pertany a cap equip, sinó que està situat una mica al costat. En tota aquesta història, la nostra tasca és entendre de manera exhaustiva com funcionen els sistemes d'informació, la seva funcionalitat, integracions, programari, xarxa, maquinari i com tot això està connectat entre si.
La plataforma en què operen les nostres botigues en línia és la següent:
- front
- mitja oficina
- back office
Per molt que ens agradaria, no passa que tots els sistemes funcionin sense problemes i sense problemes. La qüestió, de nou, és el nombre de sistemes i integracions: amb alguna cosa com la nostra, alguns incidents són inevitables, malgrat la qualitat de les proves. A més, tant dins d'un sistema separat com pel que fa a la seva integració. I cal supervisar l'estat de tota la plataforma de manera integral, i no només una part individual d'ella.
L'ideal seria automatitzar el seguiment de la salut a tota la plataforma. I vam arribar al seguiment com a part inevitable d'aquest procés. Inicialment, es va crear només per a la part de primera línia, mentre que els especialistes de xarxa, els administradors de programari i maquinari tenien i encara tenen els seus propis sistemes de monitorització capa per capa. Totes aquestes persones van seguir el seguiment només al seu nivell, ningú no tenia una comprensió global.
Per exemple, si una màquina virtual falla, en la majoria dels casos només l'administrador responsable del maquinari i la màquina virtual ho saben. En aquests casos, l'equip de primera línia va veure el fet mateix de la fallada de l'aplicació, però no tenia dades sobre la fallada de la màquina virtual. I l'administrador pot saber qui és el client i tenir una idea aproximada del que s'està executant actualment en aquesta màquina virtual, sempre que es tracti d'algun tipus de projecte gran. El més probable és que no sàpiga dels més petits. En qualsevol cas, l'administrador ha d'anar al propietari i preguntar-li què hi havia en aquesta màquina, què cal restaurar i què s'ha de canviar. I si alguna cosa realment greu es trencava, començaven a córrer en cercles, perquè ningú veia el sistema com un tot.
En última instància, històries tan dispars afecten tota la interfície, els usuaris i la nostra funció principal de negoci: les vendes en línia. Com que no formem part d'un equip, sinó que ens dediquem al funcionament de totes les aplicacions de comerç electrònic com a part d'una botiga en línia, ens vam encarregar de crear un sistema de monitoratge integral per a la plataforma de comerç electrònic.
Estructura i pila del sistema
Vam començar identificant diverses capes de monitorització per als nostres sistemes, dins de les quals hauríem de recollir mètriques. I tot això s'havia de combinar, que és el que vam fer en la primera etapa. Ara, en aquesta etapa, estem finalitzant la col·lecció de mètriques de la més alta qualitat a totes les nostres capes per tal de crear una correlació i entendre com s'influeixen els sistemes entre ells.
La manca d'un seguiment integral en les etapes inicials del llançament de l'aplicació (ja que vam començar a construir-la quan la majoria dels sistemes estaven en producció) va fer que tinguéssim un deute tècnic important per configurar el seguiment de tota la plataforma. No ens podríem permetre el luxe de centrar-nos a configurar la supervisió d'un IS i elaborar-ne la monitorització detalladament, ja que la resta de sistemes es quedarien sense monitoratge durant un temps. Per solucionar aquest problema, vam identificar una llista de les mètriques més necessàries per avaluar l'estat del sistema d'informació per capa i vam començar a implementar-la.
Per tant, van decidir menjar-se l'elefant per parts.
El nostre sistema consta de:
- maquinari;
- sistema operatiu;
- programari;
- parts de la interfície d'usuari a l'aplicació de supervisió;
- mètriques empresarials;
- aplicacions d'integració;
- Seguretat de la informació;
- xarxes;
- equilibrador de trànsit.
Al centre d'aquest sistema hi ha el seguiment. Per entendre generalment l'estat de tot el sistema, cal saber què està passant amb les aplicacions en totes aquestes capes i en tot el conjunt d'aplicacions.
Per tant, sobre la pila.
Utilitzem programari de codi obert. Al centre tenim Zabbix, que fem servir principalment com a sistema d'alertes. Tothom sap que és ideal per al seguiment d'infraestructures. Què vol dir això? Exactament aquelles mètriques de baix nivell que té cada empresa que manté el seu propi centre de dades (i Sportmaster té els seus propis centres de dades): temperatura del servidor, estat de la memòria, incursió, mètriques del dispositiu de xarxa.
Hem integrat Zabbix amb Telegram messenger i Microsoft Teams, que s'utilitzen activament en equips. Zabbix cobreix la capa de la xarxa real, el maquinari i algun programari, però no és una panacea. Enriquim aquestes dades d'altres serveis. Per exemple, a nivell de maquinari, ens connectem directament mitjançant API al nostre sistema de virtualització i recollim dades.
Què més. A més de Zabbix, utilitzem Prometheus, que ens permet supervisar mètriques en una aplicació d'entorn dinàmic. És a dir, podem rebre mètriques de l'aplicació mitjançant un punt final HTTP i no preocupar-nos de quines mètriques hi hem de carregar i quines no. A partir d'aquestes dades es poden desenvolupar consultes analítiques.
Les fonts de dades d'altres capes, per exemple, mètriques empresarials, es divideixen en tres components.
En primer lloc, es tracta de sistemes empresarials externs, Google Analytics, recopilem mètriques dels registres. D'ells obtenim dades sobre usuaris actius, conversions i tot allò relacionat amb el negoci. En segon lloc, es tracta d'un sistema de monitorització de la interfície d'usuari. S'hauria de descriure amb més detall.
Hi havia una vegada que vam començar amb proves manuals i es van convertir en proves automàtiques de funcionalitat i integracions. A partir d'això vam fer un seguiment, deixant només la funcionalitat principal, i vam confiar en marcadors el més estables possible i que no canvien sovint amb el temps.
La nova estructura d'equip significa que totes les activitats de l'aplicació es limiten als equips de producte, de manera que vam deixar de fer proves pures. En canvi, vam fer un seguiment de la interfície d'usuari a partir de les proves, escrites en Java, Selenium i Jenkins (utilitzat com a sistema per llançar i generar informes).
Vam fer moltes proves, però al final vam decidir anar a la carretera principal, la mètrica de primer nivell. I si tenim moltes proves específiques, serà difícil mantenir les dades actualitzades. Cada llançament posterior trencarà significativament tot el sistema i tot el que farem és arreglar-ho. Per tant, ens hem centrat en coses molt fonamentals que rarament canvien i només les fem un seguiment.
Finalment, en tercer lloc, la font de dades és un sistema de registre centralitzat. Utilitzem Elastic Stack per als registres i, a continuació, podem extreure aquestes dades al nostre sistema de supervisió per a mètriques empresarials. A més de tot això, disposem del nostre propi servei de Monitoring API, escrit en Python, que consulta qualsevol servei mitjançant API i en recull dades a Zabbix.
Un altre atribut indispensable del seguiment és la visualització. El nostre està basat en Grafana. Destaca entre altres sistemes de visualització perquè permet visualitzar mètriques de diferents fonts de dades al tauler. Podem recopilar mètriques de primer nivell per a una botiga en línia, per exemple, el nombre de comandes realitzades en l'última hora des del SGBD, mètriques de rendiment per al sistema operatiu en què s'executa aquesta botiga en línia des de Zabbix i mètriques per a exemples d'aquesta aplicació. de Prometeu. I tot això estarà en un tauler. Clar i accessible.
Permeteu-me tenir en compte la seguretat: actualment estem ultimant el sistema, que després integrarem amb el sistema de monitorització global. En la meva opinió, els principals problemes als quals s'enfronta el comerç electrònic en l'àmbit de la seguretat de la informació estan relacionats amb els bots, els analitzadors i la força bruta. Hem de vigilar-ho, perquè tot això pot afectar de manera crítica tant el funcionament de les nostres aplicacions com la nostra reputació des del punt de vista empresarial. I amb la pila escollida cobrim amb èxit aquestes tasques.
Un altre punt important és que la capa d'aplicació la munta Prometheus. Ell mateix també està integrat amb Zabbix. I també disposem de sitespeed, un servei que ens permet visualitzar paràmetres com la velocitat de càrrega de la nostra pàgina, colls d'ampolla, renderització de la pàgina, scripts de càrrega, etc., també està integrat amb API. Per tant, les nostres mètriques es recullen a Zabbix i, en conseqüència, també alertem des d'allà. Actualment, totes les alertes s'envien als principals mètodes d'enviament (de moment és correu electrònic i telegrama, MS Teams també s'ha connectat recentment). Hi ha plans per actualitzar l'alerta a un estat tal que els robots intel·ligents funcionin com a servei i proporcionin informació de seguiment a tots els equips de productes interessats.
Per a nosaltres, les mètriques són importants no només per als sistemes d'informació individuals, sinó també les mètriques generals per a tota la infraestructura que utilitzen les aplicacions: clústers de servidors físics en els quals s'executen màquines virtuals, equilibradors de trànsit, equilibradors de càrrega de xarxa, la pròpia xarxa, utilització dels canals de comunicació. . A més de mètriques per als nostres propis centres de dades (en tenim diversos i la infraestructura és bastant gran).
Els avantatges del nostre sistema de monitorització són que amb la seva ajuda veiem l'estat de salut de tots els sistemes i podem avaluar el seu impacte entre ells i sobre els recursos compartits. I, en definitiva, ens permet participar en la planificació de recursos, que també és la nostra responsabilitat. Gestionem els recursos del servidor: un grup dins del comerç electrònic, la posada en servei i la retirada d'equips nous, la compra d'equips nous addicionals, la realització d'una auditoria de la utilització dels recursos, etc. Cada any, els equips planifiquen nous projectes, desenvolupen els seus sistemes i per nosaltres és important dotar-los de recursos.
I amb l'ajuda de mètriques, veiem la tendència en el consum de recursos dels nostres sistemes d'informació. I a partir d'ells podem planificar alguna cosa. A nivell de virtualització, recollim dades i veiem informació sobre la quantitat de recursos disponibles per centre de dades. I ja dins del centre de dades es pot veure el reciclatge, la distribució real i el consum dels recursos. A més, tant amb servidors autònoms com amb màquines virtuals i clústers de servidors físics sobre els quals totes aquestes màquines virtuals giren amb força.
Perspectives
Ara tenim el nucli del sistema en conjunt a punt, però encara queden moltes coses per treballar. Com a mínim, es tracta d'una capa de seguretat de la informació, però també és important arribar a la xarxa, desenvolupar alertes i resoldre el problema de la correlació. Tenim moltes capes i sistemes, i a cada capa hi ha moltes més mètriques. Resulta ser una matrioshka al grau de matrioshka.
La nostra tasca és, finalment, fer les alertes adequades. Per exemple, si hi havia un problema amb el maquinari, de nou, amb una màquina virtual, i hi havia una aplicació important, i no es feia una còpia de seguretat del servei de cap manera. Descobrim que la màquina virtual ha mort. Aleshores, les mètriques empresarials us avisaran: els usuaris han desaparegut en algun lloc, no hi ha conversió, la interfície d'usuari de la interfície no està disponible, el programari i els serveis també han mort.
En aquesta situació, rebrem correu brossa d'alertes, i això ja no encaixa en el format d'un sistema de seguiment adequat. Es planteja la qüestió de la correlació. Per tant, idealment, el nostre sistema de monitorització hauria de dir: "Nois, la vostra màquina física ha mort, i juntament amb ella aquesta aplicació i aquestes mètriques", amb l'ajuda d'una alerta, en lloc de bombardejar-nos furiós amb cent alertes. Hauria d'informar del principal: la causa, que ajuda a eliminar ràpidament el problema a causa de la seva localització.
El nostre sistema de notificacions i processament d'alertes es basa en un servei de línia directa les XNUMX hores. S'envien allà totes les alertes que es consideren imprescindibles i que s'inclouen a la llista de verificació. Cada alerta ha de tenir una descripció: què va passar, què significa realment, què afecta. I també un enllaç al tauler i instruccions sobre què fer en aquest cas.
Això es refereix als requisits per crear una alerta. Aleshores, la situació es pot desenvolupar en dues direccions: o hi ha un problema i s'ha de resoldre, o hi ha hagut una fallada en el sistema de seguiment. Però, en qualsevol cas, cal anar a esbrinar-ho.
De mitjana, ara rebem prop d'un centenar d'alertes al dia, tenint en compte que la correlació d'alertes encara no s'ha configurat correctament. I si hem de fer un treball tècnic i apaguem alguna cosa per la força, el seu nombre augmenta significativament.
A més de supervisar els sistemes que operem i recollir mètriques que es consideren importants per la nostra banda, el sistema de seguiment ens permet recollir dades per als equips de producte. Poden influir en la composició de mètriques dins dels sistemes d'informació que controlem.
El nostre company pot venir i demanar afegir alguna mètrica que serà útil tant per a nosaltres com per a l'equip. O, per exemple, és possible que l'equip no tingui prou de les mètriques bàsiques que tenim; han de fer un seguiment d'algunes específiques. A Grafana, creem un espai per a cada equip i atorguem drets d'administrador. A més, si un equip necessita taulers, però ells mateixos no poden/no saben com fer-ho, l'ajudem.
Com que estem fora del flux de creació de valor de l'equip, els seus llançaments i planificació, estem arribant gradualment a la conclusió que les versions de tots els sistemes són perfectes i es poden implementar diàriament sense coordinació amb nosaltres. I és important per a nosaltres supervisar aquestes versions, perquè podrien afectar el funcionament de l'aplicació i trencar alguna cosa, i això és fonamental. Per gestionar les versions, utilitzem Bamboo, des d'on rebem dades mitjançant API i podem veure quines versions s'han llançat en quins sistemes d'informació i el seu estat. I el més important és a quina hora. Superposem marcadors de llançament a les principals mètriques crítiques, la qual cosa és visualment molt indicatiu en cas de problemes.
D'aquesta manera podem veure la correlació entre els nous llançaments i els problemes emergents. La idea principal és entendre com funciona el sistema a totes les capes, localitzar ràpidament el problema i solucionar-lo amb la mateixa rapidesa. Al cap i a la fi, sovint passa que el que necessita més temps no és resoldre el problema, sinó buscar-ne la causa.
I en aquest àmbit en el futur volem centrar-nos en la proactivitat. L'ideal és que m'agradaria saber amb antelació sobre un problema que s'acosta, i no després del fet, per poder prevenir-lo en lloc de resoldre'l. De vegades es produeixen falses alarmes del sistema de monitorització, tant per error humà com per canvis en l'aplicació, i en això treballem, depurem i intentem avisar sobre això els usuaris que l'utilitzen amb nosaltres abans de qualsevol manipulació del sistema de monitoratge. , o realitzar aquestes activitats a la finestra tècnica.
Així doncs, el sistema s'ha posat en marxa i ha funcionat amb èxit des de principis de primavera... i està mostrant beneficis molt reals. Per descomptat, aquesta no és la seva versió final; introduirem moltes més funcions útils. Però ara mateix, amb tantes integracions i aplicacions, la supervisió de l'automatització és realment inevitable.
Si també feu un seguiment de grans projectes amb un nombre important d'integracions, escriviu als comentaris quina bala de plata heu trobat per això.
Font: www.habr.com