Bugungi kunda Bitrix24 xizmatida yuzlab gigabitlik trafik yo'q va u katta serverlar parkiga ega emas (garchi, albatta, mavjudlari juda kam). Ammo ko'plab mijozlar uchun bu kompaniyada ishlash uchun asosiy vosita bo'lib, u haqiqiy biznes uchun muhim dastur hisoblanadi. Shuning uchun, yiqilishning iloji yo'q. Agar avariya sodir bo'lgan bo'lsa-chi, lekin xizmat shu qadar tez "tiklansa", hech kim hech narsani sezmagan bo'lsa? Va qanday qilib ish sifatini va mijozlar sonini yo'qotmasdan o'zgartirishni amalga oshirish mumkin? Bitrix24 bulutli xizmatlar direktori Aleksandr Demidov bizning blogimiz uchun mahsulot mavjud bo'lgan 7 yil davomida bron qilish tizimi qanday rivojlangani haqida gapirdi.
“Biz Bitrix24 ni SaaS sifatida 7 yil oldin ishga tushirgan edik. Asosiy qiyinchilik, ehtimol, quyidagilar edi: u SaaS sifatida ommaga taqdim etilishidan oldin, bu mahsulot oddiygina qutidagi yechim formatida mavjud edi. Mijozlar uni bizdan sotib oldilar, o'z serverlarida joylashtirdilar, korporativ portalni o'rnatdilar - bu xodimlar bilan muloqot qilish, fayllarni saqlash, vazifalarni boshqarish, CRM uchun umumiy yechim - barchasi. Va 2012 yilga kelib, biz uni SaaS sifatida ishga tushirishga qaror qildik, uni o'zimiz boshqarib, xatolarga chidamlilik va ishonchlilikni ta'minlaymiz. Yo‘l davomida biz tajriba orttirdik, chunki u paytgacha bizda bu yo‘q edi – biz faqat dasturiy ta’minot ishlab chiqaruvchilar edik, xizmat ko‘rsatuvchi provayder emas edik.
Xizmatni ishga tushirganda, biz eng muhimi, nosozliklarga chidamliligi, ishonchliligi va xizmatning doimiy mavjudligini ta'minlash ekanligini tushundik, chunki agar sizda oddiy oddiy veb-sayt, masalan, do'kon bo'lsa va u sizga tushadi va u erda o'tiradi. bir soat, faqat siz azob chekasiz, buyurtmalarni yo'qotasiz, mijozlarni yo'qotasiz, lekin sizning mijozingiz uchun bu uning uchun juda muhim emas. U xafa bo'ldi, albatta, lekin u borib, uni boshqa saytdan sotib oldi. Va agar bu kompaniya ichidagi barcha ishlar, aloqalar, qarorlar bog'langan dastur bo'lsa, unda eng muhimi, foydalanuvchilarning ishonchini qozonish, ya'ni ularni tushkunlikka tushirmaslik va yiqilib tushmaslikdir. Chunki ichidagi biror narsa ishlamasa, barcha ishlar to'xtab qolishi mumkin.
Bitrix.24 SaaS sifatida
Biz birinchi prototipni ommaviy ishga tushirishdan bir yil oldin, 2011 yilda yig'dik. Biz uni taxminan bir hafta ichida yig'dik, ko'rib chiqdik, aylantirdik - u hatto ishlayotgan edi. Ya'ni formaga kirib, u yerda portal nomini kiritishingiz mumkin, yangi portal ochiladi va foydalanuvchi bazasi yaratiladi. Biz uni ko'rib chiqdik, mahsulotni printsipial jihatdan baholadik, uni bekor qildik va butun yil davomida uni takomillashtirishni davom ettirdik. Chunki oldimizda katta vazifa bor edi: biz ikki xil kod bazasini yaratishni xohlamadik, biz alohida paketlangan mahsulotni, alohida bulutli echimlarni qo'llab-quvvatlashni xohlamadik - barchasini bitta kod ichida qilishni xohladik.
O'sha paytdagi odatiy veb-ilova bitta server edi, unda ba'zi bir PHP kodi ishlaydi, MySQL ma'lumotlar bazasi, fayllar yuklanadi, hujjatlar, rasmlar yuklash papkasiga joylashtiriladi - barchasi ishlaydi. Afsuski, buning yordamida tanqidiy barqaror veb-xizmatni ishga tushirish mumkin emas. U erda taqsimlangan kesh qo'llab-quvvatlanmaydi, ma'lumotlar bazasi replikatsiyasi qo'llab-quvvatlanmaydi.
Biz talablarni shakllantirdik: bu turli joylarda joylashish, replikatsiyani qo'llab-quvvatlash va ideal holda turli geografik taqsimlangan ma'lumotlar markazlarida joylashish qobiliyatidir. Mahsulot mantig'ini va, aslida, ma'lumotlarni saqlashni ajrating. Yuklash bo'yicha dinamik ravishda o'lchov qila olish va statikaga umuman toqat qilish. Bu mulohazalardan, aslida, mahsulotga qo'yiladigan talablar paydo bo'ldi, biz ularni yil davomida aniqladik. Shu vaqt ichida birlashtirilgan platformada - qutili echimlar uchun, o'z xizmatimiz uchun - biz kerakli narsalarni qo'llab-quvvatladik. MySQL replikatsiyasini mahsulotning o'zi darajasida qo'llab-quvvatlash: ya'ni kodni yozgan ishlab chiquvchi o'z so'rovlari qanday taqsimlanishi haqida o'ylamaydi, u bizning api-dan foydalanadi va biz masterlar o'rtasida yozish va o'qish so'rovlarini qanday qilib to'g'ri taqsimlashni bilamiz. va qullar.
Biz turli xil bulutli ob'ektlarni saqlash uchun mahsulot darajasida qo'llab-quvvatladik: google xotirasi, amazon s3, shuningdek, ochiq stack swiftni qo'llab-quvvatlash. Shuning uchun, bu xizmat sifatida biz uchun ham, paketli yechim bilan ishlaydigan ishlab chiquvchilar uchun ham qulay edi: agar ular bizning API-dan ish uchun foydalansalar, fayl oxir-oqibat qayerda, fayl tizimida yoki mahalliy sifatida saqlanishi haqida o'ylamaydilar. ob'ekt fayl xotirasida.
Natijada, biz darhol butun ma'lumotlar markazi darajasida zaxiralashga qaror qildik. 2012-yilda biz butunlay Amazon AWS’da ishga tushirdik, chunki bizda bu platformada tajriba bor edi – o‘z veb-saytimiz u yerda joylashgan edi. Bizni har bir mintaqada Amazonda bir nechta mavjudlik zonalari borligi qiziqtirdi - aslida (ularning terminologiyasida) bir-biridan ko'proq yoki kamroq mustaqil bo'lgan va bizga butun ma'lumotlar markazi darajasida zaxiralash imkonini beradigan bir nechta ma'lumotlar markazlari: agar u to'satdan ishlamay qolsa, ma'lumotlar bazalari master-master tomonidan takrorlanadi, veb-ilova serverlari zaxiralanadi va statik ma'lumotlar s3 ob'ekt xotirasiga ko'chiriladi. Yuk muvozanatlangan - o'sha paytda Amazon elb tomonidan, lekin birozdan keyin biz o'z yuk balanslagichlariga keldik, chunki bizga murakkabroq mantiq kerak edi.
Ular xohlagan narsaga erishdilar ...
Biz ta'minlamoqchi bo'lgan barcha asosiy narsalar - serverlarning o'zlarining nosozliklarga chidamliligi, veb-ilovalar, ma'lumotlar bazalari - hammasi yaxshi ishladi. Eng oddiy stsenariy: agar bizning veb-ilovalarimizdan biri muvaffaqiyatsiz bo'lsa, unda hamma narsa oddiy - ular balansdan o'chiriladi.
Balanslashtiruvchi (o'sha paytda bu Amazonning dirseksi edi) ishdan chiqqan mashinalarni nosog'lom deb belgiladi va ulardagi yuk taqsimotini o'chirib qo'ydi. Amazon autoscaling ishladi: yuk ko'payganda, avtomatik o'lchov guruhiga yangi mashinalar qo'shildi, yuk yangi mashinalarga taqsimlandi - hammasi yaxshi edi. Balanslashtiruvchilarimiz bilan mantiq taxminan bir xil: agar dastur serverida biror narsa yuz bersa, biz undan so'rovlarni olib tashlaymiz, bu mashinalarni tashlaymiz, yangilarini ishga tushiramiz va ishlashni davom ettiramiz. Sxema yillar davomida biroz o'zgardi, lekin ishlashda davom etmoqda: bu oddiy, tushunarli va u bilan hech qanday qiyinchiliklar yo'q.
Biz butun dunyo bo'ylab ishlaymiz, mijozlarning yuklanish cho'qqilari butunlay boshqacha va do'stona tarzda biz tizimimizning istalgan tarkibiy qismlarida istalgan vaqtda - mijozlar sezmagan holda ma'lum xizmat ko'rsatish ishlarini bajarishimiz mumkin. Shuning uchun bizda ma'lumotlar bazasini ishlashdan o'chirish, yukni ikkinchi ma'lumotlar markaziga qayta taqsimlash imkoniyati mavjud.
Hammasi qanday ishlaydi? — Biz trafikni ishlaydigan ma'lumotlar markaziga o'tkazamiz - agar ma'lumotlar markazida baxtsiz hodisa ro'y bersa, to'liq, agar bu bizning bitta ma'lumotlar bazasi bilan rejalashtirilgan ishimiz bo'lsa, biz ushbu mijozlarga xizmat ko'rsatadigan trafikning bir qismini to'xtatib, ikkinchi ma'lumot markaziga o'tkazamiz. uning replikatsiyasi. Agar veb-ilovalar uchun yangi mashinalar kerak bo'lsa, chunki ikkinchi ma'lumotlar markaziga yuk ko'paygan bo'lsa, ular avtomatik ravishda ishga tushadi. Biz ishni tugatamiz, replikatsiya tiklanadi va biz butun yukni qaytarib beramiz. Agar biz ikkinchi shaharda ba'zi ishlarni aks ettirishimiz kerak bo'lsa, masalan, tizim yangilanishlarini o'rnatish yoki ikkinchi ma'lumotlar bazasida sozlamalarni o'zgartirish, keyin, umuman olganda, biz xuddi shu narsani boshqa yo'nalishda takrorlaymiz. Va agar bu baxtsiz hodisa bo'lsa, biz hamma narsani ahamiyatsiz qilamiz: biz monitoring tizimida hodisalarni boshqarish mexanizmidan foydalanamiz. Agar bir nechta tekshiruvlar ishga tushirilsa va holat kritik darajaga tushsa, biz u yoki bu mantiqni bajara oladigan ushbu ishlov beruvchini ishga tushiramiz. Har bir ma'lumotlar bazasi uchun biz qaysi serverning o'zgarmasligini va agar u mavjud bo'lmasa, trafikni qayerga almashtirish kerakligini aniqlaymiz. Tarixiy jihatdan biz nagios yoki uning ba'zi vilkalarini u yoki bu shaklda ishlatamiz. Aslida, shunga o'xshash mexanizmlar deyarli har qanday monitoring tizimida mavjud, biz hali murakkabroq narsadan foydalanmayapmiz, lekin bir kun kelib biz ham foydalanamiz. Endi monitoring mavjud emasligi sababli ishga tushiriladi va biror narsani almashtirish qobiliyatiga ega.
Biz hamma narsani band qildikmi?
Bizda AQShdan ko'plab mijozlar, Evropadan ko'plab mijozlar, Sharqqa yaqinroq bo'lgan ko'plab mijozlar - Yaponiya, Singapur va boshqalar. Albatta, mijozlarning katta qismi Rossiyada. Ya'ni, ish bir hududda emas. Foydalanuvchilar tezkor javob olishni xohlashadi, turli xil mahalliy qonunlarga rioya qilish talablari mavjud va har bir mintaqada biz ikkita ma'lumot markazini zahiraga olamiz, shuningdek, yana bir mintaqada joylashtirish uchun qulay bo'lgan qo'shimcha xizmatlar mavjud - bu erda bo'lgan mijozlar uchun. bu hudud ishlamoqda. REST ishlov beruvchilari, avtorizatsiya serverlari, ular umuman mijozning ishlashi uchun unchalik muhim emas, siz ular orqali kichik qabul qilinadigan kechikish bilan o'tishingiz mumkin, lekin ularni qanday kuzatish va nima qilish kerakligi haqida g'ildirakni qayta kashf qilishni xohlamaysiz. ular bilan. Shuning uchun biz qo'shimcha mahsulotlarda qandaydir kompetentsiyani rivojlantirishdan ko'ra, mavjud echimlardan maksimal darajada foydalanishga harakat qilmoqdamiz. Va biron bir joyda biz DNS darajasida kommutatsiyadan foydalanamiz va biz xizmatning jonliligini xuddi shu DNS orqali aniqlaymiz. Amazon-da Route 53 xizmati mavjud, ammo bu shunchaki siz kiritishingiz mumkin bo'lgan DNS emas va bu juda ham moslashuvchan va qulay. U orqali siz geolokatsiyalar bilan geo-tarqatilgan xizmatlarni qurishingiz mumkin, undan mijoz qayerdan kelganini aniqlash va unga ma'lum yozuvlarni berish uchun foydalanilganda - uning yordami bilan uzilishlar arxitekturasini qurishingiz mumkin. Xuddi shu sog'liqni saqlash tekshiruvlari 53-yo'nalishning o'zida sozlangan, siz nazorat qilinadigan so'nggi nuqtalarni o'rnatasiz, ko'rsatkichlarni o'rnatasiz, xizmatning "hayotini" aniqlash uchun qaysi protokollarni o'rnatasiz - tcp, http, https; xizmat jonli yoki yo'qligini aniqlaydigan tekshiruvlar chastotasini belgilang. Va DNS-ning o'zida nima asosiy, nima ikkilamchi bo'lishini, agar 53-marshrut ichida sog'lig'ini tekshirish boshlangan bo'lsa, qaerga o'tish kerakligini aniqlaysiz. Bularning barchasini boshqa vositalar yordamida amalga oshirish mumkin, lekin nima uchun bu qulay - biz uni o'rnatdik. bir marta yuqoriga ko'taring va keyin bu haqda umuman o'ylamang, biz qanday tekshiruvlar qilamiz, qanday almashtiramiz: hamma narsa o'z-o'zidan ishlaydi.
Birinchi "lekin": 53-marshrutni qanday va nima bilan bron qilish kerak? Kim biladi, agar unga biror narsa bo'lsa-chi? Yaxshiyamki, biz bu rakega hech qachon qadam qo'ymaganmiz, lekin yana nima uchun biz hali ham bron qilishimiz kerak deb o'ylaganimiz haqida hikoya qilaman. Bu erda biz o'zimiz uchun oldindan somon qo'ydik. Biz kuniga bir necha marta 53-marshrutdagi barcha zonalarni to'liq tushiramiz. Amazon API-si ularni JSON-da osongina yuborish imkonini beradi va bizda bir nechta zaxira serverlarimiz bor, ularni o'zgartiramiz, uni konfiguratsiyalar shaklida yuklaymiz va taxminan, zaxira konfiguratsiyasiga egamiz. Agar biror narsa yuz bersa, biz DNS sozlamalari ma'lumotlarini yo'qotmasdan uni tezda qo'lda o'rnatishimiz mumkin.
Ikkinchi "lekin": Bu rasmdagi nima hali band qilinmagan? Balanslashtiruvchining o'zi! Mijozlarni mintaqalar bo'yicha taqsimlashimiz juda oddiy. Bizda bitrix24.ru, bitrix24.com, .de domenlari bor - endi 13 xil domenlar mavjud bo'lib, ular turli zonalarda ishlaydi. Biz quyidagilarga keldik: har bir mintaqaning o'z balanschilari bor. Bu tarmoqdagi eng yuqori yuk qayerda bo'lishiga qarab, hududlar bo'ylab tarqatishni yanada qulay qiladi. Agar bu bitta balanser darajasida nosozlik bo'lsa, u oddiygina xizmatdan chiqariladi va dns-dan o'chiriladi. Agar balanschilar guruhida qandaydir muammo yuzaga kelsa, ular boshqa saytlarda zaxiralanadi va ular o'rtasida almashish xuddi shu marshrut yordamida amalga oshiriladi53, chunki qisqa TTL tufayli kommutatsiya maksimal 2, 3, 5 daqiqada sodir bo'ladi. .
Uchinchi "lekin": Nimalar hali band qilinmagan? S3, to'g'ri. Biz foydalanuvchilar uchun saqlaydigan fayllarni s3-ga joylashtirganimizda, biz chin dildan uning zirhni teshuvchi ekanligiga ishondik va u erda hech narsa zaxiralashning hojati yo'q edi. Ammo tarix shuni ko'rsatadiki, voqealar boshqacha sodir bo'ladi. Umuman olganda, Amazon S3-ni asosiy xizmat sifatida ta'riflaydi, chunki Amazonning o'zi S3-dan mashina tasvirlari, konfiguratsiyalar, AMI tasvirlari, oniy tasvirlarni saqlash uchun foydalanadi... Va agar s3 7 yil davomida bir marta sodir bo'lgani kabi ishlamay qolsa, biz foydalanayotganimizda. bitrix24, uni fan kabi kuzatib boradi Ko'p narsalar paydo bo'ladi - virtual mashinalarni ishga tushira olmaslik, api ishdan chiqishi va hokazo.
Va S3 tushishi mumkin - bu bir marta sodir bo'ldi. Shuning uchun biz quyidagi sxemaga keldik: bir necha yil oldin Rossiyada jiddiy jamoat ob'ektlarini saqlash joylari yo'q edi va biz o'zimizning biror narsa qilish variantini ko'rib chiqdik ... Yaxshiyamki, biz buni boshlamadik, chunki biz Bizda mavjud bo'lmagan tajribani qazib oldik va ehtimol chalkashtirib yubordik. Endi Mail.ru-da s3-ga mos xotira mavjud, Yandex-da va boshqa bir qator provayderlarda mavjud. Oxir-oqibat, biz, birinchidan, zaxiraga, ikkinchidan, mahalliy nusxalar bilan ishlash qobiliyatiga ega bo'lishni xohlaymiz degan fikrga keldik. Xususan, Rossiya mintaqasi uchun biz s3 bilan mos keladigan Mail.ru Hotbox xizmatidan foydalanamiz. Bizga ilova ichidagi kodga katta oʻzgartirishlar kerak emas edi va biz quyidagi mexanizmni yaratdik: s3 da obʼyektlarni yaratish/oʻchirishni ishga tushiruvchi triggerlar mavjud, Amazonda Lambda deb nomlangan xizmat mavjud – bu kodni serversiz ishga tushirish. Bu faqat ma'lum triggerlar ishga tushirilganda amalga oshiriladi.
Biz buni juda oddiy qildik: agar triggerimiz yonib ketsa, biz ob'ektni Mail.ru xotirasiga ko'chiradigan kodni bajaramiz. Ma'lumotlarning mahalliy nusxalari bilan ishlashni to'liq boshlash uchun bizga teskari sinxronizatsiya ham kerak, shunda rus segmentida bo'lgan mijozlar ularga yaqinroq bo'lgan saqlash bilan ishlashlari mumkin. Pochta o'z xotirasida triggerlarni bajarish arafasida - infratuzilma darajasida teskari sinxronizatsiyani amalga oshirish mumkin bo'ladi, ammo hozircha biz buni o'z kodimiz darajasida qilyapmiz. Agar mijoz faylni joylashtirganini ko'rsak, kod darajasida biz voqeani navbatga qo'yamiz, uni qayta ishlaymiz va teskari replikatsiya qilamiz. Nima uchun bu yomon: agar biz mahsulotimizdan tashqarida, ya'ni qandaydir tashqi vositalar bilan ob'ektlarimiz bilan qandaydir ish qilsak, biz buni hisobga olmaymiz. Shuning uchun biz oxirigacha, saqlash darajasida triggerlar paydo bo'lguncha kutamiz, shunda kodni qayerdan bajarmasak ham, bizga kelgan ob'ekt boshqa yo'nalishda ko'chiriladi.
Kod darajasida biz har bir mijoz uchun ikkala omborni ro'yxatdan o'tkazamiz: biri asosiy, ikkinchisi zaxira deb hisoblanadi. Agar hamma narsa yaxshi bo'lsa, biz o'zimizga yaqinroq bo'lgan saqlash bilan ishlaymiz: ya'ni Amazonda bo'lgan mijozlarimiz S3 bilan ishlaydi, Rossiyada ishlaydiganlar esa Hotbox bilan ishlaydi. Agar bayroq yoqilgan bo'lsa, u holda o'chirish ulanishi kerak va biz mijozlarni boshqa xotiraga o'tkazamiz. Biz ushbu katakchani mintaqa bo'yicha mustaqil ravishda belgilashimiz va ularni oldinga va orqaga almashtirishimiz mumkin. Biz buni amalda hali ishlatmadik, lekin biz ushbu mexanizmni taqdim qildik va biz bir kun kelib bizga aynan shu o'zgartirish kerak bo'ladi va foydali bo'ladi deb o'ylaymiz. Bu allaqachon bir marta sodir bo'lgan.
Oh, va Amazon qochib ketdi ...
Shu yilning aprel oyida Rossiyada Telegram blokirovkasi boshlanganiga bir yil to'ldi. Buning ostida qolgan eng ko'p zarar ko'rgan provayder bu Amazon. Va, afsuski, butun dunyo uchun ishlagan rus kompaniyalari ko'proq zarar ko'rdi.
Agar kompaniya global bo'lsa va Rossiya buning uchun juda kichik segment bo'lsa, 3-5% - yaxshi, u yoki bu tarzda, siz ularni qurbon qilishingiz mumkin.
Agar bu sof rus kompaniyasi bo'lsa - ishonchim komilki, u mahalliy joyda joylashgan bo'lishi kerak - bu foydalanuvchilarning o'zlari uchun qulay, qulay bo'ladi va xavflar kamroq bo'ladi.
Agar bu butun dunyo bo'ylab faoliyat yuritadigan va Rossiyadan va butun dunyo bo'ylab taxminan teng miqdordagi mijozlarga ega bo'lgan kompaniya bo'lsa-chi? Segmentlarning ulanishi muhim va ular bir-biri bilan u yoki bu tarzda ishlashi kerak.
2018-yil mart oyi oxirida Roskomnadzor eng yirik operatorlarga Zello messenjerini bloklash maqsadida bir necha million Amazon IP-ni bloklashni rejalashtirayotganliklari haqida xat yubordi. Xuddi shu provayderlarga rahmat - ular maktubni hammaga muvaffaqiyatli tarqatishdi va Amazon bilan aloqa uzilishi mumkinligi haqida tushuncha paydo bo'ldi. Bu juma kuni edi, biz vahima ichida servers.ru saytidagi hamkasblarimizga yugurdik: "Do'stlar, bizga Rossiyada emas, Amazonda emas, balki, masalan, Amsterdamda joylashgan bir nechta serverlar kerak" Hech bo'lmaganda qandaydir tarzda o'zimizning VPN va proksi-serverimizni o'rnatishimiz mumkin bo'lgan ba'zi so'nggi nuqtalar uchun biz hech qanday tarzda ta'sir qila olmaydigan, masalan, bir xil s3 ning endponts - biz yangi xizmatni ko'tarishga va boshqasini olishga harakat qila olmaymiz. ip, biz siz hali ham u erga borishingiz kerak. Bir necha kun ichida biz ushbu serverlarni o'rnatdik, ularni ishga tushirdik va umuman, blokirovka boshlangan paytga tayyorlandik. Qizig'i shundaki, RKN shov-shuv va vahimaga qarab: "Yo'q, biz hozir hech narsani to'sib qo'ymaymiz", dedi. (Ammo bu aynan Telegram bloklana boshlagan paytgacha.) Bypass imkoniyatlarini o'rnatib, blokirovka joriy etilmaganini tushunib, biz hamma masalani hal qilishni boshlamadik. Ha, har qanday holatda.
Va 2019 yilda biz hali ham blokirovka sharoitida yashayapmiz. Kecha qaradim: millionga yaqin IP bloklanishda davom etmoqda. To'g'ri, Amazon deyarli butunlay blokdan chiqarildi, eng yuqori cho'qqisida u 20 million manzilga yetdi... Umuman olganda, haqiqat shundaki, izchillik, yaxshi uyg'unlik bo'lmasligi mumkin. Birdan. Bu texnik sabablarga ko'ra mavjud bo'lmasligi mumkin - yong'inlar, ekskavatorlar va boshqalar. Yoki, biz ko'rganimizdek, butunlay texnik emas. Shuning uchun, katta va katta kimdir, o'z ASlariga ega, buni boshqa yo'llar bilan boshqarishi mumkin - to'g'ridan-to'g'ri ulanish va boshqa narsalar allaqachon l2 darajasida. Ammo oddiy versiyada, biznikiga o'xshab yoki undan ham kichikroq, siz har qanday holatda, boshqa joyda ko'tarilgan, oldindan vpn, proksi-server sozlangan serverlar darajasida zaxiraga ega bo'lishingiz mumkin, bu esa konfiguratsiyani ushbu segmentlarda ularga tezda almashtirish imkoniyatiga ega. ulanishingiz uchun juda muhim. Bu biz uchun bir necha bor foydali bo'ldi, Amazon blokirovkasi boshlanganda; eng yomon stsenariyda biz ular orqali faqat S3 trafigiga ruxsat berdik, lekin asta-sekin bularning barchasi hal qilindi.
Qanday qilib butun provayderni bron qilish kerak?
Hozirda bizda butun Amazon qulab tushishi mumkin bo'lgan stsenariy yo'q. Bizda Rossiya uchun ham xuddi shunday stsenariy bor. Rossiyada bizni bitta provayder qabul qildi, ulardan bir nechta saytlarni tanladik. Va bir yil oldin biz muammoga duch keldik: bu ikkita ma'lumot markazi bo'lsa ham, provayderning tarmoq konfiguratsiyasi darajasida muammolar bo'lishi mumkin, bu ikkala ma'lumot markazlariga ham ta'sir qiladi. Va biz ikkala saytda ham ishlamasligimiz mumkin. Albatta, shunday bo'ldi. Biz ichki arxitekturani qayta ko'rib chiqishni yakunladik. Bu juda ko'p o'zgarmadi, lekin Rossiya uchun endi bizda ikkita sayt mavjud, ular bir xil provayderdan emas, balki ikki xil saytdan. Agar biri muvaffaqiyatsiz bo'lsa, biz boshqasiga o'tishimiz mumkin.
Gipotetik jihatdan, Amazon uchun biz boshqa provayder darajasida bron qilish imkoniyatini ko'rib chiqamiz; balki Google, balki boshqasi... Lekin hozirgacha amalda kuzatdikki, Amazonda bitta mavjudlik zonasi darajasida baxtsiz hodisalar ro'y bersa-da, butun mintaqa darajasida baxtsiz hodisalar juda kam uchraydi. Shuning uchun biz nazariy jihatdan "Amazon bu Amazon emas" bandini amalga oshirishimiz mumkin degan fikrga egamiz, ammo amalda bu hali shunday emas.
Avtomatlashtirish haqida bir necha so'z
Avtomatlashtirish har doim kerakmi? Bu erda Dunning-Kruger effektini eslash o'rinlidir. "X" o'qida biz olgan bilim va tajribamiz, "y" o'qida - harakatlarimizga ishonch. Avvaliga biz hech narsani bilmaymiz va umuman ishonchimiz komil emas. Keyin biz ozgina bilamiz va o'ziga ishonamiz - bu "ahmoqlik cho'qqisi" deb ataladigan narsa, "demans va jasorat" rasmida yaxshi tasvirlangan. Keyin biz biroz o'rgandik va jangga kirishga tayyormiz. Keyin biz ba'zi jiddiy xatolarga yo'l qo'yamiz va o'zimizni umidsizlik vodiysida topamiz, qachonki biz nimanidir bilgandek bo'lamiz, lekin aslida biz ko'p narsani bilmaymiz. Keyin tajriba orttirganimiz sari o‘zimizga ishonchimiz ortib boraveradi.
Muayyan baxtsiz hodisalarga turli xil avtomatik o'tish haqidagi bizning mantiqimiz ushbu grafikda juda yaxshi tasvirlangan. Biz boshladik - biz hech narsa qilishni bilmasdik, deyarli barcha ishlar qo'lda bajarildi. Keyin biz hamma narsaga avtomatlashtirishni qo'shishimiz va tinch uxlashimiz mumkinligini angladik. Va to'satdan biz mega-rakega qadam qo'ydik: noto'g'ri pozitiv ishga tushdi va biz trafikni oldinga va orqaga almashtiramiz, qachonki, yaxshi ma'noda, biz buni qilmasligimiz kerak edi. Shunday qilib, replikatsiya buziladi yoki boshqa narsa - bu umidsizlik vodiysi. Va keyin biz hamma narsaga oqilona yondashishimiz kerakligini tushunamiz. Ya'ni, noto'g'ri signallarni berish imkoniyatini ta'minlaydigan avtomatlashtirishga tayanish mantiqan. Lekin! Agar oqibatlar halokatli bo'lishi mumkin bo'lsa, uni navbatchi navbatchi muhandislarga topshirgan ma'qul, ular haqiqatan ham avariya sodir bo'lganiga ishonch hosil qiladi va nazorat qiladi va kerakli harakatlarni qo'lda bajaradi ...
xulosa
7 yil davomida biz biror narsa yiqilganda vahima paydo bo'lishidan, muammolar mavjud emas, faqat vazifalar borligini tushunishga o'tdik va ularni hal qilish kerak va mumkin. Xizmatni qurayotganingizda, unga yuqoridan qarang, yuzaga kelishi mumkin bo'lgan barcha xavflarni baholang. Agar siz ularni darhol ko'rsangiz, oldindan ortiqcha ishlarni va nosozliklarga chidamli infratuzilmani qurish imkoniyatini ta'minlang, chunki muvaffaqiyatsiz bo'lishi mumkin bo'lgan va xizmatning ishlamasligiga olib keladigan har qanday nuqta, albatta, buni amalga oshiradi. Va sizga infratuzilmaning ba'zi elementlari, albatta, muvaffaqiyatsiz bo'lmaydi deb tuyulsa ham - xuddi shu s3 kabi, ular baribir esda tuting. Va hech bo'lmaganda nazariy jihatdan, agar biror narsa yuz bersa, ular bilan nima qilish haqida tasavvurga ega bo'ling. Xatarlarni boshqarish rejasiga ega bo'ling. Hamma narsani avtomatik yoki qo'lda qilish haqida o'ylayotganingizda, xavflarni baholang: agar avtomatlashtirish hamma narsani o'zgartira boshlasa nima bo'ladi - bu baxtsiz hodisaga nisbatan yomonroq vaziyatga olib kelmaydimi? Ehtimol, biror joyda avtomatlashtirishdan foydalanish va navbatchi muhandisning reaktsiyasi o'rtasida oqilona murosani qo'llash kerak bo'ladi, u haqiqiy rasmni baholaydi va biror narsani joyida o'zgartirish kerakligini yoki "ha, lekin hozir emas" ni tushunadi.
Perfektsionizm va haqiqiy harakat, vaqt, pul o'rtasidagi oqilona kelishuv, siz oxir-oqibatda bo'ladigan sxemaga sarflashingiz mumkin.
Ushbu matn Aleksandr Demidovning konferentsiyadagi ma'ruzasining yangilangan va kengaytirilgan versiyasidir .
Manba: www.habr.com