TĂ« gjithĂ«ve pĂ«rshĂ«ndetje!Â
Më quajnë Nikita, unë jam lideri i ekipit të inxhinierëve në Cian. Një nga detyrat e mia në kompani është të ulim numrin e incidenteve që lidhen me infrastrukturën në prodhim, deri në zero.
Ajo qĂ« do tĂ« flasim mĂ« tej na ka sjellĂ« shumĂ« mundime, dhe qĂ«llimi i kĂ«tij artikulli Ă«shtĂ« tĂ« ndihmojmĂ« tĂ« tjerĂ«t tĂ« mos pĂ«rsĂ«risin gabimet tona ose tĂ« paktĂ«n tĂ« minimizojnĂ« ndikimin e tyre.Â
Preambula
ShumĂ« kohĂ« mĂ« parĂ«, kur Cian pĂ«rbĂ«hej nga monolite dhe nuk kishte asnjĂ« shenjĂ« tĂ« mikroshĂ«rbimeve, ne matnim disponueshmĂ«rinĂ« e burimit duke kontrolluar 3â5 faqe.Â
NĂ«se pĂ«rgjigjeshin - gjithçka ishte nĂ« rregull, nĂ«se nuk pĂ«rgjigjeshin pĂ«r njĂ« kohĂ« tĂ« gjatĂ« - alarmohej. Sa kohĂ« duhet tĂ« mos punojnĂ« pĂ«r t'u konsideruar incident - e vendosnin njerĂ«zit nĂ« takime. Ekipi i inxhinierĂ«ve gjithmonĂ« merrte pjesĂ« nĂ« hetimin e incidentit. Kur hetimi pĂ«rfundonte, shkruhej njĂ« postmortem - njĂ« raport i tillĂ« dĂ«rguar nĂ« email nĂ« formatin: çfarĂ« ndodhi, sa zgjati, çfarĂ« bĂ«mĂ« nĂ« moment, çfarĂ« do tĂ« bĂ«jmĂ« nĂ« tĂ« ardhmen.Â
Faqet kryesore të sitit ose si e kuptojmë se kemi arritur fundin
Â
PĂ«r tĂ« pasur njĂ« mĂ«nyrĂ« pĂ«r tĂ« kuptuar prioritetin e gabimeve, kemi identifikuar faqet mĂ« kritike pĂ«r funksionalitetin e biznesit. NĂ« to, ne numĂ«rojmĂ« numrin e kĂ«rkesave tĂ« suksesshme/dhe tĂ« pasuksesshme dhe kohĂ«ve tĂ« pritjes. KĂ«shtu matim uptime.Â
Supozoni se kemi zbuluar se ka një seri seksionesh super të rëndësishme në sit që përgjigjen për shërbimin kryesor - kërkesa dhe dërgimi i njoftimeve. Nëse numri i kërkesave që përfunduan me gabim tejkalon 1%, - ky është një incident kritik. Nëse për një periudhë 15 minutash gjatë orëve të pikut, përqindja e gabimeve tejkalon 0,1% - kjo gjithashtu konsiderohet një incident kritik. Këto kritere mbulojnë shumicën e incidenteve, ndërsa të tjeratShkruhen jashtë kufijve të këtij artikulli.
Të dhënat më të mira të incidenteve të Cian
KĂ«shtu, ne sigurisht qĂ« kemi mĂ«suar tĂ« identifikojmĂ« faktin se njĂ« incident ka ndodhur.Â
Tani çdo incident Ă«shtĂ« pĂ«rshkruar nĂ« mĂ«nyrĂ« tĂ« detajuar dhe Ă«shtĂ« reflektuar nĂ« epikĂ«n Jira. PĂ«r ta thĂ«nĂ« kĂ«tĂ«: pĂ«r kĂ«tĂ« kemi krijuar njĂ« projekt tĂ« veçantĂ«, e quajtĂ«m FAIL - nĂ« tĂ« mund tĂ« krijohen vetĂ«m epika.Â
NĂ«se tĂ« gjitha dĂ«shtimet e viteve tĂ« fundit do tĂ« mblidheshin, do tĂ« dominonin:Â
- incidencet që lidhen me mssql;
- incidencet që shkaktohen nga faktorë të jashtëm;
- gabimet e administratorëve.
Le të ndalemi më së shumti te gabimet e administratorëve, si dhe disa dështime interesante të tjera.
Vendi i pestë - "Rregullimi i DNS"
Ishte njĂ« martĂ« e palakmushme. Ne vendosĂ«m tĂ« rregullojmĂ« DNS-klasterin.Â
Na lindi dĂ«shira tĂ« transferonim serverat e brendshĂ«m tĂ« DNS nga bind nĂ« powerdns, duke ndarĂ« pĂ«r kĂ«tĂ« servera tĂ« veçantĂ«, ku nuk kishte asgjĂ« pĂ«rveç DNS.Â
VendosĂ«m pĂ«r njĂ« server DNS nĂ« çdo lokacion tĂ« DC-ve tona dhe arriti momenti i migrimit tĂ« zonave nga bind nĂ« powerdns dhe kalimi i infrastrukturĂ«s nĂ« serverat e rinj.Â
Në mesin e migrimit, nga të gjitha serveraqë ishin treguar në cache lokal bind në të gjitha serverat, mbeti vetëm një, që ishte në qendrën e të dhënave në Shën Petersburg. Ky DC fillimisht kishte shkruar si jo kritik për ne, por papritur u bë pikë e vetme dështimi.
NĂ« pikĂ«risht atĂ« periudhĂ« migrimi ra lidhja midis MoskĂ«s dhe ShĂ«n Petersburgut. Ne faktikisht mbetĂ«m pa DNS pĂ«r pesĂ« minuta dhe u ringritĂ«m kur hostin u zgjidhĂ«n problemet.Â
Konkluzione:
Nëse më herët ne e neglizhonim faktorët e jashtëm gjatë përgatitjes për punë, tani ata gjithashtu janë përfshirë në listën e asaje për çka përgatitemi. Dhe tani synojmë që të gjithë komponentët të jenë të rezervuar n-2, dhe për kohën e punëve mund të ulim këtë nivel në n-1.
- Gjatë hartimit të planit të veprimit, shënojnë pikat ku shërbimi mund të dështojë, dhe mendoni skenarë ku gjithçka shkoi "keq për më keq", më parë.
- Shpërndani serverat e DNS të brendshëm në lokacione të ndryshme/gjithsej/kolonat/switch-at/fushtat.
- NĂ« çdo server vendosni njĂ« server lokal tĂ« caching DNS qĂ« drejton kĂ«rkesat nĂ« serverat kryesorĂ« tĂ« DNS, dhe nĂ« rast tĂ« paaksesueshmĂ«risĂ« sĂ« tij, do tĂ« pĂ«rgjigjet nga cache.Â
Vendi i katërt - "Rregullimi i Nginx"
NjĂ« ditĂ« tĂ« bukur ekipi ynĂ« vendosi se "mjaft Ă«shtĂ« mjaft", dhe filloi procesi i ristrukturimit tĂ« konfigurations sĂ« nginx. QĂ«llimi kryesor - tĂ« sillte konfigurimet nĂ« njĂ« strukturĂ« intuitively tĂ« kuptueshme. MĂ« parĂ« gjithçka ishte "historikisht e pĂ«rcaktuar" dhe nuk pati asnjĂ« logjikĂ«. Tani çdo server_name u nxorr nĂ« njĂ« skedar tĂ« quajtur njĂ«lloj dhe ndarĂ« tĂ« gjitha konfigurimet sipas dosjeve. pĂ«r ta thĂ«nĂ« kĂ«tĂ« - konfigurimi ka nĂ« vetvete 253949 rreshta ose 7836520 karaktere dhe zĂ« pothuajse 7 megabajt. Niveli i sipĂ«rm i strukturĂ«s:Â
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.confKa Ă«shtĂ« bĂ«rĂ« ndjeshĂ«m mĂ« mirĂ«, por gjatĂ« ridhenim dhe shpĂ«rndarjes sĂ« konfigurimeve, disa prej tyre kishin njĂ« zgjedhje tĂ« gabuar dhe nuk u pĂ«rfshinĂ« nĂ« direktivĂ«n include *.conf. Si pasojĂ«, disa host-e u bĂ«nĂ« tĂ« pakapshĂ«m dhe kthenin 301 nĂ« tĂ« parĂ«n. PĂ«r shkak se kodi i pĂ«rgjigjes nuk ishte 5xx/4xx, nuk u vĂ«rejt menjĂ«herĂ«, por vetĂ«m nĂ« mĂ«ngjes. Pas kĂ«saj, filluam tĂ« shkruajmĂ« teste pĂ«r tĂ« kontrolluar komponentĂ«t infrastrukturore.
Konkluzione:Â
- Strukturojini saktë konfigurimet (jo vetëm nginx) dhe mendoni për strukturën në fazën e hershme të projektit. Kështu do t'i bëni ato më të kuptueshme për ekipin, duke ulur kështu TTM.
- PĂ«r disa komponentĂ« infrastrukture, shkruani teste. PĂ«r shembull: kontrolloni qĂ« tĂ« gjithĂ« server_name kyç tĂ« kthejnĂ« statusin e duhur, + trupin e pĂ«rgjigjes. Mjafton tĂ« keni disa skripta tĂ« thjeshtĂ« nĂ« dispozicion qĂ« kontrollojnĂ« funksionet kryesore tĂ« komponentit, pĂ«r tĂ« mos u kapur papritur nĂ« 3 tĂ« mĂ«ngjesit, duke u pyetur se çfarĂ« tjetĂ«r duhet tĂ« kontrolloni.Â
Vendi i tretë - "Papritur mbaroi vendi në Cassandra"
TĂ« dhĂ«nat rriteshin progresivisht dhe gjithçka ishte mirĂ« deri nĂ« momentin kur nĂ« klasterin Cassandra filluan tĂ« dĂ«shtojnĂ« riparimet e kaq shumĂ« case-space, sepse nuk mund tĂ« pĂ«rfundonin kompaktimin.Â
Një ditë të errët, klasteri pothuajse u shndërrua në një kungull, pikërisht:
- mbetën rreth 20% në total në klaster;
- nuk mund të shtoheshin node të plota, sepse nuk përfundonte pastrimi pas shtimit të një node për shkak të mungesës së vendit në pjesët;
- performanca po bie pak nga pak, sepse kompaktimi nuk funksionon;Â
- klasteri punon në modalitetin emergjent.
Zgjedhja - shtuam 5 node pa pastrimin, pas sĂ« cilĂ«s filluam tĂ« nxjerrim ngadalĂ« nga klasteri dhe t'i ri-insertojmĂ« si node tĂ« zbrazĂ«ta, tĂ« cilĂ«ve u kishte mbaruar vendi. Koha e shpenzuar ishte shumĂ« mĂ« e madhe nga sa do doja. Kishim rrezik pĂ«r njĂ« qasje tĂ« pjesshme ose totale tĂ« klasterit.Â
Konkluzione:
- NĂ« tĂ« gjitha serverĂ«t Cassandra, nuk duhet tĂ« jetĂ« e zĂ«nĂ« mĂ« shumĂ« se 60% e hapĂ«sirĂ«s nĂ« secilĂ«n pjesĂ«.Â
- Ato nuk duhet të jenë të ngarkuara më shumë se 50% sipas CPU.
- Nuk duhet të injoroni planifikimin e kapacitetit dhe duhet ta mendoni atë për secilin komponent, sipas specifikave të tij.
- Sa mĂ« shumĂ« node nĂ« klaster - aq mĂ« mirĂ«. ServerĂ«t qĂ« mbajnĂ« sasi tĂ« vogla tĂ« tĂ« dhĂ«nave, ri-rikthehen mĂ« shpejt, dhe njĂ« klaster i tillĂ« Ă«shtĂ« mĂ« i lehtĂ« pĂ«r t'u rikuperuar.Â
Vendi i dytë - "Të dhënat iƥen nga magazina e çelësave dhe vlerave të consul"
PĂ«r zbulimin e shĂ«rbimeve ne, si shumĂ« tĂ« tjerĂ«, pĂ«rdorim consul. Por ne e pĂ«rdorim çelĂ«sin dhe vlerĂ«n e tij pĂ«r vendosjen blue-green tĂ« monolit. Aty ruhen informacionet mbi upstream-at aktivĂ« dhe jo aktivĂ«, tĂ« cilat ndĂ«rruan vendet gjatĂ« deploy-it. PĂ«r kĂ«tĂ« Ă«shtĂ« shkruar njĂ« shĂ«rbim vendosjeje, i cili ndĂ«rvepron me KV. NĂ« njĂ« moment, tĂ« dhĂ«nat nga KV u zhdukĂ«n. I rikuperuam nga memoria, por me disa gabime. Si pasojĂ«, gjatĂ« vendosjes, ngarka nĂ« upstream-at u shpĂ«rnda nĂ« mĂ«nyrĂ« tĂ« pandjeshme, dhe morĂ«m shumĂ« gabime 502 pĂ«r shkak tĂ« mbingarkesĂ«s sĂ« backend-Ă«ve sipas CPU. NĂ« fund kemi kaluar nga consul KV nĂ« postgres, nga ku t'i heqĂ«sh nuk Ă«shtĂ« aq e lehtĂ«. Â
Konkluzione:
- Shërbimet pa ndonjë lloj autorizimi nuk duhet të përmbajnë të dhëna kritikë për funksionimin e faqes. Për shembull, nëse nuk keni autorizim në ES - do ishte më mirë të ndalonit qasje në nivelin e rrjetit nga çdo vend ku nuk nevojitet, të linit vetëm ato të nevojshme, si dhe të bënit action.destructive_requires_name: true.
- Përgatitni mekanizmin e ruajtjes dhe rikuperimit paraprakisht. Për shembull, përgatitni paraprakisht një skript (për shembull, në Python), i cili di të bëjë back-up dhe rikuperimin.
Vendi i parĂ« - "Kapiteni i paditur"Â
NĂ« njĂ« moment, vĂ«mĂ« re njĂ« shpĂ«rndarje tĂ« paekuilibruar tĂ« ngarkesĂ«s nĂ« nginx upstream kur kishte 10+ servera nĂ« backend. PĂ«r shkak se round-robin drejtonte kĂ«rkesat nga upstreami i parĂ« deri tek ai i fundit nĂ« rend, dhe çdo reload i nginx fillonte nga fillimi, kĂ«rkesat gjithmonĂ« i binin mĂ« shumĂ« upstreamĂ«ve tĂ« parĂ« se sa atyre tĂ« tjerĂ«ve. Si pasojĂ« â ata punonin mĂ« ngadalĂ« dhe i gjithĂ« siti vuante. Kjo bĂ«hej gjithnjĂ« e mĂ« evidente me rritjen e trafikut. Thjesht pĂ«r tĂ« pĂ«rditĂ«suar nginx pĂ«r tĂ« pĂ«rfshirĂ« random, kjo nuk funksionoi â duhej tĂ« ri-shkruhej njĂ« pĂ«rmbledhje e madhe e kodit lua, i cili nuk funksionoi nĂ« versionin 1.15 (nĂ« atĂ« kohĂ«). Duhej tĂ« patch-ojmĂ« nginx 1.14.2, duke e pĂ«rfshirĂ« mbĂ«shtetje pĂ«r random. Kjo zgjidhi problemin. Ky defekt Ă«shtĂ« fitues nĂ« kategorinĂ« 'kapiteni i padukshĂ«m'.
Konkluzione:
Ishte shumĂ« interesante dhe tĂ«rheqĂ«se tĂ« hulumtoja kĂ«tĂ« defekt).Â
- NdĂ«rtoni monitorimin nĂ« njĂ« mĂ«nyrĂ« qĂ« tĂ« ndihmojĂ« nĂ« identifikimin e kĂ«tij lloj fluktuacionesh shpejt. PĂ«r shembull, mund tĂ« pĂ«rdorni ELK pĂ«r tĂ« vĂ«shtruar rps pĂ«r çdo backend tĂ« çdo upstream, duke ndjekur kohĂ«n e tyre tĂ« pĂ«rgjigjes nga kĂ«ndvĂ«shtrimi i nginx. NĂ« kĂ«tĂ« rast, kjo na ndihmoi tĂ« zbulojmĂ« problemin.Â
Si rezultat, shumica e dĂ«shtimeve mund tĂ« ishin evituar me njĂ« qasje mĂ« tĂ« kujdesshme ndaj asaj qĂ« po bĂ«n. Duhet gjithmonĂ« tĂ« mbani mend ligjin e Murphy-t: Anything that can go wrong will go wrong, dhe tĂ« ndĂ«rtoni komponentĂ«t duke u udhĂ«hequr prej tij.Â
Burimi: habr.com
