Hi!
Em dic Mikhail, sóc el director adjunt d'IT de l'empresa Sportmaster. Vull compartir la història de com vam afrontar els reptes que van sorgir durant la pandèmia.
En els primers dies de les noves realitats, el format habitual de comerç fora de línia de Sportmaster es va congelar i la càrrega del nostre canal en línia, principalment pel que fa al lliurament a l'adreça del client, va augmentar 10 vegades. En poques setmanes vam transformar un enorme negoci offline en un de online i vam adaptar el servei a les necessitats dels nostres clients.
Bàsicament, el que era essencialment la nostra operació secundària es va convertir en el nostre negoci principal. La importància de cada comanda en línia ha augmentat moltíssim. Calia estalviar cada ruble que el client va portar a l'empresa.
Per respondre ràpidament a les sol·licituds dels clients, vam obrir un centre de contacte addicional a l'oficina principal de l'empresa, i ara podem rebre unes 285 mil trucades per setmana. Paral·lelament, vam traslladar 270 botigues a un nou format operatiu sense contacte i segur, que va permetre als clients rebre comandes i als empleats mantenir la seva feina.
Durant el procés de transformació, vam trobar dos problemes principals. En primer lloc, la càrrega dels nostres recursos en línia ha augmentat significativament (Sergey us explicarà com hem tractat això). En segon lloc, el flux d'operacions rares (pre-COVID) ha augmentat moltes vegades, cosa que al seu torn requeria una gran quantitat d'automatització ràpida. Per solucionar aquest problema, hem hagut de transferir ràpidament recursos de les àrees que abans eren les principals. L'Elena t'explicarà com hem tractat això.
Funcionament dels serveis en línia
Kolesnikov Sergey, responsable del funcionament de la botiga en línia i dels microserveis
Des del moment en què les nostres botigues minoristes van començar a tancar als visitants, vam començar a registrar un augment de mètriques com ara el nombre d'usuaris, el nombre de comandes realitzades a la nostra aplicació i el nombre de sol·licituds a les aplicacions.
Nombre de comandes del 18 al 31 de marçNombre de sol·licituds a microserveis de pagament en líniaNombre de comandes realitzades al lloc web
En el primer gràfic veiem que l'augment va ser d'aproximadament 14 vegades, en el segon - 4 vegades. Considerem que la mètrica del temps de resposta de les nostres aplicacions és la més indicativa.
En aquest gràfic veiem la resposta de fronts i aplicacions, i per nosaltres mateixos vam determinar que no vam notar cap creixement com a tal.
Això es deu principalment al fet que vam començar els treballs preparatoris a finals del 2019. Ara els nostres serveis estan reservats, la tolerància a fallades està assegurada a nivell de servidors físics, sistemes de virtualització, dockers i serveis en ells. Al mateix temps, la capacitat dels recursos del nostre servidor ens permet suportar múltiples càrregues.
La principal eina que ens va ajudar en tota aquesta història va ser el nostre sistema de seguiment. És cert que fins fa ben poc no teníem un únic sistema que ens permetés recollir mètriques a totes les capes, des del nivell d'equip físic i maquinari fins al nivell de mètriques empresarials.
Formalment, hi havia un seguiment a l'empresa, però per regla general estava dispers i estava a l'àrea de responsabilitat de departaments específics. De fet, quan es produïa un incident, gairebé mai no teníem una comprensió comuna del que passava exactament, no hi havia comunicació, i sovint això portava a córrer en cercles per trobar i aïllar el problema perquè es pogués solucionar.
En algun moment, vam pensar i vam decidir que en teníem prou d'aguantar això: necessitàvem un sistema unificat per veure tota la imatge. Les principals tecnologies que s'inclouen a la nostra pila són Zabbix com a centre d'alertes i emmagatzematge de mètriques, Prometheus per recollir i emmagatzemar mètriques d'aplicacions, Stack ELK per registrar i emmagatzemar dades de tot el sistema de monitorització, així com Grafana per a la visualització, Swagger, Docker i altres coses útils i que us són familiars.
Al mateix temps, utilitzem no només les tecnologies disponibles al mercat, sinó que també en desenvolupem algunes de les nostres. Per exemple, fem serveis per integrar sistemes entre si, és a dir, algun tipus d'API per recollir mètriques. A més, estem treballant en els nostres propis sistemes de supervisió: a nivell de mètriques empresarials fem servir proves d'IU. I també un bot a Telegram per avisar els equips.
També estem intentant que el sistema de monitorització sigui accessible als equips perquè puguin emmagatzemar i treballar de manera independent amb les seves mètriques, inclosa la configuració d'alertes per a algunes mètriques reduïdes que no s'utilitzen àmpliament.
En tot el sistema, ens esforcem per la proactivitat i la localització d'incidències el més aviat possible. A més, el nombre dels nostres microserveis i sistemes ha crescut significativament recentment i el nombre d'integracions ha crescut en conseqüència. I com a part de l'optimització del procés de diagnòstic d'incidències a nivell d'integració, estem desenvolupant un sistema que permet realitzar comprovacions entre sistemes i mostrar el resultat, que permet trobar els principals problemes associats a les importacions i la interacció dels sistemes amb un altre.
Per descomptat, encara tenim marge per créixer i desenvolupar-nos en termes de sistemes operatius, i estem treballant activament en això. Podeu llegir més sobre el nostre sistema de monitoratge .
Proves tècniques
Orlov Sergey, dirigeix el centre de competència per al desenvolupament web i mòbil
Des que van començar els tancaments de les botigues físiques, ens hem enfrontat a diversos reptes des d'una perspectiva de desenvolupament. En primer lloc, l'augment de càrrega com a tal. És evident que si no es prenen les mesures adequades, quan s'aplica una càrrega elevada al sistema, es pot convertir en una carbassa amb un esclat trist, o degradar-se completament o fins i tot perdre la seva funcionalitat.
El segon aspecte, una mica menys evident, és que el sistema amb alta càrrega s'havia de canviar molt ràpidament, adaptant-se als canvis dels processos empresarials. De vegades diverses vegades al dia. Moltes empreses tenen una regla que, si hi ha molta activitat de màrqueting, no cal fer cap canvi al sistema. Cap, deixa que funcioni mentre funcioni.
I bàsicament vam tenir un Black Friday interminable, durant el qual va ser necessari canviar el sistema. I qualsevol error, problema o fallada en el sistema seria molt costós per al negoci.
De cara al futur, diré que vam aconseguir fer front a aquestes proves, tots els sistemes van suportar la càrrega, es van escalar fàcilment i no vam experimentar cap fallada tècnica global.
Hi ha quatre pilars sobre els quals descansa la capacitat del sistema de suportar càrregues de sobretensió elevades. El primer d'ells és el monitoratge, del qual llegiu just a dalt. Sense un sistema de control integrat, és gairebé impossible trobar colls d'ampolla del sistema. Un bon sistema de control és com la roba de casa; hauria de ser còmode i adaptar-se a tu.
El segon aspecte és la prova. Ens prenem aquest punt molt seriosament: escrivim unitats clàssiques, proves d'integració, proves de càrrega i moltes altres per a cada sistema. També estem escrivint una estratègia de proves i, al mateix temps, intentem augmentar el nivell de proves fins al punt que ja no necessitem comprovacions manuals.
El tercer pilar és CI/CD Pipeline. Els processos de creació, prova i desplegament d'una aplicació s'han d'automatitzar tant com sigui possible; no hi hauria d'haver cap intervenció manual. El tema de CI/CD Pipeline és força profund, i només el tocaré breument. Només val la pena esmentar que disposem d'una llista de comprovació CI/CD Pipeline, que cada equip de producte revisa amb l'ajuda dels centres de competència.
I aquí teniu la llista de verificació
D'aquesta manera s'assoleixen molts objectius. Es tracta de versions de l'API i de canvi de funcions per evitar el tren de llançament i aconseguir la cobertura de diverses proves a un nivell tal que les proves estiguin totalment automatitzades, els desplegaments siguin perfectes, etc.
El quart pilar són els principis arquitectònics i les solucions tècniques. Podem parlar molt d'arquitectura durant molt de temps, però vull destacar un parell de principis en els quals m'agradaria incidir.
En primer lloc, heu de triar eines especialitzades per a tasques específiques. Sí, sembla obvi, i és clar que els claus s'han de posar amb un martell i els rellotges de polsera s'han de desmuntar amb tornavís especials. Però a la nostra època, moltes eines s'esforcen per la universalització per tal de cobrir el màxim segment d'usuaris: bases de dades, memòria cau, frameworks i la resta. Per exemple, si preneu la base de dades MongoDB, funciona amb transaccions de diversos documents i la base de dades Oracle funciona amb json. I sembla que tot es pot utilitzar per a tot. Però si defensem la productivitat, hem d'entendre clarament els punts forts i febles de cada eina i utilitzar les que necessitem per a la nostra classe de tasques.
En segon lloc, a l'hora de dissenyar sistemes, cal justificar cada augment de complexitat. Hem de tenir-ho en compte constantment; el principi d'acoblament baix és conegut per tothom. Crec que s'ha d'aplicar a nivell d'un servei concret, i a nivell de tot el sistema, i a nivell del paisatge arquitectònic. També és important la capacitat d'escalar horitzontalment cada component del sistema al llarg del camí de càrrega. Si teniu aquesta habilitat, escalar no serà difícil.
Parlant de solucions tècniques, vam demanar als equips de producte que preparessin un nou conjunt de recomanacions, idees i solucions, que van implementar en preparació per a la següent onada de càrrega de treball.
Keshi
Cal abordar conscientment l'elecció de la memòria cau local i distribuïda. De vegades té sentit utilitzar tots dos dins del mateix sistema. Per exemple, tenim sistemes en què algunes de les dades són essencialment una memòria cau d'aparador, és a dir, la font de les actualitzacions es troba darrere del propi sistema i els sistemes no canvien. aquestes dades. Per a aquest enfocament utilitzem Caffeine Cache local.
I hi ha dades que el sistema canvia activament durant el funcionament, i aquí ja estem utilitzant una memòria cau distribuïda amb Hazelcast. Aquest enfocament ens permet utilitzar els avantatges d'una memòria cau distribuïda on realment es necessiten i minimitzar els costos de servei de la circulació de dades del clúster Hazelcast on podem prescindir-ne. Hem escrit molt sobre els cachés. и .
A més, canviar el serialitzador a Kryo a Hazelcast ens va donar un bon impuls. I la transició de ReplicatedMap a IMap + Near Cache a Hazelcast ens va permetre minimitzar el moviment de dades al clúster.
Un petit consell: en cas d'invalidació de la memòria cau massiva, de vegades és aplicable la tàctica d'escalfar la segona memòria cau i després canviar-la. Sembla que amb aquest plantejament hauríem d'aconseguir el doble consum de memòria, però a la pràctica, en aquells sistemes on això es practicava, el consum de memòria va disminuir.
Pila reactiva
Utilitzem la pila reactiva en un nombre bastant gran de sistemes. En el nostre cas, es tracta de Webflux o Kotlin amb coroutines. La pila reactiva és especialment bona quan esperem operacions d'entrada-sortida lentes. Per exemple, trucades a serveis lents, treballant amb el sistema de fitxers o sistemes d'emmagatzematge.
El principi més important és evitar el bloqueig de trucades. Els marcs reactius tenen un petit nombre de fils de servei en directe que s'executen sota el capó. Si descuidament ens permetem fer una trucada de bloqueig directe, com ara una trucada al controlador JDBC, el sistema simplement s'aturarà.
Intenteu convertir els errors en la vostra pròpia excepció de temps d'execució. El flux real d'execució del programa es desplaça cap a marcs reactius i l'execució del codi esdevé no lineal. Com a resultat, és molt difícil diagnosticar problemes mitjançant traces de pila. I la solució aquí seria crear excepcions d'execució clares i objectives per a cada error.
Elasticsearch
Quan utilitzeu Elasticsearch, no seleccioneu les dades no utilitzades. Aquest, en principi, també és un consell molt senzill, però sovint això és el que s'oblida. Si necessiteu seleccionar més de 10 mil registres alhora, heu d'utilitzar Scroll. Per utilitzar una analogia, és una mica com un cursor en una base de dades relacional.
No utilitzeu postfiltre tret que sigui necessari. Amb dades grans a la mostra principal, aquesta operació carrega molt la base de dades.
Utilitzeu operacions a granel si escau.
API
Quan dissenyeu una API, incloeu requisits per minimitzar les dades transmeses. Això és especialment cert en relació amb el front: és en aquesta cruïlla on anem més enllà dels canals dels nostres centres de dades i ja estem treballant en el canal que ens connecta amb el client. Si té el més mínim problema, massa trànsit provoca una experiència d'usuari negativa.
I finalment, no llenceu un munt de dades, tingueu clar el contracte entre consumidors i proveïdors.
Transformació organitzativa
Eroshkina Elena, directora adjunta d'IT
En el moment en què es va produir la quarantena i va sorgir la necessitat d'augmentar el ritme de desenvolupament en línia i introduir serveis omnicanal, ja estàvem en procés de transformació organitzativa.
Part de la nostra estructura es va traslladar a treballar d'acord amb els principis i pràctiques de l'enfocament del producte. S'han format equips que ara s'encarreguen del funcionament i desenvolupament de cada producte. Els empleats d'aquests equips estan 100% implicats i estructuren el seu treball mitjançant Scrum o Kanban, depenent del que els sigui preferible, establint un pipeline de desplegament, implementant pràctiques tècniques, pràctiques de garantia de qualitat i molt més.
Per sort, la major part dels nostres equips de producte es trobaven a l'àrea de serveis en línia i omnicanal. Això ens va permetre canviar al mode de treball remot en el menor temps possible (de debò, literalment en dos dies) sense pèrdua d'eficiència. El procés personalitzat ens va permetre adaptar-nos ràpidament a les noves condicions de treball i mantenir un ritme força elevat de lliurament de noves funcionalitats.
A més, tenim la necessitat d'enfortir aquells equips que es troben a la frontera del negoci en línia. En aquell moment va quedar clar que només podíem fer-ho amb recursos interns. I unes 50 persones en dues setmanes van canviar la zona on treballaven abans i es van involucrar en el treball en un producte que era nou per a ells.
Això no va requerir cap esforç de gestió especial, perquè juntament amb l'organització del nostre propi procés, la millora tècnica del producte i les pràctiques d'assegurament de la qualitat, ensenyem als nostres equips a autoorganitzar-se, a gestionar el seu propi procés productiu sense implicar recursos administratius.
Vam poder centrar els nostres recursos de gestió exactament allà on es necessitava en aquell moment: en coordinar-nos amb el negoci: què és important per al nostre client ara mateix, quina funcionalitat s'hauria d'implementar primer, què cal fer per augmentar la nostra capacitat de rendiment. per lliurar i processar comandes. Tot això i un model clar va fer possible durant aquest període carregar els nostres fluxos de valor de producció amb allò que és realment important i necessari.
És evident que amb el treball a distància i un alt ritme de canvi, quan els indicadors empresarials depenen de la participació de tothom, no es pot confiar només en els sentiments interns de la sèrie “Ens va tot bé? Sí, sembla bé." Es necessiten mètriques objectives del procés de producció. Tenim aquests, estan disponibles per a qualsevol persona que estigui interessada en les mètriques dels equips de producte. En primer lloc, el propi equip, el negoci, els subcontractistes i la direcció.
Cada dues setmanes es fa un estat amb cada equip, on s'analitzen les mètriques durant 10 minuts, s'identifiquen els colls d'ampolla en el procés de producció i es desenvolupa una solució conjunta: què es pot fer per eliminar aquests colls d'ampolla. Aquí podeu demanar ajuda immediatament a la direcció si algun problema identificat està fora de la zona d'influència dels equips, o l'experiència de companys que ja s'hagin trobat amb un problema similar.
Tanmateix, entenem que per accelerar diverses vegades (i aquest és exactament l'objectiu que ens plantegem), encara hem d'aprendre molt i implementar-ho en el nostre treball diari. Ara mateix seguim ampliant el nostre enfocament de producte a altres equips i productes nous. Per fer-ho, vam haver de dominar un nou format per a nosaltres: una escola en línia de metodològics.
Els metodistes, persones que ajuden els equips a construir un procés, establir comunicacions i millorar l'eficiència laboral, són essencialment agents de canvi. Ara mateix, els graduats de la nostra primera cohort estan treballant amb equips i els ajuden a tenir èxit.
Crec que la situació actual ens obre oportunitats i perspectives que potser nosaltres mateixos encara no som del tot conscients. Però l'experiència i la pràctica que estem adquirint ara mateix ens confirma que hem triat el camí correcte de desenvolupament, no perdrem aquestes noves oportunitats en el futur i podrem respondre amb la mateixa eficàcia als reptes als quals s'enfrontarà Sportmaster.
Troballes
Durant aquest moment difícil, hem formulat els principis principals sobre els quals es basa el desenvolupament de programari, que crec que seran rellevants per a totes les empreses que s'ocupen d'això.
Persones. En això es basa tot. Els empleats han de gaudir de la seva feina i entendre els objectius de l'empresa i els objectius dels productes en què treballen. I, per descomptat, podrien desenvolupar-se professionalment.
Технология. És necessari que l'empresa adopti un enfocament madur per treballar amb la seva pila tecnològica i crear competències allà on realment es necessita. Sona molt senzill i evident. I molt sovint ignorat.
Процессы. És important organitzar correctament el treball dels equips de producte i dels centres de competència, establir interacció amb el negoci per poder treballar amb ell com a soci.
En general, així és com vam sobreviure. La tesi principal del nostre temps es va confirmar una vegada més, amb un clic rotund al front
Fins i tot si sou un gran negoci fora de línia amb moltes botigues i un munt de ciutats on opereu, desenvolupeu el vostre negoci en línia. Això no és només un canal de venda addicional o una aplicació bonica a través de la qual també pots comprar alguna cosa (i també perquè els competidors també en tenen de boniques). Aquest no és un pneumàtic de recanvi per ajudar-vos a resistir la tempesta.
Això és una necessitat absoluta. Per al qual s'han de preparar no només les vostres capacitats tècniques i infraestructura, sinó també les vostres persones i processos. Després de tot, podeu comprar ràpidament memòria addicional, espai, desplegar noves instàncies, etc. en un parell d'hores. Però les persones i els processos han d'estar preparats per a això amb antelació.
Font: www.habr.com