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 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 serverne som var spesifisert i lokale caching-bindinger på alle servere, var det bare én igjen, som var i datasenteret i St. Petersburg. Denne DC ble opprinnelig erklært som ikke-kritisk for oss, men ble plutselig et enkelt feilpunkt.
Det var i denne perioden med flytting at kanalen mellom Moskva og St. Petersburg falt ned. Vi ble faktisk stående uten DNS i fem minutter og kom oss opp igjen da hosteren løste problemet. 

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.

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