ProHoster > Log > administrasjon > Topp fakapov Cyan

Topp fakapov Cyan

Topp fakapov Cyan

Alt bra! 

Jeg heter Nikita, jeg er teamleder for Cians ingeniĂžrteam. Et av mine ansvar i selskapet er Ă„ redusere antall hendelser knyttet til infrastruktur i produksjon til null.
Det som vil bli diskutert nedenfor ga oss mye smerte, og hensikten med denne artikkelen er Ă„ forhindre at andre mennesker gjentar vĂ„re feil eller i det minste minimere deres innvirkning. 

innledning

For lenge siden, da Cian besto av monolitter, og det ikke var noen hint til mikrotjenester ennĂ„, mĂ„lte vi tilgjengeligheten til en ressurs ved Ă„ sjekke 3-5 sider. 

De svarer - alt er bra, hvis de ikke svarer pĂ„ lenge - varsler. Hvor lenge de mĂ„tte ha fri fra jobb for at det skulle bli ansett som en hendelse, ble bestemt av folk i mĂžter. Et team av ingeniĂžrer var alltid involvert i etterforskningen av hendelsen. Da etterforskningen var fullfĂžrt, skrev de en postmortem – en slags rapport pĂ„ e-post i formatet: hva skjedde, hvor lenge det varte, hva vi gjorde i Ăžyeblikket, hva vi skal gjĂžre i fremtiden. 

Hovedsidene til nettstedet eller hvordan vi forstÄr at vi har truffet bunnen

 
For pĂ„ en eller annen mĂ„te Ă„ forstĂ„ prioriteringen av feilen, har vi identifisert de mest kritiske sidene for forretningsfunksjonalitet. Ved Ă„ bruke dem teller vi antall vellykkede/mislykkede forespĂžrsler og tidsavbrudd. Slik mĂ„ler vi oppetid. 

La oss si at vi fant ut at det er en rekke superviktige deler av nettstedet som er ansvarlige for hovedtjenesten – sĂžking og innsending av annonser. Hvis antallet forespĂžrsler som mislykkes overstiger 1 %, er dette en kritisk hendelse. Hvis feilraten innen 15 minutter i sendetid overstiger 0,1 %, anses dette ogsĂ„ som en kritisk hendelse. Disse kriteriene dekker de fleste hendelsene, resten er utenfor rammen av denne artikkelen.

Topp fakapov Cyan

Topp beste hendelser Cyan

SĂ„ vi har definitivt lĂŠrt Ă„ fastslĂ„ det faktum at en hendelse skjedde. 

NĂ„ er hver hendelse beskrevet i detalj og reflektert i Jira-eposet. Forresten: for dette startet vi et eget prosjekt, kalt det FAIL - bare epos kan lages i det. 

Hvis du samler alle feilene de siste Ă„rene, er lederne: 

  • mssql-relaterte hendelser;
  • hendelser forĂ„rsaket av eksterne faktorer;
  • admin feil.

La oss se mer detaljert pÄ feilene til administratorer, samt noen andre interessante feil.

Femteplass - "Å sette ting i orden i DNS"

Det var en stormfull tirsdag. Vi bestemte oss for Ă„ gjenopprette orden i DNS-klyngen. 

Jeg Ăžnsket Ă„ overfĂžre interne DNS-servere fra bind til powerdns, og tildele helt separate servere for dette, der det ikke er noe annet enn DNS. 

Vi plasserte Ă©n DNS-server pĂ„ hver plassering av vĂ„re DC-er, og Ăžyeblikket kom for Ă„ flytte soner fra bind til powerdns og bytte infrastrukturen til nye servere. 

Midt i flyttingen, av alle ting servereAv serverne som var spesifisert i lokale mellomlagringsbindinger, var det bare Ă©n som gjensto – den i datasenteret i St. Petersburg. Dette datasenteret ble opprinnelig erklĂŠrt som ikke-kritisk for oss, men ble plutselig et enkelt feilpunkt.
Det var i denne overgangsperioden at kanalen mellom Moskva og St. Petersburg gikk ned. Vi ble i praksis stĂ„ende uten DNS i fem minutter og kom oss tilbake da vert fikset problemene. 

