مهندسی آشوب: هنر تخریب عمدی. قسمت 2

توجه داشته باشید. ترجمه: این مقاله ادامه یک سری مقالات عالی از مبشر فناوری AWS، آدریان هورنسبی است، که قصد دارد به روشی ساده و واضح اهمیت آزمایش را برای کاهش پیامدهای خرابی در سیستم‌های IT توضیح دهد.

"اگر موفق به تهیه یک برنامه نشدید، پس برای شکست برنامه ریزی می کنید." - بنجامین فرانکلین

В بخش اول در این سری از مقالات، مفهوم مهندسی آشوب را معرفی کردم و توضیح دادم که چگونه به یافتن و اصلاح عیوب سیستم قبل از اینکه منجر به شکست تولید شود، کمک می کند. همچنین در مورد اینکه چگونه مهندسی آشوب باعث ایجاد تغییرات مثبت فرهنگی در سازمان ها می شود، بحث شد.

در پایان قسمت اول، قول دادم در مورد «ابزارها و روش‌هایی برای معرفی خرابی‌ها در سیستم‌ها» صحبت کنم. افسوس که سر من برنامه های خاص خود را در این زمینه داشت و در این مقاله سعی خواهم کرد به محبوب ترین سؤالی که در بین افرادی که می خواهند وارد مهندسی آشوب شوند پاسخ دهم: اول چی رو بشکنم؟

سوال عالی! با این حال، به نظر نمی رسد که او به خصوص از این پاندا ناراحت باشد ...

با پانداهای آشوب زده درگیر نشوید!

جواب کوتاه: خدمات حیاتی را در مسیر درخواست هدف قرار دهید.

پاسخ طولانی تر اما واضح تر: برای درک اینکه از کجا شروع به آزمایش هرج و مرج کنید، به سه حوزه توجه کنید:

1. نگاهی به تاریخچه تصادف و شناسایی الگوها؛
2. تصمیم بگیرید وابستگی های بحرانی;
3. به اصطلاح استفاده کنید اثر اعتماد بیش از حد.

خنده دار است، اما این قسمت را می توان به همین راحتی نامید "سفر به سوی خودشناسی و روشنگری". در آن ما شروع به "نواختن" با برخی از سازهای جالب خواهیم کرد.

1. پاسخ در گذشته نهفته است

اگر به خاطر داشته باشید، در قسمت اول مفهوم تصحیح خطاها (COE) را معرفی کردم - روشی که به وسیله آن اشتباهات خود را - اشتباهات در فناوری، فرآیند یا سازمان - تجزیه و تحلیل می کنیم تا علت (ها) آنها را بفهمیم و از آنها جلوگیری کنیم. عود در آینده . به طور کلی، این جایی است که شما باید شروع کنید.

"برای درک حال، باید گذشته را بشناسید." - کارل سیگان

به تاریخچه شکست ها نگاه کنید، آنها را در COE یا پس از مرگ تگ کنید و آنها را طبقه بندی کنید. الگوهای رایجی که اغلب منجر به مشکلات می شوند را شناسایی کنید و برای هر COE سوال زیر را از خود بپرسید:

"آیا می توان این را پیش بینی کرد و بنابراین با تزریق خطا از آن جلوگیری کرد؟"

یک شکست را در اوایل کارم به یاد دارم. اگر چند آزمایش ساده آشفتگی را انجام می دادیم، به راحتی می شد از آن جلوگیری کرد:

در شرایط عادی، نمونه‌های باطنی به بررسی‌های سلامتی پاسخ می‌دهند متعادل کننده بار (ELB)). ELB از این چک‌ها برای هدایت درخواست‌ها به نمونه‌های سالم استفاده می‌کند. وقتی معلوم شد که یک نمونه "ناسالم" است، ELB ارسال درخواست به آن را متوقف می کند. یک روز، پس از یک کمپین بازاریابی موفقیت آمیز، حجم ترافیک افزایش یافت و شرکت های باطله شروع به پاسخ آهسته تر از حد معمول به بررسی های سلامت کردند. باید گفت که این چک های بهداشتی بوده است عمیق، یعنی وضعیت وابستگی ها بررسی شد.

با این حال، برای مدتی همه چیز خوب بود.

