HighLoad++, Evgeniy Kuzovlev (EcommPay IT): hvad skal man gøre, når et minuts nedetid koster $100000

Alle taler om processer med udvikling og test, uddannelse af personale, øget motivation, men disse processer er ikke nok, når et minuts nedetid koster enorme mængder penge. Hvad skal du gøre, når du udfører finansielle transaktioner under en streng SLA? Hvordan øger du pålideligheden og fejltolerancen af ​​dine systemer, tager udvikling og test ud af ligningen?

Den næste HighLoad++ konference afholdes den 6. og 7. april 2020 i St. Petersborg. Detaljer og billetter til link. 9. november klokken 18. HighLoad++ Moskva 00, Delhi + Kolkata hall. Specialer og præsentation.

Evgeniy Kuzovlev (i det følgende – EF): - Venner, hej! Mit navn er Kuzovlev Evgeniy. Jeg er fra EcommPay-virksomheden, en specifik division er EcommPay IT, IT-afdelingen i gruppen af ​​virksomheder. Og i dag vil vi tale om nedetider – om hvordan man undgår dem, om hvordan man minimerer deres konsekvenser, hvis det ikke kan undgås. Emnet er angivet som følger: "Hvad skal man gøre, når et minuts nedetid koster 100 $"? Ser vi fremad, er vores tal sammenlignelige.

Hvad laver EkommPay IT?

Hvem er vi? Hvorfor står jeg her foran dig? Hvorfor har jeg ret til at fortælle dig noget her? Og hvad vil vi tale mere om her?

EcommPay-koncernen er en international indløser. Vi behandler betalinger over hele verden - i Rusland, Europa, Sydøstasien (hele verden). Vi har 9 kontorer, 500 ansatte i alt, og omkring lidt under halvdelen af ​​dem er it-specialister. Alt hvad vi gør, alt hvad vi tjener penge på, gjorde vi selv.

Vi har selv skrevet alle vores produkter (og vi har ret mange af dem - i vores serie af store it-produkter har vi omkring 16 forskellige komponenter); Vi skriver selv, vi udvikler os selv. Og i øjeblikket udfører vi omkring en million transaktioner om dagen (millioner er nok den rigtige måde at sige det på). Vi er en ret ung virksomhed - vi er kun omkring seks år.

For 6 år siden var det sådan en startup, da fyrene kom sammen med virksomheden. De blev forenet af en idé (der var ikke andet end en idé), og vi løb. Som enhver startup løb vi hurtigere... For os var hastighed vigtigere end kvalitet.

På et tidspunkt stoppede vi: vi indså, at vi på en eller anden måde ikke længere kunne leve med den hastighed og med den kvalitet, og vi var nødt til at fokusere på kvalitet først. I dette øjeblik besluttede vi at skrive en ny platform, der ville være korrekt, skalerbar og pålidelig. De begyndte at skrive denne platform (de begyndte at investere, udvikle udvikling, teste), men på et tidspunkt indså de, at udvikling og test ikke tillod os at nå et nyt niveau af servicekvalitet.

Man laver et nyt produkt, man sætter det i produktion, men alligevel vil noget gå galt et sted. Og i dag vil vi tale om, hvordan man når et nyt kvalitetsniveau (hvordan vi gjorde det, om vores erfaring), tager udvikling og test ud af ligningen; vi vil tale om, hvad der er tilgængeligt for drift - hvad drift kan gøre selv, hvad det kan tilbyde at teste for at påvirke kvaliteten.

Nedetider. Driftsbud.

Altid hovedhjørnestenen, det vi faktisk vil tale om i dag er nedetid. Et frygteligt ord. Hvis vi har nedetid, er alt dårligt for os. Vi løber for at hæve den, administratorerne holder serveren - Gud forbyde den ikke falder, som de siger i den sang. Det er det, vi vil tale om i dag.

Da vi begyndte at ændre vores tilgange, dannede vi 4 bud. Jeg har dem præsenteret på slides:

Disse bud er ret enkle:

• Identificer hurtigt problemet.
• Slip af med det endnu hurtigere.
• Hjælp med at forstå årsagen (senere for udviklere).
• Og standardisere tilgange.

Jeg vil gerne henlede din opmærksomhed på punkt nr. 2. Vi slipper af med problemet, ikke løser det. Beslutningen er sekundær. For os er det primære, at brugeren er beskyttet mod dette problem. Det vil eksistere i et isoleret miljø, men dette miljø vil ikke have nogen kontakt med det. Faktisk vil vi gennemgå disse fire grupper af problemer (nogle mere detaljeret, nogle i mindre detaljer), jeg vil fortælle dig, hvad vi bruger, hvilken relevant erfaring vi har i løsninger.

Fejlfinding: Hvornår sker de, og hvad skal man gøre ved dem?

Men vi starter ude af drift, vi starter med punkt nr. 2 - hvordan slipper man hurtigt af med problemet? Der er et problem - vi skal løse det. "Hvad skal vi gøre ved dette?" - hovedspørgsmålet. Og da vi begyndte at tænke på, hvordan vi skulle løse problemet, udviklede vi til os selv nogle krav, som fejlfinding skal følge.

For at formulere disse krav besluttede vi at stille os selv spørgsmålet: "Hvornår har vi problemer"? Og problemer, som det viste sig, opstår i fire tilfælde:

• Hardwarefejl.
• Eksterne tjenester mislykkedes.
• Ændring af softwareversionen (samme installation).
• Eksplosiv belastningsvækst.

Vi vil ikke tale om de to første. En hardwarefejl kan løses ganske enkelt: du skal have alt duplikeret. Hvis disse er diske, skal diskene samles i RAID; hvis dette er en server, skal serveren duplikeres; hvis du har en netværksinfrastruktur, skal du levere en anden kopi af netværksinfrastrukturen, det vil sige, du tager den og duplikere det. Og hvis noget fejler, skifter du til reservestrøm. Det er svært at sige mere her.

Det andet er fejlen i eksterne tjenester. For de fleste er systemet slet ikke et problem, men ikke for os. Da vi behandler betalinger, er vi en aggregator, der står mellem brugeren (som indtaster sine kortdata) og banker, betalingssystemer (Visa, MasterCard, Mira osv.). Vores eksterne tjenester (betalingssystemer, banker) har en tendens til at fejle. Hverken vi eller du (hvis du har sådanne tjenester) kan påvirke dette.

Hvad skal man så gøre? Der er to muligheder her. For det første, hvis du kan, bør du duplikere denne service på en eller anden måde. For eksempel, hvis vi kan, overfører vi trafik fra en tjeneste til en anden: for eksempel blev kort behandlet gennem Sberbank, Sberbank har problemer - vi overfører trafik [betinget] til Raiffeisen. Den anden ting, vi kan gøre, er at bemærke fejlen i eksterne tjenester meget hurtigt, og derfor vil vi tale om responshastighed i næste del af rapporten.

Faktisk kan vi af disse fire specifikt påvirke ændringen af ​​softwareversioner - tage handlinger, der vil føre til en forbedring af situationen i forbindelse med udrulninger og i forbindelse med eksplosiv vækst i belastningen. Det var faktisk det, vi gjorde. Her igen en lille bemærkning...

Af disse fire problemer løses flere med det samme, hvis du har en sky. Hvis du er i Microsoft Azhur, Ozon-skyerne eller bruger vores skyer fra Yandex eller Mail, så bliver i det mindste en hardwarefejl deres problem, og alt bliver straks fint for dig i forbindelse med en hardwarefejl.

Vi er en lidt utraditionel virksomhed. Her taler alle om "Kubernets", om skyer - vi har hverken "Kubernets" eller skyer. Men vi har racks af hardware i mange datacentre, og vi er tvunget til at leve af denne hardware, vi er tvunget til at stå til ansvar for det hele. Derfor vil vi tale i denne sammenhæng. Altså om problemerne. De to første blev taget ud af parentes.

Ændring af softwareversion. Baser

Vores udviklere har ikke adgang til produktion. Hvorfor det? Det er bare, at vi er PCI DSS certificeret, og vores udviklere har simpelthen ikke ret til at komme ind i "produktet". Det var det, punktum. Overhovedet. Derfor ophører udviklingsansvaret præcis i det øjeblik, hvor udviklingen sender buildet til frigivelse.

Vores andet grundlag, som vi har, som også hjælper os meget, er fraværet af unik udokumenteret viden. Jeg håber, det er det samme for dig. For hvis det ikke er tilfældet, får du problemer. Problemer vil opstå, når denne unikke, udokumenterede viden ikke er til stede på det rigtige tidspunkt på det rigtige sted. Lad os sige, at du har én person, der ved, hvordan man implementerer en bestemt komponent - personen er der ikke, han er på ferie eller er syg - det er det, du har problemer.

Og det tredje grundlag, som vi er kommet til. Vi kom til det gennem smerte, blod, tårer - vi kom til den konklusion, at enhver af vores builds indeholder fejl, selvom den er fejlfri. Vi besluttede dette for os selv: når vi implementerer noget, når vi ruller noget i produktion, har vi en build med fejl. Vi har dannet de krav, som vores system skal opfylde.

Krav til ændring af softwareversionen

Der er tre krav:

• Vi skal hurtigt rulle implementeringen tilbage.
• Vi skal minimere virkningen af ​​en mislykket implementering.
• Og vi skal hurtigt kunne indsætte parallelt.
  Præcis i den rækkefølge! Hvorfor? For først og fremmest, når du implementerer en ny version, er hastighed ikke vigtig, men det er vigtigt for dig, hvis noget går galt, hurtigt at rulle tilbage og have minimal indflydelse. Men hvis du har et sæt versioner i produktion, for hvilke det viser sig, at der er en fejl (ud af det blå, der var ingen implementering, men der er en fejl) - hastigheden af ​​den efterfølgende implementering er vigtig for dig. Hvad har vi gjort for at imødekomme disse krav? Vi har brugt følgende metode:

  
  
  Det er ret velkendt, vi har aldrig opfundet det - dette er Blue/Green deploy. Hvad er det? Du skal have en kopi for hver gruppe af servere, som dine applikationer er installeret på. Kopien er "varm": der er ingen trafik på den, men denne trafik kan til enhver tid sendes til denne kopi. Denne kopi indeholder den tidligere version. Og på tidspunktet for implementeringen ruller du koden ud til en inaktiv kopi. Så skifter du en del af trafikken (eller hele) til den nye version. For at ændre trafikstrømmen fra den gamle version til den nye skal du således kun gøre én handling: du skal ændre balanceren i opstrøms, ændre retningen - fra en opstrøm til en anden. Dette er meget praktisk og løser problemet med hurtig skift og hurtig tilbagerulning.

  Her er løsningen på det andet spørgsmål minimering: du kan kun sende en del af din trafik til en ny linje, til en linje med en ny kode (lad det f.eks. være 2%). Og disse 2% er ikke 100%! Hvis du mistede 100 % af din trafik på grund af en mislykket implementering, er det skræmmende; hvis du mistede 2 % af din trafik, er det ubehageligt, men det er ikke skræmmende. Desuden vil brugere højst sandsynligt ikke engang bemærke dette, for i nogle tilfælde (ikke i alle) vil den samme bruger, der trykker på F5, blive ført til en anden, fungerende version.

  Blå/grøn udrulning. Routing

  Men ikke alt er så simpelt "Blå/Grøn udrulning"... Alle vores komponenter kan opdeles i tre grupper:

  • dette er frontend (betalingssider, som vores kunder ser);
  • forarbejdning kerne;
  • adapter til at arbejde med betalingssystemer (banker, MasterCard, Visa...).

  Og der er en nuance her - nuancen ligger i ruten mellem linjerne. Hvis du bare skifter 100% af trafikken, har du ikke disse problemer. Men hvis du vil skifte 2 %, begynder du at stille spørgsmål: "Hvordan gør man det?" Det enkleste er lige frem: du kan opsætte Round Robin i nginx ved tilfældigt valg, og du har 2% til venstre, 98% til højre. Men dette er ikke altid passende.

  For eksempel, i vores tilfælde, interagerer en bruger med systemet med mere end én anmodning. Dette er normalt: 2, 3, 4, 5 anmodninger - dine systemer kan være de samme. Og hvis det er vigtigt for dig, at alle brugerens anmodninger kommer til den samme linje, som den første anmodning kom på, eller (andet punkt) kommer alle brugerens anmodninger til den nye linje efter skiftet (han kunne være begyndt at arbejde tidligere med system, før skiftet), - så er denne tilfældige fordeling ikke egnet for dig. Så er der følgende muligheder:

  
  
  Den første mulighed, den enkleste, er baseret på klientens grundlæggende parametre (IP Hash). Du har en IP, og du deler den fra højre mod venstre efter IP-adresse. Så vil det andet tilfælde, jeg beskrev, fungere for dig, når implementeringen fandt sted, kunne brugeren allerede begynde at arbejde med dit system, og fra tidspunktet for implementeringen vil alle anmodninger gå til en ny linje (til den samme, f.eks.).

  Hvis dette af en eller anden grund ikke passer dig, og du skal sende anmodninger til den linje, hvor brugerens oprindelige, første anmodning kom, så har du to muligheder...
  Første mulighed: du kan købe betalt nginx+. Der er en Sticky session-mekanisme, som efter brugerens første anmodning tildeler en session til brugeren og binder den til en eller anden opstrøms. Alle efterfølgende brugeranmodninger inden for sessionens levetid vil blive sendt til den samme upstream, hvor sessionen blev sendt.

  Dette passede ikke os, fordi vi allerede havde almindelig nginx. At skifte til nginx+ er ikke, at det er dyrt, det er bare, at det var noget smertefuldt for os og ikke rigtigt. "Sticks Sessions", for eksempel, fungerede ikke for os af den simple grund, at "Sticks Sessions" ikke tillader routing baseret på "Enten-eller". Der kan du angive, hvad vi "Sticks Sessions" gør, for eksempel ved IP-adresse eller ved IP-adresse og cookies eller ved postparameter, men "Enten-eller" er mere kompliceret der.

  Derfor kom vi til den fjerde mulighed. Vi tog nginx på steroider (dette er openresty) - dette er den samme nginx, som desuden understøtter inklusion af sidste scripts. Du kan skrive et sidste script, give det en "åben pause", og dette sidste script vil blive udført, når brugerens anmodning kommer.

  Og vi skrev faktisk sådan et script, satte os selv "openresti", og i dette script sorterer vi gennem 6 forskellige parametre ved sammenkædning af "Eller". Afhængigt af tilstedeværelsen af ​​en eller anden parameter ved vi, at brugeren kom til en eller anden side, en eller anden linje.

  Blå/grøn udrulning. Fordele og ulemper

  Selvfølgelig var det nok muligt at gøre det lidt enklere (brug de samme "Sticky Sessions"), men vi har også en sådan nuance, at ikke kun brugeren interagerer med os inden for rammerne af én behandling af én transaktion... Men betalingssystemer interagerer også med os: Efter at vi har behandlet transaktionen (ved at sende en anmodning til betalingssystemet), modtager vi en coolback.
  Og lad os sige, hvis vi inde i vores kredsløb kan videresende brugerens IP-adresse i alle anmodninger og opdele brugere baseret på IP-adressen, så vil vi ikke fortælle det samme "Visa": "Dude, vi er sådan en retro-virksomhed, det ser ud til at at være international (på hjemmesiden og i Rusland)... Giv os venligst brugerens IP-adresse i et ekstra felt, din protokol er standardiseret”! Det er klart, at de ikke bliver enige.

  
  
  Derfor virkede dette ikke for os - vi lavede openresty. Følgelig fik vi med routing noget som dette:

  Blue/Green Deployment har derfor de fordele, som jeg nævnte, og ulemper.

  To ulemper:

  • du er nødt til at genere routing;
  • den anden største ulempe er udgiften.

  Du har brug for dobbelt så mange servere, du har brug for dobbelt så mange driftsressourcer, du skal bruge dobbelt så mange kræfter på at vedligeholde hele denne zoologiske have.

  Blandt fordelene er der i øvrigt en ting mere, som jeg ikke har nævnt før: du har en reserve i tilfælde af belastningsvækst. Har du en eksplosiv vækst i belastningen, har du et stort antal brugere, så inddrager du blot den anden linje i 50 til 50 distributionen – og du har straks x2 servere i din klynge, indtil du løser problemet med at have flere servere.

  Hvordan laver man en hurtig implementering?

  Vi talte om, hvordan man løser problemet med minimering og hurtig tilbagerulning, men spørgsmålet er stadig: "Hvordan implementeres hurtigt?"

  
  
  Det er kort og enkelt her.

  • Du skal have et cd-system (kontinuerlig levering) - du kan ikke leve uden det. Hvis du har én server, kan du implementere manuelt. Vi har omkring halvandet tusinde servere og halvandet tusinde håndtag, selvfølgelig - vi kan plante en afdeling på størrelse med dette rum, bare for at implementere.
  • Udbredelsen skal være parallel. Hvis din implementering er sekventiel, så er alt dårligt. Én server er normalt, du vil implementere halvanden tusinde servere hele dagen.
  • Igen, for acceleration er dette sandsynligvis ikke længere nødvendigt. Under implementeringen bygges projektet normalt. Du har et webprojekt, der er en frontend del (du laver en webpakke der, du kompilerer npm - sådan noget), og denne proces er i princippet kortvarig - 5 minutter, men disse 5 minutter kan være kritisk. Det er derfor, vi for eksempel ikke gør det: Vi fjernede disse 5 minutter, vi implementerer artefakter.

    Hvad er en artefakt? Et artefakt er en samlet bygning, hvor alle monteringsdelene allerede er afsluttet. Vi opbevarer denne artefakt i artefaktlageret. På et tidspunkt brugte vi to sådanne lagringspladser - det var Nexus og nu jFrog Artifactory. Vi brugte oprindeligt "Nexus", fordi vi begyndte at praktisere denne tilgang i java-applikationer (det passede godt til det). Så lægger de nogle af de programmer, der er skrevet i PHP derind; og “Nexus” var ikke længere egnet, og derfor valgte vi jFrog Artefactory, som kan artifaktorisere næsten alt. Vi er endda kommet til det punkt, at vi i dette artefaktlager gemmer vores egne binære pakker, som vi indsamler til servere.

  Eksplosiv belastningsvækst

  Vi talte om at ændre softwareversionen. Det næste, vi har, er en eksplosiv stigning i belastningen. Her mener jeg nok med eksplosiv vækst af lasten ikke helt det rigtige...

  Vi skrev et nyt system - det er serviceorienteret, moderigtigt, smukt, arbejdere overalt, køer overalt, asynkront overalt. Og i sådanne systemer kan data flyde gennem forskellige flows. Til den første transaktion kan den 1., 3., 10. arbejder bruges, til den anden transaktion - den 2., 4., 5. Og i dag, lad os sige, om morgenen har du et dataflow, der bruger de første tre arbejdere, og om aftenen ændrer det sig dramatisk, og alt bruger de tre andre arbejdere.

  Og her viser det sig, at du på en eller anden måde skal skalere arbejderne, du skal på en eller anden måde skalere dine tjenester, men samtidig forhindre ressourceoppustethed.

  
  
  Vi har defineret vores krav. Disse krav er ret enkle: at der er Service discovery, parameterisering - alt er standard for at bygge sådanne skalerbare systemer, bortset fra et punkt - ressourceafskrivning. Vi sagde, at vi ikke er klar til at amortisere ressourcer, så serverne opvarmer luften. Vi tog "Konsul", vi tog "Nomad", som styrer vores arbejdere.

  Hvorfor er dette et problem for os? Lad os gå lidt tilbage. Vi har nu omkring 70 betalingssystemer bag os. Om morgenen går trafikken gennem Sberbank, så faldt Sberbank for eksempel, og vi skifter den til et andet betalingssystem. Vi havde 100 arbejdere før Sberbank, og derefter skal vi øge 100 medarbejdere kraftigt til et andet betalingssystem. Og det er ønskeligt, at alt dette sker uden menneskelig deltagelse. For hvis der er menneskelig deltagelse, burde der sidde en ingeniør 24/7, som kun skulle gøre dette, fordi sådanne fejl, når 70 systemer er bag dig, sker jævnligt.

  Derfor kiggede vi på Nomad, som har en åben IP, og skrev vores egen ting, Scale-Nomad - ScaleNo, som gør omtrent følgende: den overvåger væksten i køen og reducerer eller øger antallet af arbejdere afhængigt af dynamikken af køen. Da vi gjorde det, tænkte vi: "Måske kan vi open source det?" Så kiggede de på hende – hun var så simpel som to kopek.

  Indtil videre har vi ikke open source det, men hvis du pludselig efter rapporten, efter at have indset, at du har brug for sådan noget, har brug for det, er mine kontakter i det sidste slide - så skriv til mig. Er der mindst 3-5 personer, sponsorerer vi det.

  
  
  Hvordan det virker? Lad os tage et kig! Ser vi fremad: på venstre side er der en del af vores overvågning: dette er en linje, øverst er tidspunktet for hændelsesbehandlingen, i midten er antallet af transaktioner, nederst er antallet af arbejdere.

  Hvis du ser, er der en fejl i dette billede. På det øverste diagram styrtede et af diagrammerne ned på 45 sekunder – et af betalingssystemerne gik ned. Straks blev der bragt trafik ind på 2 minutter og køen begyndte at vokse på et andet betalingssystem, hvor der ingen arbejdere var (vi udnyttede ikke ressourcer - tværtimod disponerede vi ressourcen korrekt). Vi ville ikke varme - der var et minimalt antal, omkring 5-10 arbejdere, men de kunne ikke klare det.

  Den sidste graf viser en "pukkel", hvilket blot betyder, at "Skaleno" fordoblede dette beløb. Og så, da grafen faldt lidt, reducerede han den lidt - antallet af arbejdere blev automatisk ændret. Det er sådan den her ting fungerer. Vi talte om punkt nummer 2 - "Sådan slipper du hurtigt af med årsager."

  Overvågning. Hvordan identificerer man hurtigt problemet?

  Nu er det første punkt "Hvordan identificerer man hurtigt problemet?" Overvågning! Vi skal hurtigt forstå visse ting. Hvilke ting skal vi hurtigt forstå?

  
  
  Tre ting!

  • Vi skal forstå og hurtigt forstå vores egne ressourcers ydeevne.
  • Vi skal hurtigt forstå fejl og overvåge ydeevnen af ​​systemer, der er eksterne for os.
  • Det tredje punkt er at identificere logiske fejl. Det er, når systemet fungerer for dig, alt er normalt ifølge alle indikatorer, men noget går galt.

  Jeg vil nok ikke fortælle dig noget så fedt her. Jeg bliver Captain Obvious. Vi ledte efter, hvad der var på markedet. Vi har en "sjov zoo". Dette er den slags zoo, vi har nu:

  
  
  Vi bruger Zabbix til at overvåge hardware, til at overvåge de vigtigste indikatorer på servere. Vi bruger Okmeter til databaser. Vi bruger "Grafana" og "Prometheus" til alle andre indikatorer, der ikke passer til de to første, nogle med "Grafana" og "Prometheus", og nogle med "Grafana" med "Influx" og Telegraf.

  For et år siden ville vi bruge New Relic. Fed ting, den kan alt. Men så meget som hun kan alt, så er hun så dyr. Da vi voksede til et volumen på 1,5 tusinde servere, kom en leverandør til os og sagde: "Lad os indgå en aftale for næste år." Vi kiggede på prisen og sagde nej, det gør vi ikke. Nu forlader vi New Relic, vi har omkring 15 servere tilbage under overvågning af New Relic. Prisen viste sig at være helt vild.

  Og der er et værktøj, som vi selv implementerede - dette er Debugger. Først kaldte vi det "Bagger", men så gik en engelsklærer forbi, grinede vildt og omdøbte det til "Debagger". Hvad er det? Dette er et værktøj, der faktisk på 15-30 sekunder på hver komponent, ligesom en "sort boks" af systemet, kører test af komponentens overordnede ydeevne.

  Hvis der for eksempel er en ekstern side (betalingsside), åbner han den blot og ser på, hvordan den skal se ud. Hvis dette behandles, sender han en test "transaktion" og sørger for, at denne "transaktion" ankommer. Hvis dette er en forbindelse med betalingssystemer, affyrer vi en testanmodning i overensstemmelse hermed, hvor vi kan, og ser, at alt er i orden hos os.

  Hvilke indikatorer er vigtige for overvågning?

  Hvad overvåger vi primært? Hvilke indikatorer er vigtige for os?

  
  

  • Responstid / RPS på fronter er en meget vigtig indikator. Han svarer straks, at der er noget galt med dig.
  • Antallet af behandlede beskeder i alle køer.
  • Antal arbejdere.
  • Grundlæggende korrekthedsmålinger.

  Det sidste punkt er "business", "business" metrisk. Hvis du vil overvåge det samme, skal du definere en eller to målinger, der er hovedindikatorerne for dig. Vores metrik er gennemløb (dette er forholdet mellem antallet af vellykkede transaktioner og det samlede transaktionsflow). Hvis noget ændrer sig i det med et interval på 5-10-15 minutter, betyder det, at vi har problemer (hvis det ændrer sig radikalt).

  Hvordan det ser ud for os er et eksempel på en af ​​vores bestyrelser:

  
  
  På venstre side er der 6 grafer, dette er i henhold til linjerne - antallet af arbejdere og antallet af beskeder i køerne. På højre side – RPS, RTS. Nedenfor er den samme "forretnings"-metrik. Og i "business" metrikken kan vi med det samme se, at noget gik galt i de to midterste grafer... Dette er blot endnu et system, der står bag os, der er faldet.

  Den anden ting, vi skulle gøre, var at overvåge faldet af eksterne betalingssystemer. Her tog vi OpenTracing - en mekanisme, standard, paradigme, der giver dig mulighed for at spore distribuerede systemer; og det blev ændret lidt. Standard OpenTracing-paradigmet siger, at vi bygger et spor for hver enkelt anmodning. Vi havde ikke brug for dette, og vi pakkede det ind i et sammenfattende, aggregeringsspor. Vi lavede et værktøj, der giver os mulighed for at spore hastigheden af ​​systemerne bag os.

  
  
  Grafen viser os, at et af betalingssystemerne begyndte at reagere på 3 sekunder - vi har problemer. Desuden vil denne ting reagere, når problemer begynder, med et interval på 20-30 sekunder.

  Og den tredje klasse af overvågningsfejl, der findes, er logisk overvågning.

  For at være ærlig vidste jeg ikke, hvad jeg skulle tegne på denne slide, for vi havde længe ledt på markedet efter noget, der ville passe til os. Vi fandt ikke noget, så vi måtte selv gøre det.

  
  
  Hvad mener jeg med logisk overvågning? Tja, forestil dig: du laver dig selv et system (for eksempel en Tinder-klon); du lavede det, lancerede det. Den succesfulde manager Vasya Pupkin satte den på sin telefon, ser en pige der, kan lide hende ... og lignende går ikke til pigen - lignende går til sikkerhedsvagten Mikhalych fra det samme forretningscenter. Lederen går nedenunder, og spørger sig så: "Hvorfor smiler denne sikkerhedsvagt Mikhalych så behageligt til ham?"

  I sådanne situationer... For os lyder denne situation lidt anderledes, for (skrev jeg) er der tale om et omdømmetab, der indirekte fører til økonomiske tab. Vores situation er den modsatte: Vi kan lide direkte økonomiske tab - for eksempel hvis vi gennemførte en transaktion som vellykket, men den var mislykket (eller omvendt). Jeg var nødt til at skrive mit eget værktøj, der sporer antallet af vellykkede transaktioner over tid ved hjælp af forretningsindikatorer. Fandt ikke noget på markedet! Det var præcis den idé, jeg ville formidle. Der er intet på markedet til at løse denne form for problemer.

  Dette handlede om, hvordan man hurtigt kunne identificere problemet.

  Sådan bestemmes årsagerne til implementering

  Den tredje gruppe af problemer, som vi løser, er efter vi har identificeret problemet, efter at vi er sluppet af med det, ville det være godt at forstå årsagen til udviklingen, for at teste, og gøre noget ved det. Derfor er vi nødt til at undersøge, vi er nødt til at hæve logfilerne.

  
  
  Hvis vi taler om logs (hovedårsagen er logs), er hovedparten af ​​vores logs i ELK Stack - næsten alle har det samme. For nogle er det måske ikke i ELK, men hvis du skriver logs i gigabyte, så kommer du før eller siden til ELK. Vi skriver dem i terabyte.

  
  
  Der er et problem her. Vi rettede det, rettede fejlen for brugeren, begyndte at grave i, hvad der var der, klatrede ind i Kibana, indtastede transaktions-id'et der og fik denne fodklud (viser meget). Og absolut intet er klart i denne fodklud. Hvorfor? Ja, fordi det ikke er klart, hvilken del der tilhører hvilken arbejder, hvilken del der tilhører hvilken komponent. Og i det øjeblik indså vi, at vi havde brug for sporing - den samme OpenTracing, som jeg talte om.

  Vi troede dette for et år siden, vendte vores opmærksomhed mod markedet, og der var to værktøjer der - "Zipkin" og "Jaeger". "Jager" er faktisk sådan en ideologisk arving, en ideologisk efterfølger af "Zipkin". Alt er godt i Zipkin, bortset fra, at det ikke ved, hvordan man aggregerer, det ved ikke, hvordan man inkluderer logfiler i sporet, kun tidsspor. Og "Jager" støttede dette.

  Vi kiggede på “Jager”: du kan instrumentere applikationer, du kan skrive i Api (Api-standarden for PHP på det tidspunkt blev dog ikke godkendt - det var et år siden, men nu er den allerede godkendt), men der var absolut ingen klient. "Okay," tænkte vi og skrev vores egen klient. Hvad fik vi? Sådan ser det nogenlunde ud:

  
  
  I Jaeger oprettes spænd for hver besked. Det vil sige, at når en bruger åbner systemet, ser han en eller to blokke for hver indkommende anmodning (1-2-3 - antallet af indkommende anmodninger fra brugeren, antallet af blokke). For at gøre det nemmere for brugerne har vi tilføjet tags til loggene og tidsspor. I tilfælde af en fejl vil vores applikation derfor markere loggen med det relevante fejlmærke. Du kan filtrere efter Error tag og kun spænd, der indeholder denne blok med en fejl, vil blive vist. Sådan ser det ud, hvis vi udvider spændvidden:

  
  
  Inde i spændet er der et sæt spor. I dette tilfælde er der tale om tre testspor, og det tredje spor fortæller os, at der opstod en fejl. Samtidig ser vi her et tidsspor: vi har en tidsskala øverst, og vi ser med hvilket tidsinterval den eller den log blev optaget.

  Derfor gik det godt for os. Vi skrev vores egen udvidelse, og vi åbnede den. Hvis du vil arbejde med sporing, hvis du vil arbejde med "Jager" i PHP, er der vores udvidelse, velkommen til at bruge, som man siger:

  
  
  Vi har denne udvidelse - det er en klient til OpenTracing Api, den er lavet som php-udvidelse, det vil sige, at du skal samle den og installere den på systemet. For et år siden var der ikke noget anderledes. Nu er der andre klienter, der ligner komponenter. Her er det op til dig: enten pumper du komponenterne ud med en komponist, eller også bruger du udvidelse op til dig.

  Virksomhedsstandarder

  Vi talte om de tre bud. Det fjerde bud er at standardisere tilgange. Hvad drejer det sig om? Det handler om dette:

  
  
  Hvorfor er ordet "virksomhed" her? Ikke fordi vi er en stor eller bureaukratisk virksomhed, nej! Jeg ønskede at bruge ordet "virksomhed" her i den sammenhæng, at enhver virksomhed, hvert produkt skal have sine egne standarder, inklusive dig. Hvilke standarder har vi?

  
  

  • Vi har indsættelsesregler. Vi flytter ingen steder uden ham, det kan vi ikke. Vi udsender cirka 60 gange om ugen, det vil sige, at vi udsender næsten konstant. Samtidig har vi fx i udsendelsesreglementet et tabu om udsendelser om fredagen - vi udsender i princippet ikke.
  • Vi kræver dokumentation. Ikke en eneste ny komponent kommer i produktion, hvis der ikke er dokumentation for det, selvom det er født under pennen af ​​vores RnD-specialister. Vi kræver fra dem installationsinstruktioner, et overvågningskort og en grov beskrivelse (som programmører kan skrive) af, hvordan denne komponent fungerer, hvordan man fejlfinder den.
  • Vi løser ikke årsagen til problemet, men problemet - hvad jeg allerede sagde. Det er vigtigt for os at beskytte brugeren mod problemer.
  • Vi har tilladelser. For eksempel betragter vi det ikke som nedetid, hvis vi mistede 2 % af trafikken inden for to minutter. Dette er som udgangspunkt ikke inkluderet i vores statistik. Hvis det er mere i procent eller midlertidigt, tæller vi allerede.
  • Og vi skriver altid ligsyn. Uanset hvad der sker med os, vil enhver situation, hvor nogen opførte sig unormalt i produktionen, blive afspejlet i obduktionen. En postmortem er et dokument, hvor du skriver, hvad der skete med dig, en detaljeret timing, hvad du gjorde for at rette det og (dette er en obligatorisk blokering!), hvad du vil gøre for at forhindre, at dette sker i fremtiden. Dette er obligatorisk og nødvendigt for efterfølgende analyse.

  Hvad betragtes som nedetid?

  
  
  Hvad førte alt dette til?

  Dette førte til, at (vi havde visse problemer med stabiliteten, det passede ikke hverken kunder eller os) i løbet af de sidste 6 måneder var vores stabilitetsindikator 99,97. Vi kan sige, at det ikke er særlig meget. Ja, vi har noget at stræbe efter. Af denne indikator er omkring halvdelen stabiliteten, som det var, ikke af vores, men af ​​vores webapplikations firewall, som står foran os og bruges som en service, men kunderne er ligeglade med dette.

  Vi lærte at sove om natten. Endelig! For seks måneder siden kunne vi ikke. Og på dette notat med resultaterne vil jeg gerne lave en note. I går aftes var der en vidunderlig rapport om kontrolsystemet til en atomreaktor. Hvis de mennesker, der har skrevet dette system, kan høre mig, så glem hvad jeg sagde om "2 % er ikke nedetid." For dig er 2 % nedetid, selvom det er i to minutter!

  Det er alt! Dine spørgsmål.

  
  

  Om balancere og databasemigrering

  Spørgsmål fra salen (herefter – B): – Godaften. Mange tak for sådan en administratorrapport! Et kort spørgsmål om dine balancere. Du nævnte, at du har en WAF, det vil sige, som jeg forstår det, du bruger en form for ekstern balancer...

  EK: – Nej, vi bruger vores tjenester som en balancer. I dette tilfælde er WAF udelukkende et DDoS-beskyttelsesværktøj for os.

  I: – Kan du sige et par ord om balancere?

  EK: – Som jeg allerede har sagt, er dette en gruppe servere i openresty. Vi har nu 5 reservegrupper som udelukkende reagerer... altså en server der udelukkende kører openresty, den proxerer kun trafik. Derfor, for at forstå, hvor meget vi har: vi har nu en regelmæssig trafikstrøm på flere hundrede megabit. De klarer sig, de har det godt, de anstrenger sig ikke engang.

  I: – Også et simpelt spørgsmål. Her er blå/grøn udrulning. Hvad gør du for eksempel med databasemigreringer?

  EK: - Godt spørgsmål! Se, i Blue/Green-implementering har vi separate køer for hver linje. Det vil sige, at hvis vi taler om begivenhedskøer, der overføres fra arbejder til arbejder, er der separate køer til den blå linje og til den grønne linje. Hvis vi taler om selve databasen, så har vi bevidst indsnævret den så meget som vi kunne, flyttede alt praktisk talt ind i køer; i databasen gemmer vi kun en stak transaktioner. Og vores transaktionsstak er den samme for alle linjer. Med databasen i denne sammenhæng: vi deler den ikke op i blå og grøn, fordi begge versioner af koden skal vide, hvad der sker med transaktionen.

  Venner, jeg har også en lille præmie at anspore jer til - en bog. Og jeg skulle tildeles den for det bedste spørgsmål.

  I: - Hej. Tak for rapporten. Spørgsmålet er dette. Du overvåger betalinger, du overvåger de tjenester, du kommunikerer med... Men hvordan overvåger du, så en person på en eller anden måde kom til din betalingsside, foretog en betaling, og projektet krediterede ham med penge? Det vil sige, hvordan overvåger du, at marchanten er tilgængelig og har accepteret dit tilbagekald?

  EK: – "Forhandler" er for os i dette tilfælde nøjagtig den samme eksterne service som betalingssystemet. Vi overvåger forretningens responshastighed.

  Om databasekryptering

  I: - Hej. Jeg har et lidt relateret spørgsmål. Du har PCI DSS-følsomme data. Jeg ville gerne vide, hvordan du gemmer PAN'er i køer, som du skal overføre til? Bruger du nogen kryptering? Og dette fører til det andet spørgsmål: ifølge PCI DSS er det nødvendigt at periodisk genkryptere databasen i tilfælde af ændringer (afskedigelse af administratorer osv.) - hvad sker der med tilgængelighed i dette tilfælde?

  
  
  EK: - Vidunderligt spørgsmål! For det første gemmer vi ikke PAN'er i køer. Vi har i princippet ikke ret til at gemme PAN overalt i klar form, så vi bruger en speciel tjeneste (vi kalder den "Kademon") - dette er en tjeneste, der kun gør én ting: den modtager en besked som input og sender ud af en krypteret besked. Og vi gemmer alt med denne krypterede besked. Derfor er vores nøglelængde under en kilobyte, så dette er seriøst og pålideligt.

  I: – Har du brug for 2 kilobyte nu?

  EK: – Det lader til, at det lige i går var 256... Nå, hvor ellers?!

  Derfor er dette den første. Og for det andet, den løsning, der findes, den understøtter genkrypteringsproceduren - der er to par "keks" (nøgler), som giver "dæk", der krypterer (nøgler er nøglerne, dek er afledte nøgler, der krypterer) . Og hvis proceduren påbegyndes (det sker regelmæssigt, fra 3 måneder til ± nogle), downloader vi et nyt par "kager", og vi krypterer dataene igen. Vi har separate tjenester, der river alle data ud og krypterer dem på en ny måde; Dataene gemmes ved siden af ​​identifikatoren for den nøgle, som den er krypteret med. Så snart vi krypterer dataene med nye nøgler, sletter vi derfor den gamle nøgle.

  Nogle gange skal betalinger foretages manuelt...

  I: – Det vil sige, hvis der er kommet en refusion for en eller anden operation, vil du så stadig dekryptere den med den gamle nøgle?

  EK: - Ja.

  I: – Så et lille spørgsmål mere. Når der opstår en form for fejl, fald eller hændelse, er det nødvendigt at skubbe transaktionen igennem manuelt. Der er sådan en situation.

  EK: - Ja, nogle gange.

  I: – Hvor får du disse data fra? Eller går du selv til dette lager?

  EK: – Nej, ja, selvfølgelig har vi en form for back-office-system, der indeholder en grænseflade til vores support. Hvis vi ikke ved, hvilken status transaktionen har (f.eks. indtil betalingssystemet svarede med en timeout), ved vi ikke på forhånd, det vil sige, at vi kun tildeler den endelige status med fuld tillid. I dette tilfælde tildeler vi transaktionen en særlig status til manuel behandling. Om morgenen, den næste dag, så snart support modtager information om, at sådanne og sådanne transaktioner forbliver i betalingssystemet, behandler de dem manuelt i denne grænseflade.

  
  
  I: – Jeg har et par spørgsmål. En af dem er fortsættelsen af ​​PCI DSS-zonen: hvordan logger du deres kredsløb? Dette spørgsmål skyldes, at udvikleren kunne have lagt hvad som helst i logfilerne! Andet spørgsmål: hvordan udruller du hotfixes? Brug af håndtag i databasen er én mulighed, men der kan være gratis hot-fixes - hvad er proceduren der? Og det tredje spørgsmål er sandsynligvis relateret til RTO, RPO. Din tilgængelighed var 99,97, næsten fire niere, men som jeg forstår det, har du et andet datacenter, et tredje datacenter og et femte datacenter... Hvordan synkroniserer du dem, replikerer dem og alt muligt andet?

  EK: - Lad os starte med den første. Var det første spørgsmål om logs? Når vi skriver logs, har vi et lag, der maskerer alle følsomme data. Hun ser på masken og på de ekstra felter. Derfor kommer vores logfiler ud med allerede maskerede data og et PCI DSS-kredsløb. Dette er en af ​​de faste opgaver, der tildeles testafdelingen. De er forpligtet til at tjekke hver opgave, inklusive de logfiler, de skriver, og dette er en af ​​de almindelige opgaver under kodegennemgange, for at kontrollere, at udvikleren ikke har skrevet noget ned. Efterfølgende kontroller af dette udføres regelmæssigt af informationssikkerhedsafdelingen cirka en gang om ugen: logs for den sidste dag tages selektivt, og de køres gennem en speciel scanner-analyzer fra testservere for at kontrollere alt.
  Om hotfixes. Dette er inkluderet i vores implementeringsregler. Vi har en separat klausul om hotfixes. Vi tror på, at vi implementerer hotfixes døgnet rundt, når vi har brug for det. Så snart versionen er samlet, så snart den er kørt, så snart vi har en artefakt, har vi en systemadministrator på vagt på et opkald fra support, og han implementerer det i det øjeblik, det er nødvendigt.

  Omkring "fire niere". Det tal, vi har nu, er virkelig nået, og vi stræbte efter det i et andet datacenter. Nu har vi et andet datacenter, og vi begynder at rute mellem dem, og spørgsmålet om replikering på tværs af datacentre er virkelig et ikke-trivielt spørgsmål. Vi forsøgte at løse det på én gang ved hjælp af forskellige midler: vi forsøgte at bruge den samme "Tarantula" - det lykkedes ikke for os, jeg vil fortælle dig med det samme. Derfor endte vi med at bestille "sens" manuelt. Faktisk kører hver applikation i vores system den nødvendige "ændring - udført" synkronisering mellem datacentre asynkront.

  I: – Hvis du fik en anden, hvorfor fik du så ikke en tredje? Fordi ingen har split-brain endnu...

  EK: - Men vi har ikke Split Brain. På grund af det faktum, at hver ansøgning er drevet af en multimaster, er det lige meget for os, hvilket center anmodningen kom til. Vi er klar til, at hvis et af vores datacentre svigter (vi stoler på dette) og midt i en brugeranmodning skifter til det andet datacenter, er vi klar til at miste denne bruger. men disse vil være enheder, absolutte enheder.

  I: - God aften. Tak for rapporten. Du talte om din debugger, som kører nogle testtransaktioner i produktionen. Men fortæl os om testtransaktioner! Hvor dybt går det?

  EK: – Den gennemgår hele komponentens cyklus. For en komponent er der ingen forskel mellem en testtransaktion og en produktionstransaktion. Men fra et logisk synspunkt er dette blot et separat projekt i systemet, hvor der kun køres testtransaktioner.

  I: - Hvor skærer du det af? Her sendte Core...

  EK: – Vi står bag “Kor” i dette tilfælde til testtransaktioner... Vi har sådan noget som routing: “Kor” ved hvilket betalingssystem der skal sendes til - vi sender til et falsk betalingssystem, som blot giver et http-signal og det er alt.

  I: – Fortæl mig venligst, var din ansøgning skrevet i en stor monolit, eller skar du den op i nogle tjenester eller endda mikrotjenester?

  EK: - Vi har ikke en monolit, selvfølgelig, vi har en serviceorienteret applikation. Vi spøger med, at vores service er lavet af monolitter - de er egentlig ret store. Det er svært at kalde det mikrotjenester, men det er tjenester, inden for hvilke arbejdere på distribuerede maskiner opererer.

  Hvis tjenesten på serveren er kompromitteret...

  I: – Så har jeg det næste spørgsmål. Selvom det var en monolit, sagde du stadig, at du har mange af disse instant-servere, de behandler alle grundlæggende data, og spørgsmålet er: "I tilfælde af et kompromittering af en af ​​instant-serverne eller en applikation, ethvert individuelt link , har de en form for adgangskontrol? Hvem af dem kan hvad? Hvem skal jeg kontakte for hvilke oplysninger?

  
  
  EK: - Ja helt sikkert. Sikkerhedskravene er ret alvorlige. For det første har vi åbne databevægelser, og havnene er kun dem, som vi på forhånd forudser trafikbevægelser igennem. Hvis en komponent kommunikerer med databasen (f.eks. med Muskul) via 5-4-3-2, vil kun 5-4-3-2 være åben for den, og andre havne og andre trafikretninger vil ikke være tilgængelige. Derudover skal du forstå, at der i vores produktion er omkring 10 forskellige sikkerhedssløjfer. Og selvom applikationen på en eller anden måde blev kompromitteret, gud forbyde, vil angriberen ikke være i stand til at få adgang til serverstyringskonsollen, fordi dette er en anden netværkssikkerhedszone.

  I: – Og i denne sammenhæng er det mere interessant for mig, at man har bestemte kontrakter med tjenester - hvad de kan gøre, gennem hvilke "handlinger" de kan kontakte hinanden... Og i et normalt flow, kræver nogle specifikke tjenester nogle række, en liste over "handlinger" på den anden. De ser ikke ud til at henvende sig til andre i en normal situation, og de har andre ansvarsområder. Hvis en af ​​dem er kompromitteret, vil den så være i stand til at forstyrre den tjenestes "handlinger"?

  EK: - Jeg forstår. Hvis det i en normal situation med en anden server overhovedet var tilladt, så ja. I henhold til SLA-kontrakten overvåger vi ikke, at du kun må de første 3 "handlinger", og du har ikke lov til de 4 "handlinger". Dette er sandsynligvis overflødigt for os, fordi vi allerede har et 4-niveau beskyttelsessystem, i princippet, til kredsløb. Vi foretrækker at forsvare os med konturerne, frem for på niveau med indersiden.

  Sådan fungerer Visa, MasterCard og Sberbank

  I: – Jeg vil gerne præcisere en pointe om at skifte en bruger fra et datacenter til et andet. Så vidt jeg ved, opererer Visa og MasterCard ved hjælp af den 8583 binære synkrone protokol, og der er blandinger der. Og jeg ville vide, nu mener vi at skifte - er det direkte "Visa" og "MasterCard" eller før betalingssystemer, før behandling?

  EK: - Det her er før blandingerne. Vores mix er placeret i samme datacenter.

  I: – Har du groft sagt ét tilslutningspunkt?

  EK: – “Visa” og “MasterCard” - ja. Simpelthen fordi Visa og MasterCard kræver ganske seriøse investeringer i infrastruktur for at indgå separate kontrakter for for eksempel at få et andet par blandinger. De er reserveret inden for ét datacenter, men hvis gud forbyde vores datacenter, hvor der er blandinger til at forbinde til Visa og MasterCard, dør, så vil vi have en forbindelse med Visa og MasterCard mistet...

  I: – Hvordan kan de reserveres? Jeg ved, at Visa kun tillader én forbindelse i princippet!

  EK: – De leverer selv udstyret. Vi har i hvert fald modtaget udstyr, der er fuldt redundant indeni.

  I: – Så standen er fra deres Connects Orange?..

  EK: - Ja.

  I: – Men hvad med denne sag: Hvis dit datacenter forsvinder, hvordan kan du så fortsætte med at bruge det? Eller stopper trafikken bare?

  EK: - Nej. I dette tilfælde skifter vi blot trafikken til en anden kanal, hvilket naturligvis vil være dyrere for os og dyrere for vores kunder. Men trafikken vil ikke gå gennem vores direkte forbindelse til Visa, MasterCard, men gennem den betingede Sberbank (meget overdrevet).

  Jeg undskylder vildt, hvis jeg fornærmede Sberbank-medarbejdere. Men ifølge vores statistik falder Sberbank oftest blandt de russiske banker. Der går ikke en måned, uden at noget falder af hos Sberbank.

  
  
  

  Nogle annoncer 🙂

  Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, cloud VPS for udviklere fra $4.99, en unik analog af entry-level servere, som blev opfundet af os til dig: Hele sandheden om VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps fra $19 eller hvordan deler man en server? (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).

  Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV fra $199 i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om Hvordan man bygger infrastruktur corp. klasse med brug af Dell R730xd E5-2650 v4-servere til en værdi af 9000 euro for en krone?

Kilde: www.habr.com