Top fakapov syaani

Hyvä kaikille! 

Nimeni on Nikita, olen Cianin suunnittelutiimin tiiminvetäjä. Yksi tehtävistäni yrityksessä on vähentää tuotannon infrastruktuuriin liittyvien tapausten määrää nollaan.
Se, mitä alla käsitellään, aiheutti meille paljon tuskaa, ja tämän artikkelin tarkoituksena on estää muita ihmisiä toistamasta virheitämme tai ainakin minimoida niiden vaikutus. 

johdanto

Kauan sitten, kun Cian koostui monoliiteista, eikä mikropalveluista ollut vielä havaintoa, mittasimme resurssin saatavuuden tarkistamalla 3-5 sivua. 

He vastaavat - kaikki on hyvin, jos he eivät vastaa pitkään aikaan - valppaana. Ihmiset päättivät kokouksissa, kuinka kauan heidän piti olla poissa töistä, jotta se katsottaisiin tapaukseksi. Tapahtuman tutkinnassa oli aina mukana insinööriryhmä. Kun tutkinta valmistui, he kirjoittivat post mortemin - eräänlaisen raportin sähköpostitse muodossa: mitä tapahtui, kuinka kauan se kesti, mitä teimme tällä hetkellä, mitä aiomme tehdä tulevaisuudessa. 

Sivuston pääsivut tai miten ymmärrämme, että olemme osuneet pohjaan

 
Ymmärtääksemme jotenkin virheen tärkeysjärjestyksen, olemme tunnistaneet liiketoiminnan kannalta kriittisimmät sivuston sivut. Niiden avulla laskemme onnistuneiden/epäonnistuneiden pyyntöjen ja aikakatkaisujen määrän. Näin mittaamme käyttöaikaa. 

Oletetaan, että saimme selville, että sivustolla on useita erittäin tärkeitä osioita, jotka vastaavat pääpalvelusta - mainosten etsimisestä ja lähettämisestä. Jos epäonnistuneiden pyyntöjen määrä ylittää yhden prosentin, tämä on kriittinen tapahtuma. Jos 1 minuutin sisällä parhaaseen katseluaikaan virheprosentti ylittää 15 %, tämäkin katsotaan kriittiseksi tapahtumaksi. Nämä kriteerit kattavat suurimman osan tapauksista; loput eivät kuulu tämän artikkelin soveltamisalaan.

Parhaat tapahtumat Cian

Olemme siis varmasti oppineet määrittämään, että tapaus tapahtui. 

Nyt jokainen tapaus kuvataan yksityiskohtaisesti ja heijastuu Jira-eepoksessa. Muuten: tätä varten aloitimme erillisen projektin, nimeltään FAIL - siinä voidaan luoda vain eeppisiä. 

Jos keräät kaikki epäonnistumiset viime vuosilta, johtajat ovat: 

• mssql:ään liittyvät tapahtumat;
• ulkoisten tekijöiden aiheuttamat vaaratilanteet;
• admin virheet.

Katsotaanpa yksityiskohtaisemmin järjestelmänvalvojien virheitä sekä joitain muita mielenkiintoisia epäonnistumisia.

Viides paikka - "Asioiden järjestäminen DNS:ssä"

Oli myrskyinen tiistai. Päätimme palauttaa järjestyksen DNS-klusterissa. 

Halusin siirtää sisäiset DNS-palvelimet bindistä powerdns:iin, varaamalla tähän täysin erilliset palvelimet, joissa ei ole muuta kuin DNS. 

Sijoitimme yhden DNS-palvelimen jokaiseen DC:imme sijaintiin, ja tuli hetki siirtää vyöhykkeet bindistä powerdns-verkkoihin ja vaihtaa infrastruktuuri uusiin palvelimiin. 

Keskellä muutosta kaikista palvelimista, jotka oli määritetty paikallisissa välimuistisidoksissa kaikilla palvelimilla, jäi jäljelle vain yksi, joka oli Pietarin palvelinkeskuksessa. Tämä DC julistettiin alun perin ei-kriittiseksi meille, mutta siitä tuli yhtäkkiä yksi vikapiste.
Tänä muuttoaikana Moskovan ja Pietarin välinen kanava putosi. Jäimme itse asiassa ilman DNS:ää viideksi minuutiksi ja nousimme takaisin, kun isännöitsijä korjasi ongelman. 

Päätelmät:

Jos aiemmin jätimme ulkoiset tekijät huomioimatta työhön valmistautuessamme, niin nyt ne ovat myös mukana listalla, mihin valmistaudumme. Ja nyt pyrimme varmistamaan, että kaikki komponentit on varattu n-2, ja työn aikana voimme laskea tämän tason n-1:een.

• Merkitse toimintasuunnitelmaa tehdessäsi kohdat, joissa palvelu voi epäonnistua, ja mieti etukäteen skenaario, jossa kaikki meni "pahasta huonompaan".
• Jaa sisäiset DNS-palvelimet eri maantieteellisiin sijaintiin/tietokeskuksiin/telineisiin/kytkimiin/tuloihin.
• Asenna jokaiselle palvelimelle paikallinen välimuistipalvelin, joka uudelleenohjaa pyynnöt tärkeimpiin DNS-palvelimiin, ja jos se ei ole käytettävissä, se vastaa välimuistista. 

Neljäs paikka - "Asioiden siivoaminen Nginxissä"

Eräänä kauniina päivänä tiimimme päätti, että "olemme saaneet tarpeeksemme tästä", ja nginx-konfiguraatioiden uudelleenmuodostus alkoi. Päätavoitteena on saada konfiguraatiot intuitiiviseen rakenteeseen. Aikaisemmin kaikki oli "historiallisesti vakiintunutta", eikä siinä ollut mitään logiikkaa. Nyt jokainen palvelimen_nimi on siirretty samannimiseen tiedostoon ja kaikki konfiguraatiot on jaettu kansioihin. Muuten, kokoonpano sisältää 253949 riviä tai 7836520 merkkiä ja vie lähes 7 megatavua. Rakenteen huipputaso: 

Nginx-rakenne

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

Siitä tuli paljon parempi, mutta konfiguraatioiden uudelleennimeämisen ja jakelun aikana joillakin niistä oli väärä pääte, eikä niitä sisällytetty include *.conf -direktiiviin. Tämän seurauksena jotkut isännät eivät olleet käytettävissä ja palauttivat 301 pääsivulle. Koska vastauskoodi ei ollut 5xx/4xx, tätä ei huomattu heti, vaan vasta aamulla. Sen jälkeen aloimme kirjoittaa testejä infrastruktuurikomponenttien tarkistamiseksi.

Päätelmät: 

• Järjestä kokoonpanosi oikein (ei vain nginx) ja mieti rakenne läpi projektin varhaisessa vaiheessa. Näin teet niistä ymmärrettävämpiä joukkueelle, mikä puolestaan ​​vähentää TTM:ää.
• Kirjoita testejä joillekin infrastruktuurikomponenteille. Esimerkki: tarkistetaan, että kaikki avaimet palvelimen_nimet antavat oikean tilan + vastaustekstin. Riittää, kun sinulla on käsillä muutama skripti, jotka tarkistavat komponentin perustoiminnot, jotta et muista kiihkeästi kello 3, mitä muuta on tarkistettava. 

Kolmas paikka - "Tila loppui yhtäkkiä Cassandrassa"

Data kasvoi tasaisesti ja kaikki oli kunnossa siihen asti, kun Cassandra-klusterin suurten kotelotilojen korjaus alkoi epäonnistua, koska tiivistys ei voinut toimia niissä. 

Eräänä myrskyisenä päivänä klusteri melkein muuttui kurpitsaksi, nimittäin:

• klusterin kokonaistilasta oli jäljellä noin 20 %;
• Solmuja on mahdotonta lisätä kokonaan, koska siivous ei mene läpi solmun lisäämisen jälkeen osioiden tilan puutteen vuoksi;
• tuottavuus laskee vähitellen, koska tiivistys ei toimi; 
• Klusteri on hätätilassa.

Exit - lisäsimme 5 solmua lisää ilman puhdistusta, minkä jälkeen aloimme järjestelmällisesti poistaa niitä klusterista ja syöttää ne uudelleen, kuten tyhjiä solmuja, joiden tila oli loppunut. Aikaa kului paljon enemmän kuin halusimme. Oli olemassa riski, että klusteri ei ole käytettävissä osittain tai kokonaan. 

Päätelmät:

• Kaikissa cassandra-palvelimissa ei saa olla yli 60 % kunkin osion tilasta. 
• Niitä ei saa ladata yli 50 % prosessorilla.
• Kapasiteetin suunnittelua ei pidä unohtaa ja se on mietittävä jokaisen komponentin osalta sen erityispiirteiden perusteella.
• Mitä enemmän solmuja klusterissa, sitä parempi. Pienen datamäärän sisältävät palvelimet ylikuormituvat nopeammin, ja tällainen klusteri on helpompi elvyttää. 

Toinen sija - "Data katosi konsulin avainarvovarastosta"

Palveluiden löytämiseen me, kuten monet, käytämme konsulia. Mutta käytämme sen avainarvoa myös monoliitin sinivihreäksi asettelussa. Se tallentaa tietoja aktiivisista ja ei-aktiivisista ylävirtauksista, jotka vaihtavat paikkaa käyttöönoton aikana. Tätä tarkoitusta varten kirjoitettiin käyttöönottopalvelu, joka oli vuorovaikutuksessa KV:n kanssa. Jossain vaiheessa KV:n tiedot katosivat. Palautettu muistista, mutta useilla virheillä. Tämän seurauksena latauksen aikana ylävirran kuormitus jakautui epätasaisesti, ja saimme monia 502-virheitä prosessorin ylikuormittumisesta johtuen. Tämän seurauksena muutimme konsulilta KV:lta postgresiin, josta niiden poistaminen ei ole enää niin helppoa.  

Päätelmät:

• Palvelut ilman lupaa eivät saa sisältää sivuston toiminnan kannalta kriittisiä tietoja. Esimerkiksi, jos sinulla ei ole valtuutusta ES:ssä, on parempi evätä pääsy verkkotasolla kaikkialta, missä sitä ei tarvita, jättää vain tarpeelliset ja asettaa myös action.destructive_requires_name: true.
• Harjoittele varmuuskopiointi- ja palautusmekanismiasi etukäteen. Tee esimerkiksi komentosarja etukäteen (esimerkiksi Pythonissa), joka voi varmuuskopioida ja palauttaa.

Ensimmäinen paikka - "Captain Unobvious" 

Jossain vaiheessa huomasimme epätasaisen kuormituksen jakautumisen nginx:n ylävirtaan tapauksissa, joissa taustajärjestelmässä oli yli 10 palvelinta. Koska round-robin lähetti pyynnöt 1. kohdasta viimeiseen ylävirtaan järjestyksessä ja jokainen nginx-uudelleenlataus alkoi alusta, ensimmäiset ylävirtaukset saivat aina enemmän pyyntöjä kuin muut, minkä seurauksena ne toimivat hitaammin ja koko sivusto kärsi. Tämä näkyi yhä selvemmin liikenteen lisääntyessä. Pelkkä nginxin päivittäminen satunnaisen käyttöön ei toiminut – meidän on tehtävä uudelleen joukko lua-koodia, joka ei lähtenyt liikkeelle versiossa 1.15 (sillä hetkellä). Meidän piti korjata nginx 1.14.2 -versiomme ottamalla siihen satunnainen tuki. Tämä ratkaisi ongelman. Tämä bugi voittaa "Kapteeni ei-ilmeisyys" -kategorian.

Päätelmät:

Oli erittäin mielenkiintoista ja jännittävää tutkia tätä vikaa). 

• Järjestä seurantasi niin, että se auttaa sinua löytämään tällaiset vaihtelut nopeasti. Voit esimerkiksi käyttää ELK:ta valvomaan rps:tä kunkin ylävirran jokaisen taustapuolen rps:llä, tarkkailemaan niiden vasteaikaa nginxin näkökulmasta. Tässä tapauksessa tämä auttoi meitä tunnistamaan ongelman. 

Tämän seurauksena useimmat epäonnistumiset olisi voitu välttää tarkalla suhtautumisella siihen, mitä olit tekemässä. Meidän tulee aina muistaa Murphyn laki: Kaikki mikä voi mennä pieleen menee pieleen, ja rakentaa sen pohjalta komponentteja. 

Lähde: will.com