ProHoster > Blog > Administrim > Top gabimet e ĐŠĐžĐ°Đœ

Top gabimet e ĐŠĐžĐ°Đœ

Top gabimet e ĐŠĐžĐ°Đœ

Mirësi për të gjithë! 

Më quajnë Nikita, unë jam lideri i ekipit të inxhinierëve në Cian. Një nga detyrat e mia në kompani është të reduktoj ngjarjet që lidhen me infrastrukturën në prodhim, deri në zero.
Ajo që do të diskutohet më poshtë na ka sjellë shumë dhimbje, dhe qëllimi i këtij artikulli është të mos lejojmë që të tjerët të përsërisin gabimet tona ose të paktën të minimalizojnë ndikimin e tyre. 

Preambula

KohĂ« mĂ« parĂ«, kur Cian ishte njĂ« monolit dhe nuk kishte asnjĂ« shenjĂ« tĂ« mikroshĂ«rbimeve, ne matnim disponueshmĂ«rinĂ« e burimit duke kontrolluar 3–5 faqe. 

Nëse përgjigjen - gjithçka është në rregull, dhe nëse nuk përgjigjen për një kohë të gjatë - alarëm. Sa kohë duhet të mos funksionojnë për ta konsideruar si një ngjarje, e vendosnin njerëzit në mbledhje. Ekipi i inxhinierëve gjithmonë merrte pjesë në hetimin e ngjarjes. Kur hetimi përfundonte, shkruanin një postmortem - një raport të veçantë që dërgohej me email në format: çfarë ndodhi, sa zgjati, çfarë bëmë në momentin e ngjarjes, çfarë do të bëjmë në të ardhmen. 

Faqet kryesore të faqes ose si kuptojmë se e kemi arritur fundin

 
Për të kuptuar siç duhet përparësinë e gabimeve, ne kemi identifikuar faqet më kritike për funksionalitetin e biznesit. Për to, ne llogarisim numrin e kërkesave të sukseshme/dështuar dhe kohëzgjatjet. Kështu masim uptime-in. 

Le të themi se kemi zbuluar se ekzistojnë disa seksione super të rëndësishme të faqes që janë përgjegjëse për shërbimin kryesor - kërkimi dhe paraqitja e shpalljeve. Nëse numri i kërkesave që përfunduan me gabim kalon 1% - është një ngjarje kritike. Nëse brenda 15 minutash në orar të pikut përqindja e gabimeve kalon 0,1% - atëherë kjo gjithashtu konsiderohet si një ngjarje kritike. Këto kritere mbulojnë pjesën më të madhe të ngjarjeve, të tjera dalin jashtë këtij artikulli.

Top gabimet e ĐŠĐžĐ°Đœ

Top ngjarjet më të mira të Cian

Pra, ne me siguri kemi mësuar të përcaktojmë faktin që ka ndodhur një ngjarje. 

Tani çdo ngjarje është e përshkruar në detaje dhe pasqyrohet në epikën Jira. Për ta thënë këtë: për këtë ne nisëm një projekt të veçantë dhe e quajtëm FAIL - në të mund të krijohet vetëm epikë. 

Nëse mbledhim të gjitha dështimet e vitet e fundit, ato kryesojnë: 

  • ngjarjet qĂ« lidhen me mssql;
  • ngjarjet qĂ« u shkaktuan nga faktorĂ« tĂ« jashtĂ«m;
  • gabimet e administratĂ«s.

Do të përqendrohemi më në detaje në gabimet e administratorëve, si dhe në disa dështime të tjera interesante.

Vendi i pestë - "Renditja e DNS-it"

Ishte një martë e ndotur. Vendosëm të rregullojmë rendin në DNS-klusterin tonë. 

U dëshiruam të kalonim serverat e brendshëm DNS nga bind në powerdns, duke rezervuar për këtë servera krejtësisht të veçantë, ku nuk ka asgjë tjetër përveç DNS. 

Vendosëm nga një server DNS në çdo vendndodhje të qendrave tona të të dhënave, dhe erdhi momenti i kalimit të zonave nga bind në powerdns dhe kalimin e infrastrukturës në serverat e rinj. 

