Har bir inson ishlab chiqish va sinovdan o'tkazish, xodimlarni o'qitish, motivatsiyani oshirish jarayonlari haqida gapiradi, biroq xizmat ko'rsatishning bir daqiqasi to'xtab qolish juda katta mablag'ni talab qilganda bu jarayonlar etarli emas. Qattiq SLA bo'yicha moliyaviy operatsiyalarni amalga oshirganingizda nima qilish kerak? Tizimlarning ishonchliligi va nosozliklarga chidamliligini qanday oshirish mumkin, ishlab chiqish va sinovni tenglamadan chiqarib tashlash mumkin?
Keyingi HighLoad++ konferensiyasi 6 yilning 7 va 2020 aprel kunlari Sankt-Peterburgda bo‘lib o‘tadi. Tafsilotlar va chiptalar . 9-noyabr, soat 18:00. HighLoad++ Moskva 2018, Dehli + Kolkata zali. Tezislar va .
Evgeniy Kuzovlev (keyingi o'rinlarda - EC): - Do'stlar, salom! Mening ismim Kuzovlev Evgeniy. Men EcommPay kompaniyasidanman, o'ziga xos bo'linma EcommPay IT, kompaniyalar guruhining IT bo'limidir. Va bugun biz uzilishlar haqida gaplashamiz - ulardan qanday qochish kerak, agar oldini olishning iloji bo'lmasa, oqibatlarini qanday kamaytirish haqida. Mavzu quyidagicha bayon etilgan: “Bir daqiqalik ishlamay qolish 100 000 dollarga tushsa nima qilish kerak”? Oldinga qarab, bizning raqamlarimiz solishtirish mumkin.
EcommPay IT nima qiladi?
Biz kimmiz? Nega men sizning oldingizda turibman? Nega bu yerda sizga bir narsa aytishga haqqim bor? Va bu erda nima haqida batafsilroq gaplashamiz?
EcommPay kompaniyalar guruhi xalqaro ekvayer hisoblanadi. Biz butun dunyo bo'ylab to'lovlarni amalga oshiramiz - Rossiyada, Evropada, Janubi-Sharqiy Osiyoda (butun dunyo bo'ylab). Bizning 9 ta ofisimiz, jami 500 nafar xodimimiz bor va ularning yarmidan sal kamrog'i IT-mutaxassislaridir. Biz qiladigan hamma narsa, pul topadigan hamma narsani o'zimiz qildik.
Biz barcha mahsulotlarimizni o'zimiz yozganmiz (va bizda ularning ko'pi bor - bizning yirik IT-mahsulotlarimiz qatorida taxminan 16 xil komponentlar mavjud); Biz o'zimizni yozamiz, o'zimizni rivojlantiramiz. Va hozirda biz kuniga bir millionga yaqin tranzaktsiyalarni amalga oshirmoqdamiz (millionlar, ehtimol, buni aytishning to'g'ri yo'lidir). Biz juda yosh kompaniyamiz - biz atigi olti yoshdamiz.
6 yil oldin, yigitlar biznes bilan birga kelganlarida, bu shunday startap edi. Ularni g‘oya birlashtirdi (g‘oyadan boshqa narsa yo‘q edi), biz yugurdik. Har qanday startap singari biz ham tezroq yugurdik... Biz uchun tezlik sifatdan muhimroq edi.
Bir nuqtada biz to'xtadik: biz endi qandaydir tarzda bu tezlikda va bu sifatda yashay olmasligimizni angladik va birinchi navbatda sifatga e'tibor qaratishimiz kerak. Ayni paytda biz to'g'ri, kengaytiriladigan va ishonchli bo'lgan yangi platforma yozishga qaror qildik. Ular ushbu platformani yozishni boshladilar (ular sarmoya kiritishni, ishlab chiqishni, test qilishni boshladilar), lekin bir nuqtada ular ishlab chiqish va sinov bizga xizmat ko'rsatish sifatining yangi darajasiga chiqishga imkon bermasligini tushunishdi.
Siz yangi mahsulot ishlab chiqarasiz, uni ishlab chiqarishga kiritasiz, lekin baribir qaerdadir noto'g'ri bo'ladi. Va bugun biz yangi sifat darajasiga qanday erishish haqida gaplashamiz (biz buni qanday qildik, tajribamiz haqida), ishlab chiqish va sinovni tenglamadan chiqarib tashlash; biz ishlash uchun mavjud bo'lgan narsalar haqida gaplashamiz - qanday operatsiyani o'zi bajarishi mumkinligi, sifatga ta'sir qilish uchun sinovdan nimani taklif qilishi mumkin.
To'xtash vaqtlari. Operatsion buyruqlari.
Har doim asosiy burchak toshi, biz bugun gaplashadigan narsa - bu ishlamay qolish vaqti. Dahshatli so'z. Agar bizda ishlamay qolsa, hamma narsa biz uchun yomon. Biz uni ko'tarish uchun yuguramiz, adminlar serverni ushlab turishadi - o'sha qo'shiqda aytganidek, xudo yiqilmasin. Bugun biz bu haqda gaplashamiz.
Yondashuvlarimizni o'zgartirishni boshlaganimizda, biz 4 ta amrni shakllantirdik. Men ularni slaydlarda taqdim etaman:
Bu amrlar juda oddiy:
- Muammoni tezda aniqlang.
- Undan tezroq qutuling.
- Sababini tushunishga yordam bering (keyinchalik, ishlab chiquvchilar uchun).
- Va yondashuvlarni standartlashtirish.
E'tiboringizni 2-bandga qaratmoqchiman.Biz muammoni hal qilmayapmiz, undan qutulayapmiz. Qaror qabul qilish ikkinchi darajali. Biz uchun asosiy narsa foydalanuvchining ushbu muammodan himoyalanganligidir. U ba'zi bir izolyatsiya qilingan muhitda mavjud bo'ladi, lekin bu muhit u bilan hech qanday aloqada bo'lmaydi. Aslida, biz ushbu to'rtta muammolar guruhini ko'rib chiqamiz (ba'zilari batafsilroq, ba'zilari esa kamroq), men sizga nimadan foydalanayotganimizni, ularni hal qilishda qanday tajribamiz borligini aytib beraman.
Muammolarni bartaraf etish: ular qachon yuz beradi va ular bilan nima qilish kerak?
Lekin biz tartibsiz boshlaymiz, biz 2-banddan boshlaymiz - muammodan qanday tezda qutulish mumkin? Muammo bor - biz uni tuzatishimiz kerak. "Bu haqda nima qilishimiz kerak?" - asosiy savol. Muammoni qanday hal qilish haqida o'ylashni boshlaganimizda, biz o'zimiz uchun muammolarni bartaraf etishda bajarilishi kerak bo'lgan ba'zi talablarni ishlab chiqdik.
Ushbu talablarni shakllantirish uchun biz o'zimizga savol berishga qaror qildik: "Bizda qachon muammolar bor"? Va muammolar, ma'lum bo'lishicha, to'rtta holatda yuzaga keladi:
- Uskuna xatosi.
- Tashqi xizmatlar muvaffaqiyatsiz tugadi.
- Dasturiy ta'minot versiyasini o'zgartirish (xuddi shu tarqatish).
- Portlovchi yukning o'sishi.
Biz birinchi ikkitasi haqida gapirmaymiz. Uskunadagi nosozlikni juda oddiy hal qilish mumkin: sizda hamma narsa takrorlanishi kerak. Agar bu disklar bo'lsa, disklar RAID-da yig'ilishi kerak; agar bu server bo'lsa, server ko'paytirilishi kerak; agar sizda tarmoq infratuzilmasi bo'lsa, siz tarmoq infratuzilmasining ikkinchi nusxasini taqdim qilishingiz kerak, ya'ni siz uni olasiz va uni takrorlang. Va agar biror narsa muvaffaqiyatsiz bo'lsa, siz zaxira quvvatiga o'tasiz. Bu erda ko'proq nimadir deyish qiyin.
Ikkinchisi - tashqi xizmatlarning muvaffaqiyatsizligi. Ko'pchilik uchun tizim umuman muammo emas, lekin biz uchun emas. Biz to'lovlarni amalga oshirganimiz sababli, biz foydalanuvchi (uning karta ma'lumotlarini kiritgan) va banklar, to'lov tizimlari (Visa, MasterCard, Mira va boshqalar) o'rtasida joylashgan agregatormiz. Bizning tashqi xizmatlarimiz (to'lov tizimlari, banklar) muvaffaqiyatsizlikka uchraydi. Biz ham, siz ham (agar sizda bunday xizmatlar bo'lsa) bunga ta'sir qila olmaysiz.
Keyin nima qilish kerak? Bu erda ikkita variant mavjud. Birinchidan, agar imkoningiz bo'lsa, ushbu xizmatni qandaydir tarzda takrorlashingiz kerak. Misol uchun, agar imkonimiz bo'lsa, biz trafikni bir xizmatdan boshqasiga o'tkazamiz: masalan, kartalar Sberbank orqali qayta ishlandi, Sberbank muammolarga duch kelmoqda - biz trafikni [shartli ravishda] Raiffeisenga o'tkazamiz. Biz qila oladigan ikkinchi narsa - tashqi xizmatlarning ishdan chiqishini juda tez payqash va shuning uchun biz hisobotning keyingi qismida javob tezligi haqida gaplashamiz.
Aslida, ushbu to'rttasidan biz dasturiy ta'minot versiyalarining o'zgarishiga aniq ta'sir ko'rsatishimiz mumkin - joylashtirish kontekstida va yukning portlovchi o'sishi kontekstida vaziyatning yaxshilanishiga olib keladigan choralarni ko'rish. Aslida, biz shunday qildik. Mana, yana bir kichik eslatma ...
Ushbu to'rtta muammoning bir nechtasi, agar sizda bulut bo'lsa, darhol hal qilinadi. Agar siz Microsoft Azhur, Ozon bulutlarida bo'lsangiz yoki Yandex yoki Mail-dan bulutlarimizdan foydalansangiz, hech bo'lmaganda apparatdagi nosozlik ularning muammosiga aylanadi va apparatdagi nosozlik kontekstida siz uchun hamma narsa darhol yaxshi bo'ladi.
Biz biroz noan'anaviy kompaniyamiz. Bu erda hamma "Kubernets" haqida, bulutlar haqida gapiradi - bizda "Kubernets" ham, bulutlar ham yo'q. Ammo bizda ko'plab ma'lumotlar markazlarida apparat to'plamlari mavjud va biz ushbu uskunada yashashga majburmiz, biz bularning barchasi uchun javobgar bo'lishga majburmiz. Shuning uchun biz ushbu kontekstda gaplashamiz. Shunday qilib, muammolar haqida. Dastlabki ikkitasi qavslardan chiqarildi.
Dasturiy ta'minot versiyasini o'zgartirish. Bazalar
Ishlab chiquvchilarimiz ishlab chiqarishga kirish imkoniga ega emaslar. Nega bunday? Biz PCI DSS sertifikatiga egamiz va bizning ishlab chiquvchilarimiz shunchaki "mahsulot" ga kirish huquqiga ega emasmiz. Bo'ldi, davr. Umuman. Shuning uchun, ishlab chiqish uchun javobgarlik ishlab chiqish qurilishni chiqarish uchun taqdim etgan paytda tugaydi.
Bizning ikkinchi asosimiz, bu ham bizga juda ko'p yordam beradi, bu noyob hujjatsiz bilimlarning yo'qligi. Umid qilamanki, bu siz uchun ham xuddi shunday. Chunki bunday bo'lmasa, sizda muammolar paydo bo'ladi. Ushbu noyob, hujjatsiz bilim kerakli vaqtda kerakli joyda bo'lmasa, muammolar paydo bo'ladi. Aytaylik, sizda ma'lum bir komponentni qanday joylashtirishni biladigan bitta odam bor - u erda yo'q, u ta'tilda yoki kasal - tamom, sizda muammolar bor.
Va biz kelgan uchinchi asos. Biz bunga og'riq, qon, ko'z yoshlar orqali keldik - biz har qanday qurilishimiz xatosiz bo'lsa ham xatolarni o'z ichiga oladi degan xulosaga keldik. Biz buni o'zimiz uchun qaror qildik: biror narsani o'rnatganimizda, biror narsani ishlab chiqarishga kiritganimizda, bizda xatolar mavjud. Biz tizimimiz qondirishi kerak bo'lgan talablarni shakllantirdik.
Dasturiy ta'minot versiyasini o'zgartirishga qo'yiladigan talablar
Uchta talab mavjud:
- Biz joylashtirishni tezda orqaga qaytarishimiz kerak.
- Muvaffaqiyatsiz joylashtirish ta'sirini minimallashtirishimiz kerak.
- Va biz tezda parallel ravishda joylashtirishimiz kerak.
Aynan shu tartibda! Nega? Chunki, birinchi navbatda, yangi versiyani o'rnatishda tezlik muhim emas, lekin siz uchun, agar biror narsa noto'g'ri bo'lsa, tezda orqaga qaytish va minimal ta'sir ko'rsatish muhimdir. Ammo agar sizda ishlab chiqarishda xatolik yuzaga kelgan versiyalar to'plami bo'lsa (ko'kda, joylashtirish yo'q edi, lekin xatolik bor) - keyingi joylashtirish tezligi siz uchun muhimdir. Bu talablarni qondirish uchun nima qildik? Biz quyidagi metodologiyaga murojaat qildik:
Bu juda yaxshi ma'lum, biz uni hech qachon ixtiro qilmaganmiz - bu Moviy/Yashil joylashtirish. Bu nima? Ilovalaringiz o'rnatilgan serverlarning har bir guruhi uchun sizda nusxa bo'lishi kerak. Nusxa "iliq": unda hech qanday trafik yo'q, lekin istalgan vaqtda ushbu trafik ushbu nusxaga yuborilishi mumkin. Ushbu nusxada oldingi versiya mavjud. Va tarqatish vaqtida siz kodni faol bo'lmagan nusxaga chiqarasiz. Keyin siz trafikning bir qismini (yoki hammasini) yangi versiyaga o'tkazasiz. Shunday qilib, transport oqimini eski versiyadan yangisiga o'zgartirish uchun siz faqat bitta amalni bajarishingiz kerak: yuqori oqimdagi muvozanatni o'zgartirishingiz, yo'nalishni o'zgartirishingiz kerak - bir yuqoridan ikkinchisiga. Bu juda qulay va tez almashtirish va tez qaytarish muammosini hal qiladi.Bu erda ikkinchi savolning yechimi - minimallashtirish: siz trafikning faqat bir qismini yangi qatorga, yangi kodli qatorga yuborishingiz mumkin (masalan, 2%). Va bu 2% 100% emas! Muvaffaqiyatsiz joylashtirish tufayli siz trafikning 100 foizini yo'qotgan bo'lsangiz, bu qo'rqinchli; agar siz trafikning 2 foizini yo'qotgan bo'lsangiz, bu yoqimsiz, ammo qo'rqinchli emas. Bundan tashqari, foydalanuvchilar buni sezishmaydi ham, chunki ba'zi hollarda (hammasida emas) bir xil foydalanuvchi F5 tugmachasini bosib, boshqa ishlaydigan versiyaga o'tadi.
Moviy/yashil joylashish. Marshrutlash
Biroq, hamma narsa juda oddiy emas "Blue / Green deploy" ... Bizning barcha komponentlarimizni uchta guruhga bo'lish mumkin:
- bu frontend (mijozlarimiz ko'radigan to'lov sahifalari);
- qayta ishlash yadrosi;
- to'lov tizimlari bilan ishlash uchun adapter (banklar, MasterCard, Visa...).
Va bu erda bir nuance bor - nuance chiziqlar orasidagi marshrutda yotadi. Agar siz 100% trafikni almashtirsangiz, sizda bunday muammolar bo'lmaydi. Ammo agar siz 2% ni o'zgartirmoqchi bo'lsangiz, siz savollar berishni boshlaysiz: "Buni qanday qilish kerak?" Eng oddiy narsa to'g'ridan-to'g'ri oldinga: siz tasodifiy tanlov orqali nginx-da Round Robin-ni o'rnatishingiz mumkin va sizda 2% chapda, 98% o'ngda. Ammo bu har doim ham mos emas.
Misol uchun, bizning holatlarimizda foydalanuvchi tizim bilan bir nechta so'rovlar bilan o'zaro ishlaydi. Bu normal holat: 2, 3, 4, 5 so'rovlar - tizimlaringiz bir xil bo'lishi mumkin. Va agar siz uchun muhim bo'lsa, foydalanuvchining barcha so'rovlari birinchi so'rov kelgan qatorga to'g'ri keladi yoki (ikkinchi nuqta) foydalanuvchining barcha so'rovlari kommutatordan keyin yangi qatorga keladi (u avvalroq ishlashni boshlashi mumkin edi). tizim, kalitdan oldin), - keyin bu tasodifiy taqsimot siz uchun mos emas. Keyin quyidagi variantlar mavjud:
Birinchi variant, eng oddiy, mijozning asosiy parametrlariga asoslanadi (IP Hash). Sizda IP bor va uni IP manzili bo'yicha o'ngdan chapga ajratasiz. Keyin men ta'riflagan ikkinchi holat siz uchun ishlaydi, o'rnatish sodir bo'lganda, foydalanuvchi allaqachon tizimingiz bilan ishlashni boshlashi mumkin va tarqatilgan paytdan boshlab barcha so'rovlar yangi qatorga o'tadi (aytaylik, xuddi shunday).Agar biron sababga ko'ra bu sizga mos kelmasa va foydalanuvchining dastlabki, dastlabki so'rovi kelgan qatorga so'rov yuborishingiz kerak bo'lsa, sizda ikkita variant bor...
Birinchi variant: pullik nginx+ sotib olishingiz mumkin. Yopishqoq seanslar mexanizmi mavjud bo'lib, u foydalanuvchining dastlabki so'roviga ko'ra foydalanuvchiga sessiya tayinlaydi va uni u yoki bu yuqori oqimga bog'laydi. Seansning amal qilish muddatidagi barcha keyingi foydalanuvchi so'rovlari sessiya joylashtirilgan yuqori oqimga yuboriladi.Bu bizga mos kelmadi, chunki bizda allaqachon oddiy nginx bor edi. Nginx+ ga o'tish qimmat emas, shunchaki bu biz uchun biroz og'riqli va unchalik to'g'ri emas. Masalan, "Sticks Sessions" biz uchun ishlamadi, chunki "Stick Sessions" "Yoki-yoki" asosida marshrutlashga ruxsat bermaydi. U erda biz "Sticks Sessions" nima qilishimizni, masalan, IP-manzil yoki IP-manzil va cookie-fayllar yoki postparametr bo'yicha belgilashingiz mumkin, ammo "Yoki-yoki" u erda murakkabroq.
Shuning uchun biz to'rtinchi variantga keldik. Biz nginx-ni steroidlarda oldik (bu ochiqlikdir) - bu bir xil nginx bo'lib, u qo'shimcha ravishda oxirgi skriptlarni kiritishni qo'llab-quvvatlaydi. Siz oxirgi skriptni yozishingiz, unga "ochiq dam olish" berishingiz mumkin va bu oxirgi skript foydalanuvchi so'rovi kelganda bajariladi.
Va biz yozdik, aslida, bunday skript, o'zimizni "openresti" ni o'rnatdik va bu skriptda biz "Yoki" birikmasi bo'yicha 6 xil parametrlarni saralaymiz. U yoki bu parametrning mavjudligiga qarab, foydalanuvchining u yoki bu sahifaga, u yoki bu qatorga kelganini bilamiz.
Moviy/yashil joylashish. Afzalliklari va kamchiliklari
Albatta, buni biroz soddalashtirish mumkin edi (xuddi shu "Yopishqoq sessiyalar" dan foydalaning), lekin bizda shunday nuance borki, nafaqat foydalanuvchi biz bilan bitta tranzaksiyani qayta ishlash doirasida o'zaro aloqada bo'ladi... Ammo toʻlov tizimlari ham biz bilan oʻzaro aloqada boʻladi: tranzaksiyani amalga oshirganimizdan soʻng (toʻlov tizimiga soʻrov yuborish orqali) biz “sovgʻa”ni olamiz.
Aytaylik, agar bizning sxemamiz ichida biz barcha so'rovlarda foydalanuvchining IP-manzilini yo'naltira olsak va foydalanuvchilarni IP-manzilga qarab taqsimlay olsak, biz o'sha "Visa" ni aytmaymiz: "Do'stim, biz shunday retro kompaniyamiz, biz ko'rinadi. xalqaro bo'lish (veb-saytda va Rossiyada) ... Iltimos, bizga qo'shimcha maydonda foydalanuvchining IP-manzilini taqdim eting, sizning protokolingiz standartlashtirilgan»! Ular rozi bo'lmasligi aniq.
Shuning uchun, bu biz uchun ishlamadi - biz ochiqlik qildik. Shunga ko'ra, marshrutlash bilan biz shunga o'xshash narsani oldik:Moviy/Yashil Deployment, shunga ko'ra, men aytib o'tgan afzalliklarga va kamchiliklarga ega.
Ikki kamchilik:
- marshrutlash bilan bezovta qilishingiz kerak;
- ikkinchi asosiy kamchilik - bu xarajat.
Sizga ikki baravar ko'p serverlar kerak, sizga ikki barobar ko'p operatsion resurslar kerak, bu butun hayvonot bog'ini saqlash uchun ikki barobar ko'proq kuch sarflashingiz kerak.
Aytgancha, afzalliklar orasida men ilgari aytib o'tmagan yana bir narsa bor: sizda yukning o'sishida zaxirangiz bor. Agar sizda yuklanishda portlovchi o'sish bo'lsa, sizda juda ko'p foydalanuvchilar mavjud bo'lsa, siz shunchaki ikkinchi qatorni 50 dan 50 gacha taqsimotga qo'shasiz - va siz ko'proq serverlarga ega bo'lish muammosini hal qilmaguningizcha darhol klasteringizda x2 serverlarga ega bo'lasiz.
Tez joylashtirishni qanday qilish kerak?
Biz minimallashtirish va tez qaytarish muammosini qanday hal qilish haqida gaplashdik, ammo savol qolmoqda: "Qanday qilib tezda joylashtirish kerak?"
Bu erda qisqa va sodda.- Sizda CD tizimi (uzluksiz yetkazib berish) bo'lishi kerak - siz usiz yashay olmaysiz. Agar sizda bitta server bo'lsa, uni qo'lda joylashtirishingiz mumkin. Bizda bir yarim mingga yaqin serverlar va bir yarim ming tutqichlar bor, albatta - biz faqat joylashtirish uchun shu xonaning o'lchamidagi bo'limni ekishimiz mumkin.
- O'rnatish parallel bo'lishi kerak. Agar joylashtirishingiz ketma-ket bo'lsa, unda hamma narsa yomon. Bitta server oddiy, siz kun bo'yi bir yarim ming serverni joylashtirasiz.
- Shunga qaramay, tezlashtirish uchun bu endi kerak emas. Joylashtirish vaqtida loyiha odatda quriladi. Sizda veb-loyiha bor, front-end qismi bor (siz u yerda veb-paket qilasiz, npm-ni kompilyatsiya qilasiz - shunga o'xshash narsa) va bu jarayon, qoida tariqasida, qisqa muddatli - 5 daqiqa, lekin bu 5 daqiqa tanqidiy bo'ling. Shuning uchun, masalan, biz buni qilmaymiz: biz bu 5 daqiqani olib tashladik, artefaktlarni joylashtiramiz.
Artefakt nima? Artefakt - bu yig'ilgan qurilish bo'lib, unda barcha yig'ish qismlari allaqachon tugagan. Biz bu artefaktni artefakt omborida saqlaymiz. Bir vaqtlar biz ikkita bunday xotiradan foydalanganmiz - bu Nexus va hozir jFrog Artifactory).Biz dastlab "Nexus" dan foydalandik, chunki biz ushbu yondashuvni java ilovalarida qo'llashni boshladik (bu juda mos edi). Keyin ular PHPda yozilgan ba'zi ilovalarni u erga qo'yishdi; va "Nexus" endi mos emas edi va shuning uchun biz deyarli hamma narsani artifaktorlashtira oladigan jFrog Artefactory-ni tanladik. Biz hatto ushbu artefakt omborida serverlar uchun to'playdigan o'zimizning ikkilik paketlarimizni saqlaydigan nuqtaga keldik.
Portlovchi yukning o'sishi
Biz dasturiy ta'minot versiyasini o'zgartirish haqida gaplashdik. Bizda mavjud bo'lgan keyingi narsa - yukning portlovchi ortishi. Bu erda, ehtimol, yukning portlovchi o'sishi bilan to'g'ri emasligini nazarda tutyapman ...
Biz yangi tizimni yozdik - bu xizmatga yo'naltirilgan, moda, chiroyli, hamma joyda ishchilar, hamma joyda navbatlar, hamma joyda asinxronlik. Va bunday tizimlarda ma'lumotlar turli oqimlar orqali oqishi mumkin. Birinchi tranzaksiya uchun 1-chi, 3-chi, 10-chi ishchi, ikkinchi tranzaksiya uchun - 2, 4, 5-chi ishchilardan foydalanish mumkin. Va bugungi kunda, aytaylik, ertalab siz dastlabki uchta ishchidan foydalanadigan ma'lumotlar oqimiga egasiz va kechqurun u keskin o'zgaradi va hamma narsa qolgan uchta ishchidan foydalanadi.
Va bu erda ma'lum bo'lishicha, siz qandaydir tarzda ishchilarni ko'paytirishingiz kerak, siz qandaydir tarzda xizmatlaringizni ko'paytirishingiz kerak, lekin shu bilan birga resurslarning to'lib ketishining oldini olishingiz kerak.
Biz talablarimizni belgilab oldik. Bu talablar juda oddiy: Xizmatni ochish, parametrlashtirish bo'lishi - bunday kengaytiriladigan tizimlarni qurish uchun hamma narsa standartdir, bir nuqtadan tashqari - resurslarning amortizatsiyasi. Biz serverlar havoni isitish uchun resurslarni amortizatsiya qilishga tayyor emasligimizni aytdik. “Konsul” oldik, ishchilarimizni boshqaradigan “Nomad”ni oldik.Nega bu biz uchun muammo? Keling, biroz orqaga qaytaylik. Bizning orqamizda 70 ga yaqin to'lov tizimi mavjud. Ertalab trafik Sberbank orqali o'tadi, keyin Sberbank, masalan, tushib ketdi va biz uni boshqa to'lov tizimiga o'tkazamiz. Sberbankdan oldin bizda 100 nafar ishchi bor edi, shundan keyin biz boshqa to'lov tizimi uchun 100 nafar ishchini keskin oshirishimiz kerak. Va bularning barchasi inson ishtirokisiz sodir bo'lishi maqsadga muvofiqdir. Chunki inson ishtiroki bo'lsa, u erda 24/7 o'tirgan muhandis bo'lishi kerak, u faqat buni qilishi kerak, chunki 70 ta tizim sizning orqangizda turganda bunday nosozliklar muntazam ravishda sodir bo'ladi.
Shuning uchun biz ochiq IPga ega Nomad-ni ko'rib chiqdik va o'zimizning Scale-Nomad - ScaleNo-ni yozdik, u taxminan quyidagilarni bajaradi: u navbatning o'sishini kuzatadi va dinamikaga qarab ishchilar sonini kamaytiradi yoki oshiradi. navbatda. Buni amalga oshirganimizda, biz o'yladik: "Balki biz uni ochishimiz mumkinmi?" Keyin ular unga qarashdi - u ikki tiyin kabi oddiy edi.
Hozircha biz uni ochganimiz yo'q, lekin agar hisobotdan so'ng to'satdan sizga bunday narsa kerakligini tushunib, sizga kerak bo'lsa, mening kontaktlarim oxirgi slaydda - iltimos, menga yozing. Kamida 3-5 kishi bo'lsa homiylik qilamiz.
U qanday ishlaydi? Keling, ko'rib chiqaylik! Oldinga qarab: chap tomonda bizning monitoringimiz bo'lagi bor: bu bitta satr, tepada voqeani qayta ishlash vaqti, o'rtada tranzaktsiyalar soni, pastki qismida ishchilar soni.Agar qarasangiz, bu rasmda xatolik bor. Yuqori jadvalda 45 soniya ichida jadvallardan biri qulab tushdi - to'lov tizimlaridan biri ishlamay qoldi. Darhol 2 daqiqada trafik keltirildi va navbat ishchilar bo'lmagan boshqa to'lov tizimida o'sishni boshladi (biz resurslardan foydalanmadik - aksincha, biz resursni to'g'ri yo'q qildik). Biz isitishni xohlamadik - minimal son, taxminan 5-10 ishchi bor edi, lekin ular bardosh bera olmadilar.
Oxirgi grafikda "qo'ng'iz" ko'rsatilgan, bu shunchaki "Skaleno" bu miqdorni ikki baravar oshirganligini anglatadi. Va keyin, grafik biroz pasayganda, u uni biroz qisqartirdi - ishchilar soni avtomatik ravishda o'zgartirildi. Bu narsa shunday ishlaydi. Biz 2-band - "Sabablardan qanday tezda qutulish kerak" haqida gaplashdik.
Monitoring. Muammoni tezda qanday aniqlash mumkin?
Endi birinchi nuqta - "Muammoni qanday tezda aniqlash mumkin?" Monitoring! Biz ba'zi narsalarni tezda tushunishimiz kerak. Qanday narsalarni tezda tushunishimiz kerak?
Uch narsa!- Biz o'z resurslarimiz samaradorligini tezda tushunishimiz va tushunishimiz kerak.
- Biz nosozliklarni tezda tushunishimiz va bizga tashqi bo'lgan tizimlarning ishlashini kuzatishimiz kerak.
- Uchinchi nuqta - mantiqiy xatolarni aniqlash. Bu tizim siz uchun ishlayotganida, barcha ko'rsatkichlar bo'yicha hamma narsa normal, lekin biror narsa noto'g'ri bo'ladi.
Men sizga bu erda ajoyib narsani aytmayman. Men kapitan Obvious bo'laman. Biz bozorda nima borligini qidirdik. Bizda "qiziqarli hayvonot bog'i" bor. Hozir bizda shunday hayvonot bog'i mavjud:
Biz Zabbix-dan uskunani kuzatish, serverlarning asosiy ko'rsatkichlarini kuzatish uchun foydalanamiz. Ma'lumotlar bazalari uchun Okmeterdan foydalanamiz. Biz birinchi ikkitasiga mos kelmaydigan barcha boshqa ko'rsatkichlar uchun "Grafana" va "Prometey" dan foydalanamiz, ba'zilari "Grafana" va "Prometey", ba'zilari esa "Grafana" bilan "Influx" va Telegraf bilan.Bir yil oldin biz New Relic-dan foydalanmoqchi edik. Ajoyib narsa, u hamma narsani qila oladi. Ammo u hamma narsani qila olsa, u juda qimmat. Biz 1,5 ming server hajmiga etganimizda, sotuvchi bizga kelib: "Kelinglar, kelasi yil uchun shartnoma tuzamiz", dedi. Biz narxga qaradik va yo'q, biz buni qilmaymiz dedik. Endi biz New Relic-dan voz kechmoqdamiz, bizda New Relic monitoringi ostida 15 ga yaqin serverlar qoldi. Narx mutlaqo yirtqich bo'lib chiqdi.
Va biz o'zimiz amalga oshirgan bitta vosita bor - bu Debugger. Avvaliga biz uni "Bagger" deb atardik, lekin keyin bir ingliz tili o'qituvchisi o'tib ketdi, vahshiyona kuldi va uni "Debagger" deb o'zgartirdi. Bu nima? Bu, aslida, tizimning "qora qutisi" kabi har bir komponentda 15-30 soniya ichida komponentning umumiy ishlashi bo'yicha testlarni o'tkazadigan vositadir.
Misol uchun, agar tashqi sahifa (to'lov sahifasi) bo'lsa, u shunchaki uni ochadi va qanday ko'rinishi kerakligiga qaraydi. Agar bu qayta ishlanayotgan bo'lsa, u sinov "tranzaksiyasi" ni yuboradi va bu "tranzaksiya" kelishiga ishonch hosil qiladi. Agar bu to'lov tizimlari bilan bog'liq bo'lsa, biz shunga mos ravishda test so'rovini yuboramiz, bizda hamma narsa yaxshi ekanini ko'ramiz.
Monitoring uchun qanday ko'rsatkichlar muhim?
Biz asosan nimani kuzatamiz? Biz uchun qanday ko'rsatkichlar muhim?
- Jabhalarda javob vaqti / RPS juda muhim ko'rsatkichdir. U darhol sizga nimadir noto'g'ri deb javob beradi.
- Barcha navbatlarda qayta ishlangan xabarlar soni.
- Ishchilar soni.
- To'g'rilikning asosiy ko'rsatkichlari.
Oxirgi nuqta - "biznes", "biznes" ko'rsatkichi. Agar siz xuddi shu narsani kuzatmoqchi bo'lsangiz, siz uchun asosiy ko'rsatkichlar bo'lgan bir yoki ikkita ko'rsatkichni belgilashingiz kerak. Bizning ko'rsatkichimiz o'tkazish qobiliyatidir (bu muvaffaqiyatli tranzaktsiyalar sonining umumiy tranzaksiya oqimiga nisbati). Agar unda 5-10-15 daqiqa oralig'ida biror narsa o'zgarsa, demak, bizda muammolar bor (agar u tubdan o'zgarsa).
Bu biz uchun qanday ko'rinadi, bizning kengashlarimizdan biriga misol:
Chap tomonda 6 ta grafik mavjud, bu chiziqlarga ko'ra - ishchilar soni va navbatdagi xabarlar soni. O'ng tomonda - RPS, RTS. Quyida bir xil "biznes" ko'rsatkichi mavjud. Va "biznes" metrikasida biz ikkita o'rta grafikda biror narsa noto'g'ri ketganini darhol ko'rishimiz mumkin ... Bu bizning orqamizda turgan yana bir tizim tushib ketgan.Biz qilishimiz kerak bo'lgan ikkinchi narsa tashqi to'lov tizimlarining qulashini kuzatish edi. Bu erda biz OpenTracing-ni oldik - mexanizm, standart, taqsimlangan tizimlarni kuzatish imkonini beruvchi paradigma; va u biroz o'zgartirildi. Standart OpenTracing paradigmasi biz har bir alohida so'rov uchun iz yaratishimizni aytadi. Bizga bu kerak emas edi va biz uni xulosa, yig'ish iziga o'rab oldik. Biz orqamizdagi tizimlarning tezligini kuzatish imkonini beruvchi vositani yaratdik.
Grafik bizga to'lov tizimlaridan biri 3 soniyada javob bera boshlaganini ko'rsatadi - bizda muammolar mavjud. Bundan tashqari, bu narsa muammolar boshlanganda, 20-30 soniya oralig'ida reaksiyaga kirishadi.Va mavjud kuzatuv xatolarining uchinchi klassi mantiqiy monitoringdir.
Rostini aytsam, men bu slaydda nima chizishni bilmasdim, chunki biz bozorda uzoq vaqtdan beri o'zimizga mos keladigan narsani qidirgan edik. Biz hech narsa topmadik, shuning uchun buni o'zimiz qilishimiz kerak edi.
Mantiqiy monitoring deganda nimani tushunaman? Xo'sh, tasavvur qiling: siz o'zingizni tizimga aylantirasiz (masalan, Tinder kloni); siz buni qildingiz, ishga tushirdingiz. Muvaffaqiyatli menejer Vasya Pupkin uni telefoniga qo'ydi, u erda bir qizni ko'radi, uni yoqtiradi ... va shunga o'xshash narsa qizga bormaydi - xuddi shu biznes markazining qo'riqchisi Mixalichga o'xshaydi. Menejer pastga tushadi va keyin hayron bo'ladi: "Nega bu qo'riqchi Mixalich unga shunchalik yoqimli tabassum qiladi?"Bunday vaziyatlarda... Biz uchun bu holat biroz boshqacha eshitiladi, chunki (men yozgan edim) bu bilvosita moliyaviy yo'qotishlarga olib keladigan obro'ni yo'qotishdir. Bizning vaziyatimiz buning aksi: biz to'g'ridan-to'g'ri moliyaviy yo'qotishlarga duch kelishimiz mumkin - masalan, agar biz operatsiyani muvaffaqiyatli amalga oshirgan bo'lsak, lekin u muvaffaqiyatsiz bo'lsa (yoki aksincha). Men biznes ko'rsatkichlari yordamida vaqt o'tishi bilan muvaffaqiyatli bitimlar sonini kuzatuvchi o'z vositamni yozishim kerak edi. Bozorda hech narsa topilmadi! Aynan shu fikrni aytmoqchi edim. Bozorda bunday muammoni hal qiladigan hech narsa yo'q.
Bu muammoni qanday tezda aniqlash haqida edi.
Joylashtirish sabablarini qanday aniqlash mumkin
Biz hal qiladigan muammolarning uchinchi guruhi - bu muammoni aniqlaganimizdan so'ng, undan xalos bo'lganimizdan so'ng, rivojlanish sababini tushunish, sinovdan o'tkazish va bu haqda biror narsa qilish yaxshi bo'lar edi. Shunga ko'ra, biz tergov qilishimiz kerak, loglarni ko'tarishimiz kerak.
Agar biz jurnallar haqida gapiradigan bo'lsak (asosiy sabab - jurnallar), bizning jurnallarimizning asosiy qismi ELK Stack-da - deyarli hamma bir xil. Ba'zilar uchun bu ELKda bo'lmasligi mumkin, lekin agar siz loglarni gigabaytlarda yozsangiz, ertami-kechmi ELKga kelasiz. Biz ularni terabaytlarda yozamiz.
Bu yerda muammo bor. Biz uni tuzatdik, foydalanuvchi uchun xatoni tuzatdik, u erda nima borligini qazishni boshladik, Kibanaga chiqdik, u erda tranzaksiya identifikatorini kiritdik va shunga o'xshash oyoq kiyimini oldik (ko'p narsani ko'rsatadi). Va bu oyoq kiyimida mutlaqo hech narsa aniq emas. Nega? Ha, chunki qaysi qism qaysi ishchiga tegishli, qaysi qism qaysi komponentga tegishli ekanligi aniq emas. Va o'sha paytda biz kuzatish kerakligini angladik - men aytgan xuddi shu OpenTracing.Biz bir yil oldin bu haqda o'ylagan edik, e'tiborimizni bozorga qaratdik va u erda ikkita vosita bor edi - "Zipkin" va "Jaeger". “Jager” aslida shunday mafkuraviy voris, “Zipkin”ning mafkuraviy davomchisidir. Zipkinda hamma narsa yaxshi, bundan tashqari u qanday yig'ishni bilmaydi, u loglarni izga qanday kiritishni bilmaydi, faqat vaqt izi. Va "Jager" buni qo'llab-quvvatladi.
Biz "Jager" ni ko'rib chiqdik: siz ilovalarni asboblashtira olasiz, siz Api-da yozishingiz mumkin (o'sha paytda PHP uchun Api standarti tasdiqlanmagan edi - bu bir yil oldin edi, lekin hozir u allaqachon tasdiqlangan), lekin u erda mutlaqo mijoz emas edi. "Yaxshi", deb o'yladik va o'z mijozimizni yozdik. Biz nima oldik? Bu taxminan shunday ko'rinadi:
Jaeger-da har bir xabar uchun oraliqlar yaratiladi. Ya'ni, foydalanuvchi tizimni ochganda, u har bir kiruvchi so'rov uchun bir yoki ikkita blokni ko'radi (1-2-3 - foydalanuvchidan kiruvchi so'rovlar soni, bloklar soni). Foydalanuvchilar uchun qulaylik yaratish uchun biz jurnallar va vaqt izlariga teglar qo'shdik. Shunga ko'ra, xatolik yuz bergan taqdirda, bizning ilovamiz jurnalni tegishli Xato yorlig'i bilan belgilaydi. Siz Xato yorlig'i bo'yicha filtrlashingiz mumkin va faqat xato bilan ushbu blokni o'z ichiga olgan oraliqlar ko'rsatiladi. Agar biz oraliqni kengaytirsak, shunday ko'rinadi:
Spanning ichida bir qator izlar mavjud. Bunday holda, bu uchta sinov izi va uchinchi iz bizga xatolik yuz berganligini bildiradi. Shu bilan birga, bu erda biz vaqt izini ko'ramiz: bizda yuqorida vaqt shkalasi bor va biz u yoki bu jurnalning qaysi vaqt oralig'ida qayd etilganini ko'ramiz.Shunga ko'ra, ishlar biz uchun yaxshi o'tdi. Biz o'z kengaytmamizni yozdik va biz uni ochdik. Agar siz tracing bilan ishlamoqchi bo'lsangiz, PHP da "Jager" bilan ishlamoqchi bo'lsangiz, bizning kengaytmamiz mavjud, ular aytganidek, foydalanishga xush kelibsiz:
Bizda bu kengaytma bor - bu OpenTracing Api mijozi bo'lib, u php-kengaytma sifatida yaratilgan, ya'ni uni yig'ish va tizimga o'rnatish kerak bo'ladi. Bir yil oldin hech qanday farq yo'q edi. Endi komponentlarga o'xshash boshqa mijozlar mavjud. Bu sizga bog'liq: yo kompozitor bilan tarkibiy qismlarni chiqarib olasiz yoki o'zingiz uchun kengaytmadan foydalanasiz.Korporativ standartlar
Biz uchta amr haqida gaplashdik. To'rtinchi amr yondashuvlarni standartlashtirishdir. Bu nima haqida? Bu haqida:
Nima uchun bu erda "korporativ" so'zi bor? Biz katta yoki byurokratik kompaniya ekanligimiz uchun emas, yo'q! Men bu yerda “korporativ” so‘zini har bir kompaniya, har bir mahsulot o‘z standartlariga ega bo‘lishi kerak, shu jumladan sizda ham ishlatmoqchi bo‘ldim. Bizda qanday standartlar bor?
- Bizda joylashtirish qoidalari bor. Biz usiz hech qaerga harakat qilmayapmiz, qila olmaymiz. Biz haftasiga taxminan 60 marta joylashtiramiz, ya'ni biz deyarli doimiy ravishda joylashtiramiz. Shu bilan birga, bizda, masalan, joylashtirish qoidalarida juma kuni joylashtirish taqiqlangan - printsipial jihatdan biz joylashtirmaymiz.
- Biz hujjatlarni talab qilamiz. Birorta ham yangi komponent ishlab chiqarishga kiritilmaydi, agar u uchun hujjatlar bo'lmasa, hatto u bizning RnD mutaxassislarimiz qalami ostida tug'ilgan bo'lsa ham. Biz ulardan joylashtirish bo'yicha ko'rsatmalarni, monitoring xaritasini va ushbu komponent qanday ishlashi, uni qanday bartaraf etish haqida taxminiy tavsifni (dasturchilar yozishi mumkin) talab qilamiz.
- Biz muammoning sababini emas, balki muammoni hal qilamiz - men aytganlar. Biz uchun foydalanuvchini muammolardan himoya qilish muhim.
- Bizda ruxsatnomalar bor. Misol uchun, agar biz ikki daqiqa ichida trafikning 2 foizini yo'qotgan bo'lsak, biz uni to'xtatib turish deb hisoblamaymiz. Bu, asosan, bizning statistikamizga kiritilmagan. Agar u foizlarda yoki vaqtinchalik ko'proq bo'lsa, biz allaqachon hisoblaymiz.
- Va biz har doim postmortems yozamiz. Biz bilan nima sodir bo'lishidan qat'i nazar, kimdir ishlab chiqarishda o'zini g'ayritabiiy tutgan har qanday vaziyat o'limdan keyin o'z aksini topadi. Postmortem - bu sizga nima bo'lganini, batafsil vaqtni, uni tuzatish uchun nima qilganingizni va (bu majburiy blokdir!) kelajakda bu sodir bo'lishining oldini olish uchun nima qilishingizni yozadigan hujjat. Bu majburiy va keyingi tahlil uchun zarurdir.
To'xtash vaqti nima deb hisoblanadi?
Bularning barchasi nimaga olib keldi?Bu (bizda barqarorlik bilan bog'liq ma'lum muammolar bor edi, bu mijozlarga ham, bizga ham mos kelmadi) so'nggi 6 oy ichida barqarorlik ko'rsatkichimiz 99,97 ni tashkil qildi. Aytishimiz mumkinki, bu juda ko'p emas. Ha, bizda intilish kerak bo'lgan narsa bor. Ushbu ko'rsatkichning qariyb yarmi barqarorligi, go'yo biznikida emas, balki bizning oldimizda turgan va xizmat sifatida ishlatiladigan veb-ilovaning xavfsizlik devori, ammo mijozlar bunga ahamiyat bermaydilar.
Biz kechasi uxlashni o'rgandik. Nihoyat! Olti oy oldin biz qila olmadik. Natijalar bilan ushbu eslatmada men bitta eslatma qilmoqchiman. Kecha tunda yadroviy reaktorni boshqarish tizimi haqida ajoyib hisobot chiqdi. Agar ushbu tizimni yozgan odamlar meni eshitsa, iltimos, "2% ishlamay qolgan vaqt emas" haqida aytganlarimni unuting. Siz uchun 2% - ikki daqiqa bo'lsa ham, ishlamay qolish vaqti!
Ana xolos! Sizning savollaringiz.
Balanschilar va ma'lumotlar bazasi migratsiyasi haqida
Tomoshabinlar savoli (keyingi o'rinlarda – B): – Xayrli kech. Bunday admin hisoboti uchun katta rahmat! Balanschilaringiz haqida qisqacha savol. Sizda WAF borligini aytdingiz, ya'ni men tushunganimdek, siz qandaydir tashqi balanslashtirgichdan foydalanasiz ...
EK: - Yo'q, biz o'z xizmatlarimizdan balanslashtiruvchi sifatida foydalanamiz. Bunday holda, WAF biz uchun faqat DDoS himoya vositasidir.
Savol: – Balanschilar haqida bir necha so‘z ayta olasizmi?
EK: – Yuqorida aytganimdek, bu ochiq serverlar guruhi. Endi bizda faqat javob beradigan 5 ta zaxira guruhimiz bor... ya'ni faqat ochiq rejimda ishlaydigan server, u faqat trafikni proksi qiladi. Shunga ko'ra, biz qancha ushlab turganimizni tushunish uchun: endi bizda bir necha yuz megabitlik muntazam trafik oqimi mavjud. Ular bardosh beradilar, o'zlarini yaxshi his qiladilar, hatto o'zlarini zo'rlashtirmaydilar.
Savol: - Shuningdek, oddiy savol. Bu yerda Moviy/Yashil joylashtirish. Masalan, ma'lumotlar bazasini ko'chirish bilan nima qilasiz?
EK: - Yaxshi savol! Qarang, Moviy/Yashil joylashtirishda bizda har bir qator uchun alohida navbatlar mavjud. Ya'ni, agar biz ishchidan ishchiga uzatiladigan voqea navbatlari haqida gapiradigan bo'lsak, ko'k chiziq va yashil chiziq uchun alohida navbatlar mavjud. Agar biz ma'lumotlar bazasining o'zi haqida gapiradigan bo'lsak, unda biz uni imkon qadar ataylab toraytirdik, hamma narsani amalda navbatga o'tkazdik; ma'lumotlar bazasida biz faqat tranzaktsiyalar to'plamini saqlaymiz. Va bizning tranzaksiya stekimiz barcha qatorlar uchun bir xil. Ushbu kontekstda ma'lumotlar bazasi bilan: biz uni ko'k va yashil rangga ajratmaymiz, chunki kodning ikkala versiyasi ham tranzaktsiya bilan nima sodir bo'layotganini bilishi kerak.
Do'stlar, menda sizlarni rag'batlantirish uchun kichik sovg'a bor - kitob. Va menga eng yaxshi savol uchun mukofot berilishi kerak.
Savol: - Salom. Hisobot uchun rahmat. Savol shu. Siz to'lovlarni kuzatib borasiz, siz muloqot qilayotgan xizmatlarni kuzatib borasiz... Lekin qanday qilib odam sizning to'lov sahifangizga kirib, to'lovni amalga oshirgan va loyiha unga pul kiritganini qanday kuzatasiz? Ya'ni, marchant mavjud va sizning qayta qo'ng'iroqingizni qabul qilganligini qanday nazorat qilasiz?
EK: – Bu holda biz uchun “Savdogar” to‘lov tizimi bilan bir xil tashqi xizmatdir. Biz savdogarning javob tezligini kuzatamiz.
Ma'lumotlar bazasini shifrlash haqida
Savol: - Salom. Menda bir oz bog'liq savol bor. Sizda PCI DSS sezgir ma'lumotlaringiz bor. PAN-larni o'tkazishingiz kerak bo'lgan navbatda qanday saqlashingizni bilmoqchi edim? Har qanday shifrlashdan foydalanasizmi? Va bu ikkinchi savolga olib keladi: PCI DSS ga ko'ra, ma'lumotlar bazasini o'zgartirishlar (administratorlarni ishdan bo'shatish va h.k.) bo'lsa, vaqti-vaqti bilan qayta shifrlash kerak - bu holda kirish imkoniyati bilan nima sodir bo'ladi?
EK: - Ajoyib savol! Birinchidan, biz PAN-larni navbatda saqlamaymiz. Bizda PAN-ni har qanday joyda aniq shaklda saqlashga haqqimiz yo'q, shuning uchun biz maxsus xizmatdan foydalanamiz (biz uni "Kademon" deb ataymiz) - bu faqat bitta narsani bajaradigan xizmat: u kirish sifatida xabar oladi va yuboradi. shifrlangan xabarni chiqaradi. Va biz hamma narsani ushbu shifrlangan xabar bilan saqlaymiz. Shunga ko'ra, bizning kalit uzunligimiz kilobaytdan kam, shuning uchun bu jiddiy va ishonchli.Savol: – Hozir sizga 2 kilobayt kerakmi?
EK: – Kechagina 256 edi shekilli... Xo‘sh, yana qayerda?!
Shunga ko'ra, bu birinchi. Va ikkinchidan, mavjud yechim qayta shifrlash protsedurasini qo'llab-quvvatlaydi - ikkita juft "keks" (kalitlar) mavjud bo'lib, ular shifrlaydigan "pastki"larni beradi (kalit - kalitlar, dek - shifrlovchi kalitlarning hosilalari). . Va agar protsedura boshlangan bo'lsa (bu muntazam ravishda, 3 oydan ± bir necha oygacha sodir bo'ladi), biz yangi "pirojnoe" juftligini yuklab olamiz va biz ma'lumotlarni qayta shifrlaymiz. Bizda barcha ma'lumotlarni o'chirib tashlaydigan va ularni yangi usulda shifrlaydigan alohida xizmatlar mavjud; Ma'lumotlar shifrlangan kalitning identifikatori yonida saqlanadi. Shunga ko'ra, biz ma'lumotlarni yangi kalitlar bilan shifrlashimiz bilanoq, biz eski kalitni o'chirib tashlaymiz.
Ba'zan to'lovlarni qo'lda qilish kerak ...
Savol: - Ya'ni, agar biron bir operatsiya uchun pul qaytarilgan bo'lsa, siz uni eski kalit bilan hal qila olasizmi?
EK: - Ha.
Savol: – Keyin yana bir kichik savol. Qandaydir nosozlik, yiqilish yoki voqea sodir bo'lganda, tranzaktsiyani qo'lda bajarish kerak. Bunday holat mavjud.
EK: - Ha, ba'zan.
Savol: - Bu ma'lumotlarni qayerdan olasiz? Yoki bu saqlash joyiga o'zingiz borasizmi?
EK: - Yo'q, albatta, bizda qo'llab-quvvatlash interfeysini o'z ichiga olgan qandaydir bek-ofis tizimi mavjud. Agar biz tranzaktsiya qanday holatda ekanligini bilmasak (masalan, to'lov tizimi kutish vaqti bilan javob bermaguncha), biz apriori bilmaymiz, ya'ni biz yakuniy holatni faqat to'liq ishonch bilan belgilaymiz. Bunday holda, biz operatsiyani qo'lda qayta ishlash uchun maxsus holatga beramiz. Ertalab, ertasi kuni, qo'llab-quvvatlash to'lov tizimida bunday va shunga o'xshash operatsiyalar qolishi haqida ma'lumot olishi bilanoq, ular ushbu interfeysda ularni qo'lda qayta ishlaydilar.
Savol: – Bir-ikkita savolim bor. Ulardan biri PCI DSS zonasining davomi: ularning sxemasini qanday qayd qilish kerak? Bu savol, chunki ishlab chiquvchi jurnallarga biron bir narsani qo'yishi mumkin edi! Ikkinchi savol: tuzatishlarni qanday ishlab chiqarasiz? Ma'lumotlar bazasidagi tutqichlar bitta variant, lekin bepul tuzatishlar bo'lishi mumkin - u erda qanday tartib bor? Va uchinchi savol, ehtimol, RTO, RPO bilan bog'liq. Sizning mavjudligingiz 99,97, deyarli to'rtta to'qqizta edi, lekin men tushunganimdek, sizda ikkinchi ma'lumotlar markazi, uchinchi ma'lumotlar markazi va beshinchi ma'lumotlar markazi bor ... Ularni qanday qilib sinxronlashtirasiz, ularni takrorlaysiz va boshqa hamma narsa?EK: - Birinchisidan boshlaylik. Birinchi savol jurnallar haqida edi? Jurnallarni yozganimizda, bizda barcha nozik ma'lumotlarni maskalaydigan qatlam mavjud. U niqobga va qo'shimcha maydonlarga qaraydi. Shunga ko'ra, bizning jurnallarimiz allaqachon maskalangan ma'lumotlar va PCI DSS sxemasi bilan chiqadi. Bu test bo'limiga yuklangan muntazam vazifalardan biridir. Ulardan har bir topshiriqni, shu jumladan ular yozgan jurnallarni tekshirish talab qilinadi va bu ishlab chiquvchi biror narsa yozmaganligini nazorat qilish uchun kodni ko'rib chiqish paytidagi odatiy vazifalardan biridir. Buning keyingi tekshiruvlari axborot xavfsizligi bo'limi tomonidan muntazam ravishda haftada bir marta amalga oshiriladi: oxirgi kun uchun jurnallar tanlab olinadi va ular hamma narsani tekshirish uchun test serverlaridan maxsus skaner-analizator orqali ishga tushiriladi.
Issiq tuzatishlar haqida. Bu bizning joylashtirish qoidalarimizga kiritilgan. Bizda tuzatishlar haqida alohida band bor. Biz o'ylaymizki, kerak bo'lganda tuzatishlarni kechayu kunduz o'rnatamiz. Versiya yig'ilgandan so'ng, u ishga tushirilishi bilanoq, bizda artefakt paydo bo'lishi bilan bizda qo'llab-quvvatlash xizmatidan qo'ng'iroq bo'yicha navbatchi tizim ma'muri bor va u kerak bo'lganda uni joylashtiradi.Taxminan "to'rt to'qqiz". Bizda mavjud bo'lgan ko'rsatkich haqiqatan ham erishildi va biz boshqa ma'lumotlar markazida bunga intildik. Endi bizda ikkinchi ma'lumotlar markazi bor va biz ular o'rtasida yo'nalishni boshlaymiz va ma'lumotlar markazlarini o'zaro replikatsiya qilish masalasi haqiqatdan ham ahamiyatsiz savol. Biz buni bir vaqtning o'zida turli xil vositalar yordamida hal qilishga harakat qildik: biz bir xil "Tarantula" dan foydalanishga harakat qildik - bu biz uchun ish bermadi, men sizga darhol aytaman. Shuning uchun biz "sens" ga qo'lda buyurtma berishni tugatdik. Aslida, bizning tizimimizdagi har bir dastur ma'lumotlar markazlari o'rtasida asinxron ravishda kerakli "o'zgartirish - bajarildi" sinxronizatsiyasini amalga oshiradi.
Savol: - Agar ikkinchisini olgan bo'lsangiz, nega uchinchisini olmadingiz? Chunki hali hech kimning miyasi yo'q ...
EK: - Ammo bizda Split Brain yo'q. Har bir ilova multimaster tomonidan boshqarilganligi sababli, so'rov qaysi markazga kelganligi biz uchun muhim emas. Agar bizning ma'lumotlar markazlarimizdan biri ishlamay qolsa (biz bunga tayanamiz) va foydalanuvchi so'rovi o'rtasida ikkinchi ma'lumot markaziga o'tsa, biz ushbu foydalanuvchini yo'qotishga tayyormiz; lekin bu birliklar, mutlaq birliklar bo'ladi.
Savol: - Hayrli kech. Hisobot uchun rahmat. Siz ishlab chiqarishda ba'zi sinov operatsiyalarini amalga oshiradigan tuzatuvchi haqida gapirdingiz. Ammo test operatsiyalari haqida bizga xabar bering! U qanchalik chuqurlashadi?
EK: - U butun komponentning to'liq tsiklidan o'tadi. Komponent uchun sinov bitimi va ishlab chiqarish operatsiyasi o'rtasida farq yo'q. Ammo mantiqiy nuqtai nazardan, bu tizimdagi alohida loyiha bo'lib, unda faqat sinov operatsiyalari amalga oshiriladi.
Savol: - Uni qayerdan kesib tashlaysiz? Mana, Core yuborildi...
EK: – Biz bu holatda test tranzaksiyalari uchun “Kor” dan orqadamiz... Bizda marshrutlash kabi narsa bor: “Kor” qaysi to‘lov tizimiga jo‘natish kerakligini biladi – biz soxta to‘lov tizimiga jo‘natamiz, u shunchaki http signalini beradi va ana xolos.
Savol: - Iltimos, ayting-chi, arizangiz bitta katta monolitda yozilganmi yoki uni ba'zi xizmatlarga yoki hatto mikroservislarga ajratdingizmi?
EK: - Bizda monolit yo'q, albatta, bizda xizmatga yo'naltirilgan dastur mavjud. Bizning xizmatimiz monolitlardan iborat deb hazil qilamiz - ular haqiqatan ham juda katta. Buni mikroservislar deb atash qiyin, ammo bular taqsimlangan mashinalar ishchilari ishlaydigan xizmatlardir.
Agar serverdagi xizmat buzilgan bo'lsa...
Savol: – Unda keyingi savolim bor. Agar u monolit bo'lsa ham, siz hali ham sizda bunday tezkor serverlarning ko'pchiligi borligini aytdingiz, ularning barchasi asosan ma'lumotlarni qayta ishlaydi va savol quyidagicha: "Instant serverlar yoki dasturdan biri buzilgan taqdirda, har qanday alohida havola. , ularda qandaydir kirish nazorati bormi? Ulardan qaysi biri nima qila oladi? Qanday ma'lumot olish uchun kimga murojaat qilishim kerak?
EK: - Ha, albatta. Xavfsizlik talablari juda jiddiy. Birinchidan, bizda ochiq ma'lumotlar harakati mavjud va portlar faqat trafik harakatini oldindan taxmin qiladigan portlardir. Agar komponent ma'lumotlar bazasi bilan (masalan, Muskul bilan) 5-4-3-2 orqali aloqa qilsa, unga faqat 5-4-3-2 ochiq bo'ladi va boshqa portlar va boshqa trafik yo'nalishlari mavjud bo'lmaydi. Bundan tashqari, bizning ishlab chiqarishimizda 10 ga yaqin turli xil xavfsizlik halqalari mavjudligini tushunishingiz kerak. Va agar ilova qandaydir tarzda buzilgan bo'lsa ham, Xudo saqlasin, tajovuzkor server boshqaruv konsoliga kira olmaydi, chunki bu boshqa tarmoq xavfsizlik zonasi.Savol: – Shu nuqtai nazardan, men uchun qiziqroq narsa shundaki, sizda xizmatlar bilan muayyan shartnomalaringiz bor – ular nima qila oladi, qanday “harakatlari” orqali ular bir-birlari bilan bog‘lanishlari mumkin... Oddiy oqimda esa ba’zi bir maxsus xizmatlar ba’zilarini so‘raydi. qator, ikkinchisida "harakatlar" ro'yxati. Ular oddiy vaziyatda boshqalarga murojaat qilmaydiganga o'xshaydi va ular boshqa mas'uliyat sohalariga ega. Agar ulardan biri buzilgan bo'lsa, u o'sha xizmatning "harakatlarini" buzishi mumkinmi?..
EK: - Tushunaman. Agar normal holatda boshqa server bilan aloqaga umuman ruxsat berilsa, ha. SLA shartnomasiga ko'ra, biz sizga faqat birinchi 3 ta "harakat"ga ruxsat berilganligini va 4 ta "harakat"ga ruxsat berilmaganligini kuzatmaymiz. Bu, ehtimol, biz uchun ortiqcha, chunki bizda allaqachon sxemalar uchun 4 darajali himoya tizimi mavjud. Biz o'zimizni ichki qism darajasida emas, balki konturlar bilan himoya qilishni afzal ko'ramiz.
Visa, MasterCard va Sberbank qanday ishlaydi
Savol: – Men foydalanuvchini bir maʼlumot markazidan boshqasiga oʻtkazish haqidagi fikrga aniqlik kiritmoqchiman. Men bilishimcha, Visa va MasterCard 8583 ikkilik sinxron protokoli yordamida ishlaydi va u erda aralashmalar mavjud. Va men bilmoqchi edim, endi biz almashtirishni nazarda tutamiz - bu to'g'ridan-to'g'ri "Visa" va "MasterCard" yoki to'lov tizimlaridan oldin, ishlov berishdan oldinmi?
EK: - Bu aralashmalardan oldin. Bizning aralashmalarimiz bir xil ma'lumotlar markazida joylashgan.
Savol: - Qo'pol qilib aytganda, sizda bitta ulanish nuqtasi bormi?
EK: – “Visa” va “MasterCard” - ha. Shunchaki, Visa va MasterCard, masalan, aralashmalarning ikkinchi juftligini olish uchun alohida shartnomalar tuzish uchun infratuzilmaga jiddiy investitsiyalarni talab qiladi. Ular bitta maʼlumot markazida saqlangan, lekin agar, Xudo asrasin, Visa va MasterCard’ga ulanish uchun mikslar mavjud boʻlgan maʼlumotlar markazimiz oʻlib qolsa, biz Visa va MasterCard bilan aloqamiz yoʻqoladi...
Savol: - Qanday qilib ularni bron qilish mumkin? Visa printsipial jihatdan faqat bitta ulanishga ruxsat berishini bilaman!
EK: – Uskunalarni o‘zlari yetkazib beradi. Har holda, biz ichkarida to'liq ortiqcha bo'lgan uskunani oldik.
Savol: – Demak, stend ularning Connects Orange-danmi?..
EK: - Ha.
Savol: - Ammo bu holat haqida nima deyish mumkin: agar sizning ma'lumotlar markazingiz yo'qolsa, undan qanday foydalanishni davom ettirishingiz mumkin? Yoki tirbandlik to'xtab qoladimi?
EK: - Yo'q. Bunday holda, biz shunchaki trafikni boshqa kanalga o'tkazamiz, bu, tabiiyki, biz uchun qimmatroq va mijozlarimiz uchun qimmatroq bo'ladi. Ammo trafik bizning Visa, MasterCard-ga to'g'ridan-to'g'ri ulanishimiz orqali emas, balki shartli Sberbank orqali (juda abartılı) o'tadi.
Agar Sberbank xodimlarini xafa qilgan bo'lsam, kechirim so'rayman. Ammo bizning statistik ma'lumotlarimizga ko'ra, Rossiya banklari orasida Sberbank ko'pincha tushadi. Sberbankda biror narsa yiqilmasdan bir oy o'tmaydi.
Ba'zi reklamalar 🙂
Biz bilan qolganingiz uchun tashakkur. Bizning maqolalarimiz sizga yoqdimi? Ko'proq qiziqarli tarkibni ko'rishni xohlaysizmi? Buyurtma berish yoki do'stlaringizga tavsiya qilish orqali bizni qo'llab-quvvatlang, , Siz uchun biz tomonidan ixtiro qilingan boshlang'ich darajadagi serverlarning noyob analogi: (RAID1 va RAID10, 24 tagacha yadro va 40 Gb gacha DDR4 bilan mavjud).
Amsterdamdagi Equinix Tier IV ma'lumotlar markazida Dell R730xd 2 baravar arzonmi? Faqat shu yerda Gollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! Haqida o'qing
Manba: www.habr.com