Top fakapov tsüaan

Hea kõigile! 

Minu nimi on Nikita, ma olen Ciani insenerimeeskonna meeskonnajuht. Üks minu kohustustest ettevõttes on vähendada tootmises taristuga seotud intsidentide arvu nullini.
Allpool käsitletav tõi meile palju valu ja selle artikli eesmärk on takistada teistel inimestel meie vigu kordamast või vähemalt minimeerida nende mõju. 

Preambul

Ammu aega tagasi, kui Cian koosnes monoliitidest ja mikroteenustele veel vihjeid polnud, mõõtsime ressursi saadavust 3-5 lehekülge kontrollides. 

Nad vastavad - kõik on hästi, kui nad pikka aega ei vasta - valvel. Kui kaua nad pidid töölt ära olema, et seda vahejuhtumiks pidada, otsustasid inimesed koosolekutel. Juhtumi uurimisse oli alati kaasatud inseneride meeskond. Kui uurimine oli lõppenud, kirjutasid nad postmortemi - omamoodi e-kirja teel vormingus: mis juhtus, kui kaua see kestis, mida me hetkel tegime, mida me tulevikus teeme. 

Saidi põhilehed või kuidas me aru saame, et oleme tabanud põhja

 
Vea prioriteedi mõistmiseks oleme tuvastanud ettevõtte funktsionaalsuse jaoks kõige olulisemad saidi lehed. Neid kasutades loendame edukate/ebaõnnestunud taotluste ja ajalõppude arvu. Nii mõõdame tööaega. 

Oletame, et saime teada, et saidil on mitu ülitähtsat jaotist, mis vastutavad põhiteenuse – reklaamide otsimise ja esitamise – eest. Kui ebaõnnestunud päringute arv ületab 1%, on see kriitiline juhtum. Kui parimal ajal 15 minuti jooksul ületab veamäär 0,1%, loetakse ka seda kriitiliseks intsidendiks. Need kriteeriumid hõlmavad enamikku intsidentidest; ülejäänud jäävad käesoleva artikli reguleerimisalast välja.

Parimad juhtumid Cyan

Seega oleme kindlasti õppinud kindlaks tegema, et juhtum juhtus. 

Nüüd kirjeldatakse iga juhtumit üksikasjalikult ja kajastatakse Jira eeposes. Muide: selleks alustasime eraldi projektiga, nimega FAIL – selles saab luua ainult eeposi. 

Kui kogute kokku kõik viimaste aastate ebaõnnestumised, on juhid järgmised: 

• mssql-iga seotud juhtumid;
• välistest teguritest põhjustatud intsidendid;
• administraatori vead.

Vaatame üksikasjalikumalt administraatorite vigu, aga ka mõnda muud huvitavat ebaõnnestumist.

Viies koht - "DNS-is asjade järjekorda seadmine"

Oli tormine teisipäev. Otsustasime DNS-klastris korra taastada. 

Tahtsin sisemised DNS-serverid sidumisest powerdns-ile üle kanda, eraldades selleks täiesti eraldi serverid, kus peale DNS-i pole midagi. 

Paigaldasime ühe DNS-serveri igasse oma DC-de asukohta ja saabus hetk teisaldada tsoonid sidumiselt powerdns-ile ja vahetada infrastruktuur uutele serveritele. 

Kolimise ajaks jäi kõigist serveritest kohalikes vahemällu sidemetes määratud serveritest alles vaid üks, mis asus Peterburi andmekeskuses. Algselt kuulutati see alalisvoolu meie jaoks mittekriitiliseks, kuid järsku muutus see üheks tõrkepunktiks.
Just sel kolimisperioodil langes alla Moskva ja Peterburi vaheline kanal. Me jäime tegelikult viieks minutiks ilma DNS-ita ja tõusime uuesti üles, kui hoster probleemi lahendas. 

Järeldused:

Kui varem jätsime tööks valmistumisel tähelepanuta välised tegurid, siis nüüd on needki lisatud meie ettevalmistuste nimekirja. Ja nüüd püüame tagada, et kõik komponendid oleksid reserveeritud n-2 ja töö käigus saame selle taseme alandada n-1-ni.

• Tegevuskava koostamisel märgi punktid, kus teenus võib ebaõnnestuda, ja mõtle eelnevalt läbi stsenaarium, kus kõik läks “halvast hullemini”.
• Jaotage sisemised DNS-serverid erinevate geograafiliste asukohtade / andmekeskuste / riiulite / lülitite / sisendite vahel.
• Paigaldage igasse serverisse kohalik vahemällu salvestav DNS-server, mis suunab päringud peamistele DNS-serveritele ja kui see pole saadaval, vastab see vahemälust. 

Neljas koht – “Nginxi asjade koristamine”

Ühel ilusal päeval otsustas meie meeskond, et "meil on sellest küllalt" ja algas nginxi konfiguratsioonide taastamine. Peamine eesmärk on viia konfiguratsioonid intuitiivsesse struktuuri. Varem oli kõik "ajalooliselt väljakujunenud" ega kandnud mingit loogikat. Nüüd on iga serveri_nimi teisaldatud samanimelisse faili ja kõik konfiguratsioonid on jagatud kaustadesse. Muide, konfiguratsioon sisaldab 253949 rida või 7836520 tähemärki ja võtab enda alla peaaegu 7 megabaiti. Struktuuri kõrgeim tase: 

Nginxi struktuur

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

See muutus palju paremaks, kuid konfiguratsioonide ümbernimetamise ja levitamise käigus oli mõnel neist vale laiend ja neid ei kaasatud include *.conf direktiivi. Selle tulemusena muutusid mõned hostid kättesaamatuks ja tagastasid 301 avalehele. Kuna vastuse kood ei olnud 5xx/4xx, siis seda ei märgatud kohe, vaid alles hommikul. Pärast seda hakkasime kirjutama teste infrastruktuuri komponentide kontrollimiseks.

