Všetci hovoria o procesoch vývoja a testovania, školení personálu, zvyšovaní motivácie, ale tieto procesy nestačia, keď minúta výpadku služby stojí obrovské peniaze. Čo robiť, keď vykonávate finančné transakcie podľa prísnej SLA? Ako zvýšiť spoľahlivosť a odolnosť voči chybám vašich systémov, pričom vývoj a testovanie sa vylúči z rovnice?
Ďalšia konferencia HighLoad++ sa bude konať 6. a 7. apríla 2020 v Petrohrade. Podrobnosti a vstupenky na . 9. novembra, 18:00. HighLoad++ Moskva 2018, Dillí + hala Kalkata. Tézy a .
Jevgenij Kuzovlev (ďalej len EC): - Priatelia, ahojte! Volám sa Kuzovlev Evgeniy. Som zo spoločnosti EcommPay, špecifickou divíziou je EcommPay IT, IT divízia skupiny spoločností. A dnes si povieme o prestojoch – o tom, ako sa im vyhnúť, o tom, ako minimalizovať ich následky, ak sa tomu nedá vyhnúť. Téma je uvedená takto: „Čo robiť, keď minúta prestoja stojí 100 000 USD“? Pri pohľade do budúcnosti sú naše čísla porovnateľné.
Čo robí EcommPay IT?
Kto sme? Prečo tu stojím pred tebou? Prečo mám právo ti tu niečo hovoriť? A o čom si tu povieme podrobnejšie?
Skupina spoločností EcommPay je medzinárodným nadobúdateľom. Platby spracovávame po celom svete - v Rusku, Európe, juhovýchodnej Ázii (Celý svet). Máme 9 kancelárií, spolu 500 zamestnancov a približne o niečo menej ako polovicu z nich tvoria IT špecialisti. Všetko, čo robíme, na čom zarábame, sme robili sami.
Všetky naše produkty (a máme ich pomerne veľa – v našej rade veľkých IT produktov máme asi 16 rôznych komponentov) sme si napísali sami; Píšeme sami seba, rozvíjame sa. A v súčasnosti realizujeme asi milión transakcií denne (správne sa to dá povedať asi v miliónoch). Sme pomerne mladá spoločnosť – máme len asi šesť rokov.
Pred 6 rokmi to bol taký startup, keď chalani prišli spolu s biznisom. Spojila ich myšlienka (nebolo tam nič iné ako myšlienka) a my sme sa rozbehli. Ako každý startup sme bežali rýchlejšie... Rýchlosť bola pre nás dôležitejšia ako kvalita.
V určitom bode sme sa zastavili: uvedomili sme si, že už nemôžeme nejako žiť v takej rýchlosti a kvalite a musíme sa najprv zamerať na kvalitu. V tejto chvíli sme sa rozhodli napísať novú platformu, ktorá by bola správna, škálovateľná a spoľahlivá. Začali písať túto platformu (začali investovať, vyvíjať vývoj, testovať), no v istom momente si uvedomili, že vývoj a testovanie nám neumožňujú dosiahnuť novú úroveň kvality služieb.
Vyrobíte nový produkt, dáte ho do výroby, no aj tak sa niekde niečo pokazí. A dnes budeme hovoriť o tom, ako dosiahnuť novú úroveň kvality (ako sa nám to podarilo, o našich skúsenostiach), pričom vývoj a testovanie vylúčime z rovnice; budeme hovoriť o tom, čo má prevádzka k dispozícii - čo prevádzka môže robiť sama, čo môže ponúknuť testovaniu s cieľom ovplyvniť kvalitu.
Prestoje. Operačné príkazy.
Vždy hlavným základným kameňom, o čom sa dnes vlastne budeme baviť, sú prestoje. Strašné slovo. Ak máme výpadky, všetko je pre nás zlé. Bežíme to zdvihnúť, admini držia server - Bože chráň, aby nespadol, ako sa hovorí v tej piesni. O tom si dnes povieme.
Keď sme začali meniť naše prístupy, vytvorili sme 4 prikázania. Mám ich prezentované na snímkach:
Tieto prikázania sú celkom jednoduché:
- Rýchlo identifikujte problém.
- Zbavte sa toho ešte rýchlejšie.
- Pomôžte pochopiť dôvod (neskôr pre vývojárov).
- A štandardizovať prístupy.
Dávam do pozornosti bod č.2. Problém sa zbavujeme, neriešime. Rozhodovanie je druhoradé. Pre nás je prvoradé, aby bol používateľ pred týmto problémom chránený. Bude existovať v nejakom izolovanom prostredí, ale toto prostredie s ním nebude mať žiadny kontakt. Vlastne si prejdeme tieto štyri skupiny problémov (niektoré podrobnejšie, niektoré menej podrobne), poviem vám, čo používame, aké relevantné skúsenosti máme s riešeniami.
Riešenie problémov: Kedy sa vyskytujú a čo s nimi robiť?
Začneme ale mimo poradia, začneme bodom č.2 – ako sa rýchlo zbaviť problému? Vyskytol sa problém – musíme ho vyriešiť. "Čo by sme s tým mali robiť?" - hlavná otázka. A keď sme začali premýšľať o tom, ako problém vyriešiť, vyvinuli sme pre seba niekoľko požiadaviek, ktoré musí riešenie problémov spĺňať.
Aby sme sformulovali tieto požiadavky, rozhodli sme sa položiť si otázku: „Kedy máme problémy“? A problémy, ako sa ukázalo, sa vyskytujú v štyroch prípadoch:
- Porucha hardvéru.
- Externé služby zlyhali.
- Zmena verzie softvéru (rovnaké nasadenie).
- Rast výbušného zaťaženia.
Nebudeme hovoriť o prvých dvoch. Hardvérová porucha sa dá vyriešiť celkom jednoducho: musíte mať všetko duplikované. Ak ide o disky, disky musia byť zostavené v RAID; ak ide o server, server musí byť duplikovaný; ak máte sieťovú infraštruktúru, musíte dodať druhú kópiu sieťovej infraštruktúry, to znamená, že ju vezmete a duplikovať to. A ak niečo zlyhá, prepnete na záložnú energiu. Tu je ťažké povedať niečo viac.
Druhým je zlyhanie externých služieb. Pre väčšinu nie je systém vôbec problém, no pre nás nie. Keďže spracovávame platby, sme agregátor, ktorý stojí medzi používateľom (ktorý zadáva údaje o svojej karte) a bankami, platobnými systémami (Visa, MasterCard, Mira atď.). Naše externé služby (platobné systémy, banky) majú tendenciu zlyhávať. Ani my, ani vy (ak máte takéto služby) to nemôžeme ovplyvniť.
čo robiť potom? Tu sú dve možnosti. Po prvé, ak môžete, mali by ste túto službu nejakým spôsobom duplikovať. Napríklad, ak môžeme, prenášame prevádzku z jednej služby do druhej: napríklad karty boli spracované cez Sberbank, Sberbank má problémy - prenášame prevádzku [podmienečne] do Raiffeisen. Druhá vec, ktorú môžeme urobiť, je veľmi rýchlo spozorovať výpadok externých služieb, a preto si o rýchlosti odozvy povieme v ďalšej časti správy.
V skutočnosti z týchto štyroch môžeme konkrétne ovplyvniť zmenu verzií softvéru – prijať opatrenia, ktoré povedú k zlepšeniu situácie v kontexte nasadení a v kontexte explozívneho rastu záťaže. V skutočnosti sme to urobili. Ešte raz malá poznámka...
Z týchto štyroch problémov je niekoľko vyriešených okamžite, ak máte cloud. Ak ste v oblakoch Microsoft Azhur, Ozone alebo používate naše cloudy od spoločnosti Yandex alebo Mail, potom sa ich problémom stane prinajmenšom porucha hardvéru a v kontexte poruchy hardvéru sa pre vás všetko okamžite stane v poriadku.
Sme trochu netradičná spoločnosť. Tu každý hovorí o „Kubernetoch“, o oblakoch – nemáme ani „Kubernety“, ani mraky. Ale v mnohých dátových centrách máme stojany s hardvérom a sme nútení žiť na tomto hardvéri, sme nútení niesť za to všetko zodpovednosť. Preto budeme hovoriť v tejto súvislosti. Takže o problémoch. Prvé dve boli vyňaté zo zátvoriek.
Zmena verzie softvéru. Základy
Naši vývojári nemajú prístup k produkcii. prečo je to tak? Ide len o to, že máme certifikáciu PCI DSS a naši vývojári jednoducho nemajú právo dostať sa do „produktu“. To je všetko, bodka. Vôbec. Zodpovednosť za vývoj teda končí presne v momente, keď vývoj odošle zostavu na vydanie.
Naším druhým základom, ktorý máme a ktorý nám tiež veľmi pomáha, je absencia jedinečných nezdokumentovaných vedomostí. Dúfam, že je to tak aj u vás. Pretože ak to tak nie je, budete mať problémy. Problémy nastanú, keď tieto jedinečné, nezdokumentované znalosti nebudú prítomné v správnom čase na správnom mieste. Povedzme, že máte jedného človeka, ktorý vie nasadiť konkrétny komponent – ten človek tam nie je, je na dovolenke alebo je chorý – to je všetko, máte problémy.
A tretí základ, ku ktorému sme sa dostali. Prišli sme k tomu cez bolesť, krv, slzy – prišli sme na to, že každá naša zostava obsahuje chyby, aj keď je bezchybná. Rozhodli sme sa pre seba: keď niečo nasadíme, keď niečo uvedieme do výroby, máme zostavu s chybami. Vytvorili sme požiadavky, ktoré musí náš systém spĺňať.
Požiadavky na zmenu verzie softvéru
Existujú tri požiadavky:
- Musíme rýchlo vrátiť nasadenie.
- Musíme minimalizovať vplyv neúspešného nasadenia.
- A musíme byť schopní rýchlo nasadiť paralelne.
Presne v tomto poradí! prečo? Pretože v prvom rade pri nasadzovaní novej verzie nie je dôležitá rýchlosť, ale dôležité je, aby ste sa v prípade, že sa niečo pokazí, rýchlo vrátili späť a mali minimálny dopad. Ale ak máte vo výrobe sadu verzií, pri ktorých sa ukáže, že došlo k chybe (z ničoho nič nedošlo k nasadeniu, ale je tam chyba) - rýchlosť následného nasadenia je pre vás dôležitá. Čo sme urobili, aby sme splnili tieto požiadavky? Použili sme nasledujúcu metodiku:
Je to celkom známe, nikdy sme to nevymysleli - toto je nasadenie Blue/Green. Čo to je? Musíte mať kópiu pre každú skupinu serverov, na ktorých sú nainštalované vaše aplikácie. Kópia je „teplá“: nie je na nej žiadna návštevnosť, ale túto návštevnosť možno kedykoľvek odoslať do tejto kópie. Táto kópia obsahuje predchádzajúcu verziu. A v čase nasadenia kód zavediete do neaktívnej kópie. Potom prepnete časť prevádzky (alebo celú) na novú verziu. Ak teda chcete zmeniť tok premávky zo starej verzie na novú, musíte urobiť iba jednu akciu: musíte zmeniť vyvažovač v protiprúde, zmeniť smer - z jedného proti prúdu na druhý. To je veľmi pohodlné a rieši to problém rýchleho prepínania a rýchleho návratu.Tu je riešením druhej otázky minimalizácia: na novú linku, na linku s novým kódom (nech sú to napr. 2%) môžete poslať len časť svojej návštevnosti. A tieto 2% nie sú 100%! Ak ste stratili 100 % návštevnosti v dôsledku neúspešného nasadenia, je to desivé; ak ste stratili 2 % návštevnosti, je to nepríjemné, ale nie je to desivé. Okrem toho si to používatelia s najväčšou pravdepodobnosťou ani nevšimnú, pretože v niektorých prípadoch (nie vo všetkých) sa ten istý používateľ po stlačení klávesu F5 dostane do inej, fungujúcej verzie.
Nasadenie modrej/zelenej. Smerovanie
Nie všetko je však také jednoduché „Modrá/zelená nasadzovanie“... Všetky naše komponenty možno rozdeliť do troch skupín:
- toto je frontend (platobné stránky, ktoré vidia naši klienti);
- jadro spracovania;
- adaptér pre prácu s platobnými systémami (banky, MasterCard, Visa...).
A tu je nuansa - nuansa spočíva v smerovaní medzi riadkami. Ak len prepnete 100 % prevádzky, tieto problémy nemáte. Ale ak chcete zmeniť 2%, začnete klásť otázky: "Ako to urobiť?" Najjednoduchšia vec je priamočiara: môžete nastaviť Round Robin v nginx náhodným výberom a máte 2% vľavo a 98% vpravo. Ale to nie je vždy vhodné.
Napríklad v našom prípade používateľ interaguje so systémom s viac ako jednou požiadavkou. To je normálne: 2, 3, 4, 5 žiadostí – vaše systémy môžu byť rovnaké. A ak je pre vás dôležité, aby všetky požiadavky používateľa prišli na ten istý riadok, na ktorý prišla prvá požiadavka, alebo (druhý bod) všetky požiadavky používateľa po prepnutí prišli na nový riadok (mohol začať pracovať skôr s systém, pred prepnutím), - potom toto náhodné rozdelenie nie je pre vás vhodné. Potom existujú nasledujúce možnosti:
Prvá možnosť, najjednoduchšia, je založená na základných parametroch klienta (IP Hash). Máš IP a rozdeľuješ ju sprava doľava podľa IP adresy. Potom vám bude fungovať druhý prípad, ktorý som opísal, keď došlo k nasadeniu, používateľ už mohol začať pracovať s vaším systémom a od okamihu nasadenia budú všetky požiadavky smerovať na nový riadok (povedzme na ten istý).Ak vám to z nejakého dôvodu nevyhovuje a musíte posielať požiadavky na linku, kam prišla prvotná, prvotná požiadavka používateľa, tak máte dve možnosti...
Prvá možnosť: môžete si kúpiť platený nginx+. Existuje mechanizmus Sticky sessions, ktorý na základe počiatočnej požiadavky používateľa pridelí používateľovi reláciu a pripojí ju k jednému alebo druhému upstreamu. Všetky následné požiadavky používateľov počas trvania relácie budú odoslané tomu istému upstreamu, kde bola relácia odoslaná.To nám nevyhovovalo, pretože sme už mali pravidelný nginx. Prechod na nginx+ neznamená, že by bol drahý, len to bolo pre nás trochu bolestivé a nie veľmi správne. Napríklad „relácie Sticks“ nám nefungovali z jednoduchého dôvodu, že „relácie Sticks“ neumožňujú smerovanie založené na „buď-alebo“. Tam môžete špecifikovať, čo robíme „Sticks Sessions“, napríklad podľa IP adresy alebo podľa IP adresy a cookies alebo podľa postparametra, ale tam je „Buď-alebo“ zložitejšie.
Preto sme sa dostali k štvrtej možnosti. Vzali sme nginx na steroidoch (toto je openresty) - je to rovnaký nginx, ktorý navyše podporuje zahrnutie posledných skriptov. Môžete napísať posledný skript, dať mu „otvorený odpočinok“ a tento posledný skript sa spustí, keď príde požiadavka používateľa.
Napísali sme vlastne taký skript, nastavili sme si „openresti“ a v tomto skripte triedime 6 rôznych parametrov podľa zreťazenia „alebo“. V závislosti od prítomnosti jedného alebo druhého parametra vieme, že používateľ prišiel na jednu alebo druhú stránku, jeden alebo druhý riadok.
Nasadenie modrej/zelenej. Výhody a nevýhody
Samozrejme, asi by sa to dalo trochu zjednodušiť (použiť tie isté “Sticky Sessions”), ale máme aj takú nuanciu, že v rámci jedného spracovania jednej transakcie s nami nekomunikuje len používateľ... Ale aj platobné systémy s nami interagujú: Po spracovaní transakcie (zaslaním požiadavky do platobného systému) dostaneme coolback.
A povedzme, že ak v našom okruhu dokážeme preposlať IP adresu používateľa vo všetkých požiadavkách a rozdeliť používateľov na základe IP adresy, potom nepovieme to isté „Visa“: „Ty vole, my sme taká retro spoločnosť, zdá sa nám byť medzinárodný (na webovej stránke av Rusku)... Uveďte IP adresu používateľa v dodatočnom poli, váš protokol je štandardizovaný“! Je jasné, že sa nedohodnú.
Preto nám toto nefungovalo – robili sme openresty. Podľa toho sme so smerovaním dostali niečo takéto:Blue/Green Deployment má teda výhody, ktoré som spomenul, a nevýhody.
Dve nevýhody:
- musíte sa obťažovať so smerovaním;
- druhou hlavnou nevýhodou sú náklady.
Potrebujete dvakrát toľko serverov, potrebujete dvakrát toľko prevádzkových zdrojov, musíte vynaložiť dvakrát toľko úsilia na údržbu celej tejto zoo.
Mimochodom, medzi výhody patrí ešte jedna vec, ktorú som predtým nespomenul: máte rezervu pre prípad rastu záťaže. Ak máte explozívny nárast zaťaženia, máte veľký počet používateľov, potom jednoducho zahrniete druhý riadok do distribúcie 50 na 50 - a okamžite máte x2 servery vo svojom klastri, kým nevyriešite problém s ďalšími servermi.
Ako urobiť rýchle nasadenie?
Hovorili sme o tom, ako vyriešiť problém minimalizácie a rýchleho návratu, ale otázka zostáva: „Ako rýchlo nasadiť?
Tu je to krátke a jednoduché.- Musíte mať CD systém (Continuous Delivery) – bez neho nemôžete žiť. Ak máte jeden server, môžete ho nasadiť manuálne. Máme asi jeden a pol tisíc serverov a jeden a pol tisíc kľučiek, samozrejme - môžeme osadiť oddelenie veľkosti tejto miestnosti len na nasadenie.
- Nasadenie musí byť paralelné. Ak je vaše nasadenie sekvenčné, potom je všetko zlé. Jeden server je normálny, celý deň budete nasadzovať jeden a pol tisíc serverov.
- Opäť pre zrýchlenie to už asi nie je potrebné. Počas nasadenia sa projekt zvyčajne zostavuje. Máte webový projekt, je tam front-end časť (urobíte tam webový balík, zostavíte npm - niečo také) a tento proces je v princípe krátkodobý - 5 minút, ale týchto 5 minút môže byť kritický. Preto to napríklad nerobíme: odstránili sme týchto 5 minút, nasadili sme artefakty.
Čo je artefakt? Artefakt je zostavená zostava, v ktorej už boli dokončené všetky montážne časti. Tento artefakt uložíme do úložiska artefaktov. Kedysi sme používali dve takéto úložiská - bol to Nexus a teraz jFrog Artifactory. Spočiatku sme používali "Nexus", pretože sme tento prístup začali praktizovať v java aplikáciách (vyhovovalo to). Potom tam dali nejaké aplikácie napísané v PHP; a “Nexus” už nevyhovoval, a preto sme zvolili jFrog Artefactory, ktorý dokáže artefaktovať takmer všetko. Dokonca sme dospeli k tomu, že v tomto úložisku artefaktov ukladáme naše vlastné binárne balíčky, ktoré zhromažďujeme pre servery.
Rast výbušného zaťaženia
Hovorili sme o zmene verzie softvéru. Ďalšia vec, ktorú máme, je explozívny nárast zaťaženia. Tu mám asi na mysli explozívny rast záťaže nie úplne to pravé...
Napísali sme nový systém – je orientovaný na služby, módny, krásny, všade robotníci, všade rady, všade asynchrónnosť. A v takýchto systémoch môžu dáta prúdiť rôznymi tokmi. Pre prvú transakciu môže byť použitý 1., 3., 10. pracovník, pre druhú transakciu - 2., 4., 5.. A dnes, povedzme, ráno máte dátový tok, ktorý využíva prvých troch pracovníkov, a večer sa dramaticky mení a všetko využíva ďalších troch pracovníkov.
A tu sa ukazuje, že musíte nejako škálovať pracovníkov, musíte nejako škálovať svoje služby, ale zároveň zabrániť nadúvaniu zdrojov.
Definovali sme naše požiadavky. Tieto požiadavky sú celkom jednoduché: aby existovalo zisťovanie služieb, parametrizácia - všetko je štandardné pre budovanie takýchto škálovateľných systémov, s výnimkou jedného bodu - odpisovania zdrojov. Povedali sme, že nie sme pripravení amortizovať zdroje tak, aby servery ohrievali vzduch. Vzali sme „konzula“, zobrali sme „Nomáda“, ktorý riadi našich pracovníkov.Prečo je to pre nás problém? Vráťme sa trochu späť. Teraz máme za sebou okolo 70 platobných systémov. Ráno ide doprava cez Sberbank, potom padla napríklad Sberbank a prepíname ju na iný platobný styk. Pred Sberbank sme mali 100 zamestnancov a potom potrebujeme výrazne zvýšiť 100 zamestnancov pre ďalší platobný styk. A je žiaduce, aby sa to všetko dialo bez ľudskej účasti. Pretože ak je tam ľudská účasť, mal by tam 24/7 sedieť inžinier, ktorý by mal robiť iba toto, pretože takéto zlyhania, keď je za vami 70 systémov, sa stávajú pravidelne.
Pozreli sme sa preto na Nomad, ktorý má otvorenú IP a napísali sme vlastnú vec Scale-Nomad - ScaleNo, ktorá robí približne toto: sleduje rast fronty a znižuje alebo zvyšuje počet pracovníkov v závislosti od dynamiky. z radu. Keď sme to urobili, pomysleli sme si: „Možno to môžeme otvoriť ako zdroj? Potom sa na ňu pozreli – bola jednoduchá ako dve kopejky.
Zatiaľ sme to neotvorili, ale ak zrazu po správe, keď ste si uvedomili, že niečo také potrebujete, potrebujete to, moje kontakty sú na poslednej snímke - napíšte mi. Ak bude aspoň 3-5 ľudí, sponzorujeme to.
Ako to funguje? Poďme sa pozrieť! Pohľad dopredu: na ľavej strane je časť nášho monitoringu: toto je jeden riadok, hore je čas spracovania udalosti, v strede je počet transakcií, dole je počet pracovníkov.Ak sa pozriete, na tomto obrázku je chyba. Na hornom grafe sa jeden z grafov zrútil za 45 sekúnd – jeden z platobných systémov vypadol. Okamžite bola za 2 minúty privedená doprava a rad sa začal zväčšovať na inom platobnom systéme, kde neboli žiadni pracovníci (nevyužívali sme zdroje - naopak, správne sme zdroj zlikvidovali). Nechceli sme kúriť - bol tam minimálny počet, asi 5-10 robotníkov, ale nezvládli to.
Posledný graf ukazuje „hrb“, čo znamená, že „Skaleno“ zdvojnásobilo túto sumu. A potom, keď graf trochu klesol, trochu ho zmenšil – automaticky sa zmenil počet pracovníkov. Tak táto vec funguje. Hovorili sme o bode číslo 2 - "Ako sa rýchlo zbaviť dôvodov."
Monitorovanie. Ako rýchlo identifikovať problém?
Teraz je prvým bodom „Ako rýchlo identifikovať problém? Monitorovanie! Niektoré veci musíme pochopiť rýchlo. Aké veci by sme mali rýchlo pochopiť?
Tri veci!- Musíme rýchlo pochopiť a pochopiť výkon našich vlastných zdrojov.
- Musíme rýchlo pochopiť zlyhania a monitorovať výkon systémov, ktoré sú pre nás externé.
- Tretím bodom je identifikácia logických chýb. Vtedy vám systém funguje, podľa všetkých ukazovateľov je všetko v poriadku, ale niečo sa pokazí.
Asi vám tu nepoviem nič skvelé. Budem kapitán Obvious. Hľadali sme, čo je na trhu. Máme „zábavnú zoo“. Toto je druh zoologickej záhrady, ktorú teraz máme:
Zabbix používame na monitorovanie hardvéru, na sledovanie hlavných indikátorov serverov. Pre databázy používame Okmeter. Používame „Grafana“ a „Prometheus“ pre všetky ostatné ukazovatele, ktoré nezodpovedajú prvým dvom, niektoré s „Grafana“ a „Prometheus“ a niektoré s „Grafana“ s „Influx“ a Telegraf.Pred rokom sme chceli použiť New Relic. Super vec, dokáže všetko. Ale ako môže všetko, je taká drahá. Keď sme narástli na objem 1,5 tisíc serverov, prišiel za nami predajca a povedal: „Uzavrime zmluvu na budúci rok.“ Pozreli sme sa na cenu a povedali sme nie, to neurobíme. Teraz opúšťame New Relic, máme asi 15 serverov pod dohľadom New Relic. Cena sa ukázala byť úplne divoká.
A je tu jeden nástroj, ktorý sme sami implementovali – toto je Debugger. Najprv sme to volali „Bagger“, ale potom okolo prešiel učiteľ angličtiny, divoko sa zasmial a premenoval to na „Debagger“. Čo to je? Toto je nástroj, ktorý v skutočnosti za 15-30 sekúnd na každom komponente, ako „čierna skrinka“ systému, spustí testy celkového výkonu komponentu.
Napríklad, ak existuje externá stránka (platobná stránka), jednoducho ju otvorí a pozrie sa, ako by mala vyzerať. Ak sa toto spracováva, odošle testovaciu „transakciu“ a uistí sa, že táto „transakcia“ príde. Ak ide o spojenie s platobnými systémami, podľa toho spustíme testovaciu požiadavku, kde môžeme, a uvidíme, že je u nás všetko v poriadku.
Aké ukazovatele sú dôležité pre monitorovanie?
Čo hlavne sledujeme? Aké ukazovatele sú pre nás dôležité?
- Čas odozvy / RPS na frontoch je veľmi dôležitým ukazovateľom. Hneď odpovedá, že s vami niečo nie je v poriadku.
- Počet spracovaných správ vo všetkých frontoch.
- Počet pracovníkov.
- Základné metriky správnosti.
Posledným bodom je metrika „obchod“, „obchod“. Ak chcete sledovať to isté, musíte si definovať jednu alebo dve metriky, ktoré sú pre vás hlavnými ukazovateľmi. Našou metrikou je priepustnosť (to je pomer počtu úspešných transakcií k celkovému toku transakcií). Ak sa v ňom niečo zmení v intervale 5-10-15 minút, znamená to, že máme problémy (ak sa to radikálne zmení).
Ako to u nás vyzerá, je príklad jednej z našich dosiek:
Na ľavej strane je 6 grafov, je to podľa riadkov - počet pracovníkov a počet správ vo frontoch. Na pravej strane - RPS, RTS. Nižšie je uvedená rovnaká „obchodná“ metrika. A v „obchodnej“ metrike okamžite vidíme, že sa v dvoch stredných grafoch niečo pokazilo... Toto je len ďalší systém, ktorý za nami stojí a padol.Druhá vec, ktorú sme museli urobiť, bolo sledovať pád externých platobných systémov. Tu sme vzali OpenTracing - mechanizmus, štandard, paradigma, ktorá vám umožňuje sledovať distribuované systémy; a trochu sa to zmenilo. Štandardná paradigma OpenTracing hovorí, že vytvárame sledovanie pre každú jednotlivú požiadavku. Nepotrebovali sme to a zabalili sme to do súhrnného, agregačného sledovania. Vytvorili sme nástroj, ktorý nám umožňuje sledovať rýchlosť systémov za nami.
Graf nám ukazuje, že jeden z platobných systémov začal reagovať do 3 sekúnd – máme problémy. Navyše táto vec bude reagovať, keď začnú problémy, v intervale 20-30 sekúnd.A treťou triedou monitorovacích chýb, ktoré existujú, je logické monitorovanie.
Aby som bol úprimný, nevedel som, čo na túto snímku nakresliť, pretože sme dlho hľadali na trhu niečo, čo by nám vyhovovalo. Nič sme nenašli, tak sme to museli urobiť sami.
Čo myslím pod logickým sledovaním? No predstavte si: urobíte si systém (napríklad klon Tinder); urobili ste to, spustili ste to. Úspešný manažér Vasya Pupkin si to dal do telefónu, vidí tam dievča, páči sa mu... a to isté sa dievčaťu netýka - to isté dostane ochrankár Mikhalych z toho istého obchodného centra. Manažér ide dole a potom sa pýta: "Prečo sa naňho tento ochrankár Mikhalych tak príjemne usmieva?"V takýchto situáciách... U nás táto situácia vyznieva trochu inak, pretože (písal som) ide o reputačné straty, ktoré nepriamo vedú k finančným stratám. Naša situácia je opačná: môžeme utrpieť priame finančné straty – napríklad ak sme transakciu zrealizovali ako úspešnú, no bola neúspešná (alebo naopak). Musel som napísať vlastný nástroj, ktorý sleduje počet úspešných transakcií v priebehu času pomocou obchodných ukazovateľov. Na trhu som nič nenašiel! Presne túto myšlienku som chcel vyjadriť. Na trhu nie je nič, čo by tento druh problému vyriešilo.
Išlo o to, ako rýchlo identifikovať problém.
Ako určiť dôvody nasadenia
Tretia skupina problémov, ktoré riešime, je potom, čo sme problém identifikovali, potom, čo sme sa ho zbavili, bolo by dobré pochopiť dôvod vývoja, testovania a niečo s tým urobiť. V súlade s tým musíme vyšetriť, musíme zdvihnúť protokoly.
Ak hovoríme o protokoloch (hlavným dôvodom sú protokoly), väčšina našich protokolov je v ELK Stack - takmer každý má rovnaký. Pre niekoho to možno nie je v ELK, ale ak píšete logy v gigabajtoch, tak skôr či neskôr prídete na ELK. Zapisujeme ich v terabajtoch.
Tu je problém. Opravili sme to, opravili chybu pre používateľa, začali sme vyhrabávať, čo tam bolo, vliezli sme do Kibana, zadali sme tam ID transakcie a dostali sme takúto handričku (veľa ukazuje). A v tejto obrúčke nie je nič jasné. prečo? Áno, pretože nie je jasné, ktorá časť patrí ktorému pracovníkovi, ktorá časť patrí ktorej zložke. A v tom momente sme si uvedomili, že potrebujeme sledovanie – to isté OpenTracing, o ktorom som hovoril.Mysleli sme si to pred rokom, obrátili sme našu pozornosť na trh a boli tam dva nástroje - „Zipkin“ a „Jaeger“. „Jager“ je v skutočnosti takým ideologickým dedičom, ideovým nástupcom „Zipkina“. V Zipkine je všetko dobré, až na to, že nevie agregovať, nevie do sledovania zahrnúť protokoly, iba časovú stopu. A „Jager“ to podporil.
Pozreli sme sa na „Jager“: môžete inštruovať aplikácie, môžete písať v Api (v tom čase však štandard Api pre PHP nebol schválený - bolo to pred rokom, ale teraz je už schválený), ale existuje nebol absolútne žiadny klient. "Dobre," pomysleli sme si a napísali nášho vlastného klienta. čo sme dostali? Takto to vyzerá zhruba:
V Jaeger sa pre každú správu vytvárajú rozpätia. To znamená, že keď používateľ otvorí systém, vidí jeden alebo dva bloky pre každú prichádzajúcu požiadavku (1-2-3 - počet prichádzajúcich požiadaviek od používateľa, počet blokov). Aby sme to používateľom uľahčili, pridali sme do denníkov a časových stôp značky. Preto v prípade chyby naša aplikácia označí protokol príslušným štítkom Error. Môžete filtrovať podľa značky Error a zobrazia sa iba rozsahy, ktoré obsahujú tento blok s chybou. Takto to vyzerá, ak rozpätie rozšírime:
Vo vnútri rozpätia je súbor stôp. V tomto prípade ide o tri testovacie stopy a tretie sledovanie nám hovorí, že sa vyskytla chyba. Zároveň tu vidíme časovú stopu: hore máme časovú škálu a vidíme, v akom časovom intervale bol zaznamenaný ten či onen log.Podľa toho nám to išlo dobre. Napísali sme vlastné rozšírenie a vytvorili sme ho s otvoreným zdrojom. Ak chcete pracovať so sledovaním, ak chcete pracovať s „Jager“ v PHP, je tu naše rozšírenie, vitajte na použitie, ako sa hovorí:
Máme toto rozšírenie - je to klient pre OpenTracing Api, je vyrobený ako rozšírenie php, to znamená, že ho budete musieť zostaviť a nainštalovať do systému. Pred rokom nebolo nič iné. Teraz existujú ďalší klienti, ktorí sú ako komponenty. Tu je to na vás: buď napumpujete komponenty pomocou skladateľa, alebo použijete rozšírenie podľa vás.Firemné štandardy
Hovorili sme o troch prikázaniach. Štvrtým prikázaním je štandardizovať prístupy. O čom to je? Ide o toto:
Prečo je tu slovo „firemný“? Nie preto, že sme veľká alebo byrokratická spoločnosť, to nie! Chcel som tu použiť slovo „firemný“ v kontexte, že každá spoločnosť, každý produkt by mal mať svoje vlastné štandardy, vrátane vás. Aké máme štandardy?
- Máme pravidlá nasadenia. Bez neho sa nikam nepohneme, nemôžeme. Týždenne nasadzujeme asi 60-krát, čiže nasadzujeme takmer neustále. Zároveň máme napríklad v nasadzovacích predpisoch tabu nasadzovanie v piatok – zásadne nenasadzujeme.
- Vyžadujeme dokumentáciu. Ani jeden nový komponent sa nedostane do výroby, ak k nemu neexistuje dokumentácia, aj keby sa zrodil pod perom našich RnD špecialistov. Vyžadujeme od nich pokyny na nasadenie, mapu monitorovania a približný popis (no dobre, ako vedia napísať programátori), ako tento komponent funguje, ako ho riešiť.
- Neriešime príčinu problému, ale problém - to, čo som už povedal. Je pre nás dôležité chrániť používateľa pred problémami.
- Máme povolenia. Za výpadok nepovažujeme napríklad to, ak do dvoch minút stratíme 2 % návštevnosti. Toto v podstate nie je zahrnuté v našich štatistikách. Ak je to viac v percentuálnom vyjadrení alebo dočasné, už počítame.
- A vždy píšeme posmrtne. Nech sa nám stane čokoľvek, každá situácia, keď sa niekto pri výrobe správal neštandardne, sa odrazí na pitve. Pitva je dokument, do ktorého napíšete, čo sa vám stalo, podrobné načasovanie, čo ste urobili pre nápravu a (toto je povinný blok!) čo urobíte, aby sa to v budúcnosti nestalo. Toto je povinné a nevyhnutné pre následnú analýzu.
Čo sa považuje za prestoje?
K čomu to všetko viedlo?To viedlo k tomu, že (mali sme určité problémy so stabilitou, nevyhovovalo to ani klientom, ani nám) za posledných 6 mesiacov bol náš indikátor stability 99,97. Môžeme povedať, že to nie je veľa. Áno, máme sa o čo snažiť. Z tohto ukazovateľa je asi polovica stability nie našej, ale našej webovej aplikačnej brány firewall, ktorá stojí pred nami a používa sa ako služba, ale klientov to nezaujíma.
Naučili sme sa v noci spať. Konečne! Pred šiestimi mesiacmi sme nemohli. A k tejto poznámke s výsledkami by som rád poznamenal jednu poznámku. Včera večer bola úžasná správa o riadiacom systéme jadrového reaktora. Ak ma ľudia, ktorí napísali tento systém, počujú, zabudnite na to, čo som povedal o „2 % nie sú prestoje“. Pre vás sú 2 % prestoje, aj keď na dve minúty!
To je všetko! Vaše otázky.
O balanceroch a migrácii databáz
Otázka z publika (ďalej – B): – Dobrý večer. Ďakujem veľmi pekne za takúto správu od správcu! Krátka otázka o vašich balanceroch. Spomínali ste, že máte WAF, teda ako som pochopil, používate nejaký externý balancer...
EK: – Nie, naše služby využívame ako balancer. V tomto prípade je pre nás WAF výhradne nástrojom DDoS ochrany.
in: – Môžete povedať pár slov o balancéroch?
EK: – Ako som už povedal, toto je skupina serverov v openresty. Teraz máme 5 rezervných skupín, ktoré odpovedajú výhradne... teda server, ktorý beží výhradne openresty, iba proxy server. Aby sme pochopili, koľko toho držíme: teraz máme pravidelný dopravný tok niekoľko stoviek megabitov. Zvládnu to, cítia sa dobre, dokonca sa ani nenamáhajú.
in: – Tiež jednoduchá otázka. Tu je nasadenie modrej/zelenej. Čo robíte napríklad s migráciami databáz?
EK: - Dobrá otázka! Pozrite, v modrom/zelenom nasadení máme samostatné fronty pre každý riadok. To znamená, že ak hovoríme o frontoch udalostí, ktoré sa prenášajú od pracovníka k pracovníkovi, existujú oddelené fronty pre modrú linku a pre zelenú linku. Ak hovoríme o samotnej databáze, tak sme ju zámerne zúžili, ako sa len dalo, všetko presunuli prakticky do frontov, v databáze ukladáme len zásobník transakcií. A náš zásobník transakcií je rovnaký pre všetky riadky. S databázou v tomto kontexte: nedelíme ju na modrú a zelenú, pretože obe verzie kódu musia vedieť, čo sa s transakciou deje.
Priatelia, mám pre vás aj malú odmenu - knihu. A mal by som byť ocenený za najlepšiu otázku.
in: - Ahoj. Ďakujem za správu. Otázkou je toto. Sleduješ platby, sleduješ služby, s ktorými komunikuješ... Ako však sledovať, aby sa človek nejakým spôsobom dostal na vašu platobnú stránku, vykonal platbu a projekt mu pripísal peniaze? To znamená, ako monitorujete, či je obchodník k dispozícii a prijal vaše spätné volanie?
EK: – „Obchodník“ je pre nás v tomto prípade úplne rovnaká externá služba ako platobný systém. Sledujeme rýchlosť odozvy obchodníka.
O šifrovaní databázy
in: - Ahoj. Mám trochu súvisiacu otázku. Máte citlivé údaje PCI DSS. Chcel som vedieť, ako ukladáte čísla PAN vo frontoch, do ktorých musíte preniesť? Používate nejaké šifrovanie? A to vedie k druhej otázke: podľa PCI DSS je potrebné v prípade zmien (prepúšťanie administrátorov a pod.) pravidelne prešifrovať databázu - čo sa v tomto prípade stane s prístupnosťou?
EK: - Úžasná otázka! Po prvé, čísla PAN neukladáme do frontov. V zásade nemáme právo nikde ukladať PAN v jasnej forme, preto používame špeciálnu službu (nazývame ju „Kademon“) - ide o službu, ktorá robí len jednu vec: prijíma správu ako vstup a odosiela odoslať zašifrovanú správu. A všetko ukladáme s touto zašifrovanou správou. V súlade s tým je dĺžka nášho kľúča pod kilobajtom, takže je to seriózne a spoľahlivé.in: – Potrebujete teraz 2 kilobajty?
EK: – Zdá sa, že len včera to bolo 256... No kde inde?!
Podľa toho je toto prvé. A po druhé, riešenie, ktoré existuje, podporuje postup opätovného šifrovania – existujú dva páry „kekov“ (kľúčov), ktoré dávajú „balíčky“, ktoré šifrujú (kľúč sú kľúče, dek sú deriváty kľúčov, ktoré šifrujú) . A ak sa postup spustí (stáva sa to pravidelne, od 3 mesiacov do ± niektorých), stiahneme nový pár „koláčov“ a znova zašifrujeme údaje. Máme samostatné služby, ktoré vytrhávajú všetky údaje a šifrujú ich novým spôsobom; Dáta sú uložené vedľa identifikátora kľúča, ktorým sú zašifrované. Preto, akonáhle zašifrujeme údaje pomocou nových kľúčov, starý kľúč vymažeme.
Niekedy je potrebné platiť manuálne...
in: – To znamená, že ak vám prišla refundácia za nejakú operáciu, budete ju stále dešifrovať pomocou starého kľúča?
EK: - Áno.
in: – Potom ešte jedna malá otázka. Keď dôjde k nejakému zlyhaniu, pádu alebo incidentu, je potrebné transakciu pretlačiť manuálne. Existuje taká situácia.
EK: - Áno, niekedy.
in: – Odkiaľ máte tieto údaje? Alebo chodíte do tohto skladu sami?
EK: – Nie, no, samozrejme, máme nejaký druh back-office systému, ktorý obsahuje rozhranie pre našu podporu. Ak nevieme, v akom stave sa transakcia nachádza (napríklad kým platobný systém nereagoval timeoutom), nevieme a priori, čiže konečný stav pridelíme len s plnou dôverou. V tomto prípade priradíme transakcii špeciálny stav na manuálne spracovanie. Ráno, na druhý deň, akonáhle podpora dostane informáciu, že také a také transakcie zostávajú v platobnom systéme, manuálne ich spracujú v tomto rozhraní.
in: – Mám pár otázok. Jedným z nich je pokračovanie PCI DSS zóny: ako zaznamenáte ich okruh? Táto otázka je preto, lebo vývojár mohol do denníkov vložiť čokoľvek! Druhá otázka: ako zavádzate rýchle opravy? Jednou z možností je použitie úchytov v databáze, ale môžu existovať bezplatné rýchle opravy – aký je tam postup? A tretia otázka asi súvisí s RTO, RPO. Vaša dostupnosť bola 99,97, takmer štyri deviatky, ale ako som dobre pochopil, máte druhé dátové centrum, tretie dátové centrum a piate dátové centrum... Ako ich synchronizujete, replikujete a všetko ostatné?EK: - Začnime prvým. Bola prvá otázka o logách? Keď píšeme protokoly, máme vrstvu, ktorá maskuje všetky citlivé údaje. Pozrie sa na masku a na ďalšie polia. V súlade s tým naše protokoly vychádzajú s už maskovanými údajmi a obvodom PCI DSS. Ide o jednu z pravidelných úloh pridelených oddeleniu testovania. Sú povinní kontrolovať každú úlohu, vrátane protokolov, ktoré píšu, a to je jedna z pravidelných úloh počas kontroly kódu, aby sa dalo kontrolovať, či vývojár niečo nezapísal. Následné kontroly vykonáva oddelenie informačnej bezpečnosti pravidelne asi raz týždenne: selektívne sa zbierajú protokoly za posledný deň a prechádzajú cez špeciálny skener-analyzátor z testovacích serverov, aby sa všetko skontrolovalo.
O hot-fixoch. Toto je zahrnuté v našich pravidlách nasadenia. Máme samostatnú klauzulu o rýchlych opravách. Veríme, že rýchle opravy nasadzujeme nepretržite, keď ich potrebujeme. Hneď ako je verzia zostavená, hneď ako je spustená, akonáhle máme artefakt, máme v službe správcu systému na zavolanie z podpory a ten ju nasadí v momente, keď je to potrebné.Asi „štyri deviataci“. Číslo, ktoré máme teraz, bolo skutočne dosiahnuté a snažili sme sa o to v inom dátovom centre. Teraz máme druhé dátové centrum a medzi nimi začíname smerovať a otázka replikácie medzi dátovými centrami je skutočne netriviálna otázka. Pokúsili sme sa to vyriešiť naraz pomocou rôznych prostriedkov: pokúsili sme sa použiť rovnakú „Tarantulu“ - nefungovalo to pre nás, hneď vám to poviem. Preto sme skončili s ručným objednávaním „senzákov“. V skutočnosti každá aplikácia v našom systéme asynchrónne spúšťa potrebnú synchronizáciu „zmena – hotovo“ medzi dátovými centrami.
in: - Ak ste dostali druhú, prečo ste nedostali tretiu? Pretože ešte nikto nemá rozdelený mozog...
EK: - Ale nemáme rozdelený mozog. Vzhľadom na to, že každá aplikácia je riadená multimasterom, je pre nás jedno, do ktorého centra požiadavka prišla. Sme pripravení na to, že ak jedno z našich dátových centier zlyhá (na to sa spoliehame) a uprostred požiadavky užívateľa prejde do druhého dátového centra, sme pripravení o tohto užívateľa skutočne prísť; ale to budú jednotky, absolútne jednotky.
in: - Dobrý večer. Ďakujem za správu. Hovorili ste o vašom ladiacom nástroji, ktorý spúšťa niektoré testovacie transakcie vo výrobe. Ale povedzte nám o testovacích transakciách! Ako hlboko to ide?
EK: – Prechádza celým cyklom celého komponentu. Pre komponent nie je rozdiel medzi testovacou transakciou a produkčnou transakciou. Ale z logického hľadiska ide jednoducho o samostatný projekt v systéme, na ktorom sa spúšťajú len testovacie transakcie.
in: -Kde to odstrihneš? Tu Core poslal...
EK: – V tomto prípade za „Kor“ stojíme pri testovacích transakciách... Máme niečo ako smerovanie: „Kor“ vie, na ktorý platobný systém má byť zaslaný – pošleme ho do falošného platobného systému, ktorý jednoducho dá http signál a to je všetko.
in: – Povedzte mi, prosím, bola vaša aplikácia napísaná v jednom obrovskom monolite, alebo ste ju rozsekali na nejaké služby či dokonca mikroslužby?
EK: – Nemáme monolit, samozrejme, máme aplikáciu orientovanú na služby. Žartujeme, že naša služba je vyrobená z monolitov - sú naozaj dosť veľké. Je ťažké to nazvať mikroslužbami, ale sú to služby, v rámci ktorých pracujú pracovníci distribuovaných strojov.
Ak je služba na serveri ohrozená...
in: – Potom mám ďalšiu otázku. Aj keby to bol monolit, stále ste povedali, že máte veľa týchto okamžitých serverov, všetky v podstate spracúvajú údaje a otázka znie: „V prípade kompromitácie jedného z okamžitých serverov alebo aplikácie akýkoľvek individuálny odkaz , majú nejakú kontrolu prístupu? Ktorý z nich čo dokáže? Na koho sa mám obrátiť o aké informácie?
EK: - Rozhodne áno. Bezpečnostné požiadavky sú dosť vážne. Po prvé, máme otvorené pohyby dát a porty sú len tie, cez ktoré vopred predpokladáme pohyb dopravy. Ak komponent komunikuje s databázou (povedzme s Muskulom) cez 5-4-3-2, bude preň otvorený iba 5-4-3-2 a ostatné porty a iné smery premávky nebudú dostupné. Okrem toho musíte pochopiť, že v našej produkcii existuje asi 10 rôznych bezpečnostných slučiek. A aj keby bola aplikácia nejakým spôsobom ohrozená, nedajbože, útočník nebude mať prístup ku konzole na správu servera, pretože ide o inú zónu zabezpečenia siete.in: – A v tomto kontexte je pre mňa zaujímavejšie, že máte určité zmluvy so službami – čo môžu robiť, akými „akciami“ sa môžu navzájom kontaktovať... A v bežnom toku si niektoré konkrétne služby vyžadujú nejaké riadok, zoznam „akcií“ na druhom. Zdá sa, že sa v normálnej situácii neobracajú na ostatných a majú iné oblasti zodpovednosti. Ak bude jedna z nich napadnutá, bude schopná narušiť „akcie“ tejto služby?...
EK: - Rozumiem. Ak bola v normálnej situácii s iným serverom vôbec povolená komunikácia, tak áno. Podľa zmluvy SLA nemonitorujeme, že máte povolené iba prvé 3 „akcie“ a že nemáte povolené 4 „akcie“. Pre nás je to asi nadbytočné, pretože už máme 4-stupňový ochranný systém v princípe pre obvody. Radšej sa bránime kontúrami, než na úrovni vnútorností.
Ako funguje Visa, MasterCard a Sberbank
in: – Chcem objasniť bod týkajúci sa prechodu používateľa z jedného dátového centra do druhého. Pokiaľ viem, Visa a MasterCard fungujú pomocou binárneho synchrónneho protokolu 8583 a existujú tam zmesi. A chcel som vedieť, teraz máme na mysli prechod – je to priamo „Visa“ a „MasterCard“ alebo pred platobnými systémami, pred spracovaním?
EK: - Toto je pred mixmi. Naše mixy sú umiestnené v rovnakom dátovom centre.
in: – Zhruba povedané, máte jeden prípojný bod?
EK: – „Visa“ a „MasterCard“ – áno. Jednoducho preto, že Visa a MasterCard vyžadujú pomerne vážne investície do infraštruktúry na uzavretie samostatných zmlúv napríklad na získanie druhého páru mixov. Sú rezervované v rámci jedného dátového centra, ale ak nám, nedajbože, zanikne dátové centrum, kde sú mixy na pripojenie k Visa a MasterCard, tak stratíme spojenie s Visa a MasterCard...
in: – Ako ich možno rezervovať? Viem, že Visa povoľuje v princípe len jedno spojenie!
EK: – Zariadenia si dodávajú sami. V každom prípade sme dostali výbavu, ktorá je vo vnútri plne nadbytočná.
in: – Takže stojan je od ich Connects Orange?...
EK: - Áno.
in: – Ale čo tento prípad: ak vaše dátové centrum zmizne, ako ho môžete ďalej používať? Alebo sa doprava zastaví?
EK: - Nie. V tomto prípade jednoducho prepneme prevádzku na iný kanál, čo bude samozrejme drahšie pre nás a drahšie pre našich klientov. Ale premávka nepôjde cez naše priame spojenie s Visa, MasterCard, ale cez podmienenú Sberbank (veľmi prehnané).
Veľmi sa ospravedlňujem, ak som urazil zamestnancov Sberbank. Ale podľa našich štatistík medzi ruskými bankami najčastejšie padá Sberbank. Neprejde mesiac, aby v Sberbank niečo nespadlo.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com