ProHoster > Blog > administration > Top fakapov Cyan

Top fakapov Cyan

Top fakapov Cyan

God til alle! 

Mit navn er Nikita, jeg er teamleder for Cians ingeniÞrteam. Et af mine ansvarsomrÄder i virksomheden er at reducere antallet af hÊndelser relateret til infrastruktur i produktionen til nul.
Det, der vil blive diskuteret nedenfor, gav os en masse smerte, og formĂ„let med denne artikel er at forhindre andre mennesker i at gentage vores fejl eller i det mindste minimere deres indvirkning. 

prĂŠambel

For lang tid siden, da Cian bestod af monolitter, og der endnu ikke var antydninger af mikrotjenester, mĂ„lte vi tilgĂŠngeligheden af ​​en ressource ved at tjekke 3-5 sider. 

De svarer - alt er i orden, hvis de ikke svarer i lang tid - alarm. Hvor lĂŠnge de skulle have fri fra arbejde, for at det kunne betragtes som en hĂŠndelse, blev besluttet af folk pĂ„ mĂžder. Et team af ingeniĂžrer var altid involveret i efterforskningen af ​​hĂŠndelsen. Da undersĂžgelsen var afsluttet, skrev de en obduktion – en slags rapport pĂ„ e-mail i formatet: hvad skete der, hvor lĂŠnge det varede, hvad vi gjorde i Ăžjeblikket, hvad vi vil gĂžre i fremtiden. 

Sidens hovedsider eller hvordan vi forstÄr, at vi har ramt bunden

 
For pĂ„ en eller anden mĂ„de at forstĂ„ fejlens prioritet har vi identificeret de mest kritiske webstedssider for virksomhedsfunktionalitet. Ved at bruge dem tĂŠller vi antallet af vellykkede/mislykkede anmodninger og timeouts. SĂ„dan mĂ„ler vi oppetid. 

Lad os sige, at vi fandt ud af, at der er en rÊkke supervigtige dele af webstedet, der er ansvarlige for hovedtjenesten - sÞgning og indsendelse af annoncer. Hvis antallet af anmodninger, der mislykkes, overstiger 1 %, er dette en kritisk hÊndelse. Hvis fejlraten inden for 15 minutter i primetime overstiger 0,1 %, betragtes dette ogsÄ som en kritisk hÊndelse. Disse kriterier dÊkker de fleste hÊndelser; resten er uden for denne artikels omfang.

Top fakapov Cyan

Top bedste hĂŠndelser Cian

SĂ„ vi har helt sikkert lĂŠrt at fastslĂ„, at der skete en hĂŠndelse. 

Nu er hver hĂŠndelse beskrevet i detaljer og afspejlet i Jira-eposet. Forresten: til dette startede vi et separat projekt, kaldet det FAIL - kun epos kan oprettes i det. 

Hvis du samler alle fejlene i de sidste par Ă„r, er lederne: 

  • mssql-relaterede hĂŠndelser;
  • hĂŠndelser forĂ„rsaget af eksterne faktorer;
  • admin fejl.

Lad os se mere detaljeret pÄ administratorernes fejl samt nogle andre interessante fejl.

Femteplads - "At bringe tingene i orden i DNS"

Det var en stormfuld tirsdag. Vi besluttede at genoprette orden i DNS-klyngen. 

Jeg Ăžnskede at overfĂžre interne DNS-servere fra bind til powerdns, og allokere helt separate servere til dette, hvor der ikke er andet end DNS. 

Vi placerede Ă©n DNS-server pĂ„ hver lokation af vores DC'er, og tidspunktet kom til at flytte zoner fra bind til powerdns og skifte infrastrukturen til nye servere. 

Midt i flytningen, af alle ting servereAf de servere, der var angivet i lokale caching-bindinger, var der kun Ă©n tilbage – den i datacentret i St. Petersborg. Dette datacenter blev oprindeligt erklĂŠret ikke-kritisk for os, men blev pludselig et enkelt fejlpunkt.
Det var i denne overgangsperiode, at kanalen mellem Moskva og Skt. Petersborg gik ned. Vi var reelt uden DNS i fem minutter og kom os igen, da vĂŠrt lĂžste problemerne. 

Konklusioner:

Hvis vi tidligere forsÞmte eksterne faktorer under forberedelsen til arbejdet, er de nu ogsÄ inkluderet pÄ listen over, hvad vi forbereder os pÄ. Og nu bestrÊber vi os pÄ at sikre, at alle komponenter er reserveret n-2, og under arbejdet kan vi sÊnke dette niveau til n-1.

  • NĂ„r du udarbejder en handlingsplan, skal du markere de punkter, hvor tjenesten kan fejle, og gennemtĂŠnke et scenarie, hvor alt gik "fra slemt til vĂŠrre" pĂ„ forhĂ„nd.
  • Distribuer interne DNS-servere pĂ„ tvĂŠrs af forskellige geolokationer/datacentre/racks/switches/inputs.
  • PĂ„ hver server skal du installere en lokal cache-DNS-server, som omdirigerer anmodninger til de vigtigste DNS-servere, og hvis den ikke er tilgĂŠngelig, vil den svare fra cachen. 

Fjerdeplads - "At sĂŠtte tingene i orden i Nginx"

En skĂžnne dag besluttede vores team, at "vi har fĂ„et nok af det her", og processen med at omstrukturere nginx-konfigurationer begyndte. HovedmĂ„let er at bringe konfigurationerne til en intuitiv struktur. Tidligere var alt "historisk etableret" og bar ingen logik. Nu er hver server_name blevet flyttet til en fil med samme navn, og alle konfigurationer er blevet distribueret i mapper. Konfigurationen indeholder i Ăžvrigt 253949 linjer eller 7836520 tegn og fylder nĂŠsten 7 megabyte. Øverste strukturniveau: 

Nginx struktur

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    â”œâ”€â”€ cian-mcs.conf
    â”œâ”€â”€ ...
    â””── wafserver.conf

Det blev meget bedre, men i processen med at omdĂžbe og distribuere konfigurationer, havde nogle af dem den forkerte udvidelse og var ikke inkluderet i include *.conf-direktivet. Som et resultat blev nogle vĂŠrter utilgĂŠngelige og returnerede 301 til hovedsiden. PĂ„ grund af at svarkoden ikke var 5xx/4xx, blev dette ikke bemĂŠrket med det samme, men fĂžrst om morgenen. Derefter begyndte vi at skrive test for at kontrollere infrastrukturkomponenter.

Konklusioner: 

  • Strukturer dine konfigurationer korrekt (ikke kun nginx) og tĂŠnk strukturen igennem pĂ„ et tidligt stadium af projektet. PĂ„ denne mĂ„de vil du gĂžre dem mere forstĂ„elige for teamet, hvilket igen vil reducere TTM.
  • Skriv test for nogle infrastrukturkomponenter. For eksempel: kontrol af, at alle nĂžgleservernavne giver den korrekte status + svartekst. Det vil vĂŠre nok kun at have et par scripts ved hĂ„nden, der kontrollerer komponentens grundlĂŠggende funktioner, for ikke at huske febrilsk klokken 3, hvad der ellers skal kontrolleres. 

Tredjeplads - “Pludselig lþb tþr for plads i Cassandra”

Dataene voksede stĂžt, og alt var fint indtil det Ăžjeblik, hvor reparationen af ​​store sagsrum begyndte at mislykkes i Cassandra-klyngen, fordi komprimering ikke kunne fungere pĂ„ dem. 

En stormfuld dag blev klyngen nĂŠsten til et grĂŠskar, nemlig:

  • der var omkring 20% ​​af den samlede plads tilbage i klyngen;
  • Det er umuligt at tilfĂžje noder fuldt ud, fordi oprydning ikke gĂ„r igennem efter tilfĂžjelse af en node pĂ„ grund af pladsmangel pĂ„ partitionerne;
  • produktiviteten falder gradvist, da komprimering ikke virker; 
  • Klyngen er i nĂždtilstand.

Top fakapov Cyan

Afslut - vi tilfĂžjede yderligere 5 noder uden oprydning, hvorefter vi begyndte systematisk at fjerne dem fra klyngen og gĂ„ ind i dem igen, som tomme noder, der var lĂžbet tĂžr for plads. Der blev brugt meget mere tid, end vi gerne ville. Der var risiko for delvis eller fuldstĂŠndig utilgĂŠngelighed af klyngen. 

Konklusioner:

  • PĂ„ alle cassandra-servere bĂžr ikke mere end 60% af pladsen pĂ„ hver partition vĂŠre optaget. 
  • De bĂžr ikke indlĂŠses med mere end 50 % cpu.
  • Du bĂžr ikke glemme alt om kapacitetsplanlĂŠgning og nĂždt til at gennemtĂŠnke det for hver komponent, baseret pĂ„ dens detaljer.
  • Jo flere noder i klyngen, jo bedre. Servere, der indeholder en lille mĂŠngde data, overbelastes hurtigere, og en sĂ„dan klynge er lettere at genoplive. 

Andenplads - "Data forsvandt fra konsul nĂžglevĂŠrdi-lagring"

Til serviceopdagelse bruger vi som mange konsul. Men vi bruger ogsĂ„ dens nĂžglevĂŠrdi til blĂ„-grĂžn layout af monolitten. Den gemmer information om aktive og inaktive upstreams, som skifter plads under udrulningen. Til dette formĂ„l blev der skrevet en implementeringstjeneste, der interagerede med KV. PĂ„ et tidspunkt forsvandt dataene fra KV. Gendannet fra hukommelsen, men med en rĂŠkke fejl. Som et resultat, under upload, blev belastningen pĂ„ upstreams fordelt ujĂŠvnt, og vi modtog mange 502-fejl pĂ„ grund af, at backends var overbelastet pĂ„ CPU'en. Det resulterede i, at vi flyttede fra konsul KV til postgres, hvorfra det ikke lĂŠngere er sĂ„ nemt at fjerne dem.  

Konklusioner:

  • Tjenester uden nogen autorisation bĂžr ikke indeholde data, der er kritiske for driften af ​​webstedet. For eksempel, hvis du ikke har autorisation i ES, ville det vĂŠre bedre at nĂŠgte adgang pĂ„ netvĂŠrksniveau alle steder, hvor det ikke er nĂždvendigt, kun lade de nĂždvendige vĂŠre, og ogsĂ„ indstille action.destructive_requires_name: true.
  • Øv din backup- og gendannelsesmekanisme pĂ„ forhĂ„nd. Lav for eksempel et script pĂ„ forhĂ„nd (for eksempel i python), der kan sikkerhedskopiere og gendanne.

FĂžrstepladsen - “Captain Unobvious” 

PĂ„ et tidspunkt bemĂŠrkede vi en ujĂŠvn fordeling af belastningen pĂ„ nginx upstreams i tilfĂŠlde, hvor der var 10+ servere i backend. PĂ„ grund af det faktum, at round-robin sendte forespĂžrgsler fra 1. til sidste upstream i rĂŠkkefĂžlge, og hver nginx reload startede forfra, modtog de fĂžrste upstreams altid flere anmodninger end resten. Som et resultat arbejdede de langsommere, og hele siden led. Dette blev mere og mere mĂŠrkbart, efterhĂ„nden som mĂŠngden af ​​trafik steg. Blot at opdatere nginx for at aktivere tilfĂŠldig virkede ikke - vi er nĂždt til at lave en masse lua-kode om, der ikke startede pĂ„ version 1.15 (pĂ„ det tidspunkt). Vi var nĂždt til at lappe vores nginx 1.14.2 og introducerede tilfĂŠldig support i den. Dette lĂžste problemet. Denne fejl vinder kategorien "Captain Non-Obviousness".

Konklusioner:

Det var meget interessant og spĂŠndende at udforske denne fejl). 

  • Organiser din overvĂ„gning, sĂ„ den hjĂŠlper dig med at finde sĂ„danne udsving hurtigt. For eksempel kan du bruge ELK til at overvĂ„ge rps pĂ„ hver backend af hver upstream, overvĂ„ge deres responstid fra nginx' synspunkt. I dette tilfĂŠlde hjalp dette os med at identificere problemet. 

Som et resultat kunne de fleste af fejlene have vĂŠret undgĂ„et med en mere omhyggelig tilgang til det, du lavede. Vi skal altid huske Murphys lov: Alt, der kan gĂ„ galt, vil gĂ„ galt, og bygge komponenter baseret pĂ„ det. 

Kilde: www.habr.com

KĂžb pĂ„lidelig hosting til websteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KĂžb pĂ„lidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster