HighLoad++, Evgeniy Kuzovlev (EcommPay IT): što učiniti kada minuta zastoja košta 100000 USD

Svi govore o procesima razvoja i testiranja, obuci osoblja, povećanju motivacije, ali ti procesi nisu dovoljni kada minuta zastoja servisa košta enormne količine novca. Što učiniti kada provodite financijske transakcije pod strogim SLA? Kako povećati pouzdanost i otpornost na pogreške vaših sustava, izbacujući razvoj i testiranje iz jednadžbe?

Sljedeća HighLoad++ konferencija održat će se 6. i 7. travnja 2020. u St. Detalji i ulaznice za link. 9. studenog, 18:00. HighLoad++ Moskva 2018, Delhi + dvorana Kolkata. Teze i prezentacija.

Evgeniy Kuzovlev (u daljnjem tekstu – EC): - Prijatelji, zdravo! Moje ime je Kuzovlev Evgeniy. Ja sam iz tvrtke EcommPay, posebna divizija je EcommPay IT, IT divizija grupe kompanija. A danas ćemo govoriti o zastojima - o tome kako ih izbjeći, o tome kako minimizirati njihove posljedice ako se ne mogu izbjeći. Tema je navedena na sljedeći način: “Što učiniti kada minuta zastoja košta 100 dolara”? Gledajući unaprijed, naše brojke su usporedive.

Što EcommPay IT radi?

Tko smo mi? Zašto stojim ovdje ispred tebe? Zašto ja imam pravo da ti nešto kažem ovdje? A o čemu ćemo ovdje detaljnije?

Grupa tvrtki EcommPay međunarodni je preuzimatelj. Obrađujemo plaćanja u cijelom svijetu - u Rusiji, Europi, jugoistočnoj Aziji (po cijelom svijetu). Imamo 9 ureda, ukupno 500 zaposlenih, a otprilike nešto manje od polovice su informatičari. Sve što radimo, sve od čega zarađujemo, napravili smo sami.

Sve naše proizvode (a imamo ih dosta - u našoj liniji velikih IT proizvoda imamo oko 16 različitih komponenti) sami smo napisali; Sami pišemo, sami se razvijamo. A trenutno dnevno obavimo oko milijun transakcija (milijuni je vjerojatno pravi način da se kaže). Mi smo prilično mlada tvrtka - imamo samo oko šest godina.

Prije 6 godina bio je takav startup kada su dečki krenuli s poslom. Ujedinila ih je ideja (nije bilo ništa drugo osim ideje), a mi smo potrčali. Kao i svaki startup, trčali smo brže... Nama je brzina bila važnija od kvalitete.

U jednom trenutku smo stali: shvatili smo da ne možemo više nekako živjeti tom brzinom i tom kvalitetom i prvo se moramo fokusirati na kvalitetu. U ovom trenutku odlučili smo napisati novu platformu koja će biti ispravna, skalabilna i pouzdana. Počeli su pisati ovu platformu (počeli su ulagati, razvijati razvoj, testirati), ali su u jednom trenutku shvatili da nam razvoj i testiranje ne dopuštaju da dosegnemo novu razinu kvalitete usluge.

Napraviš novi proizvod, pustiš ga u proizvodnju, ali svejedno će negdje nešto pogriješiti. A danas ćemo razgovarati o tome kako doći do nove razine kvalitete (kako smo to uspjeli, o našem iskustvu), izbacujući razvoj i testiranje iz jednadžbe; govorit ćemo o tome što je operaciji dostupno - što operacija može učiniti sama, što može ponuditi testiranju kako bi se utjecalo na kvalitetu.

Zastoji. Zapovijedi rada.

Uvijek glavni kamen temeljac, ono o čemu ćemo danas zapravo govoriti je zastoj. Strašna riječ. Ako imamo zastoje, sve nam je loše. Mi trčimo da ga podignemo, admini drže server - daj Bože da ne padne, kako se kaže u onoj pjesmi. O tome ćemo danas govoriti.

Kada smo počeli mijenjati svoje pristupe, formirali smo 4 zapovijedi. Predstavio sam ih na slajdovima:

Ove su zapovijedi vrlo jednostavne:

• Brzo identificirajte problem.
• Riješite ga se još brže.
• Pomozite razumjeti razlog (kasnije, za programere).
• I standardizirati pristupe.

Skrećem vam pozornost na točku broj 2. Mi se rješavamo problema, a ne rješavamo ga. Odlučivanje je sekundarno. Nama je primarno da korisnik bude zaštićen od ovog problema. Ono će postojati u nekom izoliranom okruženju, ali to okruženje neće imati nikakav kontakt s njim. Zapravo, proći ćemo kroz ove četiri grupe problema (neke detaljnije, neke manje detaljnije), reći ću vam što koristimo, kakvo relevantno iskustvo imamo u rješenjima.

Rješavanje problema: Kada se događaju i što učiniti u vezi s njima?

Ali krenut ćemo od reda, počet ćemo s točkom br. 2 - kako se brzo riješiti problema? Postoji problem - moramo ga riješiti. "Što bismo trebali učiniti u vezi s ovim?" - glavno pitanje. I kada smo počeli razmišljati o tome kako riješiti problem, razvili smo za sebe neke zahtjeve koje rješavanje problema mora slijediti.

Kako bismo formulirali ove zahtjeve, odlučili smo si postaviti pitanje: “Kada imamo probleme”? A problemi se, kako se pokazalo, javljaju u četiri slučaja:

• Kvar hardvera.
• Vanjske usluge nisu uspjele.
• Promjena verzije softvera (ista implementacija).
• Eksplozivni rast opterećenja.

O prva dva nećemo. Kvar hardvera može se riješiti prilično jednostavno: morate imati sve duplicirano. Ako su to diskovi, diskovi moraju biti sklopljeni u RAID; ako je ovo poslužitelj, poslužitelj mora biti dupliciran; ako imate mrežnu infrastrukturu, morate nabaviti drugu kopiju mrežne infrastrukture, odnosno uzeti je i umnožiti ga. A ako nešto zakaže, prelazite na rezervno napajanje. Teško je tu nešto više reći.

Drugi je neuspjeh vanjskih usluga. Većini sustav uopće nije problem, ali nama nije. Budući da obrađujemo plaćanja, mi smo agregator koji stoji između korisnika (koji unosi podatke o svojoj kartici) i banaka, platnih sustava (Visa, MasterCard, Mira itd.). Naše vanjske usluge (platni sustavi, banke) imaju tendenciju neuspjeha. Niti mi niti vi (ako imate takve usluge) ne možemo utjecati na to.

Što onda učiniti? Ovdje postoje dvije mogućnosti. Prvo, ako možete, trebali biste na neki način duplicirati ovu uslugu. Na primjer, ako možemo, prebacujemo promet s jedne usluge na drugu: na primjer, kartice su procesuirane preko Sberbanke, Sberbank ima problema - prebacujemo promet [uvjetno] na Raiffeisen. Druga stvar koju možemo učiniti je vrlo brzo primijetiti kvar vanjskih servisa, pa ćemo o brzini odgovora govoriti u sljedećem dijelu izvješća.

Naime, od ova četiri možemo konkretno utjecati na promjenu verzija softvera - poduzeti radnje koje će dovesti do poboljšanja situacije u kontekstu implementacija iu kontekstu eksplozivnog rasta opterećenja. Zapravo, to smo i učinili. Evo opet mala napomena...

Od ova četiri problema, nekoliko se odmah riješi ako imate oblak. Ako ste u oblacima Microsoft Azhur, Ozone, ili koristite naše oblake, s Yandexa ili Mail-a, onda barem kvar hardvera postaje njihov problem i sve vam odmah postaje u redu u kontekstu kvara hardvera.

Mi smo pomalo nekonvencionalna tvrtka. Ovdje svi pričaju o “Kubernetsu”, o oblacima - nemamo ni “Kubernetsa” ni oblaka. Ali imamo police hardvera u mnogim podatkovnim centrima, i prisiljeni smo živjeti na ovom hardveru, prisiljeni smo biti odgovorni za sve to. Stoga ćemo govoriti u ovom kontekstu. Dakle, o problemima. Prva dva su izvučena iz zagrade.

Promjena verzije softvera. Baze

Naši programeri nemaju pristup produkciji. Zašto je to? Samo što imamo PCI DSS certifikat, a naši programeri jednostavno nemaju pravo ulaziti u “proizvod”. To je to, točka. Uopće. Stoga odgovornost za razvoj prestaje točno u trenutku kada razvoj preda gradnju za puštanje.

Naša druga osnova koju imamo, a koja nam također puno pomaže, je nepostojanje jedinstvenog nedokumentiranog znanja. Nadam se da je i tebi tako. Jer ako to nije slučaj, imat ćete problema. Problemi će nastati kada ovo jedinstveno, nedokumentirano znanje nije prisutno u pravo vrijeme na pravom mjestu. Recimo, imate jednu osobu koja zna postaviti određenu komponentu - osoba nije tu, na odmoru je ili je bolesna - to je to, imate problema.

I treća osnova do koje smo došli. Do njega smo došli kroz bol, krv, suze - došli smo do zaključka da svaki naš build sadrži greške, čak i ako je bez grešaka. Sami smo to odlučili: kada nešto implementiramo, kada nešto ubacimo u proizvodnju, imamo međugradnju s pogreškama. Formirali smo zahtjeve koje naš sustav mora zadovoljiti.

Zahtjevi za promjenu verzije softvera

Postoje tri zahtjeva:

