Top fakapov Cyan

Gera visiems! 

Mano vardas Nikita, aš esu Cian inžinierių komandos vadovas. Viena iš mano pareigų įmonėje – iki nulio sumažinti incidentų, susijusių su infrastruktūra gamyboje, skaičių.
Tai, kas bus aptarta toliau, atnešė mums daug skausmo, o šio straipsnio tikslas – neleisti kitiems žmonėms kartoti mūsų klaidų arba bent jau sumažinti jų poveikį. 

Preambulė

Seniai, kai Cian susidėjo iš monolitų, o apie mikropaslaugas dar nebuvo užuominų, resurso prieinamumą matavome patikrinę 3-5 puslapius. 

Jie atsako - viskas gerai, jei ilgai neatsiliepia - budrūs. Kiek laiko jie turėjo būti nedarbingi, kad tai būtų laikoma incidentu, žmonės spręsdavo susirinkimuose. Įvykio tyrime visada dalyvavo inžinierių komanda. Kai tyrimas buvo baigtas, jie surašė pomirtinį pranešimą – savotišką pranešimą el. paštu tokiu formatu: kas atsitiko, kiek tai truko, ką veikėme šiuo metu, ką darysime ateityje. 

Pagrindiniai svetainės puslapiai arba kaip mes suprantame, kad pataikėme į dugną

 
Siekdami kažkaip suprasti klaidos prioritetą, nustatėme svarbiausius verslo funkcionalumui svetainės puslapius. Naudodami juos skaičiuojame sėkmingų/nesėkmingų užklausų skaičių ir skirtąjį laiką. Taip mes matuojame veikimo laiką. 

Tarkime, išsiaiškinome, kad svetainėje yra nemažai itin svarbių skilčių, kurios yra atsakingos už pagrindinę paslaugą – skelbimų paiešką ir pateikimą. Jei nepavykusių užklausų skaičius viršija 1%, tai yra kritinis incidentas. Jei per 15 minučių geriausiu laiku klaidų lygis viršija 0,1%, tai taip pat laikoma kritiniu incidentu. Šie kriterijai apima daugumą incidentų, o kiti nepatenka į šio straipsnio taikymo sritį.

Geriausi incidentai Cyan

Taigi, mes tikrai išmokome nustatyti incidento faktą. 

Dabar kiekvienas incidentas yra išsamiai aprašytas ir atspindėtas Jira epe. Beje: tam pradėjome atskirą projektą, pavadintą FAIL – jame galima kurti tik epas. 

Jei surinksite visas nesėkmes per pastaruosius kelerius metus, lyderiai yra: 

• su mssql susiję incidentai;
• incidentai, kuriuos sukelia išoriniai veiksniai;
• admin klaidos.

Pažvelkime išsamiau į administratorių klaidas, taip pat kai kurias kitas įdomias nesėkmes.

Penkta vieta - „Danalų sutvarkymas DNS“

Buvo audringas antradienis. Nusprendėme atkurti tvarką DNS klasteryje. 

Norėjau perkelti vidinius DNS serverius iš bind į powerdns, skirdamas tam visiškai atskirus serverius, kuriuose nėra nieko, išskyrus DNS. 

Įdėjome po vieną DNS serverį kiekvienoje DC vietoje ir atėjo laikas perkelti zonas iš bind į powerdns ir perjungti infrastruktūrą į naujus serverius. 

Įpusėjus perkėlimui iš visų serverių, kurie buvo nurodyti vietiniuose talpyklos susiejuose visuose serveriuose, liko tik vienas, kuris buvo duomenų centre Sankt Peterburge. Iš pradžių ši nuolatinė srovė mums buvo paskelbta nekritine, bet staiga tapo vieninteliu gedimo tašku.
Būtent šiuo perkėlimo laikotarpiu nugriuvo kanalas tarp Maskvos ir Sankt Peterburgo. Iš tikrųjų penkias minutes likome be DNS ir vėl atsikėlėme, kai prieglobos serveris išsprendė problemą. 

