HighLoad++, Evgeniy Kuzovlev (EcommPay IT): vad man ska göra när en minuts stillestånd kostar $100000 XNUMX

Alla pratar om processerna för utveckling och testning, utbildning av personal, ökad motivation, men dessa processer räcker inte när en minuts driftstopp kostar enorma summor pengar. Vad ska du göra när du utför finansiella transaktioner under en strikt SLA? Hur ökar man tillförlitligheten och feltoleransen för sina system, tar utveckling och testning ur ekvationen?

Nästa HighLoad++-konferens kommer att hållas den 6 och 7 april 2020 i St. Petersburg. Detaljer och biljetter till länk. 9 november, 18:00. HighLoad++ Moskva 2018, Delhi + Kolkata hall. Avhandlingar och presentation.

Evgeniy Kuzovlev (nedan – EC): - Vänner, hej! Jag heter Kuzovlev Evgeniy. Jag kommer från företaget EcommPay, en specifik division är EcommPay IT, företagsgruppens IT-avdelning. Och idag ska vi prata om stilleståndstider – om hur man undviker dem, om hur man minimerar deras konsekvenser om det inte kan undvikas. Ämnet anges enligt följande: "Vad ska man göra när en minuts stillestånd kostar $100 000"? När vi blickar framåt är våra siffror jämförbara.

Vad gör EkommPay IT?

Vilka är vi? Varför står jag här framför dig? Varför har jag rätt att berätta något här? Och vad ska vi prata om här mer i detalj?

EcommPay-företagsgruppen är en internationell förvärvare. Vi behandlar betalningar över hela världen - i Ryssland, Europa, Sydostasien (allt i världen). Vi har 9 kontor, totalt 500 anställda, och ungefär lite mindre än hälften av dem är IT-specialister. Allt vi gör, allt vi tjänar pengar på, gjorde vi själva.

Vi skrev alla våra produkter (och vi har ganska många av dem - i vårt sortiment av stora IT-produkter har vi cirka 16 olika komponenter) själva; Vi skriver själva, vi utvecklar oss själva. Och för tillfället genomför vi ungefär en miljon transaktioner om dagen (miljoner är förmodligen rätt sätt att säga det). Vi är ett ganska ungt företag - vi är bara cirka sex år gamla.

För 6 år sedan var det en sådan startup när killarna kom med verksamheten. De förenades av en idé (det fanns inget annat än en idé), och vi sprang. Som alla startuper sprang vi snabbare... För oss var snabbhet viktigare än kvalitet.

Vid något tillfälle slutade vi: vi insåg att vi på något sätt inte längre kunde leva i den hastigheten och med den kvaliteten och vi behövde fokusera på kvalitet först. Just nu bestämde vi oss för att skriva en ny plattform som skulle vara korrekt, skalbar och pålitlig. De började skriva den här plattformen (de började investera, utveckla utveckling, testa), men vid något tillfälle insåg de att utveckling och testning inte tillät oss att nå en ny nivå av servicekvalitet.

Du gör en ny produkt, du sätter den i produktion, men ändå kommer något att gå fel någonstans. Och idag ska vi prata om hur man når en ny kvalitetsnivå (hur vi gjorde det, om vår erfarenhet), ta utveckling och testning ur ekvationen; vi kommer att prata om vad som finns tillgängligt för drift - vad drift kan göra själv, vad det kan erbjuda att testa för att påverka kvaliteten.

Driftstopp. Driftbud.

Alltid den viktigaste hörnstenen, vad vi faktiskt kommer att prata om idag är driftstopp. Ett hemskt ord. Om vi ​​har stillestånd är allt dåligt för oss. Vi springer för att höja den, administratörerna håller servern - Gud förbjude att den inte faller, som de säger i den låten. Detta är vad vi kommer att prata om idag.

När vi började ändra vårt förhållningssätt, bildade vi 4 bud. Jag har dem presenterade på bilderna:

Dessa bud är ganska enkla:

• Identifiera problemet snabbt.
• Bli av med det ännu snabbare.
• Hjälp till att förstå orsaken (senare, för utvecklare).
• Och standardisera tillvägagångssätt.

Jag skulle vilja uppmärksamma er på punkt nr 2. Vi blir av med problemet, inte löser det. Att bestämma sig är sekundärt. För oss är det primära att användaren är skyddad från detta problem. Det kommer att finnas i någon isolerad miljö, men den här miljön kommer inte att ha någon kontakt med det. Egentligen kommer vi att gå igenom dessa fyra problemgrupper (några mer detaljerat, vissa i mindre detalj), jag kommer att berätta vad vi använder, vilken relevant erfarenhet vi har av lösningar.

Felsökning: När händer de och vad ska man göra åt dem?

Men vi börjar ur funktion, vi börjar med punkt nr 2 - hur blir man snabbt av med problemet? Det finns ett problem - vi måste åtgärda det. "Vad ska vi göra åt det här?" - huvudfrågan. Och när vi började fundera på hur vi skulle åtgärda problemet utvecklade vi för oss själva några krav som felsökning måste följa.

För att formulera dessa krav bestämde vi oss för att ställa oss själva frågan: ”När har vi problem”? Och problem, som det visade sig, uppstår i fyra fall:

• Maskinvarufel.
• Externa tjänster misslyckades.
• Ändra programversionen (samma distribution).
• Explosiv belastningstillväxt.

Vi ska inte prata om de två första. Ett hårdvarufel kan lösas helt enkelt: du måste ha allt duplicerat. Om dessa är diskar måste diskarna monteras i RAID; om detta är en server måste servern dupliceras; om du har en nätverksinfrastruktur måste du tillhandahålla en andra kopia av nätverksinfrastrukturen, det vill säga du tar den och duplicera det. Och om något misslyckas byter du till reservkraft. Det är svårt att säga något mer här.

Det andra är de externa tjänsternas misslyckande. För de flesta är systemet inget problem alls, men inte för oss. Eftersom vi behandlar betalningar är vi en aggregator som står mellan användaren (som anger hans kortdata) och banker, betalningssystem (Visa, MasterCard, Mira, etc.). Våra externa tjänster (betalningssystem, banker) tenderar att misslyckas. Varken vi eller du (om du har sådana tjänster) kan påverka detta.

Vad ska man göra då? Det finns två alternativ här. Först, om du kan, bör du duplicera den här tjänsten på något sätt. Till exempel, om vi kan, överför vi trafik från en tjänst till en annan: till exempel behandlades kort genom Sberbank, Sberbank har problem - vi överför trafik [villkorligt] till Raiffeisen. Det andra vi kan göra är att märka felet i externa tjänster mycket snabbt, och därför kommer vi att prata om svarshastighet i nästa del av rapporten.

Faktum är att av dessa fyra kan vi specifikt påverka förändringen av mjukvaruversioner - vidta åtgärder som kommer att leda till en förbättring av situationen i samband med utplaceringar och i samband med explosiv ökning av belastningen. Det var faktiskt vad vi gjorde. Här återigen en liten notis...

Av dessa fyra problem löses flera direkt om du har ett moln. Om du befinner dig i Microsoft Azhur-, Ozon-molnen, eller använder våra moln, från Yandex eller Mail, så blir åtminstone ett hårdvarufel deras problem och allt blir omedelbart bra för dig i samband med ett hårdvarufel.

Vi är ett lite okonventionellt företag. Här pratar alla om "Kubernets", om moln - vi har varken "Kubernets" eller moln. Men vi har rack med hårdvara i många datacenter, och vi är tvungna att leva på den här hårdvaran, vi tvingas ta ansvar för allt. Därför kommer vi att prata i detta sammanhang. Alltså om problemen. De två första togs ur parentes.

Ändra mjukvaruversionen. Baser

Våra utvecklare har inte tillgång till produktion. Varför är det så? Det är bara det att vi är PCI DSS-certifierade, och våra utvecklare har helt enkelt inte rätt att komma in i "produkten". Det är det, punkt. Alls. Därför upphör utvecklingsansvaret exakt i det ögonblick då utvecklingen lämnar in bygget för release.

Vår andra grund som vi har, som också hjälper oss mycket, är frånvaron av unik odokumenterad kunskap. Jag hoppas att det är samma sak för dig. För om så inte är fallet kommer du att få problem. Problem kommer att uppstå när denna unika, odokumenterade kunskap inte finns vid rätt tidpunkt på rätt plats. Låt oss säga att du har en person som vet hur man distribuerar en specifik komponent - personen är inte där, han är på semester eller är sjuk - det är det, du har problem.

Och den tredje grunden som vi har kommit till. Vi kom till det genom smärta, blod, tårar - vi kom fram till att alla våra byggen innehåller fel, även om den är felfri. Vi bestämde detta för oss själva: när vi distribuerar något, när vi rullar något i produktion, har vi en build med fel. Vi har format de krav som vårt system ska uppfylla.

Krav för att ändra mjukvaruversionen

Det finns tre krav:

• Vi måste snabbt rulla tillbaka utbyggnaden.
• Vi måste minimera effekten av en misslyckad implementering.
• Och vi måste snabbt kunna sätta in parallellt.
  Precis i den ordningen! Varför? För, först och främst, när du distribuerar en ny version är hastigheten inte viktig, men det är viktigt för dig, om något går fel, att snabbt rulla tillbaka och ha minimal påverkan. Men om du har en uppsättning versioner i produktion, för vilka det visar sig att det finns ett fel (av det blå, det fanns ingen distribution, men det finns ett fel) - hastigheten för efterföljande distribution är viktig för dig. Vad har vi gjort för att möta dessa krav? Vi använde oss av följande metod:

  
  
  Det är ganska välkänt, vi har aldrig uppfunnit det - det här är Blue/Green deploy. Vad det är? Du måste ha en kopia för varje grupp av servrar som dina applikationer är installerade på. Kopian är "varm": det finns ingen trafik på den, men när som helst kan denna trafik skickas till denna kopia. Detta exemplar innehåller den tidigare versionen. Och vid tidpunkten för implementering rullar du ut koden till en inaktiv kopia. Sedan byter du en del av trafiken (eller hela) till den nya versionen. Således, för att ändra trafikflödet från den gamla versionen till den nya, behöver du bara göra en åtgärd: du behöver ändra balanseringsanordningen i uppströms, ändra riktning - från en uppströms till en annan. Detta är mycket bekvämt och löser problemet med snabb växling och snabb återställning.

  Här är lösningen på den andra frågan minimering: du kan bara skicka en del av din trafik till en ny linje, till en linje med en ny kod (låt det vara t.ex. 2%). Och dessa 2% är inte 100%! Om du tappade 100 % av din trafik på grund av en misslyckad implementering är det skrämmande; om du tappade 2 % av din trafik är det obehagligt, men det är inte skrämmande. Dessutom kommer användare med största sannolikhet inte ens att märka detta, eftersom i vissa fall (inte i alla) samma användare, som trycker på F5, kommer att tas till en annan fungerande version.

  Blå/grön utplacering. Routing

  Allt är dock inte så enkelt "Blå/Grön deploy"... Alla våra komponenter kan delas in i tre grupper:

  • detta är frontend (betalningssidor som våra kunder ser);
  • bearbetning kärna;
  • adapter för att arbeta med betalningssystem (banker, MasterCard, Visa...).

  Och det finns en nyans här - nyansen ligger i routingen mellan linjerna. Om du bara byter till 100 % av trafiken har du inte dessa problem. Men om du vill byta 2 % börjar du ställa frågor: "Hur gör man det här?" Det enklaste är rakt fram: du kan ställa in Round Robin i nginx genom slumpmässiga val, och du har 2% till vänster, 98% till höger. Men detta är inte alltid lämpligt.

  Till exempel, i vårt fall, interagerar en användare med systemet med mer än en begäran. Detta är normalt: 2, 3, 4, 5 förfrågningar - dina system kan vara desamma. Och om det är viktigt för dig att alla användarens förfrågningar kommer till samma linje som den första förfrågan kom, eller (andra punkten) kommer alla användarens förfrågningar till den nya raden efter bytet (han kunde ha börjat arbeta tidigare med system, före bytet), - då är denna slumpmässiga distribution inte lämplig för dig. Sedan finns det följande alternativ:

  
  
  Det första alternativet, det enklaste, är baserat på klientens grundläggande parametrar (IP Hash). Du har en IP, och du delar den från höger till vänster efter IP-adress. Sedan kommer det andra fallet jag beskrev att fungera för dig, när implementeringen inträffade kunde användaren redan börja arbeta med ditt system, och från och med driftsättningsögonblicket kommer alla förfrågningar att gå till en ny rad (till samma rad, säg).

  Om detta av någon anledning inte passar dig och du måste skicka förfrågningar till den linje där användarens första, första förfrågan kom, så har du två alternativ...
  Första alternativet: du kan köpa betald nginx+. Det finns en Sticky sessions-mekanism, som på användarens första begäran tilldelar en session till användaren och binder den till en eller annan uppströms. Alla efterföljande användarförfrågningar inom sessionens livslängd kommer att skickas till samma uppströms där sessionen publicerades.

  Detta passade inte oss eftersom vi redan hade vanlig nginx. Att byta till nginx+ är inte att det är dyrt, det är bara att det var lite smärtsamt för oss och inte särskilt rätt. "Sticks Sessions", till exempel, fungerade inte för oss av den enkla anledningen att "Sticks Sessions" inte tillåter routing baserat på "Antingen-eller". Där kan du specificera vad vi "Sticks Sessions" gör, till exempel genom IP-adress eller med IP-adress och cookies eller med postparameter, men "Antingen-eller" är mer komplicerat där.

  Därför kom vi till det fjärde alternativet. Vi tog nginx på steroider (detta är openresty) - det här är samma nginx, som dessutom stöder införandet av de senaste skripten. Du kan skriva ett sista skript, ge det en "öppen vila", och det sista skriptet kommer att exekveras när användarens begäran kommer.

  Och vi skrev faktiskt ett sådant skript, satte oss "openresti" och i det här skriptet sorterar vi igenom 6 olika parametrar genom sammanlänkning "Eller". Beroende på närvaron av en eller annan parameter vet vi att användaren kom till en eller annan sida, en eller annan rad.

  Blå/grön utplacering. Fördelar och nackdelar

  Naturligtvis var det förmodligen möjligt att göra det lite enklare (använd samma "Sticky Sessions"), men vi har också en sådan nyans att inte bara användaren interagerar med oss ​​inom ramen för en bearbetning av en transaktion... Men betalningssystem interagerar också med oss: Efter att vi har behandlat transaktionen (genom att skicka en förfrågan till betalningssystemet) får vi en coolback.
  Och låt oss säga, om vi inuti vår krets kan vidarebefordra användarens IP-adress i alla förfrågningar och dela upp användare baserat på IP-adressen, då kommer vi inte att säga samma "Visa": "Dude, vi är ett sådant retroföretag, vi verkar att vara internationell (på webbplatsen och i Ryssland)... Vänligen ange användarens IP-adress i ett extra fält, ditt protokoll är standardiserat”! Det är klart att de inte kommer överens.

  
  
  Därför fungerade inte detta för oss – vi gjorde openresty. Följaktligen, med routing fick vi något så här:

  Blue/Green Deployment har följaktligen de fördelar som jag nämnde och nackdelar.

  Två nackdelar:

  • du behöver bry dig om routing;
  • den andra största nackdelen är kostnaden.

  Du behöver dubbelt så många servrar, du behöver dubbelt så många operativa resurser, du behöver lägga dubbelt så mycket ansträngning på att underhålla hela denna djurpark.

  Förresten, bland fördelarna finns det en sak till som jag inte har nämnt tidigare: du har en reserv vid lasttillväxt. Om du har en explosiv ökning av belastningen har du ett stort antal användare, då inkluderar du helt enkelt den andra raden i 50 till 50-distributionen – och du har direkt x2-servrar i ditt kluster tills du löser problemet med att ha fler servrar.

  Hur gör man en snabb implementering?

  Vi pratade om hur man löser problemet med minimering och snabb återställning, men frågan kvarstår: "Hur distribueras snabbt?"

  
  
  Det är kort och enkelt här.

  • Du måste ha ett CD-system (Continuous Delivery) - du kan inte leva utan det. Om du har en server kan du distribuera manuellt. Vi har ungefär ett och ett halvt tusen servrar och ett och ett halvt tusen handtag, naturligtvis - vi kan plantera en avdelning av storleken på det här rummet bara för att distribuera.
  • Utbyggnaden måste vara parallell. Om din distribution är sekventiell är allt dåligt. En server är normalt, du kommer att distribuera ett och ett halvt tusen servrar hela dagen.
  • Återigen, för acceleration är detta förmodligen inte längre nödvändigt. Under driftsättningen byggs projektet vanligtvis. Du har ett webbprojekt, det finns en front-end-del (du gör ett webbpaket där, du kompilerar npm - något sådant), och den här processen är i princip kortlivad - 5 minuter, men dessa 5 minuter kan vara kritisk. Det är därför vi till exempel inte gör det: vi tog bort dessa 5 minuter, vi distribuerar artefakter.

    Vad är en artefakt? En artefakt är en monterad byggnad där alla monteringsdelar redan har slutförts. Vi lagrar denna artefakt i artefaktförrådet. En gång använde vi två sådana lagringar - det var Nexus och nu jFrog Artifactory. Vi använde först "Nexus" eftersom vi började öva på detta tillvägagångssätt i java-applikationer (det passade det bra). Sedan lägger de in några av applikationerna skrivna i PHP där; och "Nexus" passade inte längre, och därför valde vi jFrog Artefactory, som kan artifaktisera nästan allt. Vi har till och med kommit till den punkten att vi i detta artefaktförråd lagrar våra egna binära paket som vi samlar in för servrar.

  Explosiv belastningstillväxt

  Vi pratade om att ändra mjukvaruversionen. Nästa sak vi har är en explosiv ökning av belastningen. Här menar jag förmodligen med explosiv tillväxt av lasten inte helt rätt...

  Vi skrev ett nytt system - det är serviceinriktat, moderiktigt, vackert, arbetare överallt, köer överallt, asynkront överallt. Och i sådana system kan data flöda genom olika flöden. För den första transaktionen kan den 1:a, 3:e, 10:e arbetaren användas, för den andra transaktionen - den 2:a, 4:e, 5:e. Och idag, låt oss säga, på morgonen har du ett dataflöde som använder de tre första arbetarna, och på kvällen förändras det dramatiskt, och allt använder de andra tre arbetarna.

  Och här visar det sig att du på något sätt behöver skala arbetarna, du måste på något sätt skala dina tjänster, men samtidigt förhindra resursuppsvällning.

  
  
  Vi har definierat våra krav. Dessa krav är ganska enkla: att det finns Service discovery, parametrisering - allt är standard för att bygga sådana skalbara system, förutom en punkt - resursavskrivning. Vi sa att vi inte är redo att amortera resurser så att servrarna värmer luften. Vi tog "Konsul", vi tog "Nomad", som sköter våra arbetare.

  Varför är detta ett problem för oss? Låt oss backa lite. Vi har nu ett 70-tal betalningssystem bakom oss. På morgonen går trafiken genom Sberbank, sedan föll till exempel Sberbank och vi byter till ett annat betalningssystem. Vi hade 100 anställda före Sberbank, och efter det måste vi kraftigt öka 100 anställda för ett annat betalningssystem. Och det är önskvärt att allt detta sker utan mänsklig medverkan. För om det finns mänskligt deltagande borde det finnas en ingenjör som sitter där 24/7, som bara borde göra detta, eftersom sådana misslyckanden, när 70 system är bakom dig, inträffar regelbundet.

  Därför tittade vi på Nomad, som har en öppen IP, och skrev vår egen grej, Scale-Nomad - ScaleNo, som gör ungefär följande: den övervakar köns tillväxt och minskar eller ökar antalet arbetare beroende på dynamiken av kön. När vi gjorde det tänkte vi: "Vi kanske kan öppna källkod?" Sedan tittade de på henne - hon var så enkel som två kopek.

  Hittills har vi inte öppna källkod, men om du plötsligt efter rapporten, efter att ha insett att du behöver något sådant, behöver det, mina kontakter finns i den sista bilden - skriv till mig. Om det är minst 3-5 personer så sponsrar vi det.

  
  
  Hur det fungerar? Låt oss ta en titt! Framöver: på vänster sida finns en del av vår övervakning: det här är en rad, överst är tiden för händelsebearbetning, i mitten är antalet transaktioner, längst ner är antalet arbetare.

  Om du tittar så finns det ett fel i den här bilden. På toppdiagrammet kraschade ett av diagrammen på 45 sekunder – ett av betalningssystemen gick ner. Omedelbart kom trafik in på 2 minuter och kön började växa på ett annat betalningssystem, där det inte fanns några arbetare (vi utnyttjade inte resurser - tvärtom, vi disponerade resursen korrekt). Vi ville inte värma - det fanns ett minimalt antal, cirka 5-10 arbetare, men de klarade sig inte.

  Den sista grafen visar en "puckel", vilket bara betyder att "Skaleno" fördubblade detta belopp. Och sedan, när grafen sjönk lite, minskade han den lite - antalet arbetare ändrades automatiskt. Det är så den här saken fungerar. Vi pratade om punkt nummer 2 - "Hur man snabbt blir av med skäl."

  Övervakning. Hur identifierar man snabbt problemet?

  Nu är den första punkten "Hur identifierar man snabbt problemet?" Övervakning! Vi måste förstå vissa saker snabbt. Vilka saker bör vi förstå snabbt?

  
  
  Tre saker!

  • Vi måste förstå och snabbt förstå hur våra egna resurser presterar.
  • Vi måste snabbt förstå fel och övervaka prestandan hos system som är externa för oss.
  • Den tredje punkten är att identifiera logiska fel. Det är då systemet fungerar för dig, allt är normalt enligt alla indikatorer, men något går fel.

  Jag kommer förmodligen inte att berätta något så coolt här. Jag blir Captain Obvious. Vi letade efter vad som fanns på marknaden. Vi har ett "roligt zoo". Det här är den sortens djurpark vi har nu:

  
  
  Vi använder Zabbix för att övervaka hårdvara, för att övervaka servrarnas huvudindikatorer. Vi använder Okmeter för databaser. Vi använder "Grafana" och "Prometheus" för alla andra indikatorer som inte passar de två första, några med "Grafana" och "Prometheus", och några med "Grafana" med "Influx" och Telegraf.

  För ett år sedan ville vi använda New Relic. Cool grej, den kan göra allt. Men så mycket hon kan göra allt så är hon så dyr. När vi växte till en volym på 1,5 tusen servrar kom en leverantör till oss och sa: "Låt oss ingå ett avtal för nästa år." Vi tittade på priset och sa nej, det kommer vi inte att göra. Nu överger vi New Relic, vi har cirka 15 servrar kvar under övervakning av New Relic. Priset visade sig vara helt vilt.

  Och det finns ett verktyg som vi implementerade själva - det här är Debugger. Först kallade vi det "Bagger", men sedan gick en engelsklärare förbi, skrattade vilt och döpte om det till "Debagger." Vad det är? Detta är ett verktyg som i själva verket på 15-30 sekunder på varje komponent, som en "svart låda" i systemet, kör tester på komponentens övergripande prestanda.

  Om det till exempel finns en extern sida (betalningssida) öppnar han den helt enkelt och tittar på hur den ska se ut. Om detta bearbetas skickar han en test "transaktion" och ser till att denna "transaktion" kommer fram. Om detta är en koppling till betalningssystem så avfyrar vi en testförfrågan i enlighet med detta, där vi kan, och ser att allt är bra med oss.

  Vilka indikatorer är viktiga för uppföljning?

  Vad bevakar vi främst? Vilka indikatorer är viktiga för oss?

  
  

  • Responstid / RPS på fronter är en mycket viktig indikator. Han svarar direkt att något är fel på dig.
  • Antalet behandlade meddelanden i alla köer.
  • Antal arbetare.
  • Grundläggande korrekthetsmått.

  Den sista punkten är "affär", "affärs"-mått. Om du vill övervaka samma sak måste du definiera en eller två mätvärden som är huvudindikatorerna för dig. Vårt mått är genomströmning (detta är förhållandet mellan antalet framgångsrika transaktioner och det totala transaktionsflödet). Om något ändras i den med ett intervall på 5-10-15 minuter betyder det att vi har problem (om det förändras radikalt).

  Hur det ser ut för oss är ett exempel på en av våra styrelser:

  
  
  På vänster sida finns 6 grafer, detta är enligt linjerna - antalet arbetare och antalet meddelanden i köerna. På höger sida - RPS, RTS. Nedan finns samma "affärs"-mått. Och i "affärs"-måttet kan vi omedelbart se att något gick fel i de två mittersta graferna... Detta är bara ytterligare ett system som står bakom oss som har fallit.

  Det andra vi var tvungna att göra var att övervaka de externa betalningssystemens fall. Här tog vi OpenTracing - en mekanism, standard, paradigm som låter dig spåra distribuerade system; och det ändrades lite. Standard OpenTracing-paradigmet säger att vi bygger ett spår för varje enskild begäran. Vi behövde inte detta, och vi slog in det i ett sammanfattande, aggregeringsspår. Vi gjorde ett verktyg som låter oss spåra hastigheten på systemen bakom oss.

  
  
  Grafen visar att ett av betalningssystemen började svara på 3 sekunder - vi har problem. Dessutom kommer den här saken att reagera när problemen börjar, med ett intervall på 20-30 sekunder.

  Och den tredje klassen av övervakningsfel som finns är logisk övervakning.

  För att vara ärlig så visste jag inte vad jag skulle rita på den här bilden, för vi hade länge letat på marknaden efter något som skulle passa oss. Vi hittade ingenting, så vi fick göra det själva.

  
  
  Vad menar jag med logisk övervakning? Tja, föreställ dig: du gör dig själv till ett system (till exempel en Tinder-klon); du gjorde det, lanserade det. Den framgångsrika chefen Vasya Pupkin satte den på sin telefon, ser en tjej där, gillar henne... och liknande går inte till tjejen - liknande går till säkerhetsvakten Mikhalych från samma affärscenter. Chefen går ner och undrar sedan: "Varför ler den här säkerhetsvakten Mikhalych så glatt mot honom?"

  I sådana situationer... För oss låter den här situationen lite annorlunda, eftersom (skrev jag) detta är en anseendeförlust som indirekt leder till ekonomiska förluster. Vår situation är den motsatta: vi kan drabbas av direkta ekonomiska förluster - till exempel om vi genomförde en transaktion som framgångsrik, men den var misslyckad (eller vice versa). Jag var tvungen att skriva ett eget verktyg som spårar antalet framgångsrika transaktioner över tid med hjälp av affärsindikatorer. Hittade inget på marknaden! Det var precis den idén jag ville förmedla. Det finns inget på marknaden för att lösa den här typen av problem.

  Det här handlade om hur man snabbt kunde identifiera problemet.

  Hur man bestämmer orsakerna till distributionen

  Den tredje gruppen av problem som vi löser är efter att vi har identifierat problemet, efter att vi blivit av med det, skulle det vara bra att förstå orsaken till utvecklingen, för att testa, och göra något åt ​​det. Därför måste vi undersöka, vi måste höja stockarna.

  
  
  Om vi ​​pratar om stockar (huvudorsaken är stockar), så finns huvuddelen av våra stockar i ELK Stack - nästan alla har samma. För vissa är det kanske inte i ELK, men om du skriver loggar i gigabyte så kommer du förr eller senare till ELK. Vi skriver dem i terabyte.

  
  
  Det finns ett problem här. Vi fixade det, rättade till felet för användaren, började gräva fram vad som fanns, klättrade in i Kibana, skrev in transaktions-id där och fick en sån här fotduk (visar mycket). Och absolut ingenting är klart i denna fotduk. Varför? Ja, eftersom det inte framgår vilken del som tillhör vilken arbetare, vilken del som tillhör vilken komponent. Och i det ögonblicket insåg vi att vi behövde spårning - samma OpenTracing som jag talade om.

  Vi trodde det här för ett år sedan, riktade vår uppmärksamhet mot marknaden och det fanns två verktyg där - "Zipkin" och "Jaeger". "Jager" är faktiskt en sådan ideologisk arvtagare, en ideologisk efterträdare till "Zipkin". Allt är bra i Zipkin, förutom att det inte vet hur man aggregerar, det vet inte hur man inkluderar loggar i spåret, bara tidsspårning. Och "Jager" stödde detta.

  Vi tittade på "Jager": du kan instrumentera applikationer, du kan skriva i Api (Api-standarden för PHP på den tiden godkändes dock inte - det här var ett år sedan, men nu är det redan godkänt), men där var absolut ingen kund. "Okej", tänkte vi och skrev till vår egen klient. Vad fick vi? Ungefär så här ser det ut:

  
  
  I Jaeger skapas spann för varje meddelande. Det vill säga när en användare öppnar systemet ser han ett eller två block för varje inkommande begäran (1-2-3 - antalet inkommande förfrågningar från användaren, antalet block). För att göra det enklare för användarna har vi lagt till taggar i loggarna och tidsspår. Följaktligen, i händelse av ett fel, kommer vår applikation att markera loggen med lämplig feltagg. Du kan filtrera efter Error-tagg och endast spann som innehåller detta block med ett fel kommer att visas. Så här ser det ut om vi utökar spann:

  
  
  Inne i spännet finns en uppsättning spår. I det här fallet är det tre testspår, och det tredje spåret talar om för oss att ett fel uppstod. Samtidigt ser vi här ett tidsspår: vi har en tidsskala överst, och vi ser vid vilket tidsintervall den eller den loggen registrerades.

  Därför gick det bra för oss. Vi skrev vårt eget tillägg och vi öppnade det. Om du vill arbeta med spårning, om du vill arbeta med "Jager" i PHP, finns vårt tillägg, välkommen att använda, som de säger:

  
  
  Vi har det här tillägget - det är en klient för OpenTracing Api, det är gjort som php-förlängning, det vill säga du måste montera det och installera det på systemet. För ett år sedan var det inget annorlunda. Nu finns det andra klienter som är som komponenter. Här är det upp till dig: antingen pumpar du ut komponenterna med en kompositör, eller så använder du förlängning upp till dig.

  Företagsstandarder

  Vi pratade om de tre buden. Det fjärde budet är att standardisera tillvägagångssätt. Vad handlar det här om? Det handlar om detta:

  
  
  Varför finns ordet "företag" här? Inte för att vi är ett stort eller byråkratiskt företag, nej! Jag ville använda ordet "företag" här i sammanhanget att varje företag, varje produkt bör ha sina egna standarder, inklusive du. Vilka standarder har vi?

  
  

  • Vi har utbyggnadsregler. Vi flyttar ingenstans utan honom, det kan vi inte. Vi sätter in cirka 60 gånger i veckan, det vill säga vi sätter in nästan konstant. Samtidigt har vi till exempel i insättningsbestämmelserna ett tabu om insatser på fredag ​​– i princip sätter vi inte in.
  • Vi kräver dokumentation. Inte en enda ny komponent kommer i produktion om det inte finns dokumentation för den, även om den föddes under pennan av våra RnD-specialister. Vi kräver av dem installationsinstruktioner, en övervakningskarta och en grov beskrivning (ja, som programmerare kan skriva) av hur den här komponenten fungerar, hur man felsöker den.
  • Vi löser inte orsaken till problemet, utan problemet - det jag redan har sagt. Det är viktigt för oss att skydda användaren från problem.
  • Vi har tillstånd. Vi anser till exempel inte att det är stillestånd om vi tappade 2 % av trafiken inom två minuter. Detta ingår i princip inte i vår statistik. Om det är mer procentuellt eller tillfälligt räknar vi redan.
  • Och vi skriver alltid obduktioner. Oavsett vad som händer med oss, kommer varje situation där någon betedde sig onormalt i produktionen att återspeglas i obduktionen. En obduktion är ett dokument där du skriver vad som hände dig, en detaljerad tidpunkt, vad du gjorde för att rätta till det och (detta är en obligatorisk spärr!) vad du kommer att göra för att förhindra att detta händer i framtiden. Detta är obligatoriskt och nödvändigt för efterföljande analys.

  Vad anses vara stillestånd?

  
  
  Vad ledde allt detta till?

  Detta ledde till att (vi hade vissa problem med stabiliteten, detta passade varken kunder eller oss) under de senaste 6 månaderna var vår stabilitetsindikator 99,97. Vi kan säga att detta inte är särskilt mycket. Ja, vi har något att sträva efter. Av denna indikator är ungefär hälften stabiliteten, så att säga, inte av vår, utan av vår webbapplikationsbrandvägg, som står framför oss och används som en tjänst, men kunderna bryr sig inte om detta.

  Vi lärde oss att sova på natten. Till sist! För sex månader sedan kunde vi inte. Och på den här lappen med resultatet, skulle jag vilja göra en anteckning. I går kväll kom ett underbart reportage om styrsystemet för en kärnreaktor. Om personerna som skrev det här systemet kan höra mig, vänligen glöm vad jag sa om "2% är inte driftstopp." För dig är 2 % stillestånd, även om det är två minuter!

  Det är allt! Dina frågor.

  
  

  Om balanserare och databasmigrering

  Fråga från publiken (nedan – B): – God kväll. Tack så mycket för en sådan adminrapport! En kort fråga om dina balansörer. Du nämnde att du har en WAF, det vill säga som jag förstår det använder du någon form av extern balanserare...

  EK: – Nej, vi använder våra tjänster som en balanserare. I det här fallet är WAF exklusivt ett DDoS-skyddsverktyg för oss.

  PÅ: – Kan du säga några ord om balanserare?

  EK: – Som jag redan sa, det här är en grupp servrar i openresty. Vi har nu 5 reservgrupper som svarar exklusivt... det vill säga en server som kör enbart openresty, den proxar bara trafik. Följaktligen, för att förstå hur mycket vi har: vi har nu ett regelbundet trafikflöde på flera hundra megabit. De klarar sig, de mår bra, de anstränger sig inte ens.

  PÅ: – Också en enkel fråga. Här är blå/grön implementering. Vad gör man till exempel med databasmigreringar?

  EK: - Bra fråga! Titta, i Blue/Green-distribution har vi separata köer för varje rad. Det vill säga, om vi pratar om händelseköer som överförs från arbetare till arbetare, finns det separata köer för den blå linjen och för den gröna linjen. Om vi ​​pratar om själva databasen, så har vi medvetet minskat den så mycket vi kunde, flyttat allt praktiskt taget till köer; i databasen lagrar vi bara en stapel med transaktioner. Och vår transaktionsstapel är densamma för alla linjer. Med databasen i detta sammanhang: vi delar inte upp den i blått och grönt, eftersom båda versionerna av koden måste veta vad som händer med transaktionen.

  Vänner, jag har också ett litet pris att sporra er - en bok. Och jag borde tilldelas den för den bästa frågan.

  PÅ: - Hallå. Tack för rapporten. Frågan är denna. Du övervakar betalningar, du övervakar de tjänster som du kommunicerar med... Men hur övervakar du så att en person på något sätt kom till din betalningssida, gjorde en betalning och projektet krediterade honom med pengar? Det vill säga, hur övervakar du att marchant är tillgänglig och har accepterat din callback?

  EK: – "Merchant" för oss är i detta fall exakt samma externa tjänst som betalningssystemet. Vi övervakar handlarens svarshastighet.

  Om databaskryptering

  PÅ: - Hallå. Jag har en lite relaterad fråga. Du har PCI DSS-känsliga data. Jag ville veta hur du lagrar PAN i köer som du behöver överföra till? Använder du någon kryptering? Och detta leder till den andra frågan: enligt PCI DSS är det nödvändigt att periodiskt omkryptera databasen vid ändringar (avskedande av administratörer, etc.) - vad händer med tillgängligheten i det här fallet?

  
  
  EK: – Underbar fråga! För det första lagrar vi inte PAN i köer. Vi har inte rätt att lagra PAN var som helst i tydlig form, i princip, så vi använder en speciell tjänst (vi kallar det "Kademon") - det här är en tjänst som bara gör en sak: den tar emot ett meddelande som input och skickar ut ett krypterat meddelande. Och vi lagrar allt med detta krypterade meddelande. Följaktligen är vår nyckellängd under en kilobyte, så att detta är seriöst och pålitligt.

  PÅ: – Behöver du 2 kilobyte nu?

  EK: – Det verkar som om det var 256 igår... Ja, var annars?!

  Följaktligen är detta den första. Och för det andra, lösningen som finns, den stöder omkrypteringsproceduren - det finns två par "keks" (nycklar), som ger "däck" som krypterar (nyckeln är nycklarna, dek är derivator av nycklarna som krypterar) . Och om proceduren initieras (det händer regelbundet, från 3 månader till ± några), laddar vi ner ett nytt par "kakor" och vi krypterar om data. Vi har separata tjänster som river ut all data och krypterar den på ett nytt sätt; Data lagras bredvid identifieraren för nyckeln med vilken den är krypterad. Följaktligen, så snart vi krypterar data med nya nycklar, tar vi bort den gamla nyckeln.

  Ibland måste betalningar göras manuellt...

  PÅ: – Det vill säga, om en återbetalning har kommit för någon operation, kommer du fortfarande att dekryptera den med den gamla nyckeln?

  EK: - Ja.

  PÅ: – Sedan en liten fråga till. När någon form av fel, fall eller incident inträffar är det nödvändigt att driva igenom transaktionen manuellt. Det finns en sådan situation.

  EK: - Ja ibland.

  PÅ: – Var får du dessa uppgifter ifrån? Eller går du själv till det här förrådet?

  EK: – Nej, visst, vi har något slags back-office-system som innehåller ett gränssnitt för vår support. Om vi ​​inte vet vilken status transaktionen har (till exempel tills betalningssystemet svarade med en timeout), vet vi inte på förhand, det vill säga att vi tilldelar slutstatus endast med fullt förtroende. I det här fallet tilldelar vi transaktionen en speciell status för manuell bearbetning. På morgonen, nästa dag, så snart supporten får information om att sådana och sådana transaktioner finns kvar i betalningssystemet, bearbetar de dem manuellt i detta gränssnitt.

  
  
  PÅ: – Jag har ett par frågor. En av dem är fortsättningen av PCI DSS-zonen: hur loggar du deras krets? Den här frågan beror på att utvecklaren kunde ha lagt vad som helst i loggarna! Andra frågan: hur rullar du ut snabbkorrigeringar? Att använda handtag i databasen är ett alternativ, men det kan finnas gratis snabbkorrigeringar - vad är proceduren där? Och den tredje frågan är förmodligen relaterad till RTO, RPO. Din tillgänglighet var 99,97, nästan fyra nior, men som jag förstår det har du ett andra datacenter, ett tredje datacenter och ett femte datacenter... Hur synkroniserar du dem, replikerar dem och allt annat?

  EK: – Låt oss börja med den första. Gällde den första frågan loggar? När vi skriver loggar har vi ett lager som maskerar all känslig data. Hon tittar på masken och på de ytterligare fälten. Följaktligen kommer våra loggar ut med redan maskerade data och en PCI DSS-krets. Detta är en av de vanliga uppgifterna som tilldelas testavdelningen. De måste kontrollera varje uppgift, inklusive loggarna som de skriver, och detta är en av de vanliga uppgifterna under kodgranskning, för att kontrollera att utvecklaren inte skrev ner något. Efterföljande kontroller av detta utförs regelbundet av informationssäkerhetsavdelningen ungefär en gång i veckan: loggar för den sista dagen tas selektivt och de körs genom en speciell skanner-analysator från testservrar för att kontrollera allt.
  Om hotfixar. Detta ingår i våra distributionsregler. Vi har en separat klausul om snabbkorrigeringar. Vi tror att vi distribuerar snabbkorrigeringar dygnet runt när vi behöver det. Så fort versionen är monterad, så fort den körs, så fort vi har en artefakt, har vi en systemadministratör i tjänst på ett samtal från supporten, och han distribuerar den i det ögonblick det är nödvändigt.

  Ungefär "fyra nior". Den siffra som vi har nu har verkligen uppnåtts, och vi strävade efter den i ett annat datacenter. Nu har vi ett andra datacenter, och vi börjar gå mellan dem, och frågan om replikering mellan datacenter är verkligen en icke-trivial fråga. Vi försökte lösa det på en gång med olika metoder: vi försökte använda samma "Tarantula" - det fungerade inte för oss, jag ska berätta omedelbart. Det var därför det slutade med att vi beställde "sens" manuellt. Faktum är att varje applikation i vårt system kör den nödvändiga "ändring - klar"-synkroniseringen mellan datacenter asynkront.

  PÅ: – Om du fick en andra, varför fick du inte en tredje? För ingen har split-brain ännu...

  EK: – Men vi har inte Split Brain. På grund av att varje applikation drivs av en multimaster spelar det ingen roll för oss vilket center förfrågan kom till. Vi är redo för det faktum att om ett av våra datacenter misslyckas (vi förlitar oss på detta) och mitt i en användarförfrågan byter till det andra datacentret, är vi beredda att förlora denna användare, verkligen; men dessa kommer att vara enheter, absoluta enheter.

  PÅ: - God kväll. Tack för rapporten. Du pratade om din debugger, som kör några testtransaktioner i produktionen. Men berätta om testtransaktioner! Hur djupt går det?

  EK: – Den går igenom hela cykeln för hela komponenten. För en komponent är det ingen skillnad mellan en testtransaktion och en produktionstransaktion. Men från en logisk synvinkel är detta helt enkelt ett separat projekt i systemet, på vilket endast testtransaktioner körs.

  PÅ: -Var skär du av den? Här skickade Core...

  EK: – Vi ligger bakom “Kor” i det här fallet för testtransaktioner... Vi har en sådan sak som routing: “Kor” vet vilket betalningssystem vi ska skicka till - vi skickar till ett falskt betalningssystem som helt enkelt ger en http-signal och det är allt.

  PÅ: – Säg mig, snälla, var din ansökan skriven i en stor monolit, eller skar du den i några tjänster eller till och med mikrotjänster?

  EK: – Vi har ingen monolit, naturligtvis, vi har en serviceinriktad applikation. Vi skämtar om att vår tjänst är gjord av monoliter - de är egentligen ganska stora. Det är svårt att kalla det mikrotjänster, men det här är tjänster inom vilka arbetare på distribuerade maskiner verkar.

  Om tjänsten på servern äventyras...

  PÅ: – Då har jag nästa fråga. Även om det vore en monolit, sa du fortfarande att du har många av dessa direktservrar, de bearbetar alla i princip data, och frågan är: "I händelse av en kompromiss med en av instantservrarna eller en applikation, varje enskild länk , har de någon form av åtkomstkontroll? Vem av dem kan göra vad? Vem ska jag kontakta för vilken information?

  
  
  EK: - Ja definitivt. Säkerhetskraven är ganska allvarliga. För det första har vi öppna datarörelser, och portarna är bara de som vi förutser trafikrörelser genom i förväg. Om en komponent kommunicerar med databasen (säg, med Muskul) via 5-4-3-2, kommer endast 5-4-3-2 att vara öppen för den, och andra hamnar och andra trafikriktningar kommer inte att vara tillgängliga. Dessutom måste du förstå att det i vår produktion finns ett 10-tal olika säkerhetsslingor. Och även om applikationen på något sätt äventyras, Gud förbjude, kommer angriparen inte att kunna komma åt serverhanteringskonsolen, eftersom detta är en annan nätverkssäkerhetszon.

  PÅ: – Och i det här sammanhanget, det som är mer intressant för mig är att man har vissa kontrakt med tjänster - vad de kan göra, genom vilka "åtgärder" de kan kontakta varandra... Och i ett normalt flöde kräver vissa specifika tjänster några rad, en lista med "åtgärder" på den andra. De verkar inte vända sig till andra i en normal situation, och de har andra ansvarsområden. Om en av dem äventyras, kommer den att kunna störa tjänstens "åtgärder"?

  EK: - Jag förstår. Om i en normal situation med en annan server kommunikation alls var tillåten, så ja. Enligt SLA-kontraktet övervakar vi inte att du endast tillåts de första 3 "åtgärderna", och du tillåts inte de 4 "åtgärderna". Detta är förmodligen överflödigt för oss, eftersom vi redan har ett 4-nivås skyddssystem, i princip, för kretsar. Vi föredrar att försvara oss med konturerna, snarare än på insidans nivå.

  Hur Visa, MasterCard och Sberbank fungerar

  PÅ: – Jag vill förtydliga en punkt om att byta en användare från ett datacenter till ett annat. Så vitt jag vet använder Visa och MasterCard det binära synkrona protokollet 8583, och det finns blandningar där. Och jag ville veta, nu menar vi byte – är det direkt "Visa" och "MasterCard" eller före betalningssystem, innan bearbetning?

  EK: – Det här är före blandningarna. Våra mixar finns i samma datacenter.

  PÅ: – Grovt sett, har du en anslutningspunkt?

  EK: – “Visa” och “MasterCard” - ja. Helt enkelt för att Visa och MasterCard kräver ganska seriösa investeringar i infrastruktur för att sluta separata kontrakt för att till exempel få ett andra par mixar. De är reserverade inom ett datacenter, men om, gud förbjude, vårt datacenter, där det finns blandningar för att ansluta till Visa och MasterCard, dör, kommer vi att förlora en anslutning med Visa och MasterCard...

  PÅ: – Hur kan de reserveras? Jag vet att Visa endast tillåter en anslutning i princip!

  EK: – De levererar utrustningen själva. Vi fick i alla fall utrustning som är helt redundant inuti.

  PÅ: – Så stativet är från deras Connects Orange?..

  EK: - Ja.

  PÅ: – Men hur är det med det här fallet: om ditt datacenter försvinner, hur kan du fortsätta använda det? Eller stannar trafiken bara?

  EK: - Nej. I det här fallet kommer vi helt enkelt att byta trafik till en annan kanal, vilket naturligtvis kommer att bli dyrare för oss och dyrare för våra kunder. Men trafiken kommer inte att gå via vår direkta anslutning till Visa, MasterCard, utan genom den villkorade Sberbank (mycket överdrivet).

  Jag ber vilt om ursäkt om jag förolämpade Sberbank-anställda. Men enligt vår statistik, bland de ryska bankerna, faller Sberbank oftast. Det går inte en månad utan att något faller av på Sberbank.

  
  
  

  Några annonser 🙂

  Tack för att du stannar hos oss. Gillar du våra artiklar? Vill du se mer intressant innehåll? Stöd oss ​​genom att lägga en beställning eller rekommendera till vänner, moln VPS för utvecklare från $4.99, en unik analog av ingångsservrar, som uppfanns av oss för dig: Hela sanningen om VPS (KVM) E5-2697 v3 (6 kärnor) 10GB DDR4 480GB SSD 1Gbps från $19 eller hur delar man en server? (tillgänglig med RAID1 och RAID10, upp till 24 kärnor och upp till 40 GB DDR4).

  Dell R730xd 2 gånger billigare i Equinix Tier IV datacenter i Amsterdam? Bara här 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV från $199 i Nederländerna! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - från $99! Läs om Hur man bygger infrastructure corp. klass med användning av Dell R730xd E5-2650 v4-servrar värda 9000 XNUMX euro för en slant?

Källa: will.com