Sve dobro!
Moje ime je Nikita, vođa sam tima Cian inženjeringa. Jedna od mojih obaveza u kompaniji je da smanjim broj incidenata vezanih za infrastrukturu u proizvodnji na nulu.
Ono o čemu će biti riječi u nastavku donijelo nam je mnogo bola, a svrha ovog članka je spriječiti druge ljude da ponove naše greške ili barem umanjuju njihov utjecaj.
Preambula
Davno, kada se Cian sastojao od monolita, a još nije bilo naznaka mikroservisa, mjerili smo dostupnost resursa provjeravanjem 3-5 stranica.
Odgovaraju - sve je u redu, ako se dugo ne javljaju - uzbuna. Koliko dugo su morali biti van posla da bi se to smatralo incidentom, odlučivali su ljudi na sastancima. Tim inženjera je uvijek bio uključen u istragu incidenta. Kada je istraga završena, napisali su obdukciju - svojevrsni izvještaj mejlom u formatu: šta se dogodilo, koliko je trajalo, šta smo uradili u ovom trenutku, šta ćemo raditi u budućnosti.
Glavne stranice stranice ili kako mi razumijemo da smo dotakli dno
Kako bismo nekako razumjeli prioritet greške, identificirali smo najkritičnije stranice web-mjesta za poslovnu funkcionalnost. Koristeći ih, brojimo broj uspješnih/neuspješnih zahtjeva i vremenskih ograničenja. Ovako mjerimo vrijeme rada.
Recimo da smo saznali da postoji niz super važnih sekcija na sajtu koje su odgovorne za glavnu uslugu – pretraživanje i slanje oglasa. Ako broj neuspjelih zahtjeva prelazi 1%, ovo je kritičan incident. Ako u roku od 15 minuta u udarnom terminu stopa greške pređe 0,1%, onda se i ovo smatra kritičnim incidentom. Ovi kriteriji pokrivaju većinu incidenata, a ostali su izvan okvira ovog članka.
Najbolji najbolji incidenti Cian
Dakle, definitivno smo naučili da utvrdimo činjenicu da se incident dogodio.
Sada je svaki incident detaljno opisan i reflektovan u epu Jira. Usput: za ovo smo pokrenuli poseban projekat, nazvan FAIL - u njemu se mogu stvarati samo epovi.
Ako sakupite sve neuspjehe u proteklih nekoliko godina, lideri su:
- incidenti povezani sa mssql;
- incidenti uzrokovani vanjskim faktorima;
- administratorske greške.
Pogledajmo detaljnije greške administratora, kao i neke druge zanimljive propuste.
Peto mjesto - “Dovođenje stvari u red u DNS-u”
Bio je buran utorak. Odlučili smo da uspostavimo red u DNS klasteru.
Želio sam da prenesem interne DNS servere sa bind na powerdns, dodijelivši potpuno odvojene servere za ovo, gdje nema ničega osim DNS-a.
Postavili smo po jedan DNS server na svaku lokaciju naših DC-ova i došao je trenutak da se zone premjeste sa bind na powerdns i prebacimo infrastrukturu na nove servere.
U jeku selidbe, od svih servera koji su bili specificirani u lokalnom keširanju na svim serverima, ostao je samo jedan, koji je bio u data centru u Sankt Peterburgu. Ovaj DC je u početku deklariran kao nekritičan za nas, ali je odjednom postao jedna jedina tačka neuspjeha.
U tom periodu preseljenja pao je kanal između Moskve i Sankt Peterburga. Mi smo zapravo ostali bez DNS-a pet minuta i vratili se kada je hoster riješio problem.
Zaključci:
Ako smo ranije zanemarivali spoljne faktore tokom priprema za rad, sada su i oni uvršteni u listu onoga za šta se spremamo. I sada se trudimo da sve komponente budu rezervisane n-2, a tokom rada možemo spustiti ovaj nivo na n-1.
- Prilikom sastavljanja akcionog plana, označite tačke u kojima servis može pokvariti i unaprijed razmislite o scenariju u kojem je sve išlo od lošeg ka gorem.
- Distribuirajte interne DNS servere na različite geolokacije/centre podataka/rekove/prekidače/ulaze.
- Na svakom serveru instalirajte lokalni DNS server za keširanje, koji preusmjerava zahtjeve na glavne DNS servere, a ako je nedostupan, odgovarat će iz keša.
Četvrto mjesto - “Dovođenje stvari u red u Nginxu”
Jednog lijepog dana, naš tim je odlučio da nam je dosta ovoga i počeo je proces refaktoriranja nginx konfiguracija. Glavni cilj je dovesti konfiguracije u intuitivnu strukturu. Ranije je sve bilo „istorijski utvrđeno“ i nije imalo nikakvu logiku. Sada je svaki server_name premješten u datoteku istog imena i sve konfiguracije su raspoređene u foldere. Inače, konfiguracija sadrži 253949 linija ili 7836520 karaktera i zauzima skoro 7 megabajta. Najviši nivo strukture:
Nginx struktura
├── 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.confPostalo je mnogo bolje, ali u procesu preimenovanja i distribucije konfiguracija, neke od njih su imale pogrešnu ekstenziju i nisu bile uključene u include *.conf direktivu. Kao rezultat toga, neki hostovi su postali nedostupni i vratili 301 na glavnu stranicu. Zbog činjenice da kod odgovora nije bio 5xx/4xx, to se nije primijetilo odmah, već tek ujutro. Nakon toga smo počeli pisati testove za provjeru infrastrukturnih komponenti.
Zaključci:
- Pravilno strukturirajte svoje konfiguracije (ne samo nginx) i razmislite o strukturi u ranoj fazi projekta. Na ovaj način ćete ih učiniti razumljivijima timu, što će zauzvrat smanjiti TTM.
- Napišite testove za neke infrastrukturne komponente. Na primjer: provjeravanje da li svi ključni server_names daju ispravan status + tijelo odgovora. Biće dovoljno imati pri ruci samo nekoliko skripti koje provjeravaju osnovne funkcije komponente, kako se u 3 ujutro ne bi grčevito sjećali šta još treba provjeriti.
Treće mjesto - „Iznenada mi je ponestalo prostora u Kasandri”
Podaci su stalno rasli i sve je bilo u redu sve do trenutka kada je popravka velikih kućišta počela da propada u klasteru Cassandra, jer na njima nije moglo raditi sabijanje.
Jednog olujnog dana grozd se skoro pretvorio u bundevu, naime:
- u klasteru je ostalo oko 20% ukupnog prostora;
- Nemoguće je u potpunosti dodati čvorove, jer čišćenje ne prolazi nakon dodavanja čvora zbog nedostatka prostora na particijama;
- produktivnost postepeno opada jer zbijanje ne radi;
- Klaster je u hitnom modu.
Izlaz - dodali smo još 5 čvorova bez čišćenja, nakon čega smo počeli da ih sistematski uklanjamo iz klastera i ponovo ulazimo u njih, kao prazne čvorove kojima je ponestalo prostora. Potrošeno je mnogo više vremena nego što bismo željeli. Postojao je rizik od djelimične ili potpune nedostupnosti klastera.
Zaključci:
- Na svim cassandra serverima ne bi trebalo biti zauzeto više od 60% prostora na svakoj particiji.
- Ne treba ih učitavati na najviše 50% CPU-a.
- Ne treba zaboraviti na planiranje kapaciteta i potrebno ga je promisliti za svaku komponentu, na osnovu njenih specifičnosti.
- Što više čvorova u klasteru, to bolje. Serveri koji sadrže malu količinu podataka brže se preopterećuju, a takav klaster je lakše oživjeti.
Drugo mjesto - “Podaci su nestali iz konzulata ključ/vrijednost memorije”
Za otkrivanje usluge, mi, kao i mnogi, koristimo konzul. Ali koristimo i njegov ključ/vrijednost za plavo-zeleni izgled monolita. Pohranjuje informacije o aktivnim i neaktivnim uzvodnim linijama, koje mijenjaju mjesta tokom implementacije. U tu svrhu je napisana služba za raspoređivanje koja je bila u interakciji sa KV. U nekom trenutku podaci iz KV-a su nestali. Vraćeno iz memorije, ali sa nizom grešaka. Kao rezultat toga, tokom upload-a, opterećenje na upstreamovima je bilo neravnomjerno raspoređeno, a dobili smo mnogo 502 grešaka zbog preopterećenja backenda na CPU-u. Kao rezultat toga, prešli smo sa konzula KV na postgres, odakle ih više nije tako lako ukloniti.
Zaključci:
- Usluge bez ikakvog odobrenja ne bi trebale sadržavati podatke kritične za rad stranice. Na primjer, ako nemate autorizaciju u ES-u, bilo bi bolje da zabranite pristup na nivou mreže sa svih mjesta gdje nije potreban, ostavite samo potrebne, a također postavite action.destructive_requires_name: true.
- Unaprijed vježbajte svoj mehanizam sigurnosne kopije i oporavka. Na primjer, unaprijed napravite skriptu (na primjer, u pythonu) koja može napraviti sigurnosnu kopiju i vratiti.
Prvo mjesto - “Kapetan Neočito”
U nekom trenutku smo primijetili neravnomjernu raspodjelu opterećenja na nginx uzvodno u slučajevima gdje je bilo 10+ servera u pozadini. Zbog činjenice da je round-robin slao zahtjeve od 1. do posljednjeg uzvodnog po redu, a svako nginx ponovno učitavanje je počinjalo ispočetka, prvi upstreamovi su uvijek primali više zahtjeva od ostalih, zbog čega su radili sporije i patila je cijela stranica. To je postajalo sve uočljivije kako se povećavao promet. Jednostavno ažuriranje nginxa da bi se omogućilo nasumično nije uspjelo - moramo ponovo napraviti gomilu lua koda koji se nije pojavio u verziji 1.15 (u tom trenutku). Morali smo zakrpiti naš nginx 1.14.2, uvodeći nasumičnu podršku u njega. Ovo je riješilo problem. Ova greška pobjeđuje u kategoriji "Kapetan ne-očiglednost".
Zaključci:
Bilo je vrlo zanimljivo i uzbudljivo istražiti ovu grešku).
- Organizirajte svoje praćenje tako da vam pomaže da brzo pronađete takve fluktuacije. Na primjer, možete koristiti ELK da nadgledate rps na svakom pozadinskom dijelu svakog uzvodnog toka, pratite njihovo vrijeme odgovora sa gledišta nginxa. U ovom slučaju, to nam je pomoglo da identificiramo problem.
Kao rezultat toga, većina neuspjeha je mogla biti izbjegnuta sa skrupuloznijim pristupom onome što radite. Uvijek se moramo sjetiti Marfijevog zakona: Sve što može poći po zlu, poći će po zlu, i na osnovu toga izgraditi komponente.
izvor: www.habr.com