على مر السنين ، كان Netcracker هو بائع المنتجات لمشغلي الاتصالات ، ويعمل في الوقت نفسه كمدمج لمجموعة كاملة من برامج المشغل. في هذا العمل ، تنشأ المهمة حتماً من مزامنة وتنسيق عدد كبير من إصدارات المنتجات والحلول ، في مجموعات مختلفة ، من مختلف المطورين وبوظائف مختلفة. يتجنب العديد من المشغلين الاعتماد عن عمد على مورد واحد من خلال إنشاء حديقة حيوانات من المنتجات من بائعين مختلفين ، بحيث يمكن إشراك ما يصل إلى عشرات الأنظمة والعمليات المتباينة في سيناريو معقد إلى حد ما.
لتوضيح ما نتحدث عنه ، تخيل أنك تحتاج مرة واحدة في الأسبوع إلى تنفيذ عملية باستخدام مجموعة من الأدوات والتقنيات المختلفة: إجراءات PL / SQL والبرامج النصية للباش ونصوص Perl وإطلاق التطبيقات الفردية والوصول إلى عمليات الخفي. هذا كله يرجع إلى عدم تجانس مشهد تكنولوجيا المعلومات للمشغل. في الوقت نفسه ، لكل إجراء سيكون هناك معلمات التشغيل الخاصة به ، والتحكم في الخروج ، وكذلك مجموعة من الأخطاء المحتملة التي تؤثر على التنفيذ اللاحق للبرنامج النصي. يتحول كل عملية إطلاق إلى مهمة خطيرة تتطلب عدة ساعات أو أيام من العمل لمهندسي تكنولوجيا المعلومات المؤهلين تأهيلا عاليا - يمكن أن يستغرق تدريبهم ما يصل إلى ثلاث سنوات قبل إطلاقهم إلى مشغل اتصالات منتج مع عشرات الملايين من المستخدمين.
من الواضح أن هذه المهام تحتاج إلى أتمتة. لذلك ، قررنا الاستفادة بشكل أفضل من BPMN Orchestra ، مخطط العملية ، نظام المراقبة وإثراء هذه المجموعة مع القدرة على تحليل السجلات والأخطاء. بالطبع ، تم النظر في أفضل ممثلين من نوعهم لكل نوع من أنواع النظام. ولكن لم يتم العثور على خلاصات مطابقة لخصائص الصناعة. لذلك - افعلها بنفسك.
باختصار حول ما نقوم به: يتم تجميع الإجراءات غير المتجانسة في "مهام" مع مجموعة نموذجية من الواجهات والخصائص ؛ يشكل تسلسل معين من المهام "عملية" (على سبيل المثال ، عملية إعداد الفواتير مقابل رسوم خدمات الاتصالات). علاوة على ذلك ، وفقًا لجدول أو يدويًا ، تبدأ كل عملية تسلسل الإجراءات مع المعلمات اللازمة ، وترصد التنفيذ ، وتقيم نتائج المهام المتداخلة ، وتتخذ قرارًا بشأن اختيار السيناريوهات. تعتمد العلاقة بين المهام داخل العملية على منطق BPMN القياسي ، بينما في خادم الإدارة وضعنا القدرة على إيقاف العملية يدويًا ، وإيقافها مؤقتًا ، والخروج من السيناريو الحالي مع حفظ البيانات التي تمت معالجتها بالفعل. يتم تنفيذ إدارة العملية من خلال واجهة ويب مع مراقبة في الوقت الحقيقي ، مع تقييم الشذوذ ، ورصد اتفاقات مستوى الخدمة المحددة لكل عملية.
الآن ، يمكن لـ "مدير العمليات" العمل في وضع شبه تلقائي ، لكنه لا يقلل من الحمل على مهندسي تكنولوجيا المعلومات - عندما يتفاعل نظامان أو أكثر من الأنظمة المعقدة ، يزداد تباين الحالات الشاذة في العمليات عدة مرات ويتوقف الجهد الرئيسي على معالجة الأخطاء. لذلك ، في المرحلة التالية ، كان علينا اتخاذ قرار:
- كيف نريد أتمتة معالجة الأخطاء؟
- كيفية تصحيح السيناريوهات بناءً على تحليل الشذوذ؟
- بشكل عام ، ما مدى تدخل الشخص في تشغيل مثل هذا النظام ، وفي أي مجلدات وفي أي مكان؟
وألاحظ مرة أخرى أن كل هذا يجب القيام به في الوقت الفعلي على إنتاجية النظام المهم للمهمة الذي يخدم عشرات ومئات الآلاف من المعاملات في الثانية. وهنا كان علينا حل مشكلة البحث عن الأخطاء وإصلاحها (ما يسمى استكشاف الأخطاء وإصلاحها) في الظروف:
- تحديثات دورية في العمليات
- تطوير قاعدة الناقل
- التغييرات في مجموعة خدمات الاتصالات
نعم ، والشرط المهم الآخر الذي يجب أن نلتزم به هو عدم الإضرار. أو التحدث بلغة الوثائق الرسمية - لتقليل الوقت وتكاليف العمالة في تشغيل أنظمة تكنولوجيا المعلومات لمزود الاتصالات.
السؤال الذي يطرح نفسه - ما هي النسبة التي يجب أن تكون مختلطة معالجة الأخطاء التلقائي ومشاركة الخبراء في استكشاف الأخطاء وإصلاحها. بعد ذلك ، دعونا نتحدث عن الخيارات.
منظمة العفو الدولية
نظرًا لأننا نعيش في عصر الضجيج الأبدي ، فقد قررنا أن نجعل التطوير قاعدة من الذكاء الاصطناعي - بحيث يدرك هذا العقل الأخطاء والشذوذ ويتنبأ بالفشل ويصححها على الفور. الشركات الكبيرة والشركات الناشئة الصغيرة تقوم بالفعل بإنشاء مثل هذه وحتى تنفيذ حلول مماثلة. النطاق الرئيسي لتطبيقها: عمليات بناء وصيانة ودعم البنية التحتية لتكنولوجيا المعلومات. يُطلق على عمليات AIOps - Aritificial Intelligence (لتكنولوجيا المعلومات) ، وأكثر الكلمات الطنانة شيوعًا هي NoOps ، أي عمليات تكنولوجيا المعلومات المؤتمتة بالكامل.
لن يكون تعلم النظام سهلاً ، نظرًا لأن مجموعة البيانات التاريخية محدودة ، فإنه من المكلف إنشاء نسخة دقيقة من المنتج ، وأن أمثلة التدريس (التعلم النشط) طويلة جدًا ، وفي حالتنا ، غير دقيقة. يمكنك تجربة طريقة تجميع bootstrap - لمحاكاة مجموعة محدودة من السيناريوهات للحالات المعروفة والمشتبه فيها وإنشاء شجرة قرارات بناءً على ذلك ، على سبيل المثال ، شجرة التصنيف والانحدار ، لكنها أيضًا طريقة مكلفة. ولكن إذا فعلنا كل هذا ، فسنجعل البرنامج يفكر فينا ونوفر مجموعة من الموارد المفيدة (والتي تعني من الإدارة إلى البشرية ، وتعني "إطلاق النار على أكثر مسؤولي النظام إزعاجًا").
سلبيات:
- نظرًا لتعقيد الأنظمة وتفاعلها ، من المستحيل عملياً إنشاء وتدريب إصدار معين "محاصر" من هذا الحل لجميع المواقف الممكنة. بالنسبة لكل مشروع جديد ، ستكون هذه "الدورة التدريبية" المنفصلة الخاصة بها ، مع الاعتراف بالأخطاء المحددة والشذوذ والطرق المناسبة لحلها.
- نحن لا نصمم حلاً جماعياً ، بل حل داخلي لعدد محدود من التطبيقات (لأن هناك عددًا قليلًا جدًا من المشغلين بهذا الحجم في العالم). يمكن أن تتحول بسهولة حتى يكون من الأفضل اقتصاديًا تقديم الاستعانة بمصادر خارجية بشرية مناسبة لحل مثل هذه المشكلات.
- ربما يكون من المحتمل أن يتقبل عملاؤنا تكاليف المهندسين الجدد المؤهلين تأهيلا عاليا أكثر من قبول مخاطر نقل دعم المنتج إلى الذكاء الاصطناعي. بعبارة ملطفة ، يمكن أن يثير هذا بعض المخاوف.
ليس أنا العقول لي
بما أنه لا يمكن الاستغناء عن التدخل البشري ، فقد سلكنا الطريقة القديمة. تذكر ، بمجرد أن اعتقدنا أن "الآلة يجب أن تعمل ، ويجب أن يفكر الشخص"؟ لقد أعدنا صياغة هذا: "يجب أن يحل البرنامج المشكلات المعروفة ، ويجب على المهندس حل المشكلات المجهولة".
لقد أنشأنا نظام حسابي منظم في مفهوم التعلم المعزز ، ولكن مع منطق واضح. يتم تدريب النظام في وحدة تخزين ضيقة يتم التحكم فيها ، ويتم تخزين القواعد بشفافية ، ويمكن تحريرها وتوسيع نطاقها وتحديدها وتعطيلها ، إلخ. مثل هذا التطور ليس أكثر تعقيدًا من مجرد "شبه أتمتة" بسيط. لا يزال هناك حاجة إلى مهندس مؤهل للتشغيل ، ولكن موارده تستخدم فقط لتحديد وحل المشكلات الجديدة. إذا التزمنا التزاما راسخا بمبدأ "ينبغي ألا يحل الشخص المشاكل المعروفة" ، يمكننا أن نفترض أنه بعد مرور بعض الوقت سوف تبدأ إمدادات المشاكل غير المعروفة في التلاشي ، وستقترب وظائف النظام المطور من الذكاء الاصطناعي في هذا المجال المعين من التطبيق.
الجزء الأكثر أهمية في مثل هذا النظام هو تصنيف ، إعادة تحديد الشذوذ. لدى شركتنا بالفعل نظام مشابه - Order Tracker ، والذي يستخدم لمراقبة العمليات التجارية لمشغل إدارة المحمول. يقوم Order Tracker بتحليل مئات الأحداث في الثانية ، ويحدد الحالات الشاذة في كل من الصفوف المنفصلة وفي مجموعات الأحداث ، ويمكّن المستخدم من تجميعها ، وتحديد القيم القصوى والدنيا ، وتحديد أخطاء مستويات الخطورة المختلفة ، واقتراح إجراءات لحل المشكلات. كان النظام يعمل لفترة طويلة ، وقد تم بالفعل العديد من مكابس بنجاح ، لذلك أخذناه كأداة للتصنيف.
الآن كان من الضروري لأتمتة حل المشاكل. على عكس إدارة الطلبات ، حيث غالبًا ما يكون تدخل المشغل مطلوبًا (على سبيل المثال ، عندما تحتاج إلى إشراك الإدارة المالية وخدمة العملاء وما إلى ذلك) ، لدينا القدرة على حل جزء كبير من الحوادث تلقائيًا وهناك أداة جاهزة لتصميم هذه الحلول - نصوص برمجية جاهزة ، والتي يمكن استكمالها ، المنطق الموسع ، تشمل عمليات فحص إضافية وربطها بكل فئة من الأخطاء المعروفة.
ما يمكن أن يحدث الخطأ؟
هذا كل شئ!
عادةً لا يتطلب نظام مراقبة الطلبات اتخاذ القرارات والتصحيح في الوقت الفعلي ، وأي شذوذ يؤثر على عدد محدود من العملاء ، من واحد إلى عدة مئات. نحاول تقديم معالجة تلقائية للأخطاء في العمليات التي تؤثر على مئات الآلاف والملايين من المشتركين وتتطلب حلاً في الوقت الفعلي أو في غضون ساعات قليلة. هذا خطر كبير على أي مشغل نتعامل معه ، وبالتالي ، بالنسبة لسمعتنا.
لقد اضطررنا إلى زيادة مرونة البرامج النصية بشكل كبير ، وتطبيق نظام للتحكم في الإصدار ، وإضافة "نسخة البرنامج النصي" للكيان ، أي أنه يمكنك الآن إنشاء كل فئة فرعية لكل مجموعة نصية تحتوي على مجموعات معينة من المعلمات ، والعتبات ، وعمليات فحص إضافية ، إلخ. اضطررت إلى زيادة مرونة العديد من المهام من خلال إدخال اختبارات إضافية لمعلمات الإدخال والإخراج.
هناك اتجاه تطوير آخر يتمثل في زيادة تفصيل فئات الأحداث التي تم تحليلها وإنشاء فئات تعريف ، أي مجموعات من الأحداث المختلفة التي يحددها المصنف. أضفنا تقديرا لتسلسل الحالات الشاذة وتزامن مختلف الحالات الشاذة في الوقت المناسب. أصبح النظام أكثر تعقيدًا ، لكنه لا يزال يحتفظ بمنطق واضح - بالنسبة لأي زوج من "فئة الحالات الشاذة - سيناريو محدد" ، لا تزال العلاقات السببية محفوظة.
بالنسبة للعديد من المجموعات ، حصلنا بالفعل على نتائج موثوقة وموثوقة وأصدرناها بطريقة مثمرة. الأخطاء ، البحث والتصحيح الذي استغرق ساعات في السابق ، يتم الآن حلها في الوضع التلقائي. بالنسبة للأنواع الأخرى من الحالات الشاذة ، ما زلنا نواصل الاختبار: في مكان ما على بيانات الاختبار ، في مكان ما في وضع التحقق اليدوي وتأكيد السيناريو المحدد.
ثم اتضح ...
لقد أدركنا مؤخرًا أننا حصلنا على نتيجة من هذه الأعمال التي لم نكن نتوقعها في البداية - وهي أداة فعالة للغاية للهندسة العكسية لأشخاص آخرين ، بما في ذلك الحلول التي لا نوفر لها الدعم من المطورين ، ولا حتى الوثائق الواضحة. عن غير قصد ، تم تنفيذ ما يسمى "اكتشاف عملية الأعمال". لقد تعلمنا في الممارسة العملية تحليل منطق التطبيقات ، لتحديد الأخطاء الداخلية ومشاكل التكامل مع الأنظمة الأخرى. الآن لا يمكننا فقط تنظيم تطبيقات الآخرين - يمكننا تطوير إصلاحات لهم ، وتحسين التكامل ، والشيء الأكثر قيمة هو تقديم منتجاتنا لتحل محل الإرث الحالي.
في المرحلة التالية ، نريد أن نحاول تنفيذ حلنا كمنتج شامل لاختبار التكامل ، والذي سيكتشف تلقائيًا الأخطاء والشذوذ ، ويتعلم على الفور ، ويوفر أدوات لتصحيح الأعراض وللبحث وتحليل المشكلات في منطق التطبيق. لن يكون لهذا الحل كفاءة أقل من AIOps و NoOps العصرية ، بينما نحافظ على منطق القرار الشفاف والقابل للإدارة. لذلك إذا واجهت مثل هذا الحل في غضون بضع سنوات من Netcracker في السوق ، فضع في اعتبارك - كل ذلك بدأ مرة واحدة بنصوص bash ...