HighLoad++, Evgeniy Kuzovlev (EcommPay IT): šta učiniti kada minut zastoja košta 100000 dolara

Svi pričaju o procesima razvoja i testiranja, obuci osoblja, povećanju motivacije, ali ti procesi nisu dovoljni kada minut zastoja usluge košta enormne svote novca. Šta učiniti kada obavljate finansijske transakcije pod strogim SLA? Kako povećati pouzdanost i toleranciju grešaka vaših sistema, izvlačeći razvoj i testiranje iz jednačine?

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

Evgeniy Kuzovlev (u daljem tekstu – EK): - Prijatelji, zdravo! Moje ime je Kuzovlev Evgeniy. Ja sam iz kompanije EcommPay, specifična divizija je EcommPay IT, IT odjel 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: „Šta učiniti kada minut zastoja košta 100 dolara“? Gledajući unaprijed, naši brojevi su uporedivi.

Šta radi EcommPay IT?

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

EcommPay grupa kompanija je međunarodni preuzimač. Obrađujemo plaćanja širom svijeta - u Rusiji, Evropi, jugoistočnoj Aziji (All Around the World). Imamo 9 kancelarija, ukupno 500 zaposlenih, a otprilike nešto manje od polovine su IT stručnjaci. Sve što radimo, sve od čega zarađujemo, uradili 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; Mi sami pišemo, razvijamo se. A trenutno izvršimo oko milion transakcija dnevno (milioni je vjerovatno pravi način da se to kaže). Mi smo prilično mlada kompanija - imamo samo oko šest godina.

Prije 6 godina bio je takav startup kada su momci došli zajedno s poslom. Njih je ujedinila ideja (nije bilo ništa osim ideje), a mi smo se kandidovali. Kao i svaki startup, trčali smo brže... Nama je brzina bila važnija od kvaliteta.

U nekom trenutku smo stali: shvatili smo da više nekako ne možemo živjeti tom brzinom i kvalitetom i moramo se prvo fokusirati na kvalitet. U ovom trenutku smo odlučili da napišemo novu platformu koja bi bila 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 omogućavaju da dostignemo novi nivo kvaliteta usluge.

Napraviš novi proizvod, pustiš ga u proizvodnju, ali ipak će negdje nešto poći po zlu. A danas ćemo pričati o tome kako doći do novog nivoa kvaliteta (kako smo to uradili, o našem iskustvu), izvlačeći razvoj i testiranje iz jednačine; razgovaraćemo o tome šta je dostupno za rad – šta operacija može sama da uradi, šta može ponuditi testiranju kako bi uticala na kvalitet.

Zastoji. Zapovijedi rada.

Uvek glavni kamen temeljac, ono o čemu ćemo danas zapravo pričati je zastoj. Užasna reč. Ako imamo zastoje, sve je loše po nas. Trčimo da ga podignemo, admini drže server - daj Bože da ne padne, kako se kaže u onoj pesmi. To je ono o čemu ćemo danas razgovarati.

Kada smo počeli da menjamo naše pristupe, formirali smo 4 zapovesti. Imam ih predstavljene na slajdovima:

Ove zapovesti su prilično jednostavne:

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

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

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

Ali počet ćemo van reda, počet ćemo s tačkom br. 2 - kako se brzo riješiti problema? Postoji problem - moramo ga popraviti. „Šta da radimo povodom ovoga?“ - glavno pitanje. A 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 da sebi postavimo pitanje: „Kada imamo problema“? A problemi se, kako se pokazalo, javljaju u četiri slučaja:

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

O prva dva nećemo. Neispravnost hardvera može se riješiti vrlo jednostavno: morate sve duplicirati. Ako se radi o diskovima, diskovi moraju biti sastavljeni u RAID-u; ako je ovo server, server mora biti dupliciran; ako imate mrežnu infrastrukturu, morate dostaviti drugu kopiju mrežne infrastrukture, odnosno uzeti je i duplirajte ga. A ako nešto pokvari, prelazite na rezervnu snagu. Teško je ovde nešto više reći.

Drugi je neuspjeh vanjskih usluga. Za većinu sistem uopšte nije problem, ali ne i za nas. Pošto obrađujemo plaćanja, mi smo agregator koji stoji između korisnika (koji unosi podatke svoje kartice) i banaka, platnih sistema (Visa, MasterCard, Mira itd.). Naše eksterne usluge (platni sistemi, banke) imaju tendenciju da propadnu. Ni mi ni vi (ako imate takve usluge) ne možemo uticati na to.

Šta onda učiniti? Ovdje postoje dvije opcije. Prvo, ako možete, trebali biste na neki način duplicirati ovu uslugu. Na primjer, ako možemo, prenosimo promet s jedne usluge na drugu: na primjer, kartice su obrađene preko Sberbanke, Sberbank ima problema - prenosimo promet [uslovno] na Raiffeisen. Druga stvar koju možemo učiniti je da vrlo brzo uočimo kvar eksternih servisa, pa ćemo o brzini odgovora govoriti u narednom dijelu izvještaja.

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

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

Mi smo malo nekonvencionalna kompanija. Ovdje svi pričaju o “kubernetima”, o oblacima – nemamo ni “kuberneta” ni oblaka. Ali mi imamo police sa hardverom u mnogim data centrima, i mi smo primorani da živimo na ovom hardveru, primorani smo da budemo odgovorni za sve. Stoga ćemo razgovarati u ovom kontekstu. Dakle, o problemima. Prva dva su izvučena iz zagrada.

Promjena verzije softvera. Baze

Naši programeri nemaju pristup proizvodnji. Žašto je to? Samo što smo PCI DSS certificirani, a naši programeri jednostavno nemaju pravo ulaziti u “proizvod”. To je to, tačka. Uopšte. Stoga, razvojna odgovornost prestaje tačno u trenutku kada razvoj preda build za izdavanje.

Naša druga osnova koju imamo, a koja nam takođe mnogo pomaže, jeste odsustvo jedinstvenog nedokumentovanog znanja. Nadam se da je i tebi isto. Jer ako to nije slučaj, imat ćete problema. Problemi će nastati kada ovo jedinstveno, nedokumentovano znanje ne bude prisutno u pravo vrijeme na pravom mjestu. Recimo da imate jednu osobu koja zna da rasporedi 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 toga smo došli kroz bol, krv, suze - došli smo do zaključka da bilo koja naša konstrukcija sadrži greške, čak i ako je bez grešaka. Ovo smo sami odlučili: kada nešto implementiramo, kada nešto uvedemo u proizvodnju, imamo build s greškama. Formirali smo zahtjeve koje naš sistem mora zadovoljiti.

Zahtjevi za promjenu verzije softvera

Postoje tri zahtjeva:

• Moramo brzo poništiti raspoređivanje.
• Moramo minimizirati utjecaj neuspješnog postavljanja.
• I moramo biti u mogućnosti da se brzo rasporedimo paralelno.
  Upravo tim redosledom! Zašto? Jer, prije svega, kada postavljate novu verziju, brzina nije bitna, ali vam je važno, ako nešto krene po zlu, da se brzo vratite i imate minimalan utjecaj. Ali ako imate skup verzija u produkciji, za koje se ispostavi da postoji greška (iz vedra neba, nije bilo implementacije, ali postoji greška) - bitna vam je brzina naknadne implementacije. Šta smo uradili da ispunimo ove zahtjeve? Pribjegli smo sljedećoj metodologiji:

  
  
  Prilično je poznato, nikada ga nismo izmislili - ovo je Plavo/Zeleno postavljanje. Šta je to? Morate imati kopiju za svaku grupu servera na kojima su vaše aplikacije instalirane. Kopija je “topla”: na njoj nema saobraćaja, ali se u svakom trenutku ovaj promet može poslati ovoj kopiji. Ova kopija sadrži prethodnu verziju. I u vrijeme implementacije, kod razvijate neaktivnu kopiju. Zatim prebacujete dio prometa (ili cijeli) 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 dijelu, promijeniti smjer - od jednog uzvodno do drugog. Ovo je vrlo zgodno i rješava problem brzog prebacivanja i brzog vraćanja.

  Ovdje je rješenje za drugo pitanje minimizacija: možete poslati samo dio vašeg prometa na novu liniju, na liniju s novim kodom (neka bude, na primjer, 2%). A ovih 2% nije 100%! Ako ste izgubili 100% prometa zbog neuspješnog postavljanja, to je zastrašujuće; ako ste izgubili 2% prometa, to je neugodno, ali nije strašno. Štaviše, korisnici to najvjerovatnije 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/zeleno postavljanje. Routing

  Međutim, nije sve tako jednostavno “Plavo/zeleno postavljanje”... Sve naše komponente možemo podijeliti u tri grupe:

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

  I ovdje postoji nijansa - nijansa leži u usmjeravanju između redova. Ako samo prebacite 100% saobraćaja, nemate ovih problema. Ali ako želite promijeniti 2%, počinjete postavljati pitanja: "Kako to učiniti?" Najjednostavnija stvar je direktna: možete postaviti Round Robin u nginx nasumično, i imate 2% lijevo, 98% desno. Ali ovo nije uvijek prikladno.

  Na primjer, u našem slučaju, korisnik stupa u interakciju sa sistemom s više od jednog zahtjeva. Ovo je normalno: 2, 3, 4, 5 zahtjeva - vaši sistemi mogu biti isti. I ako vam je važno da svi zahtjevi korisnika dolaze u istu liniju na kojoj je došao prvi zahtjev, ili (druga tačka) svi zahtjevi korisnika dolaze u novu liniju nakon prebacivanja (mogao je početi raditi ranije sa sistem, prije prekidača), - onda ova nasumična distribucija nije prikladna za vas. Zatim postoje sljedeće opcije:

  
  
  Prva opcija, najjednostavnija, zasniva se na osnovnim parametrima klijenta (IP Hash). Imate IP i dijelite ga s desna na lijevo po IP adresi. Tada će vam raditi drugi slučaj koji sam opisao, kada je došlo do implementacije, korisnik je već mogao početi raditi sa vašim sistemom, a od trenutka postavljanja svi zahtjevi će ići na novu liniju (na isti, recimo).

  Ako vam iz nekog razloga ovo ne odgovara i morate slati zahtjeve na liniju na koju je došao korisnikov početni, početni zahtjev, 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 vezuje je za jednu ili drugu uzvodnu. Svi naredni korisnički zahtjevi unutar životnog vijeka sesije bit će poslani istom uzvodnom mjestu gdje je sesija objavljena.

  Ovo nam nije odgovaralo jer smo već imali običan nginx. Prebacivanje na nginx+ nije da je skupo, samo je bilo pomalo bolno za nas i nije baš u redu. “Sticks Sessions”, na primjer, nisu radile za nas iz jednostavnog razloga što “Sticks Sessions” ne dozvoljavaju rutiranje na osnovu “Ili-ili”. Tamo možete odrediti šta radimo "Sticks Sessions", na primjer, putem IP adrese ili IP adrese i kolačića ili postparametra, ali "Ili-ili" je tu složenije.

  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 posljednjih skripti. Možete napisati posljednju skriptu, dati joj "otvoreni odmor", a ova zadnja skripta će se izvršiti kada dođe korisnički zahtjev.

  I napisali smo, u stvari, takvu skriptu, postavili sebi “openresti” i u ovoj skripti sortiramo 6 različitih parametara konkatenacijom “Ili”. Ovisno o prisutnosti jednog ili drugog parametra, znamo da je korisnik došao na jednu ili drugu stranicu, na ovaj ili onaj red.

  Plavo/zeleno postavljanje. Prednosti i nedostaci

  Naravno, vjerovatno je bilo moguće to učiniti 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 platni sistemi takođe stupaju u interakciju s nama: nakon što obradimo transakciju (slanjem zahtjeva platnom sistemu), dobijamo povrat.
  I recimo, ako unutar našeg kola možemo proslijediti IP adresu korisnika u svim zahtjevima i podijeliti korisnike na osnovu IP adrese, onda nećemo reći istu „Vizu“: „Čovječe, mi smo takva retro kompanija, čini nam se biti međunarodni (na web stranici i u Rusiji)... Molimo da nam u dodatnom polju navedete IP adresu korisnika, vaš protokol je standardiziran”! Jasno je da se neće složiti.

  
  
  Dakle, ovo nam nije išlo - radili smo openresty. Shodno tome, sa rutiranjem smo dobili nešto ovako:

  Plavo/zeleno raspoređivanje ima, shodno tome, prednosti koje sam spomenuo i nedostatke.

  dva nedostatka:

  • morate se mučiti oko rutiranja;
  • drugi glavni nedostatak je trošak.

  Treba vam duplo više servera, duplo više operativnih resursa, morate uložiti duplo više truda da održite cijeli ovaj zoološki vrt.

  Inače, među prednostima postoji još jedna stvar koju ranije nisam spomenuo: imate rezervu u slučaju povećanja opterećenja. Ako imate eksplozivno povećanje opterećenja, imate veliki broj korisnika, onda jednostavno uključite drugi red u distribuciju 50 do 50 - i odmah imate x2 servera u svom klasteru dok ne riješite problem sa više servera.

  Kako napraviti 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 sistem (kontinuirana isporuka) - ne možete živjeti bez njega. Ako imate jedan server, možete ga instalirati ručno. Imamo oko hiljadu i po servera i hiljadu i po rukova, naravno - možemo podići odjel veličine ove sobe samo da se rasporedi.
  • Postavljanje mora biti paralelno. Ako je vaše raspoređivanje sekvencijalno, onda je sve loše. Jedan server je normalan, ceo dan ćete postavljati hiljadu i po servera.
  • Opet, za ubrzanje, ovo vjerovatno više nije potrebno. Tokom implementacije, projekat se obično gradi. Imate web projekat, postoji front-end dio (tamo radite web paket, kompajlirate npm - tako nešto), i taj proces je u principu kratkotrajan - 5 minuta, ali ovih 5 minuta može biti kritičan. Zato, na primjer, to ne radimo: uklonili smo ovih 5 minuta, mi postavljamo artefakte.

    Šta je artefakt? Artefakt je sklopljena konstrukcija u kojoj su svi montažni dijelovi već završeni. Ovaj artefakt pohranjujemo u skladište artefakata. Svojevremeno smo koristili dva takva skladišta - to je bio Nexus, a sada jFrog Artifactory.U početku smo koristili “Nexus” jer smo počeli da praktikujemo 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 bio prikladan, te smo stoga 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 servere.

  Eksplozivni rast opterećenja

  Razgovarali smo o promjeni verzije softvera. Sljedeće što imamo je eksplozivno povećanje opterećenja. Ovdje vjerovatno mislim pod eksplozivnim rastom opterećenja nije baš prava stvar...

  Napisali smo novi sistem - orijentisan je ka uslugama, moderan, lep, radnici svuda, redovi svuda, asinhron svuda. I u takvim sistemima, podaci mogu teći kroz različite tokove. Za prvu transakciju može se koristiti 1., 3., 10. radnik, za drugu transakciju - 2., 4., 5. A danas, recimo, ujutro imate tok 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 naduvavanje resursa.

  
  
  Definisali smo naše zahtjeve. Ovi zahtjevi su prilično jednostavni: da postoji otkrivanje servisa, parametrizacija - sve je standardno za izgradnju takvih skalabilnih sistema, osim jedne tačke - amortizacije resursa. Rekli smo da nismo spremni da amortizujemo resurse da bi serveri zagrevali vazduh. Uzeli smo "Consul", uzeli smo "Nomad", koji upravlja našim radnicima.

  Zašto je ovo problem za nas? Vratimo se malo unazad. Sada imamo oko 70 platnih sistema iza sebe. Ujutro promet ide preko Sberbanke, onda je Sberbanka pala, na primjer, pa je prebacimo na drugi sistem plaćanja. Imali smo 100 radnika prije Sberbanke, a nakon toga moramo naglo povećati 100 radnika za drugi sistem plaćanja. I poželjno je da se sve to dešava bez ljudskog učešća. Jer ako postoji ljudsko učešće, tamo bi trebao sjediti inženjer 24/7, koji bi trebao samo ovo da radi, jer se takvi kvarovi, kada je 70 sistema iza vas, dešavaju redovno.

  Stoga smo pogledali Nomad, koji ima otvoren IP, i napisali svoju stvar, Scale-Nomad - ScaleNo, koja radi otprilike sljedeće: prati rast reda i smanjuje ili povećava broj radnika ovisno o dinamici iz reda. Kada smo to uradili, pomislili smo: „Možda možemo da otvorimo kod?“ Onda su je pogledali - bila je jednostavna kao dvije kopejke.

  Do sada nismo otvorili izvorni kod, ali ako odjednom nakon izvještaja, nakon što shvatite da vam tako nešto treba, zatreba vam, moji kontakti su na zadnjem slajdu - molim vas pišite mi. Ako bude bar 3-5 ljudi, mi ćemo to sponzorisati.

  
  
  Kako radi? Hajde da pogledamo! Gledajući unaprijed: na lijevoj strani je dio našeg monitoringa: ovo je jedan red, na vrhu je vrijeme obrade događaja, u sredini je broj transakcija, dolje je broj radnika.

  Ako pogledate, na ovoj slici postoji greška. Na vrhu ljestvice, jedna od ljestvica se srušila za 45 sekundi - jedan od platnih sistema je pao. Odmah je promet doveden za 2 minute i red je počeo da raste na drugom sistemu plaćanja, gdje nije bilo radnika (nismo koristili resurse - naprotiv, ispravno smo raspolagali resursom). Nismo hteli da se grejemo - bilo je minimalno, oko 5-10 radnika, ali nisu mogli da izdrže.

  Posljednji grafikon prikazuje “grbu”, što samo znači da je “Skaleno” udvostručio ovaj iznos. A onda, kada je graf malo pao, malo ga je smanjio - automatski se menjao broj radnika. Tako ova stvar radi. Razgovarali smo o tački broj 2 - "Kako se brzo riješiti razloga."

  Monitoring. Kako brzo prepoznati problem?

  Sada je prva tačka "Kako brzo prepoznati problem?" Monitoring! Moramo brzo shvatiti određene stvari. Koje stvari treba da shvatimo brzo?

  
  
  Tri stvari!

  • Moramo brzo razumjeti i razumjeti učinak naših vlastitih resursa.
  • Moramo brzo razumjeti kvarove i pratiti performanse sistema koji su nam vanjski.
  • Treća tačka je identifikacija logičkih grešaka. Ovo je kada sistem radi za vas, sve je normalno po svim pokazateljima, ali nešto krene po zlu.

  Vjerovatno vam ovdje neću reći ništa tako kul. Ja ću biti kapetan Obvious. Tražili smo šta ima na tržištu. Imamo “zabavni zoološki vrt”. Ovakav zoološki vrt imamo sada:

  
  
  Zabbix koristimo za praćenje hardvera, za praćenje glavnih indikatora servera. Koristimo Okmeter za baze podataka. Za sve ostale indikatore koji se ne uklapaju u prva dva koristimo „Grafana“ i „Prometej“, neki kod „Grafana“ i „Prometej“, a neki od „Grafana“ uz „Influx“ i Telegraf.

  Prije godinu dana htjeli smo koristiti New Relic. Super stvar, može sve. Ali koliko god može sve, toliko je skupa. Kada smo narasli na obim od 1,5 hiljada servera, došao nam je prodavac i rekao: "Da zaključimo ugovor za sledeću godinu." Pogledali smo cijenu i rekli ne, nećemo to učiniti. Sada napuštamo New Relic, ostalo nam je oko 15 servera pod nadzorom New Relic-a. Ispostavilo se da je cijena apsolutno divlja.

  I postoji jedan alat koji smo sami implementirali - ovo je Debugger. U početku smo ga nazvali „Bagger“, ali onda je prošao profesor engleskog, divlje se nasmijao i preimenovao ga u „Debagger“. Šta je to? Ovo je alat koji, u stvari, za 15-30 sekundi na svakoj komponenti, poput “crne kutije” sistema, pokreće testove ukupnih performansi komponente.

  Na primjer, ako postoji vanjska stranica (stranica za plaćanje), on je jednostavno otvori i pogleda kako bi trebala izgledati. Ako se ovo obrađuje, on šalje probnu "transakciju" i osigurava da ova "transakcija" stigne. Ako se radi o vezi sa platnim sistemima, u skladu sa tim pokrećemo testni zahtev, gde možemo i vidimo da je kod nas sve u redu.

  Koji su indikatori važni za praćenje?

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

  
  

  • Vrijeme odziva / RPS na frontovima je vrlo važan pokazatelj. On odmah odgovara da nešto nije u redu sa vama.
  • Broj obrađenih poruka u svim redovima.
  • Broj radnika.
  • Osnovne metrike ispravnosti.

  Posljednja tačka je „biznis“, „biznis“ metrika. Ako želite pratiti istu stvar, morate definirati jednu ili dvije metrike koje su za vas glavni indikatori. Naša metrika je propusnost (ovo je omjer broja uspješnih transakcija i ukupnog protoka transakcija). Ako se nešto u njemu promijeni u intervalu od 5-10-15 minuta, to znači da imamo problema (ako se promijeni radikalno).

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

  
  
  Na lijevoj strani je 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 „poslovnoj“ metrici odmah vidimo da je nešto pošlo po zlu na dva srednja grafikona... Ovo je samo još jedan sistem koji stoji iza nas koji je pao.

  Druga stvar koju smo morali da uradimo je da pratimo pad eksternih platnih sistema. Ovde smo uzeli OpenTracing – mehanizam, standard, paradigmu koja vam omogućava da pratite distribuirane sisteme; i malo je promenjeno. Standardna OpenTracing paradigma kaže da gradimo praćenje za svaki pojedinačni zahtjev. Ovo nam nije trebalo i umotali smo ga u sažetak, agregacijski trag. Napravili smo alat koji nam omogućava da pratimo brzinu sistema iza nas.

  
  
  Grafikon nam pokazuje da je jedan od platnih sistema počeo da odgovara za 3 sekunde - imamo problema. Štaviše, ova stvar će reagovati kada počnu problemi, u intervalu od 20-30 sekundi.

  I treća klasa grešaka u praćenju koja postoji je logičko praćenje.

  Da budem iskren, nisam znao šta 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.

  
  
  Šta mislim pod logičkim praćenjem? Pa, zamislite: sami napravite sistem (na primjer, Tinder klon); ti si ga napravio, lansirao ga. Uspješni menadžer Vasja Pupkin stavio je to na svoj telefon, tamo vidi djevojku, sviđa joj se... i slično ne ide djevojci - lajk ide čuvaru Mihalychu iz istog poslovnog centra. Menadžer silazi dole, a onda se pita: „Zašto mu se taj čuvar Mihalič tako prijatno osmehuje?“

  U takvim situacijama... Nama ova situacija zvuči malo drugačije, jer (pisao sam) ovo je reputacijski gubitak koji indirektno dovodi do finansijskih gubitaka. Naša situacija je suprotna: možemo pretrpjeti direktne finansijske gubitke – na primjer, ako smo transakciju obavili kao uspješnu, ali je bila neuspješna (ili obrnuto). Morao sam da napišem sopstveni alat koji prati broj uspešnih transakcija tokom vremena koristeći poslovne indikatore. 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.

  Radilo se o tome kako brzo prepoznati problem.

  Kako utvrditi razloge za raspoređivanje

  Treća grupa problema koju rješavamo je nakon što smo identificirali problem, nakon što smo ga se riješili, bilo bi dobro razumjeti razlog razvoja, testiranja i učiniti nešto po tom pitanju. Shodno tome, treba da istražimo, treba da podignemo balvane.

  
  
  Ako govorimo o logovima (glavni razlog su trupci), većina naših dnevnika je u ELK Stack-u - skoro svi imaju iste. Za neke možda nije u ELK-u, ali ako pišete logove u gigabajtima, prije ili kasnije ćete doći do ELK-a. Zapisujemo ih u terabajtima.

  
  
  Tu je problem. Popravili smo to, ispravili grešku za korisnika, počeli da kopamo šta ima, popeli se u Kibanu, uneli tamo ID transakcije i dobili ovakvu krpu za noge (pokazuje dosta). 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 trenutku smo shvatili da nam je potrebno praćenje - isti OpenTracing o kojem sam govorio.

  Mislili smo to prije godinu dana, skrenuli pažnju na tržište, a tu su bila dva alata – “Zipkin” i “Jaeger”. “Jager” je zapravo takav ideološki naslednik, ideološki naslednik “Zipkina”. Sve je dobro u Zipkinu, osim što ne zna da agregira, ne zna da uključi logove 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-u (Api standard za PHP u to vrijeme, međutim, nije odobren - to je bilo prije godinu dana, ali sada je već odobren), ali postoji nije bio nikakav klijent. „U redu“, pomislili smo i napisali sopstvenom klijentu. Šta smo dobili? Ovako otprilike izgleda:

  
  
  U Jaegeru, rasponi se kreiraju za svaku poruku. Odnosno, kada korisnik otvori sistem, 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 zapise i vremenske tragove. Shodno tome, u slučaju greške, naša aplikacija će označiti dnevnik odgovarajućom oznakom Error. Možete filtrirati prema oznaci Error i samo će rasponi koji sadrže ovaj blok s greškom biti prikazani. Ovako to izgleda ako proširimo raspon:

  
  
  Unutar raspona nalazi se skup tragova. U ovom slučaju, ovo su tri testna traga, a treći trag nam govori da je došlo do greške. Istovremeno, ovde vidimo vremenski trag: imamo vremensku skalu na vrhu i vidimo u kom vremenskom intervalu je zabeležen ovaj ili onaj dnevnik.

  Shodno tome, stvari su nam išle dobro. Napisali smo vlastitu ekstenziju i otvorili je kod. Ako želite da radite sa praćenjem, ako želite da radite sa "Jagerom" u PHP-u, postoji naša ekstenzija, dobrodošla da koristite, kako kažu:

  
  
  Imamo ovo proširenje - to je klijent za OpenTracing Api, napravljeno je kao php-extention, odnosno moraćete da ga sastavite i instalirate na sistem. Prije godinu dana nije bilo ništa drugačije. Sada postoje i drugi klijenti koji su kao komponente. Ovdje je na vama: ili ćete ispumpati komponente pomoću kompozitora ili ćete koristiti proširenje prema vama.

  Korporativni standardi

  Razgovarali smo o tri zapovesti. Četvrta zapovest je standardizacija pristupa. o čemu se radi? radi se o ovome:

  
  
  Zašto je ovdje riječ “korporacija”? Ne zato što smo velika ili birokratska kompanija, ne! Želio sam ovdje upotrijebiti riječ “korporacija” u kontekstu da svaka kompanija, svaki proizvod treba da ima svoje standarde, uključujući i vas. Koje standarde imamo?

  
  

  • Imamo propise o raspoređivanju. Ne krećemo se nikuda bez njega, ne možemo. Raspoređujemo se oko 60 puta sedmično, odnosno raspoređujemo se gotovo konstantno. Istovremeno, imamo, na primjer, u pravilniku o raspoređivanju tabu na raspoređivanje u petak - u principu, ne raspoređujemo.
  • Potrebna nam je dokumentacija. Niti jedna nova komponenta ne ulazi u proizvodnju ako za nju nema dokumentacije, čak i ako je rođena pod perom naših RnD stručnjaka. Od njih tražimo instrukcije za implementaciju, mapu praćenja i grubi opis (pa, kako programeri mogu da napišu) kako ova komponenta radi, kako je riješiti.
  • Ne rješavamo uzrok problema, već problem - ono što sam već rekao. Važno nam je zaštititi korisnika od problema.
  • Imamo odobrenja. Na primjer, ne smatramo zastojem ako smo izgubili 2% prometa u roku od dvije minute. Ovo u osnovi nije uključeno u našu statistiku. Ako je više u procentima ili privremeno, već računamo.
  • I mi uvijek pišemo obdukcije. Šta god da nam se dogodi, svaka situacija u kojoj se neko nenormalno ponašao u proizvodnji će se odraziti na obdukciju. Obdukcija je dokument u koji pišete šta vam se dogodilo, detaljan tajming, šta ste uradili da to ispravite i (ovo je obavezan blok!) šta ćete učiniti da se to ne dešava u budućnosti. Ovo je obavezno i ​​neophodno za naknadnu analizu.

  Šta se smatra prekidom rada?

  
  
  Do čega je sve ovo dovelo?

  To je dovelo do toga da (imali smo određenih problema sa stabilnošću, to nije odgovaralo ni klijentima ni nama) u proteklih 6 mjeseci naš pokazatelj stabilnosti iznosi 99,97. Možemo reći da to nije mnogo. Da, imamo čemu da težimo. Od ovog pokazatelja, otprilike polovina je stabilnost, takoreći, ne naše, već vatrozida naše web aplikacije, koji stoji ispred nas i koristi se kao servis, ali klijenti o tome ne mare.

  Naučili smo da spavamo noću. Konačno! Prije šest mjeseci nismo mogli. I na ovoj belešci sa rezultatima, želeo bih da napravim jednu belešku. Sinoć je bio divan izvještaj o sistemu upravljanja nuklearnim reaktorom. Ako ljudi koji su napisali ovaj sistem mogu da me čuju, molim vas, zaboravite na ono što sam rekao o „2% nije prekid rada“. Za vas je 2% zastoja, čak i na dvije minute!

  To je sve! Vaša pitanja.

  
  

  O balanserima i migraciji baze podataka

  Pitanje iz publike (u daljem tekstu – B): – Dobro veče. Hvala vam puno na ovakvom izvještaju administratora! Kratko pitanje o vašim balanserima. Spomenuli ste da imate WAF, odnosno, koliko sam ja shvatio, koristite neku vrstu eksternog balansera...

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

  AT: – Možete li reći nekoliko riječi o balansima?

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

  AT: – Takođe jednostavno pitanje. Ovdje je Plavo/Zeleno raspoređivanje. Šta radite, na primjer, s migracijama baze podataka?

  EK: - Dobro pitanje! Gledajte, u Blue/Green implementaciji imamo odvojene 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, sve praktički prebacili u redove, u bazi podataka pohranjujemo samo hrpu transakcija. I naš stek transakcija je isti za sve linije. Sa 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 trebalo bi da dobijem nagradu za najbolje pitanje.

  AT: - Zdravo. Hvala na izvještaju. Pitanje je ovo. Pratiš plaćanja, pratiš servise sa kojima komuniciraš... Ali kako da pratiš da je neko na neki način došao na tvoju stranicu za plaćanje, izvršio uplatu, a projekat mu kreditirao novac? Odnosno, kako nadgledate da je trgovac dostupan i da li je prihvatio vaš povratni poziv?

  EK: – „Trgovac“ je za nas u ovom slučaju potpuno isti eksterni servis kao i platni sistem. Pratimo brzinu odgovora trgovca.

  O šifriranju baze podataka

  AT: - Zdravo. Imam malo povezano pitanje. Imate PCI DSS osjetljive podatke. Želio sam znati kako pohranjujete PAN-ove u redovima u koje trebate prenijeti? Koristite li neku enkripciju? I to dovodi do drugog pitanja: prema PCI DSS-u, potrebno je periodično ponovo šifrirati bazu podataka u slučaju promjena (otpuštanje administratora, itd.) - šta se dešava sa pristupačnošću u ovom slučaju?

  
  
  EK: - Divno pitanje! Prvo, mi ne pohranjujemo PAN-ove u redovima. U principu nemamo pravo pohranjivati ​​PAN nigdje u jasnom obliku, pa koristimo posebnu uslugu (zovemo je “Kademon”) - ovo je usluga koja radi samo jednu stvar: prima poruku kao ulaz i šalje poslati šifrovanu poruku. I sve pohranjujemo sa ovom šifrovanom porukom. Shodno tome, dužina našeg ključa je ispod kilobajta, tako da je ovo ozbiljno i pouzdano.

  AT: – Treba li vam sada 2 kilobajta?

  EK: – Čini se da je juče bilo 256... Pa, gde još?!

  Shodno tome, ovo je prvi. I drugo, rješenje koje postoji, podržava proceduru ponovnog šifriranja - postoje dva para "keksa" (ključeva), koji daju "dekove" koji šifriraju (ključ su ključevi, dek su derivati ​​ključeva koji šifriraju) . A ako je postupak pokrenut (to se dešava redovno, od 3 mjeseca do ± nekoliko), preuzimamo novi par „kolača“ i ponovo šifriramo podatke. Imamo odvojene servise koji izvlače sve podatke i šifriraju ih na nov način; Podaci se pohranjuju pored identifikatora ključa kojim su šifrirani. Shodno tome, čim šifriramo podatke novim ključevima, brišemo stari ključ.

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

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

  EK: - Da.

  AT: – 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.

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

  EK: – Ne, pa, naravno, imamo neku vrstu back-office sistema koji sadrži interfejs za našu podršku. Ako ne znamo u kojem je statusu transakcija (na primjer, dok platni sistem nije odgovorio timeoutom), ne znamo a priori, odnosno konačni status dodjeljujemo samo s punim povjerenjem. U tom slučaju transakciji dodjeljujemo poseban status za ručnu obradu. Ujutro, sutradan, čim podrška dobije informaciju da takve i takve transakcije ostaju u platnom sistemu, oni ih ručno obrađuju u ovom interfejsu.

  
  
  AT: – Imam par pitanja. Jedan od njih je nastavak PCI DSS zone: kako evidentirate njihovo kolo? Ovo pitanje je zato što je programer mogao staviti bilo šta u evidenciju! Drugo pitanje: kako uvodite hitne popravke? Korištenje ručki u bazi podataka je jedna od opcija, ali možda postoje besplatni hitni popravci - koja je procedura tamo? I treće pitanje je vjerovatno vezano za RTO, RPO. Vaša dostupnost je bila 99,97, skoro četiri devetke, ali koliko sam shvatio, imate drugi data centar, treći data centar i peti data centar... Kako ih sinhronizujete, replicirate i sve ostalo?

  EK: - Počnimo s prvim. Je li prvo pitanje bilo o trupcima? Kada pišemo dnevnike, imamo sloj koji maskira sve osjetljive podatke. Ona gleda u masku i dodatna polja. U skladu s tim, naši dnevnici izlaze s već maskiranim podacima i PCI DSS krugom. Ovo je jedan od redovnih zadataka koji se dodjeljuju odjelu za testiranje. Od njih se traži da provjere svaki zadatak, uključujući i logove koje pišu, a to je jedan od redovnih zadataka prilikom pregleda koda, kako bi se kontroliralo da programer nije nešto zapisao. Naknadne provjere ovoga odjela za informatičku sigurnost obavlja redovno otprilike jednom sedmično: selektivno se uzimaju dnevnici za posljednji dan i propuštaju se kroz poseban skener-analizator sa test servera kako bi se sve provjerilo.
  O hitnim popravkama. Ovo je uključeno u naše propise o raspoređivanju. Imamo posebnu klauzulu o hitnim popravkama. Vjerujemo da implementiramo hitne ispravke XNUMX sata dnevno kada nam zatrebaju. Čim se verzija sklopi, čim se pokrene, čim imamo artefakt, imamo dežurnog sistem administratora na poziv podrške, koji ga postavlja u trenutku kada je to potrebno.

  Oko "četiri devetke". Cifra koju sada imamo je zaista postignuta, a tome smo težili u drugom data centru. Sada imamo drugi podatkovni centar i počinjemo rutirati između njih, a pitanje replikacije više podatkovnih centara je zaista netrivijalno pitanje. Pokušali smo to u jednom trenutku riješiti različitim sredstvima: pokušali smo koristiti istu "Tarantulu" - nije nam išlo, odmah ću vam reći. Zbog toga smo na kraju naručili "sens" ručno. Zapravo, svaka aplikacija u našem sistemu asinhrono pokreće neophodnu sinhronizaciju „promena – urađeno“ između centara podataka.

  AT: – Ako ste dobili drugu, zašto niste dobili treću? Jer niko još nema podeljeni mozak...

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

  AT: - Dobro veče. Hvala na izvještaju. Govorili ste o svom debugeru, koji pokreće neke testne transakcije u proizvodnji. Ali recite nam o probnim transakcijama! Koliko duboko ide?

  EK: – Prolazi kroz puni ciklus cijele komponente. Za komponentu, nema razlike između testne transakcije i proizvodne transakcije. Ali sa logične tačke gledišta, ovo je jednostavno poseban projekat u sistemu, na kojem se pokreću samo probne transakcije.

  AT: -Gde to odsečeš? Evo Core poslao...

  EK: – Mi smo iza „Kora“ u ovom slučaju za probne transakcije... Imamo nešto poput rutiranja: „Kor“ zna na koji platni sistem da pošalje – šaljemo lažnom platnom sistemu, koji jednostavno daje http signal i to je sve.

  AT: – Recite mi, molim vas, da li je vaša aplikacija napisana u jednom ogromnom monolitu, ili ste je urezali u neke servise ili čak mikroservise?

  EK: – Nemamo monolit, naravno, imamo servisno orijentisanu aplikaciju. Šalimo se da je naš servis napravljen od monolita - oni su zaista prilično veliki. Teško je to nazvati mikroservisima, ali to su servisi u okviru kojih rade radnici distribuiranih mašina.

  Ako je usluga na serveru ugrožena...

  AT: – Onda imam sledeće pitanje. Čak i da je monolit, ipak ste rekli da imate mnogo ovih instant servera, svi oni u osnovi obrađuju podatke, a pitanje je: „U slučaju kompromitacije jednog od instant servera ili aplikacije, bilo koja pojedinačna veza , imaju li neku vrstu kontrole pristupa? Ko od njih šta može? Kome da se obratim za koje informacije?

  
  
  EK: - Da, definitivno. Sigurnosni zahtjevi su prilično ozbiljni. Prvo, imamo otvorene pokrete podataka, a portovi su samo oni preko kojih unaprijed predviđamo kretanje prometa. Ako komponenta komunicira sa bazom podataka (recimo, sa Muskulom) putem 5-4-3-2, samo 5-4-3-2 će joj 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. A čak i da je aplikacija na neki način ugrožena, ne daj Bože, napadač neće moći pristupiti konzoli za upravljanje serverom, jer je ovo druga sigurnosna zona mreže.

  AT: – I u ovom kontekstu, meni je interesantnije da imate određene ugovore sa službama – šta oni mogu da urade, preko kojih „akcija“ mogu da kontaktiraju jedni s drugima... A u normalnom toku neke specifične službe zahtevaju neke red, spisak „akcija“ na drugom. Čini se da se u normalnoj situaciji ne okreću drugima, a imaju i druga područja odgovornosti. Ako jedan od njih bude kompromitovan, da li će moći da poremeti „radnje“ te službe?..

  EK: - Razumijem. Ako je u normalnoj situaciji s drugim serverom komunikacija uopće bila dopuštena, onda da. Prema SLA ugovoru, ne pratimo da su vam dozvoljene samo prve 3 “radnje”, a da vam nisu dozvoljene 4 “radnje”. Ovo nam je vjerovatno suvišno, jer već imamo 4-stepeni sistem zaštite, u principu, za kola. Radije se branimo konturama, a ne na nivou unutrašnjosti.

  Kako rade Visa, MasterCard i Sberbank

  AT: – Želim da razjasnim nešto o prebacivanju korisnika iz jednog data centra u drugi. Koliko ja znam, Visa i MasterCard rade koristeći 8583 binarni sinhroni protokol i tu ima miksova. I hteo sam da znam, sada mislimo na prebacivanje – da li direktno „Visa“ i „MasterCard“ ili pre platnih sistema, pre obrade?

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

  AT: – Grubo rečeno, imate li jednu tačku veze?

  EK: – “Visa” i “MasterCard” - da. Jednostavno zato što Visa i MasterCard zahtijevaju prilično ozbiljna ulaganja u infrastrukturu da bi se zaključili zasebni ugovori za dobijanje drugog para miksa, na primjer. Oni su rezervisani u okviru jednog data centra, ali ako, ne daj Bože, naš data centar, gde postoje miksevi za povezivanje na Visa i MasterCard, umre, onda ćemo imati izgubljenu vezu sa Visom i MasterCardom...

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

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

  AT: – Znači štand je iz njihove Connects Orange?..

  EK: - Da.

  AT: – Ali šta je sa ovim slučajem: ako vaš data centar nestane, kako ga možete nastaviti koristiti? Ili se saobraćaj jednostavno zaustavlja?

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

  Srdačno se izvinjavam ako sam uvredio radnike Sberbanke. Ali prema našim statistikama, među ruskim bankama, Sberbank najčešće pada. Ne prođe mjesec dana a da nešto ne padne u Sberbanci.

  
  
  

  Neke reklame 🙂

  Hvala vam što ste ostali s nama. Da li vam se sviđaju naši članci? Želite li vidjeti još zanimljivih sadržaja? Podržite nas naručivanjem ili preporukom prijateljima, cloud VPS za programere od 4.99 USD, jedinstveni analog servera početnog nivoa, koji smo mi izmislili za vas: Cijela istina o VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps od 19$ ili kako dijeliti server? (dostupno sa RAID1 i RAID10, do 24 jezgra i do 40GB DDR4).

  Dell R730xd 2 puta jeftiniji u Equinix Tier IV data 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 Holandiji! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - od 99 USD! Pročitajte o Kako izgraditi infrastrukturnu kompaniju. klase uz korišćenje Dell R730xd E5-2650 v4 servera u vrednosti od 9000 evra za peni?

izvor: www.habr.com