سپس، در شرایط نسبتاً استرس زا، یکی از نمونه ها شروع به اجرای یک کار غیر بحرانی و منظم ETL cron کرد. ترکیبی از ترافیک بالا و cronjob استفاده از CPU را به تقریبا 100٪ رساند. اضافه بار CPU باعث کاهش بیشتر پاسخ به بررسی های سلامتی شد، به طوری که ELB تصمیم گرفت که نمونه با مشکلات عملکردی مواجه است. همانطور که انتظار می رفت، متعادل کننده توزیع ترافیک به آن را متوقف کرد، که به نوبه خود منجر به افزایش بار روی نمونه های باقی مانده در گروه شد.

ناگهان، تمام موارد دیگر نیز شروع به شکست در بررسی سلامت کردند.

شروع یک نمونه جدید مستلزم دانلود و نصب بسته ها بود و بسیار بیشتر از زمانی که ELB آنها را غیرفعال کرد - یک به یک - در گروه مقیاس خودکار طول کشید. واضح است که به زودی کل فرآیند به نقطه بحرانی رسید و برنامه از کار افتاد.

سپس ما برای همیشه نکات زیر را درک کردیم:

• نصب نرم افزار هنگام ایجاد یک نمونه جدید زمان زیادی می برد؛ بهتر است به رویکرد تغییرناپذیر اولویت داده شود و AMI طلایی.
• در موقعیت‌های پیچیده، پاسخ به بررسی‌های سلامت و ELB باید اولویت داشته باشند - آخرین چیزی که می‌خواهید این است که زندگی را برای نمونه‌های باقی‌مانده پیچیده کنید.
• ذخیره محلی چک های سلامت کمک زیادی می کند (حتی برای چند ثانیه).
• در شرایط دشوار، وظایف cron و سایر فرآیندهای غیر بحرانی را اجرا نکنید - منابع را برای مهمترین وظایف ذخیره کنید.
• هنگام مقیاس خودکار، از نمونه های کوچکتر استفاده کنید. یک گروه 10 نمونه کوچک بهتر از یک گروه 4 تایی بزرگ است. اگر یک نمونه با شکست مواجه شود، در مورد اول 10٪ از ترافیک در 9 نقطه توزیع می شود، در مورد دوم - 25٪ از ترافیک بیش از سه نقطه.

بنابراین، آیا می شد این را پیش بینی کرد و بنابراین با معرفی مشکل از آن جلوگیری کرد؟

بله، و از چند جهت.

ابتدا با شبیه سازی بار بالای CPU با استفاده از ابزارهایی مانند stress-ng یا cpuburn:

❯ stress-ng --matrix 1 -t 60s

استرس زا

ثانیاً، با بارگذاری بیش از حد نمونه با wrk و سایر ابزارهای مشابه:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

آزمایش‌ها نسبتاً ساده هستند، اما می‌توانند غذای خوبی برای فکر کردن بدون نیاز به تحمل استرس ناشی از یک شکست واقعی فراهم کنند.

اما اینجا متوقف نشو. سعی کنید خرابی را در یک محیط آزمایشی تکرار کنید و پاسخ خود را به سوال بررسی کنید "آیا می شد این امر را پیش بینی کرد و بنابراین با معرفی یک عیب از آن جلوگیری کرد؟" این یک آزمایش کوچک آشوب در یک آزمایش آشوب برای آزمایش مفروضات است، اما با شکست شروع می شود.

آیا این یک رویا بود یا واقعاً اتفاق افتاد؟

پس تاریخ شکست ها را مطالعه کنید، تحلیل کنید EOC، آنها را بر اساس "شعاع ضربه" - یا دقیق تر، تعداد مشتریان تحت تأثیر - برچسب گذاری و طبقه بندی کنید و سپس به دنبال الگوها بگردید. از خود بپرسید که آیا می‌توانست با معرفی مشکل، این موضوع را پیش‌بینی کرده و از آن جلوگیری کرد؟ پاسخ خود را بررسی کنید

سپس به رایج ترین الگوها با بیشترین دامنه تغییر دهید.

2. یک نقشه وابستگی بسازید

لحظه ای به برنامه خود فکر کنید. آیا نقشه واضحی از وابستگی های آن وجود دارد؟ آیا می دانید در صورت شکست چه تاثیری خواهند داشت؟

اگر با کد برنامه خود آشنا نیستید یا خیلی بزرگ شده است، درک این که کد چه کار می کند و چه وابستگی هایی دارد دشوار است. درک این وابستگی ها و تأثیر احتمالی آنها بر برنامه کاربردی و کاربران برای دانستن اینکه مهندسی آشوب از کجا باید شروع شود بسیار مهم است: نقطه شروع جزء با بیشترین شعاع ضربه است.