Në kulmin e kalimit nga të gjitha serverësh, që ishin shënuar në cache-local bind në të gjitha serverat, mbeti vetëm një, që ishte në qendrën e të dhënave në Shën Petersburg. Ky DC në fillim ishte deklaruar si jo kritik për ne, por papritmas u bë një pikë e vetme dështimi.
Pikërisht në këtë periudhë kalimi ra lidhja midis Moskës dhe Shën Petersburgut. Në fakt, mbetëm pa DNS për pesë minuta dhe u rikthyem, kur hosti zgjidhi problemet. 

PĂ«rfundimet:

Nëse më parë e neglizhonim faktorët e jashtëm gjatë përgatitjes për punë, tani i përfshimë ato në listën e asaj për të cilën po përgatitemi. Dhe tani synojmë që të gjithë komponentët të jenë të rezervuar n-2, ndërsa gjatë punëve mund të ulim këtë nivel në n-1.

  • GjatĂ« hartimit tĂ« planit tĂ« veprimit, shĂ«noni pikat ku shĂ«rbimi mund tĂ« bjerĂ«, dhe mendoni pĂ«r skenarin ku gjithçka shkon "mĂ« keq se asnjĂ«herĂ«" paraprakisht.
  • Rregulloni serverat e brendshĂ«m DNS nĂ« lokacione tĂ« ndryshme gjeografike/qendra tĂ« tĂ« dhĂ«nave/rrafshina/switch-e/influx.
  • NĂ« çdo server vendosni njĂ« server lokal tĂ« cache DNS, i cili redirekton kĂ«rkesat nĂ« serverat kryesorĂ« tĂ« DNS, dhe nĂ« rast tĂ« papĂ«rshtatshmĂ«risĂ« do tĂ« pĂ«rgjigjet nga cache. 

Vendi i katĂ«rt — "RregullojmĂ« rregullat nĂ« Nginx"

NĂ« njĂ« ditĂ« tĂ« bukur, ekipi ynĂ« vendosi se "mjafton tĂ« durojmĂ«", dhe procesi i riorganizimit tĂ« konfigurimeve tĂ« nginx filloi. QĂ«llimi kryesor — tĂ« sjellim konfigurimet nĂ« njĂ« strukturĂ« intuitivisht tĂ« kuptueshme. MĂ« parĂ« gjithçka ishte "historikisht e krijuar" dhe nuk kishte logjikĂ«. Tani çdo server_name Ă«shtĂ« nxjerrĂ« nĂ« njĂ« skedar tĂ« quajtur nĂ« tĂ« njĂ«jtĂ«n emĂ«r dhe tĂ« gjitha konfigurimet janĂ« shpĂ«rndarĂ« nĂ« dosje. PĂ«r t'u thĂ«nĂ« — konfigurimi pĂ«rmban 253949 rreshta ose 7836520 karaktere dhe zĂ« pothuajse 7 megabajt. Niveli i sipĂ«rm i strukturĂ«s: 

Struktura e Nginx

├── akses
│   ├── 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
...
│   ├── dinamik
│   └── 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

Ka ishte shumë më mirë, por gjatë procesit të rinomimit dhe shpërndarjes së konfigurations, disa prej tyre kishin një zgjerim të gabuar dhe nuk u futën në direktivën include *.conf. Si pasojë, disa hoste u bënë të paqëndrueshëm dhe kthyen 301 në kryefaqe. Për shkak se kodi i përgjigjes nuk ishte 5xx/4xx, këtë nuk e vunë re menjëherë, por vetëm në mëngjes. Pas kësaj, filluam të shkruajmë teste për kontrollet e komponenteve infrastrukturore.

