Eslatma. tarjima.: Ushbu maqola AT tizimlaridagi nosozliklar oqibatlarini yumshatish uchun eksperiment o'tkazish muhimligini sodda va tushunarli tarzda tushuntirishga kirishgan AWS texnologiya evangelisti Adrian Xornsbining ajoyib maqolalarini davom ettiradi.
"Agar siz reja tuza olmasangiz, muvaffaqiyatsiz bo'lishni rejalashtirasiz." - Benjamin Franklin
В Ushbu maqolalar turkumida men xaos muhandisligi tushunchasi bilan tanishdim va bu tizimdagi kamchiliklarni ishlab chiqarishdagi nosozliklarga olib kelishidan oldin topish va tuzatishga qanday yordam berishini tushuntirdim. Shuningdek, tartibsizlik muhandisligi tashkilotlar ichidagi ijobiy madaniy o'zgarishlarni qanday targ'ib qilishini muhokama qildi.
Birinchi qismning oxirida men "tizimlarga nosozliklarni kiritish vositalari va usullari" haqida gapirishga va'da berdim. Afsuski, mening boshimning bu borada o'z rejalari bor edi va ushbu maqolada men betartiblik muhandisligiga kirishni xohlaydigan odamlar orasida paydo bo'ladigan eng mashhur savolga javob berishga harakat qilaman: Avval nimani buzish kerak?
Ajoyib savol! Biroq, uni bu panda unchalik bezovta qilmaganga o'xshaydi...
Xaos panda bilan aralashmang!
Qisqa javob: So'rov yo'li bo'ylab muhim xizmatlarni maqsad qilib oling.
Uzunroq, ammo aniqroq javob: Xaos bilan tajribani qaerdan boshlashni tushunish uchun uchta sohaga e'tibor bering:
- Qarang halokat tarixi va naqshlarni aniqlash;
- Qaror qabul qiling tanqidiy bog'liqliklar;
- Deb atalmishlardan foydalaning haddan tashqari ishonch effekti.
Bu kulgili, lekin bu qismni osongina chaqirish mumkin "O'z-o'zini kashf qilish va ma'rifat sari sayohat". Unda biz ajoyib asboblar bilan "o'ynashni" boshlaymiz.
1. Javob o'tmishda yotadi
Esingizda bo'lsa, birinchi bo'limda men xatolarni tuzatish (COE) tushunchasini kiritgan edim - bu usul yordamida biz xatolarimizni tahlil qilamiz - texnologiya, jarayon yoki tashkilotdagi xatolar - ularning sabablarini tushunish va oldini olish uchun. kelajakda takrorlash. Umuman olganda, bu erdan boshlash kerak.
"Hozirgi kunni tushunish uchun o'tmishni bilish kerak." - Karl Sagan
Muvaffaqiyatsizliklar tarixiga qarang, ularni COE yoki postmortemlarda belgilang va ularni tasniflang. Ko'pincha muammolarga olib keladigan umumiy naqshlarni aniqlang va har bir COE uchun o'zingizga quyidagi savolni bering:
"Buni bashorat qilish va shuning uchun nosozlik in'ektsiyasi bilan oldini olish mumkinmi?"
Faoliyatimning boshida bitta muvaffaqiyatsizlikni eslayman. Agar biz bir nechta oddiy tartibsizlik tajribalarini o'tkazganimizda, buni osongina oldini olish mumkin edi:
Oddiy sharoitlarda, backend namunalari sog'liq tekshiruvlariga javob beradi ). ELB so'rovlarni sog'lom misollarga yo'naltirish uchun ushbu tekshiruvlardan foydalanadi. Agar namuna "nosog'lom" ekanligi aniqlansa, ELB unga so'rov yuborishni to'xtatadi. Bir kuni, muvaffaqiyatli marketing kampaniyasidan so'ng, trafik hajmi oshdi va orqa tomonlar sog'lig'ini tekshirishga odatdagidan ko'ra sekinroq javob berishni boshladilar. Aytish kerakki, bu sog'liq tekshiruvlari edi , ya'ni bog'liqliklarning holati tekshirildi.
Biroq, bir muncha vaqt hamma narsa yaxshi edi.
Keyin, juda og'ir sharoitlarda, misollardan biri muhim bo'lmagan, muntazam ETL cron vazifasini bajarishni boshladi. Yuqori trafik va cronjob kombinatsiyasi protsessordan foydalanishni deyarli 100% ga oshirdi. Protsessorning haddan tashqari yuklanishi salomatlik tekshiruvlariga javoblarni yanada sekinlashtirdi, shuning uchun ELB misolda ishlashda muammolar bor deb qaror qildi. Kutilganidek, balanschi unga trafikni taqsimlashni to'xtatdi, bu esa, o'z navbatida, guruhdagi qolgan misollardagi yukning oshishiga olib keldi.
To'satdan, boshqa barcha holatlar ham sog'liq tekshiruvidan o'ta boshladi.
Yangi namunani ishga tushirish paketlarni yuklab olish va o'rnatishni talab qildi va ularni avtomatik o'lchov guruhida birma-bir o'chirib qo'yish uchun ELB sarflaganidan ancha ko'proq vaqt talab qilindi. Ko'rinib turibdiki, ko'p o'tmay butun jarayon juda muhim nuqtaga yetdi va dastur ishdan chiqdi.
Keyin biz quyidagi fikrlarni abadiy tushundik:
- Yangi namuna yaratishda dasturiy ta'minotni o'rnatish uzoq vaqt talab etadi, o'zgarmas yondashuvga ustunlik berish yaxshidir. .
- Murakkab vaziyatlarda sog'liqni saqlash tekshiruvlari va ELBlarga javoblar ustuvor bo'lishi kerak - siz istagan oxirgi narsa qolgan holatlar uchun hayotni murakkablashtirishdir.
- Sog'liqni saqlash tekshiruvlarini mahalliy keshlash juda ko'p yordam beradi (hatto bir necha soniya).
- Qiyin vaziyatda cron vazifalarini va boshqa muhim bo'lmagan jarayonlarni bajarmang - eng muhim vazifalar uchun resurslarni saqlang.
- Avtomatik masshtablashda kichikroq misollardan foydalaning. 10 ta kichik namunadan iborat guruh 4 ta katta bo'lgan guruhdan yaxshiroqdir; agar bitta instansiya bajarilmasa, birinchi holatda trafikning 10% 9 ball bo'yicha taqsimlanadi, ikkinchisida - uch balldan 25% trafik.
Va shunday qilib, Buni oldindan ko'rish mumkin edi va shuning uchun muammoni kiritish orqali oldini olish mumkinmi?
ekan, va bir necha usulda.
Birinchidan, kabi vositalar yordamida yuqori protsessordan foydalanishni simulyatsiya qilish orqali yoki :
❯ stress-ng --matrix 1 -t 60s
stress-dan
Ikkinchidan, misolni haddan tashqari yuklash orqali va boshqa shunga o'xshash yordamchi dasturlar:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
Tajribalar nisbatan sodda, ammo haqiqiy muvaffaqiyatsizlik stressini boshdan kechirmasdan fikrlash uchun yaxshi ozuqa berishi mumkin.
Biroq, u erda to'xtamang. Sinov muhitida halokatni takrorlashga harakat qiling va savolga javobingizni tekshiring "Buni oldindan ko'rish mumkinmi va shuning uchun xato kiritish orqali oldini olish mumkinmi?" Bu farazlarni sinab ko'rish uchun xaos eksperimenti doirasidagi mini xaos tajribasi, ammo muvaffaqiyatsizlik bilan boshlanadi.
Bu tushmi yoki haqiqatan ham sodir bo'lganmi?
Shunday qilib, muvaffaqiyatsizliklar tarixini o'rganing, tahlil qiling COE, ularni “urilish radiusi” yoki aniqrog‘i, ta’sirlangan mijozlar soni bo‘yicha belgilang va tasniflang va keyin naqshlarni qidiring. O'zingizdan so'rang, bu muammoni kiritish orqali oldindan aytish va oldini olish mumkinmi? Javobingizni tekshiring.
Keyin eng katta zarar radiusi bilan eng keng tarqalgan naqshlarga o'ting.
2. Bog‘liqlik xaritasini tuzing
Arizangiz haqida o'ylab ko'ring. Uning bog'liqliklarining aniq xaritasi bormi? Muvaffaqiyatsizlik bo'lsa, ular qanday ta'sir qilishini bilasizmi?
Agar ilovangiz kodi bilan unchalik tanish bo'lmasangiz yoki u juda katta bo'lib qolsa, kod nima qilishini va uning bog'liqliklarini tushunish qiyin bo'lishi mumkin. Ushbu bog'liqliklarni va ularning dastur va foydalanuvchilarga ta'sirini tushunish tartibsizlik muhandisligini qaerdan boshlashni bilish uchun juda muhimdir: boshlang'ich nuqtasi eng katta ta'sir radiusiga ega bo'lgan komponent hisoblanadi.
Bog'liqlarni aniqlash va hujjatlashtirish "deb ataladi.qaramlik xaritasini yaratish» (qaramlik xaritasi). Bu odatda kodni profillash vositalaridan foydalangan holda katta kod bazasiga ega ilovalar uchun amalga oshiriladi. (kodni profillash) va asboblar (asboblar). Shuningdek, siz tarmoq trafigini kuzatish orqali xarita yaratishingiz mumkin.
Biroq, barcha bog'liqliklar bir xil emas (bu jarayonni yanada murakkablashtiradi). Biroz tanqidiy, boshqa - ikkinchi darajali (hech bo'lmaganda nazariy jihatdan, chunki buzilishlar ko'pincha muhim bo'lmagan bog'liqliklar bilan bog'liq muammolar tufayli yuzaga keladi).
Kritik bog'liqliklarsiz xizmat ishlamaydi. Kritik bo'lmagan bog'liqliklar "Kerak emas» qulab tushganda xizmatga ta'sir qilish. Bog'liqlarni tushunish uchun siz ilovangiz tomonidan ishlatiladigan API-lar haqida aniq tushunchaga ega bo'lishingiz kerak. Bu ko'rinadiganidan ancha qiyin bo'lishi mumkin - hech bo'lmaganda katta ilovalar uchun.
Barcha API-lardan o'tishni boshlang. Eng ko'p ajratib ko'rsatish muhim va tanqidiy. Oling bog'liqliklar kod omboridan, uni tekshiring ulanish jurnallari, keyin ko'ring hujjatlar (albatta, agar u mavjud bo'lsa - aks holda sizda hali ham borоkatta muammolar). Buning uchun asboblardan foydalaning profillash va kuzatish, tashqi qo'ng'iroqlarni filtrlang.
kabi dasturlardan foydalanishingiz mumkin netstat - tizimdagi barcha tarmoq ulanishlari (faol rozetkalar) ro'yxatini ko'rsatadigan buyruq qatori yordam dasturi. Masalan, barcha joriy ulanishlarni ro'yxatlash uchun quyidagilarni yozing:
❯ netstat -a | more
AWS da foydalanishingiz mumkin (oqim jurnallari) VPC - bu VPC-dagi tarmoq interfeyslariga ketadigan yoki undan chiqadigan IP-trafik haqida ma'lumot to'plash imkonini beruvchi usul. Bunday jurnallar boshqa vazifalarni bajarishda ham yordam berishi mumkin - masalan, nega ma'lum trafik instansiyaga etib bormaydi degan savolga javob topish.
Siz ham foydalanishingiz mumkin . X-ray sizga batafsil, "yakuniy" olish imkonini beradi. (oxirigacha) so'rovlar ilova bo'ylab harakatlanayotganda ularning umumiy ko'rinishi, shuningdek, ilovaning asosiy komponentlari xaritasini tuzadi. Agar bog'liqliklarni aniqlash kerak bo'lsa, juda qulay.
AWS rentgen konsoli
Tarmoqqa bog'liqlik xaritasi faqat qisman yechimdir. Ha, u qaysi ilova qaysi bilan bog'lanishini ko'rsatadi, ammo boshqa bog'liqliklar ham mavjud.
Ko'pgina ilovalar bog'liqliklarga ulanish uchun DNS-dan foydalanadi, boshqalari esa konfiguratsiya fayllarida xizmatlarni aniqlash yoki hatto qattiq kodlangan IP manzillardan foydalanishi mumkin (masalan,). /etc/hosts).
Masalan, siz yaratishingiz mumkin yordamida iptables va nima buzayotganini ko'ring. Buning uchun quyidagi buyruqni kiriting:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
DNS qora tuynuk
Agarda /etc/hosts yoki boshqa konfiguratsiya fayllarida siz hech narsa bilmagan IP manzillarini topasiz (ha, afsuski, bu ham sodir bo'ladi), siz yana yordamga kelishingiz mumkin. iptables. Aytaylik, siz kashf qildingiz 8.8.8.8 va bu Googlening umumiy DNS server manzili ekanligini bilmayman. Yordamida iptables Quyidagi buyruqlar yordamida ushbu manzilga kiruvchi va chiquvchi trafikni bloklashingiz mumkin:
❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"
Kirish yopilyapti
Birinchi qoida barcha paketlarni Google umumiy DNS-dan olib tashlaydi: ping ishlaydi, lekin paketlar qaytarilmaydi. Ikkinchi qoida tizimingizdan kelgan barcha paketlarni Google umumiy DNS-ga o'chiradi - bunga javoban ping biz olamiz Operatsiyaga ruxsat berilmagan.
Eslatma: bu alohida holatda foydalanish yaxshiroqdir whois 8.8.8.8, lekin bu faqat bir misol.
Biz quyon teshigidan yanada chuqurroq tushishimiz mumkin, chunki TCP va UDP dan foydalanadigan hamma narsa aslida IP-ga bog'liq. Ko'p hollarda IP ARP bilan bog'langan. Xavfsizlik devorlari haqida unutmang ...
Agar siz qizil tabletkani ichsangiz, siz ajoyibotlar mamlakatida qolasiz va men sizga quyon teshigi qanchalik chuqurligini ko'rsataman.
Buning uchun yanada radikal yondashuv o'chirib qo'ying mashinalarni birma-bir ko'ring va nima buzilganligini ko'ring ... "tartibsizlik maymuniga" aylang. Albatta, ko'plab ishlab chiqarish tizimlari bunday qo'pol kuch hujumi uchun mo'ljallanmagan, lekin hech bo'lmaganda uni sinov muhitida sinab ko'rish mumkin.
Bog'liqlik xaritasini yaratish ko'pincha juda uzoq davom etadigan ishdir. Men yaqinda deyarli 2 yil davomida yuzlab mikroservislar va buyruqlar uchun qaramlik xaritalarini yarim avtomatik ravishda yaratadigan vositani ishlab chiqishga sarflagan mijoz bilan gaplashdim.
Biroq, natija juda qiziqarli va foydali. Siz tizimingiz, uning bog'liqliklari va operatsiyalari haqida ko'p narsalarni bilib olasiz. Yana sabrli bo'ling: eng muhimi bu sayohatning o'zi.
3. Haddan tashqari ishonchdan ehtiyot bo'ling
"Kim nimani orzu qilsa, unga ishonadi." - Demosfen
Hech eshitganmisiz haddan tashqari ishonch effekti?
Vikipediyaga ko'ra, haddan tashqari o'ziga ishonch effekti "odamning o'z harakatlari va qarorlariga bo'lgan ishonchi, ayniqsa, ishonch darajasi nisbatan yuqori bo'lsa, bu hukmlarning ob'ektiv aniqligidan sezilarli darajada yuqori bo'lgan kognitiv moyillikdir".
Instinkt va tajribaga asoslangan ...
Mening tajribamga ko'ra, bu buzilish xaos muhandisligi bilan qaerdan boshlash kerakligi haqida ajoyib ishoradir.
Haddan tashqari ishonchli operatordan ehtiyot bo'ling:
Charli: "Bu narsa besh yildan beri tushmadi, hammasi joyida!"
Crash: "Kutib turing ... Men tez orada bo'laman!"
Haddan tashqari o'ziga ishonchning oqibati sifatida qarama-qarshilik unga ta'sir qiluvchi turli omillar tufayli makkor va hatto xavfli narsadir. Bu, ayniqsa, jamoa a'zolari o'z yuraklarini texnologiyaga to'kishsa yoki uni "tuzatish" uchun ko'p vaqt sarflaganlarida to'g'ri keladi.
Xulosa qilish
Xaos muhandisligi uchun boshlang'ich nuqtani izlash har doim kutilganidan ko'ra ko'proq natijalar beradi va narsalarni tezda buzishni boshlagan jamoalar (xaos-)muhandislik - ijodiy foydalanish ilmiy usullar и empirik dalillar (dasturiy ta'minot) tizimlarini loyihalash, ishlab chiqish, ishlatish, texnik xizmat ko'rsatish va takomillashtirish uchun.
Bu ikkinchi qismni yakunlaydi. Iltimos, sharhlar yozing, fikrlaringizni baham ko'ring yoki shunchaki qo'lingizni bosing . Keyingi qismda I albatta Tizimlarga nosozliklarni kiritish uchun vositalar va usullarni ko'rib chiqaman. Qachonki!
Tarjimondan PS
Shuningdek, bizning blogimizda o'qing:
- «";
- «";
- «";
- «".
Manba: www.habr.com