Top fakapov Cyan

Hamma yaxshi! 

Mening ismim Nikita, men Cian muhandislik guruhining guruh rahbariman. Kompaniyadagi vazifalarimdan biri ishlab chiqarishdagi infratuzilma bilan bog'liq hodisalar sonini nolga tushirishdir.
Quyida muhokama qilinadigan narsalar bizga juda ko'p og'riq keltirdi va ushbu maqolaning maqsadi boshqa odamlarning xatolarimizni takrorlashiga yo'l qo'ymaslik yoki hech bo'lmaganda ularning ta'sirini kamaytirishdir. 

Ibtido

Uzoq vaqt oldin, Cian monolitlardan iborat bo'lganida va hali mikroservislar haqida hech qanday maslahatlar bo'lmaganida, biz 3-5 sahifani tekshirish orqali resurs mavjudligini o'lchadik. 

Ular javob berishadi - hammasi yaxshi, agar ular uzoq vaqt javob bermasalar - ogohlantirish. Hodisa deb hisoblanishi uchun ular qancha vaqt ishdan bo'shashlari kerakligi yig'ilishlarda hal qilindi. Hodisani tergov qilishda doimo muhandislar guruhi ishtirok etgan. Tergov tugagach, ular o'limdan keyingi xabarni yozishdi - bu formatda elektron pochta orqali hisobot: nima bo'ldi, u qancha davom etdi, biz hozir nima qildik, kelajakda nima qilamiz. 

Saytning asosiy sahifalari yoki biz pastga tushganimizni qanday tushunamiz

 
Xatoning ustuvorligini qandaydir tarzda tushunish uchun biz biznes faoliyati uchun eng muhim sayt sahifalarini aniqladik. Ulardan foydalanib, biz muvaffaqiyatli/muvaffaqiyatsiz so'rovlar va kutish vaqtini hisoblaymiz. Biz ish vaqtini shunday o'lchaymiz. 

Aytaylik, biz saytning asosiy xizmat - reklamalarni qidirish va yuborish uchun mas'ul bo'lgan bir qator o'ta muhim bo'limlari borligini aniqladik. Muvaffaqiyatsiz bo'lgan so'rovlar soni 1% dan oshsa, bu juda muhim voqea. Agar prime-taym vaqtida 15 daqiqa ichida xatolik darajasi 0,1% dan oshsa, bu ham muhim voqea hisoblanadi. Ushbu mezonlar aksariyat hodisalarni qamrab oladi, qolganlari esa ushbu maqola doirasidan tashqarida.

Eng yaxshi voqealar Cyan

Shunday qilib, biz voqea sodir bo'lganligini aniq aniqlashni o'rgandik. 

Endilikda har bir voqea batafsil tasvirlanib, Jira dostonida aks ettirilgan. Aytgancha: buning uchun biz FAIL deb nomlangan alohida loyihani boshladik - unda faqat dostonlarni yaratish mumkin. 

Agar siz so'nggi bir necha yildagi barcha muvaffaqiyatsizliklarni to'plasangiz, etakchilar: 

• mssql bilan bog'liq hodisalar;
• tashqi omillar ta'sirida sodir bo'lgan hodisalar;
• administrator xatolar.

Keling, ma'murlarning xatolarini, shuningdek, boshqa qiziqarli muvaffaqiyatsizliklarni batafsil ko'rib chiqaylik.

Beshinchi o'rin - "DNS-da narsalarni tartibga solish"

Bo'ronli seshanba edi. Biz DNS klasterida tartibni tiklashga qaror qildik. 

Men ichki DNS serverlarini bog'lashdan powerdns-ga o'tkazmoqchi bo'ldim, buning uchun DNS-dan boshqa hech narsa yo'q, buning uchun butunlay alohida serverlarni ajratdim. 

Biz DC-ning har bir joyiga bittadan DNS serverini joylashtirdik va zonalarni bog'lashdan powerdns-ga o'tkazish va infratuzilmani yangi serverlarga o'tkazish vaqti keldi. 

Harakat paytida, barcha serverlarda mahalliy keshlashda ko'rsatilgan barcha serverlardan faqat bittasi Sankt-Peterburgdagi ma'lumotlar markazida qoldi. Ushbu DC dastlab biz uchun tanqidiy emas deb e'lon qilindi, lekin birdaniga bitta muvaffaqiyatsizlik nuqtasiga aylandi.
Aynan shu ko'chirish davrida Moskva va Sankt-Peterburg o'rtasidagi kanal qulab tushdi. Biz aslida besh daqiqa davomida DNSsiz qoldik va hoster muammoni hal qilganda qayta turdik. 

