Topp fakapov Cyan

Med vänliga hälsningar! 

Jag heter Nikita, jag är teamledare för Cians ingenjörsteam. Ett av mina ansvarsområden på företaget är att minska antalet incidenter relaterade till infrastruktur i produktionen till noll.
Det som kommer att diskuteras nedan gav oss mycket smärta, och syftet med den här artikeln är att förhindra att andra människor upprepar våra misstag eller åtminstone minimerar deras inverkan. 

ingressen

För länge sedan, när Cian bestod av monoliter, och det inte fanns några antydan om mikrotjänster ännu, mätte vi tillgängligheten av en resurs genom att kontrollera 3-5 sidor. 

De svarar - allt är bra, om de inte svarar på länge - varna. Hur länge de behövde vara lediga från jobbet för att det skulle anses vara en incident bestämdes av folk på möten. Ett team av ingenjörer var alltid involverat i utredningen av händelsen. När utredningen var klar skrev de en obduktion – en slags rapport via mejl i formatet: vad hände, hur länge det varade, vad vi gjorde i stunden, vad vi kommer att göra i framtiden. 

Sidans huvudsidor eller hur vi förstår att vi har nått botten

 
För att på något sätt förstå prioriteringen av felet har vi identifierat de mest kritiska webbplatssidorna för affärsfunktionalitet. Med hjälp av dem räknar vi antalet lyckade/misslyckade förfrågningar och timeouts. Så här mäter vi upptid. 

Låt oss säga att vi fick reda på att det finns ett antal superviktiga delar av webbplatsen som är ansvariga för huvudtjänsten - att söka och skicka in annonser. Om antalet förfrågningar som misslyckas överstiger 1 % är detta en kritisk incident. Om felfrekvensen inom 15 minuter under bästa sändningstid överstiger 0,1 %, anses detta också vara en kritisk incident. Dessa kriterier täcker de flesta av incidenterna, resten ligger utanför ramen för denna artikel.

Topp bästa incidenter Cian

Så vi har definitivt lärt oss att fastställa det faktum att en incident inträffade. 

Nu beskrivs varje incident i detalj och återspeglas i Jira-eposet. Förresten: för detta startade vi ett separat projekt, kallat det FAIL - bara epos kan skapas i det. 

Om du samlar alla misslyckanden under de senaste åren är ledarna: 

• mssql-relaterade incidenter;
• incidenter orsakade av yttre faktorer;
• admin fel.

Låt oss titta mer i detalj på administratörers misstag, liksom några andra intressanta misslyckanden.

Femte plats - "Rätta ordning i DNS"

Det var en stormig tisdag. Vi bestämde oss för att återställa ordningen i DNS-klustret. 

Jag ville överföra interna DNS-servrar från bind till powerdns, och tilldela helt separata servrar för detta, där det inte finns något förutom DNS. 

Vi placerade en DNS-server på varje plats i våra DC:er, och ögonblicket kom att flytta zoner från bind till powerdns och byta infrastrukturen till nya servrar. 

Mitt under flytten, av alla servrar som specificerades i lokala cachingbindningar på alla servrar, återstod bara en, som fanns i datacentret i St. Petersburg. Denna DC förklarades från början som icke-kritisk för oss, men blev plötsligt en enda punkt av misslyckande.
Det var under denna flyttperiod som kanalen mellan Moskva och St Petersburg föll ner. Vi var faktiskt lämnade utan DNS i fem minuter och kom upp igen när hostaren åtgärdade problemet. 

Slutsatser:

Om vi ​​tidigare försummade externa faktorer under förberedelserna för arbetet, finns de nu också med i listan över vad vi förbereder oss för. Och nu strävar vi efter att säkerställa att alla komponenter är reserverade n-2, och under arbetets gång kan vi sänka denna nivå till n-1.

• När du gör upp en handlingsplan, markera de punkter där tjänsten kan misslyckas och tänk igenom ett scenario där allt gick "från dåligt till värre" i förväg.
• Distribuera interna DNS-servrar över olika geolokaliseringar/datacenter/rack/switchar/ingångar.
• Installera en lokal cachande DNS-server på varje server, som omdirigerar förfrågningar till de huvudsakliga DNS-servrarna, och om den inte är tillgänglig kommer den att svara från cachen. 

Fjärde plats - "Rätta ordning i Nginx"

En vacker dag beslutade vårt team att "vi har fått nog av det här", och processen med att omstrukturera nginx-konfigurationer började. Huvudmålet är att få konfigurationerna till en intuitiv struktur. Tidigare var allt "historiskt etablerat" och bar ingen logik. Nu har varje server_name flyttats till en fil med samma namn och alla konfigurationer har distribuerats till mappar. Konfigurationen innehåller förresten 253949 rader eller 7836520 tecken och tar upp nästan 7 megabyte. Översta strukturnivå: 

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 mycket bättre, men i processen med att döpa om och distribuera konfigurationer hade några av dem fel tillägg och inkluderades inte i include *.conf-direktivet. Som ett resultat blev vissa värdar otillgängliga och returnerade 301 till huvudsidan. På grund av att svarskoden inte var 5xx/4xx märktes detta inte direkt utan först på morgonen. Efter det började vi skriva tester för att kontrollera infrastrukturkomponenter.

