Top fakapov cián

Minden rendben! 

A nevem Nikita, a Cian mérnöki csapatának a csoportvezetője vagyok. Az egyik feladatom a vállalatnál, hogy nullára csökkentsem az infrastruktúrával kapcsolatos incidensek számát a termelésben.
Amiről alább szó lesz, az sok fájdalmat okozott nekünk, és ennek a cikknek az a célja, hogy megakadályozzuk, hogy mások megismételjék hibáinkat, vagy legalábbis minimalizáljuk azok hatását. 

bevezetés

Réges-régen, amikor a Cian monolitokból állt, és mikroszolgáltatásokról még nem volt utalás, 3-5 oldal ellenőrzésével mértük egy erőforrás elérhetőségét. 

Válaszolnak - minden rendben van, ha sokáig nem válaszolnak - éber. Azt, hogy mennyi ideig kellett munka nélkül lenniük, hogy ez incidensnek minősüljön, az üléseken döntötték el az emberek. Egy csapat mérnök mindig részt vett az eset kivizsgálásában. Amikor a nyomozás befejeződött, írtak egy post mortem - egyfajta jelentést e-mailben a következő formátumban: mi történt, mennyi ideig tartott, mit csináltunk a pillanatban, mit fogunk tenni a jövőben. 

Az oldal fő oldalai vagy hogyan értjük, hogy elértük az alját

 
Annak érdekében, hogy valahogy megértsük a hiba prioritását, azonosítottuk az üzleti funkciók szempontjából legkritikusabb webhelyoldalakat. Használatuk segítségével megszámoljuk a sikeres/sikertelen kérések és időtúllépések számát. Így mérjük az üzemidőt. 

Tegyük fel, hogy rájöttünk, hogy az oldalnak számos szuperfontos része van, amelyek a fő szolgáltatásért – a keresésért és a hirdetések feladásáért – felelősek. Ha a sikertelen kérelmek száma meghaladja az 1%-ot, ez kritikus esemény. Ha a főműsoridőben 15 percen belül a hibaarány meghaladja a 0,1%-ot, akkor ez is kritikus eseménynek minősül. Ezek a kritériumok lefedik a legtöbb incidenst, a többi túlmutat e cikk hatókörén.

A legjobb események Cyan

Tehát határozottan megtanultuk meghatározni, hogy egy incidens történt. 

Most minden eseményt részletesen leírnak, és tükrözik a Jira-eposz. Apropó: erre indítottunk egy külön projektet, FAIL néven - csak epikát lehet benne alkotni. 

Ha összegyűjti az elmúlt néhány év összes kudarcát, a vezetők a következők: 

• mssql-lel kapcsolatos incidensek;
• külső tényezők által okozott események;
• admin hibák.

Nézzük meg részletesebben az adminisztrátorok hibáit, valamint néhány más érdekes kudarcot.

Ötödik hely - „Rendbe helyezés a DNS-ben”

Viharos kedd volt. Úgy döntöttünk, hogy helyreállítjuk a rendet a DNS-fürtben. 

A belső DNS szervereket szerettem volna bind-ről powerdns-re átvinni, ehhez teljesen külön szervereket osztva ki, ahol a DNS-en kívül nincs más. 

A DC-ink minden helyére egy DNS-kiszolgálót helyeztünk el, és eljött a pillanat, hogy áthelyezzük a zónákat a bind-ről a powerdn-re, és az infrastruktúrát új szerverekre cseréljük. 

A költözés közepén az összes szerveren a helyi gyorsítótárazási kötésekben megadott szerverek közül csak egy maradt, amely a szentpétervári adatközpontban volt. Ezt a DC-t eredetileg nem kritikusnak nyilvánították számunkra, de hirtelen egyetlen hibaponttá vált.
Ebben az áthelyezési időszakban esett le a Moszkva és Szentpétervár közötti csatorna. Valójában 5 percre DNS nélkül maradtunk, és újra felkeltünk, amikor a hoster megoldotta a problémát. 

Következtetések:

Ha korábban a munkára való felkészülés során figyelmen kívül hagytuk a külső tényezőket, most már ezek is szerepelnek azon a listán, amire készülünk. És most arra törekszünk, hogy minden komponens le legyen foglalva n-2, és a munka során ezt a szintet le tudjuk csökkenteni n-1-re.

• A cselekvési terv elkészítésekor jelölje meg azokat a pontokat, ahol a szolgáltatás meghiúsulhat, és gondoljon át egy forgatókönyvet, ahol minden „rosszról rosszabbra fordult”.
• A belső DNS-kiszolgálók szétosztása különböző földrajzi helyeken/adatközpontokban/állványokban/kapcsolókban/bemenetekben.
• Minden szerverre telepítsen egy helyi gyorsítótárazó DNS-kiszolgálót, amely átirányítja a kéréseket a fő DNS-kiszolgálókra, és ha nem elérhető, akkor a gyorsítótárból válaszol. 

Negyedik hely - „Rendbe hozni a dolgokat Nginxben”

Egy szép napon csapatunk úgy döntött, hogy "elegünk van ebből", és elkezdődött az nginx konfigurációk újrafeldolgozásának folyamata. A fő cél az, hogy a konfigurációkat intuitív szerkezetbe hozza. Korábban minden „történelmileg megalapozott” volt, és nem hordozott semmilyen logikát. Most minden kiszolgáló_neve átkerült egy azonos nevű fájlba, és az összes konfigurációt mappákba osztották el. A konfig egyébként 253949 sort vagy 7836520 karaktert tartalmaz, és majdnem 7 megabájtot foglal el. A szerkezet legfelső szintje: 

Nginx szerkezet

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

Sokkal jobb lett, de a konfigurációk átnevezése és terjesztése során némelyikük rossz kiterjesztésű volt, és nem került bele az include *.conf direktívába. Ennek eredményeként néhány gazdagép elérhetetlenné vált, és a 301-et visszaküldte a főoldalra. Tekintettel arra, hogy a válaszkód nem 5xx/4xx volt, ezt nem vették azonnal észre, hanem csak reggel. Ezt követően elkezdtünk teszteket írni az infrastruktúra összetevőinek ellenőrzésére.

Következtetések: 

• Szerkezze fel helyesen a konfigurációkat (nem csak az nginxet), és gondolja át a szerkezetet a projekt korai szakaszában. Így érthetőbbé teszi őket a csapat számára, ami viszont csökkenti a TTM-et.
• Írjon teszteket egyes infrastruktúra-összetevőkre. Például: annak ellenőrzése, hogy minden kulcsszerver_neve a megfelelő állapotot adja-e + választörzs. Elég lesz csak néhány szkript kéznél, amelyek az összetevő alapvető funkcióit ellenőrzik, hogy ne eszébe jusson hajnali 3-kor eszeveszetten, mit kell még ellenőrizni. 

Harmadik hely - „Hirtelen elfogyott a hely Cassandrában”

Az adatok folyamatosan gyarapodtak, és minden rendben volt egészen addig a pillanatig, amikor a Cassandra-klaszterben a nagy tokterek javítása nem kezdett kudarcot vallani, mert a tömörítés nem működött rajtuk. 

Egy viharos napon a fürt majdnem tökké változott, mégpedig:

• a klaszterben a teljes hely körülbelül 20%-a maradt;
• Lehetetlen a csomópontok teljes hozzáadása, mert a partíciók helyhiánya miatt a csomópont hozzáadása után nem megy a tisztítás;
• a termelékenység fokozatosan csökken, mivel a tömörítés nem működik; 
• A fürt vészhelyzeti üzemmódban van.

Kilépés – további 5 csomópontot adtunk hozzá tisztítás nélkül, majd elkezdtük szisztematikusan eltávolítani őket a fürtből, és újra beírni őket, mint az üres csomópontokat, amelyeknél elfogyott a hely. Sokkal több időt töltöttünk el, mint szerettük volna. Fennállt a fürt részleges vagy teljes elérhetetlenségének veszélye. 

Következtetések:

• Az összes cassandra szerveren az egyes partíciók helyének legfeljebb 60%-át szabad elfoglalni. 
• Ezeket legfeljebb 50%-os cpu-val kell betölteni.
• Nem szabad megfeledkezni a kapacitástervezésről, és minden komponensnél át kell gondolni, annak sajátosságai alapján.
• Minél több csomópont van a fürtben, annál jobb. A kis mennyiségű adatot tartalmazó szerverek gyorsabban túlterhelődnek, és egy ilyen fürt könnyebben újraéleszthető. 

Második hely - „Eltűntek az adatok a konzuli kulcsérték-tárhelyről”

A szolgáltatások felderítéséhez sokakhoz hasonlóan mi is konzult használunk. De a kulcsértékét a monolit kék-zöld elrendezéséhez is használjuk. Információkat tárol az aktív és inaktív upstreamekről, amelyek a telepítés során helyet cserélnek. Erre a célra egy telepítési szolgáltatást írtak, amely együttműködött a KV-val. Valamikor a KV adatai eltűntek. Memóriából visszaállítva, de számos hibával. Emiatt a feltöltés során az upstreamek terhelése egyenetlenül oszlott el, és sok 502-es hibát kaptunk a CPU túlterheltsége miatt. Ennek eredményeként a KV consultól a postgres-hez költöztünk, ahonnan már nem olyan egyszerű őket eltávolítani.  

Következtetések:

• Az engedély nélküli szolgáltatások nem tartalmazhatnak az oldal működése szempontjából kritikus adatokat. Például, ha nincs jogosultságod az ES-ben, akkor jobb, ha mindenhonnan megtagadod a hozzáférést hálózati szinten, ahol nincs rá szükség, csak a szükségeseket hagyd meg, és állítsd be az action.desstructive_requires_name: true értéket is.
• Előzetesen gyakorolja a biztonsági mentési és helyreállítási mechanizmust. Például készítsen előre egy szkriptet (például Pythonban), amely képes biztonsági másolatot készíteni és visszaállítani.

Első hely - „Nem nyilvánvaló kapitány” 

Egy bizonyos ponton azt észleltük, hogy a terhelés egyenetlen eloszlása ​​az nginx upstream rendszerein olyan esetekben, amikor 10+ szerver volt a háttérben. Tekintettel arra, hogy a round-robin sorrendben 1-től az utolsóig küldte a kéréseket, és minden nginx újratöltés elölről indult, az első upstreamek mindig több kérést kaptak, mint a többiek, ezért lassabban működtek, és az egész webhely szenvedett. Ez a forgalom növekedésével egyre szembetűnőbbé vált. Az nginx egyszerű frissítése, hogy engedélyezze a véletlenszerűséget, nem működött – újra kell csinálnunk egy csomó lua kódot, amely nem indult el az 1.15-ös verzióban (abban a pillanatban). Ki kellett javítanunk az nginx 1.14.2-t, véletlenszerű támogatást beiktatva bele. Ezzel megoldódott a probléma. Ez a hiba megnyeri a „Nem nyilvánvaló kapitány” kategóriát.

Következtetések:

Nagyon érdekes és izgalmas volt felfedezni ezt a hibát). 

• Úgy szervezze meg a megfigyelést, hogy az segítsen gyorsan megtalálni az ilyen ingadozásokat. Például használhatja az ELK-t az rp-ek figyelésére az egyes upstream egyes háttérrendszerein, és figyelheti a válaszidejüket az nginx szempontjából. Ebben az esetben ez segített a probléma azonosításában. 

Ennek eredményeként a legtöbb kudarc elkerülhető lett volna, ha sokkal alaposabban közelítette meg tevékenységét. Mindig emlékeznünk kell Murphy törvényére: Bármi, ami elromolhat, elromlik, és az alapján építsünk össze alkatrészeket. 

Forrás: will.com