Toată lumea vorbește despre procesele de dezvoltare și testare, pregătirea personalului, creșterea motivației, dar aceste procese nu sunt suficiente atunci când un minut de oprire a serviciului costă sume enorme de bani. Ce trebuie să faceți când efectuați tranzacții financiare conform unui SLA strict? Cum să creșteți fiabilitatea și toleranța la erori a sistemelor dvs., eliminând dezvoltarea și testarea din ecuație?
Următoarea conferință HighLoad++ va avea loc pe 6 și 7 aprilie 2020 la Sankt Petersburg. Detalii si bilete pt . 9 noiembrie, ora 18:00. HighLoad++ Moscova 2018, Sala Delhi + Kolkata. Teze şi .
Evgeniy Kuzovlev (denumit în continuare – CE): - Prieteni, salut! Numele meu este Kuzovlev Evgeniy. Sunt din compania EcommPay, o divizie specifică este EcommPay IT, divizia IT a grupului de companii. Și astăzi vom vorbi despre timpii de nefuncționare - despre cum să le evităm, despre cum să le minimizăm consecințele dacă nu pot fi evitate. Subiectul este formulat după cum urmează: „Ce să faci când un minut de nefuncționare costă 100 USD”? Privind în perspectivă, cifrele noastre sunt comparabile.
Ce face EcommPay IT?
Cine suntem noi? De ce stau aici în fața ta? De ce am dreptul să vă spun ceva aici? Și despre ce vom vorbi aici mai detaliat?
Grupul de companii EcommPay este un achizitor internațional. Procesăm plăți în toată lumea - în Rusia, Europa, Asia de Sud-Est (în toată lumea). Avem 9 birouri, 500 de angajați în total, iar aproximativ puțin mai puțin de jumătate dintre ei sunt specialiști IT. Tot ceea ce facem, tot din ce facem bani, am făcut singuri.
Toate produsele noastre le-am scris (și avem destul de multe - în linia noastră de produse IT mari avem aproximativ 16 componente diferite) noi înșine; Ne scriem, ne dezvoltăm. Și în acest moment efectuăm aproximativ un milion de tranzacții pe zi (milioane este probabil modul corect de a spune). Suntem o companie destul de tânără - avem doar vreo șase ani.
În urmă cu 6 ani, era un astfel de startup când băieții au venit împreună cu afacerea. Au fost uniți de o idee (nu era altceva decât o idee), și am fugit. Ca orice startup, am alergat mai repede... Pentru noi, viteza era mai importantă decât calitatea.
La un moment dat ne-am oprit: ne-am dat seama că nu mai putem trăi cumva cu acea viteză și cu acea calitate și trebuia să ne concentrăm mai întâi pe calitate. În acest moment, am decis să scriem o nouă platformă care să fie corectă, scalabilă și de încredere. Au început să scrie această platformă (au început să investească, să dezvolte, să testeze), dar la un moment dat și-au dat seama că dezvoltarea și testarea nu ne-au permis să atingem un nou nivel de calitate a serviciilor.
Faci un produs nou, îl pui în producție, dar totuși ceva va merge prost undeva. Și astăzi vom vorbi despre cum să atingem un nou nivel de calitate (cum am făcut-o, despre experiența noastră), scoțând dezvoltarea și testarea din ecuație; vom vorbi despre ceea ce este disponibil pentru funcționare - ce operațiune poate face singură, ce poate oferi testării pentru a influența calitatea.
Timpurile de nefuncţionare. Comenzi de operare.
Întotdeauna piatra de temelie principală, despre ce vom vorbi de fapt astăzi este timpul de nefuncționare. Un cuvânt groaznic. Dacă avem timpi liberi, totul este rău pentru noi. Alergăm să-l ridicăm, administratorii țin serverul - Doamne ferește să nu cadă, așa cum se spune în acel cântec. Despre asta vom vorbi astăzi.
Când am început să ne schimbăm abordările, am format 4 porunci. Le am prezentat pe diapozitive:
Aceste porunci sunt destul de simple:
- Identificați rapid problema.
- Scapa de ea si mai repede.
- Ajutați să înțelegeți motivul (mai târziu, pentru dezvoltatori).
- Și standardizați abordările.
Aș dori să vă atrag atenția asupra punctului nr. 2. Scăpăm de problemă, nu o rezolvăm. Decizia este secundară. Pentru noi, principalul lucru este că utilizatorul este protejat de această problemă. Va exista într-un mediu izolat, dar acest mediu nu va avea niciun contact cu el. De fapt, vom parcurge aceste patru grupuri de probleme (unele mai detaliat, altele mai puțin detaliat), vă voi spune ce folosim, ce experiență relevantă avem în soluții.
Depanare: când se întâmplă și ce trebuie făcut în privința lor?
Dar vom începe din ordine, vom începe cu punctul nr. 2 - cum să scăpăm rapid de problemă? Există o problemă - trebuie să o reparăm. „Ce ar trebui să facem în privința asta?” - întrebarea principală. Și când am început să ne gândim cum să remediam problema, am dezvoltat pentru noi înșine câteva cerințe pe care trebuie să le urmeze depanarea.
Pentru a formula aceste cerințe, am decis să ne punem întrebarea: „Când avem probleme”? Și problemele, după cum sa dovedit, apar în patru cazuri:
- Defecțiune hardware.
- Serviciile externe au eșuat.
- Schimbarea versiunii software (aceeași implementare).
- Creșterea încărcăturii explozive.
Nu vom vorbi despre primele două. O defecțiune hardware poate fi rezolvată destul de simplu: trebuie să aveți totul duplicat. Dacă acestea sunt discuri, discurile trebuie asamblate în RAID; dacă acesta este un server, serverul trebuie să fie duplicat; dacă aveți o infrastructură de rețea, trebuie să furnizați oa doua copie a infrastructurii de rețea, adică o luați și duplicați-l. Și dacă ceva nu reușește, treci la rezervă de putere. Este greu să mai spun ceva aici.
Al doilea este eșecul serviciilor externe. Pentru majoritatea, sistemul nu este deloc o problemă, dar nu pentru noi. Din moment ce procesăm plăți, suntem un agregator care se află între utilizator (care își introduce datele cardului) și bănci, sisteme de plată (Visa, MasterCard, Mira etc.). Serviciile noastre externe (sisteme de plată, bănci) tind să eșueze. Nici noi, nici dumneavoastră (dacă aveți astfel de servicii) nu putem influența acest lucru.
Ce să faci atunci? Există două opțiuni aici. În primul rând, dacă puteți, ar trebui să duplicați acest serviciu într-un fel. De exemplu, dacă putem, transferăm trafic de la un serviciu la altul: de exemplu, cardurile au fost procesate prin Sberbank, Sberbank are probleme - transferăm trafic [condițional] către Raiffeisen. Al doilea lucru pe care îl putem face este să observăm foarte repede eșecul serviciilor externe și, prin urmare, vom vorbi despre viteza de răspuns în următoarea parte a raportului.
De fapt, dintre acestea patru, putem influența în mod specific schimbarea versiunilor de software - luați acțiuni care vor duce la o îmbunătățire a situației în contextul implementărilor și în contextul creșterii explozive a încărcăturii. De fapt, asta am făcut. Iată, din nou, o mică notă...
Dintre aceste patru probleme, câteva sunt rezolvate imediat dacă ai un cloud. Dacă vă aflați în norii Microsoft Azhur, Ozone sau folosiți norii noștri, de la Yandex sau Mail, atunci cel puțin o defecțiune hardware devine problema lor și totul devine imediat bine pentru dvs. în contextul unei defecțiuni hardware.
Suntem o companie ușor neconvențională. Aici toată lumea vorbește despre „Kubernet-uri”, despre nori - nu avem nici „Kubernet-uri”, nici nori. Dar avem rafturi de hardware în multe centre de date și suntem forțați să trăim cu acest hardware, suntem forțați să fim responsabili pentru toate acestea. Prin urmare, vom vorbi în acest context. Deci, despre probleme. Primele două au fost scoase din paranteze.
Schimbarea versiunii software. Bazele
Dezvoltatorii noștri nu au acces la producție. De ce este asta? Doar că suntem certificați PCI DSS, iar dezvoltatorii noștri pur și simplu nu au dreptul să intre în „produs”. Asta e, punct. Deloc. Prin urmare, responsabilitatea dezvoltării se termină exact în momentul în care dezvoltarea trimite build-ul spre lansare.
A doua noastră bază pe care o avem, care ne ajută foarte mult, este absența cunoștințelor unice nedocumentate. Sper sa fie la fel si pentru tine. Pentru că dacă nu este cazul, vei avea probleme. Problemele vor apărea atunci când aceste cunoștințe unice, nedocumentate nu sunt prezente la momentul potrivit, la locul potrivit. Să presupunem că aveți o persoană care știe să implementeze o anumită componentă - persoana nu este acolo, este în vacanță sau este bolnavă - asta e, aveți probleme.
Și a treia bază la care am ajuns. Am ajuns la ea prin durere, sânge, lacrimi - am ajuns la concluzia că oricare dintre construcțiile noastre conține erori, chiar dacă este lipsită de erori. Am decis acest lucru pentru noi înșine: când implementăm ceva, când introducem ceva în producție, avem o versiune cu erori. Ne-am format cerințele pe care sistemul nostru trebuie să le satisfacă.
Cerințe pentru schimbarea versiunii software
Există trei cerințe:
- Trebuie să anulăm rapid desfășurarea.
- Trebuie să minimizăm impactul unei implementări nereușite.
- Și trebuie să ne putem desfășura rapid în paralel.
Exact in ordinea asta! De ce? Pentru că, în primul rând, atunci când implementați o nouă versiune, viteza nu este importantă, dar este important pentru dvs., dacă ceva nu merge bine, să faceți rapid înapoi și să aveți un impact minim. Dar dacă aveți un set de versiuni în producție, pentru care se dovedește că există o eroare (din senin, nu a existat nicio implementare, dar există o eroare) - viteza de implementare ulterioară este importantă pentru dvs. Ce am făcut pentru a răspunde acestor cerințe? Am apelat la următoarea metodologie:
Este destul de cunoscut, nu l-am inventat niciodată - aceasta este implementarea Blue/Green. Ce este? Trebuie să aveți o copie pentru fiecare grup de servere pe care sunt instalate aplicațiile dvs. Copia este „caldă”: nu există trafic pe ea, dar în orice moment acest trafic poate fi trimis către această copie. Această copie conține versiunea anterioară. Și în momentul implementării, lansați codul într-o copie inactivă. Apoi comutați o parte din trafic (sau tot) la noua versiune. Astfel, pentru a schimba fluxul de trafic de la versiunea veche la cea nouă, trebuie să faceți o singură acțiune: trebuie să schimbați echilibrul în amonte, să schimbați direcția - de la una în amonte la alta. Acest lucru este foarte convenabil și rezolvă problema comutării rapide și a revenirii rapide.Aici soluția la a doua întrebare este minimizarea: puteți trimite doar o parte din traficul dvs. către o linie nouă, către o linie cu un cod nou (să fie, de exemplu, 2%). Și acești 2% nu sunt 100%! Dacă ați pierdut 100% din trafic din cauza unei implementări nereușite, este înfricoșător; dacă ați pierdut 2% din trafic, este neplăcut, dar nu este înfricoșător. Mai mult, utilizatorii, cel mai probabil, nici nu vor observa acest lucru, deoarece în unele cazuri (nu în toate) același utilizator, apăsând F5, va fi dus la o altă versiune funcțională.
Implementare albastru/verde. Dirijare
Cu toate acestea, nu totul este atât de simplu „Implementare albastru/verde”... Toate componentele noastre pot fi împărțite în trei grupuri:
- acesta este frontend-ul (paginile de plată pe care le văd clienții noștri);
- miez de procesare;
- adaptor pentru lucrul cu sisteme de plata (banci, MasterCard, Visa...).
Și există o nuanță aici - nuanța se află în rutarea între linii. Dacă comutați doar 100% din trafic, nu aveți aceste probleme. Dar dacă vrei să schimbi 2%, începi să pui întrebări: „Cum să faci asta?” Cel mai simplu lucru este simplu: puteți configura Round Robin în nginx prin alegere aleatorie și aveți 2% la stânga, 98% la dreapta. Dar acest lucru nu este întotdeauna potrivit.
De exemplu, în cazul nostru, un utilizator interacționează cu sistemul cu mai multe solicitări. Acest lucru este normal: 2, 3, 4, 5 solicitări - sistemele dvs. pot fi aceleași. Și dacă este important pentru dvs. ca toate solicitările utilizatorului să vină pe aceeași linie pe care a venit prima solicitare sau (al doilea punct) toate solicitările utilizatorului să vină pe noua linie după comutare (ar fi putut începe să lucreze mai devreme cu sistem, înainte de comutare), - atunci această distribuție aleatorie nu este potrivită pentru dvs. Apoi, există următoarele opțiuni:
Prima opțiune, cea mai simplă, se bazează pe parametrii de bază ai clientului (IP Hash). Aveți un IP și îl împărțiți de la dreapta la stânga după adresa IP. Apoi, cel de-al doilea caz pe care l-am descris va funcționa pentru dvs., când a avut loc implementarea, utilizatorul ar putea deja să înceapă să lucreze cu sistemul dvs., iar din momentul implementării toate cererile vor merge la o nouă linie (la aceeași, să zicem).Dacă, dintr-un motiv oarecare, acest lucru nu vă convine și trebuie să trimiteți cereri la linia unde a venit solicitarea inițială a utilizatorului, atunci aveți două opțiuni...
Prima opțiune: puteți cumpăra nginx+ plătit. Există un mecanism de sesiuni Sticky, care, la cererea inițială a utilizatorului, îi atribuie utilizatorului o sesiune și o leagă de unul sau altul în amonte. Toate solicitările ulterioare ale utilizatorilor din durata de viață a sesiunii vor fi trimise către același în amonte în care a fost postată sesiunea.Acest lucru nu ni s-a potrivit pentru că aveam deja nginx obișnuit. Trecerea la nginx+ nu înseamnă că ar fi scump, ci doar că a fost oarecum dureros pentru noi și nu prea corect. „Sticks Sessions”, de exemplu, nu a funcționat pentru noi din simplul motiv că „Sticks Sessions” nu permit rutarea bazată pe „Either-or”. Acolo puteți specifica ce facem noi „Sticks Sessions”, de exemplu, după adresa IP sau după adresa IP și cookie-uri sau după postparametru, dar „Either-or” este mai complicat acolo.
Prin urmare, am ajuns la a patra opțiune. Am luat nginx pe steroizi (acesta este openresty) - acesta este același nginx, care acceptă în plus includerea ultimelor scripturi. Puteți scrie un ultim script, îi puteți da un „open rest”, iar acest ultim script va fi executat când vine cererea utilizatorului.
Și noi am scris, de fapt, un astfel de scenariu, ne-am stabilit „openești” și în acest scenariu sortăm 6 parametri diferiți prin concatenare „Sau”. În funcție de prezența unuia sau altui parametru, știm că utilizatorul a ajuns la o pagină sau alta, pe o linie sau alta.
Implementare albastru/verde. Avantaje și dezavantaje
Desigur, probabil că a fost posibil să o facem puțin mai simplă (folosește aceleași „Sticky Sessions”), dar avem și o astfel de nuanță încât nu numai utilizatorul interacționează cu noi în cadrul unei procesări a unei tranzacții... Dar și sistemele de plată interacționează cu noi: după ce procesăm tranzacția (prin trimiterea unei cereri către sistemul de plată), primim un coolback.
Și să spunem, dacă în circuitul nostru putem redirecționa adresa IP a utilizatorului în toate solicitările și putem împărți utilizatorii în funcție de adresa IP, atunci nu vom spune aceeași „Visa”: „Băi, suntem o companie atât de retro, se pare că să fie internațional (pe site și în Rusia)... Vă rugăm să ne furnizați adresa IP a utilizatorului într-un câmp suplimentar, protocolul dumneavoastră este standardizat”! Este clar că nu vor fi de acord.
Prin urmare, acest lucru nu a funcționat pentru noi - am făcut openresty. În consecință, cu rutare am obținut ceva de genul acesta:Blue/Green Deployment are, în consecință, avantajele pe care le-am menționat și dezavantajele.
Doua dezavantaje:
- trebuie să vă deranjați cu rutarea;
- al doilea dezavantaj principal este cheltuiala.
Ai nevoie de două ori mai multe servere, ai nevoie de două ori mai multe resurse operaționale, trebuie să cheltuiești de două ori mai mult efort pentru a întreține toată această grădină zoologică.
Apropo, printre avantaje mai există un lucru pe care nu l-am menționat până acum: ai o rezervă în cazul creșterii sarcinii. Dacă aveți o creștere explozivă a încărcăturii, aveți un număr mare de utilizatori, atunci pur și simplu includeți a doua linie în distribuția de la 50 la 50 - și aveți imediat servere x2 în cluster până când rezolvați problema de a avea mai multe servere.
Cum se face o implementare rapidă?
Am vorbit despre cum să rezolvăm problema minimizării și derulării rapide, dar rămâne întrebarea: „Cum să implementăm rapid?”
Este scurt și simplu aici.- Trebuie să aveți un sistem CD (livrare continuă) - nu puteți trăi fără el. Dacă aveți un server, puteți implementa manual. Avem aproximativ o mie și jumătate de servere și o mie și jumătate de mânere, bineînțeles - putem instala un departament de dimensiunea acestei camere doar pentru a fi implementat.
- Desfășurarea trebuie să fie paralelă. Dacă implementarea dvs. este secvenţială, atunci totul este rău. Un server este normal, veți implementa o mie și jumătate de servere toată ziua.
- Din nou, pentru accelerare, probabil că acest lucru nu mai este necesar. În timpul implementării, proiectul este de obicei construit. Ai un proiect web, există o parte front-end (acolo faci un pachet web, compilezi npm - așa ceva), iar acest proces este, în principiu, de scurtă durată - 5 minute, dar aceste 5 minute pot fii critic. De aceea, de exemplu, nu facem asta: am eliminat aceste 5 minute, am implementat artefacte.
Ce este un artefact? Un artefact este o construcție asamblată în care toate piesele de asamblare au fost deja finalizate. Stocam acest artefact în depozitul de artefacte. La un moment dat am folosit două astfel de stocări - era Nexus și acum jFrog Artifactory).Am folosit inițial „Nexus” pentru că am început să exersăm această abordare în aplicațiile java (i se potrivea bine). Apoi au pus acolo câteva dintre aplicațiile scrise în PHP; iar „Nexus” nu mai era potrivit și, prin urmare, am ales jFrog Artefactory, care poate artefactoriza aproape totul. Am ajuns chiar la punctul în care în acest depozit de artefacte stocăm propriile pachete binare pe care le colectăm pentru servere.
Creșterea încărcăturii explozive
Am vorbit despre schimbarea versiunii software. Următorul lucru pe care îl avem este o creștere explozivă a încărcăturii. Aici, probabil că prin creșterea explozivă a încărcăturii mă refer la lucrul potrivit...
Am scris un sistem nou - este orientat spre servicii, la modă, frumos, muncitori peste tot, cozi peste tot, asincronie peste tot. Și în astfel de sisteme, datele pot circula prin diferite fluxuri. Pentru prima tranzacție se poate folosi primul, al 1-lea, al 3-lea muncitor, pentru a doua tranzacție - al 10-lea, al 2-lea, al 4-lea. Și astăzi, să spunem, dimineața aveți un flux de date care folosește primii trei lucrători, iar seara se schimbă dramatic, iar totul îi folosește pe ceilalți trei lucrători.
Și aici se dovedește că trebuie să scalați cumva lucrătorii, trebuie să vă scalați cumva serviciile, dar în același timp să preveniți umflarea resurselor.
Ne-am definit cerințele. Aceste cerințe sunt destul de simple: să existe Service discovery, parametrizare - totul este standard pentru construirea unor astfel de sisteme scalabile, cu excepția unui punct - amortizarea resurselor. Am spus că nu suntem pregătiți să amortizam resurse pentru ca serverele să încălzească aerul. Am luat „Consul”, am luat „Nomad”, care ne administrează muncitorii.De ce este aceasta o problemă pentru noi? Să ne întoarcem puțin înapoi. Avem acum în spate aproximativ 70 de sisteme de plată. Dimineața, traficul trece prin Sberbank, apoi Sberbank a căzut, de exemplu, și îl trecem la alt sistem de plată. Am avut 100 de lucrători înainte de Sberbank, iar după aceea trebuie să creștem brusc 100 de lucrători pentru un alt sistem de plată. Și este de dorit ca toate acestea să se întâmple fără participarea umană. Pentru că, dacă există participarea umană, ar trebui să existe un inginer acolo 24/7, care ar trebui să facă doar asta, pentru că astfel de defecțiuni, atunci când 70 de sisteme sunt în spatele tău, se întâmplă în mod regulat.
Prin urmare, ne-am uitat la Nomad, care are un IP deschis, și am scris propriul nostru lucru, Scale-Nomad - ScaleNo, care face aproximativ următoarele: monitorizează creșterea cozii și reduce sau crește numărul de lucrători în funcție de dinamică. a cozii. Când am făcut-o, ne-am gândit: „Poate îl putem deschide sursa?” Apoi s-au uitat la ea - era simplă ca doi copeici.
Până acum nu l-am open source, dar dacă brusc după raport, după ce îți dai seama că ai nevoie de așa ceva, ai nevoie de el, contactele mele sunt în ultimul slide - te rog să-mi scrii. Dacă sunt cel puțin 3-5 persoane, îl vom sponsoriza.
Cum functioneaza? Să aruncăm o privire! Privind în viitor: în partea stângă există o parte din monitorizarea noastră: aceasta este o linie, în partea de sus este timpul procesării evenimentului, în mijloc este numărul de tranzacții, în partea de jos este numărul de lucrători.Dacă te uiți, există o eroare în această imagine. În topul graficului, unul dintre topuri s-a prăbușit în 45 de secunde - unul dintre sistemele de plată a căzut. Imediat, traficul a fost adus în 2 minute și coada a început să crească pe un alt sistem de plată, unde nu erau muncitori (nu am folosit resurse - dimpotrivă, am eliminat resursa corect). Nu am vrut să ne încălzim - era un număr minim, aproximativ 5-10 muncitori, dar nu au putut face față.
Ultimul grafic arată o „cocoașă”, ceea ce înseamnă doar că „Skaleno” a dublat această sumă. Și apoi, când graficul a scăzut puțin, l-a redus puțin - numărul de muncitori a fost schimbat automat. Așa funcționează chestia asta. Am vorbit despre punctul numărul 2 - „Cum să scapi rapid de motive”.
Monitorizarea. Cum să identifici rapid problema?
Acum primul punct este „Cum să identificăm rapid problema?” Monitorizarea! Trebuie să înțelegem rapid anumite lucruri. Ce lucruri ar trebui să înțelegem repede?
Trei lucruri!- Trebuie să înțelegem și să înțelegem rapid performanța propriilor resurse.
- Trebuie să înțelegem rapid defecțiunile și să monitorizăm performanța sistemelor care ne sunt externe.
- Al treilea punct este identificarea erorilor logice. Acesta este momentul în care sistemul funcționează pentru tine, totul este normal conform tuturor indicatorilor, dar ceva nu merge bine.
Probabil că nu vă voi spune nimic atât de grozav aici. Voi fi căpitanul Obvious. Am căutat ce era pe piață. Avem o „grădina zoologică distractivă”. Acesta este genul de grădină zoologică pe care o avem acum:
Folosim Zabbix pentru a monitoriza hardware-ul, pentru a monitoriza principalii indicatori ai serverelor. Folosim Okmeter pentru baze de date. Folosim „Grafana” și „Prometheus” pentru toți ceilalți indicatori care nu se potrivesc cu primii doi, unii cu „Grafana” și „Prometheus”, iar alții cu „Grafana” cu „Influx” și Telegraf.Acum un an am vrut să folosim New Relic. Lucru tare, poate face totul. Dar pe cât de mult poate face totul, e atât de scumpă. Când am crescut la un volum de 1,5 mii de servere, un furnizor a venit la noi și ne-a spus: „Să încheiem un acord pentru anul viitor”. Ne-am uitat la preț și am spus nu, nu vom face asta. Acum abandonăm New Relic, avem aproximativ 15 servere rămase sub monitorizarea New Relic. Prețul s-a dovedit a fi absolut sălbatic.
Și există un instrument pe care l-am implementat noi înșine - acesta este Debugger. La început l-am numit „Bagger”, dar apoi a trecut un profesor de engleză, a râs nebunește și l-a redenumit „Debagger”. Ce este? Acesta este un instrument care, de fapt, în 15-30 de secunde pe fiecare componentă, ca o „cutie neagră” a sistemului, execută teste asupra performanței generale a componentei.
De exemplu, dacă există o pagină externă (pagina de plată), pur și simplu o deschide și se uită la cum ar trebui să arate. Dacă aceasta este în procesare, el trimite o „tranzacție” de test și se asigură că aceasta „tranzacție” ajunge. Dacă aceasta este o conexiune cu sisteme de plată, lansăm o cerere de testare în consecință, acolo unde putem, și vedem că totul este în regulă la noi.
Ce indicatori sunt importanți pentru monitorizare?
Ce monitorizăm în principal? Ce indicatori sunt importanți pentru noi?
- Timpul de răspuns / RPS pe fronturi este un indicator foarte important. El răspunde imediat că ceva nu este în regulă cu tine.
- Numărul de mesaje procesate din toate cozile.
- Numărul de muncitori.
- Valorile de bază ale corectitudinii.
Ultimul punct este metrica „afacere”, „afacere”. Dacă doriți să monitorizați același lucru, trebuie să definiți una sau două metrici care sunt principalii indicatori pentru dvs. Valoarea noastră este debitul (acesta este raportul dintre numărul de tranzacții reușite și fluxul total de tranzacții). Daca ceva se schimba in el la un interval de 5-10-15 minute inseamna ca avem probleme (daca se schimba radical).
Cum arată pentru noi este un exemplu al uneia dintre panourile noastre:
În partea stângă sunt 6 grafice, acesta este conform liniilor - numărul de lucrători și numărul de mesaje din cozi. În partea dreaptă – RPS, RTS. Mai jos este aceeași valoare pentru „afacere”. Și în metrica „afaceri” putem vedea imediat că ceva a mers prost în cele două grafice din mijloc... Acesta este doar un alt sistem care stă în spatele nostru și care a căzut.Al doilea lucru pe care trebuia să-l facem a fost să monitorizăm căderea sistemelor de plată externe. Aici am luat OpenTracing - un mecanism, standard, paradigmă care vă permite să urmăriți sistemele distribuite; si s-a schimbat putin. Paradigma standard OpenTracing spune că construim o urmă pentru fiecare cerere individuală. Nu aveam nevoie de acest lucru și l-am împachetat într-un rezumat, urmă de agregare. Am creat un instrument care ne permite să urmărim viteza sistemelor din spatele nostru.
Graficul ne arată că unul dintre sistemele de plată a început să răspundă în 3 secunde - avem probleme. Mai mult, chestia asta va reacționa atunci când încep problemele, la un interval de 20-30 de secunde.Și a treia clasă de erori de monitorizare care există este monitorizarea logică.
Sincer să fiu, nu știam ce să desenez pe acest slide, pentru că căutam de multă vreme pe piață ceva care să ni se potrivească. Nu am găsit nimic, așa că a trebuit să o facem noi.
Ce vreau să spun prin monitorizare logică? Ei bine, imaginați-vă: vă faceți un sistem (de exemplu, o clonă Tinder); ai făcut-o, ai lansat-o. Managerul de succes Vasya Pupkin și-a pus-o pe telefon, vede o fată acolo, îi place... și ceva asemănător nu i se îndreaptă fetei - așa ceva se îndreaptă către agentul de securitate Mikhalych din același centru de afaceri. Managerul coboară, apoi se întreabă: „De ce acest agent de securitate Mikhalych îi zâmbește atât de plăcut?”În astfel de situații... Pentru noi, această situație sună puțin diferit, pentru că (am scris eu) aceasta este o pierdere de reputație care duce indirect la pierderi financiare. Situația noastră este inversă: putem suferi pierderi financiare directe - de exemplu, dacă am realizat o tranzacție ca fiind reușită, dar nu a avut succes (sau invers). A trebuit să-mi scriu propriul instrument care urmărește numărul de tranzacții de succes de-a lungul timpului folosind indicatori de afaceri. Nu am gasit nimic pe piata! Este exact ideea pe care am vrut să o transmit. Nu există nimic pe piață care să rezolve acest tip de problemă.
Acesta a fost despre cum să identificăm rapid problema.
Cum să determinați motivele implementării
Al treilea grup de probleme pe care îl rezolvăm este după ce am identificat problema, după ce am scăpat de ea, ar fi bine să înțelegem motivul dezvoltării, al testării și să facem ceva în privința ei. În consecință, trebuie să investigăm, trebuie să ridicăm buștenii.
Dacă vorbim de jurnale (motivul principal sunt jurnalele), cea mai mare parte a jurnalelor noastre se află în ELK Stack - aproape toată lumea are același lucru. Pentru unii, poate să nu fie în ELK, dar dacă scrieți jurnalele în gigaocteți, atunci mai devreme sau mai târziu veți ajunge la ELK. Le scriem în terabytes.
Este o problemă aici. Am remediat-o, am corectat eroarea pentru utilizator, am început să descoperim ce era acolo, ne-am urcat în Kibana, am introdus ID-ul tranzacției acolo și am primit o cârpă ca aceasta (arată multe). Și absolut nimic nu este clar în această cârpă pentru picioare. De ce? Da, pentru că nu este clar care parte îi aparține cărei muncitori, care parte îi aparține cărei componentă. Și în acel moment ne-am dat seama că avem nevoie de urmărire - același OpenTracing despre care am vorbit.Ne-am gândit la asta acum un an, ne-am îndreptat atenția către piață și existau două instrumente acolo - „Zipkin” și „Jaeger”. „Jager” este de fapt un astfel de moștenitor ideologic, un succesor ideologic al lui „Zipkin”. Totul este bine în Zipkin, cu excepția faptului că nu știe cum să agregă, nu știe să includă loguri în urmărire, doar urmă de timp. Și „Jager” a susținut acest lucru.
Ne-am uitat la „Jager”: puteți instrumenta aplicații, puteți scrie în Api (standardul Api pentru PHP la acea vreme, totuși, nu era aprobat - asta a fost acum un an, dar acum a fost deja aprobat), dar acolo era absolut nici un client. „Bine”, ne-am gândit și i-am scris propriului nostru client. Ce am primit? Cam așa arată:
În Jaeger, se creează intervale pentru fiecare mesaj. Adică, atunci când un utilizator deschide sistemul, vede unul sau două blocuri pentru fiecare cerere primită (1-2-3 - numărul de solicitări primite de la utilizator, numărul de blocuri). Pentru a le ușura utilizatorilor, am adăugat etichete în jurnalele și urmele de timp. În consecință, în cazul unei erori, aplicația noastră va marca jurnalul cu eticheta de Eroare corespunzătoare. Puteți filtra după eticheta de eroare și vor fi afișate numai intervalele care conțin acest bloc cu o eroare. Iată cum arată dacă extindem intervalul:
În interiorul travei există un set de urme. În acest caz, acestea sunt trei urme de testare, iar a treia urmă ne spune că a apărut o eroare. În același timp, aici vedem o urmă de timp: avem o scală de timp în partea de sus și vedem la ce interval de timp a fost înregistrat acest sau acel jurnal.În consecință, lucrurile au mers bine pentru noi. Am scris propria noastră extensie și am creat-o cu sursă deschisă. Dacă doriți să lucrați cu urmărirea, dacă doriți să lucrați cu „Jager” în PHP, există extensia noastră, binevenit să o utilizați, după cum se spune:
Avem această extensie - este un client pentru OpenTracing Api, este făcut ca extensie php, adică va trebui să o asamblați și să o instalați pe sistem. Acum un an nu era nimic diferit. Acum există și alți clienți care sunt ca niște componente. Aici depinde de tine: fie scoți componentele cu un compozitor, fie folosești extensia în funcție de tine.Standardele corporative
Am vorbit despre cele trei porunci. A patra poruncă este de a standardiza abordările. Despre ce este vorba? Este vorba despre asta:
De ce este cuvântul „corporat” aici? Nu pentru că suntem o companie mare sau birocratică, nu! Am vrut să folosesc cuvântul „corporat” aici în contextul că fiecare companie, fiecare produs ar trebui să aibă propriile standarde, inclusiv pe tine. Ce standarde avem?
- Avem regulamente de desfășurare. Nu ne mutăm nicăieri fără el, nu putem. Implementăm de aproximativ 60 de ori pe săptămână, adică implementăm aproape constant. În același timp, avem, de exemplu, în regulamentele de desfășurare un tabu privind implementările de vineri - în principiu, nu desfășurăm.
- Avem nevoie de documentație. Nicio componentă nouă nu intră în producție dacă nu există documentație pentru aceasta, chiar dacă s-a născut sub condeiul specialiștilor noștri RnD. Solicităm de la ei instrucțiuni de implementare, o hartă de monitorizare și o descriere aproximativă (ei bine, așa cum pot scrie programatorii) a modului în care funcționează această componentă, cum să o depanăm.
- Rezolvăm nu cauza problemei, ci problema - ceea ce am spus deja. Este important pentru noi să protejăm utilizatorul de probleme.
- Avem autorizații. De exemplu, nu considerăm că este timpul de nefuncționare dacă am pierdut 2% din trafic în două minute. Practic, acest lucru nu este inclus în statisticile noastre. Dacă este mai mult procentual sau temporar, noi deja numărăm.
- Și întotdeauna scriem autopsie. Orice s-ar întâmpla cu noi, orice situație în care cineva s-a comportat anormal în producție se va reflecta în autopsie. O autopsie este un document în care scrieți ce vi s-a întâmplat, un calendar detaliat, ce ați făcut pentru a o corecta și (acesta este un bloc obligatoriu!) ce veți face pentru a preveni acest lucru pe viitor. Acest lucru este obligatoriu și necesar pentru analiza ulterioară.
Ce este considerat timp de nefuncţionare?
La ce au dus toate acestea?Acest lucru a condus la faptul că (am avut anumite probleme cu stabilitatea, acest lucru nu s-a potrivit nici clienților, nici nouă) în ultimele 6 luni indicatorul nostru de stabilitate a fost 99,97. Putem spune că acest lucru nu este foarte mult. Da, avem pentru ce să ne străduim. Din acest indicator, aproximativ jumătate este stabilitatea, așa cum ar fi, nu a noastră, ci a firewall-ului aplicației noastre web, care stă în fața noastră și este folosit ca serviciu, dar clienților nu le pasă de acest lucru.
Am învățat să dormim noaptea. In cele din urma! Acum șase luni nu puteam. Și pe această notă cu rezultatele, aș dori să fac o notă. Aseară a fost un raport minunat despre sistemul de control al unui reactor nuclear. Dacă cei care au scris acest sistem mă pot auzi, vă rog să uitați de ceea ce am spus despre „2% nu este timp de nefuncționare”. Pentru tine, 2% este timp de nefuncționare, chiar dacă pentru două minute!
Asta e tot! Intrebarile tale.
Despre echilibratori și migrarea bazei de date
Întrebare din partea publicului (în continuare – B): – Bună seara. Vă mulțumesc foarte mult pentru un astfel de raport administrativ! O scurtă întrebare despre echilibratorii dvs. Ai menționat că ai un WAF, adică, din câte am înțeles, folosești un fel de echilibrator extern...
EK: – Nu, ne folosim serviciile ca echilibrator. În acest caz, WAF este exclusiv un instrument de protecție DDoS pentru noi.
ÎN: – Puteți spune câteva cuvinte despre echilibratori?
EK: – După cum am spus deja, acesta este un grup de servere în openresty. Avem acum 5 grupuri de rezervă care răspund exclusiv... adică un server care rulează exclusiv openresty, numai trafic proxy. În consecință, pentru a înțelege cât de mult avem: acum avem un flux regulat de trafic de câteva sute de megabiți. Se descurcă, se simt bine, nici măcar nu se încordează.
ÎN: – De asemenea, o întrebare simplă. Aici este implementarea Albastru/Verde. Ce faci, de exemplu, cu migrarea bazelor de date?
EK: - Buna intrebare! Uite, în implementarea Albastru/Verde avem cozi separate pentru fiecare linie. Adică, dacă vorbim de cozi de evenimente care se transmit de la lucrător la muncitor, există cozi separate pentru linia albastră și pentru linia verde. Dacă vorbim despre baza de date în sine, atunci am restrâns-o în mod deliberat cât am putut, am mutat totul practic în cozi; în baza de date stocăm doar un teanc de tranzacții. Și stiva noastră de tranzacții este aceeași pentru toate liniile. Cu baza de date în acest context: nu o împărțim în albastru și verde, deoarece ambele versiuni ale codului trebuie să știe ce se întâmplă cu tranzacția.
Prieteni, am și un mic premiu pentru a vă stimula - o carte. Și ar trebui să fiu premiat pentru cea mai bună întrebare.
ÎN: - Buna ziua. Multumesc pentru raport. Întrebarea este aceasta. Monitorizezi plățile, monitorizezi serviciile cu care comunici... Dar cum monitorizezi ca o persoană să vină cumva pe pagina ta de plată, să facă o plată, iar proiectul l-a creditat cu bani? Adică, cum monitorizați dacă comerciantul este disponibil și v-a acceptat apelul înapoi?
EK: – „Comerciant” pentru noi în acest caz este exact același serviciu extern ca și sistemul de plată. Monitorizăm viteza de răspuns a comerciantului.
Despre criptarea bazei de date
ÎN: - Buna ziua. Am o intrebare usor legata. Aveți date sensibile PCI DSS. Am vrut să știu cum stocați PAN-urile în cozile în care trebuie să le transferați? Folosești vreo criptare? Și aceasta duce la a doua întrebare: conform PCI DSS, este necesară recriptarea periodică a bazei de date în cazul unor modificări (demiterea administratorilor etc.) - ce se întâmplă cu accesibilitatea în acest caz?
EK: - Minunata intrebare! În primul rând, nu stocăm PAN-urile în cozi. Nu avem dreptul de a stoca PAN oriunde într-o formă clară, în principiu, așa că folosim un serviciu special (numim „Kademon”) - acesta este un serviciu care face un singur lucru: primește un mesaj ca intrare și trimite scoate un mesaj criptat. Și stocăm totul cu acest mesaj criptat. În consecință, lungimea cheii noastre este sub un kilobyte, astfel încât acest lucru este serios și de încredere.ÎN: – Ai nevoie de 2 kilobytes acum?
EK: – Se pare că chiar ieri a fost 256... Păi, unde altundeva?!
Prin urmare, acesta este primul. Și în al doilea rând, soluția care există, acceptă procedura de re-criptare - există două perechi de „keks” (chei), care dau „decks” care criptează (cheia sunt cheile, dek sunt derivate ale cheilor care criptează) . Și dacă procedura este inițiată (se întâmplă în mod regulat, de la 3 luni la ± unele), descarcăm o nouă pereche de „prăjituri” și re-criptăm datele. Avem servicii separate care extrag toate datele și le criptează într-un mod nou; Datele sunt stocate lângă identificatorul cheii cu care sunt criptate. În consecință, de îndată ce criptăm datele cu chei noi, ștergem cheia veche.
Uneori plățile trebuie făcute manual...
ÎN: – Adică, dacă a sosit o rambursare pentru o operațiune, o vei decripta în continuare cu vechea cheie?
EK: - Da.
ÎN: – Atunci încă o mică întrebare. Când are loc un fel de eșec, cădere sau incident, este necesar să treceți manual tranzacția. Există o astfel de situație.
EK: - Da câteodată.
ÎN: – De unde ai aceste date? Sau mergi singur la acest depozit?
EK: – Nu, bineînțeles, avem un fel de sistem de back-office care conține o interfață pentru suportul nostru. Dacă nu știm în ce stare se află tranzacția (de exemplu, până când sistemul de plată a răspuns cu un timeout), nu știm a priori, adică atribuim statutul final doar cu deplină încredere. În acest caz, atribuim tranzacției un statut special pentru procesare manuală. Dimineața, a doua zi, de îndată ce suportul primește informații că astfel de tranzacții rămân în sistemul de plată, le procesează manual în această interfață.
ÎN: — Am câteva întrebări. Una dintre ele este continuarea zonei PCI DSS: cum le înregistrezi circuitul? Această întrebare se datorează faptului că dezvoltatorul ar fi putut pune orice în jurnal! A doua întrebare: cum lansați remedieri rapide? Utilizarea mânerelor în baza de date este o opțiune, dar pot exista remedieri gratuite - care este procedura acolo? Și a treia întrebare este probabil legată de RTO, RPO. Disponibilitatea dumneavoastră a fost de 99,97, aproape patru nouă, dar după cum am înțeles, aveți un al doilea centru de date, un al treilea centru de date și un al cincilea centru de date... Cum le sincronizați, le replici și orice altceva?EK: - Să începem cu primul. Prima întrebare a fost despre jurnalele? Când scriem jurnalele, avem un strat care maschează toate datele sensibile. Se uită la mască și la câmpurile suplimentare. În consecință, jurnalele noastre apar cu date deja mascate și un circuit PCI DSS. Aceasta este una dintre sarcinile obișnuite atribuite departamentului de testare. Li se cere să verifice fiecare sarcină, inclusiv jurnalele pe care le scriu, iar aceasta este una dintre sarcinile obișnuite în timpul revizuirii codului, pentru a controla că dezvoltatorul nu a notat ceva. Verificările ulterioare ale acestui lucru sunt efectuate în mod regulat de către departamentul de securitate a informațiilor aproximativ o dată pe săptămână: jurnalele pentru ultima zi sunt preluate selectiv și sunt rulate printr-un scanner-analizator special de la serverele de testare pentru a verifica totul.
Despre remedieri rapide. Acest lucru este inclus în regulamentele noastre de implementare. Avem o clauză separată despre remedieri rapide. Credem că implementăm remedieri rapide non-stop atunci când avem nevoie. De îndată ce versiunea este asamblată, de îndată ce este rulată, de îndată ce avem un artefact, avem un administrator de sistem de serviciu la un apel de la asistență, iar acesta îl implementează în momentul în care este necesar.Cam „patru nouă”. Cifra pe care o avem acum a fost cu adevărat atinsă și ne-am străduit pentru aceasta într-un alt centru de date. Acum avem un al doilea centru de date și începem să rutăm între ele, iar problema replicării între centrele de date este cu adevărat o întrebare netrivială. Am încercat să o rezolvăm la un moment dat folosind diferite mijloace: am încercat să folosim aceeași „Tarantula” - nu ne-a funcționat, vă spun imediat. De aceea am ajuns să comandăm manual „sensurile”. De fapt, fiecare aplicație din sistemul nostru rulează sincronizarea necesară „schimbare – făcută” între centrele de date în mod asincron.
ÎN: – Dacă ai primit al doilea, de ce nu ai primit al treilea? Pentru că nimeni nu are încă creierul divizat...
EK: – Dar nu avem Split Brain. Datorită faptului că fiecare aplicație este condusă de un multimaster, nu contează pentru noi la ce centru a venit solicitarea. Suntem pregătiți pentru faptul că, dacă unul dintre centrele noastre de date eșuează (ne bazăm pe asta) și în mijlocul unei cereri de utilizator trece la al doilea centru de date, suntem gata să pierdem acest utilizator, într-adevăr; dar acestea vor fi unități, unități absolute.
ÎN: - Bună seara. Multumesc pentru raport. Ai vorbit despre depanatorul tău, care rulează unele tranzacții de testare în producție. Dar spune-ne despre tranzacțiile de testare! Cât de adânc merge?
EK: – Trece prin ciclul complet al întregii componente. Pentru o componentă, nu există nicio diferență între o tranzacție de testare și una de producție. Dar din punct de vedere logic, acesta este pur și simplu un proiect separat în sistem, pe care se rulează doar tranzacții de testare.
ÎN: -Unde o tai? Aici Core a trimis...
EK: – Suntem în spatele „Kor” în acest caz pentru tranzacții de testare... Avem așa ceva ca rutare: „Kor” știe la ce sistem de plată să trimitem - trimitem către un sistem de plată fals, care pur și simplu dă un semnal http și asta e tot.
ÎN: – Spune-mi, te rog, aplicația ta a fost scrisă într-un monolit uriaș sau ai tăiat-o în unele servicii sau chiar microservicii?
EK: – Nu avem un monolit, desigur, avem o aplicație orientată spre servicii. Glumim că serviciul nostru este făcut din monoliți - sunt într-adevăr destul de mari. Este greu să-i numim microservicii, dar acestea sunt servicii în cadrul cărora lucrează lucrătorii mașinilor distribuite.
Dacă serviciul de pe server este compromis...
ÎN: – Atunci am următoarea întrebare. Chiar dacă ar fi un monolit, ai spus totuși că ai multe dintre aceste servere instant, toate procesează practic date, iar întrebarea este: „În cazul compromiterii unuia dintre serverele instant sau a unei aplicații, orice link individual. , au un fel de control al accesului? Care dintre ei poate face ce? Pe cine ar trebui să mă adresez pentru ce informații?
EK: - Da cu siguranta. Cerințele de securitate sunt destul de serioase. În primul rând, avem mișcări de date deschise, iar porturile sunt doar acelea prin care anticipăm în avans mișcarea traficului. Dacă o componentă comunică cu baza de date (să zicem, cu Muskul) prin 5-4-3-2, doar 5-4-3-2 îi va fi deschis, iar alte porturi și alte direcții de trafic nu vor fi disponibile. În plus, trebuie să înțelegeți că în producția noastră există aproximativ 10 bucle de securitate diferite. Și chiar dacă aplicația a fost cumva compromisă, Doamne ferește, atacatorul nu va putea accesa consola de management al serverului, deoarece aceasta este o zonă de securitate diferită a rețelei.ÎN: – Și în acest context, ceea ce este mai interesant pentru mine este că aveți anumite contracte cu servicii - ce pot face, prin ce „acțiuni” se pot contacta între ei... Și într-un flux normal, unele servicii specifice solicită niște rând, o listă de „acțiuni” pe celălalt. Ei nu par să se îndrepte către ceilalți într-o situație normală și au alte domenii de responsabilitate. Dacă unul dintre ei este compromis, va putea perturba „acțiunile” serviciului respectiv?...
EK: - Am înțeles. Dacă într-o situație normală cu un alt server a fost permisă deloc comunicarea, atunci da. Conform contractului SLA, nu monitorizăm că ai voie doar primele 3 „acțiuni”, și nici cele 4 „acțiuni”. Acest lucru este probabil redundant pentru noi, pentru că avem deja un sistem de protecție pe 4 niveluri, în principiu, pentru circuite. Preferăm să ne apărăm cu contururile, decât la nivelul interiorului.
Cum funcționează Visa, MasterCard și Sberbank
ÎN: – Vreau să clarific un punct despre trecerea unui utilizator de la un centru de date la altul. Din câte știu eu, Visa și MasterCard funcționează folosind protocolul sincron binar 8583 și există mixuri acolo. Și am vrut să știu, acum ne referim la schimbare – este direct „Visa” și „MasterCard” sau înainte de sistemele de plată, înainte de procesare?
EK: - Asta înainte de amestecuri. Mixurile noastre sunt situate în același centru de date.
ÎN: – În linii mari, aveți un punct de legătură?
EK: – „Visa” și „MasterCard” - da. Pur și simplu pentru că Visa și MasterCard necesită investiții destul de serioase în infrastructură pentru a încheia contracte separate pentru a obține o a doua pereche de mixuri, de exemplu. Sunt rezervate într-un singur centru de date, dar dacă, Doamne ferește, centrul nostru de date, unde există mixuri pentru conectarea la Visa și MasterCard, moare, atunci vom avea o conexiune cu Visa și MasterCard pierdută...
ÎN: – Cum pot fi rezervate? Știu că Visa permite o singură conexiune în principiu!
EK: – Ei înșiși furnizează echipamentul. În orice caz, am primit echipamente care sunt complet redundante în interior.
ÎN: – Deci standul este de la Connects Orange?...
EK: - Da.
ÎN: – Dar cum rămâne cu acest caz: dacă centrul tău de date dispare, cum poți continua să-l folosești? Sau doar se oprește traficul?
EK: - Nu. În acest caz, pur și simplu vom comuta traficul pe un alt canal, care, desigur, va fi mai scump pentru noi și mai scump pentru clienții noștri. Dar traficul nu va trece prin conexiunea noastră directă la Visa, MasterCard, ci prin Sberbank condiționat (foarte exagerat).
Îmi cer scuze nebunești dacă i-am jignit pe angajații Sberbank. Dar, conform statisticilor noastre, printre băncile rusești, Sberbank cade cel mai des. Nu trece o lună fără să piardă ceva la Sberbank.
Câteva reclame 🙂
Vă mulțumim că ați rămas cu noi. Vă plac articolele noastre? Vrei să vezi mai mult conținut interesant? Susține-ne plasând o comandă sau recomandând prietenilor, , un analog unic al serverelor entry-level, care a fost inventat de noi pentru tine: (disponibil cu RAID1 și RAID10, până la 24 de nuclee și până la 40 GB DDR4).
Dell R730xd de 2 ori mai ieftin în centrul de date Equinix Tier IV din Amsterdam? Numai aici in Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - de la 99 USD! Citește despre
Sursa: www.habr.com