Topp fakapov Cyan

Gott fyrir alla! 

Ég heiti Nikita, ég er liðsstjóri Cian verkfræðiteymis. Ein af skyldum mínum hjá fyrirtækinu er að fækka atvikum sem tengjast innviðum í framleiðslu niður í núll.
Það sem verður fjallað um hér á eftir olli okkur miklum sársauka og tilgangur þessarar greinar er að koma í veg fyrir að annað fólk endurtaki mistök okkar eða að minnsta kosti að lágmarka áhrif þeirra. 

Formáli

Fyrir löngu síðan, þegar Cian samanstóð af einlitum, og engin vísbending var um örþjónustu ennþá, mældum við framboð á auðlind með því að athuga 3-5 síður. 

Þeir svara - allt er í lagi, ef þeir svara ekki í langan tíma - á varðbergi. Hversu lengi þeir þurftu að vera frá vinnu til að það teljist til atviks var ákveðið af fólki á fundum. Hópur verkfræðinga tók alltaf þátt í rannsókn atviksins. Þegar rannsókninni var lokið skrifuðu þeir skurðaðgerð - eins konar skýrslu í tölvupósti í formi: hvað gerðist, hversu lengi það stóð, hvað við gerðum í augnablikinu, hvað við munum gera í framtíðinni. 

Aðalsíður síðunnar eða hvernig við skiljum að við höfum slegið botninn

 
Til þess að skilja einhvern veginn forgang villunnar höfum við bent á mikilvægustu síðurnar fyrir virkni fyrirtækja. Með því að nota þær teljum við fjölda vel heppnaðra/misheppnuðu beiðna og frests. Svona mælum við spennutíma. 

Segjum að við komumst að því að það eru nokkrir ofurmikilvægir hlutar síðunnar sem bera ábyrgð á aðalþjónustunni - að leita og senda inn auglýsingar. Ef fjöldi beiðna sem mistakast fer yfir 1% er þetta alvarlegt atvik. Ef villuhlutfallið fer yfir 15% innan 0,1 mínútna á besta tíma, þá er þetta einnig talið mikilvægt atvik. Þessar viðmiðanir ná yfir flest atvikin; restin er utan gildissviðs þessarar greinar.

Helstu bestu atvik Cian

Þannig að við höfum örugglega lært að ákvarða þá staðreynd að atvik hafi átt sér stað. 

Nú er hverju atviki lýst í smáatriðum og endurspeglast í Jira epíkinni. Við the vegur: fyrir þetta byrjuðum við sérstakt verkefni, kallað það FAIL - aðeins er hægt að búa til epics í því. 

Ef þú safnar öllum mistökum undanfarin ár eru leiðtogarnir: 

• mssql tengd atvik;
• atvik af völdum utanaðkomandi þátta;
• stjórnunarvillur.

Við skulum skoða nánar mistök stjórnenda, auk nokkurra annarra áhugaverðra bilana.

Fimmta sæti - „Að koma hlutunum í lag í DNS“

Það var stormasamur þriðjudagur. Við ákváðum að endurheimta röð í DNS klasanum. 

Mig langaði að flytja innri DNS netþjóna frá bind til powerdns, úthluta algjörlega aðskildum netþjónum fyrir þetta, þar sem ekkert er nema DNS. 

Við settum einn DNS netþjón á hverjum stað í DCs okkar og augnablikið kom til að færa svæði frá bindingu yfir í powerdns og skipta um innviði yfir á nýja netþjóna. 

Í miðri flutningnum, af öllum netþjónum sem voru tilgreindir í staðbundnum skyndiminni bindingar á alla netþjóna, var aðeins einn eftir, sem var í gagnaverinu í Sankti Pétursborg. Þetta DC var upphaflega lýst yfir sem ekki mikilvægt fyrir okkur, en varð skyndilega að einum bilunarpunkti.
Það var á þessu tímabili flutnings sem síkið milli Moskvu og Pétursborgar féll niður. Við vorum í raun skilin eftir án DNS í fimm mínútur og komumst aftur upp þegar hýsingaraðili lagaði vandamálið. 

Ályktanir:

Ef við vanræktum utanaðkomandi þætti áður við undirbúning fyrir vinnu, þá eru þeir einnig með á listanum yfir það sem við erum að undirbúa okkur fyrir. Og nú kappkostum við að tryggja að allir þættir séu fráteknir n-2, og meðan á vinnunni stendur getum við lækkað þetta stig í n-1.

• Þegar þú gerir aðgerðaáætlun skaltu merkja við þá staði þar sem þjónustan gæti bilað og hugsað í gegnum atburðarás þar sem allt fór „frá slæmu til verra“ fyrirfram.
• Dreifðu innri DNS netþjónum yfir mismunandi landfræðilegar staðsetningar/gagnaver/rekki/rofa/inntak.
• Á hverjum netþjóni skaltu setja upp staðbundinn skyndiminni DNS netþjón, sem vísar beiðnum til helstu DNS netþjóna, og ef hann er ekki tiltækur mun hann svara úr skyndiminni. 

Fjórða sæti - „Að koma hlutunum í lag í Nginx“

Einn góðan veðurdag ákvað teymið okkar að „við höfum fengið nóg af þessu,“ og ferlið við að endurgera nginx stillingar hófst. Meginmarkmiðið er að koma stillingunum í leiðandi uppbyggingu. Áður fyrr var allt "sögulega staðfest" og bar enga rökfræði. Nú hefur hvert server_name verið flutt í samnefnda skrá og öllum stillingum hefur verið dreift í möppur. Sem sagt, stillingin inniheldur 253949 línur eða 7836520 stafi og tekur tæplega 7 megabæti. Efsta stig uppbyggingar: 

Nginx uppbygging

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

Það varð miklu betra, en í því ferli að endurnefna og dreifa stillingum voru sumar þeirra með ranga framlengingu og voru ekki með í include *.conf tilskipuninni. Fyrir vikið urðu sumir gestgjafar ótiltækir og skiluðu 301 á aðalsíðuna. Vegna þess að svarkóði var ekki 5xx/4xx varð ekki vart við þetta strax, heldur aðeins að morgni. Eftir það byrjuðum við að skrifa próf til að athuga innviðaíhluti.

Ályktanir: 

• Settu upp stillingarnar þínar rétt (ekki bara nginx) og hugsaðu í gegnum uppbygginguna á frumstigi verkefnisins. Þannig muntu gera þá skiljanlegri fyrir teymið, sem aftur mun draga úr TTM.
• Skrifaðu próf fyrir suma innviðahluta. Til dæmis: að athuga að öll lykilþjónnöfn gefi rétta stöðu + svarhluti. Það mun vera nóg að hafa aðeins örfá smáforskrift við höndina sem athuga grunnaðgerðir íhlutans, til að muna ekki í ofvæni klukkan 3:XNUMX hvað annað þarf að athuga. 

Þriðja sæti - „Var allt í einu upp úr plássi í Cassöndru“

Gögnin jukust jafnt og þétt og allt var í lagi þar til viðgerð á stórum hyljum fór að mistakast í Cassandra þyrpingunni, vegna þess að þjöppun gat ekki virkað á þeim. 

Einn stormasaman dag breyttist þyrpingin næstum í grasker, nefnilega:

• það voru um 20% af heildarrýminu eftir í þyrpingunni;
• Það er ómögulegt að bæta við hnútum að fullu, vegna þess að hreinsun fer ekki í gegn eftir að hnút hefur verið bætt við vegna plássleysis á skiptingunum;
• framleiðni minnkar smám saman þar sem þjöppun virkar ekki; 
• Þyrpingin er í neyðarstillingu.

Hætta - við bættum við 5 hnútum í viðbót án hreinsunar, eftir það fórum við að fjarlægja þá kerfisbundið úr þyrpingunni og fara inn í þá aftur, eins og tómir hnútar sem voru orðnir uppiskroppa með pláss. Mun meiri tíma fór í en við vildum. Hætta var á að klasinn væri óaðgengilegur að hluta eða öllu leyti. 

Ályktanir:

• Á öllum cassandra netþjónum ætti ekki að vera meira en 60% af plássinu á hverri skiptingu. 
• Þeir ættu að vera hlaðnir á ekki meira en 50% örgjörva.
• Þú ættir ekki að gleyma um afkastagetuáætlun og þarft að hugsa það til enda fyrir hvern þátt, byggt á sérstöðu hans.
• Því fleiri hnútar í þyrpingunni, því betra. Netþjónar sem innihalda lítið magn af gögnum eru ofhlaðnir hraðar og auðveldara er að endurlífga slíkan þyrping. 

Annar sæti - „Gögn hurfu úr geymslu lykilgildis ræðismanns“

Til að uppgötva þjónustu notum við, eins og margir, ræðismann. En við notum líka lykilgildi þess fyrir blágræna uppsetningu einlitsins. Það geymir upplýsingar um virka og óvirka andstreymis, sem skipta um stað meðan á dreifingu stendur. Í þessu skyni var skrifuð dreifingarþjónusta sem hafði samskipti við KV. Á einhverjum tímapunkti hurfu gögnin frá KV. Endurheimt úr minni, en með fjölda villna. Fyrir vikið, meðan á upphleðslunni stóð, dreifðist álagið á andstreymið ójafnt og við fengum margar 502 villur vegna þess að bakendarnir voru ofhlaðnir á CPU. Í kjölfarið fluttum við frá ræðismanni KV til postgres, þaðan sem það er ekki lengur svo auðvelt að fjarlægja þá.  

Ályktanir:

• Þjónusta án nokkurrar heimildar ætti ekki að innihalda gögn sem eru mikilvæg fyrir rekstur síðunnar. Til dæmis, ef þú ert ekki með heimild í ES, væri betra að neita aðgangi á netstigi alls staðar þar sem þess er ekki þörf, skilja aðeins eftir nauðsynlega og einnig stilla action.destructive_requires_name: true.
• Æfðu öryggisafritunar- og endurheimtarbúnaðinn fyrirfram. Til dæmis skaltu búa til handrit fyrirfram (til dæmis í python) sem getur tekið öryggisafrit og endurheimt.

Fyrsta sæti - „Captain Unobvious“ 

Á einhverjum tímapunkti tókum við eftir ójafnri dreifingu álags á nginx andstreymis í þeim tilvikum þar sem það voru 10+ netþjónar í bakendanum. Vegna þess að round-robin sendi beiðnir frá 1. til síðasta andstreymis í röð og hver nginx endurhleðsla byrjaði upp á nýtt, fengu fyrstu upstreamarnir alltaf fleiri beiðnir en hinir. Fyrir vikið virkuðu þeir hægar og allur vefurinn þjáðist. Þetta varð æ áberandi eftir því sem umferðin jókst. Einfaldlega að uppfæra nginx til að virkja handahófi virkaði ekki - við þurfum að endurtaka fullt af lua kóða sem fór ekki í gang í útgáfu 1.15 (á því augnabliki). Við þurftum að plástra nginx 1.14.2 okkar og kynna tilviljunarkenndan stuðning inn í það. Þetta leysti vandann. Þessi galla vinnur flokkinn „Captain Non-Obviousness“.

Ályktanir:

Það var mjög áhugavert og spennandi að skoða þessa villu). 

• Skipuleggðu eftirlit þitt þannig að það hjálpi þér að finna slíkar sveiflur fljótt. Til dæmis geturðu notað ELK til að fylgjast með rps á hverjum bakenda hvers andstreymis, fylgjast með viðbragðstíma þeirra frá sjónarhóli nginx. Í þessu tilviki hjálpaði þetta okkur að bera kennsl á vandamálið. 

Þar af leiðandi hefði mátt komast hjá flestum bilunum með vandlegri nálgun á það sem þú varst að gera. Við verðum alltaf að muna lögmál Murphys: Allt sem getur farið úrskeiðis mun fara úrskeiðis, og byggja íhluti út frá því. 

Heimild: www.habr.com