AIOps

لا، ولا ينبغي أن يحاول. تجلس AIOps فوق مراقبتكم القائمة، تستوعب أحداثها وتختصرها إلى ما يمكن التصرّف بشأنه. واستبدالُ قياسٍ يعمل مكلفٌ ونادرًا ما يعالج المشكلة، فالمشكلة عادةً أنّ شيئًا لا يربط بين الأدوات التي تشغّلونها أصلًا.

في أنماط الأعطال المعروفة ذات الاستجابة المبرمَجة والمُختبَرة، نعم — إعادةُ تشغيل خدمةٍ متوقّفة، أو تفريغُ طابور، أو توسيعُ مورد. أمّا المعالجة التلقائيّة لسببٍ استنتجته المنظومة ولم تؤكّده فهي الطريقة التي تتحوّل بها حادثةٌ صغيرة إلى كبيرة. وكلُّ إجراءٍ مؤتمتٍ معتمَدٌ صراحةً ومحدودُ النطاق وقابلٌ للتراجع ومسجَّل.

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

هو أوّل بندٍ في العمل. الربطُ يعتمد على القدرة على القول إنّ تنبيهًا من أداةٍ وسطرَ سجلٍّ من أخرى يشيران إلى الخدمة نفسها، لذا تأتي التسميةُ والمعرّفات المتّسقة قبل أيّ نموذج. ونفضّل إصلاح ذلك على بيع كشفٍ فوق بياناتٍ لا تحتمله.

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

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