Hi!
Numele meu este Mihail, sunt director adjunct IT la compania Sportmaster. Vreau să vă împărtășesc povestea despre modul în care am abordat provocările apărute în timpul pandemiei.
În primele zile ale noilor realități, formatul obișnuit de tranzacționare offline al Sportmaster a înghețat, iar încărcarea pe canalul nostru online, în primul rând în ceea ce privește livrarea la adresa clientului, a crescut de 10 ori. În doar câteva săptămâni, am transformat o afacere gigantică offline într-una online și am adaptat serviciul la nevoile clienților noștri.
Practic, ceea ce era în esență operațiunea noastră secundară a devenit afacerea noastră de bază. Importanța fiecărei comenzi online a crescut extrem de mult. A fost necesar să se salveze fiecare rublă pe care clientul a adus-o companiei.
Pentru a răspunde rapid solicitărilor clienților, am deschis un centru de contact suplimentar la sediul principal al companiei, iar acum putem primi aproximativ 285 de mii de apeluri pe săptămână. În același timp, am mutat 270 de magazine într-un nou format de operare fără contact și sigur, care a permis clienților să primească comenzi și angajaților să-și mențină locurile de muncă.
În timpul procesului de transformare, am întâmpinat două probleme principale. În primul rând, sarcina resurselor noastre online a crescut semnificativ (Sergey vă va spune cum ne-am descurcat cu asta). În al doilea rând, fluxul de operațiuni rare (pre-COVID) a crescut de multe ori, ceea ce, la rândul său, a necesitat o cantitate mare de automatizare rapidă. Pentru a rezolva această problemă, a trebuit să transferăm rapid resurse din zonele care anterior erau principalele. Elena vă va spune cum ne-am descurcat cu asta.
Operarea serviciilor online
Kolesnikov Sergey, responsabil pentru funcționarea magazinului online și a microserviciilor
Din momentul în care magazinele noastre de vânzare cu amănuntul au început să se închidă de vizitatori, am început să înregistrăm o creștere a unor valori precum numărul de utilizatori, numărul de comenzi plasate în aplicația noastră și numărul de solicitări către aplicații.
Numărul de comenzi din 18 martie până în 31 martieNumărul de solicitări către microservicii de plată onlineNumărul de comenzi plasate pe site
În primul grafic vedem că creșterea a fost de aproximativ 14 ori, în al doilea - de 4 ori. Considerăm că metrica timpului de răspuns al aplicațiilor noastre este cea mai indicativă.
În acest grafic vedem răspunsul fronturilor și aplicațiilor, iar pentru noi înșine am stabilit că nu am observat nicio creștere ca atare.
Acest lucru se datorează în primul rând faptului că am început lucrările pregătitoare la sfârșitul anului 2019. Acum serviciile noastre sunt rezervate, toleranța la erori este asigurată la nivelul serverelor fizice, sistemelor de virtualizare, dockerelor și serviciilor din acestea. În același timp, capacitatea resurselor serverului nostru ne permite să suportăm mai multe sarcini.
Instrumentul principal care ne-a ajutat în toată această poveste a fost sistemul nostru de monitorizare. Adevărat, până de curând nu am avut un singur sistem care să ne permită să colectăm metrici la toate nivelurile, de la nivelul echipamentului fizic și hardware până la nivelul metricilor de business.
Formal, a existat monitorizare în companie, dar de regulă era dispersată și era în zona de responsabilitate a departamentelor specifice. De fapt, atunci când a avut loc un incident, aproape niciodată nu am avut o înțelegere comună a ceea ce s-a întâmplat exact, nu a existat nicio comunicare și, de multe ori, acest lucru ducea la alergarea în cerc pentru a găsi și izola problema, astfel încât să poată fi rezolvată.
La un moment dat, ne-am gândit și am decis că ne-am săturat să suportăm asta - aveam nevoie de un sistem unificat pentru a vedea întreaga imagine în întregime. Principalele tehnologii care sunt incluse în stiva noastră sunt Zabbix ca centru de alertă și stocare de metrici, Prometheus pentru colectarea și stocarea metricilor aplicației, Stack ELK pentru înregistrarea și stocarea datelor din întregul sistem de monitorizare, precum și Grafana pentru vizualizare, Swagger, Docker și alte lucruri utile și care vă sunt familiare.
În același timp, folosim nu numai tehnologiile disponibile pe piață, ci și dezvoltăm unele dintre ele proprii. De exemplu, realizăm servicii pentru integrarea sistemelor între ele, adică un fel de API pentru colectarea de valori. În plus, lucrăm la propriile noastre sisteme de monitorizare - la nivel de metrici de afaceri folosim teste UI. Și, de asemenea, un bot în Telegram pentru a notifica echipele.
Încercăm, de asemenea, să facem sistemul de monitorizare accesibil echipelor, astfel încât acestea să poată stoca în mod independent și să lucreze cu valorile lor, inclusiv setarea de alerte pentru unele valori înguste care nu sunt utilizate pe scară largă.
În întregul sistem, ne străduim să obținem proactivitate și localizarea incidentelor cât mai repede posibil. În plus, numărul microserviciilor și sistemelor noastre a crescut semnificativ în ultima perioadă, iar numărul integrărilor a crescut în consecință. Și ca parte a optimizării procesului de diagnosticare a incidentelor la nivel de integrare, dezvoltăm un sistem care vă permite să efectuați verificări între sisteme și să afișați rezultatul, ceea ce vă permite să găsiți principalele probleme asociate cu importurile și interacțiunea sistemelor cu reciproc.
Bineînțeles, mai avem loc să creștem și să ne dezvoltăm în ceea ce privește sistemele de operare și lucrăm activ la acest lucru. Puteți citi mai multe despre sistemul nostru de monitorizare .
Teste tehnice
Orlov Sergey, șeful centrului de competențe pentru dezvoltare web și mobilă
De când au început închiderea magazinelor fizice, ne-am confruntat cu diverse provocări din perspectiva dezvoltării. În primul rând, creșterea de sarcină ca atare. Este clar că, dacă nu sunt luate măsurile adecvate, atunci când se aplică o sarcină mare sistemului, acesta se poate transforma într-un dovleac cu o bubuitură tristă sau se poate degrada complet în performanță sau chiar își poate pierde funcționalitatea.
Al doilea aspect, puțin mai puțin evident, este că sistemul aflat sub sarcină mare a trebuit schimbat foarte rapid, adaptându-se la schimbările din procesele de afaceri. Uneori de mai multe ori pe zi. Multe companii au o regulă conform căreia, dacă există multă activitate de marketing, nu este nevoie să faci nicio modificare în sistem. Deloc, lăsați-l să funcționeze atâta timp cât funcționează.
Și, în esență, am avut o Vinere Neagră nesfârșită, timp în care a fost necesară schimbarea sistemului. Și orice eroare, problemă sau eșec în sistem ar fi foarte costisitoare pentru afacere.
Privind în perspectivă, voi spune că am reușit să facem față acestor teste, toate sistemele au rezistat sarcinii, au fost ușor scalate și nu am experimentat nicio defecțiune tehnică globală.
Există patru piloni pe care se bazează capacitatea sistemului de a rezista la supratensiuni mari. Prima dintre ele este monitorizarea, despre care ați citit chiar mai sus. Fără un sistem de monitorizare încorporat, este aproape imposibil să găsiți blocaje ale sistemului. Un sistem de monitorizare bun este ca hainele de acasă; ar trebui să fie confortabil și adaptat pentru tine.
Al doilea aspect este testarea. Luăm acest punct foarte în serios: scriem unități clasice, teste de integrare, teste de încărcare și multe altele pentru fiecare sistem. De asemenea, scriem o strategie de testare și, în același timp, încercăm să creștem nivelul de testare până la punctul în care nu mai avem nevoie de verificări manuale.
Al treilea pilon este CI/CD Pipeline. Procesele de construire, testare și implementare a unei aplicații ar trebui să fie automatizate cât mai mult posibil; nu ar trebui să existe nicio intervenție manuală. Subiectul CI/CD Pipeline este destul de profund și îl voi aborda doar pe scurt. Merită doar menționat că avem o listă de verificare CI/CD Pipeline, pe care o parcurge fiecare echipă de produs cu ajutorul centrelor de competențe.
Și aici este lista de verificare
În acest fel, multe obiective sunt atinse. Aceasta este versiunea API și comutarea funcțiilor pentru a evita trenul de lansare și pentru a obține acoperirea diferitelor teste la un astfel de nivel încât testarea este complet automatizată, implementările sunt fără probleme și așa mai departe.
Al patrulea pilon îl reprezintă principiile arhitecturale și soluțiile tehnice. Putem vorbi mult despre arhitectură pentru o lungă perioadă de timp, dar vreau să subliniez câteva principii pe care aș dori să mă concentrez.
În primul rând, trebuie să alegeți instrumente specializate pentru sarcini specifice. Da, sună evident și este clar că cuiele trebuie băgate cu un ciocan, iar ceasurile de mână trebuie dezasamblate cu șurubelnițe speciale. Dar în epoca noastră, multe instrumente se străduiesc pentru universalizare pentru a acoperi segmentul maxim de utilizatori: baze de date, cache, cadre și restul. De exemplu, dacă luați baza de date MongoDB, aceasta funcționează cu tranzacții cu mai multe documente, iar baza de date Oracle funcționează cu json. Și s-ar părea că totul poate fi folosit pentru orice. Dar dacă susținem productivitatea, atunci trebuie să înțelegem clar punctele forte și punctele slabe ale fiecărui instrument și să le folosim pe cele de care avem nevoie pentru clasa noastră de sarcini.
În al doilea rând, la proiectarea sistemelor, fiecare creștere a complexității trebuie justificată. Trebuie să ținem cont de acest lucru în mod constant; principiul cuplajului scăzut este cunoscut de toată lumea. Consider că ar trebui aplicată la nivelul unui serviciu anume, și la nivelul întregului sistem, și la nivelul peisajului arhitectural. Abilitatea de a scala orizontal fiecare componentă a sistemului de-a lungul căii de încărcare este, de asemenea, importantă. Dacă aveți această abilitate, scalarea nu va fi dificilă.
Apropo de soluții tehnice, am cerut echipelor de produse să pregătească un nou set de recomandări, idei și soluții, pe care le-au implementat în pregătirea pentru următorul val de volum de muncă.
Keshi
Este necesar să se abordeze în mod conștient alegerea cache-urilor locale și distribuite. Uneori este logic să le folosim pe ambele în cadrul aceluiași sistem. De exemplu, avem sisteme în care unele dintre date sunt în esență un cache-vitrină, adică sursa actualizărilor se află în spatele sistemului însuși, iar sistemele nu se schimbă. aceste date. Pentru această abordare folosim local Caffeine Cache.
Și există date despre care sistemul se schimbă în mod activ în timpul funcționării, iar aici deja folosim un cache distribuit cu Hazelcast. Această abordare ne permite să folosim beneficiile unui cache distribuit acolo unde sunt cu adevărat necesare și să minimizăm costurile de serviciu ale circulației datelor cluster Hazelcast acolo unde ne putem descurca fără ele. Am scris multe despre cache-uri. и .
În plus, schimbarea serializatorului cu Kryo în Hazelcast ne-a dat un impuls bun. Iar tranziția de la ReplicatedMap la IMap + Near Cache în Hazelcast ne-a permis să minimizăm mișcarea datelor în cluster.
Un mic sfat: în cazul invalidării cache-ului în masă, uneori se aplică tactica de a încălzi al doilea cache și apoi de a trece la acesta. S-ar părea că prin această abordare ar trebui să obținem un consum dublu de memorie, dar în practică, în acele sisteme în care s-a practicat acest lucru, consumul de memorie a scăzut.
Stiva reactivă
Folosim stiva reactivă într-un număr destul de mare de sisteme. În cazul nostru, acesta este Webflux sau Kotlin cu coroutine. Stiva reactivă este deosebit de bună acolo unde ne așteptăm la operațiuni de intrare-ieșire lente. De exemplu, apeluri la servicii lente, lucrul cu sistemul de fișiere sau sistemele de stocare.
Cel mai important principiu este evitarea blocării apelurilor. Cadrele reactive au un număr mic de fire de serviciu live care rulează sub capotă. Dacă ne permitem neglijent să facem un apel de blocare directă, cum ar fi un apel de driver JDBC, sistemul se va opri pur și simplu.
Încercați să transformați erorile în propria dvs. excepție de rulare. Fluxul real de execuție a programului trece la cadre reactive, iar execuția codului devine neliniară. Ca rezultat, este foarte dificil să diagnosticați problemele folosind urmele stivei. Iar soluția aici ar fi crearea de excepții clare și obiective de rulare pentru fiecare eroare.
Elasticsearch
Când utilizați Elasticsearch, nu selectați datele neutilizate. Acesta, în principiu, este și un sfat foarte simplu, dar cel mai adesea acesta este ceea ce se uită. Dacă trebuie să selectați mai mult de 10 mii de înregistrări simultan, trebuie să utilizați Scroll. Pentru a folosi o analogie, este un pic ca un cursor într-o bază de date relațională.
Nu utilizați postfiltru decât dacă este necesar. Cu date mari în eșantionul principal, această operațiune încarcă foarte mult baza de date.
Utilizați operațiuni în vrac acolo unde este cazul.
API
Când proiectați un API, includeți cerințe pentru minimizarea datelor transmise. Acest lucru este valabil mai ales în legătură cu partea frontală: tocmai la această intersecție trecem dincolo de canalele centrelor noastre de date și lucrăm deja la canalul care ne conectează cu clientul. Dacă are cea mai mică problemă, prea mult trafic provoacă o experiență negativă pentru utilizator.
Și, în sfârșit, nu aruncați o grămadă de date, fiți clar despre contractul dintre consumatori și furnizori.
Transformarea organizațională
Eroshkina Elena, director adjunct pentru IT
În momentul în care a avut loc carantina și a apărut nevoia de a crește brusc ritmul dezvoltării online și de a introduce servicii omnicanal, eram deja în proces de transformare organizațională.
O parte din structura noastră a fost transferată la lucru conform principiilor și practicilor abordării produsului. S-au format echipe care sunt acum responsabile de operarea și dezvoltarea fiecărui produs. Angajații din astfel de echipe sunt 100% implicați și își structurează munca folosind Scrum sau Kanban, în funcție de ceea ce este de preferat lor, creând un pipeline de implementare, implementând practici tehnice, practici de asigurare a calității și multe altele.
Din fericire, cea mai mare parte a echipelor noastre de produse au fost în zona serviciilor online și omnicanal. Acest lucru ne-a permis să trecem la modul de lucru la distanță în cel mai scurt timp posibil (serios, literalmente în două zile) fără pierderi de eficiență. Procesul personalizat ne-a permis să ne adaptăm rapid la noile condiții de lucru și să menținem un ritm destul de ridicat de livrare a noilor funcționalități.
În plus, avem nevoie să consolidăm acele echipe care se află la granița afacerilor online. În acel moment a devenit clar că nu putem face asta decât folosind resurse interne. Și aproximativ 50 de oameni în două săptămâni au schimbat zona în care lucrau înainte și s-au implicat în lucrul la un produs care era nou pentru ei.
Acest lucru nu a necesitat eforturi deosebite de management, deoarece pe lângă organizarea propriului proces, îmbunătățirea tehnică a produsului și practicile de asigurare a calității, învățăm echipele noastre să se autoorganizeze - să-și gestioneze propriul proces de producție fără a implica resurse administrative.
Am putut să ne concentrăm resursele de management exact acolo unde era nevoie în acel moment - pe coordonarea împreună cu afacerea: ce este important pentru clientul nostru în acest moment, ce funcționalitate ar trebui implementată mai întâi, ce trebuie făcut pentru a crește capacitatea noastră de debit pentru a livra și procesa comenzile. Toate acestea și un model clar de urmat au făcut posibilă în această perioadă să ne încărcăm fluxurile valorice de producție cu ceea ce este cu adevărat important și necesar.
Este clar că, cu munca la distanță și un ritm ridicat de schimbare, când indicatorii de afaceri depind de participarea tuturor, nu te poți baza doar pe sentimentele interne din seria „Totul merge bine cu noi? Da, pare bine.” Sunt necesare metrici obiective ale procesului de producție. Avem acestea, sunt disponibile pentru oricine este interesat de valorile echipelor de produse. În primul rând, echipa în sine, afacerea, subcontractanții și managementul.
O dată la două săptămâni, se ține un status cu fiecare echipă, unde metricile sunt analizate timp de 10 minute, se identifică blocajele în procesul de producție și se dezvoltă o soluție comună: ce se poate face pentru a elimina aceste blocaje. Aici puteți cere imediat ajutor de la conducere dacă vreo problemă identificată se află în afara zonei de influență a echipelor sau expertiza colegilor care s-ar fi confruntat deja cu o problemă similară.
Totuși, înțelegem că pentru a accelera de mai multe ori (și tocmai acesta este scopul pe care ni l-am propus), încă trebuie să învățăm multe și să le implementăm în munca noastră de zi cu zi. În acest moment, continuăm să ne extindem abordarea asupra produselor către alte echipe și produse noi. Pentru a face acest lucru, a trebuit să stăpânim un nou format pentru noi - o școală online de metodologi.
Metodologii, oameni care ajută echipele să construiască un proces, să stabilească comunicații și să îmbunătățească eficiența muncii, sunt în esență agenți ai schimbării. În acest moment, absolvenții primei noastre cohorte lucrează cu echipe și îi ajută să aibă succes.
Cred că situația actuală ne deschide oportunități și perspective de care poate că noi înșine nu suntem încă pe deplin conștienți. Dar experiența și practica pe care le dobândim chiar acum confirmă că am ales calea corectă de dezvoltare, nu vom rata aceste noi oportunități în viitor și vom putea răspunde la fel de eficient provocărilor cu care se va confrunta Sportmaster.
Constatări
În această perioadă dificilă, am formulat principalele principii pe care se bazează dezvoltarea software-ului, care cred că vor fi relevante pentru fiecare companie care se ocupă de asta.
Oameni. Pe asta se bazează totul. Angajații trebuie să se bucure de munca lor și să înțeleagă obiectivele companiei și obiectivele produselor la care lucrează. Și, desigur, s-ar putea dezvolta profesional.
Технология. Este necesar ca compania să adopte o abordare matură pentru a lucra cu tehnologia sa și să-și construiască competențe acolo unde este cu adevărat nevoie. Sună foarte simplu și evident. Și de foarte multe ori ignorate.
Procesele. Este important să se organizeze corect munca echipelor de produs și a centrelor de competență, să stabilească interacțiunea cu afacerea pentru a lucra cu aceasta ca partener.
În general, cam așa am supraviețuit. Teza principală a timpului nostru a fost confirmată încă o dată, cu un clic răsunător pe frunte
Chiar dacă sunteți o afacere offline uriașă, cu multe magazine și o grămadă de orașe în care activezi, dezvoltă-ți afacerea online. Acesta nu este doar un canal suplimentar de vânzări sau o aplicație frumoasă prin care puteți cumpăra și ceva (și tot pentru că concurenții au și ele frumoase). Aceasta nu este o anvelopă de rezervă pentru a vă ajuta să faceți față furtunii.
Aceasta este o necesitate absolută. Pentru care trebuie să fie pregătite nu numai capacitățile și infrastructura dumneavoastră tehnice, ci și oamenii și procesele dumneavoastră. La urma urmei, puteți cumpăra rapid memorie suplimentară, spațiu, puteți implementa instanțe noi etc. în câteva ore. Dar oamenii și procesele trebuie să fie pregătite în avans pentru asta.
Sursa: www.habr.com