Përfundimet: 

  • Strukturoni me saktĂ«si konfigurat (jo vetĂ«m nginx) dhe mendoni pĂ«r strukturĂ«n nĂ« fazĂ«n fillestare tĂ« projektit. KĂ«shtu do t’i bĂ«ni ato mĂ« tĂ« kuptueshme pĂ«r ekipin, çka nga ana tjetĂ«r do tĂ« ulĂ« TTM-nĂ«.
  • PĂ«r disa komponente infrastrukturore shkruani teste. PĂ«r shembull: kontrolloni qĂ« tĂ« gjithĂ« server_name kyç t’i japin statusin e duhur, + trupin e pĂ«rgjigjes. Mjafton tĂ« keni disa skripte qĂ« kontrollojnĂ« funksionet kryesore tĂ« komponentit, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos kujtoni me panik nĂ« 3 tĂ« mĂ«ngjesit çfarĂ« duhet tĂ« kontrolloni. 

Vendi i tretĂ« — "Papritur mbaroi vendi nĂ« Cassandra"

Të dhënat rriteshin rregullisht, dhe gjithçka ishte mirë deri në momentin kur në klasterin Cassandra filluan të dështojnë riparimet e case-space-ve të mëdha, sepse nuk mund të funksiononte kompaktimi. 

Në një ditë të errët, klasteri u shndërrua pothuajse në një kungull, konkretisht:

  • mbetĂ«n rreth 20% e pĂ«rgjithshme pĂ«r klasterin;
  • nuk mund tĂ« shtohen nodet nĂ« mĂ«nyrĂ« tĂ« plotĂ«, sepse nuk kalon pastrimin pas shtimit tĂ« nodit pĂ«r shkak tĂ« mungesĂ«s sĂ« vendit nĂ« seksionet;
  • performanca po ulet ngadalĂ«, pasi kompaktimi nuk punon; 
  • klasteri punon nĂ« njĂ« modalitet emergjent.

Top gabimet e ĐŠĐžĐ°Đœ

Ixit — kemi shtuar edhe 5 nodĂ« pa pastrimin, pas tĂ« cilave filluam ta nxjerrim gradualisht nga klasteri dhe ta rikthejmĂ« pĂ«rsĂ«ri, si nodĂ« tĂ« pastra, nĂ« tĂ« cilat kishte pĂ«rfunduar hapĂ«sira. Koha e shpenzuar Ă«shtĂ« shumĂ« mĂ« e madhe se sa do tĂ« doja. Ishte njĂ« rrezik i disponueshmĂ«risĂ« pjesore ose tĂ« plotĂ« tĂ« klasterit. 

PĂ«rfundimet:

  • NĂ« tĂ« gjitha serverat cassandra, hapĂ«sira nĂ« secilin seksion nuk duhet tĂ« jetĂ« mĂ« shumĂ« se 60%. 
  • TĂ« ngarkuarit nuk duhet tĂ« jenĂ« mĂ« shumĂ« se 50% pĂ«r CPU.
  • Nuk duhet tĂ« neglizhohet planifikimi i kapacitetit dhe ai duhet menduar pĂ«r secilin komponent, nĂ« bazĂ« tĂ« specifikave tĂ« tij.
  • Sa mĂ« shumĂ« nodĂ« tĂ« jenĂ« nĂ« klaster, aq mĂ« mirĂ«. Serverat qĂ« mbajnĂ« njĂ« volum tĂ« vogĂ«l tĂ« tĂ« dhĂ«nave janĂ« mĂ« tĂ« shpejtĂ« nĂ« rikthim, dhe njĂ« klaster i tillĂ« Ă«shtĂ« mĂ« i lehtĂ« pĂ«r t'u ringjallur. 

Vendi i dytĂ« — “TĂ« dhĂ«nat u zhdukĂ«n nga konsoli i ruajtjes key-value.”

Për zbulimin e shërbimeve, ne, ashtu si shumë të tjerë, përdorim konsolën. Por KV i saj përdoret gjithashtu për shpërndarjen blue-green të monolit. Atje ruhet informacioni mbi upstream-et aktiv dhe jo aktiv, të cilët ndërruan vende gjatë deplojit. Për këtë, është shkruar një shërbim deploy-i, që ndërvepronte me KV. Në një moment, të dhënat nga KV u humbën. U rikuperuan nga memoria, por me disa gabime. Si pasojë, gjatë shpërndarjes, ngarkesa në upstream ishte e shpërndarë në mënyrë të pabarabartë, dhe ne morëm shumë gabime 502 për shkak të ngarkesës në backend për CPU. Në fund, u transferuam nga konsolë KV në postgres, nga e cila është më e vështirë për t'i fshirë tashmë.  

PĂ«rfundimet:

  • ShĂ«rbimet pa ndonjĂ« autorizim nuk duhet tĂ« pĂ«rmbajnĂ« tĂ« dhĂ«na kritike pĂ«r funksionimin e faqes. PĂ«r shembull, nĂ«se nuk keni autorizim nĂ« ES — do tĂ« ishte mĂ« mirĂ« tĂ« ndalonit qasje nĂ« nivelin e rrjetit nga çdo vend qĂ« nuk Ă«shtĂ« e nevojshme, tĂ« lini vetĂ«m ato tĂ« nevojshme, dhe gjithashtu tĂ« bĂ«ni action.destructive_requires_name: true.
  • Punoni pĂ«r mekanizmin e rezervĂ«s dhe rikuperimit paraprakisht. PĂ«r shembull, krijoni njĂ« skenar (pĂ«r shembull, nĂ« python), qĂ« di tĂ« bĂ«jĂ« backup dhe rikthim.

Vendi i parĂ« — “Kapiteni i paqartĂ«sisĂ«.” 

NĂ« njĂ« moment, ne vĂ«mĂ« re njĂ« shpĂ«rndarje tĂ« pandershme tĂ« ngarkesĂ«s nĂ« upstream-et e nginx nĂ« rastet kur nĂ« backend kishte 10+ serverĂ«. PĂ«r shkak se round-robin drejtonte kĂ«rkesat nga 1 nĂ« upstream-in e fundit me radhĂ«, dhe çdo rinovim i nginx fillonte nga e para, gjithmonĂ« kishte mĂ« shumĂ« kĂ«rkesa pĂ«r upstream-et e parĂ« sesa pĂ«r tĂ« tjerĂ«t. Si pasojĂ«, ata punonin mĂ« ngadalĂ« dhe tĂ« gjithĂ« u ndikuan nga kjo. Kjo bĂ«hej gjithnjĂ« e mĂ« e dukshme me rritjen e sasisĂ« sĂ« trafikut. NjĂ« thjeshtĂ« azhurnim nĂ« nginx pĂ«r tĂ« aktivizuar random nuk e zgjidhi problemin — duhej tĂ« rregullohej shumĂ« kod LUA, i cili nuk λΔÎčÏ„ÎżÏ…ÏÎłonte nĂ« versionin 1.15 (nĂ« atĂ« kohĂ«). Iu desh tĂ« patchonim nginx 1.14.2 tonin, duke futur mbĂ«shtetje pĂ«r random. Kjo e zgjidhi problemin. Ky defekt Ă«shtĂ« fitues nĂ« kategorinĂ« «kapitani i padukshmĂ«risë».

PĂ«rfundimet:

Ishte shumë interesante dhe emocionuese të hetoja këtë defekt). 

  • NdĂ«rtoni monitorimin nĂ« mĂ«nyrĂ« qĂ« ai tĂ« ndihmojĂ« nĂ« gjetjen e fluktuacioneve tĂ« tilla shpejt. PĂ«r shembull, mund tĂ« pĂ«rdorni ELK pĂ«r tĂ« vĂ«zhguar rps pĂ«r çdo backend tĂ« çdo upstream, duke ndjekur kohĂ«n e tyre tĂ« pĂ«rgjigjes nga perspektiva e nginx. NĂ« kĂ«tĂ« rast, kjo na ndihmoi tĂ« identifikohemi problemin. 

Si rezultat, shumĂ« prej dĂ«shtimeve do tĂ« ishin shmangur me njĂ« qĂ«ndrim mĂ« tĂ« kujdesshĂ«m nĂ« ato qĂ« bĂ«ni. Duhet gjithmonĂ« tĂ« mbani mend ligjin e Murphy: Çdo gjĂ« qĂ« mund tĂ« shkojĂ« keq do tĂ« shkojĂ« keq, dhe tĂ« ndĂ«rtoni komponente duke u udhĂ«hequr nga ajo. 

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster