ما الذي يمكن للهندسة المعمارية أن تعلمنا إياه عن أنظمة الشفاء الذاتي

ما الذي يمكن للهندسة المعمارية أن تعلمنا إياه عن أنظمة الشفاء الذاتي

عقدة المصدر: 1988904

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

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

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

الدرس 1: حالات الحافة ستستغل دائمًا نقاط ضعف النظام

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

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

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

لتقليل متوسط ​​وقت الاسترداد (MTTR) / متوسط ​​الوقت للكشف (MTTD) ، يجب على فرق DevOps قبول الاحتمال الكبير للحالات المتطورة والعمل على نشر حلول التعلم الذاتي بشكل استباقي. يقطع هذا الدرس شوطا طويلا ، حيث أن التبصر أمر بالغ الأهمية في الهندسة.

الدرس الثاني: "بناء الطائرة أثناء تحليقها" يخلق دورة لا تنتهي أبدًا

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

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

يستثمر الفريق الهندسي المتوسط ​​في 16 إلى 40 أداة مراقبة ، ومع ذلك غالبًا ما يفقدون العلامة التي تظهر فيها المقاييس النجاح. أقل من 15٪ من الفرق تتعقب MTTD ، لذا فإنها تفوت 66٪ من دورة حياة الحادث. وتقرير ربع الفرق في عداد المفقودين اتفاقيات مستوى الخدمة (SLAs) على الرغم من الاستثمار الكبير في تتبع التوافر. يخبرنا هذا أن جمع البيانات يحتاج إلى تحليل شامل ومنهجي لقطعه - لم تعد الحلول النقطية كافية.

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

الدرس 3: الذكاء الاصطناعي هو لبنة أساسية لأنظمة الشفاء الذاتي

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

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

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

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

الطابع الزمني:

اكثر من البيانات