Nejlepší fakapov azurová

Dobré pro všechny! 

Jmenuji se Nikita, jsem vedoucí týmu inženýrského týmu Cian. Jednou z mých povinností ve společnosti je snížit počet incidentů souvisejících s infrastrukturou ve výrobě na nulu.
To, o čem bude řeč níže, nám přineslo mnoho bolesti a účelem tohoto článku je zabránit ostatním lidem v opakování našich chyb nebo alespoň minimalizovat jejich dopad. 

Preambule

Kdysi dávno, když se Cian skládal z monolitů a ještě neexistovaly žádné náznaky mikroslužeb, jsme měřili dostupnost zdroje kontrolou 3-5 stránek. 

Odpovídají - vše je v pořádku, pokud dlouho neodpovídají - upozornění. O tom, jak dlouho museli být mimo práci, aby to bylo považováno za incident, rozhodovali lidé na poradách. Do vyšetřování incidentu se vždy zapojil tým inženýrů. Když bylo vyšetřování ukončeno, napsali pitvu - jakousi zprávu e-mailem ve formátu: co se stalo, jak dlouho to trvalo, co jsme momentálně dělali, co budeme dělat v budoucnu. 

Hlavní stránky webu aneb jak chápeme, že jsme si sáhli na dno

 
Abychom nějak porozuměli prioritě chyby, identifikovali jsme nejkritičtější stránky webu pro obchodní funkce. Pomocí nich počítáme počet úspěšných/neúspěšných požadavků a timeoutů. Takto měříme dobu provozuschopnosti. 

Řekněme, že jsme zjistili, že na webu existuje řada superdůležitých sekcí, které zodpovídají za hlavní službu – vyhledávání a podávání inzerátů. Pokud počet požadavků, které selžou, překročí 1 %, jedná se o kritický incident. Pokud během 15 minut v hlavním vysílacím čase chybovost překročí 0,1 %, pak je to také považováno za kritický incident. Tato kritéria pokrývají většinu incidentů, ostatní jsou nad rámec tohoto článku.

Nejlepší nejlepší incidenty Cian

Rozhodně jsme se tedy naučili určit skutečnost, že k incidentu došlo. 

Nyní je každý incident podrobně popsán a reflektován v eposu Jira. Mimochodem: kvůli tomu jsme založili samostatný projekt, nazvaný FAIL - v něm lze vytvářet pouze eposy. 

Pokud shromáždíte všechna selhání za posledních několik let, vůdci jsou: 

• incidenty související s mssql;
• incidenty způsobené vnějšími faktory;
• chyby správce.

Podívejme se podrobněji na chyby správců a také na některá další zajímavá selhání.

Páté místo - „Uvedení věcí do pořádku v DNS“

Bylo bouřlivé úterý. Rozhodli jsme se obnovit pořádek v clusteru DNS. 

Chtěl jsem přenést interní servery DNS z bind na powerdns a přidělit k tomu zcela samostatné servery, kde není nic kromě DNS. 

Do každého umístění našich DC jsme umístili jeden DNS server a nastal okamžik přesunout zóny z bind na powerdns a přepnout infrastrukturu na nové servery. 

Uprostřed tohoto přesunu ze všech serverů, které byly specifikovány v místních cachovacích vazbách na všech serverech, zůstal pouze jeden, který byl v datovém centru v St. Petersburgu. Toto DC bylo původně prohlášeno za nekritické pro nás, ale najednou se stalo jediným bodem selhání.
Právě během tohoto období přesídlení spadl kanál mezi Moskvou a Petrohradem. Ve skutečnosti jsme zůstali bez DNS po dobu pěti minut a vrátili jsme se, když hostitel problém vyřešil. 

Závěry:

Jestliže jsme dříve při přípravě na práci zanedbávali vnější faktory, nyní jsou také zařazeny do seznamu toho, na co se připravujeme. A nyní se snažíme zajistit, aby všechny komponenty byly rezervovány n-2 a během práce můžeme tuto úroveň snížit na n-1.

• Při sestavování akčního plánu si označte body, kde může služba selhat, a předem si promyslete scénář, kdy vše půjde „od špatného k horšímu“.
• Distribuujte interní servery DNS napříč různými geolokacemi/datovými centry/racky/přepínači/vstupy.
• Na každý server nainstalujte lokální server DNS pro ukládání do mezipaměti, který přesměrovává požadavky na hlavní servery DNS, a pokud není dostupný, odpoví z mezipaměti. 

Čtvrté místo - „Uvedení věcí do pořádku v Nginx“

Jednoho krásného dne se náš tým rozhodl, že „už toho máme dost“, a začal proces refaktorování konfigurací nginx. Hlavním cílem je přivést konfigurace do intuitivní struktury. Dříve bylo vše „historicky založeno“ a neobsahovalo žádnou logiku. Nyní byl každý server_name přesunut do souboru se stejným názvem a všechny konfigurace byly distribuovány do složek. Mimochodem, konfigurace obsahuje 253949 řádků nebo 7836520 znaků a zabírá téměř 7 megabajtů. Nejvyšší úroveň konstrukce: 

Struktura Nginx

├── 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

Stalo se to mnohem lepší, ale v procesu přejmenování a distribuce konfigurací měly některé z nich špatné rozšíření a nebyly zahrnuty do direktivy include *.conf. V důsledku toho se někteří hostitelé stali nedostupnými a vrátili se 301 na hlavní stránku. Vzhledem k tomu, že kód odpovědi nebyl 5xx/4xx, nebylo to zaznamenáno okamžitě, ale až ráno. Poté jsme začali psát testy pro kontrolu komponent infrastruktury.

Závěry: 

• Strukturujte své konfigurace správně (nejen nginx) a promyslete strukturu v rané fázi projektu. Tímto způsobem je učiníte srozumitelnějšími pro tým, což zase sníží TTM.
• Napište testy pro některé součásti infrastruktury. Například: kontrola, zda všechny klíče server_name uvádějí správný stav + tělo odpovědi. Bude stačit mít po ruce pár skriptů, které kontrolují základní funkce komponenty, abyste si ve 3 ráno zběsile nevzpomínali, co je ještě potřeba zkontrolovat. 

Třetí místo - „Na Cassandře náhle došlo místo“

Data plynule přibývala a vše bylo v pořádku až do okamžiku, kdy oprava velkých casespace začala selhávat v clusteru Cassandra, protože na nich nemohlo fungovat zhutňování. 

Jednoho bouřlivého dne se shluk téměř proměnil v dýni, konkrétně:

• v shluku zbývalo asi 20 % celkového prostoru;
• Není možné plně přidat uzly, protože vyčištění neproběhne po přidání uzlu kvůli nedostatku místa na oddílech;
• produktivita postupně klesá, protože zhutňování nefunguje; 
• Cluster je v nouzovém režimu.

Exit – přidali jsme 5 dalších uzlů bez vyčištění, načež jsme je začali systematicky odstraňovat z clusteru a znovu do nich vstupovat, jako prázdné uzly, kterým došel prostor. Strávili jsme mnohem více času, než bychom chtěli. Hrozila částečná nebo úplná nedostupnost clusteru. 

Závěry:

• Na všech serverech cassandra by nemělo být obsazeno více než 60 % prostoru na každém oddílu. 
• Neměly by být načteny na více než 50 % CPU.
• Neměli byste zapomínat na kapacitní plánování a je třeba jej promyslet u každé součásti na základě jejích specifik.
• Čím více uzlů v clusteru, tím lépe. Servery obsahující malé množství dat se rychleji přetěžují a takový cluster se snadněji oživuje. 

Druhé místo – „Data zmizela z úložiště párů klíč–hodnota konzula“

Pro zjišťování služeb používáme, jako mnozí další, konzul. Ale používáme také jeho klíč-hodnota pro modro-zelené rozložení monolitu. Ukládá informace o aktivních a neaktivních upstreamech, které během nasazení mění místa. Za tímto účelem byla napsána služba nasazení, která interagovala s KV. V určitém okamžiku data z KV zmizela. Obnoveno z paměti, ale s řadou chyb. Výsledkem bylo, že během nahrávání byla zátěž na upstreamech rozložena nerovnoměrně a dostali jsme mnoho chyb 502 kvůli přetížení backendů na CPU. V důsledku toho jsme se přesunuli z konzula KV na postgres, odkud už není tak snadné je odstranit.  

Závěry:

• Služby bez jakékoli autorizace by neměly obsahovat data kritická pro provoz webu. Pokud například nemáte oprávnění v ES, bylo by lepší odepřít přístup na úrovni sítě odkudkoli, kde není potřeba, ponechat jen ty nezbytné a také nastavit action.destructive_requires_name: true.
• Procvičte si svůj mechanismus zálohování a obnovy předem. Například si předem vytvořte skript (například v Pythonu), který umí zálohovat a obnovovat.

První místo - „Kapitán Jednoznačný“ 

V určitém okamžiku jsme zaznamenali nerovnoměrné rozložení zátěže na nginx upstream v případech, kdy v backendu bylo 10+ serverů. Vzhledem k tomu, že round-robin posílal požadavky od 1. do posledního upstreamu v pořadí a každé opětovné načítání nginx začalo znovu, první upstreamy vždy dostávaly více požadavků než ostatní, v důsledku toho pracovaly pomaleji a celý web trpěl. To bylo stále patrnější, jak objem dopravy rostl. Pouhá aktualizace nginx, aby umožnila náhodný výběr, nefungovala - musíme znovu udělat spoustu lua kódu, který se ve verzi 1.15 (v tu chvíli) nespustil. Museli jsme opravit náš nginx 1.14.2 a zavést do něj náhodnou podporu. Tím se problém vyřešil. Tato chyba vítězí v kategorii „Nezřejmost kapitána“.

Závěry:

Bylo velmi zajímavé a vzrušující prozkoumat tuto chybu). 

• Uspořádejte si sledování tak, aby vám pomohlo takové výkyvy rychle najít. Můžete například použít ELK ke sledování rps na každém backendu každého upstreamu, sledovat jejich dobu odezvy z pohledu nginx. V tomto případě nám to pomohlo identifikovat problém. 

Výsledkem bylo, že většině selhání bylo možné předejít svědomitějším přístupem k tomu, co jste dělali. Vždy si musíme pamatovat Murphyho zákon: Cokoli, co se může pokazit, se pokazí, a sestavovat komponenty na jeho základě. 

Zdroj: www.habr.com