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 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 var der kun én tilbage af alle de servere, der var specificeret i lokale caching-bindinger på alle servere, som var i datacentret i St. Petersborg. Denne DC blev oprindeligt erklæret som ikke-kritisk for os, men blev pludselig et enkelt point of failure.
Det var i denne udflytningsperiode, at kanalen mellem Moskva og Skt. Petersborg faldt ned. Vi stod faktisk uden DNS i fem minutter og kom op igen, da hosteren løste problemet.
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.
- Распределяйте внутренние dns-серверы по разным геолокациям/датацентрам/стойкам/коммутаторам/вводам.
- 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.confDet 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.
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