Išvados:

Jei anksčiau ruošdamiesi darbui nepaisydavome išorinių veiksnių, tai dabar jie taip pat įtraukti į sąrašą, kam ruošiamės. Ir dabar mes siekiame, kad visi komponentai būtų rezervuoti n-2, o darbo metu galime sumažinti šį lygį iki n-1.

• Rengdami veiksmų planą, pažymėkite taškus, kur paslauga gali nepavykti, ir iš anksto pagalvokite apie scenarijų, kur viskas klostėsi „iš blogo į dar blogiau“.
• Paskirstykite vidinius DNS serverius įvairiose geografinėse vietose / duomenų centruose / stovuose / jungikliuose / įvestise.
• Kiekviename serveryje įdiekite vietinį talpyklos DNS serverį, kuris nukreipia užklausas į pagrindinius DNS serverius, o jei jis nepasiekiamas, atsakys iš talpyklos. 

Ketvirta vieta - „Daiktų sutvarkymas Nginx“

Vieną gražią dieną mūsų komanda nusprendė, kad „mums to jau gana“, ir prasidėjo nginx konfigūracijų pertvarkymo procesas. Pagrindinis tikslas yra sukurti konfigūracijas į intuityvią struktūrą. Anksčiau viskas buvo „istoriškai nustatyta“ ir neturėjo jokios logikos. Dabar kiekvienas serverio_pavadinimas buvo perkeltas į to paties pavadinimo failą ir visos konfigūracijos paskirstytos į aplankus. Beje, konfigūracijoje yra 253949 eilučių arba 7836520 simbolių ir ji užima beveik 7 megabaitus. Aukščiausias struktūros lygis: 

Nginx struktūra

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

Jis tapo daug geresnis, tačiau pervadinant ir platinant konfigūracijas, kai kurios iš jų turėjo netinkamą plėtinį ir nebuvo įtrauktos į include *.conf direktyvą. Dėl to kai kurie prieglobos įrenginiai tapo nepasiekiami ir grąžino 301 į pagrindinį puslapį. Dėl to, kad atsakymo kodas nebuvo 5xx/4xx, tai pastebėta ne iš karto, o tik ryte. Po to pradėjome rašyti testus infrastruktūros komponentams patikrinti.

Išvados: 

• Teisingai struktūrizuokite savo konfigūracijas (ne tik nginx) ir pagalvokite apie struktūrą ankstyvame projekto etape. Taip jūs padarysite juos suprantamesnius komandai, o tai savo ruožtu sumažins TTM.
• Parašykite kai kurių infrastruktūros komponentų testus. Pavyzdžiui: patikrinkite, ar visi raktų serverio_pavadinimai turi teisingą būseną + atsakymo tekstas. Užteks po ranka turėti vos kelis scenarijus, kurie tikrina pagrindines komponento funkcijas, kad 3 valandą nakties įnirtingai neprisimintų, ką dar reikia patikrinti. 

Trečia vieta - „Staiga pritrūko vietos Kasandroje“

Duomenys augo stabiliai, ir viskas buvo gerai iki to momento, kai Cassandra klasteryje pradėjo trikti didelių korpusų remontas, nes sutankinimas negalėjo veikti. 

Vieną audringą dieną spiečius vos nevirto moliūgu, būtent:

• klasteryje buvo likę apie 20% visos erdvės;
• Neįmanoma visiškai pridėti mazgų, nes pridėjus mazgą išvalymas nevyksta dėl vietos trūkumo skaidiniuose;
• našumas palaipsniui mažėja, nes neveikia tankinimas; 
• Klasteris veikia avariniu režimu.

Išeiti – pridėjome dar 5 mazgus be valymo, po to pradėjome sistemingai juos pašalinti iš klasterio ir vėl įvesti, kaip tuščius mazgus, kuriems pritrūko vietos. Buvo praleista daug daugiau laiko nei norėtume. Kilo grėsmė, kad klasteris bus iš dalies arba visiškai nepasiekiamas. 

