Get best of the week

هندسة المرونة: ملاحظات من مؤتمر REDeploy



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

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

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

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

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

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

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

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


حول هذا كان المؤتمر. وأدناه - ما تحدث عنه بعض المتحدثين.

بعض الملاحظات حول المرونة العظيمة في هندسة العظام والمرونة. ريتشارد كوك


بادئ ذي بدء ، يجب أن يقال عن شخص المتحدث. ريتشارد كوك هو طبيب وعالم وأحد "المروجين" الرئيسيين لهندسة المرونة في تكنولوجيا المعلومات. بالاشتراك مع David Woods و John Olspau (الشخص الذي أطلق DevOps كمرجع) ، شارك في تأسيس مختبرات Adaptive Capacity Labs ، وهي شركة تنفذ هندسة الاستدامة في منظمات أخرى.

وتجدر الإشارة إلى أن REDeploy ليس مؤتمرًا لتكنولوجيا المعلومات ، وهذا التقرير مثال حي على ذلك.

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

بشكل عام ، يمكن تقسيم تاريخ العلاج إلى اتجاهين:
  • العلاج كعملية تخلق الظروف الأكثر ملاءمة لشفاء العظام (في عملية العلاج نطبق الجبس حتى لا يتحرك العظم).
  • العلاج كعملية "تحسين" عملية الشفاء (فهم - على المستوى البيوكيميائي - كيف تسير عملية الشفاء ، نستخدم الأدوية التي تسرعها).


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

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

فن احتضان الفشل على نطاق واسع. أدريان هورنزبي


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







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



الحصول على الراحة مع كونك تحت الماء. روني تشين


تقرير من مدير تويتر لديه خبرة في الغوص التقني في أعماق البحار حول ميزات الأمان أثناء الغوص.

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

كيف يمكنك أن تحاول التعايش مع الضغط الذي يقع على عاتق الفريق في حالة الأنشطة الخطرة؟

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


The Practice of Practice: Teamwork in Complexity. Matt Davis


في حالة وقوع حادث ، يكون المهندسون بديهيًا إلى حد كبير ، ويقارن الحدس في التقرير بالارتجال الموسيقي. الارتجال هو عملية لعب موسيقى بديهية ، ولكن هذا الحدس مبني على الخبرة - معرفة المقاييس الموسيقية ، وتجربة الارتجال السابق ، والعمل الجماعي. علاوة على ذلك ، هذه عملية ثنائية الاتجاه: الحدس مبني على الخبرة ، والعمليات مبنية على تحليل الإجراءات البديهية (في الموسيقى - يتم كتابة ملاحظات تكوين مؤلف ، في التقنيات - يتم وصف عملية تصحيح الحادث).

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

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

وأنا أكثر انتظامًا من المدونة هنا ، أحتفظ بقناتي برقية ، اشترك :-)

More articles:


All Articles