• Moramo brzo vratiti implementaciju.
• Moramo minimizirati utjecaj neuspješne implementacije.
• I moramo biti u mogućnosti brzo paralelno rasporediti.
  Upravo tim redom! Zašto? Jer, prije svega, kada postavljate novu verziju, brzina nije bitna, već vam je važno da se, ako nešto pođe po zlu, brzo vratite nazad i imate minimalan utjecaj. Ali ako imate skup verzija u produkciji, za koje se ispostavi da postoji pogreška (iz vedra neba, nije bilo implementacije, ali postoji pogreška) - važna vam je brzina naknadne implementacije. Što smo učinili da ispunimo te zahtjeve? Pribjegli smo sljedećoj metodologiji:

  
  
  Prilično je poznato, mi ga nikad nismo izmislili - ovo je Blue/Green deploy. Što je? Morate imati kopiju za svaku grupu poslužitelja na kojima su vaše aplikacije instalirane. Kopija je “topla”: nema prometa na njoj, ali u bilo kojem trenutku ovaj promet može biti poslan ovoj kopiji. Ova kopija sadrži prethodnu verziju. A u vrijeme implementacije, izbacujete kod na neaktivnu kopiju. Zatim prebacite dio prometa (ili sav) na novu verziju. Dakle, da biste promijenili tok prometa sa stare verzije na novu, trebate učiniti samo jednu radnju: trebate promijeniti balanser u uzvodnom smjeru, promijeniti smjer - s jednog uzvodnog na drugi. Ovo je vrlo zgodno i rješava problem brzog prebacivanja i brzog povratka.

  Ovdje je rješenje drugog pitanja minimizacija: samo dio svog prometa možete poslati na novu liniju, na liniju s novim kodom (neka to bude npr. 2%). A ovih 2% nije 100%! Ako ste izgubili 100% prometa zbog neuspješne implementacije, to je zastrašujuće; ako ste izgubili 2% prometa, to je neugodno, ali nije zastrašujuće. Štoviše, korisnici to najvjerojatnije neće ni primijetiti, jer će u nekim slučajevima (ne u svim) isti korisnik pritiskom na F5 biti prebačen na drugu, radnu verziju.

  Plavo/zelena implementacija. Usmjeravanje

  Međutim, nije sve tako jednostavno “Blue/Green deploy”... Sve naše komponente mogu se podijeliti u tri skupine:

  • ovo je frontend (stranice za plaćanje koje vide naši klijenti);
  • jezgra za obradu;
  • adapter za rad sa sustavima plaćanja (banke, MasterCard, Visa...).

  I tu postoji nijansa - nijansa leži u usmjeravanju između redaka. Ako samo prebacite 100% prometa, nemate tih problema. Ali ako želite promijeniti 2%, počinjete postavljati pitanja: "Kako to učiniti?" Najjednostavnija stvar je ravno naprijed: možete postaviti Round Robin u nginxu nasumičnim odabirom i imate 2% lijevo, 98% desno. Ali ovo nije uvijek prikladno.

  Na primjer, u našem slučaju, korisnik komunicira sa sustavom s više od jednog zahtjeva. To je normalno: 2, 3, 4, 5 zahtjeva - vaši sustavi mogu biti isti. I ako vam je bitno da svi zahtjevi korisnika dolaze u istu liniju na kojoj je došao prvi zahtjev ili (druga točka) svi zahtjevi korisnika dolaze u novu liniju nakon prebacivanja (mogao je ranije početi raditi s sustav, prije prebacivanja), - onda ova nasumična raspodjela nije prikladna za vas. Zatim postoje sljedeće opcije:

  
  
  Prva opcija, najjednostavnija, temelji se na osnovnim parametrima klijenta (IP Hash). Imate IP i dijelite ga s desna na lijevo po IP adresi. Tada će drugi slučaj koji sam opisao raditi za vas, kada je došlo do implementacije, korisnik je već mogao početi raditi s vašim sustavom, a od trenutka implementacije svi će zahtjevi ići u novi redak (na isti, recimo).

  Ako vam iz nekog razloga to ne odgovara i morate slati zahtjeve na liniju na koju je došao početni, početni zahtjev korisnika, onda imate dvije mogućnosti...
  Prva opcija: možete kupiti plaćeni nginx+. Postoji mehanizam Sticky sessions koji, na početni zahtjev korisnika, dodjeljuje sesiju korisniku i veže je za jedan ili drugi uzvodni. Svi sljedeći zahtjevi korisnika unutar životnog vijeka sesije bit će poslani na isti uzvodni kanal gdje je sesija objavljena.

  Ovo nam nije odgovaralo jer smo već imali obični nginx. Nije da je prelazak na nginx+ skup, samo nam je bio malo bolan i nije baš u redu. “Sticks Sessions”, na primjer, nisu radili za nas iz jednostavnog razloga što “Sticks Sessions” ne dopuštaju usmjeravanje na temelju “Ili-ili”. Tamo možete odrediti što mi “Sticks Sessions” radimo, na primjer, prema IP adresi ili prema IP adresi i kolačićima ili prema postparametru, ali “Ili-ili” je tu kompliciranije.

  Stoga smo došli do četvrte opcije. Uzeli smo nginx na steroidima (ovo je openresty) - ovo je isti nginx, koji dodatno podržava uključivanje zadnjih skripti. Možete napisati posljednju skriptu, dati joj "otvoreni odmor", a ova posljednja skripta će se izvršiti kada dođe korisnički zahtjev.

  I napisali smo, zapravo, takvu skriptu, postavili smo sebi “openresti” i u toj skripti sortiramo 6 različitih parametara ulančavanjem “Ili”. Ovisno o prisutnosti jednog ili drugog parametra, znamo da je korisnik došao na jednu ili drugu stranicu, jedan ili drugi redak.

  Plavo/zelena implementacija. Prednosti i nedostatci

  Naravno, vjerojatno je bilo moguće učiniti ga malo jednostavnijim (koristite iste "Sticky Sessions"), ali imamo i takvu nijansu da ne samo da korisnik komunicira s nama u okviru jedne obrade jedne transakcije... Ali sustavi plaćanja također stupaju u interakciju s nama: nakon što obradimo transakciju (slanjem zahtjeva sustavu plaćanja), primamo povratnu informaciju.
  I recimo, ako unutar našeg kruga možemo proslijediti IP adresu korisnika u svim zahtjevima i podijeliti korisnike na temelju IP adrese, tada nećemo reći istoj “Visa”: “Čovječe, mi smo takva retro tvrtka, činimo se biti međunarodni (na web stranici i u Rusiji)... Molimo da nam u dodatnom polju unesete IP adresu korisnika, vaš je protokol standardiziran”! Jasno je da se neće dogovoriti.

  
  
  Stoga nam ovo nije uspjelo - napravili smo openresty. Prema tome, s usmjeravanjem smo dobili nešto ovako:

  Blue/Green Deployment ima, prema tome, prednosti koje sam spomenuo i nedostatke.

  Dva nedostatka:

  • trebate se mučiti s usmjeravanjem;
  • drugi glavni nedostatak je trošak.

  Trebate dvostruko više servera, trebate duplo više operativnih resursa, morate uložiti duplo više truda da održavate cijeli ovaj zoološki vrt.

  Usput, među prednostima postoji još jedna stvar koju prije nisam spomenuo: imate rezervu u slučaju povećanja opterećenja. Ako imate eksplozivan rast opterećenja, imate veliki broj korisnika, onda jednostavno uključite drugu liniju u distribuciju 50 na 50 – i odmah imate x2 servera u klasteru dok ne riješite problem više servera.

  Kako izvršiti brzu implementaciju?

  Razgovarali smo o tome kako riješiti problem minimizacije i brzog vraćanja, ali ostaje pitanje: "Kako brzo implementirati?"

  
  
  Ovdje je kratko i jednostavno.

  • Morate imati CD sustav (Continuous Delivery) - ne možete živjeti bez njega. Ako imate jedan poslužitelj, možete ga postaviti ručno. Imamo oko tisuću i pol poslužitelja i tisuću i pol rukohvata, naravno - možemo postaviti odjel veličine ove prostorije samo da ga rasporedimo.
  • Postavljanje mora biti paralelno. Ako je vaša implementacija sekvencijalna, onda je sve loše. Jedan poslužitelj je normalan, cijeli dan ćete postavljati tisuću i pol poslužitelja.
  • Opet, za ubrzanje, to vjerojatno više nije potrebno. Tijekom implementacije, projekt se obično gradi. Imate web projekt, postoji front-end dio (tamo napravite web pack, kompajlirate npm - tako nešto), i taj proces u principu traje kratko - 5 minuta, ali ovih 5 minuta može biti kritičan. Zato, na primjer, to ne radimo: uklonili smo ovih 5 minuta, postavljamo artefakte.

    Što je artefakt? Artefakt je sastavljena konstrukcija u kojoj su svi dijelovi sklopa već dovršeni. Ovaj artefakt pohranjujemo u skladište artefakata. Svojedobno smo koristili dva takva skladišta - to je bio Nexus, a sada jFrog Artifactory) U početku smo koristili "Nexus" jer smo počeli prakticirati ovaj pristup u java aplikacijama (dobro mu je odgovarao). Zatim su tamo stavili neke od aplikacija napisanih u PHP-u; i “Nexus” više nije odgovarao, pa smo odabrali jFrog Artefactory, koji može artifaktorizirati gotovo sve. Čak smo došli do toga da u ovom repozitoriju artefakata pohranjujemo vlastite binarne pakete koje prikupljamo za poslužitelje.

  Eksplozivni rast opterećenja

  Razgovarali smo o promjeni verzije softvera. Sljedeće što imamo je eksplozivno povećanje opterećenja. Ovdje vjerojatno pod eksplozivnim rastom opterećenja mislim na ne baš pravu stvar...

  Napisali smo novi sustav - orijentiran je na usluge, moderan, lijep, posvuda radnici, posvuda redovi, posvuda asinkronija. A u takvim sustavima podaci mogu teći kroz različite tokove. Za prvu transakciju mogu se koristiti 1., 3., 10. radnik, za drugu transakciju - 2., 4., 5. radnik. I danas, recimo, ujutro imate protok podataka koji koristi prva tri radnika, a navečer se dramatično mijenja i sve koristi ostala tri radnika.

  I ovdje se ispostavlja da morate nekako skalirati radnike, morate nekako skalirati svoje usluge, ali u isto vrijeme spriječiti povećanje resursa.

  
  
  Definirali smo svoje zahtjeve. Ovi zahtjevi su vrlo jednostavni: da postoji otkrivanje usluge, parametrizacija - sve je standardno za izgradnju takvih skalabilnih sustava, osim jedne točke - amortizacija resursa. Rekli smo da nismo spremni amortizirati resurse da serveri griju zrak. Uzeli smo “Consul”, uzeli smo “Nomad” koji upravlja našim radnicima.

  Zašto nam to predstavlja problem? Vratimo se malo unatrag. Sada iza sebe imamo oko 70 sustava plaćanja. Ujutro promet ide preko Sberbanke, onda je pala Sberbanka, recimo, i prebacimo je na drugi platni sustav. Imali smo 100 radnika prije Sberbanke, a nakon toga moramo naglo povećati 100 radnika za drugi platni promet. I poželjno je da se sve to dogodi bez ljudskog sudjelovanja. Jer ako ima ljudskog sudjelovanja, tu bi trebao sjediti inženjer 24/7, koji bi samo to trebao raditi, jer se takvi kvarovi, kad iza tebe stoji 70 sustava, redovito događaju.

  Stoga smo pogledali Nomad koji ima otvoreni IP i napisali svoju stvar Scale-Nomad - ScaleNo koja radi otprilike sljedeće: prati rast reda čekanja i smanjuje ili povećava broj radnika ovisno o dinamici reda čekanja. Kad smo to učinili, pomislili smo: "Možda bismo to mogli otvoriti?" Onda su je pogledali - bila je prosta kao dvije kopejke.

  Za sada ga nismo otvorili, ali ako vam iznenada nakon izvješća, nakon što ste shvatili da vam treba takva stvar, zatreba, moji kontakti su na zadnjem slajdu - molim vas, pišite mi. Ako bude barem 3-5 ljudi mi ćemo ga sponzorirati.

  
  
  Kako radi? Idemo pogledati! Gledajući unaprijed: s lijeve strane nalazi se dio našeg praćenja: ovo je jedna linija, na vrhu je vrijeme obrade događaja, u sredini je broj transakcija, na dnu je broj radnika.

  Ako pogledate, na ovoj slici postoji greška. Na top ljestvici jedna se ljestvica srušila za 45 sekundi - pao je jedan od sustava plaćanja. Odmah je promet uveden za 2 minute i red je počeo rasti na drugom sustavu plaćanja, gdje nije bilo radnika (nismo iskoristili resurse - naprotiv, pravilno smo raspolagali resursom). Nismo htjeli grijati - bio je minimalan broj, oko 5-10 radnika, ali nisu mogli izaći na kraj.

  Zadnji grafikon pokazuje “grbu”, što samo znači da je “Skaleno” udvostručilo ovaj iznos. A onda, kad je graf malo pao, on ga je malo smanjio - automatski se promijenio broj radnika. Tako ova stvar funkcionira. Razgovarali smo o točki broj 2 - "Kako se brzo riješiti razloga."

  Praćenje. Kako brzo prepoznati problem?

  Sada je prva točka "Kako brzo identificirati problem?" Praćenje! Neke stvari moramo brzo shvatiti. Koje bismo stvari trebali brzo shvatiti?

  
  
  Tri stvari!

  • Moramo razumjeti i brzo shvatiti učinak vlastitih resursa.
  • Moramo brzo razumjeti kvarove i pratiti performanse sustava koji su vanjski za nas.
  • Treća točka je identificiranje logičkih pogrešaka. To je ono kad vam sustav radi, sve je normalno po svim pokazateljima, ali nešto pođe po zlu.

  Vjerojatno vam ovdje neću reći ništa tako cool. Ja ću biti kapetan Obvious. Tražili smo što je na tržištu. Imamo "zabavni zoološki vrt". Ovo je vrsta zoološkog vrta koju sada imamo:

  
  
  Koristimo Zabbix za nadzor hardvera, za praćenje glavnih pokazatelja poslužitelja. Koristimo Okmeter za baze podataka. Za sve ostale pokazatelje koji ne odgovaraju prva dva koristimo “Grafana” i “Prometej”, neki uz “Grafana” i “Prometej”, a neki uz “Grafana” uz “Influx” i Telegraf.

  Prije godinu dana htjeli smo koristiti New Relic. Cool stvar, može sve. Ali koliko može sve, toliko je skupa. Kad smo narasli na volumen od 1,5 tisuća poslužitelja, došao nam je dobavljač i rekao: "Zaključimo ugovor za sljedeću godinu." Pogledali smo cijenu i rekli ne, nećemo to učiniti. Sada napuštamo New Relic, ostalo nam je oko 15 poslužitelja pod nadzorom New Relic-a. Cijena se pokazala apsolutno divljom.

  I postoji jedan alat koji smo sami implementirali - ovo je Debugger. Prvo smo ga zvali “Bagger”, ali onda je profesor engleskog prošao, divlje se nasmijao i preimenovao ga u “Debagger”. Što je? Ovo je alat koji zapravo u 15-30 sekundi na svakoj komponenti, poput “crne kutije” sustava, izvodi testove ukupne izvedbe komponente.

  Na primjer, ako postoji eksterna stranica (stranica za plaćanje), on je jednostavno otvori i pogleda kako treba izgledati. Ako se radi o obradi, on šalje probnu "transakciju" i osigurava da ta "transakcija" stigne. Ako se radi o vezi s platnim sustavima, onda tamo gdje možemo ispalimo testni zahtjev i vidimo da je kod nas sve u redu.

  Koji su pokazatelji važni za praćenje?

  Što uglavnom pratimo? Koji su nam pokazatelji važni?

  
  

  • Vrijeme odziva / RPS na frontama vrlo je važan pokazatelj. Odmah odgovara da s tobom nešto nije u redu.
  • Broj obrađenih poruka u svim redovima.
  • Broj radnika.
  • Osnovna metrika ispravnosti.

  Posljednja točka je "posao", "poslovna" metrika. Ako želite pratiti istu stvar, trebate definirati jednu ili dvije metrike koje su vam glavni pokazatelji. Naša metrika je protok (ovo je omjer broja uspješnih transakcija prema ukupnom tijeku transakcija). Ako se u njoj nešto mijenja u intervalu od 5-10-15 minuta, znači da imamo problema (ako se radikalno mijenja).

  Kako to kod nas izgleda je primjer jedne od naših ploča:

  
  
  Na lijevoj strani nalazi se 6 grafikona, to je prema linijama - broj radnika i broj poruka u redovima. Na desnoj strani - RPS, RTS. Ispod je ista "poslovna" metrika. A u metrici “business” odmah vidimo da je nešto pošlo krivo u dva srednja grafikona... Ovo je samo još jedan sustav koji stoji iza nas koji je pao.

  Druga stvar koju smo morali učiniti je pratiti pad vanjskih sustava plaćanja. Ovdje smo uzeli OpenTracing - mehanizam, standard, paradigmu koja vam omogućuje praćenje distribuiranih sustava; i to je malo promijenjeno. Standardna OpenTracing paradigma kaže da gradimo praćenje za svaki pojedinačni zahtjev. Ovo nam nije trebalo i zamotali smo to u sažetak, agregacijski trag. Napravili smo alat koji nam omogućuje praćenje brzine sustava iza nas.

  
  
  Grafikon nam pokazuje da je jedan od sustava plaćanja počeo odgovarati za 3 sekunde - imamo problema. Štoviše, ova stvar će reagirati kada problemi počnu, u intervalu od 20-30 sekundi.

  I treća klasa pogrešaka praćenja koja postoji je logično praćenje.

  Da budem iskren, nisam znao što da nacrtam na ovom slajdu, jer smo dugo tražili na tržištu nešto što bi nam odgovaralo. Nismo ništa našli, pa smo morali sami.

  
  
  Što mislim pod logičnim praćenjem? Pa zamislite: napravite si sustav (na primjer, klon Tindera); ti si to napravio, lansirao si. Uspješni menadžer Vasya Pupkin stavio ga je na svoj telefon, vidi tamo djevojku, sviđa mu se... i lajk ne ide djevojci - lajk ide zaštitaru Mikhalychu iz istog poslovnog centra. Upravitelj siđe u prizemlje, a zatim se zapita: "Zašto mu se taj zaštitar Mikhalych tako lijepo smiješi?"

  U takvim situacijama... Za nas ova situacija zvuči malo drugačije, jer (napisao sam) radi se o gubitku ugleda koji neizravno dovodi do financijskih gubitaka. Kod nas je situacija suprotna: možemo pretrpjeti izravne financijske gubitke – primjerice, ako smo transakciju proveli kao uspješnu, ali je bila neuspješna (ili obrnuto). Morao sam napisati vlastiti alat koji prati broj uspješnih transakcija tijekom vremena pomoću poslovnih pokazatelja. Nisam našao ništa na tržištu! To je upravo ideja koju sam želio prenijeti. Na tržištu ne postoji ništa što bi riješilo ovakav problem.

  Ovdje se radilo o tome kako brzo identificirati problem.

  Kako utvrditi razloge za raspoređivanje

  Treća skupina problema koje rješavamo je nakon što smo identificirali problem, nakon što smo ga se riješili, bilo bi dobro shvatiti razlog razvoja, testiranja i učiniti nešto po tom pitanju. Sukladno tome, trebamo istraživati, trebamo podizati balvane.

  
  
  Ako govorimo o zapisnicima (glavni razlog su zapisnici), većina naših zapisnika je u ELK Stacku - gotovo svi imaju isti. Za neke možda nije u ELK-u, ali ako pišete zapise u gigabajtima, prije ili kasnije ćete doći u ELK. Zapisujemo ih u terabajtima.

  
  
  Ovdje postoji problem. Popravili smo to, ispravili grešku za korisnika, počeli iskopavati što je tamo bilo, popeli se u Kibanu, unijeli tamo ID transakcije i dobili ovakvu krpicu (pokazuje puno). I apsolutno ništa nije jasno u ovoj krpi. Zašto? Da, jer nije jasno koji dio pripada kojem radniku, koji dio pripada kojoj komponenti. I u tom smo trenutku shvatili da nam treba praćenje - isti OpenTracing o kojem sam govorio.

  To smo mislili prije godinu dana, usmjerili pažnju na tržište, a tu su bila dva alata - “Zipkin” i “Jaeger”. “Jager” je zapravo takav ideološki nasljednik, ideološki nasljednik “Zipkina”. U Zipkinu je sve dobro, osim što ne zna agregirati, ne zna uključiti dnevnike u praćenje, samo vremensko praćenje. I “Jager” je to podržao.

  Pogledali smo “Jager”: možete instrumentirati aplikacije, možete pisati u API-ju (Api standard za PHP u to vrijeme, međutim, nije bio odobren - to je bilo prije godinu dana, ali sada je već odobren), ali postoji nije bio nikakav klijent. "U redu", pomislili smo i napisali vlastitom klijentu. Što smo dobili? Ovako to otprilike izgleda:

  
  
  U Jaegeru se za svaku poruku kreiraju rasponi. Odnosno, kada korisnik otvori sustav, vidi jedan ili dva bloka za svaki dolazni zahtjev (1-2-3 - broj dolaznih zahtjeva od korisnika, broj blokova). Kako bismo olakšali korisnicima, dodali smo oznake u zapisnike i vremenske tragove. Sukladno tome, u slučaju greške, naša aplikacija će označiti zapisnik odgovarajućom oznakom greške. Možete filtrirati prema oznaci pogreške i prikazat će se samo rasponi koji sadrže ovaj blok s pogreškom. Ovako to izgleda ako proširimo raspon:

  
  
  Unutar raspona nalazi se niz tragova. U ovom slučaju to su tri testna traga, a treći nam govori da je došlo do greške. U isto vrijeme, ovdje vidimo vremenski trag: imamo vremensku ljestvicu na vrhu i vidimo u kojem vremenskom intervalu je snimljen ovaj ili onaj dnevnik.

  Sukladno tome, stvari su nam išle dobro. Napisali smo vlastito proširenje i otvorili smo ga. Ako želite raditi s praćenjem, ako želite raditi s “Jagerom” u PHP-u, tu je naše proširenje, dobrodošli na korištenje, kako kažu:

  
  
  Imamo ovo proširenje - to je klijent za OpenTracing Api, napravljeno je kao php-nastavak, odnosno morat ćete ga sastaviti i instalirati na sustav. Prije godinu dana nije bilo ništa drugačije. Sada postoje drugi klijenti koji su poput komponenti. Ovdje je na vama: ili ćete pumpati komponente sa skladateljem ili ćete koristiti proširenje po vašoj želji.

  Korporacijski standardi

  Razgovarali smo o tri zapovijedi. Četvrta zapovijed je standardizirati pristupe. o cemu se radi Radi se o ovome:

  
  
  Zašto je ovdje riječ "korporacija"? Ne zato što smo velika ili birokratska tvrtka, ne! Htio sam ovdje upotrijebiti riječ "korporativno" u kontekstu da bi svaka tvrtka, svaki proizvod trebao imati vlastite standarde, uključujući i vas. Koje standarde imamo?

  
  

  • Imamo propise o raspoređivanju. Ne mrdamo nikuda bez njega, ne možemo. Raspoređujemo oko 60 puta tjedno, odnosno raspoređujemo gotovo stalno. Istodobno, imamo, primjerice, u pravilniku o raspoređivanju tabu rasporeda petkom – u principu ne raspoređujemo.
  • Potrebna nam je dokumentacija. Niti jedna nova komponenta ne ulazi u proizvodnju ako za nju ne postoji dokumentacija, čak i ako je rođena pod perom naših stručnjaka za istraživanje i razvoj. Od njih zahtijevamo upute za implementaciju, mapu praćenja i grubi opis (dobro, kako programeri mogu napisati) kako ova komponenta radi, kako je otkloniti.
  • Ne rješavamo uzrok problema, nego problem - što sam već rekao. Važno nam je zaštititi korisnika od problema.
  • Imamo odobrenja. Na primjer, ne smatramo prekidom rada ako smo izgubili 2% prometa unutar dvije minute. To u osnovi nije uključeno u našu statistiku. Ako je više postotno ili privremeno, već računamo.
  • I uvijek pišemo obdukcije. Što god da nam se dogodi, svaka situacija da se netko nenormalno ponaša u proizvodnji odrazit će se na obdukciju. Obdukcija je dokument u kojem pišete što vam se dogodilo, detaljno vrijeme, što ste učinili da to ispravite i (ovo je obavezan blok!) što ćete učiniti da spriječite da se to dogodi u budućnosti. Ovo je obavezno i ​​neophodno za naknadnu analizu.

  Što se smatra zastojem?

  
  
  Čemu je sve to dovelo?

  To je dovelo do činjenice da (imali smo određenih problema sa stabilnošću, to nije odgovaralo ni klijentima ni nama) u zadnjih 6 mjeseci naš pokazatelj stabilnosti bio je 99,97. Možemo reći da to nije puno. Da, imamo čemu težiti. Od tog pokazatelja otprilike polovica je stabilnost, takoreći, ne našeg, nego vatrozida naše web aplikacije, koji stoji ispred nas i koristi se kao servis, ali klijente to ne zanima.

  Naučili smo spavati noću. Konačno! Prije šest mjeseci nismo mogli. I na ovu bilješku s rezultatima, htio bih napraviti jednu napomenu. Sinoć je bila prekrasna reportaža o sustavu upravljanja za nuklearni reaktor. Ako me ljudi koji su napisali ovaj sustav mogu čuti, zaboravite ono što sam rekao o tome da "2% nije zastoj." Za vas je 2% prekid rada, makar i na dvije minute!

  To je sve! Vaša pitanja.

  
  

  O balanserima i migraciji baze podataka

  Pitanje iz publike (u daljnjem tekstu – B): – Dobra večer. Hvala vam puno na takvom izvješću administratora! Kratko pitanje o vašim balanserima. Spomenuli ste da imate WAF, odnosno, koliko sam shvatio, koristite nekakav vanjski balanser...

  EK: – Ne, koristimo naše usluge kao balanser. U ovom slučaju, WAF je za nas isključivo alat za DDoS zaštitu.

  NA: – Možete li reći nekoliko riječi o balanserima?

  EK: – Kao što sam već rekao, ovo je grupa servera u openrestyju. Sada imamo 5 rezervnih grupa koje odgovaraju isključivo... odnosno server koji pokreće isključivo openresty, on samo proxira promet. Sukladno tome, da shvatimo koliko držimo: sada imamo redoviti promet od nekoliko stotina megabita. Snalaze se, dobro se osjećaju, čak se i ne naprežu.

  NA: – Također jednostavno pitanje. Ovdje je plavo/zelena implementacija. Što radite, na primjer, s migracijama baza podataka?

  EK: - Dobro pitanje! Gledajte, u plavo/zelenoj implementaciji imamo zasebne redove za svaku liniju. Odnosno, ako govorimo o redovima događaja koji se prenose od radnika do radnika, postoje odvojeni redovi za plavu liniju i za zelenu liniju. Ako govorimo o samoj bazi podataka, onda smo je namjerno suzili koliko smo mogli, praktički sve prebacili u redove, u bazi pohranjujemo samo hrpu transakcija. A naš transakcijski stog isti je za sve linije. S bazom podataka u ovom kontekstu: ne dijelimo je na plavu i zelenu, jer obje verzije koda moraju znati što se događa s transakcijom.

  Prijatelji, imam i malu nagradu da vas potaknem - knjigu. I trebao bih dobiti nagradu za najbolje pitanje.

  NA: - Zdravo. Hvala na izvješću. Pitanje je ovo. Pratiš uplate, pratiš servise s kojima komuniciraš... Ali kako pratiti da je osoba nekako došla na tvoju stranicu za plaćanje, izvršila uplatu, a projekt joj je kreditirao novac? Odnosno, kako nadzirati da je trgovac dostupan i da li je prihvatio vaš povratni poziv?

  EK: – “Merchant” je za nas u ovom slučaju potpuno ista vanjska usluga kao i platni sustav. Pratimo brzinu reakcije trgovca.

  O enkripciji baze podataka

  NA: - Zdravo. Imam malo povezano pitanje. Imate PCI DSS osjetljive podatke. Htio sam znati kako pohranjujete PAN-ove u redove čekanja u koje trebate prenijeti? Koristite li neku enkripciju? A to dovodi do drugog pitanja: prema PCI DSS-u potrebno je povremeno ponovno šifrirati bazu podataka u slučaju promjena (otpuštanje administratora, itd.) - što se u tom slučaju događa s pristupačnošću?

  
  
  EK: - Divno pitanje! Prvo, ne pohranjujemo PAN-ove u redovima čekanja. U načelu nemamo pravo pohraniti PAN nigdje u jasnom obliku, stoga koristimo posebnu uslugu (nazivamo je “Kademon”) - to je usluga koja radi samo jednu stvar: prima poruku kao ulaz i šalje poslati šifriranu poruku. I sve pohranjujemo s ovom šifriranom porukom. Sukladno tome, duljina našeg ključa je ispod kilobajta, tako da je ovo ozbiljno i pouzdano.

  NA: – Trebate li sada 2 kilobajta?

  EK: – Kao da je jučer bilo 256... Pa gdje drugdje?!

  Sukladno tome, ovo je prvi. I drugo, rješenje koje postoji, podržava proceduru re-enkripcije - postoje dva para “keksova” (ključeva), koji daju “špilove” koji šifriraju (ključevi su ključevi, dek su derivati ​​ključeva koji šifriraju) . A ako je postupak pokrenut (to se događa redovito, od 3 mjeseca do ± nekih), preuzimamo novi par „kolača“ i ponovno šifriramo podatke. Imamo zasebne usluge koje izvlače sve podatke i šifriraju ih na novi način; Podaci se pohranjuju uz identifikator ključa kojim su šifrirani. Sukladno tome, čim kriptiramo podatke novim ključevima, brišemo stari ključ.

  Ponekad je plaćanje potrebno izvršiti ručno...

  NA: – Odnosno, ako je stigao povrat novca za neku operaciju, hoćete li ga i dalje dešifrirati starim ključem?

  EK: - Da.

  NA: – Onda još jedno malo pitanje. Kada se dogodi neka vrsta kvara, pada ili incidenta, potrebno je ručno progurati transakciju. Postoji takva situacija.

  EK: - Da ponekad.

  NA: – Odakle vam ovi podaci? Ili sami idete u ovo skladište?

  EK: – Ne, pa, naravno, imamo nekakav back-office sustav koji sadrži sučelje za našu podršku. Ako ne znamo u kakvom je statusu transakcija (npr. dok sustav plaćanja nije odgovorio timeoutom), ne znamo a priori, odnosno samo s punim povjerenjem dodjeljujemo konačni status. U tom slučaju transakciji dodjeljujemo poseban status za ručnu obradu. Ujutro, sljedeći dan, čim podrška dobije informaciju da te i takve transakcije ostaju u sustavu plaćanja, ručno ih obrađuju u ovom sučelju.

  
  
  NA: – Imam par pitanja. Jedan od njih je nastavak PCI DSS zone: kako bilježite njihov krug? Ovo pitanje je zato što je programer mogao staviti bilo što u zapisnike! Drugo pitanje: kako uvesti hitne popravke? Korištenje oznaka u bazi podataka je jedna od opcija, ali mogu postojati besplatni hitni popravci - kakav je tamo postupak? I treće pitanje je vjerojatno vezano za RTO, RPO. Vaša dostupnost bila je 99,97, skoro četiri devetke, ali koliko sam shvatio, imate drugi podatkovni centar, treći podatkovni centar i peti podatkovni centar... Kako ih sinkronizirati, replicirati i sve ostalo?

  EK: - Počnimo s prvim. Je li prvo pitanje bilo o trupcima? Kada pišemo zapise, imamo sloj koji maskira sve osjetljive podatke. Gleda masku i dodatna polja. Sukladno tome, naši zapisnici izlaze s već maskiranim podacima i PCI DSS sklopom. Ovo je jedan od redovitih zadataka odjela za testiranje. Obavezni su provjeriti svaki zadatak, uključujući i logove koje pišu, a to je jedan od redovitih zadataka prilikom pregleda koda, kako bi se kontroliralo da programer nije nešto zapisao. Naknadne provjere ovoga redovito provodi odjel za informacijsku sigurnost otprilike jednom tjedno: selektivno se uzimaju zapisi za zadnji dan i prolaze kroz poseban skener-analizator s testnih poslužitelja kako bi se sve provjerilo.
  O hitnim popravcima. To je uključeno u naše propise o raspoređivanju. Imamo zasebnu klauzulu o hitnim popravcima. Vjerujemo da hitne popravke postavljamo XNUMX sata na dan kada su nam potrebni. Čim se verzija sastavi, čim se pokrene, čim imamo artefakt, imamo dežurnog sistem administratora na poziv podrške i on to deploira u trenutku kada je potrebno.

  O "četiri devetke". Brojka koju sada imamo uistinu je postignuta, a težili smo joj u drugom podatkovnom centru. Sada imamo drugi podatkovni centar i počinjemo usmjeravati između njih, a pitanje replikacije između podatkovnih centara doista je netrivijalno pitanje. Jednom smo to pokušali riješiti različitim sredstvima: pokušali smo upotrijebiti istu "Tarantulu" - nije nam uspjelo, odmah ću vam reći. Zato smo “sens” na kraju naručili ručno. Zapravo, svaka aplikacija u našem sustavu asinkrono pokreće potrebnu sinkronizaciju "promjena - učinjeno" između podatkovnih centara.

  NA: – Ako ste dobili drugu, zašto niste dobili i treću? Jer još nitko nema split-brain...

  EK: – Ali mi nemamo Split Brain. S obzirom na to da svaku aplikaciju vodi multimaster, nije nam bitno u koji centar je zahtjev stigao. Spremni smo na činjenicu da ako jedan od naših podatkovnih centara zakaže (oslanjamo se na to) i usred korisničkog zahtjeva prijeđe na drugi podatkovni centar, spremni smo izgubiti ovog korisnika, doista; ali to će biti jedinice, apsolutne jedinice.

  NA: - Dobra večer. Hvala na izvješću. Govorili ste o svom alatu za ispravljanje pogrešaka, koji izvodi neke testne transakcije u proizvodnji. Ali recite nam o testnim transakcijama! Koliko duboko ide?

  EK: – Prolazi puni ciklus cijele komponente. Za komponentu nema razlike između testne transakcije i proizvodne transakcije. Ali s logične točke gledišta, ovo je jednostavno zaseban projekt u sustavu, na kojem se izvode samo testne transakcije.

  NA: -Gdje ga prekidaš? Ovdje je Core poslao...

  EK: – Mi stojimo iza “Kora” u ovom slučaju za probne transakcije... Imamo nešto poput usmjeravanja: “Kor” zna kojem sustavu plaćanja treba poslati – šaljemo lažnom sustavu plaćanja, koji jednostavno daje http signal i to je sve.

  NA: – Recite mi, molim vas, je li vaša aplikacija napisana u jednom ogromnom monolitu ili ste je razrezali na neke usluge ili čak mikroservise?

  EK: – Nemamo monolit, naravno, imamo servisno orijentiranu aplikaciju. U šali kažemo da je naš servis sastavljen od monolita - stvarno su veliki. Teško je to nazvati mikroservisima, ali to su servisi unutar kojih rade radnici distribuiranih strojeva.

  Ako je usluga na poslužitelju ugrožena...

  NA: – Onda imam sljedeće pitanje. Čak i da je riječ o monolitu, još uvijek ste rekli da imate mnogo ovih instant poslužitelja, svi oni u osnovi obrađuju podatke, a pitanje je: "U slučaju kompromitacije jednog od instant poslužitelja ili aplikacije, svaka pojedinačna poveznica , imaju li neku vrstu kontrole pristupa? Tko od njih što može? Kome se obratiti za koje informacije?

  
  
  EK: - Da definitivno. Sigurnosni zahtjevi su prilično ozbiljni. Prvo, imamo otvorena kretanja podataka, a portovi su samo oni kroz koje unaprijed predviđamo kretanje prometa. Ako komponenta komunicira s bazom podataka (recimo, s Muskul-om) putem 5-4-3-2, samo će joj 5-4-3-2 biti otvoren, a drugi portovi i drugi prometni pravci neće biti dostupni. Osim toga, morate razumjeti da u našoj proizvodnji postoji oko 10 različitih sigurnosnih petlji. Čak i ako je aplikacija na neki način kompromitirana, ne daj Bože, napadač neće moći pristupiti konzoli za upravljanje poslužiteljem, jer je ovo druga sigurnosna zona mreže.

  NA: – I u tom kontekstu, ono što mi je zanimljivije je da imate određene ugovore sa službama – što one mogu raditi, preko kojih “akcija” mogu kontaktirati jedna s drugom... A u normalnom toku neke specifične službe traže neke redak, popis "radnji" na drugom. Čini se da se u normalnoj situaciji ne okreću drugima, a imaju druga područja odgovornosti. Ako je jedan od njih kompromitiran, hoće li moći poremetiti “akcije” tog servisa?..

  EK: - Razumijem. Ako je u normalnoj situaciji s drugim poslužiteljem komunikacija uopće bila dopuštena, onda da. Prema SLA ugovoru, ne pratimo da su vam dopuštene samo prve 3 "radnje", a nisu vam dopuštene 4 "radnje". To nam je vjerojatno suvišno, jer već imamo sustav zaštite od 4 razine, u načelu, za strujne krugove. Radije se branimo konturama, nego na razini unutrašnjosti.

  Kako funkcioniraju Visa, MasterCard i Sberbank

  NA: – Želim pojasniti jednu točku oko prebacivanja korisnika iz jednog podatkovnog centra u drugi. Koliko ja znam, Visa i MasterCard rade koristeći 8583 binarni sinkroni protokol, a tu ima i kombinacija. I htio sam znati, sada mislimo na promjenu - je li to izravno "Visa" i "MasterCard" ili prije sustava plaćanja, prije obrade?

  EK: - Ovo je prije mikseva. Naši miksevi nalaze se u istom podatkovnom centru.

  NA: – Grubo rečeno, imate li jednu vezu?

  EK: – “Visa” i “MasterCard” - da. Jednostavno zato što Visa i MasterCard zahtijevaju prilično ozbiljna ulaganja u infrastrukturu za sklapanje zasebnih ugovora za dobivanje drugog para mješavina, na primjer. Oni su rezervirani unutar jednog podatkovnog centra, ali ako, ne daj Bože, crkne naš podatkovni centar, gdje postoje miksevi za spajanje na Visu i MasterCard, onda ćemo izgubiti vezu s Visom i MasterCardom...

  NA: – Kako se mogu rezervirati? Znam da Visa u principu dozvoljava samo jednu vezu!

  EK: – Opremu dobavljaju sami. U svakom slučaju dobili smo opremu koja je unutra potpuno suvišna.

  NA: – Znači štand je iz njihovog Connects Orangea?..

  EK: - Da.

  NA: – Ali što je s ovim slučajem: ako vaš podatkovni centar nestane, kako ga možete nastaviti koristiti? Ili se promet samo zaustavlja?

  EK: - Ne. U tom slučaju jednostavno ćemo prebaciti promet na drugi kanal, što će, naravno, biti skuplje i za nas i za naše klijente. Ali promet neće ići preko naše izravne veze s Visom, MasterCardom, nego preko uvjetne Sberbanke (jako pretjerano).

  Divno se ispričavam ako sam uvrijedio zaposlenike Sberbanke. No, prema našoj statistici, među ruskim bankama Sberbank najčešće pada. Ne prođe mjesec, a da u Sberbanci nešto ne padne.

  
  
  

  Neki oglasi 🙂

  Hvala što ste ostali s nama. Sviđaju li vam se naši članci? Želite li vidjeti više zanimljivog sadržaja? Podržite nas narudžbom ili preporukom prijateljima, cloud VPS za programere od 4.99 USD, jedinstveni analog poslužitelja početne razine, koji smo izmislili za vas: Cijela istina o VPS (KVM) E5-2697 v3 (6 jezgri) 10GB DDR4 480GB SSD 1Gbps od 19 USD ili kako podijeliti poslužitelj? (dostupno s RAID1 i RAID10, do 24 jezgre i do 40 GB DDR4).

  Dell R730xd 2 puta jeftiniji u Equinix Tier IV podatkovnom centru u Amsterdamu? Samo ovdje 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV od 199 USD u Nizozemskoj! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB - od 99 USD! Pročitaj o Kako izgraditi infrastrukturu corp. klase uz korištenje Dell R730xd E5-2650 v4 servera vrijednih 9000 eura za lipu?

Izvor: www.habr.com