Slutsatser: 

• Strukturera dina konfigurationer korrekt (inte bara nginx) och tänk igenom strukturen i ett tidigt skede av projektet. På så sätt kommer du att göra dem mer förståeliga för teamet, vilket i sin tur kommer att minska TTM.
• Skriv tester för vissa infrastrukturkomponenter. Till exempel: kontrollera att alla nyckelservernamn ger korrekt status + svarstext. Det räcker med att bara ha några skript till hands som kontrollerar komponentens grundläggande funktioner, för att inte frenetiskt komma ihåg klockan 3 vad mer som behöver kontrolleras. 

Tredje plats - "Plötsligt fick utrymme i Cassandra"

Data växte stadigt och allt var bra tills det ögonblick då reparationen av stora utrymmen började misslyckas i Cassandra-klustret, eftersom komprimering inte kunde fungera på dem. 

En stormig dag förvandlades klungan nästan till en pumpa, nämligen:

• det fanns cirka 20 % av det totala utrymmet kvar i klustret;
• Det är omöjligt att lägga till noder helt, eftersom rensningen inte går igenom efter att en nod lagts till på grund av brist på utrymme på partitionerna;
• produktiviteten sjunker gradvis eftersom packning inte fungerar; 
• Klustret är i nödläge.

Avsluta - vi lade till ytterligare 5 noder utan rensning, varefter vi började systematiskt ta bort dem från klustret och gå in i dem igen, som tomma noder som hade slut på utrymme. Det gick åt mycket mer tid än vi skulle önska. Det fanns en risk för att klustret helt eller delvis skulle vara otillgängligt. 

Slutsatser:

• På alla cassandra-servrar bör inte mer än 60 % av utrymmet på varje partition vara upptaget. 
• De bör laddas med högst 50 % cpu.
• Du bör inte glömma kapacitetsplaneringen och behöver tänka igenom den för varje komponent, baserat på dess specifika egenskaper.
• Ju fler noder i klustret, desto bättre. Servrar som innehåller en liten mängd data överbelastas snabbare, och ett sådant kluster är lättare att återuppliva. 

Andra plats - "Data försvann från konsuls nyckel-värdelagring"

För tjänsteupptäckt använder vi, som många, konsul. Men vi använder också dess nyckel-värde för blågrön layout av monoliten. Den lagrar information om aktiva och inaktiva uppströms, som byter plats under driftsättning. För detta ändamål skrevs en driftsättningstjänst som samverkade med KV. Vid något tillfälle försvann uppgifterna från KV. Återställd från minnet, men med ett antal fel. Som ett resultat, under uppladdningen, fördelades belastningen på uppströmsströmmarna ojämnt, och vi fick många 502-fel på grund av att backends var överbelastade på CPU:n. Som ett resultat av detta flyttade vi från konsul KV till postgres, varifrån det inte längre är så lätt att ta bort dem.  

Slutsatser:

• Tjänster utan tillstånd bör inte innehålla data som är kritiska för driften av webbplatsen. Till exempel, om du inte har behörighet i ES, skulle det vara bättre att neka åtkomst på nätverksnivå överallt där det inte behövs, lämna bara de nödvändiga, och även ställa in action.destructive_requires_name: true.
• Öva på säkerhetskopierings- och återställningsmekanismen i förväg. Gör till exempel ett skript i förväg (till exempel i python) som kan säkerhetskopiera och återställa.

Första plats - "Captain Unobvious" 

Vid något tillfälle märkte vi en ojämn fördelning av belastningen på nginx uppströms i fall där det fanns 10+ servrar i backend. På grund av det faktum att round-robin skickade förfrågningar från 1:a till sista uppströms i ordning, och varje nginx-reload började om, fick de första uppströmsarna alltid fler förfrågningar än resten, vilket ledde till att de arbetade långsammare och hela sajten led. Detta blev allt mer märkbart i takt med att trafikmängden ökade. Att bara uppdatera nginx för att aktivera slumpmässigt fungerade inte - vi måste göra om ett gäng lua-kod som inte tog fart på version 1.15 (vid det ögonblicket). Vi var tvungna att patcha vår nginx 1.14.2 och introducerade slumpmässigt stöd i den. Detta löste problemet. Denna bugg vinner kategorin "Kapten Non-Obviousness".

Slutsatser:

Det var väldigt intressant och spännande att utforska denna bugg). 

• Organisera din övervakning så att den hjälper dig att snabbt hitta sådana fluktuationer. Till exempel kan du använda ELK för att övervaka rps på varje backend av varje uppströms, övervaka deras svarstid från nginx synvinkel. I det här fallet hjälpte detta oss att identifiera problemet. 

Som ett resultat kunde de flesta av misslyckandena ha undvikits med en mer noggrann inställning till vad du gjorde. Vi måste alltid komma ihåg Murphys lag: Allt som kan gå fel kommer att gå fel, och bygga komponenter baserat på det. 

Källa: will.com