Natijalar:

Agar ilgari biz ishga tayyorgarlik jarayonida tashqi omillarni e'tiborsiz qoldirgan bo'lsak, endi ular ham biz tayyorlayotgan narsalar ro'yxatiga kiritilgan. Va endi biz barcha komponentlar n-2 zaxiralanganligini ta'minlashga intilamiz va ish davomida biz bu darajani n-1 ga tushirishimiz mumkin.

• Harakatlar rejasini tuzayotganda, xizmat muvaffaqiyatsiz bo'lishi mumkin bo'lgan nuqtalarni belgilang va hamma narsa "yomondan yomonroq" bo'lgan stsenariyni oldindan o'ylab ko'ring.
• Ichki DNS-serverlarni turli xil geolokatsiyalar/ma'lumotlar markazlari/racklar/kalitlar/kirishlar bo'ylab tarqating.
• Har bir serverda so'rovlarni asosiy DNS serverlariga yo'naltiradigan mahalliy keshlash DNS serverini o'rnating va agar u mavjud bo'lmasa, u keshdan javob beradi. 

To'rtinchi o'rin - "Nginx-da narsalarni tartibga solish"

Yaxshi kunlarning birida jamoamiz “bizda bundan yetarlicha bo‘ldi” degan qarorga keldi va nginx konfiguratsiyasini qayta tiklash jarayoni boshlandi. Asosiy maqsad konfiguratsiyalarni intuitiv tuzilishga keltirishdir. Ilgari hamma narsa "tarixiy ravishda o'rnatilgan" va hech qanday mantiqqa ega emas edi. Endi har bir server_name bir xil nomdagi faylga ko'chirildi va barcha konfiguratsiyalar papkalarga taqsimlandi. Aytgancha, konfiguratsiya 253949 satr yoki 7836520 belgini o'z ichiga oladi va deyarli 7 megabaytni egallaydi. Strukturaning yuqori darajasi: 

Nginx tuzilishi

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

Bu ancha yaxshilandi, lekin konfiguratsiyalarni qayta nomlash va tarqatish jarayonida ularning ba'zilari noto'g'ri kengaytmaga ega bo'lib, *.conf direktivasiga kiritilmagan. Natijada, ba'zi xostlar ishlamay qoldi va 301-ni asosiy sahifaga qaytardi. Javob kodi 5xx/4xx emasligi sababli, bu darhol sezilmadi, faqat ertalab. Shundan so'ng biz infratuzilma komponentlarini tekshirish uchun testlar yozishni boshladik.

Natijalar: 

• Konfiguratsiyalaringizni to'g'ri tuzing (nafaqat nginx) va loyihaning dastlabki bosqichida tuzilmani o'ylab ko'ring. Shunday qilib, siz ularni jamoaga tushunarli qilib qo'yasiz, bu esa o'z navbatida TTMni kamaytiradi.
• Ba'zi infratuzilma komponentlari uchun testlarni yozing. Masalan: barcha kalit server_nomlari to'g'ri holat + javob tanasini berishini tekshirish. Ertalab soat 3 da yana nimani tekshirish kerakligini eslab qolmaslik uchun komponentning asosiy funktsiyalarini tekshiradigan bir nechta skriptlar bo'lishi kifoya. 

Uchinchi o'rin - "Kassandrada to'satdan joy qolmadi"

Ma'lumotlar doimiy ravishda o'sib bordi va Cassandra klasterida katta kassa bo'shliqlarini ta'mirlash muvaffaqiyatsiz bo'lgunga qadar hammasi yaxshi edi, chunki siqishni ular ustida ishlay olmadi. 

Bo'ronli kunlarning birida klaster deyarli qovoqqa aylandi, xususan:

• klasterda umumiy bo'sh joyning taxminan 20% qolgan;
• Tugunlarni to'liq qo'shish mumkin emas, chunki bo'limlarda bo'sh joy yo'qligi sababli tugunni qo'shgandan keyin tozalash o'tmaydi;
• mahsuldorlik asta-sekin pasayib bormoqda, chunki siqilish ishlamayapti; 
• Klaster favqulodda rejimda.

Chiqish - biz yana 5 ta tugunni tozalamasdan qo'shdik, shundan so'ng biz ularni tizimli ravishda klasterdan olib tashlashni va bo'sh joy tugab qolgan bo'sh tugunlar kabi qayta kiritishni boshladik. Biz xohlaganimizdan ham ko'proq vaqt sarflandi. Klasterning qisman yoki to'liq ishlamasligi xavfi mavjud edi. 

Natijalar:

• Barcha cassandra serverlarida har bir bo'limda bo'sh joyning 60% dan ko'p bo'lmasligi kerak. 
• Ular 50% dan ko'p bo'lmagan CPU bilan yuklanishi kerak.
• Imkoniyatlarni rejalashtirish haqida unutmasligingiz kerak va har bir komponent uchun uning o'ziga xos xususiyatlaridan kelib chiqqan holda o'ylab ko'rishingiz kerak.
• Klasterdagi tugunlar qancha ko'p bo'lsa, shuncha yaxshi. Kichik miqdordagi ma'lumotlarni o'z ichiga olgan serverlar tezroq yuklanadi va bunday klasterni qayta tiklash osonroq. 

Ikkinchi o'rin - "Konsul kalit-qiymati omboridan ma'lumotlar yo'qoldi"

Xizmatni topish uchun biz, ko'pchilik singari, konsuldan foydalanamiz. Ammo biz monolitning ko'k-yashil tartibi uchun uning kalit-qiymatidan ham foydalanamiz. U o'rnatish vaqtida joylarni o'zgartiradigan faol va nofaol yuqori oqimlar haqidagi ma'lumotlarni saqlaydi. Shu maqsadda KV bilan o'zaro aloqada bo'lgan joylashtirish xizmati yozildi. Bir nuqtada KV dan ma'lumotlar yo'qoldi. Xotiradan tiklandi, lekin bir qator xatolar bilan. Natijada, yuklash vaqtida yuqori oqimdagi yuk notekis taqsimlandi va biz protsessorga orqa qismlar haddan tashqari yuklanganligi sababli ko'plab 502 xatoga yo'l qo'ydik. Natijada biz konsul KVdan postgresga o'tdik, u erdan ularni olib tashlash endi unchalik oson emas.  

Natijalar:

• Hech qanday ruxsatsiz xizmatlar sayt faoliyati uchun muhim ma'lumotlarni o'z ichiga olmaydi. Misol uchun, agar sizda ESda avtorizatsiya bo'lmasa, kerak bo'lmagan hamma joydan tarmoq darajasida kirishni rad etish, faqat keraklilarini qoldirish, shuningdek action.destructive_requires_name: true o'rnatish yaxshiroqdir.
• Zaxira va tiklash mexanizmingizni oldindan mashq qiling. Misol uchun, zaxira nusxasini yaratish va tiklash mumkin bo'lgan skriptni oldindan tayyorlang (masalan, pythonda).

Birinchi o'rin - "Kapitan Unobvious" 

Bir nuqtada, biz backendda 10+ server bo'lgan hollarda nginx yuqori oqimlarida yukning notekis taqsimlanishini payqadik. Round-robin so'rovlarni 1-dan oxirgi yuqoriga tartibda yuborganligi va har bir nginx qayta yuklanishi qayta boshlanganligi sababli, birinchi yuqori oqimlar qolganlaridan ko'ra ko'proq so'rovlarni qabul qilishdi.Natijada ular sekinroq ishladi va butun sayt zarar ko'rdi. Bu trafik miqdori oshgani sayin tobora sezilarli bo'ldi. Tasodifiyni yoqish uchun oddiygina nginx-ni yangilash ishlamadi - biz 1.15 versiyasida (o'sha paytda) ochilmagan bir qator lua kodlarini qayta tiklashimiz kerak. Biz nginx 1.14.2 ni tuzatishimiz kerak edi, unga tasodifiy qo'llab-quvvatlash kiritildi. Bu muammoni hal qildi. Ushbu xato "Kapitanning aniq emasligi" toifasida g'olib chiqadi.

Natijalar:

Bu xatoni o'rganish juda qiziqarli va hayajonli edi). 

• Monitoringni shunday tashkil qilingki, u sizga bunday tebranishlarni tezda topishga yordam beradi. Masalan, siz ELK-dan har bir yuqori oqimning har bir orqa tomonidagi rpsni kuzatish, ularning javob vaqtini nginx nuqtai nazaridan kuzatish uchun foydalanishingiz mumkin. Bunday holda, bu muammoni aniqlashga yordam berdi. 

Natijada, qilayotgan ishingizga jiddiyroq yondashish orqali ko'pgina muvaffaqiyatsizliklarning oldini olish mumkin edi. Biz har doim Merfi qonunini yodda tutishimiz kerak: Xato bo'lishi mumkin bo'lgan har qanday narsa noto'g'ri bo'ladi, va uning asosida komponentlar qurish. 

Manba: www.habr.com