Konklusjoner:

Hvis vi tidligere forsÞmte eksterne faktorer under forberedelsene til arbeid, er de nÄ ogsÄ inkludert i listen over hva vi forbereder oss pÄ. Og nÄ streber vi etter Ä sikre at alle komponenter er reservert n-2, og under arbeidet kan vi senke dette nivÄet til n-1.

  • NĂ„r du lager en handlingsplan, merk av punktene der tjenesten kan svikte, og tenk gjennom et scenario der alt gikk «fra vondt til verre» pĂ„ forhĂ„nd.
  • Distribuer interne DNS-servere pĂ„ tvers av forskjellige geolokasjoner/datasentre/rack/svitsjer/innganger.
  • PĂ„ hver server, installer en lokal caching DNS-server, som omdirigerer forespĂžrsler til hoved-DNS-serverne, og hvis den ikke er tilgjengelig, vil den svare fra cachen. 

Fjerdeplass - "Å sette ting i orden i Nginx"

En vakker dag bestemte teamet vĂ„rt at "vi har fĂ„tt nok av dette," og prosessen med Ă„ refaktorisere nginx-konfigurasjoner begynte. HovedmĂ„let er Ă„ bringe konfigurasjonene til en intuitiv struktur. Tidligere var alt "historisk etablert" og hadde ingen logikk. NĂ„ har hver server_name blitt flyttet til en fil med samme navn og alle konfigurasjonene har blitt distribuert til mapper. Konfigurasjonen inneholder forresten 253949 linjer eller 7836520 tegn og tar opp nesten 7 megabyte. ToppnivĂ„ av struktur: 

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 ble mye bedre, men i prosessen med Ă„ gi nytt navn og distribuere konfigurasjoner, hadde noen av dem feil utvidelse og ble ikke inkludert i include *.conf-direktivet. Som et resultat ble noen verter utilgjengelige og returnerte 301 til hovedsiden. PĂ„ grunn av at svarkoden ikke var 5xx/4xx ble dette ikke lagt merke til umiddelbart, men fĂžrst om morgenen. Etter det begynte vi Ă„ skrive tester for Ă„ sjekke infrastrukturkomponenter.

Konklusjoner: 

  • Strukturer konfigurasjonene dine riktig (ikke bare nginx) og tenk gjennom strukturen pĂ„ et tidlig stadium av prosjektet. PĂ„ denne mĂ„ten vil du gjĂžre dem mer forstĂ„elige for teamet, noe som igjen vil redusere TTM.
  • Skriv tester for noen infrastrukturkomponenter. For eksempel: sjekke at alle nĂžkkelservernavn gir riktig status + svartekst. Det vil vĂŠre nok Ă„ bare ha noen fĂ„ skript for hĂ„nden som sjekker de grunnleggende funksjonene til komponenten, for ikke Ă„ febrilsk huske klokken 3 hva annet som mĂ„ sjekkes. 

Tredjeplass - "Plutselig gikk tom for plass i Cassandra"

Dataene vokste jevnt og trutt, og alt var bra inntil det Ăžyeblikket da reparasjonen av store kofferter begynte Ă„ mislykkes i Cassandra-klyngen, fordi komprimering ikke kunne fungere pĂ„ dem. 

En stormfull dag ble klyngen nesten til et gresskar, nemlig:

  • det var omtrent 20 % av den totale plassen igjen i klyngen;
  • Det er umulig Ă„ legge til noder fullt ut, fordi opprydding ikke gĂ„r gjennom etter Ă„ ha lagt til en node pĂ„ grunn av mangel pĂ„ plass pĂ„ partisjonene;
  • produktiviteten faller gradvis fordi komprimeringen ikke fungerer; 
  • Klyngen er i nĂždmodus.

Topp fakapov Cyan

Avslutt - vi la til 5 noder til uten opprydding, hvoretter vi begynte Ă„ systematisk fjerne dem fra klyngen og gĂ„ inn i dem igjen, som tomme noder som hadde gĂ„tt tom for plass. Det ble brukt mye mer tid enn vi skulle Ăžnske. Det var en risiko for delvis eller fullstendig utilgjengelighet av klyngen. 

