ServiceNow ITOM: شرح Discovery وService Mapping ببساطة

فهم الفرق بين ITSM وITOM

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

اضبط المحيط قبل تشغيل Discovery

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

دور خادم MID في البيئات المتأثرة

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

تحديد والتعرف وجمع المعلومات

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

قم بملء CMDB دون مضاعفة التكرارات

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

الانتقال من المورد إلى الخدمة باستخدام تعيين الخدمة

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

مثال: تحليل تأثير قاعدة بيانات غير متوفرة

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

تصميم عملية آمنة وقابلة للصيانة

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

قياس تغطية البطاقة ونضارتها

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

بناء خارطة طريق حسب الخدمة

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

ورشة عمل: التحقق من صحة الاكتشاف في محيط معروف

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

الأسئلة المتداولة: الأتمتة وسبب الحوادث

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

هل يثبت الإدمان سبب الحادثة؟ لا، فهي تشير إلى مسار محتمل للتأثير، يمكن مقارنته بقياسات وأحداث حقيقية.

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