شناسایی و مستندسازی وابستگی ها نامیده می شودساختن یک نقشه وابستگی» (نقشه وابستگی). این معمولاً برای برنامه هایی با پایه کد بزرگ با استفاده از ابزارهای پروفایل کد انجام می شود. (پروفایل کد) و ابزار دقیق (ابزار). همچنین می توانید با نظارت بر ترافیک شبکه یک نقشه بسازید.

با این حال، همه وابستگی ها یکسان نیستند (که این روند را بیشتر پیچیده می کند). مقداری بحرانی، دیگر - ثانوی (حداقل در تئوری، زیرا خرابی ها اغلب به دلیل مشکلات مربوط به وابستگی هایی رخ می دهد که غیر بحرانی در نظر گرفته می شدند).

بدون وابستگی های حیاتی، سرویس نمی تواند کار کند. وابستگی های غیر بحرانی "نباید» برای تحت تاثیر قرار دادن سرویس در صورت سقوط. برای درک وابستگی ها، باید درک روشنی از API های مورد استفاده برنامه خود داشته باشید. این می تواند بسیار دشوارتر از آن چیزی باشد که به نظر می رسد - حداقل برای برنامه های کاربردی بزرگ.

با مرور همه API ها شروع کنید. بیشترین را برجسته کنید قابل توجه و انتقادی. بگیرید وابستگی ها از مخزن کد، آن را بررسی کنید لاگ های اتصال، سپس مشاهده کنید مستندات (البته، اگر وجود داشته باشد - در غیر این صورت هنوز داریدоمشکلات بزرگتر). از ابزار استفاده کنید تا پروفایل و ردیابی، تماس های خارجی را فیلتر کنید.

می توانید از برنامه هایی مانند netstat - یک ابزار خط فرمان که لیستی از تمام اتصالات شبکه (سوکت های فعال) را در سیستم نمایش می دهد. به عنوان مثال، برای لیست کردن تمام اتصالات فعلی، تایپ کنید:

❯ netstat -a | more 

در AWS می توانید استفاده کنید سیاهههای مربوط به جریان (گزارش‌های جریان) VPC روشی است که به شما امکان می‌دهد اطلاعاتی در مورد ترافیک IP که به یا از رابط‌های شبکه در VPC می‌رود جمع‌آوری کنید. چنین گزارش‌هایی همچنین می‌توانند به کارهای دیگر کمک کنند - به عنوان مثال، یافتن پاسخی برای این سؤال که چرا ترافیک خاصی به نمونه نمی‌رسد.

همچنین می توانید استفاده کنید AWS X-Ray. اشعه ایکس به شما امکان می دهد جزئیات، "نهایی" را دریافت کنید (پایان به انتها) مروری بر درخواست‌ها در حین حرکت در برنامه، و همچنین ایجاد نقشه‌ای از اجزای اصلی برنامه. اگر نیاز به شناسایی وابستگی ها دارید بسیار راحت است.

کنسول AWS X-Ray

نقشه وابستگی شبکه تنها یک راه حل جزئی است. بله، نشان می دهد که کدام برنامه با کدام یک ارتباط برقرار می کند، اما وابستگی های دیگری وجود دارد.

بسیاری از برنامه‌ها از DNS برای اتصال به وابستگی‌ها استفاده می‌کنند، در حالی که برخی دیگر ممکن است از کشف سرویس یا حتی آدرس‌های IP سخت‌کد شده در فایل‌های پیکربندی استفاده کنند (مثلاً. /etc/hosts).

به عنوان مثال، شما می توانید ایجاد کنید سیاهچاله DNS با کمک iptables و ببینید چه چیزی می شکند برای این کار دستور زیر را وارد کنید:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

سیاهچاله DNS

اگر در /etc/hosts یا سایر فایل های پیکربندی، آدرس های IP را پیدا خواهید کرد که هیچ چیز در مورد آنها نمی دانید (بله، متأسفانه، این نیز اتفاق می افتد)، می توانید دوباره به کمک بیایید. iptables. فرض کنید شما کشف کردید 8.8.8.8 و نمی دانم که این آدرس سرور DNS عمومی گوگل است. با استفاده از iptables با استفاده از دستورات زیر می توانید ترافیک ورودی و خروجی به این آدرس را مسدود کنید:

❯ 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"