Konklusjoner:

  • PĂ„ alle cassandra-servere bĂžr ikke mer enn 60 % av plassen pĂ„ hver partisjon vĂŠre okkupert. 
  • De skal ikke lastes med mer enn 50 % cpu.
  • Du bĂžr ikke glemme kapasitetsplanlegging og trenger Ă„ tenke gjennom den for hver komponent, basert pĂ„ dens spesifikasjoner.
  • Jo flere noder i klyngen, jo bedre. Servere som inneholder en liten mengde data overbelastes raskere, og en slik klynge er lettere Ă„ gjenopplive. 

Andreplass – «Data forsvant fra konsulnĂžkkelverdilagring»

For tjenesteoppdagelse bruker vi, som mange, konsul. Men vi bruker ogsĂ„ nĂžkkelverdien for blĂ„grĂžnn utforming av monolitten. Den lagrer informasjon om aktive og inaktive oppstrĂžms, som bytter plass under utrulling. For dette formĂ„let ble det skrevet en distribusjonstjeneste som samhandlet med KV. PĂ„ et tidspunkt forsvant dataene fra KV. Gjenopprettet fra minnet, men med en rekke feil. Som et resultat, under opplastingen, ble belastningen pĂ„ oppstrĂžmsene fordelt ujevnt, og vi fikk mange 502-feil pĂ„ grunn av at backends ble overbelastet pĂ„ CPU. Det fĂžrte til at vi flyttet fra konsul KV til postgres, hvor det ikke lenger er sĂ„ lett Ă„ fjerne dem.  

Konklusjoner:

  • Tjenester uten autorisasjon skal ikke inneholde data som er kritiske for driften av nettstedet. For eksempel, hvis du ikke har autorisasjon i ES, ville det vĂŠre bedre Ă„ nekte tilgang pĂ„ nettverksnivĂ„ fra alle steder der det ikke er nĂždvendig, la bare de nĂždvendige, og ogsĂ„ angi action.destructive_requires_name: true.
  • Øv pĂ„ sikkerhetskopierings- og gjenopprettingsmekanismen pĂ„ forhĂ„nd. Lag for eksempel et skript pĂ„ forhĂ„nd (for eksempel i python) som kan sikkerhetskopiere og gjenopprette.

FĂžrste plass - "Captain Unobvious" 

PÄ et tidspunkt la vi merke til en ujevn fordeling av belastningen pÄ nginx oppstrÞms i tilfeller der det var 10+ servere i backend. PÄ grunn av det faktum at round-robin sendte forespÞrsler fra 1. til siste oppstrÞms i rekkefÞlge, og hver nginx reload startet pÄ nytt, mottok de fÞrste oppstrÞmsene alltid flere forespÞrsler enn resten. Som et resultat jobbet de tregere og hele siden led. Dette ble stadig mer merkbart etter hvert som trafikkmengden Þkte. Bare Ä oppdatere nginx for Ä aktivere tilfeldig fungerte ikke - vi mÄ gjÞre om en haug med lua-kode som ikke tok av pÄ versjon 1.15 (i det Þyeblikket). Vi mÄtte lappe vÄr nginx 1.14.2, og introduserte tilfeldig stÞtte i den. Dette lÞste problemet. Denne feilen vinner kategorien "Kaptein Non-Obviousness".

Konklusjoner:

Det var veldig interessant og spennende Ă„ utforske denne feilen). 

  • Organiser overvĂ„kingen din slik at den hjelper deg Ă„ finne slike svingninger raskt. Du kan for eksempel bruke ELK til Ă„ overvĂ„ke rps pĂ„ hver backend av hver oppstrĂžms, overvĂ„ke responstiden deres fra nginx synspunkt. I dette tilfellet hjalp dette oss med Ă„ identifisere problemet. 

Som et resultat kunne de fleste feilene vĂŠrt unngĂ„tt med en mer nĂžye tilnĂŠrming til det du gjorde. Vi mĂ„ alltid huske Murphys lov: Alt som kan gĂ„ galt vil gĂ„ galt, og bygge komponenter basert pĂ„ det. 

Kilde: www.habr.com

Legg til en kommentar