كان اجتماعنا في يونيو في اختبار في الإنتاج مخصصًا لهندسة الفوضى. بدأت مهندسة البرمجيات الرئيسية نورا جونز بكيفية إجراء Netflix للاختبارات في الإنتاج.
هندسة الفوضى ... هذه تجارب في الإنتاج للعثور على نقاط الضعف في النظام قبل أن تجعل الخدمة غير مناسبة للعملاء. في Netflix ، نديرها باستخدام أداة تسمى ChAP ... [هي] تكتشف نقاط الضعف وتسمح لنا بتنفيذ حالات الفشل في الخدمات والإنتاج. تؤكد هذه الإخفاقات الافتراضات حول هذه الخدمات قبل أن تؤدي إلى انقطاع كامل ".
شاهد عرضًا تقديميًا (أو اقرأ النص) حول كيفية مساعدة فريقها للمستخدمين - مهندسي Netflix - في الاختبار بأمان في الإنتاج وتحديد نقاط الضعف في أنظمتهم.
فك التشفير
أنا سعيد لوجودي هنا اليوم.
تستخدم Netflix بنشاط الاختبارات في الإنتاج. نحن نقوم بذلك من خلال هندسة الفوضى ، وقمنا مؤخراً بإعادة تسمية فريقنا Resiliance Engineering [التنمية المستدامة] لأن هندسة الفوضى هي إحدى الطرق لتحقيق الاستدامة الشاملة. أنا على وشك الحديث عن هذا اليوم.
هدفنا هو زيادة وقت التشغيل من خلال البحث الاستباقي عن نقاط الضعف في الخدمات. نقوم بذلك من خلال التجارب في الإنتاج. الفريق واثق من أنه يمكن الكشف عن فئة معينة من نقاط الضعف والمشاكل فقط على حركة المرور الحقيقية.
بادئ ذي بدء ، يجب أن تهتم بالأمن والمراقبة ، وإلا فلن تتمكن من نشر الاختبارات العادية في الإنتاج. يمكن أن تكون هذه الاختبارات مخيفة: إذا كانت مخيفة ، يجب عليك الاستماع إلى هذا الصوت ومعرفة السبب. ربما لأنه ليس لديك نظام أمان جيد. أو لأنه لا يوجد رصد جيد. في أدواتنا ، نحن نهتم بهذه الأشياء.
إذا قمنا بصياغة هندسة الفوضى في جملة واحدة ، فإن هذا هو نظام التجارب في الإنتاج للعثور على نقاط الضعف في النظام قبل أن تجعل الخدمة غير مناسبة للعملاء. في Netflix ، نقوم بتشغيلها باستخدام أداة تسمى ChAP ، والتي تعني منصة Chaos Automation Platform (منصة Chaos Automation Platform). تقوم ChAP باكتشاف الثغرات الأمنية وتسمح للمستخدمين بتنفيذ حالات الفشل في الخدمات والإنتاج. تؤكد هذه الإخفاقات افتراضات المستخدم حول هذه الخدمات قبل أن تؤدي إلى انقطاع كامل النطاق.
سأخبرك كيف تعمل المنصة على مستوى عال. هذه مجموعة افتراضية من تبعيات الخدمات الصغيرة. هناك وكيل معين. يرسل طلبًا إلى الخدمة A ، والتي تختلف بعد ذلك عن المعجبين للخدمات B و C و D ، ولا يزال هناك مستوى من الثبات. تصل الخدمة D إلى Cassandra ، ثم تصل الخدمة B إلى ذاكرة التخزين المؤقت.
أسرع إلى الأمام وأوجز كل شيء ، لأن الجوهر يبدأ أكثر. نريد أن نتأكد من أن الخدمة D قوية ضد فشل التخزين المؤقت. يدخل المستخدم إلى واجهة ChAP ويختار الخدمة D كخدمة تراقب فشل ذاكرة التخزين المؤقت وخدمة الفشل. يقوم ChAP بالفعل بنسخ الخدمة B إلى نسختين. نستخدمها للتحكم في المجموعات التجريبية: بطريقة ما تعمل مثل اختبارات A / B أو اختبارات الكناري. هذه النسخ المتماثلة أصغر بكثير من الخدمة ب. نحن نرسل فقط نسبة صغيرة جدًا جدًا من العملاء إلى هذه المجموعات لأنه من الواضح أننا لا نريد فشلًا تامًا. نحن نحسب هذه النسبة المئوية بناءً على العدد الحالي للمستخدمين الذين يستخدمون الخدمة في الوقت الحالي.
ثم يوجه ChAP نظام تجاوز الفشل للإبلاغ عن الطلبات التي تطابق معاييرنا. يتم ذلك عن طريق إضافة معلومات إلى رؤوس الطلبات. يتم إنشاء مجموعتين من العلامات. في المجموعة الأولى من التعليمات الخاصة بالفشل والتوجيه إلى النسخة المتماثلة للكناري ، وفي الثانية - فقط الإرشادات الخاصة بالتوجيه إلى عنصر المراقبة.
عندما يتلقى عميل RPC والخدمة A الإرشادات اللازمة لتوجيه الطلب ، فعليهما توجيه حركة المرور إلى مجموعة المراقبة أو مجموعة التجارب. ثم ، يرى نظام تنفيذ الفشل على مستوى RPC للمجموعة التجريبية أن الطلب تم وضع علامة على الفشل ، ويعيد استجابة فاشلة. كما كان من قبل ، ستنفذ المجموعة التجريبية كودًا للتعامل مع الفشل كاستجابة غير ناجحة من ذاكرة التخزين المؤقت. نفعل ذلك على افتراض أنه متسامح مع الخطأ ، أليس كذلك؟ لكن في بعض الأحيان نرى أن الأمر ليس كذلك. من وجهة نظر الخدمة أ ، يبدو كل شيء وكأنه سلوك عادي.
نحن نتحكم بعناية في هندسة الفوضى ، والتي يمكن أن تسير بشكل سيئ للغاية. عندما بدأت Netflix هذه التجارب لأول مرة ، لم يكن لدينا نظام تحكم جيد. أطلقنا خللًا صناعيًا وجلسنا في الغرفة ، وتقاطع الأصابع وتحقق من أن كل شيء يعمل بشكل جيد. الآن لدينا المزيد من الاهتمام بالأمن.
نحن ننظر إلى مقاييس الأعمال الرئيسية. واحد منهم يسمى SPS (يبدأ البث في الثانية) ، أي يبدأ دفق الفيديو في الثانية. إذا كنت تفكر في ما هو الأهم بالنسبة إلى أعمال Netflix ، فإنه يمكن للمستخدمين تشغيل أي مسلسل في أي وقت يريدون.
في الرسوم البيانية ترى تجربة حقيقية. ويبين الفرق في SPS بين المجموعات التجريبية والضابطة أثناء الاختبار. يمكنك ملاحظة أن الرسوم البيانية تنحرف بشكل كبير عن بعضها البعض ، وهذا لا ينبغي أن يحدث ، لأن نفس النسبة المئوية من الزيارات يتم إرسالها إلى كلا المجموعتين.
لهذا السبب ، يستخدم الاختبار تحليل الكناري الآلي. يعطي إشارة إلى أن الرسوم البيانية جدًا تنحرف بشكل كبير عن بعضها البعض. في هذه الحالة ، يتم مقاطعة الاختبار على الفور حتى يتمكن الأشخاص من العمل بشكل طبيعي مع الموقع. من وجهة نظر المستخدم ، يشبه هذا خلل قصير المدى عند حدوث ذلك.
لدينا العديد من العلاجات الأخرى. نحن نحد من حجم زيارات الاختبار في كل منطقة ، لذلك لا نجري التجربة إلا في منطقة West West الأمريكية. ونقوم بها في كل مكان ونحد من عدد التجارب التي يمكن إجراؤها في المنطقة في كل مرة. لا تجتاز الاختبارات إلا خلال ساعات العمل ، لذلك لن نوقظ المهندسين إذا حدث خطأ ما. إذا فشل الاختبار ، فلا يمكن بدء تشغيله تلقائيًا مرة أخرى حتى يقوم شخص ما بتصحيحه يدويًا ويؤكد: "مرحبًا ، أعلم أن الاختبار لم ينجح ، لكنني أصلحت كل ما هو مطلوب".
من الممكن تطبيق خصائص مخصصة على الكتل. هذا مفيد إذا تم تقسيم الخدمة إلى أجزاء ، مثل العديد من خدمات Netflix. بالإضافة إلى ذلك ، يمكنك تنفيذ حالات الفشل بناءً على نوع الجهاز. إذا افترضنا وجود أي مشاكل على أجهزة Apple أو نوع معين من التلفزيون ، فيمكننا إجراء اختبارات خاصة بهم.
وجد ChAP العديد من الأخطاء. هذه واحدة من مفضلاتي لقد أجرينا تجربة للتحقق من مسار النسخ الاحتياطي للخدمة ، وهو أمر حاسم لتوافرها ، وحددنا خطأ هناك. تم حل المشكلة قبل أن تؤدي إلى حادثة توفر الخدمة. هذه حالة مثيرة للاهتمام حقًا ، لأنه لم يتم تنفيذ مسار النسخ الاحتياطي هذا كثيرًا. لذلك ، لم يكن المستخدم يعرف حقًا ما إذا كان يعمل بشكل صحيح ، وتمكننا من تقليده. لقد تسببنا في الواقع في فشل الخدمة وتحققنا مما إذا كانت قد انحرفت وإذا كانت تعمل بشكل صحيح. في هذه الحالة ، اعتقد المستخدم أن خدمته كانت غير حرجة أو ثانوية ، ولكنها في الواقع كانت خدمة حرجة.
هنا مثال آخر. أجرينا تجربة لإعادة إظهار المشكلة أثناء عملية التسجيل ، والتي ظهرت ليلاً على بعض الخوادم. حدث شيء غريب مع الخدمة. تم تكرار المشكلة بعد إدخال تأخير قدره 500 مللي ثانية. أثناء الاختبار ، تم العثور على المشكلة في السجلات التي تم تحميلها على بوابة البيانات الكبيرة. وقد ساعد ذلك على فهم سبب عدم نجاح التسجيل في بعض الحالات. فقط بفضل تجربة ChAP نجحنا في معرفة ما كان يحدث ولماذا.
يتطلب تكوين اختبار ChAP الكثير من المعلومات. نحن بحاجة إلى معرفة النقاط المناسبة لإدخال الأخطاء. يجب أن تحدد الفرق ما إذا كانت تريد التعطل أو التأخير. كل هذا يتوقف على نقطة الحقن. يمكنك تعطل Cassandra أو Hystrix (نظام النسخ الاحتياطي لدينا) أو خدمة RPC أو عميل RPC أو S3 أو SQS أو ذاكرة التخزين المؤقت لدينا ، أو إضافة تأخير من بينها. أو قم بكليهما. يمكنك أيضًا التوصل إلى مجموعات من التجارب المختلفة.
ما عليك القيام به هو الالتقاء بفريق خدمة والتوصل إلى اختبار جيد. سوف يستغرق الكثير من الوقت. عند إعداد تجربة ، يجب عليك أيضًا تحديد تكوينات ACA (تحليل الكناري الآلي) أو تكوينات الكناري التلقائية.
كان لدينا بعض تكوينات ACA الجاهزة. كان هناك تكوين ChAP واحد لـ SPS. كان هناك واحد مع مؤشرات نظام المراقبة. واحد آخر فحص أعطال RPS. شخص آخر تأكد من أن خدمتنا تعمل بشكل جيد بالفعل وتنفذ الأخطاء بشكل صحيح. لقد أدركنا أن تصميم الاختبار يمكن أن يستغرق وقتًا طويلاً ، وهكذا حدث. لم يتم إنشاء العديد من الاختبارات. من الصعب على الشخص أن يضع في اعتباره كل ما هو مطلوب لتجربة جيدة. قررنا أتمتة شيء ما مع ChAP. نظرنا إلى المؤشرات: أين ومن أين تذهب المكالمات ، الملفات ذات المهلات ، المكالمات المتكررة. أصبح من الواضح أن جميع المعلومات تأتي من أماكن مختلفة. كان من الضروري تجميعه.
قمنا بتحجيم التحليل إلى مستوى ChAP ، حيث يكون أكثر ملاءمة للعمل مع المعلومات ويمكنك استخدام Monocle. الآن يمكن دراسة جميع المعلومات حول التطبيق والكتلة في مكان واحد. هنا ، يمثل كل سطر تبعية ، وتمثل هذه التبعيات أرضًا خصبة لتجارب هندسة الفوضى.
لقد جمعنا جميع المعلومات في مكان واحد لتطوير التجربة ، لكننا لم نفهم أن هذا التجميع مفيد جدًا في حد ذاته ، لذا فإن هذا تأثير جانبي مثير للاهتمام. يمكنك الذهاب هنا والاطلاع فعليًا على الأنماط المضادة المرتبطة بخدمة معينة. على سبيل المثال ، تم اكتشاف تبعية لم تكن تعتبر حرجة ، ولكن ليس لها مسار احتياطي. من الواضح أنها أصبحت الآن منتقدة. يمكن للناس رؤية عدم تطابق المهلة ، عدم تطابق رد الاتصال. نستخدم هذه المعلومات لتقييم مدى أهمية تجربة من نوع معين وإدخالها في خوارزمية تحدد الأولويات.
يمثل كل سطر تبعية ، ويمكن توسيع هذه الخطوط. هنا مثال مثير للاهتمام.
هنا ، يشير الخط الأزرق في الأعلى إلى انتهاء مهلة أحد الأشخاص ، ويشير الخط الأرجواني في الأسفل إلى وقت التشغيل المعتاد. كما ترون ، إنه بعيد جدًا جدًا عن المهلة. لكن معظم هذه المعلومات لم تكن متاحة. ماذا يحدث إذا أجرينا الاختبار تحت المهلة؟ ما رأيك؟ هل سيمر؟ هذا سؤال مثير للاهتمام. نحن نحاول تزويد المستخدمين بهذا المستوى من التفاصيل قبل تشغيل الاختبارات حتى يتمكنوا من استخلاص النتائج وتغيير الإعدادات.
أريد أن ألعب لعبة صغيرة. توجد ثغرة في خدمة Netflix هذه ، حاول اكتشافها. خذ ثانية وانظر.
لإعطائك بعض السياق ، يحتوي أمر Hystrix عن بعد على كل من sample-rest-client و sample-rest-client.GET. تم ضبط مهلة Hystrix على 500 مللي ثانية. Sample-rest-client.GET لديه مهلة 200 مللي ثانية مع إعادة المحاولة مرة واحدة ، وهو أمر جيد ، لأن الإجمالي 400 مللي ثانية ، والتي تتناسب مع حد Hystrix. لدى العميل الثاني مهلة 100 و 600 مع إعادة محاولة واحدة.
في هذه الحالة ، لا يمكن إتمام إعادة المحاولة مع مراعاة مهلة غلاف Hystrix ، أي أن Hystrix يرفض الطلب قبل أن يتمكن العميل من تلقي رد. هذا هو المكان الذي تكمن فيه الثغرة الأمنية. نحن نقدم هذه المعلومات للمستخدمين. ومن المثير للاهتمام أن معظم المنطق في تنفيذ هذه الوظائف في أماكن مختلفة ، وقبل أن يتمكنوا من مقارنة هذه الأشياء. اعتقدوا أن كل شيء يسير على ما يرام ، ولكن هذا خطأ.
لماذا حدث هذا؟ بالطبع ، من السهل على المطور رؤية التعارض وتغيير المهلة ، أليس كذلك؟ لكننا نريد معرفة السبب. يمكننا تغيير المهلة ، ولكن كيف يمكننا ضمان عدم حدوث ذلك مرة أخرى؟ نساعد أيضًا في معرفة الأسباب.
عند إنشاء اختبارات آلية ، نستخدم أيضًا Monocle. ينشئ المستخدم تجربة على أنواع عديدة من بيانات الإدخال. نأخذ كل هذا وأتمتة إنشاء مثل هذه الاختبارات بحيث لا يزعج المستخدمون. نقوم تلقائيًا بإنشاء وتعيين أولويات تجارب Hystrix وتجارب RPC مع التأخيرات والفشل بسبب التأخيرات. تتم إضافة تكوينات ACA بشكل افتراضي. لدينا SPC ، ومقاييس النظام ، وإحصاءات الاستعلام ، والتجارب تعمل تلقائيًا. يتم إنشاء أولويات التجارب أيضًا. تعمل خوارزمية عالية المستوى لهم. نستخدم دلو مع إحصاءات RPS. نستخدم العديد من عمليات إعادة المحاولة وأوامر Hystrix ذات الصلة. تم وزن المجموعة بالكامل بشكل مناسب.
بالإضافة إلى ذلك ، يتم أخذ عدد الفرق التي ليس لديها مسارات تنفيذ احتياطية وأي تأثير خارجي (تأثير منظم) يضيفه العميل إلى تبعيته. تؤثر التأثيرات الخارجية بشكل كبير على إجراءات التفويض والتسجيل وإجراءات الصحة والصحة النباتية. ونقيس تأثيره حقًا ولا نجري تجارب إذا كانت النتيجة سلبية. ثم يتم ترتيب الاختبارات وتشغيلها بترتيب تنازلي من الأهمية. كلما زادت درجة الأهمية ، كلما بدأ الاختبار في وقت مبكر.
ومن المفارقات أن Monocle زودتنا بملاحظات تسمح لنا بإجراء عدد أقل من الاختبارات في الإنتاج. لقد أجرينا العديد من الاختبارات التي نتجت عن ذلك حلقة ملاحظات: رأينا الروابط بين الاختبارات. الآن يمكنك إلقاء نظرة على ملفات تكوين محددة والاطلاع على أنماط مكافحة معينة. حتى بدون اختبارات لهذه المعلومات ، من الممكن أن نفهم ما الذي سيسبب الفشل بالضبط ، في ذلك الوقت لم نفهم هذا من قبل.
وقد أدى هذا إلى مستوى جديد من الأمن. سابقًا ، تم وضع علامة على تجربة غير ناجحة على أنها تم حلها. الآن تم وضع علامة عليه على أنه تم حله قبل إعادة التشغيل. ولكن الآن يمكننا أن نضيف صراحة التأثيرات الخارجية (القيمية) على الإدمان. يقوم المستخدم بإدخال Monocle الخاص به ويشير إلى: يؤثر هذا العامل بدقة على إجراء التفويض. هذا على SPC. ونحن نعمل على دورة تغذية مرتدة ، حتى إذا فشلت ، يتم أيضًا إضافة مثل هذا التأثير التنظيمي.
وبالتالي ، تعد Monocle in ChAP أداة مهمة يتم فيها جمع جميع المعلومات ، حيث تقوم تلقائيًا بإنشاء التجارب ، وتحديد الأولويات والبحث تلقائيًا عن الثغرات الأمنية قبل أن تؤدي إلى عمليات إغلاق كاملة النطاق. للتلخيص ، من المهم أن نتذكر لماذا نشارك في هندسة الفوضى ونجري كل هذه التجارب في الإنتاج. يتم ذلك لفهم كيفية استخدام العملاء للخدمة ، وعدم إغفالهم. تريد أن تقدم للأشخاص الخدمة الأكثر ملاءمة. لذا فإن المراقبة والأمن لهما أهمية قصوى. يجب أن يعرض Netflix الفيديو دائمًا.
شكرا لك