عمليات تقنية المعلومات بسؤال واحد: فرز وتحقيق وتقرير

ماذا يفعل بوتيفاي في عمليات تقنية المعلومات؟

في عمليات تقنية المعلومات، بوتيفاي مساعد يستدعي الأدوات: يقرأ سؤالا أو تنبيها، ويقرر أي نظام يستعلم منه، ويستدعي واجهة ذلك النظام، ثم يقرأ النتيجة ويقرر السؤال التالي. والأدوات هي نفسها التي يستخدمها فريقك اليوم، مثل منصات المراقبة (Dynatrace وSplunk) ومنصة إدارة الخدمات (ServiceNow) والبريد الإلكتروني.

الفرق عن روبوت المحادثة أن بوتيفاي لا يجيب من ذاكرته. كل معلومة يقدّمها عن بيئتك يجب أن تأتي من استدعاء أداة نفّذه في أثناء التشغيل نفسه، فيمكن التحقق منها. روبوت المحادثة يستطيع أن يشرح معنى «مشكلة» في Dynatrace، أما بوتيفاي فيخبرك بالمشكلات المفتوحة الآن على خدمة الدفع لديك وما الذي تغيّر قبل بدايتها.

عمليا يعمل بوتيفاي كمهندس مناوبة مبتدئ لا يملّ من نسخ المعرّفات بين الشاشات: يجمع الأدلة ويرتبها، ثم يسلّم المهندس الخبير ملخصا قصيرا موثّق المصادر ليتخذ القرار.

ما الفرق بين بوتيفاي وAIOps التقليدي؟

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

يعمل بوتيفاي في طبقة أعلى؛ فهو لا يحل محل رصد الشذوذ بل يستهلك مخرجاته. مشكلة في Dynatrace أو حدث بارز (Notable Event) في Splunk ITSI نقطة انطلاق للوكيل، ثم يجلب النشرات والسجلات وطلبات التغيير والحوادث السابقة من أدوات أخرى لا يراها محرك AIOps أصلا.

ماذا يفعل بوتيفاي فعلا في عمليات تقنية المعلومات؟

بعيدا عن الضجيج التسويقي، هناك أربع مهام يؤديها بوتيفاي بموثوقية اليوم، وأغلبها قراءة وتلخيص، ولهذا فهي آمنة كبداية.

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

كيف يبدو تحقيق عبر بوتيفاي من البداية إلى النهاية؟

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

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

ما الإجراءات المسموح لبوتيفاي بتنفيذها؟

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

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

أين يخطئ بوتيفاي في عمليات تقنية المعلومات؟

الأخطاء متوقعة، ولكل منها حل في التصميم، ولا يكفي تحسين التعليمات وحده لعلاج أي منها.

• اختلاق الأسباب: يملأ النموذج الفراغ بقصة معقولة. اشترط أن تستند كل نتيجة إلى نتيجة أداة محددة، وصنّف كل ما لا دليل عليه كفرضية.
• الاستعلامات المنفلتة: البحث غير المحدود في السجلات بطيء ومكلف. افرض نافذة زمنية إلزامية وحدا أقصى للنتائج في كل أداة بحث.
• اختلاف الأسماء: «checkout» و«checkout-svc-prod» وعنصر إعداد في ServiceNow قد تكون الشيء نفسه. احتفظ بربط لمعرّفات الكيانات عبر الأدوات، ودع شخصا يؤكد كل ربط جديد.
• الخلط بين التزامن والسببية: نشر حدث قرب الحادثة خيط يُتتبَّع لا حكم نهائي. يصف كتاب هندسة موثوقية المواقع من Google استكشاف الأعطال بأنه صياغة فرضيات واختبارها، وهذا الانضباط ينطبق على بوتيفاي أيضا.
• صلاحيات زائدة: يرث بوتيفاي كل ما يستطيعه الرمز المتصل. امنح صلاحيات القراءة افتراضيا، وأضف صلاحيات الكتابة عن قصد.

كيف تبدأ باستخدام بوتيفاي في عمليات تقنية المعلومات؟

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

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