{"id":83188,"date":"2020-05-29T07:43:02","date_gmt":"2020-05-29T05:43:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali"},"modified":"2020-05-29T07:43:02","modified_gmt":"2020-05-29T05:43:02","slug":"kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-my-perezhili-rezkij-rost-nagruzki-x10-na-udalenke-i-kakie-vyvody-sdelali","title":{"rendered":"Cum am supravie\u021buit unei cre\u0219teri bruste a \u00eenc\u0103rc\u0103rii de 10 ori \u00een regimul de lucru la distan\u021b\u0103 \u0219i ce concluzii am tras.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bun\u0103, Habr! \u00cen ultimele c\u00e2teva luni, am tr\u0103it o situa\u021bie foarte interesant\u0103 \u0219i a\u0219 dori s\u0103 \u00eemp\u0103rt\u0103\u0219esc povestea noastr\u0103 despre scalarea infrastructurii. \u00cen acest timp, SberMarket a crescut de patru ori \u00een comenzi \u0219i a lansat serviciul \u00een 17 ora\u0219e noi. Cre\u0219terea exploziv\u0103 a cererii de livrare a produselor a necesitat extinderea infrastructurii. Cite\u0219te mai departe pentru cele mai interesante \u0219i utile concluzii.<\/p>\n

\"Cum
\n<\/a><\/noindex>
\nM\u0103 numesc Dima Bobylev, sunt directorul tehnic al SberMarket. Deoarece acesta este primul post din blogul nostru, voi spune c\u00e2teva cuvinte despre mine \u0219i despre companie. \u00cen toamna trecut\u0103, am participat la concursul tinerilor lideri din Runet. Pentru acest concurs, am scris o poveste scurt\u0103<\/a><\/noindex> despre cum vedem noi, la SberMarket, cultura intern\u0103 \u0219i abordarea dezvolt\u0103rii serviciului. \u0218i de\u0219i nu am c\u00e2\u0219tigat concursul, am reu\u0219it s\u0103-mi formulez principii fundamentale pentru dezvoltarea ecosistemului IT. <\/p>\n

Atunci c\u00e2nd gestionezi o echip\u0103, este important s\u0103 \u00een\u021belegi \u0219i s\u0103 g\u0103se\u0219ti un echilibru \u00eentre ceea ce este necesar pentru afacere \u0219i nevoile fiec\u0103rui dezvoltator \u00een parte. \u00cen prezent, SberMarket cre\u0219te de 13 ori pe an, iar acest lucru influen\u021beaz\u0103 produsul, impun\u00e2nd o cre\u0219tere constant\u0103 a volumului \u0219i a ritmului de dezvoltare. Cu toate acestea, aloc\u0103m suficient timp dezvoltatorilor pentru analiza preliminar\u0103 \u0219i scrierea de cod de calitate. Abordarea stabilit\u0103 ajut\u0103 nu doar la crearea unui produs func\u021bional, ci \u0219i la scalarea \u0219i dezvoltarea acestuia \u00een continuare. Ca rezultat al acestei cre\u0219teri, SberMarket a devenit deja lider printre serviciile de livrare a produselor: livr\u0103m zilnic aproximativ 18.000 de comenzi pe zi, de\u0219i la \u00eenceputul lunii februarie erau \u00een jur de 3.500.<\/p>\n

\"Cum
\nOdat\u0103, un client a cerut curierului SberMarket s\u0103-i livreze produsele \u00eentr-un mod f\u0103r\u0103 contact - direct pe balcon.<\/i><\/p>\n

Dar s\u0103 trecem la concret. \u00cen ultimele c\u00e2teva luni, ne-am concentrat activ pe scalarea infrastructurii companiei noastre. Aceast\u0103 nevoie a fost determinat\u0103 at\u00e2t de factori externi, c\u00e2t \u0219i interni. \u00cen acela\u0219i timp cu extinderea bazei de clien\u021bi, num\u0103rul magazinelor conectate a crescut de la 90 la \u00eenceputul anului la peste 200 p\u00e2n\u0103 \u00een mijlocul lunii mai. Sigur, ne-am preg\u0103tit, am rezervat infrastructura principal\u0103 \u0219i am calculat posibilitatea scal\u0103rii verticale \u0219i orizontale a tuturor ma\u0219inilor virtuale g\u0103zduite \u00een cloud-ul Yandex. Totu\u0219i, realitatea a demonstrat: \u201eTot ce poate merge prost, va merge prost\u201d. Ast\u0103zi vreau s\u0103 \u00eemp\u0103rt\u0103\u0219esc cele mai interesante situa\u021bii care au ap\u0103rut \u00een aceste s\u0103pt\u0103m\u00e2ni. Sper c\u0103 experien\u021ba noastr\u0103 va fi util\u0103 pentru voi.<\/p>\n

Slave-ul este \u00een plin\u0103 capacitate opera\u021bional\u0103<\/h3>\n

\n\u00cenc\u0103 \u00eenainte de \u00eenceperea pandemiei, ne-am confruntat cu o cre\u0219tere a num\u0103rului de solicit\u0103ri pentru serverele noastre backend. Tendin\u021ba de a comanda produse cu livrare la domiciliu a \u00eenceput s\u0103 prind\u0103 av\u00e2nt, iar odat\u0103 cu introducerea primelor m\u0103suri de autoizolare din cauza COVID-19, \u00eenc\u0103rcarea a crescut dramatic pe parcursul \u00eentregii zile. A ap\u0103rut necesitatea de a decongestiona rapid serverele master ale bazei de date principale \u0219i de a transfera parte din solicit\u0103rile de citire pe serverele replici (slave).<\/p>\n

Ne-am preg\u0103tit din timp pentru acest pas, iar pentru un astfel de manevr\u0103 deja fuseser\u0103 activate 2 servere slave. Acestea au fost folosite \u00een principal pentru sarcini batch de generare a fluxurilor de informa\u021bii pentru schimbul de date cu partenerii. Aceste procese generau o \u00eenc\u0103rcare suplimentar\u0103 \u0219i, pe bun\u0103 dreptate, fuseser\u0103 excluse din func\u021bionare cu c\u00e2teva luni \u00eenainte.\u00a0<\/p>\n

Deoarece pe Slave avea loc replicarea, ne-am men\u021binut conceptul c\u0103 aplica\u021biile pot lucra cu acestea doar \u00een modul read only. Planul de Recuperare \u00een Caz de Calamitate presupunea c\u0103, \u00een cazul unei catastrofe, putem monta pur \u0219i simplu Slave-ul \u00een locul Master-ului \u0219i vom redirec\u021biona toate solicit\u0103rile de scriere \u0219i citire pe Slave. Cu toate acestea, ne-am dorit de asemenea s\u0103 folosim replicile pentru nevoile departamentului de analiz\u0103, a\u0219a c\u0103 serverele nu au fost complet tran\u0219ate \u00een statutul de read only, iar pe fiecare host a existat un set propriu de utilizatori, unii av\u00e2nd permisiuni de scriere pentru a salva rezultatele intermediare ale calculelor.<\/p>\n

P\u00e2n\u0103 la un anumit nivel de \u00eenc\u0103rcare, ne ajungea un master at\u00e2t pentru scriere, c\u00e2t \u0219i pentru citire \u00een procesarea solicit\u0103rilor HTTP. La mijlocul lunii martie, atunci c\u00e2nd Sbermarket a decis s\u0103 treac\u0103 complet la munca de la distan\u021b\u0103, am \u00eenceput s\u0103 observ\u0103m o cre\u0219tere exponen\u021bial\u0103 a RPS. Tot mai mul\u021bi dintre clien\u021bii no\u0219tri au \u00eenceput s\u0103 se izoleze sau s\u0103 lucreze de acas\u0103, ceea ce a avut un impact asupra indicatorilor de \u00eenc\u0103rcare.<\/p>\n

Performan\u021ba \u201emaster-ului\u201d nu a mai fost suficient\u0103, a\u0219a c\u0103 am \u00eenceput s\u0103 externaliz\u0103m o parte din cele mai intense solicit\u0103ri de citire c\u0103tre replic\u0103. Pentru a direc\u021biona transparent solicit\u0103rile de scriere c\u0103tre master \u0219i citirea c\u0103tre slave, am folosit gem-ul ruby \u201eOctopus<\/a><\/noindex>\u201d. Am creat un utilizator special cu sufixul _readonly f\u0103r\u0103 drepturi de scriere. Dar din cauza unei erori \u00een configura\u021bia unuia dintre hosturi, o parte din solicit\u0103rile de scriere au fost redirec\u021bionate c\u0103tre serverul slave \u00een numele unui utilizator care avea drepturi corespunz\u0103toare.<\/p>\n

Problema nu s-a manifestat imediat, deoarece \u00eenc\u0103rcarea crescut\u0103 a dus la \u00eent\u00e2rzierea slavelor. Inconsisten\u021ba datelor a fost descoperit\u0103 diminea\u021ba, c\u00e2nd, dup\u0103 importurile nocturne, slavelor nu au reu\u0219it s\u0103 \u201eajung\u0103\u201d master-ul. Am pus acest lucru pe seama \u00eenc\u0103rc\u0103rii mari pe serviciu \u0219i a importului legat de lansarea de noi magazine. Totu\u0219i, livrarea de date cu o \u00eent\u00e2rziere de c\u00e2teva ore era inacceptabil\u0103, a\u0219a c\u0103 am transferat procesele pe al doilea slave analitic, deoarece avea bmare<\/strong>urse resurse \u0219i nu era \u00eenc\u0103rcat cu solicit\u0103ri de citire (ceea ce ne-a explicat absen\u021ba \u00eent\u00e2rzierii replic\u0103rii).<\/p>\n

C\u00e2nd ne-am dat seama de cauzele \u201edezintegr\u0103rii\u201d slave-ului principal, cel analitic a ie\u0219it din func\u021biune din acela\u0219i motiv. \u00cen ciuda existen\u021bei a dou\u0103 servere suplimentare, pe care inten\u021bionam s\u0103 transfer\u0103m \u00eenc\u0103rc\u0103tura \u00een caz de c\u0103dere a masterului, dintr-o eroare regretabil\u0103 nu am avut niciunul \u00een momentul critic.<\/p>\n

Dar, fiindc\u0103 nu doar am f\u0103cut un dump al bazei de date (restaurarea la acel moment dura aproximativ 5 ore), ci \u0219i un snapshot al serverului master, am reu\u0219it s\u0103 lans\u0103m replica \u00een decurs de 2 ore. Cu toate acestea, dup\u0103 aceasta, a fost necesar\u0103 actualizarea jurnalului de replicare timp \u00eendelungat (deoarece procesul se desf\u0103\u0219oar\u0103 \u00eentr-un mod unithread, dar aceasta este o alt\u0103 poveste).<\/p>\n

Concluzie:<\/strong> Dup\u0103 un astfel de incident, a devenit clar c\u0103 trebuie s\u0103 renun\u021b\u0103m la practica restric\u021bion\u0103rii \u00eenregistr\u0103rii pentru utilizatori \u0219i s\u0103 declar\u0103m serverul \u00een mod readonly. Cu o astfel de abordare, nu putem fi dec\u00e2t siguri c\u0103 replicile vor fi disponibile \u00een momente critice.<\/p><\/blockquote>\n

<\/p>\n

Optimizarea chiar \u0219i a unei singure interog\u0103ri intensive poate \u201ereaduce la via\u021b\u0103\u201d baza de date.<\/h3>\n

\nDe\u0219i actualiz\u0103m constant catalogul de pe site, interog\u0103rile pe care le-am direc\u021bionat c\u0103tre serverele Slave au suferit o \u00eent\u00e2rziere minor\u0103 fa\u021b\u0103 de Master. Timpul necesar pentru a descoperi \u0219i a remedia problema replicilor \u201ecare au ie\u0219it brusc de pe traseu\u201d a fost mai mare dec\u00e2t \u201ebariera psihologic\u0103\u201d (\u00een acest timp ar fi putut avea loc actualiz\u0103ri de pre\u021buri, iar clien\u021bii ar fi v\u0103zut date \u00eenvechite), iar noi am fost nevoi\u021bi s\u0103 comut\u0103m toate interog\u0103rile pe serverul principal al bazei de date. Ca rezultat, site-ul a func\u021bionat lent\u2026 dar m\u0103m\u0103lig\u0103 \u00een sf\u00e2r\u0219it a func\u021bionat. \u0218i c\u00e2t timp Slave-ul se recupera, nu ne-a r\u0103mas altceva de f\u0103cut dec\u00e2t optimizarea.\u00a0<\/p>\n

\u00cen timp ce serverele Slave se recuperau, minutele se scurgeau lent, Masterul r\u0103m\u00e2nea supra\u00eenc\u0103rcat, iar noi ne-am concentrat toate eforturile pe optimizarea sarcinilor active conform \u201eRegulii Pareto\u201d: am selectat CELE MAI IMPORTANTE interog\u0103ri, care generau cea mai mare parte a \u00eenc\u0103rc\u0103rii \u0219i am \u00eenceput tuningul. Acest lucru a fost realizat direct \u201e\u00een mers\u201d.<\/p>\n

Un efect interesant a fost c\u0103 un MySQL suprasolicitat r\u0103spunde chiar \u0219i la o \u00eembun\u0103t\u0103\u021bire nesemnificativ\u0103 a proceselor. Optimiza\u021bia unor interog\u0103ri care produceau doar 5% din \u00eenc\u0103rcarea total\u0103 a ar\u0103tat deja o reducere notabil\u0103 a CPU-ului. Ca urmare, am reu\u0219it s\u0103 asigur\u0103m o rezerv\u0103 de resurse acceptabil\u0103 pentru func\u021bionarea Master-ului cu baza de date \u0219i s\u0103 ob\u021binem timpul necesar pentru recuperarea replicilor.\u00a0<\/p>\n

Concluzie:<\/strong> Chiar \u0219i o mic\u0103 optimizare permite \u201es\u0103 supravie\u021buie\u0219ti\u201d la o supra\u00eenc\u0103rcare timp de c\u00e2teva ore. Asta era exact ce ne trebuia pentru timpul de recuperare al serverelor cu replici. Apropo, partea tehnic\u0103 a optimiz\u0103rii interog\u0103rilor o vom discuta \u00eentr-unul dintre urm\u0103toarele post\u0103ri. A\u0219a c\u0103 abona\u021bi-v\u0103 la blogul nostru dac\u0103 v\u0103 poate fi de folos.<\/p><\/blockquote>\n

<\/p>\n

Organiza\u021bi monitorizarea func\u021bion\u0103rii serviciilor-partener.<\/h3>\n

\nNe ocup\u0103m cu procesarea comenzilor clien\u021bilor \u0219i, prin urmare, serviciile noastre interac\u021bioneaz\u0103 constant cu API-uri externe \u2013 acestea sunt portaluri pentru trimiterea SMS-urilor, platforme de plat\u0103, sisteme de rutare, geocodare, serviciul de fiscalitate \u0219i multe alte sisteme. C\u00e2nd volumul de munc\u0103 a \u00eenceput s\u0103 creasc\u0103 rapid, am \u00eenceput s\u0103 ne ciocnim de limitele API-urilor serviciilor noastre partenere, despre care nu ne-am g\u00e2ndit anterior.<\/p>\n

Excedarea nea\u0219teptat\u0103 a cotelor serviciilor partenere poate duce la nefunc\u021bionarea propriilor servicii. Multe API-uri blocheaz\u0103 clien\u021bii care dep\u0103\u0219esc limitele, iar \u00een unele cazuri, un surplus de cereri poate supra\u00eenc\u0103rca produc\u021bia partenerului.\u00a0<\/p>\n

De exemplu, \u00een timpul cre\u0219terii num\u0103rului de livr\u0103ri, serviciile \u00eenso\u021bitoare nu reu\u0219eau s\u0103 fac\u0103 fa\u021b\u0103 sarcinilor de distribuire \u0219i determinare a rutelor. Ca rezultat, comenzile erau plasate, iar serviciul care creeaz\u0103 ruta nu func\u021biona. Trebuie spus c\u0103 logisticienii no\u0219tri au realizat aproape imposibilul \u00een aceste condi\u021bii, iar colaborarea echipei a ajutat s\u0103 compenseze defec\u021biunile temporare ale serviciilor. Dar un volum at\u00e2t de mare de solicit\u0103ri nu se poate gestiona constant manual \u0219i, dup\u0103 un timp, ne-am fi confruntat cu o pr\u0103pastie inacceptabil\u0103 \u00eentre comenzi \u0219i execu\u021bia lor.\u00a0<\/p>\n

A fost adoptat un \u00eentreg set de m\u0103suri organiza\u021bionale \u0219i munca coordonat\u0103 a echipei a ajutat s\u0103 c\u00e2\u0219tig\u0103m timp \u00een timp ce negociam noi condi\u021bii \u0219i a\u0219teptam modernizarea serviciilor din partea unor parteneri. Exist\u0103 \u0219i alte API-uri care se remarc\u0103 prin rezisten\u021ba ridicat\u0103 \u0219i tarife s\u0103lbatice \u00een cazul unui trafic mare. De exemplu, la \u00eenceput, am folosit un API cartografic cunoscut pentru determinarea adresei punctului de livrare. Dar la sf\u00e2r\u0219itul lunii, am primit o factur\u0103 considerabil\u0103 de aproape 2 milioane de ruble. Dup\u0103 aceea, am decis s\u0103-l \u00eenlocuim rapid. Nu voi face reclam\u0103, dar voi spune c\u0103 cheltuielile noastre s-au redus semnificativ.
\n\"Cum<\/p>\n

Concluzie: <\/strong>Este esen\u021bial s\u0103 monitoriz\u0103m condi\u021biile de func\u021bionare ale tuturor serviciilor partenere \u0219i s\u0103 le avem \u00een vedere. Chiar dac\u0103 ast\u0103zi pare c\u0103 au \u201eun mare rezerv\u0103\u201d, nu \u00eenseamn\u0103 c\u0103 m\u00e2ine nu vor deveni un obstacol pentru cre\u0219tere. \u0218i, desigur, este mai bine s\u0103 negociezi \u00eenainte condi\u021biile financiare pentru cererile crescute c\u0103tre serviciu.\u00a0<\/p><\/blockquote>\n

<\/p>\n

Uneori se dovede\u0219te c\u0103 \u201ee nevoie de mai mult aur<\/a><\/noindex>\u201d (c) nu ajut\u0103<\/h3>\n

\nNe-am obi\u0219nuit cu \"blocajele\" \u00een baza de date principal\u0103 sau pe serverele aplica\u021biilor, dar la scalare, problemele pot ap\u0103rea acolo unde nu te a\u0219tep\u021bi. Pentru c\u0103utarea full-text pe site, folosim motorul Apache Solr. Cu cre\u0219terea \u00eenc\u0103rc\u0103rii, am observat o sc\u0103dere a timpului de r\u0103spuns, iar utilizarea procesorului serverului ajungea la 100%. Ce poate fi mai simplu - s\u0103 oferim containerului cu Solr mai multe resurse.<\/p>\n

\u00cen loc de cre\u0219terea a\u0219teptat\u0103 a performan\u021bei, serverul s-a \"\u00eenghe\u021bat\". Se \u00eenc\u0103rca imediat la 100% \u0219i r\u0103spundea \u0219i mai lent. Ini\u021bial, aveam 2 nuclee \u0219i 2 GB RAM. Am decis s\u0103 facem ceea ce de obicei ajut\u0103 - am dat serverului 8 nuclee \u0219i 32 GB. Totul a devenit mult mai r\u0103u (cum anume \u0219i de ce - vom povesti \u00eentr-o postare separat\u0103).\u00a0<\/p>\n

\u00cen c\u00e2teva zile, am \u00een\u021beles subtilit\u0103\u021bile acestei probleme \u0219i am ob\u021binut o performan\u021b\u0103 optim\u0103 la 8 nuclee \u0219i 32 GB. Aceast\u0103 configura\u021bie permite \u0219i ast\u0103zi continuarea cre\u0219terii \u00eenc\u0103rc\u0103rii, ceea ce este foarte important, deoarece cre\u0219terea nu vine doar din num\u0103rul de clien\u021bi, ci \u0219i din num\u0103rul de magazine conectate - \u00een 2 luni, num\u0103rul acestora s-a dublat.\u00a0<\/p>\n

Concluzie: <\/strong>Metodele standard, cum ar fi \u201ead\u0103ugarea mai multor resurse\u201d, nu func\u021bioneaz\u0103 \u00eentotdeauna. A\u0219adar, la scalarea oric\u0103rui serviciu, trebuie s\u0103 \u00een\u021belegi bine cum utilizeaz\u0103 resursele \u0219i s\u0103 testezi din timp func\u021bionarea acestuia \u00een noi condi\u021bii.\u00a0\n<\/p><\/blockquote>\n

<\/p>\n

Stateless - cheia scal\u0103rii orizontale simple<\/h3>\n

\n\u00cen general, echipa noastr\u0103 ader\u0103 la abordarea cunoscut\u0103: serviciile nu ar trebui s\u0103 aib\u0103 un stat intern (stateless) \u0219i ar trebui s\u0103 fie independente de mediu. Acest lucru ne-a permis s\u0103 facem fa\u021b\u0103 cre\u0219terii \u00eenc\u0103rc\u0103rii prin scalare orizontal\u0103 simpl\u0103. Dar am avut un serviciu-excep\u021bie - un procesator de sarcini de fundal lungi. Se ocupa cu trimiterea de emailuri \u0219i SMS-uri, procesarea evenimentelor, generarea de feed-uri, importul de pre\u021buri \u0219i stocuri, procesarea imaginilor. A\u0219a s-a \u00eent\u00e2mplat c\u0103 depindea de un storage local \u0219i era \u00eentr-un singur exemplar.\u00a0<\/p>\n

C\u00e2nd num\u0103rul de sarcini \u00een coada procesorului a crescut (ceea ce s-a \u00eent\u00e2mplat firesc odat\u0103 cu cre\u0219terea num\u0103rului de comenzi), performan\u021ba serverului pe care erau g\u0103zduite procesorul \u0219i stocarea de fi\u0219iere a devenit un factor limitativ. Ca urmare, s-a oprit actualizarea stocului \u0219i a pre\u021burilor, trimiterea notific\u0103rilor utilizatorilor \u0219i multe alte func\u021bii critice, blocate \u00een coad\u0103. Echipa Ops a migrat rapid stocarea de fi\u0219iere \u00eentr-o solu\u021bie de stocare de tip S3, ceea ce ne-a permis s\u0103 ridic\u0103m mai multe ma\u0219ini puternice pentru a scala procesorul de sarcini \u00een fundal.<\/p>\n

Concluzie: <\/strong>Regula Stateless trebuie respectat\u0103 pentru toate componentele, f\u0103r\u0103 excep\u021bie, chiar dac\u0103 pare \u201ec\u0103 aici sigur nu ne vom \u00eempotmoli\u201d. Mai bine s\u0103 investe\u0219ti pu\u021bin timp \u00een organizarea corect\u0103 a func\u021bion\u0103rii tuturor sistemelor, dec\u00e2t s\u0103 rescrii codul \u00een grab\u0103 \u0219i s\u0103 repari un serviciu care sufer\u0103 de suprasarcin\u0103.<\/p><\/blockquote>\n

<\/p>\n

7 principii pentru cre\u0219tere intens\u0103<\/h2>\n

\n\u00cen ciuda disponibilit\u0103\u021bii unor capacit\u0103\u021bi suplimentare, \u00een timpul cre\u0219terii am dat peste c\u00e2teva capcane. \u00cen aceast\u0103 perioad\u0103, num\u0103rul comenzilor a crescut de peste 4 ori. Acum livr\u0103m deja mai mult de 17 000 de comenzi pe zi \u00een 62 de ora\u0219e \u0219i pl\u0103nuim s\u0103 ne extindem \u0219i mai mult geografic \u2014 \u00een prima jum\u0103tate a anului 2020, lansarea serviciului la nivel na\u021bional \u00een Rusia este a\u0219teptat\u0103. Pentru a face fa\u021b\u0103 \u00eenc\u0103rc\u0103turii cresc\u00e2nde, av\u00e2nd \u00een vedere experien\u021bele acumulate, am formulat 7 principii fundamentale de lucru \u00een condi\u021bii de cre\u0219tere constant\u0103:<\/p>\n

    \n
  1. Managementul incidentelor<\/strong>. Am creat un tablou \u00een Jira, unde fiecare incident este reflectat sub form\u0103 de tichet. Aceasta va ajuta efectiv la stabilirea priorit\u0103\u021bilor \u0219i realizarea sarcinilor legate de incident. De fapt, nu este \u00eenfrico\u0219\u0103tor s\u0103 gre\u0219e\u0219ti \u2014 este \u00eenfrico\u0219\u0103tor s\u0103 gre\u0219e\u0219ti de dou\u0103 ori pe aceea\u0219i tem\u0103. Pentru cazurile \u00een care incidentele se repet\u0103 \u00eenainte de a reu\u0219i s\u0103 corect\u0103m cauza, ar trebui s\u0103 existe o instruc\u021biune de ac\u021biune preg\u0103tit\u0103, pentru c\u0103, \u00een timpul unei mari \u00eenc\u0103rc\u0103ri, este important s\u0103 reac\u021bionezi instantaneu.<\/li>\n
  2. Monitorizare <\/strong>este necesar\u0103 pentru toate elementele infrastructurii, f\u0103r\u0103 excep\u021bie. Tocmai datorit\u0103 lui am putut prognoza cre\u0219terea \u00eenc\u0103rc\u0103rii \u0219i alege corect \u201eg\u00e2turile de sticl\u0103\u201d pentru prioritizarea remedierii. Cel mai probabil, sub o \u00eenc\u0103rcare mare se va defecta sau va \u00eencepe s\u0103 \u00eencetineasc\u0103 tot ceea ce nu te-ai g\u00e2ndit. De aceea, cele mai bune alerte sunt cele create imediat dup\u0103 apari\u021bia primelor incidente, pentru a le monitoriza \u0219i anticipa.<\/li>\n
  3. Alertele corecte<\/strong> sunt pur \u0219i simplu necesare \u00een cazul unei cre\u0219teri bru\u0219te a \u00eenc\u0103rc\u0103rii. \u00cen primul r\u00e2nd, acestea trebuie s\u0103 raporteze exact ce s-a defectat. \u00cen al doilea r\u00e2nd, nu ar trebui s\u0103 fie multe alerte, deoarece abunden\u021ba alertelor non-critice duce la ignorarea tuturor notific\u0103rilor \u00een general.<\/li>\n
  4. Aplica\u021biile trebuie s\u0103 fie stateless. <\/strong>Ne-am asigurat c\u0103 pentru aceast\u0103 regul\u0103 nu ar trebui s\u0103 existe excep\u021bii. Este necesar\u0103 o independen\u021b\u0103 total\u0103 fa\u021b\u0103 de mediul de execu\u021bie. Pentru aceasta, po\u021bi stoca date partajate \u00een DB sau, de exemplu, direct \u00een S3. \u0218i mai bine, urmeaz\u0103 regulile https:\/\/12factor.net<\/a><\/noindex>. \u00cen timpul unei cre\u0219teri bru\u0219te, nu este timp de optimizare a codului, iar gestionarea \u00eenc\u0103rc\u0103rii va trebui s\u0103 se fac\u0103 prin cre\u0219terea direct\u0103 a resurselor computa\u021bionale \u0219i prin scalarea orizontal\u0103.<\/li>\n
  5. Cotele \u0219i performan\u021ba serviciilor externe. <\/strong>\u00cen cazul unei cre\u0219teri rapide, problema poate ap\u0103rea nu doar \u00een infrastructura ta, ci \u0219i \u00een serviciul extern. Cel mai frustrant este c\u00e2nd acest lucru se \u00eent\u00e2mpl\u0103 nu din cauza unei defec\u021biuni, ci din cauza atingerii cotelor sau limitelor. A\u0219a c\u0103 serviciile externe trebuie s\u0103 se scaleze la fel de bine ca \u0219i tine.\u00a0<\/li>\n
  6. Separ\u0103 procesele \u0219i cozile. <\/strong>Acest lucru ajut\u0103 foarte mult atunci c\u00e2nd apare o blocare la unul dintre gateway-uri. Nu ne-am confrunta cu \u00eent\u00e2rzieri \u00een transmiterea datelor, dac\u0103 cozile pline de trimitere a SMS-urilor nu ar perturba schimbul de notific\u0103ri \u00eentre sistemele informa\u021bionale. \u0218i ar fi fost mai u\u0219or s\u0103 cre\u0219tem num\u0103rul de worker-e, dac\u0103 ar fi lucrat separat.<\/li>\n
  7. Realit\u0103\u021bile financiare.<\/strong> C\u00e2nd exist\u0103 o cre\u0219tere exploziv\u0103 a fluxurilor de date, nu este timp de g\u00e2ndire la tarife \u0219i subscrip\u021bii. Dar trebuie s\u0103 te g\u00e2nde\u0219ti la ele, mai ales dac\u0103 e\u0219ti o companie mic\u0103. O factur\u0103 mare poate s\u0103 apar\u0103 din partea oric\u0103rui API, precum \u0219i a furnizorului t\u0103u de hosting. A\u0219a c\u0103 trebuie s\u0103 cite\u0219ti cu aten\u021bie contractele.<\/li>\n<\/ol>\n

    <\/p>\n

    Concluzie<\/h2>\n

    \nNu f\u0103r\u0103 pierderi, dar am trecut prin aceast\u0103 etap\u0103 \u0219i ast\u0103zi ne str\u0103duim s\u0103 ne respect\u0103m toate principiile stabilite, fiecare ma\u0219in\u0103 av\u00e2nd capacitatea de a cre\u0219te performan\u021ba de 4 ori pentru a face fa\u021b\u0103 unor surprize neprev\u0103zute.\u00a0<\/p>\n

    \u00cen post\u0103rile viitoare, ne vom \u00eemp\u0103rt\u0103\u0219i experien\u021ba \u00een investigarea sc\u0103derii performan\u021bei \u00een Apache Solr, precum \u0219i vom discuta despre optimizarea cererilor \u0219i despre cum interac\u021biunea cu FNS ajut\u0103 compania s\u0103 economiseasc\u0103 bani. Abona\u021bi-v\u0103 la blogul nostru pentru a nu rat\u0103 nimic \u0219i povesti\u021bi-ne \u00een comentarii dac\u0103 a\u021bi \u00eent\u00e2mpinat probleme similare \u00een timpul cre\u0219terii traficului.<\/p>\n

    \"Cum<\/p>\n

    Numai utilizatorii \u00eenregistra\u021bi pot participa la sondaj. Conecta\u021bi-v\u0103<\/a><\/noindex>, v\u0103 rug\u0103m.<\/p>\n

    A\u021bi \u00eent\u00e2mpinat vreodat\u0103 o \u00eencetinire\/schem\u0103 a serviciului \u00een condi\u021biile unei cre\u0219teri bru\u0219te a \u00eenc\u0103rc\u0103rii din cauza:<\/h2>\n