Všichni mluví o procesech vývoje a testování, školení personálu, zvyšování motivace, ale tyto procesy nestačí, když minuta výpadku služby stojí obrovské peníze. Co dělat, když provádíte finanční transakce v rámci přísné smlouvy SLA? Jak zvýšit spolehlivost a odolnost proti chybám vašich systémů a vyřadit z rovnice vývoj a testování?
Příští konference HighLoad++ se bude konat 6. a 7. dubna 2020 v St. Petersburgu. Podrobnosti a vstupenky na . 9. listopadu, 18:00. HighLoad++ Moskva 2018, Dillí + hala Kalkata. Teze a .
Jevgenij Kuzovlev (dále jen EC): - Přátelé, ahoj! Jmenuji se Kuzovlev Evgeniy. Jsem ze společnosti EcommPay, specifickou divizí je EcommPay IT, IT divize skupiny společností. A dnes si povíme o prostojích – o tom, jak se jim vyhnout, o tom, jak minimalizovat jejich následky, když se tomu vyhnout nedá. Téma je uvedeno takto: „Co dělat, když minuta výpadku stojí 100 000 USD“? Při pohledu do budoucna jsou naše čísla srovnatelná.
Co dělá EcommPay IT?
Kdo jsme? Proč tu před tebou stojím? Proč mám právo ti tady něco říkat? A o čem si zde budeme povídat podrobněji?
Skupina společností EcommPay je mezinárodním akvizitorem. Platby zpracováváme po celém světě - v Rusku, Evropě, jihovýchodní Asii (Celý svět). Máme 9 kanceláří, celkem 500 zaměstnanců a přibližně o něco méně než polovinu z nich tvoří IT specialisté. Všechno, co děláme, na čem vyděláváme peníze, jsme dělali sami.
Všechny naše produkty (a máme jich poměrně hodně – v naší řadě velkých IT produktů máme asi 16 různých komponent) jsme napsali sami; Píšeme sami sebe, vyvíjíme se. A v tuto chvíli provádíme asi milion transakcí denně (miliony je asi správný způsob, jak to říct). Jsme poměrně mladá společnost – je nám teprve asi šest let.
Před 6 lety to byl takový startup, když kluci přišli s byznysem. Spojila je myšlenka (nebylo nic jiného než myšlenka) a my jsme běželi. Jako každý startup jsme běželi rychleji... Rychlost pro nás byla důležitější než kvalita.
V určitém okamžiku jsme přestali: uvědomili jsme si, že v takové rychlosti a kvalitě už nemůžeme žít a musíme se nejprve zaměřit na kvalitu. V tuto chvíli jsme se rozhodli napsat novou platformu, která by byla správná, škálovatelná a spolehlivá. Začali psát tuto platformu (začali investovat, vyvíjet vývoj, testovat), ale v určitém okamžiku si uvědomili, že vývoj a testování nám neumožňují dosáhnout nové úrovně kvality služeb.
Vyrobíte nový produkt, dáte ho do výroby, ale stejně se někde něco pokazí. A dnes budeme hovořit o tom, jak dosáhnout nové úrovně kvality (jak jsme to udělali, o našich zkušenostech), přičemž vývoj a testování jsou mimo rovnici; budeme hovořit o tom, co má provoz k dispozici - co provoz umí sám, co může nabídnout testování za účelem ovlivnění kvality.
Prostoje. Operační příkazy.
Vždy hlavním základním kamenem, o čem si dnes budeme vlastně povídat, jsou prostoje. Hrozné slovo. Pokud máme prostoje, je pro nás všechno špatné. Běžíme to zvýšit, admini drží server - nedej bože, aby nespadl, jak se říká v té písni. O tom si dnes povíme.
Když jsme začali měnit své přístupy, vytvořili jsme 4 přikázání. Mám je prezentovány na snímcích:
Tato přikázání jsou docela jednoduchá:
- Rychle identifikujte problém.
- Zbavte se toho ještě rychleji.
- Pomozte pochopit důvod (později pro vývojáře).
- A standardizovat přístupy.
Upozorňuji na bod č. 2. Problém se zbavujeme, neřešíme. Rozhodování je vedlejší. Pro nás je prvořadé, aby byl uživatel před tímto problémem chráněn. Bude existovat v nějakém izolovaném prostředí, ale toto prostředí s ním nebude mít žádný kontakt. Vlastně si projdeme tyto čtyři skupiny problémů (některé podrobněji, některé méně podrobně), řeknu vám, co používáme, jaké relevantní zkušenosti s řešením máme.
Odstraňování problémů: Kdy k nim dochází a co s nimi dělat?
Začneme ale mimo pořadí, začneme bodem č. 2 – jak se rychle zbavit problému? Vyskytl se problém – musíme ho opravit. "Co s tím máme dělat?" - hlavní otázka. A když jsme začali přemýšlet o tom, jak problém vyřešit, vyvinuli jsme pro sebe několik požadavků, které musí řešení problémů splňovat.
Pro formulaci těchto požadavků jsme se rozhodli položit si otázku: „Kdy máme problémy“? A problémy, jak se ukázalo, nastávají ve čtyřech případech:
- Selhání hardwaru.
- Externí služby se nezdařily.
- Změna verze softwaru (stejné nasazení).
- Růst výbušného zatížení.
O prvních dvou se bavit nebudeme. Hardwarovou poruchu lze vyřešit zcela jednoduše: musíte mít vše duplikované. Pokud se jedná o disky, musí být disky sestaveny v RAID; pokud se jedná o server, musí být server duplikován; pokud máte síťovou infrastrukturu, musíte dodat druhou kopii síťové infrastruktury, to znamená, že ji vezmete a duplikovat to. A pokud něco selže, přepnete na záložní napájení. Tady je těžké říct něco víc.
Druhým je selhání externích služeb. Pro většinu není systém vůbec problém, ale pro nás ne. Jelikož zpracováváme platby, jsme agregátorem, který stojí mezi uživatelem (který zadává údaje o své kartě) a bankami, platebními systémy (Visa, MasterCard, Mira atd.). Naše externí služby (platební systémy, banky) mají tendenci selhávat. My ani vy (pokud takové služby máte) to nemůžeme ovlivnit.
co potom dělat? Zde jsou dvě možnosti. Za prvé, pokud můžete, měli byste tuto službu nějakým způsobem duplikovat. Například, pokud můžeme, převádíme provoz z jedné služby do druhé: například karty byly zpracovány přes Sberbank, Sberbank má problémy – provoz převádíme [podmíněně] do Raiffeisen. Druhá věc, kterou můžeme udělat, je velmi rychle zaznamenat výpadek externích služeb, a proto si o rychlosti odezvy povíme v další části zprávy.
Ve skutečnosti z těchto čtyř můžeme konkrétně ovlivnit změnu verzí softwaru – přijmout opatření, která povedou ke zlepšení situace v kontextu nasazení a v kontextu explozivního růstu zátěže. Ve skutečnosti jsme to udělali. Opět malá poznámka...
Z těchto čtyř problémů je několik vyřešeno okamžitě, pokud máte cloud. Pokud se nacházíte v cloudech Microsoft Azhur, Ozone nebo používáte naše cloudy od Yandexu nebo Mailu, pak se jejich problémem stane přinejmenším hardwarová porucha a v rámci hardwarové poruchy se pro vás vše okamžitě stane v pořádku.
Jsme trochu netradiční společnost. Tady všichni mluví o „Kubernetech“, o oblacích – nemáme ani „Kubernety“, ani mraky. Ale v mnoha datových centrech máme racky s hardwarem a jsme nuceni žít na tomto hardwaru, jsme nuceni nést za to všechno zodpovědnost. Proto budeme hovořit v této souvislosti. Takže o problémech. První dva byly vyjmuty ze závorek.
Změna verze softwaru. Základny
Naši vývojáři nemají přístup k produkci. proč tomu tak je? Jde jen o to, že máme certifikaci PCI DSS a naši vývojáři prostě nemají právo dostat se do „produktu“. To je ono, tečka. Vůbec. Odpovědnost za vývoj tedy končí přesně v okamžiku, kdy vývoj odešle sestavení k vydání.
Naším druhým základem, který máme a který nám také velmi pomáhá, je absence unikátních nezdokumentovaných znalostí. Doufám, že u vás je to stejné. Protože pokud tomu tak není, budete mít problémy. Problémy nastanou, když tyto jedinečné, nezdokumentované znalosti nebudou přítomny ve správný čas na správném místě. Řekněme, že máte jednoho člověka, který ví, jak nasadit konkrétní komponentu – ten člověk tam není, je na dovolené nebo nemocný – to je vše, máte problémy.
A třetí základ, ke kterému jsme se dostali. Došli jsme k tomu přes bolest, krev, slzy – došli jsme k závěru, že jakákoliv naše stavba obsahuje chyby, i když je bez chyb. Rozhodli jsme se pro to sami: když něco nasadíme, když něco zavedeme do výroby, máme sestavení s chybami. Vytvořili jsme požadavky, které musí náš systém splňovat.
Požadavky na změnu verze softwaru
Existují tři požadavky:
- Rozmístění musíme rychle vrátit zpět.
- Musíme minimalizovat dopad neúspěšného nasazení.
- A musíme být schopni rychle nasadit paralelně.
Přesně v tomto pořadí! Proč? Protože v první řadě při nasazování nové verze není důležitá rychlost, ale důležité je pro vás, když se něco pokazí, rychle se vrátit zpět a mít minimální dopad. Pokud ale máte ve výrobě sadu verzí, u kterých se ukáže, že došlo k chybě (z ničeho nic nedošlo k nasazení, ale je tam chyba) - je pro vás důležitá rychlost následného nasazení. Co jsme pro splnění těchto požadavků udělali? Uchýlili jsme se k následující metodice:
Je to docela známé, nikdy jsme to nevynalezli - tohle je nasazení Blue/Green. co to je? Musíte mít kopii pro každou skupinu serverů, na kterých jsou vaše aplikace nainstalovány. Kopie je „teplá“: není na ní žádný provoz, ale tento provoz lze kdykoli odeslat do této kopie. Tato kopie obsahuje předchozí verzi. A v době nasazení zavedete kód do neaktivní kopie. Poté přepnete část provozu (nebo celý) na novou verzi. Chcete-li tedy změnit tok provozu ze staré verze na novou, musíte provést pouze jednu akci: musíte změnit balancer v proti proudu, změnit směr - z jednoho proti proudu do druhého. To je velmi pohodlné a řeší to problém rychlého přepínání a rychlého vrácení zpět.Zde je řešením druhé otázky minimalizace: na novou linku, na linku s novým kódem (ať jsou to např. 2 %), můžete poslat jen část svého provozu. A tato 2% nejsou 100%! Pokud jste ztratili 100 % provozu kvůli neúspěšnému nasazení, je to děsivé; pokud jste ztratili 2 % provozu, je to nepříjemné, ale není to děsivé. Navíc si toho uživatelé s největší pravděpodobností ani nevšimnou, protože v některých případech (ne ve všech) se stejný uživatel po stisknutí F5 dostane do jiné, funkční verze.
Modré/zelené nasazení. Směrování
Nicméně ne vše je tak jednoduché „Modrá/zelená nasazení“... Všechny naše komponenty lze rozdělit do tří skupin:
- toto je frontend (platební stránky, které vidí naši klienti);
- zpracovatelské jádro;
- adaptér pro práci s platebními systémy (banky, MasterCard, Visa...).
A je tu nuance - nuance spočívá ve směrování mezi řádky. Pokud prostě přepnete 100 % provozu, tyto problémy nemáte. Ale pokud chcete změnit 2 %, začnete se ptát: „Jak to udělat?“ Nejjednodušší věc je přímo vpřed: můžete nastavit Round Robin v nginx náhodným výběrem a máte 2 % doleva, 98 % doprava. Ale to není vždy vhodné.
Například v našem případě uživatel interaguje se systémem s více než jedním požadavkem. To je normální: 2, 3, 4, 5 požadavků – vaše systémy mohou být stejné. A pokud je pro vás důležité, aby všechny požadavky uživatele přicházely na stejnou linku, na kterou přišel první požadavek, nebo (druhý bod) všechny požadavky uživatele přišly po přepnutí na novou linku (mohl začít pracovat dříve s systém, před přepnutím), - pak pro vás toto náhodné rozdělení není vhodné. Pak jsou následující možnosti:
První možnost, nejjednodušší, je založena na základních parametrech klienta (IP Hash). Máte IP a rozdělíte ji zprava doleva podle IP adresy. Pak vám bude fungovat druhý případ, který jsem popsal, když došlo k nasazení, uživatel již mohl začít pracovat s vaším systémem a od okamžiku nasazení budou všechny požadavky chodit na nový řádek (řekněme na stejnou).Pokud vám to z nějakého důvodu nevyhovuje a musíte posílat požadavky na linku, kam přišel prvotní, prvotní požadavek uživatele, pak máte dvě možnosti...
První možnost: můžete si koupit placený nginx+. Existuje mechanismus Sticky sessions, který na počáteční požadavek uživatele přiřadí uživateli relaci a připojí ji k jednomu nebo druhému upstreamu. Všechny následné uživatelské požadavky v průběhu trvání relace budou odeslány do stejného upstreamu, kde byla relace zveřejněna.To nám nevyhovovalo, protože jsme již měli pravidelný nginx. Přechod na nginx+ neznamená, že by byl drahý, jen to pro nás bylo poněkud bolestivé a ne příliš správné. „Sticks Sessions“ nám například nefungovaly z prostého důvodu, že „Sticks Sessions“ neumožňují směrování založené na „Buď-nebo“. Zde můžete specifikovat, co děláme „Sticks Sessions“, například podle IP adresy nebo podle IP adresy a cookies nebo podle postparametru, ale tam je „Buď-nebo“ složitější.
Proto jsme se dostali ke čtvrté možnosti. Vzali jsme nginx na steroidech (toto je openresty) - to je stejný nginx, který navíc podporuje zahrnutí posledních skriptů. Můžete napsat poslední skript, dát mu „otevřený odpočinek“ a tento poslední skript bude spuštěn, když přijde požadavek uživatele.
A napsali jsme vlastně takový skript, nastavili jsme si „openresti“ a v tomto skriptu třídíme 6 různých parametrů zřetězením „nebo“. Podle přítomnosti toho či onoho parametru víme, že uživatel přišel na tu či onu stránku, na ten či onen řádek.
Modré/zelené nasazení. Výhody a nevýhody
Pravděpodobně by to šlo trochu zjednodušit (použít stejné „Sticky Sessions“), ale máme také takovou nuanci, že s námi nekomunikuje pouze uživatel v rámci jednoho zpracování jedné transakce... Ale také s námi komunikují platební systémy: Po zpracování transakce (zasláním požadavku do platebního systému) obdržíme coolback.
A řekněme, že pokud v našem okruhu dokážeme přeposlat IP adresu uživatele ve všech požadavcích a rozdělit uživatele na základě IP adresy, pak neřekneme to samé „Visa“: „Ty vole, my jsme taková retro společnost, zdá se nám být mezinárodní (na webu a v Rusku)... Uveďte prosím IP adresu uživatele do dalšího pole, váš protokol je standardizovaný“! Je jasné, že nebudou souhlasit.
Tudíž nám to nefungovalo – dělali jsme openresty. Podle toho jsme se směrováním dostali něco takového:Blue/Green Deployment má tedy výhody, které jsem zmínil, a nevýhody.
Dvě nevýhody:
- musíte se obtěžovat se směrováním;
- druhou hlavní nevýhodou jsou náklady.
Potřebujete dvakrát tolik serverů, potřebujete dvakrát tolik provozních zdrojů, musíte vynaložit dvakrát tolik úsilí na údržbu celé této zoo.
Mimochodem, mezi výhody patří ještě jedna věc, kterou jsem dříve nezmínil: máte rezervu pro případ růstu zátěže. Pokud máte explozivní nárůst zátěže, máte velký počet uživatelů, pak jednoduše zahrnete druhý řádek do distribuce 50 na 50 - a okamžitě máte x2 servery ve svém clusteru, dokud nevyřešíte problém s více servery.
Jak provést rychlé nasazení?
Mluvili jsme o tom, jak vyřešit problém minimalizace a rychlého vrácení zpět, ale otázka zůstává: "Jak rychle nasadit?"
Tady je to krátké a jednoduché.- Musíte mít CD systém (Continuous Delivery) – bez něj nemůžete žít. Pokud máte jeden server, můžete jej nasadit ručně. Máme asi jeden a půl tisíce serverů a jeden a půl tisíce úchytů, samozřejmě - můžeme osadit oddělení o velikosti této místnosti jen pro nasazení.
- Nasazení musí být paralelní. Pokud je vaše nasazení sekvenční, pak je všechno špatně. Jeden server je normální, celý den budete nasazovat jeden a půl tisíce serverů.
- Zase pro zrychlení to už asi není potřeba. Během nasazení je projekt obvykle postaven. Máte webový projekt, existuje front-endová část (uděláte tam webový balíček, zkompilujete npm - něco takového) a tento proces je v zásadě krátkodobý - 5 minut, ale těchto 5 minut může být kritický. To je důvod, proč to například neděláme: odstranili jsme těchto 5 minut, nasadili jsme artefakty.
Co je to artefakt? Artefakt je sestavená stavba, ve které již byly dokončeny všechny části sestavy. Tento artefakt uložíme do úložiště artefaktů. Svého času jsme používali dvě taková úložiště - byl to Nexus a nyní jFrog Artifactory. Zpočátku jsme používali "Nexus", protože jsme tento přístup začali praktikovat v java aplikacích (vyhovovalo to). Pak tam dali nějaké aplikace napsané v PHP; a „Nexus“ již nebyl vhodný, a proto jsme zvolili jFrog Artefactory, který umí artefaktovat téměř vše. Dokonce jsme dospěli k tomu, že v tomto úložišti artefaktů ukládáme naše vlastní binární balíčky, které shromažďujeme pro servery.
Růst výbušného zatížení
Mluvili jsme o změně verze softwaru. Další věc, kterou máme, je explozivní nárůst zátěže. Tady asi myslím explozivním růstem zátěže ne úplně to pravé...
Napsali jsme nový systém – je orientovaný na služby, módní, krásný, všude pracovníci, všude fronty, všude asynchronie. A v takových systémech mohou data proudit různými toky. Pro první transakci lze použít 1., 3., 10. pracovníka, pro druhou transakci - 2., 4., 5.. A dnes, řekněme, ráno máte datový tok, který využívá první tři pracovníky, a večer se dramaticky změní a vše využívá další tři pracovníky.
A tady se ukazuje, že musíte nějak škálovat pracovníky, musíte nějak škálovat své služby, ale zároveň zabránit nafouknutí zdrojů.
Definovali jsme naše požadavky. Tyto požadavky jsou docela jednoduché: aby existovalo zjišťování služeb, parametrizace - vše je standardní pro budování takových škálovatelných systémů, s výjimkou jednoho bodu - znehodnocení zdrojů. Řekli jsme, že nejsme připraveni amortizovat zdroje tak, aby servery ohřívaly vzduch. Vzali jsme "Consul", vzali jsme "Nomáda", který řídí naše pracovníky.Proč je to pro nás problém? Vraťme se trochu zpět. Nyní máme za sebou kolem 70 platebních systémů. Ráno jede provoz přes Sberbank, pak padla třeba Sberbank a přepínáme ji na jiný platební systém. Před Sberbank jsme měli 100 zaměstnanců a poté potřebujeme prudce navýšit 100 zaměstnanců pro další platební styk. A je žádoucí, aby se to vše dělo bez lidské účasti. Protože pokud je tam lidská účast, měl by tam 24/7 sedět inženýr, který by měl dělat pouze toto, protože takové poruchy, když je za vámi 70 systémů, se stávají pravidelně.
Podívali jsme se proto na Nomad, který má otevřenou IP, a napsali vlastní věc Scale-Nomad - ScaleNo, která dělá přibližně toto: sleduje růst fronty a snižuje nebo zvyšuje počet pracovníků v závislosti na dynamice z fronty. Když jsme to udělali, pomysleli jsme si: "Možná bychom to mohli otevřít jako open source?" Pak se na ni podívali – byla jednoduchá jako dvě kopejky.
Zatím jsme to neotevřeli, ale pokud náhle po nahlášení, poté, co jste si uvědomili, že něco takového potřebujete, potřebujete to, moje kontakty jsou na posledním snímku - napište mi prosím. Pokud bude alespoň 3-5 lidí, sponzorujeme to.
Jak to funguje? Pojďme se podívat! Pohled do budoucna: na levé straně je část našeho sledování: toto je jeden řádek, nahoře je čas zpracování události, uprostřed je počet transakcí, dole počet pracovníků.Když se podíváte, na tomto obrázku je chyba. Na horním žebříčku se jeden z žebříčků zhroutil za 45 sekund – jeden z platebních systémů selhal. Okamžitě byl za 2 minuty přiveden provoz a fronta začala narůstat na jiný platební systém, kde nebyli žádní pracovníci (nevyužívali jsme zdroje - naopak jsme zdroj správně zlikvidovali). Nechtěli jsme topit - byl minimální počet, asi 5-10 pracovníků, ale nezvládli.
Poslední graf ukazuje „hrb“, což znamená, že „Skaleno“ tuto částku zdvojnásobilo. A pak, když graf trochu klesl, trochu ho snížil – počet pracovníků se automaticky změnil. Tak tahle věc funguje. Mluvili jsme o bodu číslo 2 - "Jak se rychle zbavit důvodů."
Sledování. Jak rychle identifikovat problém?
Nyní je prvním bodem „Jak rychle identifikovat problém? Monitorování! Některé věci musíme rychle pochopit. Jaké věci bychom měli rychle pochopit?
Tři věci!- Musíme rychle pochopit a pochopit výkon našich vlastních zdrojů.
- Musíme rychle porozumět poruchám a sledovat výkon systémů, které jsou pro nás externí.
- Třetím bodem je identifikace logických chyb. To je, když vám systém funguje, vše je podle všech ukazatelů normální, ale něco se pokazí.
Tady vám asi neřeknu nic tak skvělého. Budu kapitán Obvious. Hledali jsme, co je na trhu. Máme „zábavnou zoo“. Toto je druh zoo, který nyní máme:
Zabbix používáme k monitorování hardwaru, ke sledování hlavních indikátorů serverů. Pro databáze používáme Okmeter. Používáme „Grafana“ a „Prometheus“ pro všechny ostatní ukazatele, které neodpovídají prvním dvěma, některé s „Grafana“ a „Prometheus“ a některé s „Grafana“ s „Influx“ a Telegraf.Před rokem jsme chtěli použít New Relic. Super věc, umí všechno. Ale jak umí všechno, je tak drahá. Když jsme narostli na objem 1,5 tisíce serverů, přišel za námi dodavatel a řekl: „Uzavřeme smlouvu na příští rok.“ Podívali jsme se na cenu a řekli ne, to neuděláme. Nyní opouštíme New Relic, zbývá nám asi 15 serverů pod kontrolou New Relic. Cena se ukázala jako naprosto divoká.
A je tu jeden nástroj, který jsme sami implementovali – je to Debugger. Nejprve jsme tomu říkali „Bagger“, ale pak kolem prošel učitel angličtiny, divoce se zasmál a přejmenoval to na „Debagger“. co to je? Jedná se o nástroj, který ve skutečnosti během 15–30 sekund na každé součásti, jako „černá skříňka“ systému, spustí testy celkového výkonu součásti.
Pokud například existuje externí stránka (platební stránka), jednoduše ji otevře a podívá se, jak by měla vypadat. Pokud se toto zpracovává, odešle testovací „transakci“ a ujistí se, že tato „transakce“ dorazí. Pokud se jedná o spojení s platebními systémy, spustíme tam, kde je to možné, testovací požadavek a uvidíme, že je u nás vše v pořádku.
Jaké ukazatele jsou důležité pro sledování?
Co hlavně sledujeme? Jaké ukazatele jsou pro nás důležité?
- Doba odezvy / RPS na frontách je velmi důležitým ukazatelem. Okamžitě odpovídá, že s vámi není něco v pořádku.
- Počet zpracovaných zpráv ve všech frontách.
- Počet pracovníků.
- Základní metriky správnosti.
Posledním bodem je metrika „obchod“, „obchod“. Pokud chcete sledovat to samé, musíte si definovat jednu nebo dvě metriky, které jsou pro vás hlavními indikátory. Naší metrikou je propustnost (jedná se o poměr počtu úspěšných transakcí k celkovému toku transakcí). Pokud se v něm něco změní v intervalu 5-10-15 minut, znamená to, že máme problémy (pokud se to radikálně změní).
Jak to u nás vypadá, je příklad jedné z našich desek:
Na levé straně je 6 grafů, to je podle řádků - počet pracovníků a počet zpráv ve frontách. Na pravé straně – RPS, RTS. Níže je uvedena stejná „obchodní“ metrika. A v „obchodní“ metrice můžeme okamžitě vidět, že se ve dvou prostředních grafech něco pokazilo... Je to jen další systém, který za námi stojí a padl.Druhá věc, kterou jsme museli udělat, bylo sledovat pád externích platebních systémů. Zde jsme vzali OpenTracing - mechanismus, standardní, paradigma, které vám umožňuje sledovat distribuované systémy; a trochu se to změnilo. Standardní paradigma OpenTracing říká, že vytváříme trasování pro každý jednotlivý požadavek. Nepotřebovali jsme to a zabalili jsme to do souhrnného, agregačního trasování. Vytvořili jsme nástroj, který nám umožňuje sledovat rychlost systémů za námi.
Graf nám ukazuje, že jeden z platebních systémů začal reagovat do 3 sekund – máme problémy. Navíc tato věc bude reagovat, když začnou problémy, v intervalu 20-30 sekund.A třetí třídou monitorovacích chyb, které existují, je logické monitorování.
Abych byl upřímný, nevěděl jsem, co na tento snímek nakreslit, protože jsme na trhu dlouho hledali něco, co by nám vyhovovalo. Nic jsme nenašli, tak jsme to museli udělat sami.
Co myslím logickým sledováním? No, představte si: uděláte ze sebe systém (například klon Tinder); udělal jsi to, spustil jsi to. Úspěšný manažer Vasja Pupkin si to dal do telefonu, vidí tam dívku, líbí se mu... a to podobné dívce nejde – to podobné jde ochrance Michaličovi ze stejného obchodního centra. Manažer jde dolů a pak se diví: "Proč se na něj tento ochranka Mikhalych tak příjemně usmívá?"V takových situacích... U nás zní tato situace trochu jinak, protože (psal jsem) jde o reputační ztrátu, která nepřímo vede k finančním ztrátám. Naše situace je opačná: můžeme utrpět přímé finanční ztráty – například pokud jsme transakci provedli jako úspěšnou, ale byla neúspěšná (nebo naopak). Musel jsem napsat svůj vlastní nástroj, který sleduje počet úspěšných transakcí v čase pomocí obchodních ukazatelů. Na trhu jsem nic nenašel! To je přesně ta myšlenka, kterou jsem chtěl sdělit. Na trhu není nic, co by tento druh problému vyřešilo.
Šlo o to, jak rychle identifikovat problém.
Jak zjistit důvody nasazení
Třetí skupina problémů, které řešíme, je poté, co jsme problém identifikovali, poté, co jsme se ho zbavili, bylo by dobré pochopit důvod vývoje, pro testování a něco s tím udělat. V souladu s tím musíme prozkoumat, musíme zvednout protokoly.
Pokud se bavíme o logech (hlavním důvodem jsou logy), převážná část našich logů je v ELK Stacku - téměř každý to má stejné. Pro někoho to nemusí být v ELK, ale pokud budete psát logy v gigabajtech, tak dříve nebo později na ELK přijdete. Zapisujeme je v terabajtech.
Tady je problém. Opravili jsme to, opravili chybu pro uživatele, začali jsme vyhrabávat, co tam bylo, vlezli jsme do Kibana, zadali tam ID transakce a dostali takový nánožník (ukazuje hodně). A v této utěrce není vůbec nic jasné. Proč? Ano, protože není jasné, která část patří jakému pracovníkovi, která část patří které složce. A v tu chvíli jsme si uvědomili, že potřebujeme trasování – stejný OpenTracing, o kterém jsem mluvil.Mysleli jsme si to před rokem, obrátili naši pozornost na trh a byly tam dva nástroje - „Zipkin“ a „Jaeger“. „Jager“ je ve skutečnosti takovým ideovým dědicem, ideovým nástupcem „Zipkina“. V Zipkinu je vše dobré, až na to, že neumí agregovat, neumí zahrnout logy do trasování, pouze časovou stopu. A „Jager“ to podpořil.
Podívali jsme se na „Jager“: můžete instrumentovat aplikace, můžete psát v Api (standard Api pro PHP však v té době nebyl schválen - bylo to před rokem, ale nyní je již schválen), ale tam nebyl absolutně žádný klient. "Dobře," pomysleli jsme si a napsali jsme svému vlastnímu klientovi. co jsme dostali? Zhruba takhle to vypadá:
V Jaegeru se pro každou zprávu vytvoří rozpětí. To znamená, že když uživatel otevře systém, vidí jeden nebo dva bloky pro každý příchozí požadavek (1-2-3 - počet příchozích požadavků od uživatele, počet bloků). Aby to bylo pro uživatele jednodušší, přidali jsme do protokolů a časových stop značky. Podle toho v případě chyby naše aplikace označí protokol příslušnou značkou Error. Můžete filtrovat podle značky Error a zobrazí se pouze úseky, které obsahují tento blok s chybou. Takto to vypadá, když rozpětí rozšíříme:
Uvnitř rozpětí je soubor stop. V tomto případě se jedná o tři testovací trasování a třetí trasování nám říká, že došlo k chybě. Zároveň zde vidíme časovou stopu: nahoře máme časovou stupnici a vidíme, v jakém časovém intervalu byl zaznamenán ten či onen log.Podle toho to pro nás šlo dobře. Napsali jsme vlastní rozšíření a vytvořili jsme ho jako open source. Pokud chcete pracovat s trasováním, pokud chcete pracovat s „Jager“ v PHP, je tu naše rozšíření, které můžete používat, jak se říká:
Máme toto rozšíření - je to klient pro OpenTracing Api, je vytvořeno jako php-extention, to znamená, že jej budete muset sestavit a nainstalovat do systému. Před rokem tomu nebylo jinak. Nyní existují další klienti, kteří jsou jako komponenty. Zde je to na vás: buď napumpujete komponenty pomocí skladatele, nebo použijete rozšíření na vás.Firemní standardy
Mluvili jsme o třech přikázáních. Čtvrtým přikázáním je standardizovat přístupy. O čem to je? Jde o toto:
Proč je zde slovo „firemní“? Ne proto, že bychom byli velká nebo byrokratická společnost, ne! Chtěl jsem zde použít slovo „firemní“ v kontextu toho, že každá společnost, každý produkt by měl mít své vlastní standardy, včetně vás. Jaké máme standardy?
- Máme pravidla pro nasazení. Bez něj se nikam nehneme, nemůžeme. Nasazujeme zhruba 60x týdně, tedy nasazujeme téměř neustále. Přitom my máme například v nasazovacích předpisech tabu na nasazení v pátek - zásadně nenasazujeme.
- Požadujeme dokumentaci. Ani jedna nová součástka se nedostane do výroby, pokud k ní není dokumentace, i kdyby se zrodila pod perem našich RnD specialistů. Požadujeme od nich pokyny k nasazení, monitorovací mapu a hrubý popis (no, jak mohou napsat programátoři), jak tato komponenta funguje, jak ji řešit.
- Řešíme ne příčinu problému, ale problém - to, co jsem již řekl. Je pro nás důležité chránit uživatele před problémy.
- Máme povolení. Za výpadek například nepovažujeme, pokud během dvou minut ztratíme 2 % provozu. To v našich statistikách v podstatě není zahrnuto. Jestli je to více v procentech nebo dočasné, už počítáme.
- A vždy píšeme posmrtně. Ať se nám stane cokoliv, každá situace, kdy se někdo ve výrobě choval nenormálně, se promítne do pitvy. Posmrtná pitva je dokument, do kterého napíšete, co se vám stalo, podrobné načasování, co jste udělali pro nápravu a (toto je povinný blok!) co uděláte, aby se to v budoucnu nestalo. To je povinné a nezbytné pro následnou analýzu.
Co je považováno za prostoj?
K čemu to všechno vedlo?To vedlo k tomu, že (měli jsme určité problémy se stabilitou, to nevyhovovalo klientům ani nám) za posledních 6 měsíců byl náš ukazatel stability 99,97. Dá se říci, že to není moc. Ano, máme se o co snažit. Z tohoto ukazatele je asi polovina stability, jaksi ne naší, ale našeho webového aplikačního firewallu, který stojí před námi a používá se jako služba, ale klienti se o to nestarají.
Naučili jsme se v noci spát. Konečně! Před šesti měsíci jsme nemohli. A k této poznámce s výsledky bych rád poznamenal jednu poznámku. Včera v noci byla úžasná zpráva o řídicím systému jaderného reaktoru. Pokud mě lidé, kteří napsali tento systém, slyší, zapomeňte prosím na to, co jsem řekl o „2 % nejsou prostoje“. Pro vás jsou 2 % prostoje, i když na dvě minuty!
To je vše! Vaše otázky.
O balancerech a migraci databází
Otázka z publika (dále – B): – Dobrý večer. Moc děkuji za takovou adminskou zprávu! Krátká otázka ohledně vašich balancerů. Zmínil jsi, že máš WAF, to znamená, jak jsem pochopil, používáš nějaký externí balancer...
EK: – Ne, využíváme naše služby jako balancer. V tomto případě je pro nás WAF výhradně DDoS ochranným nástrojem.
In: – Můžete říci pár slov o vyvažovačích?
EK: – Jak jsem již řekl, jedná se o skupinu serverů v openresty. Nyní máme 5 rezervních skupin, které reagují výhradně... tedy server, který běží výhradně openresty, pouze proxy provozuje. Abychom pochopili, kolik toho držíme: nyní máme pravidelný tok provozu několik stovek megabitů. Poradí si, cítí se dobře, ani se nenamáhají.
In: – Taky jednoduchá otázka. Zde je modré/zelené nasazení. Co děláte například s migracemi databází?
EK: - Dobrá otázka! Podívejte, v modrém/zeleném nasazení máme samostatné fronty pro každý řádek. To znamená, že pokud mluvíme o frontách událostí, které jsou přenášeny od pracovníka k pracovníkovi, existují samostatné fronty pro modrou linku a pro zelenou linku. Pokud se bavíme o databázi samotné, tak jsme ji záměrně zúžili, jak jen to šlo, vše přesunuli prakticky do front, v databázi ukládáme pouze zásobník transakcí. A náš zásobník transakcí je pro všechny řádky stejný. S databází v tomto kontextu: nerozdělujeme ji na modrou a zelenou, protože obě verze kódu musí vědět, co se s transakcí děje.
Přátelé, mám pro vás také malou odměnu - knihu. A měl bych to dostat za nejlepší otázku.
In: - Ahoj. Díky za zprávu. Otázkou je toto. Sledujete platby, hlídáte služby, se kterými komunikujete... Jak ale hlídat, aby člověk nějak přišel na vaši platební stránku, provedl platbu a projekt mu připsal peníze? To znamená, jak sledujete, že je marchant dostupný a přijal vaše zpětné volání?
EK: – „Obchodník“ je pro nás v tomto případě naprosto stejná externí služba jako platební systém. Sledujeme rychlost odezvy obchodníka.
O šifrování databáze
In: - Ahoj. Mám trochu související dotaz. Máte citlivá data PCI DSS. Chtěl jsem vědět, jak ukládáte čísla PAN ve frontách, do kterých potřebujete přesunout? Používáte nějaké šifrování? A to vede k druhé otázce: podle PCI DSS je nutné v případě změn (odvolání administrátorů apod.) databázi periodicky přešifrovat - co se v tomto případě stane s přístupností?
EK: - Úžasná otázka! Za prvé neukládáme čísla PAN do front. V zásadě nemáme právo PAN nikde ukládat v jasné podobě, proto používáme speciální službu (říkáme jí „Kademon“) - jedná se o službu, která dělá pouze jednu věc: přijímá zprávu jako vstup a odesílá odeslat zašifrovanou zprávu. A vše ukládáme s touto zašifrovanou zprávou. V souladu s tím je délka našeho klíče pod kilobajtem, takže je to vážné a spolehlivé.In: – Potřebujete nyní 2 kilobajty?
EK: – Zdá se, že právě včera to bylo 256... No, kde jinde?!
Podle toho je to první. A za druhé, řešení, které existuje, podporuje postup opětovného šifrování - existují dva páry „keků“ (klíčů), které dávají „balíčky“, které šifrují (klíč jsou klíče, dek jsou deriváty klíčů, které šifrují) . A pokud je procedura zahájena (stává se pravidelně, od 3 měsíců do ± některé), stáhneme nový pár „koláčů“ a data znovu zašifrujeme. Máme samostatné služby, které vytrhnou všechna data a zašifrují je novým způsobem; Data jsou uložena vedle identifikátoru klíče, kterým jsou šifrována. Jakmile tedy data zašifrujeme novými klíči, smažeme starý klíč.
Někdy je potřeba provést platby ručně...
In: – To znamená, že pokud došlo k vrácení peněz za nějakou operaci, budete ji stále dešifrovat pomocí starého klíče?
EK: - Ano.
In: – Pak ještě jedna malá otázka. Když dojde k nějakému selhání, pádu nebo incidentu, je nutné transakci prosadit ručně. Existuje taková situace.
EK: - Ano, někdy.
In: – Odkud tato data získáváte? Nebo do tohoto úložiště chodíte sami?
EK: – Ne, no, samozřejmě, máme nějaký druh back-office systému, který obsahuje rozhraní pro naši podporu. Pokud nevíme, v jakém stavu se transakce nachází (např. dokud platební systém neodpověděl timeoutem), neznáme a priori, to znamená, že konečný stav přiřadíme pouze s plnou důvěrou. V tomto případě přiřadíme transakci zvláštní stav pro ruční zpracování. Ráno, druhý den, jakmile podpora obdrží informaci, že takové a takové transakce zůstávají v platebním systému, ručně je zpracují v tomto rozhraní.
In: – Mám pár otázek. Jedním z nich je pokračování PCI DSS zóny: jak logujete jejich okruh? Tato otázka je proto, že vývojář mohl do protokolů vložit cokoli! Druhá otázka: jak zavádíte opravy hotfix? Jednou z možností je použití úchytů v databázi, ale mohou existovat bezplatné opravy hotfix – jaký je tam postup? A třetí otázka asi souvisí s RTO, RPO. Vaše dostupnost byla 99,97, téměř čtyři devítky, ale pokud tomu dobře rozumím, máte druhé datové centrum, třetí datové centrum a páté datové centrum... Jak je synchronizujete, replikujete a vše ostatní?EK: - Začněme tím prvním. Byla první otázka ohledně protokolů? Když píšeme protokoly, máme vrstvu, která maskuje všechna citlivá data. Podívá se na masku a na další pole. V souladu s tím naše protokoly vycházejí s již maskovanými daty a obvodem PCI DSS. Jedná se o jeden z pravidelných úkolů zadávaných oddělení testování. Jsou povinni zkontrolovat každý úkol, včetně protokolů, které zapisují, a to je jeden z pravidelných úkolů během kontroly kódu, aby bylo možné kontrolovat, že si vývojář něco nezapsal. Následné kontroly jsou pravidelně prováděny oddělením informační bezpečnosti zhruba jednou týdně: selektivně se snímají protokoly za poslední den a vše se prověřuje speciálním skenerem-analyzátorem z testovacích serverů.
O hot-fixech. Toto je zahrnuto v našich pravidlech pro nasazení. O opravách hotfix máme samostatnou klauzuli. Věříme, že opravy hotfix nasazujeme nepřetržitě, když je potřebujeme. Jakmile je verze sestavena, jakmile je spuštěna, jakmile máme artefakt, máme ve službě systémového administrátora na zavolání podpory a ten to nasadí v momentě, kdy je to potřeba.Asi „čtyři devítky“. Číslo, které nyní máme, bylo skutečně dosaženo a snažili jsme se o něj v jiném datovém centru. Nyní máme druhé datové centrum a začínáme mezi nimi směrovat a otázka replikace mezi datovými centry je skutečně netriviální otázkou. Snažili jsme se to vyřešit najednou pomocí různých prostředků: zkusili jsme použít stejnou „Tarantule“ - nefungovalo to pro nás, řeknu vám to hned. Proto jsme nakonec „smysly“ objednávali ručně. Ve skutečnosti každá aplikace v našem systému spouští nezbytnou synchronizaci „změna – hotovo“ mezi datovými centry asynchronně.
In: – Když jsi dostal druhý, proč jsi nedostal třetí? Protože rozdělený mozek ještě nikdo nemá...
EK: – Ale my nemáme Split Brain. Vzhledem k tomu, že každá aplikace je řízena multimasterem, je pro nás jedno, do kterého centra požadavek přišel. Jsme připraveni na to, že pokud jedno z našich datových center selže (spoléháme se na to) a uprostřed požadavku uživatele přejde do druhého datového centra, jsme připraveni o tohoto uživatele skutečně přijít; ale to budou jednotky, absolutní jednotky.
In: - Dobrý večer. Díky za zprávu. Mluvil jste o svém debuggeru, který spouští některé testovací transakce v produkci. Řekněte nám ale o testovacích transakcích! Jak hluboko to sahá?
EK: – Prochází celým cyklem celé součásti. U komponenty není žádný rozdíl mezi testovací transakcí a produkční transakcí. Ale z logického hlediska jde prostě o samostatný projekt v systému, na kterém se spouštějí pouze testovací transakce.
In: -Kde jsi to odřízl? Tady Core poslal...
EK: – V tomto případě jsme za „Kor“ u testovacích transakcí... Máme něco jako směrování: „Kor“ ví, do kterého platebního systému má poslat – pošleme do falešného platebního systému, který jednoduše vydá signál http a to je vše.
In: – Řekněte mi, prosím, byla vaše aplikace napsána v jednom obrovském monolitu, nebo jste ji rozřezal na nějaké služby či dokonce mikroslužby?
EK: – Nemáme monolit, samozřejmě, máme aplikaci orientovanou na služby. Děláme si legraci, že naše služba je tvořena monolity – ty jsou opravdu dost velké. Je těžké to nazvat mikroslužbami, ale jsou to služby, v rámci kterých pracují pracovníci distribuovaných strojů.
Pokud je služba na serveru kompromitována...
In: – Pak mám další otázku. I kdyby to byl monolit, stále jste řekl, že máte mnoho těchto instantních serverů, všechny v podstatě zpracovávají data a otázka zní: „V případě kompromitace jednoho z instantních serverů nebo aplikace jakýkoli jednotlivý odkaz , mají nějakou kontrolu přístupu? Co kdo z nich umí? Na koho se mám obrátit o jaké informace?
EK: - Ano, určitě. Bezpečnostní požadavky jsou poměrně vážné. Za prvé, máme otevřené pohyby dat a porty jsou pouze ty, přes které předem předpokládáme pohyb provozu. Pokud komponenta komunikuje s databází (řekněme s Muskulem) přes 5-4-3-2, bude pro ni otevřena pouze 5-4-3-2 a další porty a další směry provozu nebudou dostupné. Kromě toho musíte pochopit, že v naší produkci existuje asi 10 různých bezpečnostních smyček. A i kdyby byla aplikace nějak kompromitována, nedej bože, útočník nebude mít přístup ke konzole pro správu serveru, protože se jedná o jinou zónu zabezpečení sítě.In: – A v této souvislosti je pro mě zajímavější, že máte určité smlouvy se službami – co mohou dělat, jakými „akcemi“ se mohou navzájem kontaktovat... A v běžném toku některé konkrétní služby požadují nějaké řádek, seznam „akcí“ na druhém. Zdá se, že se v normální situaci neobracejí na ostatní a mají jiné oblasti odpovědnosti. Bude-li jeden z nich kompromitován, bude schopen narušit „akce“ této služby?...
EK: - Chápu. Pokud byla v normální situaci s jiným serverem vůbec komunikace povolena, pak ano. Podle smlouvy SLA nesledujeme, že máte povoleny pouze první 3 „akce“ a že nemáte povoleny 4 „akce“. To je pro nás asi nadbytečné, protože v zásadě pro obvody už máme 4stupňový ochranný systém. Raději se bráníme konturami, než na úrovni vnitřností.
Jak fungují Visa, MasterCard a Sberbank
In: – Chci objasnit bod týkající se přechodu uživatele z jednoho datového centra do druhého. Pokud vím, Visa a MasterCard fungují pomocí binárního synchronního protokolu 8583 a jsou tam směsi. A chtěl jsem vědět, teď máme na mysli přechod – je to přímo „Visa“ a „MasterCard“ nebo před platebními systémy, před zpracováním?
EK: - To je před mixem. Naše mixy jsou umístěny ve stejném datovém centru.
In: – Zhruba řečeno, máte jeden přípojný bod?
EK: – „Visa“ a „MasterCard“ – ano. Jednoduše proto, že Visa a MasterCard vyžadují poměrně vážné investice do infrastruktury k uzavření samostatných smluv například k získání druhého páru mixů. Jsou rezervované v rámci jednoho datového centra, ale pokud nám nedej bože zanikne naše datové centrum, kde jsou mixy pro připojení k Visa a MasterCard, tak budeme mít spojení s Visa a MasterCard ztraceno...
In: – Jak je lze zarezervovat? Vím, že Visa umožňuje v zásadě pouze jedno spojení!
EK: – Zařízení si dodávají sami. Každopádně jsme dostali výbavu, která je uvnitř plně nadbytečná.
In: – Takže stojan je z jejich Connects Orange?...
EK: - Ano.
In: – Ale co tento případ: pokud vaše datové centrum zmizí, jak je můžete dále používat? Nebo se prostě zastaví provoz?
EK: - Ne. V tomto případě jednoduše přepneme provoz na jiný kanál, což bude samozřejmě dražší pro nás a dražší pro naše klienty. Ale provoz nepůjde přes naše přímé napojení na Visa, MasterCard, ale přes podmíněnou Sberbank (velmi přehnané).
Velmi se omlouvám, pokud jsem urazil zaměstnance Sberbank. Ale podle našich statistik mezi ruskými bankami nejčastěji padá Sberbank. Neuplyne měsíc, aby ve Sberbank něco nespadlo.
Nějaké inzeráty 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com