Topsite fopaad Cianis

Tere kõigile! 

Minu nimi on Nikita, olen Циан'i insenerimeeskonna tiimijuht. Üks minu ülesannetest firmas on vähendada produtseerimise infrastruktuuriga seotud intsidente nullini.
Käesolevas artiklis käsitletav teema on meile palju valu toonud, ja eesmärk on vältida, et teised inimesed kordaks meie vigu või vähemalt minimeeriks nende mõju. 

Eesliide

Kauges minevikus, kui Циан koosnes monoliitidest ja mikroteenustest polnud veel jälgegi, mõõtsime ressursi kättesaadavust kontrollides 3–5 lehte. 

Kui nad vastavad — on kõik hästi, kui nad ei vasta pikka aega — on häire. Kui kaua nad peavad mitte töötama, et seda loetaks intsidendiks, määrati koosolekutel. Insenerimeeskond osales alati intsidendi uurimises. Kui uurimine oli lõpetatud, kirjutati post mortem — omamoodi aruanne e-posti formaadis: mis juhtus, kui kaua see kestis, mida tehti hetkel, mida teeme tulevikus. 

Peamised veebisaidi lehed või kuidas me mõistame, et oleme põhja tabanud

 
Kuna me püüame mõista vea prioriteeti, oleme välja toonud kõige kriitilisemad veebisaidi lehed äritegevuse funktsionaalsuse jaoks. Nende põhjal loeme edukaid/ebaõnnestunud päringute ja ajakulu arvu. Nii mõõdame uptime'i. 

Oletame, et oleme tuvastanud, et on olemas rida superolulisi veebisaidi sektsioone, mis vastutavad põhiteenuse — otsingu ja kuulutuste esitamise — eest. Kui veaga lõppenud päringute arv ületab 1%, on see kriitiline intsident. Kui tipptunnil 15 minuti jooksul veaprotsent ületab 0,1%, loetakse seda samuti kriitiliseks intsidendiks. Need kriteeriumid katab suurema osa intsidendidest, teised jäävad artikli raamesse.

Циан'i parimate intsidentide edetabel

Nii et me oleme kindlasti õppinud tuvastama, et intsident on juhtunud. 

Nüüd on iga intsident detailselt kirjeldatud ja kajastatud Jira epic'is. Muide: selleks käivitasime eraldi projekti, mille nimeks sai FAIL — seal saab luua ainult epikuid. 

Kui koguda kokku kõik ebaõnnestumised viimase paari aasta jooksul, siis valitsevad: 

• intsidendid, mis on seotud mssql-iga;
• intsidendid, mis on tingitud välistest teguritest;
• admini vead.

Haarame põhjalikumalt kinni adminide vigadest ja mõnest muust huvitavast ebaõnnestumisest.

Viies koht — 'Teeme korda DNS'i'

See oli sombune teisipäev. Otsustasime DNS-klastri korrastada. 

Soovisime ümber seadistada sise dns-serverid bindilt powerdns-ile, eraldades selleks täielikult eraldi serverid, kus peale dns-i midagi ei ole. 

Paigutasime igasse meie andmekeskuse asukohta ühe dns-serveri ja saabus hetk, mil tegime tsoonide üleviimise bindilt powerdns-ile ning lülitasime infrastruktuuri uutele serveritele. 

Üleviimise kõige tihedamal perioodil jäi meil alles vaid üks dns-server, serverid, mis oli kohalikes vahemälu bind-ides kõigil serveritel, oli Peterburi andmekeskuses. See andmekeskus oli algselt deklareeritud meie jaoks mitte kriitiliseks, kuid muutus äkitselt ühekordseks rikke kohaks.
Just selle ülemineku ajal kukkus kanal Moskva ja Peterburi vahel. Me olime tegelikult viie minuti jooksul DNS-ita ja saime uuesti tööle, kui hostija vead likvideeriti. 

Kokkuvõtted:

Kui varem olime me välistest teguritest tööde ettevalmistamisel mööda vaadanud, siis nüüd oleme need ka ettevalmistuse nimekirja lisanud. Ja nüüd püüame tagada, et kõik komponendid on reserveeritud n-2, ja tööde ajaks saame selle taseme langetada n-1.

• Tegevusplaani koostamisel märkige üles punktid, kus teenus võib kokku kukkuda, ja mõelge läbi stsenaarium, kus kõik läheb halvasti, ette.
• Jaotage sise dns-serverid erinevatesse geolokatsioonidesse/andmekeskustesse/rakendustesse/lülititesse/sisenditesse.
• Iga serveri jaoks seadke üles lokaalset vahemälu dns-serverit, mis suunab päringud peamistele dns-serveritele ning juhul, kui see ei ole saadaval, vastab vahemälust. 

Neljas koht - "Korrastame Nginx'i"

Ühel kenal päeval otsustas meie meeskond, et „piisab sellest talumisest“, ja algas nginx-i konfiguratsioonide refaktoreerimise protsess. Peamine eesmärk on tuua konfiguratsioonid intuitiivselt arusaadavasse struktuuri. Varem oli kõik olnud „ajaloo tõttu” ja loogikat ei olnud. Nüüd on iga server_name viidatud sama nimega faili ja kõik konfiguratsioonid on jaotatud kaustadesse. Muide - konfiguratsioon sisaldab 253949 rida või 7836520 märki ja on peaaegu 7 megabaiti suur. Ülemise taseme struktuur: 

Nginx 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

On parem, kuid konfigureerimise ümbernimetamise ja jagamise käigus oli mitmel neist vale laiend ja nad ei sattunud direktiivi include *.conf. Selle tulemusena olid mõned hostid kättesaamatud ja suunati 301 põhilehe poole. Kuna vastuskood ei olnud 5xx/4xx, märkasime seda alles hommikul. Pärast seda hakkasime kirjutama teste infrastruktuuri komponentide kontrollimiseks.

Kokkuvõtted: 

• Struktureerige konfigureerimine õigesti (mitte ainult nginx) ja mõelge struktuuri varajases projekti etapis. Nii teete need meeskonnale arusaadavamaks, mis omakorda vähendab TTM-i.
• Kirjutage mõne infrastruktuuri komponendi jaoks teste. Näiteks: kontrollige, et kõik olulised server_name tagastavad õige staatuse ja vastuse keha. Piisab, kui teil on lihtsalt paar skripti, mis kontrollivad komponendi põhifunktsioone, et mitte 3 öösel põhjalikult mõelda, mida veel kontrollida. 

Kolmas koht — "Ühtäkki lõppes koht Cassandra's"

Andmed kasvasid järk-järgult ja kõik oli hästi, kuni Cassandra klastris hakkasid kukkuma repair suurtel keyspace'idel, kuna compaction ei saanud töötada. 

Ühel sombusel päeval muutus klaster peaaegu kõrvitsaks, nimelt:

• koha jäi klastrisse umbes 20%;
• täielikult node'e lisada ei saa, kuna node'i lisamise järel ei toimu cleanup-i ruumi puudumise tõttu partitsioonides;
• tootlikkus langeb tasapisi, kuna compaction ei toimi; 
• klaster töötab avariirežiimis.

Väljund — lisasime veel 5 sõlme ilma puhastuseta, pärast mida hakkasime järk-järgult klastrist eemaldama ja uuesti lisama, nagu tühjad sõlmed, millel ruum lõppes. Aega on kulutatud oluliselt rohkem, kui oleks soovinud. Oli oht osalise või täieliku klastrite kättesaamatuse osas. 

Kokkuvõtted:

• Kõikidel cassandra serveritel ei tohi iga jaotuse peal olla rohkem kui 60% ruumi kasutuses. 
• Need ei tohi olla laaditud rohkem kui 50% CPU-st.
• Ärge unustage mahtude planeerimist ja seda tuleks mõelda iga kompoondi suhtes, lähtudes tema spetsiifikast.
• Mida rohkem sõlmi klastris, seda parem. Serverid, mis sisaldavad väikest andmemahu, laaditakse kiiremini ja sellist klastrit on lihtsam taastada. 

Teine koht — „Andmed kadusid consul key-value salvestusest“

Teenuste avastamiseks kasutame nagu paljud teisedki consul. Kuid meil kasutatakse tema key-value veel ka monoliidi blue-green välja laskmiseks. Seal hoitakse teavet aktiivsete ja mitteaktiivsete upstreamide kohta, mis vahetavad kohti juurutamise ajal. Selleks kirjutati juurutamise teenus, mis suhtles KV-ga. Ühel hetkel kadusid andmed KV-st. Taastasime mälust, kuid mitmete vigadega. Tagajärjena jaotati koormus upstreamidele ebaühtlaselt ja saime palju 502 vigu, kuna backendide CPU oli üle koormatud. Lõppkokkuvõttes kolisime consul KV-lt postgres'i, kust nende eemaldamine ei ole enam nii lihtne.  

Kokkuvõtted:

• Teenused, millel ei ole mingit autoriseerimist, ei tohi sisaldada veebisaidi toimimiseks kriitilisi andmeid. Näiteks, kui teil ei ole autoriseerimist ES-is — oleks parem keelata juurdepääs võrgu tasemel kõikjal, kus see ei ole vajalik, jätta alles ainult vajalikud, ning seada action.destructive_requires_name: true.
• Harjutage varukoopiate ja taastamise mehhanismi eelnevalt. Näiteks kirjutage ette skript (näiteks pythonis), mis oskab nii varundada kui ka taastada.

Esimene koht — „Kapten ebaselgus“ 

Mingil hetkel märkamisime, et nginx'i ülesvoolude koormus oli ebaühtlaselt jaotunud, kui tagaplaanil oli rohkem kui 10 serverit. Kuna round-robin suunas päringud esimesest kuni viimase ülesvooluni järjestikku ja iga nginx'i uuendamine algas algusest, said esimesed ülesvoolud alati rohkem päringuid kui teised. Selle tulemusena töötasid nad aeglasemalt ja kogu veebisait kannatas. See muutus üha silmatorkavamaks, kui liiklus suurenes. Lihtne nginx'i värskendamine random'i toeks ei piisand — pidime ümber tegema hulga lua koodi, mis versioonil 1.15 ei töötanud (selles hetkes). Me pidime patšima meie nginx 1.14.2, lisades sellele random'i toe. See lahendas probleemi. See bugi võidab “kapteni ebaselgus” auhinna.

Kokkuvõtted:

See oli väga huvitav ja kaasahaarav uurida seda viga). 

• Seadke jälgimine üles nii, et see aitaks kiiresti leida sarnaseid fluctuaatsioone. Näiteks võib kasutada ELK-d, et jälgida rps-i iga tagaplaani jaoks iga ülesvoolu puhul ning jälgida nende vastusaega nginx'i kontekstis. Sel juhul aitas see meil probleemi tuvastada. 

Suurema osa ebaõnnestumisi oleks saanud vältida, kui oleksime lähenenud asjadele põhjalikumalt. Peame alati meeles pidama Murphy seadust: Anything that can go wrong will go wrong, ja ehitama komponente, lähtudes sellest. 

Allikas: habr.com