Järeldused: 

• Struktureerige oma konfiguratsioonid õigesti (mitte ainult nginx) ja mõelge struktuur läbi projekti varajases staadiumis. Nii muudate need meeskonnale arusaadavamaks, mis omakorda vähendab TTM-i.
• Kirjutage mõne infrastruktuuri komponendi testid. Näiteks: kontrollimine, et kõik võtmeserveri_nimed annaksid õige oleku + vastuse keha. Piisab, kui teil on käepärast vaid paar skripti, mis kontrollivad komponendi põhifunktsioone, et mitte kell 3 öösel meeletult meeles pidada, mida veel kontrollida tuleb. 

Kolmas koht - "Cassandras sai järsku ruum otsa"

Andmed kasvasid pidevalt ja kõik oli korras kuni hetkeni, mil Cassandra klastris hakkas suurte korpuste remont ebaõnnestuma, sest tihendamine ei saanud nende peal toimida. 

Ühel tormisel päeval muutus kobar peaaegu kõrvitsaks, nimelt:

• klastris oli jäänud umbes 20% kogupinnast;
• Täielikult sõlmede lisamine on võimatu, kuna puhastamine ei toimu pärast sõlme lisamist partitsioonide ruumipuuduse tõttu;
• tootlikkus langeb järk-järgult, kuna tihendamine ei toimi; 
• Klaster on avariirežiimis.

Välju – lisasime ilma puhastamiseta veel 5 sõlme, misjärel hakkasime neid süstemaatiliselt klastrist eemaldama ja uuesti sisestama, nagu tühjad sõlmed, mille ruum oli otsa saanud. Aega kulus palju rohkem, kui sooviksime. Esines klastri osalise või täieliku kättesaamatuse oht. 

Järeldused:

• Kõigis Cassandra serverites ei tohiks igal partitsioonil olla hõivatud rohkem kui 60% ruumist. 
• Neid ei tohiks laadida rohkem kui 50% protsessoriga.
• Te ei tohiks unustada võimsuse planeerimist ja see tuleb iga komponendi puhul läbi mõelda, lähtudes selle spetsiifikast.
• Mida rohkem sõlme klastris, seda parem. Väikest andmemahtu sisaldavad serverid koormatakse kiiremini üle ja sellist klastrit on lihtsam taaselustada. 

Teine koht – “Andmed kadusid konsuli võtmeväärtuste salvestusruumist”

Teenuste avastamiseks kasutame me, nagu paljud, konsulit. Kuid me kasutame selle võtmeväärtust ka monoliidi sinakasrohelise paigutuse jaoks. See salvestab teavet aktiivsete ja mitteaktiivsete ülesvoolude kohta, mis vahetavad juurutamise ajal kohta. Selleks kirjutati juurutusteenus, mis suhtles KV-ga. Mingil hetkel kadusid andmed KV-st. Mälust taastatud, kuid mitmete vigadega. Selle tulemusena jaotus üleslaadimise ajal ülesvoolu koormus ebaühtlaselt ja saime palju 502 tõrkeid, mis olid tingitud CPU taustaprogrammide ülekoormamisest. Selle tulemusena kolisime konsul KV juurest postgresi, kust neid enam nii lihtne eemaldada ei ole.  

Järeldused:

• Ilma loata teenused ei tohiks sisaldada saidi toimimise jaoks olulisi andmeid. Näiteks kui sul pole ES-s autoriseerimist, siis tasuks võrgu tasemel ligipääs keelata kõikjalt, kus seda vaja pole, jätta alles vaid vajalikud ning määrata ka action.destructive_requires_name: true.
• Harjutage eelnevalt varundamise ja taastamise mehhanismi. Näiteks tehke eelnevalt (näiteks pythonis) skript, mida saab varundada ja taastada.

Esimene koht - "Capten Unobvious" 

Mingil hetkel märkasime nginxi ülesvoolu koormuse ebaühtlast jaotumist juhtudel, kui taustaprogrammis oli 10+ serverit. Kuna round-robin saatis päringuid järjekorras 1.-st kuni viimase ülesvooluni ja iga nginxi uuestilaadimine algas otsast peale, siis esimesed ülesvoolud said alati rohkem päringuid kui ülejäänud.Selle tulemusena töötasid aeglasemalt ja kannatas kogu sait. See muutus liikluse suurenedes üha märgatavamaks. Nginxi lihtsalt värskendamine juhusliku lubamiseks ei töötanud – peame uuesti tegema hulga lua-koodi, mis versioonis 1.15 (sel hetkel) ei käivitunud. Pidime oma nginx 1.14.2 parandama, lisades sellesse juhusliku toe. See lahendas probleemi. See viga võidab kategooria "Kapteni mitteilmnelisus".

Järeldused:

Väga huvitav ja põnev oli seda viga uurida). 

• Korraldage oma jälgimine nii, et see aitaks teil selliseid kõikumisi kiiresti leida. Näiteks saate ELK-ga jälgida rps-i iga ülesvoolu igas taustaprogrammis, jälgida nende reaktsiooniaega nginxi seisukohast. Antud juhul aitas see meil probleemi tuvastada. 

Selle tulemusel oleks saanud enamikku ebaõnnestumisi vältida, kui suhtute oma tegemistesse hoolikamalt. Peame alati meeles pidama Murphy seadust: Kõik, mis võib valesti minna, läheb valesti, ja ehitada selle põhjal komponente. 

Allikas: www.habr.com