HighLoad++, Evgeniy Kuzovlev (EcommPay IT): hva du skal gjøre når et minutt med nedetid koster $100000 XNUMX

Alle snakker om prosessene med utvikling og testing, opplæring av personalet, økende motivasjon, men disse prosessene er ikke nok når et minutt med nedetid koster enorme summer. Hva skal du gjøre når du utfører finansielle transaksjoner under en streng SLA? Hvordan øke påliteligheten og feiltoleransen til systemene dine, ta utvikling og testing ut av ligningen?

Den neste HighLoad++-konferansen holdes 6. og 7. april 2020 i St. Petersburg. Detaljer og billetter til link. 9. november, 18:00. HighLoad++ Moskva 2018, Delhi + Kolkata hall. Avhandlinger og presentasjon.

Evgeniy Kuzovlev (heretter – EM): - Venner, hei! Mitt navn er Kuzovlev Evgeniy. Jeg er fra EcommPay-selskapet, en spesifikk divisjon er EcommPay IT, IT-avdelingen til gruppen av selskaper. Og i dag skal vi snakke om nedetider - om hvordan man unngår dem, om hvordan man kan minimere konsekvensene hvis det ikke kan unngås. Emnet er oppgitt som følger: "Hva skal jeg gjøre når et minutt med nedetid koster $100 000"? Ser vi fremover er tallene våre sammenlignbare.

Hva gjør EkommPay IT?

Hvem er vi? Hvorfor står jeg her foran deg? Hvorfor har jeg rett til å fortelle deg noe her? Og hva skal vi snakke mer om her?

EcommPay-gruppen av selskaper er en internasjonal innkjøper. Vi behandler betalinger over hele verden - i Russland, Europa, Sørøst-Asia (hele verden). Vi har 9 kontorer, 500 ansatte totalt, og omtrent litt under halvparten av dem er IT-spesialister. Alt vi gjør, alt vi tjener penger på, gjorde vi selv.

Vi skrev alle produktene våre (og vi har ganske mange av dem - i vår serie med store IT-produkter har vi omtrent 16 forskjellige komponenter) selv; Vi skriver selv, vi utvikler oss selv. Og for øyeblikket utfører vi omtrent en million transaksjoner om dagen (millioner er sannsynligvis den rette måten å si det på). Vi er en ganske ung bedrift - vi er bare rundt seks år gamle.

For 6 år siden var det en slik startup da gutta kom sammen med bedriften. De ble forent av en idé (det var ingenting annet enn en idé), og vi løp. Som enhver oppstart løp vi raskere... For oss var hastighet viktigere enn kvalitet.

På et tidspunkt stoppet vi: vi innså at vi på en eller annen måte ikke lenger kunne leve i den hastigheten og med den kvaliteten, og vi måtte fokusere på kvalitet først. I dette øyeblikk bestemte vi oss for å skrive en ny plattform som ville være korrekt, skalerbar og pålitelig. De begynte å skrive denne plattformen (de begynte å investere, utvikle utvikling, teste), men på et tidspunkt innså de at utvikling og testing ikke tillot oss å nå et nytt nivå av tjenestekvalitet.

Du lager et nytt produkt, du setter det i produksjon, men likevel vil noe gå galt et sted. Og i dag skal vi snakke om hvordan vi kan nå et nytt kvalitetsnivå (hvordan vi gjorde det, om vår erfaring), ta utvikling og testing ut av ligningen; vi skal snakke om hva som er tilgjengelig for drift - hva drift kan gjøre selv, hva det kan tilby testing for å påvirke kvaliteten.

Nedetider. Driftsbud.

Alltid hovedhjørnesteinen, det vi faktisk skal snakke om i dag er nedetid. Et forferdelig ord. Hvis vi har nedetid, er alt dårlig for oss. Vi løper for å heve den, administratorene holder serveren - Gud forby at den ikke faller, som de sier i den sangen. Det er dette vi skal snakke om i dag.

Da vi begynte å endre våre tilnærminger, dannet vi 4 bud. Jeg har dem presentert på lysbildene:

Disse budene er ganske enkle:

• Identifiser problemet raskt.
• Bli kvitt det enda raskere.
• Hjelp til å forstå årsaken (senere, for utviklere).
• Og standardisere tilnærminger.

Jeg vil gjøre deg oppmerksom på punkt nr. 2. Vi blir kvitt problemet, ikke løser det. Å bestemme er sekundært. For oss er det primære at brukeren er beskyttet mot dette problemet. Det vil eksistere i et isolert miljø, men dette miljøet vil ikke ha noen kontakt med det. Egentlig skal vi gå gjennom disse fire problemgruppene (noen mer detaljert, noen i mindre detalj), jeg vil fortelle deg hva vi bruker, hvilken relevant erfaring vi har i løsninger.

Feilsøking: Når skjer de og hva skal jeg gjøre med dem?

Men vi starter ute av drift, vi starter med punkt nr. 2 - hvordan bli raskt kvitt problemet? Det er et problem - vi må fikse det. "Hva skal vi gjøre med dette?" - hovedspørsmålet. Og da vi begynte å tenke på hvordan vi skulle fikse problemet, utviklet vi for oss selv noen krav som feilsøking må følge.

For å formulere disse kravene bestemte vi oss for å stille oss selv spørsmålet: «Når har vi problemer»? Og problemer, som det viste seg, oppstår i fire tilfeller:

• Maskinvarefeil.
• Eksterne tjenester mislyktes.
• Endring av programvareversjon (samme distribusjon).
• Eksplosiv lastvekst.

Vi skal ikke snakke om de to første. En maskinvarefeil kan løses ganske enkelt: du må ha alt duplisert. Hvis dette er disker, må diskene settes sammen i RAID; hvis dette er en server, må serveren dupliseres; hvis du har en nettverksinfrastruktur, må du levere en ekstra kopi av nettverksinfrastrukturen, det vil si at du tar den og duplisere det. Og hvis noe feiler, bytter du til reservestrøm. Det er vanskelig å si noe mer her.

Det andre er svikt i eksterne tjenester. For de fleste er ikke systemet noe problem i det hele tatt, men ikke for oss. Siden vi behandler betalinger, er vi en aggregator som står mellom brukeren (som legger inn kortdataene hans) og banker, betalingssystemer (Visa, MasterCard, Mira, etc.). Våre eksterne tjenester (betalingssystemer, banker) har en tendens til å mislykkes. Verken vi eller du (hvis du har slike tjenester) kan påvirke dette.

Hva skal man gjøre da? Det er to alternativer her. Først, hvis du kan, bør du duplisere denne tjenesten på en eller annen måte. For eksempel, hvis vi kan, overfører vi trafikk fra en tjeneste til en annen: for eksempel ble kort behandlet gjennom Sberbank, Sberbank har problemer - vi overfører trafikk [betinget] til Raiffeisen. Det andre vi kan gjøre er å merke svikten i eksterne tjenester veldig raskt, og derfor vil vi snakke om responshastighet i neste del av rapporten.

Faktisk, av disse fire, kan vi spesifikt påvirke endringen av programvareversjoner - ta handlinger som vil føre til en forbedring av situasjonen i sammenheng med utplasseringer og i sammenheng med eksplosiv vekst i belastning. Det var faktisk det vi gjorde. Her igjen en liten merknad...

Av disse fire problemene løses flere umiddelbart hvis du har en sky. Hvis du er i Microsoft Azhur, Ozon-skyene, eller bruker skyene våre, fra Yandex eller Mail, blir i det minste en maskinvarefeil problemet deres, og alt blir umiddelbart bra for deg i sammenheng med en maskinvarefeil.

Vi er et litt ukonvensjonelt selskap. Her snakker alle om "Kubernets", om skyer - vi har verken "Kubernets" eller skyer. Men vi har racks med maskinvare i mange datasentre, og vi er tvunget til å leve på denne maskinvaren, vi er tvunget til å være ansvarlige for det hele. Derfor vil vi snakke i denne sammenhengen. Så om problemene. De to første ble tatt ut av parentes.

Endring av programvareversjon. Baser

Våre utviklere har ikke tilgang til produksjon. Hvorfor det? Det er bare det at vi er PCI DSS-sertifisert, og utviklerne våre har rett og slett ikke rett til å komme inn i "produktet". Det er det, punktum. I det hele tatt. Derfor slutter utviklingsansvaret akkurat i det øyeblikket utviklingen sender bygget for utgivelse.

Vårt andre grunnlag som vi har, som også hjelper oss mye, er fraværet av unik udokumentert kunnskap. Jeg håper det er det samme for deg. For hvis dette ikke er tilfelle, vil du få problemer. Det vil oppstå problemer når denne unike, udokumenterte kunnskapen ikke er tilstede til rett tid på rett sted. La oss si at du har en person som vet hvordan han skal distribuere en bestemt komponent - personen er ikke der, han er på ferie eller er syk - det er det, du har problemer.

Og det tredje grunnlaget vi har kommet til. Vi kom til det gjennom smerte, blod, tårer - vi kom til den konklusjonen at alle byggene våre inneholder feil, selv om de er feilfrie. Vi bestemte dette selv: når vi distribuerer noe, når vi ruller noe i produksjon, har vi en build med feil. Vi har laget kravene som systemet vårt skal tilfredsstille.

Krav for endring av programvareversjon

Det er tre krav:

• Vi må raskt rulle tilbake utplasseringen.
• Vi må minimere virkningen av en mislykket distribusjon.
• Og vi må raskt kunne sette inn parallelt.
  Akkurat i den rekkefølgen! Hvorfor? Fordi først og fremst, når du distribuerer en ny versjon, er ikke hastigheten viktig, men det er viktig for deg, hvis noe går galt, raskt å rulle tilbake og ha minimal innvirkning. Men hvis du har et sett med versjoner i produksjon, som det viser seg at det er en feil for (ut av det blå, det var ingen distribusjon, men det er en feil) - hastigheten på påfølgende distribusjon er viktig for deg. Hva har vi gjort for å møte disse kravene? Vi brukte følgende metodikk:

  
  
  Det er ganske godt kjent, vi har aldri funnet det opp - dette er Blue/Green deploy. Hva det er? Du må ha en kopi for hver gruppe servere som applikasjonene dine er installert på. Kopien er "varm": det er ingen trafikk på den, men når som helst kan denne trafikken sendes til denne kopien. Denne kopien inneholder den forrige versjonen. Og på tidspunktet for distribusjon ruller du ut koden til en inaktiv kopi. Deretter bytter du deler av trafikken (eller hele) til den nye versjonen. Derfor, for å endre trafikkflyten fra den gamle versjonen til den nye, trenger du bare å gjøre én handling: du må endre balanseren i oppstrøms, endre retningen - fra en oppstrøms til en annen. Dette er veldig praktisk og løser problemet med raskt bytte og rask tilbakerulling.

  Her er løsningen på det andre spørsmålet minimering: du kan sende bare deler av trafikken til en ny linje, til en linje med en ny kode (la det være for eksempel 2%). Og disse 2% er ikke 100%! Hvis du mistet 100 % av trafikken på grunn av en mislykket distribusjon, er det skummelt; hvis du mistet 2 % av trafikken, er det ubehagelig, men det er ikke skummelt. Dessuten vil brukere mest sannsynlig ikke engang legge merke til dette, fordi i noen tilfeller (ikke i alle) den samme brukeren, som trykker på F5, vil bli tatt til en annen fungerende versjon.

  Blå/grønn utplassering. Ruting

  Imidlertid er ikke alt så enkelt "Blå/grønn utplassering"... Alle komponentene våre kan deles inn i tre grupper:

  • dette er frontend (betalingssider som våre kunder ser);
  • behandlingen kjernen;
  • adapter for arbeid med betalingssystemer (banker, MasterCard, Visa...).

  Og det er en nyanse her - nyansen ligger i rutingen mellom linjene. Hvis du bare bytter 100 % av trafikken, har du ikke disse problemene. Men hvis du vil bytte 2%, begynner du å stille spørsmål: "Hvordan gjør jeg dette?" Det enkleste er rett frem: du kan sette opp Round Robin i nginx ved tilfeldig valg, og du har 2 % til venstre, 98 % til høyre. Men dette er ikke alltid egnet.

  For eksempel, i vårt tilfelle, samhandler en bruker med systemet med mer enn én forespørsel. Dette er normalt: 2, 3, 4, 5 forespørsler - systemene dine kan være de samme. Og hvis det er viktig for deg at alle brukerens forespørsler kommer til samme linje som den første forespørselen kom på, eller (andre punkt) kommer alle brukerens forespørsler til den nye linjen etter byttet (han kunne ha begynt å jobbe tidligere med system, før bryteren), - da passer ikke denne tilfeldige distribusjonen for deg. Da er det følgende alternativer:

  
  
  Det første alternativet, det enkleste, er basert på de grunnleggende parametrene til klienten (IP Hash). Du har en IP, og du deler den fra høyre til venstre etter IP-adresse. Da vil det andre tilfellet jeg beskrev fungere for deg, når distribusjonen skjedde, kunne brukeren allerede begynne å jobbe med systemet ditt, og fra tidspunktet for utrullingen vil alle forespørsler gå til en ny linje (til den samme, for eksempel).

  Hvis dette av en eller annen grunn ikke passer deg og du må sende forespørsler til linjen der brukerens første, første forespørsel kom, så har du to alternativer...
  Første alternativ: du kan kjøpe betalt nginx+. Det er en Sticky sessions-mekanisme, som på brukerens første forespørsel tildeler en økt til brukeren og binder den til en eller annen oppstrøms. Alle påfølgende brukerforespørsler i løpet av øktens levetid vil bli sendt til samme oppstrøms der økten ble lagt ut.

  Dette passet ikke oss fordi vi allerede hadde vanlig nginx. Å bytte til nginx+ er ikke det at det er dyrt, det er bare at det var litt smertefullt for oss og ikke veldig riktig. “Sticks Sessions”, for eksempel, fungerte ikke for oss av den enkle grunn at “Sticks Sessions” ikke tillater ruting basert på “Enten-eller”. Der kan du spesifisere hva vi "Sticks Sessions" gjør, for eksempel ved IP-adresse eller ved IP-adresse og informasjonskapsler eller ved postparameter, men "Enten-eller" er mer komplisert der.

  Derfor kom vi til det fjerde alternativet. Vi tok nginx på steroider (dette er openresty) - dette er den samme nginx, som i tillegg støtter inkludering av siste skript. Du kan skrive et siste skript, gi det en "åpen hvile", og dette siste skriptet vil bli utført når brukerforespørselen kommer.

  Og vi skrev faktisk et slikt skript, satte oss "openresti" og i dette skriptet sorterer vi gjennom 6 forskjellige parametere etter sammenkobling av "Eller". Avhengig av tilstedeværelsen av en eller annen parameter, vet vi at brukeren kom til en eller annen side, en eller annen linje.

  Blå/grønn utplassering. Fordeler og ulemper

  Selvfølgelig var det sannsynligvis mulig å gjøre det litt enklere (bruk de samme "Sticky Sessions"), men vi har også en slik nyanse at ikke bare brukeren samhandler med oss ​​innenfor rammen av én behandling av én transaksjon... Men betalingssystemer samhandler også med oss: Etter at vi har behandlet transaksjonen (ved å sende en forespørsel til betalingssystemet), mottar vi en avkjøling.
  Og la oss si, hvis vi inne i kretsen vår kan videresende brukerens IP-adresse i alle forespørsler og dele brukere basert på IP-adressen, så vil vi ikke fortelle det samme "Visa": "Dude, vi er et slikt retroselskap, ser vi ut til at å være internasjonal (på nettsiden og i Russland)... Vennligst oppgi brukerens IP-adresse i et tilleggsfelt, protokollen din er standardisert”! Det er klart at de ikke blir enige.

  
  
  Derfor fungerte ikke dette for oss - vi gjorde openresty. Følgelig, med ruting fikk vi noe sånt som dette:

  Blue/Green Deployment har følgelig fordelene som jeg nevnte og ulemper.

  To ulemper:

  • du må bry deg med ruting;
  • den andre største ulempen er utgiften.

  Du trenger dobbelt så mange servere, du trenger dobbelt så mange driftsressurser, du må bruke dobbelt så mye krefter på å vedlikeholde hele denne dyrehagen.

  Forresten, blant fordelene er det en ting til som jeg ikke har nevnt før: du har en reserve i tilfelle lastvekst. Hvis du har en eksplosiv vekst i belastning, har du et stort antall brukere, så inkluderer du ganske enkelt den andre linjen i 50 til 50-fordelingen – og du har umiddelbart x2-servere i klyngen din til du løser problemet med å ha flere servere.

  Hvordan gjøre en rask distribusjon?

  Vi snakket om hvordan vi løser problemet med minimering og rask tilbakeføring, men spørsmålet gjenstår: "Hvordan distribuere raskt?"

  
  
  Det er kort og enkelt her.

  • Du må ha et CD-system (kontinuerlig levering) - du kan ikke leve uten det. Hvis du har én server, kan du distribuere manuelt. Vi har omtrent halvannet tusen servere og halvannet tusen håndtak, selvfølgelig - vi kan plante en avdeling på størrelse med dette rommet bare for å distribuere.
  • Utplasseringen må være parallell. Hvis distribusjonen din er sekvensiell, er alt dårlig. Én server er normalt, du vil distribuere halvannet tusen servere hele dagen.
  • Igjen, for akselerasjon er dette sannsynligvis ikke lenger nødvendig. Under distribusjon bygges prosjektet vanligvis. Du har et nettprosjekt, det er en frontend-del (du lager en webpakke der, du kompilerer npm - noe sånt), og denne prosessen er i prinsippet kortvarig - 5 minutter, men disse 5 minuttene kan være kritisk. Det er derfor, for eksempel, vi ikke gjør det: vi fjernet disse 5 minuttene, vi distribuerer artefakter.

    Hva er en artefakt? En artefakt er en montert bygning der alle monteringsdelene allerede er fullført. Vi lagrer denne artefakten i artefaktlageret. På en gang brukte vi to slike lagringer - det var Nexus og nå jFrog Artifactory. Vi brukte først "Nexus" fordi vi begynte å praktisere denne tilnærmingen i java-applikasjoner (det passet godt). Så la de noen av applikasjonene skrevet i PHP der inne; og «Nexus» var ikke lenger egnet, og derfor valgte vi jFrog Artefactory, som kan artifaktisere nesten alt. Vi har til og med kommet til det punktet at vi i dette artefaktlageret lagrer våre egne binære pakker som vi samler inn for servere.

  Eksplosiv lastvekst

  Vi snakket om å endre programvareversjonen. Det neste vi har er en eksplosiv økning i lasten. Her mener jeg nok med eksplosiv vekst av lasten ikke helt riktig...

  Vi skrev et nytt system - det er serviceorientert, fasjonabelt, vakkert, arbeidere overalt, køer overalt, asynkront overalt. Og i slike systemer kan data flyte gjennom ulike flyter. For den første transaksjonen kan 1., 3., 10. arbeider brukes, for den andre transaksjonen - 2., 4., 5. Og i dag, la oss si, om morgenen har du en dataflyt som bruker de tre første arbeiderne, og om kvelden endres den dramatisk, og alt bruker de tre andre arbeiderne.

  Og her viser det seg at du på en eller annen måte må skalere arbeiderne, du må på en eller annen måte skalere tjenestene dine, men samtidig forhindre ressursoppblåsthet.

  
  
  Vi har definert våre krav. Disse kravene er ganske enkle: at det er tjenesteoppdagelse, parameterisering - alt er standard for å bygge slike skalerbare systemer, bortsett fra ett punkt - ressursavskrivning. Vi sa at vi ikke er klare til å amortisere ressurser slik at serverne varmer opp luften. Vi tok "Konsul", vi tok "Nomad", som styrer arbeiderne våre.

  Hvorfor er dette et problem for oss? La oss gå litt tilbake. Vi har nå rundt 70 betalingssystemer bak oss. Om morgenen går trafikken gjennom Sberbank, så falt Sberbank for eksempel, og vi bytter den til et annet betalingssystem. Vi hadde 100 arbeidere før Sberbank, og etter det må vi øke kraftig med 100 arbeidere for et annet betalingssystem. Og det er ønskelig at alt dette skjer uten menneskelig medvirkning. For hvis det er menneskelig medvirkning, bør det være en ingeniør som sitter der 24/7, som bare skal gjøre dette, fordi slike feil, når 70 systemer er bak deg, skjer regelmessig.

  Derfor så vi på Nomad, som har en åpen IP, og skrev vår egen ting, Scale-Nomad - ScaleNo, som gjør omtrent følgende: den overvåker veksten i køen og reduserer eller øker antall arbeidere avhengig av dynamikken av køen. Da vi gjorde det, tenkte vi: "Kanskje vi kan åpne kildekoden?" Så så de på henne - hun var så enkel som to kopek.

  Så langt har vi ikke åpen kildekode det, men hvis du plutselig etter rapporten, etter å ha innsett at du trenger noe slikt, trenger det, kontaktene mine er i det siste lysbildet - vennligst skriv til meg. Er det minst 3-5 personer, sponser vi det.

  
  
  Hvordan det fungerer? La oss ta en titt! Ser vi fremover: på venstre side er det en del av vår overvåking: dette er én linje, øverst er tidspunktet for hendelsesbehandling, i midten er antall transaksjoner, nederst er antall arbeidere.

  Hvis du ser, er det en feil i dette bildet. På toppdiagrammet krasjet et av diagrammene på 45 sekunder – ett av betalingssystemene gikk ned. Umiddelbart ble trafikk hentet inn på 2 minutter og køen begynte å vokse på et annet betalingssystem, hvor det ikke var arbeidere (vi brukte ikke ressurser - tvert imot disponerte vi ressursen riktig). Vi ville ikke varme - det var et minimalt antall, omtrent 5-10 arbeidere, men de klarte det ikke.

  Den siste grafen viser en "pukkel", som bare betyr at "Skaleno" doblet dette beløpet. Og så, når grafen falt litt, reduserte han den litt - antall arbeidere ble endret automatisk. Det er slik denne tingen fungerer. Vi snakket om punkt nummer 2 - "Hvordan bli raskt kvitt årsaker."

  Overvåkning. Hvordan identifisere problemet raskt?

  Nå er det første punktet "Hvordan identifiserer jeg problemet raskt?" Overvåkning! Vi må forstå visse ting raskt. Hvilke ting bør vi forstå raskt?

  
  
  Tre ting!

  • Vi må forstå og raskt forstå ytelsen til våre egne ressurser.
  • Vi må raskt forstå feil og overvåke ytelsen til systemer som er eksterne for oss.
  • Det tredje punktet er å identifisere logiske feil. Dette er når systemet fungerer for deg, alt er normalt i henhold til alle indikatorer, men noe går galt.

  Jeg vil sannsynligvis ikke fortelle deg noe så kult her. Jeg blir Captain Obvious. Vi så etter det som var på markedet. Vi har en "morsom zoo". Dette er den typen dyrehage vi har nå:

  
  
  Vi bruker Zabbix til å overvåke maskinvare, for å overvåke hovedindikatorene på servere. Vi bruker Okmeter for databaser. Vi bruker "Grafana" og "Prometheus" for alle andre indikatorer som ikke passer til de to første, noen med "Grafana" og "Prometheus", og noen med "Grafana" med "Influx" og Telegraf.

  For et år siden ønsket vi å bruke New Relic. Kul ting, den kan gjøre alt. Men så mye hun kan gjøre alt, er hun så dyr. Da vi vokste til et volum på 1,5 tusen servere, kom en leverandør til oss og sa: "La oss inngå en avtale for neste år." Vi så på prisen og sa nei, det vil vi ikke gjøre. Nå forlater vi New Relic, vi har omtrent 15 servere igjen under overvåking av New Relic. Prisen viste seg å være helt vill.

  Og det er ett verktøy som vi implementerte selv - dette er Debugger. Først kalte vi det «Bagger», men så gikk en engelsklærer forbi, lo vilt og ga det nytt navn til «Debagger». Hva det er? Dette er et verktøy som faktisk i løpet av 15-30 sekunder på hver komponent, som en "svart boks" av systemet, kjører tester på den generelle ytelsen til komponenten.

  Hvis det for eksempel er en ekstern side (betalingsside), åpner han den og ser på hvordan den skal se ut. Hvis dette behandles, sender han en test-"transaksjon" og sørger for at denne "transaksjonen" kommer. Hvis dette er en forbindelse med betalingssystemer, avfyrer vi en testforespørsel tilsvarende, der vi kan, og ser at alt er bra med oss.

  Hvilke indikatorer er viktige for overvåking?

  Hva overvåker vi hovedsakelig? Hvilke indikatorer er viktige for oss?

  
  

  • Responstid / RPS på fronter er en svært viktig indikator. Han svarer umiddelbart at noe er galt med deg.
  • Antall behandlede meldinger i alle køer.
  • Antall arbeidere.
  • Grunnleggende korrekthetsmålinger.

  Det siste punktet er "business", "business"-beregning. Hvis du vil overvåke det samme, må du definere en eller to beregninger som er hovedindikatorene for deg. Vår beregning er gjennomstrømning (dette er forholdet mellom antall vellykkede transaksjoner og den totale transaksjonsflyten). Hvis noe endres i det med et intervall på 5-10-15 minutter, betyr det at vi har problemer (hvis det endres radikalt).

  Hvordan det ser ut for oss er et eksempel på et av styrene våre:

  
  
  På venstre side er det 6 grafer, dette er i henhold til linjene - antall arbeidere og antall meldinger i køene. På høyre side - RPS, RTS. Nedenfor er den samme "forretningsverdien". Og i "business"-metrikken kan vi umiddelbart se at noe gikk galt i de to midterste grafene... Dette er bare et annet system som står bak oss som har falt.

  Det andre vi måtte gjøre var å overvåke fallet til eksterne betalingssystemer. Her tok vi OpenTracing – en mekanisme, standard, paradigme som lar deg spore distribuerte systemer; og det ble endret litt. Standard OpenTracing-paradigmet sier at vi bygger et spor for hver enkelt forespørsel. Vi trengte ikke dette, og vi pakket det inn i et sammendrag, aggregeringsspor. Vi laget et verktøy som lar oss spore hastigheten på systemene bak oss.

  
  
  Grafen viser oss at et av betalingssystemene begynte å svare på 3 sekunder - vi har problemer. Dessuten vil denne tingen reagere når problemene begynner, med et intervall på 20-30 sekunder.

  Og den tredje klassen av overvåkingsfeil som finnes er logisk overvåking.

  For å være ærlig, visste jeg ikke hva jeg skulle tegne på dette lysbildet, fordi vi hadde lett lenge på markedet etter noe som ville passe oss. Vi fant ingenting, så vi måtte gjøre det selv.

  
  
  Hva mener jeg med logisk overvåking? Vel, tenk: du lager deg selv et system (for eksempel en Tinder-klon); du klarte det, lanserte det. Den suksessrike lederen Vasya Pupkin la den på telefonen sin, ser en jente der, liker henne ... og lignende går ikke til jenta - lignende går til sikkerhetsvakten Mikhalych fra det samme forretningssenteret. Lederen går ned, og lurer så på: "Hvorfor smiler denne sikkerhetsvakten Mikhalych så hyggelig til ham?"

  I slike situasjoner... For oss høres denne situasjonen litt annerledes ut, fordi (skrev jeg) dette er et omdømmetap som indirekte fører til økonomiske tap. Vår situasjon er motsatt: vi kan lide direkte økonomiske tap - for eksempel hvis vi gjennomførte en transaksjon som vellykket, men den var mislykket (eller omvendt). Jeg måtte skrive mitt eget verktøy som sporer antall vellykkede transaksjoner over tid ved å bruke forretningsindikatorer. Fant ingenting på markedet! Det var akkurat denne ideen jeg ønsket å formidle. Det er ingenting på markedet for å løse denne typen problemer.

  Dette handlet om hvordan man raskt kunne identifisere problemet.

  Hvordan finne ut årsakene til distribusjon

  Den tredje gruppen av problemer som vi løser er etter at vi har identifisert problemet, etter at vi har blitt kvitt det, vil det være greit å forstå årsaken til utviklingen, for testing, og gjøre noe med det. Følgelig må vi undersøke, vi må heve loggene.

  
  
  Hvis vi snakker om tømmerstokker (hovedårsaken er tømmerstokker), er hoveddelen av tømmerstokkene våre i ELK Stack - nesten alle har det samme. For noen er det kanskje ikke i ELK, men skriver du logger i gigabyte, så kommer du før eller siden til ELK. Vi skriver dem i terabyte.

  
  
  Det er et problem her. Vi fikset det, rettet feilen for brukeren, begynte å grave ut hva som var der, klatret inn i Kibana, skrev inn transaksjons-ID der og fikk en fotduk som denne (viser mye). Og absolutt ingenting er klart i denne fotduken. Hvorfor? Ja, fordi det ikke er klart hvilken del som tilhører hvilken arbeider, hvilken del som tilhører hvilken komponent. Og i det øyeblikket innså vi at vi trengte sporing - den samme OpenTracing som jeg snakket om.

  Vi trodde dette for et år siden, vendte oppmerksomheten mot markedet, og det var to verktøy der - "Zipkin" og "Jaeger". "Jager" er faktisk en slik ideologisk arving, en ideologisk etterfølger av "Zipkin". Alt er bra i Zipkin, bortsett fra at den ikke vet hvordan den skal aggregere, den vet ikke hvordan den skal inkludere logger i sporet, bare tidssporing. Og "Jager" støttet dette.

  Vi så på "Jager": du kan instrumentere applikasjoner, du kan skrive i Api (Api-standarden for PHP på den tiden ble imidlertid ikke godkjent - dette var et år siden, men nå er den allerede godkjent), men der var absolutt ingen klient. "Ok," tenkte vi, og skrev vår egen klient. Hva fikk vi? Dette er omtrent slik det ser ut:

  
  
  I Jaeger opprettes spenn for hver melding. Det vil si at når en bruker åpner systemet, ser han en eller to blokker for hver innkommende forespørsel (1-2-3 - antall innkommende forespørsler fra brukeren, antall blokker). For å gjøre det enklere for brukerne har vi lagt til tagger i loggene og tidssporene. Følgelig, i tilfelle en feil, vil vår applikasjon merke loggen med den riktige feilkoden. Du kan filtrere etter Error tag og bare spenn som inneholder denne blokken med feil vil vises. Slik ser det ut hvis vi utvider spennvidden:

  
  
  Inne i spennet er det et sett med spor. I dette tilfellet er dette tre testspor, og det tredje sporet forteller oss at det har oppstått en feil. Samtidig ser vi her et tidsspor: vi har en tidsskala øverst, og vi ser på hvilket tidsintervall denne eller den loggen ble registrert.

  Derfor gikk det bra for oss. Vi skrev vår egen utvidelse og vi åpnet den. Hvis du vil jobbe med sporing, hvis du vil jobbe med "Jager" i PHP, er det utvidelsen vår, velkommen til bruk, som de sier:

  
  
  Vi har denne utvidelsen - det er en klient for OpenTracing Api, den er laget som php-utvidelse, det vil si at du må montere den og installere den på systemet. For et år siden var det ikke noe annerledes. Nå er det andre klienter som er som komponenter. Her er det opp til deg: enten pumper du ut komponentene med en komponist, eller så bruker du utvidelse opp til deg.

  Bedriftsstandarder

  Vi snakket om de tre budene. Det fjerde budet er å standardisere tilnærminger. Hva handler dette om? Det handler om dette:

  
  
  Hvorfor er ordet "bedrift" her? Ikke fordi vi er et stort eller byråkratisk selskap, nei! Jeg ønsket å bruke ordet "bedrift" her i sammenheng med at hvert selskap, hvert produkt bør ha sine egne standarder, inkludert deg. Hvilke standarder har vi?

  
  

  • Vi har utplasseringsregler. Vi flytter ingen steder uten ham, det kan vi ikke. Vi utplasserer omtrent 60 ganger i uken, det vil si at vi utplasserer nesten konstant. Samtidig har vi for eksempel i utplasseringsreglementet et tabu på utplasseringer på fredag ​​– i utgangspunktet setter vi ikke inn.
  • Vi krever dokumentasjon. Ikke en eneste ny komponent kommer i produksjon hvis det ikke finnes dokumentasjon for det, selv om det ble født under pennen til våre RnD-spesialister. Vi krever fra dem distribusjonsinstruksjoner, et overvåkingskart og en grov beskrivelse (vel, som programmerere kan skrive) av hvordan denne komponenten fungerer, hvordan den feilsøkes.
  • Vi løser ikke årsaken til problemet, men problemet - det jeg allerede har sagt. Det er viktig for oss å beskytte brukeren mot problemer.
  • Vi har klareringer. Vi regner for eksempel ikke som nedetid hvis vi mistet 2 % av trafikken innen to minutter. Dette er i utgangspunktet ikke inkludert i vår statistikk. Hvis det er mer prosentvis eller midlertidig, teller vi allerede.
  • Og vi skriver alltid postmortems. Uansett hva som skjer med oss, vil enhver situasjon der noen oppførte seg unormalt i produksjonen gjenspeiles i obduksjonen. En postmortem er et dokument der du skriver hva som skjedde med deg, en detaljert timing, hva du gjorde for å rette det og (dette er en obligatorisk blokkering!) hva du vil gjøre for å forhindre at dette skjer i fremtiden. Dette er obligatorisk og nødvendig for påfølgende analyse.

  Hva regnes som nedetid?

  
  
  Hva førte alt dette til?

  Dette førte til at (vi hadde visse problemer med stabilitet, dette passet verken klienter eller oss) i løpet av de siste 6 månedene var stabilitetsindikatoren vår 99,97. Vi kan si at dette ikke er veldig mye. Ja, vi har noe å strekke oss etter. Av denne indikatoren er omtrent halvparten stabiliteten, så å si, ikke av vår, men til vår nettapplikasjonsbrannmur, som står foran oss og brukes som en tjeneste, men klienter bryr seg ikke om dette.

  Vi lærte å sove om natten. Endelig! For seks måneder siden kunne vi ikke. Og på dette notatet med resultatene, vil jeg gjerne gjøre ett notat. I går kveld kom det en fantastisk rapport om kontrollsystemet for en atomreaktor. Hvis personene som skrev dette systemet kan høre meg, vennligst glem det jeg sa om "2 % er ikke nedetid." For deg er 2 % nedetid, selv om det er to minutter!

  Det er alt! Dine spørsmål.

  
  

  Om balansere og databasemigrering

  Spørsmål fra salen (heretter – B): – God kveld. Tusen takk for en slik adminrapport! Et kort spørsmål om balansere. Du nevnte at du har en WAF, det vil si, slik jeg forstår det, bruker du en slags ekstern balanserer...

  EK: – Nei, vi bruker tjenestene våre som en balanserer. I dette tilfellet er WAF utelukkende et DDoS-beskyttelsesverktøy for oss.

  I: – Kan du si noen ord om balansere?

  EK: – Som jeg allerede har sagt, er dette en gruppe servere i openresty. Vi har nå 5 reservegrupper som reagerer eksklusivt... det vil si en server som kjører utelukkende openresty, den proxiserer kun trafikk. Følgelig, for å forstå hvor mye vi har: vi har nå en vanlig trafikkflyt på flere hundre megabit. De takler det, de føler seg bra, de anstrenger seg ikke engang.

  I: – Også et enkelt spørsmål. Her er blå/grønn utplassering. Hva gjør du for eksempel med databasemigreringer?

  EK: - Godt spørsmål! Se, i blå/grønn distribusjon har vi separate køer for hver linje. Det vil si at hvis vi snakker om hendelseskøer som overføres fra arbeider til arbeider, er det separate køer for den blå linjen og for den grønne linjen. Hvis vi snakker om selve databasen, har vi bevisst begrenset den så mye vi kunne, flyttet alt praktisk talt inn i køer; i databasen lagrer vi bare en stabel med transaksjoner. Og transaksjonsstabelen vår er den samme for alle linjer. Med databasen i denne sammenhengen: vi deler den ikke opp i blått og grønt, fordi begge versjoner av koden må vite hva som skjer med transaksjonen.

  Venner, jeg har også en liten premie å anspore dere til - en bok. Og jeg bør tildeles det for det beste spørsmålet.

  I: - Hallo. Takk for rapporten. Spørsmålet er dette. Du overvåker betalinger, du overvåker tjenestene du kommuniserer med... Men hvordan overvåker du slik at en person på en eller annen måte kom til betalingssiden din, foretok en betaling, og prosjektet krediterte ham med penger? Det vil si, hvordan overvåker du at marchanten er tilgjengelig og har akseptert tilbakeringingen din?

  EK: – "Selger" for oss er i dette tilfellet nøyaktig samme eksterne tjeneste som betalingssystemet. Vi overvåker selgerens responshastighet.

  Om databasekryptering

  I: - Hallo. Jeg har et litt relatert spørsmål. Du har PCI DSS-sensitive data. Jeg ville vite hvordan du lagrer PAN-er i køer som du må overføre til? Bruker du noe kryptering? Og dette fører til det andre spørsmålet: i henhold til PCI DSS er det nødvendig å periodisk kryptere databasen i tilfelle endringer (avskjedigelse av administratorer, etc.) - hva skjer med tilgjengelighet i dette tilfellet?

  
  
  EK: – Fantastisk spørsmål! For det første lagrer vi ikke PAN-er i køer. Vi har ikke rett til å lagre PAN hvor som helst i klar form, i prinsippet, så vi bruker en spesiell tjeneste (vi kaller det "Kademon") - dette er en tjeneste som bare gjør én ting: den mottar en melding som input og sender ut en kryptert melding. Og vi lagrer alt med denne krypterte meldingen. Følgelig er nøkkellengden vår under en kilobyte, slik at dette er seriøst og pålitelig.

  I: – Trenger du 2 kilobyte nå?

  EK: – Det virker som om det var 256 i går... Vel, hvor ellers?!

  Følgelig er dette den første. Og for det andre, løsningen som eksisterer, den støtter re-krypteringsprosedyren - det er to par "keks" (nøkler), som gir "decks" som krypterer (nøkkelen er nøklene, dek er derivater av nøklene som krypterer) . Og hvis prosedyren startes (det skjer regelmessig, fra 3 måneder til ± noen), laster vi ned et nytt par "kaker", og vi krypterer dataene på nytt. Vi har separate tjenester som river ut all data og krypterer den på en ny måte; Dataene lagres ved siden av identifikatoren til nøkkelen som den er kryptert med. Følgelig, så snart vi krypterer dataene med nye nøkler, sletter vi den gamle nøkkelen.

  Noen ganger må betalinger gjøres manuelt...

  I: – Det vil si, hvis en refusjon har kommet for en operasjon, vil du fortsatt dekryptere den med den gamle nøkkelen?

  EK: - Ja.

  I: – Så ett lite spørsmål til. Når en slags feil, fall eller hendelse oppstår, er det nødvendig å presse gjennom transaksjonen manuelt. Det er en slik situasjon.

  EK: - Ja, noen ganger.

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

  EK: – Nei, vel, selvfølgelig, vi har et slags back-office-system som inneholder et grensesnitt for vår support. Hvis vi ikke vet hvilken status transaksjonen har (for eksempel inntil betalingssystemet svarte med en timeout), vet vi ikke på forhånd, det vil si at vi tildeler den endelige statusen kun med full tillit. I dette tilfellet tildeler vi transaksjonen en spesiell status for manuell behandling. Om morgenen, neste dag, så snart støtte mottar informasjon om at slike og slike transaksjoner forblir i betalingssystemet, behandler de dem manuelt i dette grensesnittet.

  
  
  I: – Jeg har et par spørsmål. En av dem er fortsettelsen av PCI DSS-sonen: hvordan logger du kretsen deres? Dette spørsmålet er fordi utvikleren kunne ha lagt hva som helst i loggene! Det andre spørsmålet: hvordan ruller du ut hurtigreparasjoner? Å bruke håndtak i databasen er ett alternativ, men det kan være gratis hurtigreparasjoner - hva er prosedyren der? Og det tredje spørsmålet er sannsynligvis knyttet til RTO, RPO. Tilgjengeligheten din var 99,97, nesten fire niere, men slik jeg forstår det, har du et andre datasenter, et tredje datasenter og et femte datasenter... Hvordan synkroniserer du dem, replikerer dem og alt annet?

  EK: – La oss starte med den første. Var det første spørsmålet om logger? Når vi skriver logger, har vi et lag som maskerer alle sensitive data. Hun ser på masken og på tilleggsfeltene. Følgelig kommer loggene våre ut med allerede maskerte data og en PCI DSS-krets. Dette er en av de faste oppgavene som tildeles testavdelingen. De er pålagt å sjekke hver oppgave, inkludert loggene de skriver, og dette er en av de vanlige oppgavene under kodegjennomganger, for å kontrollere at utvikleren ikke skrev ned noe. Etterfølgende kontroller av dette utføres jevnlig av informasjonssikkerhetsavdelingen omtrent en gang i uken: logger for siste dag tas selektivt og de kjøres gjennom en spesiell skanner-analysator fra testservere for å sjekke alt.
  Om hurtigreparasjoner. Dette er inkludert i våre distribusjonsforskrifter. Vi har en egen klausul om hurtigreparasjoner. Vi tror at vi distribuerer hurtigreparasjoner døgnet rundt når vi trenger det. Så snart versjonen er satt sammen, så snart den er kjørt, så snart vi har en artefakt, har vi en systemadministrator på vakt som ringer fra support, og han distribuerer den i det øyeblikket det er nødvendig.

  Omtrent "fire niere". Tallet vi har nå er virkelig oppnådd, og vi strebet etter det i et annet datasenter. Nå har vi et annet datasenter, og vi begynner å rute mellom dem, og spørsmålet om replikering på tvers av datasenter er virkelig et ikke-trivielt spørsmål. Vi prøvde å løse det på en gang med forskjellige midler: vi prøvde å bruke den samme "Tarantula" - det fungerte ikke for oss, jeg skal fortelle deg med en gang. Derfor endte vi opp med å bestille «sens» manuelt. Faktisk kjører hver applikasjon i systemet vårt den nødvendige "endre - ferdig"-synkroniseringen mellom datasentre asynkront.

  I: – Hvis du fikk en andre, hvorfor fikk du ikke en tredje? Fordi ingen har splittet hjerne ennå...

  EK: – Men vi har ikke Split Brain. På grunn av at hver applikasjon er drevet av en multimaster, spiller det ingen rolle for oss hvilket senter forespørselen kom til. Vi er klare for det faktum at hvis et av våre datasentre svikter (vi stoler på dette) og midt i en brukerforespørsel bytter til det andre datasenteret, er vi klare til å miste denne brukeren, faktisk; men dette vil være enheter, absolutte enheter.

  I: - God kveld. Takk for rapporten. Du snakket om feilsøkeren din, som kjører noen testtransaksjoner i produksjonen. Men fortell oss om testtransaksjoner! Hvor dypt går det?

  EK: – Den går gjennom hele syklusen til hele komponenten. For en komponent er det ingen forskjell mellom en testtransaksjon og en produksjonstransaksjon. Men fra et logisk synspunkt er dette rett og slett et eget prosjekt i systemet, hvor det kun kjøres testtransaksjoner.

  I: -Hvor kutter du det av? Her sendte Core...

  EK: – Vi står bak «Kor» i dette tilfellet for testtransaksjoner... Vi har noe slikt som ruting: «Kor» vet hvilket betalingssystem vi skal sende til - vi sender til et falskt betalingssystem, som ganske enkelt gir et http-signal og det er alt.

  I: – Fortell meg, vær så snill, var søknaden din skrevet i en enorm monolitt, eller kuttet du den inn i noen tjenester eller til og med mikrotjenester?

  EK: – Vi har ikke en monolitt, selvfølgelig, vi har en tjenesteorientert applikasjon. Vi spøker med at tjenesten vår er laget av monolitter - de er egentlig ganske store. Det er vanskelig å kalle det mikrotjenester, men dette er tjenester der arbeidere på distribuerte maskiner opererer.

  Hvis tjenesten på serveren er kompromittert...

  I: – Da har jeg neste spørsmål. Selv om det var en monolitt, sa du fortsatt at du har mange av disse instant-serverne, de behandler alle i utgangspunktet data, og spørsmålet er: "I tilfelle av et kompromittering av en av instant-serverne eller en applikasjon, enhver individuell lenke , har de noen form for tilgangskontroll? Hvem av dem kan gjøre hva? Hvem bør jeg kontakte for hvilken informasjon?

  
  
  EK: - Ja, definitivt. Sikkerhetskravene er ganske alvorlige. For det første har vi åpne databevegelser, og portene er kun de som vi forventer trafikkbevegelse gjennom på forhånd. Hvis en komponent kommuniserer med databasen (for eksempel med Muskul) via 5-4-3-2, vil bare 5-4-3-2 være åpen for den, og andre porter og andre trafikkretninger vil ikke være tilgjengelige. I tillegg må du forstå at i vår produksjon er det omtrent 10 forskjellige sikkerhetssløyfer. Og selv om applikasjonen på en eller annen måte ble kompromittert, Gud forby, vil angriperen ikke få tilgang til serveradministrasjonskonsollen, fordi dette er en annen nettverkssikkerhetssone.

  I: – Og i denne sammenhengen, det som er mer interessant for meg er at du har visse kontrakter med tjenester - hva de kan gjøre, gjennom hvilke "handlinger" de kan kontakte hverandre... Og i en normal flyt ber noen spesifikke tjenester om noen rad, en liste over "handlinger" på den andre. De ser ikke ut til å henvende seg til andre i en normal situasjon, og de har andre ansvarsområder. Hvis en av dem blir kompromittert, vil den da kunne forstyrre "handlingene" til den tjenesten?

  EK: - Jeg forstår. Hvis det i en normal situasjon med en annen server var tillatt kommunikasjon i det hele tatt, så ja. I henhold til SLA-kontrakten overvåker vi ikke at du kun har lov til de 3 første "handlingene", og du har ikke lov til de 4 "handlingene". Dette er sannsynligvis overflødig for oss, fordi vi allerede har et 4-nivå beskyttelsessystem, i prinsippet, for kretser. Vi foretrekker å forsvare oss med konturene, fremfor på nivå med innsiden.

  Hvordan Visa, MasterCard og Sberbank fungerer

  I: – Jeg ønsker å presisere et poeng om å bytte en bruker fra et datasenter til et annet. Så vidt jeg vet, opererer Visa og MasterCard ved hjelp av 8583 binær synkron protokoll, og det er blandinger der. Og jeg ville vite, nå mener vi bytte - er det direkte "Visa" og "MasterCard" eller før betalingssystemer, før behandling?

  EK: – Dette er før blandingene. Våre mikser er plassert i samme datasenter.

  I: – Grovt sett, har du ett koblingspunkt?

  EK: – “Visa” og “MasterCard” – ja. Rett og slett fordi Visa og MasterCard krever ganske seriøse investeringer i infrastruktur for å inngå separate kontrakter for å få et andre par mikser, for eksempel. De er reservert innenfor ett datasenter, men hvis, gud forby, datasenteret vårt, hvor det er mikser for å koble til Visa og MasterCard, dør, så vil vi miste forbindelsen med Visa og MasterCard...

  I: – Hvordan kan de reserveres? Jeg vet at Visa kun tillater én forbindelse i prinsippet!

  EK: – De leverer utstyret selv. Uansett fikk vi utstyr som er fullt redundant innvendig.

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

  EK: - Ja.

  I: – Men hva med denne saken: Hvis datasenteret ditt forsvinner, hvordan kan du fortsette å bruke det? Eller stopper trafikken bare?

  EK: - Nei. I dette tilfellet vil vi ganske enkelt bytte trafikken til en annen kanal, som naturligvis vil være dyrere for oss og dyrere for kundene våre. Men trafikken vil ikke gå gjennom vår direkte forbindelse til Visa, MasterCard, men gjennom den betingede Sberbank (veldig overdrevet).

  Jeg beklager vilt hvis jeg fornærmet Sberbank-ansatte. Men ifølge vår statistikk, blant de russiske bankene, faller Sberbank oftest. Det går ikke en måned uten at noe faller av hos Sberbank.

  
  
  

  Noen annonser 🙂

  Takk for at du bor hos oss. Liker du artiklene våre? Vil du se mer interessant innhold? Støtt oss ved å legge inn en bestilling eller anbefale til venner, cloud VPS for utviklere fra $4.99, en unik analog av entry-level servere, som ble oppfunnet av oss for deg: Hele sannheten om VPS (KVM) E5-2697 v3 (6 kjerner) 10GB DDR4 480GB SSD 1Gbps fra $19 eller hvordan dele en server? (tilgjengelig med RAID1 og RAID10, opptil 24 kjerner og opptil 40 GB DDR4).

  Dell R730xd 2x billigere i Equinix Tier IV datasenter i Amsterdam? Bare her 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV fra $199 i Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Lese om Hvordan bygge infrastruktur corp. klasse med bruk av Dell R730xd E5-2650 v4-servere verdt 9000 euro for en krone?

Kilde: www.habr.com