بستن دسترسی

قانون اول همه بسته ها را از DNS عمومی Google حذف می کند: ping کار می کند، اما بسته ها برگردانده نمی شوند. قانون دوم در پاسخ به همه بسته‌های منشأ از سیستم شما به DNS عمومی Google رها می‌کند ping ما گرفتیم عملیات مجاز نیست.

توجه: در این مورد خاص بهتر است استفاده شود whois 8.8.8.8، اما این فقط یک مثال است.

ما می توانیم حتی عمیق تر از سوراخ خرگوش برویم، زیرا هر چیزی که از TCP و UDP استفاده می کند در واقع به IP نیز بستگی دارد. در بیشتر موارد، IP به ARP گره خورده است. فایروال ها را فراموش نکنید...

اگر قرص قرمز را بخوری، در سرزمین عجایب می مانی، و من به تو نشان خواهم داد که سوراخ خرگوش چقدر عمیق است."

یک رویکرد رادیکال تر این است که قطع شدن ماشین ها یکی یکی و ببین چی خرابه... "میمون آشوب" بشی. البته بسیاری از سیستم های تولیدی برای چنین حمله brute force طراحی نشده اند، اما حداقل می توان آن را در یک محیط آزمایشی امتحان کرد.

ساختن یک نقشه وابستگی اغلب یک کار بسیار طولانی است. من اخیراً با مشتری صحبت کردم که تقریباً 2 سال را صرف توسعه ابزاری کرد که به طور نیمه خودکار نقشه های وابستگی را برای صدها میکروسرویس و دستور تولید می کند.

نتیجه اما بسیار جالب و مفید است. شما چیزهای زیادی در مورد سیستم خود، وابستگی ها و عملیات آن خواهید آموخت. باز هم صبور باشید: این خود سفر است که بیشترین اهمیت را دارد.

3. مراقب اعتماد به نفس بیش از حد باشید

«هر کس چه چیزی را در خواب ببیند، به آن ایمان دارد.» - دموستنس

آیا تا به حال شنیده اید اثر اعتماد بیش از حد?

بر اساس ویکی پدیا، تأثیر بیش از حد اعتماد به نفس «یک سوگیری شناختی است که در آن اعتماد فرد به اعمال و تصمیماتش به طور قابل توجهی بیشتر از دقت عینی آن قضاوت‌ها است، به خصوص زمانی که سطح اطمینان نسبتاً بالا باشد».

بر اساس غریزه و تجربه...

در تجربه من، این اعوجاج اشاره بزرگی به این است که مهندسی آشوب را از کجا شروع کنیم.

مراقب اپراتور بیش از حد اعتماد به نفس باشید:

چارلی: "این چیز پنج سال است که سقوط نکرده است، همه چیز خوب است!"
کراش: "صبر کن... من به زودی آنجا خواهم بود!"

سوگیری در نتیجه اعتماد بیش از حد به دلیل عوامل مختلفی که بر آن تأثیر می گذارد، امری موذیانه و حتی خطرناک است. این امر به ویژه زمانی صادق است که اعضای تیم قلب خود را روی یک فناوری ریخته باشند یا زمان زیادی را صرف «تعمیر» آن کرده باشند.

جمع بندی

جستجوی نقطه شروعی برای مهندسی آشوب همیشه نتایجی بیشتر از آنچه انتظار می رفت به ارمغان می آورد و تیم هایی که خیلی سریع شروع به شکستن چیزها می کنند ماهیت جهانی تر و جالب تر (آشوب-) را از دست می دهند.مهندسی - برنامه خلاقانه روش های علمی и شواهد تجربی برای طراحی، توسعه، بهره برداری، نگهداری و بهبود سیستم های (نرم افزار).

این قسمت دوم را به پایان می رساند. لطفاً نظرات خود را بنویسید، نظرات خود را به اشتراک بگذارید یا فقط دست خود را بزنید متوسط. در قسمت بعدی I واقعا من ابزارها و روش هایی را برای معرفی خرابی ها در سیستم ها در نظر خواهم گرفت. تا زمان!

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «مهندسی آشوب: هنر تخریب عمدی. قسمت 1"؛
• «نحوه دستیابی به دسترسی بالا در Kubernetes"؛
• «مانیتورینگ و Kubernetes (بازبینی و گزارش تصویری)"؛
• «آزمایش با kube-proxy و در دسترس نبودن گره در Kubernetes'.

منبع: www.habr.com