تقريبا. العابرة. : تستمر هذه المادة في سلسلة رائعة من المقالات من المبشر بتقنية AWS أدريان هورنسبي ، الذي شرع في شرح أهمية التجارب المصممة لتخفيف عواقب الإخفاقات في أنظمة تكنولوجيا المعلومات بكل بساطة ووضوح.
"إذا فشلت في إعداد الخطة ، فأنت تخطط للفشل". - بنيامين فرانكلين
في
الجزء الأول من هذه السلسلة من المقالات ، قمت بتقديم مفهوم هندسة الفوضى وشرحت كيف يساعد في العثور على وإصلاح العيوب في النظام قبل أن تؤدي إلى تعطل الإنتاج. كما تحدث عن كيفية مساهمة هندسة الفوضى في التغيير الثقافي الإيجابي داخل المنظمات.
في نهاية الجزء الأول ، وعدت بالحديث عن "الأدوات والأساليب لإدخال الإخفاقات في الأنظمة". للأسف ، كان لدى رأسي خطط خاصة به في هذا الصدد ، وسأحاول في هذه المقالة الإجابة على السؤال الأكثر شيوعًا الذي يطرحه الأشخاص الذين يرغبون في الانخراط في هندسة الفوضى:
ما الذي يجب أن نضعه أولاً؟ سؤال رائع! ومع ذلك ، لا يبدو أنه يهتم بهذه الباندا ...
لا تعبث مع فوضى الباندا!إجابة مختصرة : الهدف من الخدمات الحرجة على مسار الطلب.
إجابة طويلة ولكنها أكثر وضوحًا : لفهم من أين تبدأ تجارب الفوضى ، انتبه إلى ثلاثة مجالات:
- انظر إلى تاريخ الإخفاقات وحدد الأنماط ؛
- اتخاذ قرار بشأن التبعيات الحرجة ؛
- استخدم ما يسمى. تأثير الإفراط في الثقة .
إنه أمر مضحك ، ولكن يمكن تسمية هذا الجزء بنفس النجاح
"رحلة إلى معرفة الذات والتنوير" . في ذلك ، سنبدأ في "اللعب" مع بعض الأدوات الرائعة.
1. الجواب يكمن في الماضي
إذا كنت تتذكر ، فقد قدمت في الجزء الأول مفهوم تصحيح الأخطاء (COE) - الطريقة التي نحلل بها أخطاءنا: الأخطاء في التكنولوجيا أو العملية أو المنظمة - لفهم سببهم (أسبابهم) ومنع التكرار في المستقبل. . بشكل عام ، يجب أن يبدأ هذا.
"لفهم الحاضر ، تحتاج إلى معرفة الماضي." - كارل ساجان
إلقاء نظرة على تاريخ الإخفاقات ، ووضع العلامات في الشركات المملوكة للدولة أو ما بعد الوفاة وتصنيفها. حدد الأنماط الشائعة التي تؤدي غالبًا إلى حدوث مشكلات ، ولكل حالة من الطرق المملوكة للدولة اسأل نفسك السؤال التالي:
"هل كان من الممكن توقع ذلك ، وبالتالي تمنعه من حدوث خلل؟"أتذكر فشل واحد في بداية مسيرتي المهنية. كان من الممكن الوقاية منه بسهولة إذا كان لدينا بعض التجارب البسيطة للفوضى:
في الظروف العادية ، تستجيب مثيلات الخلفية للفحوصات الصحية من موازن الحمل (ELB ). يستخدم ELB هذه الاختبارات لإعادة توجيه الطلبات إلى الحالات الصحية. عندما يتبين أن مثيلًا معينًا "غير صحي" ، يتوقف ELB عن إرسال الطلبات إليه. مرة واحدة ، بعد حملة تسويقية ناجحة ، زاد حجم حركة المرور ، وبدأت الواجهة الخلفية في الاستجابة للفحوصات الصحية بشكل أبطأ من المعتاد. يجب أن يقال إن هذه الفحوصات الصحية كانت عميقة ، أي أنه تم فحص حالة التبعيات.
ومع ذلك ، لفترة من الوقت كان كل شيء في النظام.
ثم ، في ظروف مرهقة بالفعل ، بدأت واحدة من الحالات في أداء مهمة cron غير انتقادية من فئة ETL. مزيج من حركة المرور العالية و cronjob حفزت استخدام وحدة المعالجة المركزية بنسبة 100 ٪ تقريبا. أدى التحميل الزائد للمعالج إلى إبطاء الاستجابات للفحوصات الصحية بدرجة أكبر - لدرجة أن ELB قرر أن المثيل يعاني من مشكلات. كما هو متوقع ، توقف الموازن عن توزيع حركة المرور عليه ، مما أدى بدوره إلى زيادة الحمل على الحالات المتبقية في المجموعة.
فجأة ، بدأت جميع الحالات الأخرى بالفشل في الفحص الصحي.
يتطلب تشغيل مثيل جديد تنزيل الحزم وتثبيتها واستغرق وقتًا أطول بكثير مما استغرقه ELB لفصلها - واحدة تلو الأخرى - في مجموعة autoscale. من الواضح أن العملية بأكملها سرعان ما وصلت إلى نقطة حرجة وسقط التطبيق.
ثم فهمنا إلى الأبد النقاط التالية:
- لتثبيت البرنامج عند إنشاء مثيل جديد لفترة طويلة ، من الأفضل إعطاء الأفضلية للنهج الثابت و Golden AMI .
- في المواقف الصعبة ، يجب أن تكون الاستجابات للفحوصات الصحية و ELBs لها الأولوية - آخر شيء تريد القيام به هو جعل الحياة صعبة للحالات المتبقية.
- التخزين المؤقت المحلي للفحوصات الصحية (حتى لبضع ثوان) يساعد كثيرا.
- في المواقف الصعبة ، لا تقم بتشغيل مهام cron وغيرها من العمليات غير الحرجة - وفر الموارد لأهم المهام.
- عند الفحص الذاتي ، استخدم مثيلات أصغر. مجموعة من 10 نسخ صغيرة أفضل من 4 نسخ كبيرة ؛ إذا سقطت حالة واحدة ، في الحالة الأولى سيتم توزيع 10 ٪ من حركة المرور عبر 9 نقاط ، في الثانية - 25 ٪ من حركة المرور عبر ثلاث نقاط.
لذلك ، هل
يمكن توقع ذلك ، وبالتالي منعه عن طريق إدخال المشكلة؟نعم وبطرق متعددة.
أولاً ، من خلال محاكاة استخدام وحدة المعالجة المركزية عالية مع أدوات مثل
stress-ng أو
cpuburn :
❯ stress-ng --matrix 1 -t 60s
الإجهاد نانوغرامثانياً ، التحميل الزائد للمثيل باستخدام
wrk والأدوات المساعدة الأخرى المشابهة:
❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health
التجارب بسيطة نسبيًا ، لكنها يمكن أن توفر طعامًا جيدًا للتفكير دون الحاجة إلى تجربة ضغوط الفشل الحقيقي.
ومع ذلك ،
لا تتوقف عند هذا الحد . حاول إعادة إنتاج الفشل في بيئة اختبار وتحقق من إجابتك على السؤال "
هل كان من الممكن توقع ذلك ، وبالتالي تمنعه عن طريق إدخال عطل؟" ". هذه تجربة فوضى صغيرة داخل تجربة فوضى لاختبار الافتراضات ، ولكن البدء بالفشل.
هل كان حلما ، أم أنه حدث بالفعل؟لذا قم بدراسة تاريخ الإخفاقات ، وتحليل
المعدات المملوكة للوحدات ، ووضع علامة عليها وتصنيفها وفقًا لـ "نصف قطر الضرر" - أو بشكل أكثر دقة ، وفقًا لعدد العملاء المتأثرين - ثم ابحث عن الأنماط. اسأل نفسك عما إذا كان من الممكن توقع ذلك ومنع حدوثه من خلال تقديم المشكلة. تحقق إجابتك.
ثم انتقل إلى الأنماط الأكثر شيوعًا مع أكبر مجموعة.
2. بناء خريطة التبعية
نتوقف لحظة للتفكير في طلبك. هل هناك خريطة واضحة تبعياتها؟ هل تعرف ما هو تأثيرها في حالة الفشل؟
إذا لم تكن معتادًا على رمز التطبيق الخاص بك أو أصبح كبيرًا جدًا ، فقد يكون من الصعب فهم ما تقوم به الشفرة وما هي تبعياتها. يعد فهم هذه التبعيات وتأثيرها المحتمل على التطبيق والمستخدمين أمرًا مهمًا لفهم من أين تبدأ هندسة الفوضى: سيكون المكون الذي يتمتع بأكبر دائرة نصف قطرها نقطة الانطلاق.
يُعرف تعريف وتوثيق التبعيات "
تعيين التبعية ". عادة ما يتم تنفيذه للتطبيقات ذات قاعدة الشفرة واسعة النطاق باستخدام أدوات
لشفرة التعليمات البرمجية والأجهزة. يمكنك أيضًا إنشاء خرائط من خلال مراقبة حركة مرور الشبكة.
ومع ذلك ، ليست كل التبعيات هي نفسها (مما يزيد من تعقيد العملية). بعضها
مهم ، والبعض الآخر
ثانوي (على الأقل من الناحية النظرية ، لأن الأعطال غالباً ما تنتج عن مشكلات التبعية التي تعتبر غير حرجة) .
بدون التبعيات الحرجة ، لا يمكن أن تعمل الخدمة. التبعيات غير الحرجة "
لا ينبغي "
أن يكون لها تأثير على الخدمة في حالة السقوط. للتعامل مع التبعيات ، يجب أن يكون لديك فهم واضح لواجهة برمجة التطبيقات التي يستخدمها التطبيق. يمكن أن يكون الأمر أكثر تعقيدًا مما يبدو - على الأقل بالنسبة للتطبيقات الكبيرة.
ابدأ بالفرز عبر جميع واجهات برمجة التطبيقات. تسليط الضوء على أهم
وأهم . خذ
التبعيات من مستودع الشفرة ، وفحص
سجلات الاتصال ، ثم استعرض
الوثائق (بالطبع ، إذا كانت موجودة ، وإلا فستواجه المزيد من المشكلات). استخدم الأدوات الخاصة
بالتوصيف والتعقب وتصفية المكالمات الخارجية.
يمكنك استخدام برامج مثل
netstat ، وهي أداة مساعدة لسطر الأوامر تعرض قائمة بجميع اتصالات الشبكة (مآخذ نشطة) على النظام. على سبيل المثال ، لعرض جميع الاتصالات الحالية ، اكتب:
❯ netstat -a | more
في AWS ، يمكنك استخدام سجلات التدفق VPC - وهي طريقة تسمح لك بجمع معلومات حول حركة مرور IP التي تذهب إلى أو من واجهات الشبكة على VPCs. يمكن أن تساعد هذه السجلات في المهام الأخرى ، على سبيل المثال ، العثور على إجابة على السؤال حول سبب عدم وصول حركة مرور معينة إلى المثيل.
يمكنك أيضًا استخدام
AWS X-Ray . يتيح لك X-Ray الحصول على نظرة عامة مفصلة "نهاية"
(نهاية إلى نهاية) للطلبات أثناء تقدمها من خلال التطبيق ، وأيضًا إنشاء خريطة للمكونات الأساسية للتطبيق. أنها مريحة للغاية إذا كنت بحاجة إلى تحديد التبعيات.
AWS X-Ray Consoleخريطة تبعية الشبكة ليست سوى حل جزئي. نعم ، يعرض التطبيق الذي يرتبط به ، ولكن هناك تبعيات أخرى.
تستخدم العديد من التطبيقات DNS للاتصال بالتبعيات ، بينما يمكن للآخرين استخدام آلية اكتشاف الخدمة أو حتى عناوين IP ذات الترميز الثابت في ملفات التكوين (على سبيل المثال ، في
/etc/hosts ).
على سبيل المثال ، يمكنك إنشاء
DNS blackhole باستخدام
iptables ومعرفة ما يكسر. للقيام بذلك ، أدخل الأمر التالي:
❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"
بلاك هول DNSإذا وجدت عناوين IP في
/etc/hosts أو ملفات التكوين الأخرى التي لا تعرف شيئًا عنها (نعم ، لسوء الحظ ، يحدث ذلك) ، يمكن أن
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. احذر من الغطرسة
"من يحلم بما يؤمن بذلك". - ديموثينيس
هل سمعت
يومًا بأثر الثقة المفرطة ؟
وفقًا ليكيبيديا ، فإن تأثير الثقة المفرطة هو "تشويه إدراكي تكون فيه ثقة الشخص في تصرفاته وقراراته أعلى بكثير من الدقة الموضوعية لهذه الأحكام ، خاصةً عندما يكون مستوى الثقة مرتفعًا نسبيًا."
بناء على الغريزة والخبرة ...من تجربتي الخاصة ، أستطيع أن أقول إن هذا التشويه يعد تلميحًا كبيرًا حول مكان بدء هندسة الفوضى.
احذر المشغل الواثق من نفسه:
تشارلي: "لم يسقط هذا الشيء منذ حوالي خمس سنوات ، كل شيء على ما يرام!"
الفشل: "انتظر ... سأكون قريباً!"
التحيز نتيجة للثقة بالنفس هو أمر غادر وحتى خطير بسبب عوامل مختلفة تؤثر عليه. هذا صحيح بشكل خاص عندما يضع أعضاء الفريق روحهم في تقنية معينة أو يقضون الكثير من الوقت في "الإصلاحات".
لتلخيص
إن البحث عن نقطة انطلاق لهندسة الفوضى يسفر دائمًا عن نتائج أكثر مما كان متوقعًا ، والفرق التي تبدأ في كسر كل شيء بسرعة تغفل عن الجوهر العالمي الأكثر إثارة للاهتمام
للهندسة (الفوضى) - التطبيق الإبداعي
للطرق العلمية والأدلة التجريبية للتصميم والتطوير وتشغيل وصيانة وتحسين النظم (البرمجيات).
على هذا ، الجزء الثاني يأتي إلى نهايته. يرجى كتابة تعليقات أو مشاركة الآراء أو مجرد التصفيق على يديك.
في الجزء التالي ، سألقي نظرة على الأدوات والتقنيات اللازمة لإدخال إخفاقات في النظام. حتى - وداعا! محدث (19 ديسمبر): أصبحت
ترجمة الجزء الثالث متاحة.
PS من المترجم
اقرأ أيضًا في مدونتنا: