هندسة الفوضى

آخر شيء تريد رؤيته أثناء تصحيح التعليمات البرمجية هو الفوضى . ولكن ماذا لو تم التحكم في هذه الفوضى وإطلاقها على أيدي المطور نفسه؟ لماذا تعمد ترتيب الاضطرابات في التشغيل السلس للتطبيق الخاص بك ، وكيفية تحقيق راحة البال عند إصدار ميزات مهمة وحيثما تكون ممارسة هندسة الفوضى مفيدة ، اقرأ PavelOsipov في المحادثة بين بودكاست AppsCast الرائد و Pavel Osipov.



أليكسي كودريافتسيف: مرحباً بالجميع! اليوم ، ضيفنا هو Pavel Osipov من Mail.ru Cloud ، الذي سنتحدث معه عن هندسة الفوضى.

بافيل أوسيبوف: مرحباً بالجميع! منذ ستة أعوام ، كنت أدير تطوير Mail.ru Cloud. خلال هذا الوقت ، تراكمت لدينا العديد من ممارسات الاختبار الاقتصادي ، واحدة منها هي هندسة الفوضى. تتيح لك هذه الممارسة إجراء سلسلة من التجارب التي يتم التحكم فيها لتحديد صحة نظامك في بيئة معادية. بناءً على نتائج هذه التجارب ، تحصل على رؤى مفيدة. على سبيل المثال ، من غير المحتمل أن ترى بانتظام كيف يتصرف النظام في شبكة غير مستقرة. إذا كان المستخدم الخاص بك يسافر في كثير من الأحيان في المترو أو يقع في بيئة wifi الفندقية ، فإن الشبكة ليست مستقرة كما في مكان عمل المبرمج. بعد كل إجازتي في البحر ، أحمل "مجموعة" كاملة من سجلات الأخطاء التي حدثت في التطبيق.

شخصيًا ، تسمح لي الفوضى اليدوية بتلقي جرعة إضافية من الثقة بأن كل شيء سوف يسير على ما يرام ، حتى لو كان كل شيء سيئًا خارج التطبيق.

هناك حالات عندما أثق بالفوضى اليدوية أكثر من الاختبارات التلقائية.

رؤية جذر الفوضى

أليكسي كودريافتسيف: من أين أتت جذور هذه الممارسة؟

بافيل أوسيبوف: هذه ممارسة للخوادم ، حيث توجد العديد من المشكلات. لقد اعتدنا على مفهوم الدين الفني ، وفي الغرب هناك أيضًا ديون مظلمة - دين خفي ينشأ حتماً في أنظمة معقدة. على عكس الديون الفنية ، حيث نستعير بوعي وقت المستقبل بأنفسنا من الحاضر ، فإن الديون الخفية غير مرئية في مرحلة إنشاء النظام. يحدث عند تقاطع المكونات أو الأجهزة والبرمجيات ويمكن أن يؤدي إلى سلسلة من المشاكل: هناك شيء ما ينهار على أحد المكونات ويتداخل مع مكون آخر ، والآن يكمن النظام بأكمله.

على سبيل المثال ، في عام 2016 ، بسبب إغلاق قاعدة البيانات المتتالية ، وضعت 2.5 ساعة فيسبوك. ثم بدأ النظام الذي تحقق من صحة ملفات التكوين في حذفها عن طريق الخطأ ، ليس فقط في النظام الفرعي للتخزين المؤقت ، ولكن أيضًا في قاعدة البيانات التي كانت المصدر الأساسي.

أحب حقًا المقابلة مع Oleg Anastasiev من Odnoklassniki حول إجراء التدريبات لمنع حوادث البنية التحتية. لديهم ثلاثة مراكز بيانات ، والتي يجب أن تكون في حالة تأهب 24/7 ، ولكن مرة واحدة في ربع يحدث نوع من الفشل. أنها تجري مثل هذه التمارين على الإنتاج. من ناحية ، يبدو هذا مخيفًا ، لأنه إذا حدث شيء غير متوقع ، فسوف يسقط مركز البيانات بالكامل ولن يكون متاحًا على المنتج. لكن من ناحية أخرى ، يتم التحكم في هذه العملية ، وإذا حدث خطأ ما ، فستراها فورًا وتوقفها وستتم استعادة كل شيء. إذا حدث هذا في ظروف القتال القتالي ، فإن إعادة تشغيله لا يعمل ، وسيستمر تحليل أسباب الإغلاق لفترة طويلة.

فوائد الفوضى في تطوير المحمول

دانييل بوبوف: حتى الآن ، نحن نتحدث عن تطوير الخوادم ، حيث الخدمات المجهرية شائعة ويمكن انقطاع التيار الكهربائي. هل يمكنك إعطاء المزيد من الأمثلة حول ما يمكن التحقق منه من خلال هندسة الفوضى في تطوير الأجهزة المحمولة؟

بافيل أوسيبوف: المثال المفضل لدي هو تسجيل التطبيق. في ظروف الاختبار ، يمكن أن تكون إجراءاتنا لطيفة للغاية فيما يتعلق بالتطبيق: لقد دخلنا في إعدادات الحساب ، ونقرنا على زر "خروج" ، وخرج التطبيق ، وعند عرض شاشة تسجيل الدخول ، يبدو أن كل شيء على ما يرام. المستخدمين في كثير من الأحيان المواقف الغريبة. على سبيل المثال ، قام العميل بتغيير كلمة المرور من خلال واجهة الويب أو حدث عدد كبير من السجلات على الأجهزة الأخرى وتم استبدال رمز التحديث. يحدث هذا التسجيل ليس في النافذة بحساب المستخدم ، ولكن ، على سبيل المثال ، في وقت عارض الصور بملء الشاشة.

لقد وجدنا العديد من الحالات التي يؤدي فيها تسجيل الدخول في أماكن مختلفة من التطبيق إلى عواقب مثل تسرب الذاكرة. يمكن للمشاهد نفسه مع كتلة الإنجاز الاستيلاء على خدمة حيوية ، والتي تسربت في نهاية المطاف.

نحن محاكاة الظروف باستخدام هندسة الفوضى. يحتوي النظام على خدمة تقوم بتحديث خدمات التطبيق عالي المستوى بشفافية لرمز الوصول إلى التطبيق باستخدام الرمز المميز للتحديث الخاص بالتطبيق. لقد قدمنا ​​الفوضى التي تفسد فيها الخدمة ، بدلاً من تحديث الرمز المميز ، بدرجة معينة من الاحتمال ، ويواجه كل مطور سجلًا عدة مرات يوميًا في مكان غير متوقع.

بفضل هذا ، اكتشفنا سلوكًا مثيرًا لـ UIKit في نظام التشغيل iOS: إذا تم تسليط الضوء على نافذة تحكم أخرى تم حجبها من النافذة ، فعندما يتم تسريب إطار آخر ViewController من النافذة ، فإن تسرب الجذر ViewController ويبقى في النظام إلى الأبد. إذا كان في ViewController في الوقت نفسه رابط إلى خدمات ، وفقًا لمنطق الهيكل ، يجب أن تكون موجودة في النظام في حالة واحدة ، فلا يمكن تجنب المشاكل. على سبيل المثال ، لدى Cloud خدمة التحميل التلقائي للصور ، وإذا ظلت هاتان الخدمتان في النظام ، فستقومان بالكثير من الأعمال غير الضرورية وتضع بطارية الجهاز في أسرع وقت ممكن.

حالة غريبة أخرى. عندما ظهر نظام التشغيل iOS 8 ، كانت هناك مشاكل في الإضافات: في بعض الأجهزة ، عندما يتم منح جميع الأذونات في إعدادات التطبيق ، في النظام ، ذكر النظام في البداية أن التطبيق لا يستطيع الوصول إلى مجموعة التطبيقات المشتركة.

تصنيف الفوضى

دانييل بوبوف: يتم إدخال Chaos في النظام تلقائيًا على أساس الاهتمام أو التكوين ، لكن هل يحتاج الشخص إلى نظرة لفهم الخطأ الذي حدث؟

بافيل أوسيبوف: الفوضى مختلفة: كلاهما يدوي وآلي. في حالة نظام التشغيل ، الذي قال إن التطبيق لم يكن لديه حق الوصول إلى مجموعة التطبيقات المشتركة ، ولم تتمكن الإضافات من الوصول إلى الموارد المشتركة وقاعدة البيانات ، تم استخدام الفوضى اليدوية ، والتي تم تشغيلها مع وجود علامة اختيار في إعدادات النظام للتطبيق. يمكن أن يصمم هذا بسهولة من قبل فريق من فريق ضمان الجودة.

هناك فوضى الآلي. على وجه الخصوص ، هذه هي الأخطاء التي تم تصميمها من خلال خدمات microservices الخلفية الخاصة بنا ، والفوضى المرتبطة بتحديث الرمز المميز. النتائج مختلفة. يمكن تحديد التصميم المقطوع من خلال الملاحظة البصرية. هناك أماكن تتيح لك اكتشاف الحالات الشاذة في الوضع التلقائي. على سبيل المثال ، في تطبيقنا ، يتم اكتشاف تسرب الذاكرة تلقائيًا. هناك حاويات IoC في النظام. أحد المديرين هو عمر الخدمات العالمية ، والذي يتزامن مع عمر التطبيق نفسه ، والحاوية الأخرى هي مدير الخدمات التي تتزامن مع المستخدم في الوقت المناسب. تقوم كل حاوية IoC بإنشاء خدمة بالتحقق من وجودها في مثيل واحد.

دعنا نعود إلى المثال مع السجلات. في مكان ما ، حدث تسجيل دخول فجأة وأعاد المطور إدخال الحساب لمواصلة العمل. في هذه المرحلة ، تشير حاوية IoC إلى حدوث تسرب للذاكرة ، ويتم اكتشاف الخدمة ، التي يجب أن توجد نظريًا في حالة واحدة ، مرة أخرى.

متى يكون وقت الفوضى؟

أليكسي كودريافتسيف: ما الذي كان بمثابة حافز لتنفيذ هذه الممارسة؟

بافيل أوسيبوف: لقد توصلنا إلى هذا من خلال الحاجة إلى تقليل تكلفة الاختبار. كيف يمكن للمرء التعامل مع نفس مشاكل razlogin؟ يمكنك كتابة اختبارات وحدة للتسريبات ، يمكنك الحصول على الخلط وكتابة اختبارات واجهة المستخدم.

تعتبر Chaos engineering أرخص ممارسة ، لأنها ليست مرتبطة بحالات المستخدم ، ولكنها تعمل تلقائيًا لجميع حالات المستخدم معًا.

الزناد الثاني - قبل تقديم الممارسة ، في تقريرنا عن الأعطال ، لوحظت حوادث مماثلة مع نفس السبب الجذري. على سبيل المثال ، حدث هذا التعطل ليس بسبب سجل النظام في ملف التعريف ، ولكن بسبب قيام المستخدم بالتمرير خلال معرض الصور في ذلك الوقت. تختلف المواقف ، ومن المستحيل اختبار جميع مجموعات razlogins. لذلك أردت أن أتوصل إلى شيء يعمل على أتمتة العملية.

هندسة الفوضى لديها الممارسة ذات الصلة - اختبار طفري . في هذه الممارسة ، نقوم بتعديل أجزاء صغيرة من التعليمات البرمجية ونرى كيف يؤثر ذلك على الاختبارات. إذا ، بعد التغيير ، يتم إجراء الاختبارات بشكل صحيح ، فهذا يعني أن هذه الأجزاء من الكود لا تكون الاختبارات كافية.

الفرق بين هندسة الفوضى واختبار الطفرة هو أننا لا نغير رمز الإنتاج نفسه تلقائيًا ، ولكن بيئته.

أليكسي كودريافتسيف: هل من الممكن توطين السبب وإصلاحه دون هندسة الفوضى؟

بافيل أوسيبوف: لا يوجد سبب واحد يثير حوادث التعطل. كل حالة فريدة بطريقتها الخاصة. على سبيل المثال ، ظهر زر مشروط أعلى النافذة ، مما أدى إلى تسرب ViewController المدمرة أثناء برنامج razlog. لا يمكن التنبؤ بجميع مجموعات التسلسلات الهرمية للنافذة التي لديك أثناء التسجيل. الفوضى هندسة الأنماط المترجمة التي تحدث تسريبات وتعطل.

أليكسي كودريافتسيف: منذ متى وأنت تستخدم هذه الممارسة؟

بافيل أوسيبوف: بدأنا استخدامه في فجر المشروع في عام 2012 ، لأنه كان من الضروري تطويره بسرعة ، ولم يتم تخصيص وقت للاختبار على نطاق واسع. علاوة على ذلك ، هذه ليست مؤثرة فقط ، ولكنها أيضًا تجربة إيجابية.

دانييل بوبوف: إذا تعطل شيء ما في طلبي وكنت بحاجة لبدء مهمة في JIRA ، فما الذي يمكنني إصلاحه في المستقبل ، كيف يمكنني إعادة إنتاج هذا الموقف؟

بافيل أوسيبوف: لا توجد وصفة عالمية. يتم تنشيط هندسة الفوضى عند تصحيح التطبيق وإلغاء تنشيطه عند إنشاء إصدار الإصدار ، لذلك يمكن رؤية مثل هذه المواقف من خلال السجلات في وحدة تحكم بيئة التطوير ، والتي يمكنك من خلالها معرفة كيفية وضع المهمة في JIRA.

Alexei Kudryavtsev: هل تحاول إنشاء سلوك قابل للتكرار بحيث يخطرك نظام الفوضى بحالات المشكلة ويقترح إدخاله في التهيئة في البداية لتكرار هذه الحالة؟

بافل أوسيبوف: يبدو كونيًا وربما في أبنية مثل Redux. إذا كانت البنية تسمح لك بتسجيل جميع الإجراءات التي سبقت الأحداث الحرجة ، فهذا ممكن. هذا ليس كذلك معنا. تم ممارسة هذا عندما كنت أعمل كمبرمج serveride في مجال الاتصالات. كانت هناك اختبارات عشوائية العشوائية مدخل النظام الفرعي والتحقق من وجود إخراج كاف. لقد حققنا أنه عندما تعطل اختبار الإدخال العشوائي للنظام ، وفي البرنامج الذي كان مسؤولاً عن اختبار التشغيل الآلي ، تم تأجيل جميع المعلمات اللازمة لطلب الإدخال حتى يمكن إعادة إنتاجه.

تطبيق الفوضى في التطبيق

دانييل بوبوف: هل يصح إدخال مثل هذه الفوضى في الكود باليد؟

بافيل أوسيبوف: نعم ، عميل الشبكة لدينا لديه وظيفة مدمجة حيث يمكنك تقديم التكوين ، الذي يصف المعلمة الفوضى التي ينبغي استنساخها. بناءً على التكوين ، يقرر إرسال طلب عميل إلى الخادم أو الرد على هذا الهراء بمفرده. طبقة العمل مع الشبكة بحيث يمكنك تخصيص الفوضى التي يتم تقديمها بواسطة microservice في الخلفية. لا يوجد أي معنى لنمذجة الأخطاء في صحة بيانات التفويض إذا كانت طلبات خدمات microservice لا تتطلب ترخيصًا.

نحن لا نقوم فقط بعشوائية كل شيء ، بل نلعب الكود المثالي ، بل نستخدم العشوائية بشكل معقول ما يمكن للمستخدم إعادة إنتاجه في الحياة الحقيقية.

أليكسي كودريافتسيف: ما الذي تقوم العشوائية بصرف النظر عن الشبكة والملفات؟

بافيل أوسيبوف: لقد قمنا بتصحيح ممارسة إضفاء الطابع العشوائي على الاستجابات من نقاط النهاية المحددة لنمذجة سلوك وفوضى كل خدمة ميكروية بشكل منفصل. لقد انتهينا من العمل على نقل نظام الملفات إلى أنظمة فرعية منفصلة ، وأحاول تصميم أنواع مختلفة من الأخطاء عندما يحاول تطبيق ما كتابة أو قراءة ملف. محاكاة الوصول يدويًا إلى مجموعة التطبيقات المشتركة في التطبيق ، وأريد حقًا أن أبدأ في تصميم سلوك التطبيق عندما يبدأ بمساحة صغيرة جدًا على القرص ، بحيث يكون من المستحيل حتى إنشاء قاعدة بيانات.

أليكسي كودريافتسيف: هل هذا كل ما تفعله؟

بافيل أوسيبوف: من حيث المبدأ ، نعم. لم نقم بعد بكافة تلك الأخطاء التي تم العثور عليها باستخدام الفوضى الحالية. بالطبع ، من المثير للاهتمام زيادة الفوضى والانتقال إلى النظم الفرعية الأخرى ، ولكن بعد ذلك لن يكون لدينا وقت لإصلاح ما ستجده الفوضى.

أين مكان الفوضى؟ يمكنك دائمًا العثور على مكان يمكنك فيه إنشاء اضطراب آخر للتطبيق. من المهم البناء على المشاكل. لقد صنعنا فوضى للتسجيل لأننا لاحظنا عددًا كبيرًا من المشكلات المماثلة.

إذا أظهرت المراقبة أنه لا توجد مشكلات خاصة في الأنظمة الفرعية الأخرى ، فليس من المنطقي قضاء الوقت في نمذجة الظروف غير المتوقعة.

لا ينطبق هذا على الفوترة ، حيث تكون العملية الصحيحة مهمة.

أليكسي كودريافتسيف: من ناحية أخرى ، لا نعرف ما الذي يحدث مع المستخدمين - فهذه هي الفوضى بحد ذاتها ، لأنك لا تعرف من أين تضعها أم لا ، وعليك فقط محاكاة ذلك.

بافيل أوسيبوف: تحتاج دائمًا إلى إلقاء نظرة على عائد الاستثمار. بالطبع ، يمكنك إعادة إنتاج الحالات الأكثر غرابة ، ولكن إذا كانت مفردة ، فربما ليست حرجة ، وليس هناك أي فائدة في تصميمها.

تحديات تقديم الفوضى

أليكسي كودريافتسيف: أيًا مما تم فعله بالفعل كان سهلاً بالنسبة لك ، وما سبب الصعوبات؟

بافيل أوسيبوف: التعود على الفوضى أمر غير معتاد بالنسبة للمبتدئين ، لأن هذه ليست ممارسة شائعة الاستخدام. من الصعب التكيف مع حقيقة أن لديك مجموعة من الأخطاء. في كل شاشة تقريبًا ، يمكنك الحصول على حزمة من "خمسمائة" أو "404" غير مفهومة ، يستجيب الخادم مرة واحدة. فقط مع مرور الوقت تعتاد على حقيقة أن كل هذا ممل ، واستجابات من الخادم على غرار النظام نفسه.

يكون الأمر صعبًا عندما يكون لديك ميزة مهمة تم إشعالها بالفعل ، وتحتاج إلى الانتهاء منها في أقرب وقت ممكن ، ثم يظهر razlogin فجأة في مكان تراكم الطلبات. على سبيل المثال ، تحتاج إلى تكوين الشاشة بشكل صحيح وتحتاج إلى إكمال جميع الطلبات بنجاح ، وهذا من غير المرجح أن تضطر إلى الذهاب بضع عشرات لتحقيق الحالة المطلوبة. في مثل هذه الحالات ، يصبح تعطيل الفوضى إجراءً مضادًا ، ومن المهم ألا تنسى تشغيله مرة أخرى.

النقطة الأخرى التي تسبب عدم الرضا هي استخدام الفوضى في خدمات البنية التحتية مع عدد كبير من الآثار الجانبية.

دانييل بوبوف: إذن ، هل يعمل المطورون دائمًا على تشغيل الفوضى افتراضيًا؟

بافيل أوسيبوف: بالتأكيد. في بعض الأحيان ، عندما لا تهتم بالفوضى وتلك المواقف الغريبة التي يمكنه التكاثر من أجلك ، فإنها تزعجك. يجب أن تتحمل ، لكن يمكنك دائمًا ضبط مستوى الفوضى إذا كانت شاشتك تعمل بشكل مكثف مع الشبكة. من ناحية أخرى ، يمكن أن تكشف الفوضى عن مشكلة بعيدة عن المكان الذي تبحث عنه ، وليس عن المطور الذي يطور هذه الميزة. يحدث أن تؤدي الميزة الخاصة بك ، التي تتم فيها إضافة الفوضى ، إلى عواقب تؤثر على ميزة زميلك. لن تعرف هذا إذا كانت الفوضى ستدرج فقط في لحظة معينة من التطور.

معنى الفوضى هو تحديد العواقب غير المتوقعة في تفاعل عدد كبير من المكونات.

إذا قمت بتضمين الفوضى بطريقة دقيقة ودقيقة ، فإن هذه اللقطات النادرة والموجهة جيدًا ستكون غير مرئية.

دانييل بوبوف: هل الفوضى تمنع قراءة الكود؟

بافيل أوسيبوف: عندما يتم إدخال الفوضى خارج النظام ، تتمسك بالنهاية النهائية ، ثم نعم ، تبدو غير واضحة. في الولايات المتحدة ، نظرًا لخبرة الاستخدام الطويلة ، يتم إحداث الفوضى داخل النظام ومعزولة جدًا بحيث لا تلاحظها في الكود.

أليكسي كودريافتسيف: يمكنك التقاط الكثير من الحالات النادرة ، وإصلاحها ، ويحيط بالرمز العكازات. هل هذا يعقد منطق التطبيق؟

بافيل أوسيبوف: هذا دائمًا جزء كبير من الكود لدينا ، ولكن على خلاف ذلك ، لا تتم كتابة طلبات الإنتاج الكبيرة. بالطبع ، كل هذا يتوقف على مهارة المطور ، الذي يعرف كيفية إصلاح الكود بحيث لا يزعج العينين.

إيجابيات إدخال الفوضى

دانييل بوبوف: هل هناك أي مؤشرات كمية تحسنت بعد إدخال هندسة الفوضى؟

بافيل أوسيبوف: بالنسبة لي ، فإن المقياس الأكثر أهمية هو راحة البال الداخلية عندما أرسل ميزة لإطلاقها.

أليكسي كودريافتسيف: لا يمكن بيع السلام لرجال الأعمال. كيف يجادل إدخال هندسة الفوضى في الشركة؟

بافيل أوسيبوف: تعمل هندسة الفوضى على توفير الوقت للمختبرين ، حيث توجد اختبارات تلقائية. التحطم نفسه مع razlogin بعد إدخال ممارسة الفوضى اختفى تقريبا من JIRA لدينا.

هندسة الفوضى لها تأثير مفيد على دورة الإصدار ، حيث تحصل على ردود فعل سريعة. إنه شيء واحد عندما يتم تشغيل الميزة النهائية في الاختبار ، وبعد وقت طويل يتم إعلامك بعدد الأخطاء التي تم العثور عليها ، يكون الأمر مختلفًا تمامًا عندما يكون لديك اختبار الروبوت الذي يعمل طوال برنامج تصحيح الأخطاء.

لدي شعور بالثقة من نتائج اختبارات الوحدة أقل بكثير من الفوضى التي تم تشغيلها بنسبة 50٪ عند تنزيل آلاف الملفات. مع مثل هذا الحمل ، سيتم بالتأكيد إصلاح جميع المجموعات الأكثر غرابة.

من الذي تتعلم منه ومن أين تبدأ؟

أليكسي كودريافتسيف: ما هي الأدوات التي استخدمتها لهذا؟ أخذت المكتبات المفتوحة أو كتب ونشرت في المصدر المفتوح؟

بافيل أوسيبوف: لقد قمنا بنشر مكتبة شبكة مفتوحة المصدر ، لكن لا توجد أدوات متخصصة. الشيء الوحيد الذي أعرفه هو Netflix Chaos Monkey ، الذي "يعمل" بشكل عشوائي عبر مثيل AWS وينهيها ، يتطلع إلى معرفة ما إذا كان كل شيء سار بشكل جيد إذا تم إطفاء عدد معين من الحاويات. , , , .

: chaos engineering?

: -, Principles of Chaos , . -, Learning Chaos Engineering Chaos Engineering Observability .

, - — . , . ? , .

: , - ?

: , . , , . .

: , ? ?

: . . API, . - , , . , UIKit API .

— , .

: ?

: -, unit-, .

-? AppsConf - 21-21 , Key-value .