Išvados:

• Visuose „cassandra“ serveriuose turi būti užimta ne daugiau kaip 60% kiekvienos skaidinio vietos. 
• Jie turi būti įkeliami ne daugiau kaip 50% procesoriaus.
• Neturėtumėte pamiršti apie pajėgumų planavimą ir pagalvokite apie kiekvieną komponentą, atsižvelgiant į jo specifiką.
• Kuo daugiau mazgų klasteryje, tuo geriau. Serveriai, kuriuose yra nedidelis duomenų kiekis, perkraunami greičiau, o tokį klasterį lengviau atgaivinti. 

Antroji vieta – „Duomenys dingo iš konsulo raktų vertės saugyklos“

Norėdami rasti paslaugą, mes, kaip ir daugelis, naudojame konsulą. Tačiau mes taip pat naudojame jo pagrindinę reikšmę mėlynai žaliai monolito išdėstymui. Jame saugoma informacija apie aktyvius ir neaktyvius prieš srovę, kurie keičiasi vietomis diegimo metu. Tam tikslui buvo parašyta dislokavimo tarnyba, kuri bendravo su KV. Tam tikru momentu KV duomenys dingo. Atkurta iš atminties, bet su daugybe klaidų. Dėl to įkėlimo metu apkrova prieš srovę buvo paskirstyta netolygiai ir gavome daug 502 klaidų dėl procesoriaus perkrautų backendų. Dėl to iš konsulo KV persikėlėme į postgres, iš kur juos pašalinti nebėra taip paprasta.  

Išvados:

• Paslaugose be jokio leidimo neturėtų būti duomenų, kurie yra svarbūs svetainės veikimui. Pavyzdžiui, jei neturite autorizacijos ES, geriau uždrausti prieigą tinklo lygiu iš visur, kur to nereikia, palikite tik būtinus, taip pat nustatykite action.desstructive_requires_name: true.
• Iš anksto pasinaudokite atsarginės kopijos kūrimo ir atkūrimo mechanizmu. Pavyzdžiui, iš anksto sukurkite scenarijų (pavyzdžiui, python), kuris gali sukurti atsarginę kopiją ir atkurti.

Pirmoji vieta - „Neakivaizdus kapitonas“ 

Tam tikru momentu pastebėjome netolygų nginx apkrovos pasiskirstymą prieš srovę tais atvejais, kai užpakalinėje sistemoje buvo 10 ir daugiau serverių. Dėl to, kad apvaliai siųsdavo užklausas nuo 1-os iki paskutinės eilės, o kiekvienas nginx perkrovimas prasidėdavo iš naujo, pirmieji aukštyn įkeliami visada gaudavo daugiau užklausų nei kiti, todėl veikė lėčiau ir nukentėjo visa svetainė. Tai tapo vis labiau pastebima didėjant srautui. Paprasčiausias nginx atnaujinimas, kad būtų įjungtas atsitiktinis, nepavyko – turime perdaryti daugybę lua kodų, kurie nepasirodė 1.15 versijoje (tuo metu). Turėjome pataisyti savo nginx 1.14.2, įtraukdami į ją atsitiktinį palaikymą. Tai išsprendė problemą. Ši klaida laimi kategoriją „Neakivaizdus kapitonas“.

Išvados:

Buvo labai įdomu ir įdomu ištirti šią klaidą). 

• Stebėjimą organizuokite taip, kad tai padėtų greitai rasti tokius svyravimus. Pavyzdžiui, galite naudoti ELK, kad stebėtumėte rps kiekvienoje prieš srovę kiekvienoje pusėje, stebėtumėte jų atsako laiką nginx požiūriu. Šiuo atveju tai padėjo mums nustatyti problemą. 

Dėl to daugumos nesėkmių buvo galima išvengti skrupulingesniu požiūriu į tai, ką darai. Mes visada turime prisiminti Merfio dėsnį: Viskas, kas gali suklysti, sutiks, ir pagal jį kurti komponentus. 

Šaltinis: www.habr.com