ملحوظة. ترجمة.: تتابع هذه المقالة سلسلة ممتازة من المقالات من المبشر التكنولوجي في AWS Adrian Hornsby ، الذي شرع ببساطة ووضوح في شرح أهمية التجارب المصممة للتخفيف من آثار الإخفاقات في أنظمة تكنولوجيا المعلومات.
"إذا فشلت في إعداد خطة ، فأنت تخطط للفشل." - بنجامين فرانكلين
В في هذه السلسلة من المقالات ، قدمت مفهوم هندسة الفوضى وشرحت كيف تساعد في اكتشاف العيوب في النظام وإصلاحها قبل أن تؤدي إلى فشل الإنتاج. كما تمت مناقشة كيف تساهم هندسة الفوضى في التغيير الثقافي الإيجابي داخل المنظمات.
في نهاية الجزء الأول ، وعدت بالحديث عن "أدوات وطرق إدخال الإخفاقات في الأنظمة". للأسف ، كان لدى رأسي خطط خاصة به في هذا الصدد ، وفي هذه المقالة سأحاول الإجابة على السؤال الأكثر شيوعًا الذي يطرح نفسه للأشخاص الذين يرغبون في القيام بهندسة الفوضى: ما يجب كسره أولا؟
سؤال رائع! ومع ذلك ، لا يبدو أن هذا الباندا قلق بشكل خاص ...
لا تعبث مع فوضى الباندا!
اجابة قصيرة: استهداف الخدمات الهامة على طول مسار الطلب.
إجابة طويلة ولكن أكثر وضوحا: لفهم من أين تبدأ تجربة الفوضى ، انتبه لثلاثة مجالات:
- النظر في تاريخ الحادث وتحديد الأنماط ؛
- اتخاذ قرار بشأن التبعيات الحرجة;
- استخدم ما يسمى ب. تأثير الثقة المفرطة.
إنه أمر مضحك ، ولكن يمكن أيضًا تسمية هذا الجزء "رحلة إلى معرفة الذات والتنوير". في ذلك ، سنبدأ في "اللعب" ببعض الآلات الرائعة.
1. الجواب يكمن في الماضي
إذا كنت تتذكر ، فقد قدمت في الجزء الأول مفهوم تصحيح الأخطاء (COE) - الطريقة التي نحلل بها أخطائنا: الأخطاء في التكنولوجيا أو العملية أو المنظمة - من أجل فهم سببها (أسبابها) ومنعها تكرار في المستقبل. بشكل عام ، هذا هو المكان الذي يجب أن تبدأ منه.
"لفهم الحاضر ، عليك أن تعرف الماضي". - كارل ساجان
انظر إلى سجل العطل ، وقم بوضع علامة على المعدات المملوكة للوحدات أو عمليات تشريح الجثة وصنفها. حدد الأنماط الشائعة التي غالبًا ما تؤدي إلى مشاكل ، ولكل دولة مملوكة للدولة ، اسأل نفسك السؤال التالي:
"هل كان من الممكن توقعه ، وبالتالي منعه ، من خلال إحداث عطل؟"
أتذكر فشلًا واحدًا في بداية مسيرتي المهنية. يمكن منعه بسهولة إذا أجرينا تجربتين بسيطتين للفوضى:
في ظل الظروف العادية ، تستجيب النسخ الخلفية للفحوصات الصحية من ). يستخدم ELB هذه الفحوصات لإعادة توجيه الطلبات إلى الطبعات "السليمة". عندما يتضح أن حالة معينة "غير صحية" ، تتوقف ELB عن إرسال الطلبات إليها. في أحد الأيام ، بعد حملة تسويقية ناجحة ، زاد حجم حركة المرور ، وبدأت الخلفيات في الاستجابة للفحوصات الصحية بشكل أبطأ من المعتاد. يجب أن يقال أن هذه الفحوصات الصحية كانت ، وهذا يعني أنه تم فحص حالة التبعيات.
ومع ذلك ، لفترة من الوقت كان كل شيء على ما يرام.
بعد ذلك ، في ظل ظروف مرهقة إلى حد ما ، بدأت إحدى الحالات في أداء مهمة cron غير حرجة ومنتظمة من فئة ETL. أدى الجمع بين حركة المرور العالية و cronjob إلى تعزيز استخدام وحدة المعالجة المركزية بنسبة 100٪ تقريبًا. أدى الحمل الزائد على المعالج إلى إبطاء الاستجابات لفحوصات الصحة بشكل أكبر - لدرجة أن ELB قرر أن المثيل يواجه مشاكل في التشغيل. كما هو متوقع ، توقف الموازن عن توزيع حركة المرور عليه ، مما أدى بدوره إلى زيادة الحمل على باقي المثيلات في المجموعة.
فجأة ، بدأت جميع الحالات الأخرى أيضًا في فشل الفحص الصحي.
تطلب بدء مثيل جديد تنزيل الحزم وتثبيتها ، واستغرق الأمر وقتًا أطول بكثير مما استغرقه ELB لإغلاقها - واحدة تلو الأخرى - في مجموعة أداة القياس التلقائي. من الواضح أن العملية برمتها سرعان ما وصلت إلى نقطة حرجة وسقط التطبيق.
ثم أوضحنا أخيرًا النقاط التالية:
- يستغرق تثبيت البرنامج وقتًا طويلاً عند إنشاء مثيل جديد ، فمن الأفضل إعطاء الأفضلية للنهج الثابت و .
- في المواقف الصعبة ، يجب أن يكون للردود على الفحوصات الصحية و ELBs الأسبقية - آخر شيء تريد القيام به هو جعل الحياة صعبة بالنسبة للحالات المتبقية.
- يساعد التخزين المؤقت المحلي للفحوصات الصحية كثيرًا (حتى لبضع ثوان).
- في المواقف الصعبة ، لا تقم بتشغيل مهام cron وغيرها من العمليات غير الحرجة - وفر الموارد لأهم المهام.
- استخدم حالات أصغر عند القياس التلقائي. مجموعة من 10 عينات صغيرة أفضل من 4 عينات كبيرة ؛ إذا فشل أحد الأمثلة ، في الحالة الأولى ، سيتم توزيع 10٪ من حركة المرور على 9 نقاط ، وفي الحالة الثانية ، سيتم توزيع 25٪ من الحركة على ثلاث نقاط.
وهكذا، هل كان من الممكن توقعه ، وبالتالي منعه ، من خلال إدخال المشكلة؟
نعم وبعدة طرق.
أولاً ، من خلال محاكاة الاستخدام العالي لوحدة المعالجة المركزية باستخدام أدوات مثل أو :
❯ stress-ng --matrix 1 -t 60s
الإجهاد نانوغرام
ثانيًا ، عن طريق التحميل الزائد للمثيل بـ والمرافق المماثلة الأخرى:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
التجارب بسيطة نسبيًا ، ولكنها يمكن أن توفر بعض الطعام الجيد للفكر دون الاضطرار إلى المرور بضغوط الفشل الحقيقي.
لكن لا تتوقف عند هذا الحد. حاول إعادة إنتاج الفشل في بيئة اختبار وتحقق من إجابتك على السؤال "هل كان من الممكن توقع ذلك ، وبالتالي منعه بإحداث عطل؟". هذه تجربة فوضى صغيرة ضمن تجربة فوضى لاختبار الافتراضات ، ولكن تبدأ بانهيار.
هل كان حلما أم أنه حدث بالفعل؟
لذا ادرس تاريخ الإخفاقات وحللها EOC، وضع علامة عليها وتصنيفها حسب "نصف قطر تأثيرها" - أو بشكل أكثر تحديدًا ، حسب عدد العملاء المتأثرين - ثم ابحث عن الأنماط. اسأل نفسك عما إذا كان من الممكن توقع ذلك ومنعه من خلال تقديم المشكلة. تحقق من إجابتك.
ثم قم بالتبديل إلى الأنماط الأكثر شيوعًا ذات نصف قطر الضرر الأكبر.
2. بناء خريطة التبعية
خذ لحظة للتفكير في طلبك. هل هناك خريطة واضحة لتوابعها؟ هل تعرف ما هو تأثيرهم في حالة الفشل؟
إذا لم تكن معتادًا على كود التطبيق الخاص بك ، أو إذا كان التطبيق الخاص بك قد نما بشكل كبير جدًا ، فقد يكون من الصعب فهم ما يفعله الكود وما هي تبعياته. يعد فهم هذه التبعيات وتأثيرها المحتمل على التطبيق والمستخدمين أمرًا بالغ الأهمية لفهم مكان بدء هندسة الفوضى: نقطة البداية هي المكون ذي التأثير الأكبر.
يشار إلى تحديد التبعيات وتوثيقها باسم "بناء خريطة التبعية» (تعيين التبعية). يتم إجراؤه عادةً على التطبيقات ذات قاعدة التعليمات البرمجية الكبيرة باستخدام أدوات تحديد ملفات تعريف التعليمات البرمجية. (التنميط رمز) والأجهزة (الأجهزة). يمكنك أيضًا إنشاء خريطة من خلال مراقبة حركة مرور الشبكة.
ومع ذلك ، ليست كل التبعيات هي نفسها (مما يزيد العملية تعقيدًا). بعض شديد الأهمية، آخر - ثانوي (على الأقل من الناحية النظرية ، نظرًا لأن الأعطال غالبًا ما تكون بسبب مشكلات التبعية التي تم اعتبارها غير حرجة).
بدون التبعيات الحرجة ، لا يمكن للخدمة أن تعمل. التبعيات غير الحرجةلا ينبغي»لها تأثير على الخدمة في حال سقوطها. للتعامل مع التبعيات ، يجب أن يكون لديك فهم واضح لواجهات برمجة التطبيقات التي يستخدمها التطبيق. قد يكون هذا أكثر صعوبة مما يبدو - على الأقل بالنسبة للتطبيقات الكبيرة.
ابدأ بالتكرار على جميع واجهات برمجة التطبيقات. تسليط الضوء على أكثر من غيرها مهم وحاسم. يأخذ اعتمادا على من مستودع الكود ، استكشف سجلات الاتصال، ثم اعرض الوثائق (بالطبع ، إذا كان موجودًا - وإلا فلا يزال لديكоمشاكل أكبر). استخدم الأدوات ل التنميط والتعقب، تصفية المكالمات الخارجية.
يمكنك استخدام برامج مثل netstat - أداة سطر أوامر تعرض قائمة بجميع اتصالات الشبكة (المقابس النشطة) في النظام. على سبيل المثال ، لسرد جميع الاتصالات الحالية ، اكتب:
❯ netstat -a | more
على AWS ، يمكنك استخدام ملفات (سجلات التدفق) VPC هي طريقة تسمح لك بجمع معلومات حول حركة مرور IP التي تذهب إلى أو من واجهات الشبكة في VPC. يمكن أن تساعد هذه السجلات أيضًا في مهام أخرى ، مثل العثور على إجابة للسؤال عن سبب عدم وصول حركة مرور معينة إلى المثيل.
تستطيع ايضا استخذام . يسمح لك X-Ray بالحصول على تقرير تفصيلي "نهائي" (من طرف إلى طرف) نظرة عامة على الطلبات أثناء انتقالها عبر التطبيق ، كما أنها تنشئ خريطة للمكونات الأساسية للتطبيق. مفيد جدًا إذا كنت بحاجة إلى تحديد التبعيات.
وحدة تحكم AWS X-Ray
تعد خريطة تبعية الشبكة حلاً جزئيًا فقط. نعم ، يُظهر التطبيق الذي يتواصل معه ، ولكن هناك تبعيات أخرى.
تستخدم العديد من التطبيقات DNS للاتصال بالتبعية ، بينما قد يستخدم البعض الآخر اكتشاف الخدمة أو حتى عناوين IP المشفرة في ملفات التكوين (على سبيل المثال ، في /etc/hosts).
على سبيل المثال ، يمكنك إنشاء ملفات من خلال 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 العام لـ Google. باستخدام 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. لا تنس جدران الحماية ...
خذ الحبة الحمراء وابق في بلاد العجائب وسأوضح لك مدى عمق حفرة الأرانب ".
نهج أكثر راديكالية هو قطع الاتصال آلات واحدة تلو الأخرى وانظر ما هو مكسور ... أصبح "قرد الفوضى". بالطبع ، لم يتم تصميم العديد من أنظمة الإنتاج لمثل هذا الهجوم الغاشم ، ولكن على الأقل يمكن تجربتها في بيئة اختبار.
غالبًا ما يكون بناء خريطة التبعية مهمة طويلة جدًا. لقد تحدثت مؤخرًا مع عميل قضى ما يقرب من عامين في تطوير أداة تنشئ خرائط تبعية بشكل شبه تلقائي لمئات الخدمات والأوامر الصغيرة.
النتيجة ، مع ذلك ، مثيرة للاهتمام ومفيدة للغاية. سوف تتعلم الكثير عن نظامك وتبعياته وعملياته. مرة أخرى ، تحلى بالصبر: الرحلة نفسها هي الأكثر أهمية.
3. احذر من الإفراط في الثقة
"من يحلم بشيء فهو يؤمن به". - ديموسثينيس
هل سمعت من قبل عن تأثير الثقة المفرطة?
وفقًا لـ Wikipedia ، فإن تأثير الثقة المفرطة هو "تحيز معرفي تكون فيه ثقة الشخص في أفعاله وقراراته أكبر بكثير من الدقة الموضوعية لتلك الأحكام ، خاصة عندما يكون مستوى الثقة مرتفعًا نسبيًا."
بناء على الحدس والخبرة ...
من واقع خبرتي ، فإن هذا التشويه هو إشارة عظيمة إلى أين تبدأ هندسة الفوضى.
احذر من عامل الثقة المفرط:
تشارلي: "هذا الشيء لم يُسقط منذ خمس سنوات ، كل شيء على ما يرام!"
خلل: "انتظر ... سأكون هناك قريبًا!"
التحيز نتيجة الثقة بالنفس هو شيء ماكر بل وخطير بسبب العوامل المختلفة التي تؤثر عليه. هذا صحيح بشكل خاص عندما يضع أعضاء الفريق قلوبهم وأرواحهم في تقنية معينة أو يقضون الكثير من الوقت في "الإصلاحات".
تلخيص لما سبق
دائمًا ما يجلب البحث عن نقطة بداية لهندسة الفوضى نتائج أكثر مما كان متوقعًا ، والفرق التي تبدأ في كسر كل شيء بسرعة كبيرة جدًا تغفل عن الجوهر الأكثر عالمية وإثارة للاهتمام (الفوضى)هندسة - تطبيق إبداعي الأساليب العلمية и دليل تجريبي لتصميم أنظمة (برمجيات) وتطويرها وتشغيلها وصيانتها وتحسينها.
هذا يختتم الجزء الثاني. يرجى كتابة التعليقات أو مشاركة الآراء أو مجرد التصفيق . في الجزء التالي أنا حقا سأفكر في الأدوات والأساليب لإدخال الأعطال في الأنظمة. حتى!
PS من المترجم
اقرأ أيضًا على مدونتنا:
- «"؛
- «"؛
- «"؛
- «".
المصدر: www.habr.com