النمذجة الصحية ومراقبة أحمال العمل الحرجة للمهام على Azure

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

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

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

هام

هذه المقالة هي جزء من سلسلة حمل العمل الحرجة للمهام Well-Architected Azure . إذا لم تكن على دراية بهذه السلسلة، نوصيك بالبدء بما هو حمل العمل الحرج للمهمة؟

هناك ثلاثة مستويات رئيسية من النضج التشغيلي عند السعي لتحقيق أقصى قدر من الموثوقية.

1. الكشف عن المشكلات والاستجابة لها عند حدوثها.
2. تشخيص المشكلات التي تحدث أو التي حدثت بالفعل.
3. توقع المشكلات ومنعها قبل حدوثها.

فيديو: تحديد نموذج صحي لحمل العمل الحرج للمهمة

صحة التطبيق متعدد الطبقات

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

هام

عند تحديد الحالات "غير الصحية"، تمثل لجميع مستويات التطبيق. من المهم التمييز بين حالات الفشل العابرة وغير العابرة لتأهيل تدهور الخدمة بالنسبة لعدم التوفر.

اعتبارات التصميم

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

• يعتمد نموذج الصحة بشكل كامل على سياق الحل الذي يمثله، وبالتالي لا يمكن حله "خارج الصندوق" لأن "حجم واحد لا يناسب الجميع".

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

• يتيح نموذج صحة الطبقات تتبع صحة التطبيق مرة أخرى إلى تبعيات المستوى الأدنى، ما يساعد على الجذر السريع لتدهور الخدمة.

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

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

  • قد لا يمكن ملاحظة مثل هذه الأخطاء على الفور.

توصيات التصميم

• حدد نموذجا صحيا قابلا للقياس كأولوية لضمان فهم تشغيلي واضح للتطبيق بأكمله.

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

• تمثيل الحالات الصحية باستخدام درجة صحية دقيقة لكل مكون تطبيق مميز وكل تدفق مستخدم عن طريق تجميع درجات الصحة للمكونات التابعة المعينة، مع مراعاة المتطلبات الرئيسية غير الوظيفية كمعاملات.

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

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

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

• استخدم النموذج الصحي لحساب تحقيق هدف مستوى الخدمة (SLO) للتوفر بدلا من التوفر البسيط، مما يضمن أن ينعكس الترسيم بين تدهور الخدمة وعدم التوفر كوحدات SLOs منفصلة.

• استخدم نموذج الصحة داخل البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD ودورات الاختبار للتحقق من صحة التطبيق يتم الاحتفاظ بها بعد تحديثات التعليمات البرمجية والتكوين.

  • يجب استخدام نموذج الصحة لمراقبة الصحة والتحقق من صحتها أثناء اختبار التحميل واختبار الفوضى كجزء من عمليات CI/CD.

• يعد بناء نموذج صحي وصيانته عملية متكررة وينبغي مواءمة الاستثمار الهندسي لدفع التحسينات المستمرة.

  • حدد عملية لتقييم دقة النموذج وضبطها باستمرار، والنظر في الاستثمار في نماذج التعلم الآلي لزيادة تدريب النموذج.

مثال - نموذج صحة الطبقات

هذا تمثيل مبسط لنموذج صحة التطبيق متعدد الطبقات لأغراض توضيحية. يتم توفير نموذج صحي شامل وسياقي في عمليات التنفيذ المرجعية Mission-Critical:

• مهمة حرجة عبر الإنترنت
• متصل بالغ الأهمية للمهمة

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

يمكن تمثيل تعريف الصحة هذا لاحقا بواسطة استعلام KQL، كما هو موضح في استعلام المثال أدناه الذي يجمع InsightsMetrics (نتائج تحليلات الحاوية) وAzureMetrics (إعداد التشخيص لمجموعة AKS) ويقارن (الصلة الداخلية) مع حدود الصحة النموذجية.

// ClusterHealthStatus
let Thresholds=datatable(MetricName: string, YellowThreshold: double, RedThreshold: double) [
    // Disk Usage:
    "used_percent", 50, 80,
    // Average node cpu usage %:
    "node_cpu_usage_percentage", 60, 90,
    // Average node disk usage %:
    "node_disk_usage_percentage", 60, 80,
    // Average node memory usage %:
    "node_memory_rss_percentage", 60, 80
    ];
InsightsMetrics
| summarize arg_max(TimeGenerated, *) by Computer, Name
| project TimeGenerated,Computer, Namespace, MetricName = Name, Value=Val
| extend NodeName = extract("([a-z0-9-]*)(-)([a-z0-9]*)$", 3, Computer)
| union (
    AzureMetrics
    | extend ResourceType = extract("(PROVIDERS/MICROSOFT.)([A-Z]*/[A-Z]*)", 2, ResourceId)
    | where ResourceType == "CONTAINERSERVICE/MANAGEDCLUSTERS"
    | summarize arg_max(TimeGenerated, *) by MetricName
    | project TimeGenerated, MetricName, Namespace = "AzureMetrics", Value=Average
    )
| lookup kind=inner Thresholds on MetricName
| extend IsYellow = iff(Value > YellowThreshold and Value < RedThreshold, 1, 0)
| extend IsRed = iff(Value > RedThreshold, 1, 0)
| project NodeName, MetricName, Value, YellowThreshold, IsYellow, RedThreshold, IsRed

يمكن تحويل إخراج الجدول الناتج لاحقا إلى درجة صحية لتسهيل التجميع على مستويات أعلى من نموذج الصحة.

// ClusterHealthScore
ClusterHealthStatus
| summarize YellowScore = max(IsYellow), RedScore = max(IsRed)
| extend HealthScore = 1-(YellowScore*0.25)-(RedScore*0.5)

يمكن تمثيل هذه الدرجات المجمعة لاحقا كمخطط تبعية باستخدام أدوات التصور مثل Grafana لتوضيح نموذج الصحة.

تعرض هذه الصورة مثالا لنموذج صحة الطبقات من تطبيق مرجع Azure Mission-Critical عبر الإنترنت، وتوضح كيف يمكن أن يكون للتغيير في الحالة الصحية لمكون أساسي تأثير متتالي على تدفقات المستخدم وصحة التطبيق العامة (تتوافق قيم المثال مع الجدول في الصورة السابقة).

فيديو تجريبي: عرض توضيحي للرصد والنمذجة الصحية

متلقي البيانات الموحد للتحليل المترابط

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

مطلوب متلقي بيانات موحد لضمان تخزين جميع البيانات التشغيلية بسرعة وإتاحتها للتحليل المترابط لإنشاء تمثيل "جزء واحد" لصحة التطبيق. يوفر Azure العديد من التقنيات التشغيلية المختلفة تحت مظلة Azure Monitor، وتعمل مساحة عمل Log Analytics كمتلقي بيانات Azure الأصلي الأساسي لتخزين البيانات التشغيلية وتحليلها.

اعتبارات التصميم

Azure Monitor

• يتم تمكين Azure Monitor بشكل افتراضي لجميع اشتراكات Azure، ولكن يجب نشر سجلات Azure Monitor (مساحة عمل Log Analytics) وموارد Application Insights وتكوينها لدمج إمكانات جمع البيانات والاستعلام.

• يدعم Azure Monitor ثلاثة أنواع من بيانات إمكانية المراقبة: السجلات والمقاييس والتتبعات الموزعة.

  • يتم تخزين السجلات في مساحات عمل Log Analytics، والتي تستند إلى Azure Data Explorer. يتم تخزين استعلامات السجل في حزم الاستعلام التي يمكن مشاركتها عبر الاشتراكات، وتستخدم لدفع مكونات إمكانية المراقبة مثل لوحات المعلومات أو المصنفات أو أدوات إعداد التقارير والتصور الأخرى.
  • يتم تخزين المقاييس في قاعدة بيانات سلسلة زمنية داخلية. بالنسبة لمعظم موارد Azure، يتم جمع المقاييس تلقائيا والاحتفاظ بها لمدة 93 يوما. يمكن أيضا إرسال البيانات القياسية إلى مساحة عمل Log Analytics باستخدام إعداد تشخيص للمورد.

• تعرض جميع موارد Azure السجلات والمقاييس، ولكن يجب تكوين الموارد بشكل مناسب لتوجيه البيانات التشخيصية إلى متلقي البيانات المطلوب.

تلميح

يوفر Azure العديد من النهج المضمنة التي يمكن تطبيقها لضمان تكوين الموارد المنشورة لإرسال السجلات والمقاييس إلى مساحة عمل Log Analytics.

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

• قد تتطلب أنواع البيانات التشغيلية المختلفة فترات استبقاء مختلفة. على سبيل المثال، قد تحتاج سجلات الأمان إلى الاحتفاظ بها لفترة طويلة، بينما من غير المحتمل أن تتطلب بيانات الأداء استبقاء طويل الأجل خارج سياق AIOps.

• يمكن أرشفة البيانات أو تصديرها من مساحات عمل Log Analytics لأغراض الاستبقاء و/أو التدقيق على المدى الطويل.

• توفر المجموعات المخصصة خيار توزيع يتيح مناطق التوفر للحماية من حالات الفشل المناطقية في مناطق Azure المدعومة. تتطلب المجموعات المخصصة الحد الأدنى من الالتزام اليومي لاستيعاب البيانات.

• يتم نشر مساحات عمل Log Analytics في منطقة Azure محددة.

• للحماية من فقدان البيانات من عدم توفر مساحة عمل Log Analytics، يمكن تكوين الموارد بإعدادات تشخيص متعددة. يمكن لكل إعداد تشخيص إرسال المقاييس والسجلات إلى مساحة عمل Log Analytics منفصلة.

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

• يمكن تصدير بيانات مساحة عمل Log Analytics إلى Azure Storage أو Azure Event Hubs على أساس مستمر أو مجدول أو لمرة واحدة.

  • يسمح تصدير البيانات لأرشفة البيانات على المدى الطويل ويحمي من فقدان البيانات التشغيلية المحتمل بسبب عدم التوفر.
  • وجهات التصدير المتوفرة هي Azure Storage أو Azure Event Hubs. يمكن تكوين Azure Storage لمستوي تكرار مختلف بما في ذلك النطاقي أو الإقليمي. تصدير البيانات إلى Azure Storage يخزن البيانات داخل ملفات .json.
  • يجب أن تكون وجهات تصدير البيانات داخل نفس منطقة Azure مثل مساحة عمل Log Analytics. وجهة تصدير بيانات مركز الأحداث لتكون داخل نفس منطقة مساحة عمل Log Analytics. لا ينطبق الإصلاح بعد كارثة الجغرافية لمراكز الأحداث على هذا السيناريو.
  • هناك العديد من قيود تصدير البيانات. يتم دعم جداول معينة فقط في مساحة العمل لتصدير البيانات.
  • يمكن استخدام الأرشفة لتخزين البيانات في مساحة عمل Log Analytics للاحتفاظ بها على المدى الطويل بتكلفة مخفضة دون تصديرها.

• تحتوي سجلات Azure Monitor على حدود تقييد استعلام المستخدم، والتي قد تظهر على أنها توفر أقل للعملاء، مثل لوحات معلومات إمكانية المراقبة.

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

• حزم الاستعلام هي موارد Azure Resource Manager، والتي يمكن استخدامها لحماية استعلامات السجل واستردادها إذا كانت مساحة عمل Log Analytics غير متوفرة.

  • تحتوي حزم الاستعلام على استعلامات ك JSON ويمكن تخزينها خارج Azure على غرار أصول البنية الأساسية كتعلم برمجية أخرى.
    • قابل للنشر من خلال Microsoft.Insights REST API.
    • إذا كان يجب إعادة إنشاء مساحة عمل Log Analytics، يمكن إعادة توزيع حزمة الاستعلام من تعريف مخزن خارجيا.

• يمكن نشر Application Insights في نموذج توزيع يستند إلى مساحة العمل، مدعوما بمساحة عمل Log Analytics حيث يتم تخزين جميع البيانات.

• يمكن تمكين أخذ العينات داخل Application Insights لتقليل مقدار بيانات تتبع الاستخدام المرسلة وتحسين تكاليف استيعاب البيانات.

• يتم فرض رسوم على جميع البيانات التي تم جمعها بواسطة Azure Monitor، بما في ذلك Application Insights، استنادا إلى حجم البيانات التي تم استيعابها ومدة الاحتفاظ بالبيانات.

  • يمكن الاحتفاظ بالبيانات التي تم إدخالها في مساحة عمل Log Analytics دون أي رسوم إضافية حتى أول 31 يوما (90 يوما إذا تم تمكين Sentinel)
  • يتم الاحتفاظ بالبيانات التي تم استيعابها في Application Insights المستندة إلى مساحة العمل لأول 90 يوما دون أي رسوم إضافية.

• يوفر نموذج تسعير مستوى التزام Log Analytics تكلفة مخفضة ونهجا يمكن التنبؤ به لاستيعاب البيانات.

  • تتم فوترة أي استخدام أعلى من مستوى الحجز بنفس سعر المستوى الحالي.

• يستخدم Log Analytics وApplication Insights وAzure Data Explorer لغة استعلام Kusto (KQL).

• يتم حفظ استعلامات Log Analytics كوظائف داخل مساحة عمل Log Analytics (savedSearches).

توصيات التصميم

• استخدم مساحة عمل Log Analytics كمتلقي بيانات موحد لتوفير "جزء واحد" عبر جميع مجموعات البيانات التشغيلية.

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

• ضع في اعتبارك تكوين الموارد بإعدادات تشخيص متعددة تشير إلى مساحات عمل Log Analytics مختلفة للحماية من عدم توفر Azure Monitor للتطبيقات ذات طوابع النشر الإقليمية الأقل.

• استخدم Application Insights كأداة متسقة لمراقبة أداء التطبيق (APM) عبر جميع مكونات التطبيق لجمع سجلات التطبيق والمقاييس والتتبعات.

  • انشر Application Insights في تكوين يستند إلى مساحة العمل للتأكد من أن كل مساحة عمل إقليمية لتحليلات السجل تحتوي على سجلات ومقاييس من كل من مكونات التطبيق وموارد Azure الأساسية.

• استخدم الاستعلامات عبر مساحة العمل للحفاظ على "جزء واحد" موحد عبر مساحات العمل المختلفة.

• استخدم حزم الاستعلام لحماية استعلامات السجل في حالة عدم توفر مساحة العمل.

  • تخزين حزم الاستعلام داخل مستودع git للتطبيق كأصول البنية الأساسية كتعليق برمجي.

• يجب التعامل مع جميع مساحات عمل Log Analytics على أنها موارد طويلة الأمد مع دورة حياة مختلفة لموارد التطبيق داخل طابع توزيع إقليمي.

• تصدير البيانات التشغيلية الهامة من مساحة عمل Log Analytics للاحتفاظ والتحليلات على المدى الطويل لتسهيل AIOps والتحليلات المتقدمة لتحسين نموذج الصحة الأساسي وإبلاغ الإجراء التنبؤي.

• تقييم مخزن البيانات الذي يجب استخدامه لاستبقاء البيانات على المدى الطويل بعناية؛ لا يجب تخزين جميع البيانات في مخزن بيانات ساخن وقابل للاستعلام.

  • يوصى بشدة باستخدام Azure Storage في تكوين GRS لتخزين البيانات التشغيلية على المدى الطويل.
    • استخدم إمكانية تصدير مساحة عمل Log Analytics لتصدير جميع مصادر البيانات المتوفرة إلى Azure Storage.

• حدد فترات الاستبقاء المناسبة أنواع البيانات التشغيلية داخل تحليلات السجل، وتكوين فترات استبقاء أطول داخل مساحة العمل حيث توجد متطلبات إمكانية المراقبة "الساخنة".

• استخدم نهج Azure لضمان توجيه جميع الموارد الإقليمية للبيانات التشغيلية إلى مساحة عمل Log Analytics الصحيحة.

ملاحظة

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

إذا كان تكامل SIEM مطلوبا، فلا ترسل إدخالات السجل الأولية، ولكن بدلا من ذلك أرسل تنبيهات مهمة.

• تكوين أخذ العينات داخل Application Insights فقط إذا كان مطلوبا لتحسين الأداء، أو إذا لم يكن أخذ العينات يصبح باهظ التكلفة.

  • يمكن أن يؤدي أخذ العينات المفرط إلى إشارات تشغيلية فائتة أو غير دقيقة.

• استخدم معرفات الارتباط لجميع أحداث التتبع ورسائل السجل لربطها بطلب معين.

  • إرجاع معرفات الارتباط إلى المتصل لجميع المكالمات وليس فقط الطلبات الفاشلة.

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

  • يجب أن تستخدم التعليمات البرمجية للتطبيق Application Insights لتسهيل التتبع الموزع، من خلال تزويد المتصل برسالة خطأ شاملة تتضمن معرف ارتباط عند حدوث فشل.

• استخدم التسجيل المنظم لجميع رسائل السجل.

• أضف تحقيقات صحية ذات معنى إلى جميع مكونات التطبيق.

  • عند استخدام AKS، قم بتكوين نقاط النهاية الصحية لكل عملية نشر (pod) بحيث يمكن ل Kubernetes تحديد متى يكون الجراب سليما أو غير صحي بشكل صحيح.
  • عند استخدام Azure App Service، قم بتكوين Health Checks بحيث لا تتسبب عمليات توسيع النطاق في حدوث أخطاء عن طريق إرسال نسبة استخدام الشبكة إلى مثيلات غير جاهزة بعد، والتأكد من إعادة تدوير المثيلات غير الصحية بسرعة.

إذا كان التطبيق مشتركا في دعم Microsoft Mission-Critical، ففكر في الكشف عن فحوصات السلامة الرئيسية لدعم Microsoft، بحيث يمكن تصميم سلامة التطبيق بشكل أكثر دقة بواسطة دعم Microsoft.

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

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

  • في البيئات الأقل، مثل التطوير والاختبار، يمكن اعتبار الحد الأقصى اليومي آلية اختيارية لتوفير التكاليف.

• وحدات تخزين استيعاب البيانات التشغيلية المقدمة تفي بالحد الأدنى من المستوى، وتكوين مساحات عمل Log Analytics لاستخدام التسعير المستند إلى مستوى الالتزام لدفع كفاءات التكلفة بالنسبة إلى نموذج التسعير "الدفع أولا بأول".

• يوصى بشدة بتخزين استعلامات Log Analytics باستخدام التحكم بالمصادر واستخدام أتمتة CI/CD لتوزيعها في مثيلات مساحة عمل Log Analytics ذات الصلة.

عرض البيانات بشكل بياني

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

توفر Microsoft العديد من تقنيات تصور البيانات، بما في ذلك لوحات معلومات Azure وPower BI وAzure Managed Grafana (قيد المعاينة حاليا). تم وضع لوحات معلومات Azure لتوفير حل مرئي متكامل بإحكام للبيانات التشغيلية داخل Azure Monitor. ولذلك فإن له دورا أساسيا يؤديه في التمثيل المرئي للبيانات التشغيلية وصحة التطبيقات لحمل عمل بالغ الأهمية للمهمة. ومع ذلك، هناك العديد من القيود من حيث تحديد موضع لوحات معلومات Azure كمنصة مراقبة شاملة، ونتيجة لذلك يجب مراعاة الاستخدام التكميلي لحلول المراقبة الرائدة في السوق، مثل Grafana، والتي يتم توفيرها أيضا كحل مدار داخل Azure.

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

اعتبارات التصميم

• عند تصور النموذج الصحي باستخدام استعلامات السجل، لاحظ أن هناك حدود Log Analytics على الاستعلامات المتزامنة والمسجلة في قائمة الانتظار، بالإضافة إلى معدل الاستعلام الإجمالي، مع وضع الاستعلامات اللاحقة في قائمة الانتظار وتقييدها.

• يمكن كتابة الاستعلامات لاسترداد البيانات التشغيلية المستخدمة لحساب الدرجات الصحية وتمثيلها وتنفيذها إما في Log Analytics أو Azure Data Explorer.

  • تتوفر نماذج الاستعلامات هنا.

• تفرض Log Analytics عدة حدود للاستعلام، والتي يجب تصميمها عند تصميم لوحات المعلومات التشغيلية.

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

• إذا كان العديد من المستخدمين يستخدمون لوحات المعلومات داخل أداة مثل Grafana، فإن عدد الاستعلامات المرسلة إلى Log Analytics يتضاعف بسرعة.

  • سيؤدي الوصول إلى حد الاستعلام المتزامن على Log Analytics إلى وضع الاستعلامات اللاحقة في قائمة الانتظار، ما يجعل تجربة لوحة المعلومات تبدو "بطيئة".

توصيات التصميم

• جمع وتقديم المخرجات التي تم الاستعلام عنها من جميع مساحات عمل Log Analytics الإقليمية ومساحة عمل Log Analytics العمومية لإنشاء عرض موحد لصحة التطبيق.

ملاحظة

إذا كان التوزيع في منطقة هبوط Azure، ففكر في الاستعلام عن مساحة عمل Log Analytics للنظام الأساسي المركزي إذا كانت هناك تبعيات رئيسية على موارد النظام الأساسي، مثل ExpressRoute للاتصال المحلي.

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

• استخدم لوحات معلومات Azure لإنشاء عدسات تشغيلية للموارد العالمية وطوابع التوزيع الإقليمية، التي تمثل المقاييس الرئيسية مثل عدد الطلبات ل Azure Front Door، وزمن الانتقال من جانب الخادم ل Azure Cosmos DB، والرسائل الواردة/الصادرة لمراكز الأحداث، واستخدام وحدة المعالجة المركزية أو حالات التوزيع ل AKS. يجب تصميم لوحات المعلومات لدفع الفعالية التشغيلية، وغرس التعلم من سيناريوهات الفشل لضمان حصول فرق DevOps على رؤية مباشرة للمقاييس الرئيسية.

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

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

  • قم بفصل حالة التكوين إلى مخزن بيانات خارجي، مثل قاعدة بيانات Azure ل Postgres أو MySQL، لضمان بقاء عقد تطبيق Grafana عديمة الحالة.

    • تكوين النسخ المتماثل لقاعدة البيانات عبر مناطق التوزيع.

  • توزيع عقد Grafana إلى App Services في تكوين متوفر بشكل كبير عبر تلك الموجودة داخل منطقة ما، باستخدام عمليات التوزيع المستندة إلى الحاوية.

    • توزيع مثيلات App Service عبر مناطق التوزيع المدروسة.

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

  • استخدم Azure Storage في تكوين GRS لاستضافة وإدارة المرئيات والمكونات الإضافية المخصصة.

  • انشر مكونات Grafana لخدمة التطبيق والنسخة المتماثلة للقراءة لقاعدة البيانات إلى منطقتين للتوزيع كحد أدنى، وفكر في استخدام نموذج حيث يتم نشر Grafana في جميع مناطق النشر المدروسة.

بالنسبة للسيناريوهات التي تستهدف >SLO = 99.99٪، يجب توزيع Grafana ضمن 3 مناطق توزيع كحد أدنى لزيادة الموثوقية الإجمالية للوحات المعلومات التشغيلية الرئيسية.

• التخفيف من حدود استعلام Log Analytics عن طريق تجميع الاستعلامات في عدد واحد أو صغير من الاستعلامات، مثل استخدام عامل تشغيل KQL "union"، وتعيين معدل تحديث مناسب على لوحة المعلومات.

  • يعتمد الحد الأقصى المناسب لمعدل التحديث على عدد وتعقيد استعلامات لوحة المعلومات؛ مطلوب تحليل الاستعلامات المنفذة.

• إذا تم الوصول إلى حد الاستعلام المتزامن لتحليلات السجل، ففكر في تحسين نمط الاسترداد عن طريق تخزين البيانات المطلوبة للوحة المعلومات (مؤقتا) في مخزن بيانات عالي الأداء مثل Azure SQL.

الاستجابة التلقائية للحوادث

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

يوفر Azure Monitor إطار عمل تنبيه واسع النطاق للكشف عن الإشارات التشغيلية وتصنيفها والاستجابة لها من خلال مجموعات العمل. لذلك سيركز هذا القسم على استخدام تنبيهات Azure Monitor لدفع الإجراءات التلقائية استجابة للانحرافات الحالية أو المحتملة عن حالة تطبيق سليمة.

هام

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

اعتبارات التصميم

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

• يمكن تعريف التنبيهات داخل Log Analytics أو Azure Monitor على مورد معين.

• بعض المقاييس قابلة للاستجواب فقط داخل Azure Monitor، حيث لا يتم توفير جميع نقاط البيانات التشخيصية داخل Log Analytics.

• يمكن استخدام واجهة برمجة تطبيقات تنبيهات Azure Monitor لاسترداد التنبيهات النشطة والتاريخية.

• هناك حدود للاشتراك تتعلق بمجموعات التنبيه والإجراءات، والتي يجب تصميمها من أجل:

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

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

توصيات التصميم

• للتنبيه الذي يركز على الموارد، قم بإنشاء قواعد تنبيه داخل Azure Monitor لضمان توفر جميع البيانات التشخيصية لمعايير قاعدة التنبيه.

• دمج الإجراءات التلقائية ضمن الحد الأدنى من مجموعات الإجراءات، تتماشى مع فرق الخدمة لدعم نهج DevOps.

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

• إجراءات نموذجية لاستيعاب ترتيب حسب الأولوية، والذي يجب تحديده من خلال تأثير الأعمال.

• استخدم واجهة برمجة تطبيقات تنبيهات Azure Monitor لجمع التنبيهات التاريخية لتضمينها داخل التخزين التشغيلي "البارد" للتحليلات المتقدمة.

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

• إنشاء بدلات داخل الدورات المتكررة الهندسية لدفع التحسينات المتزايدة في التنبيه لضمان إمكانية استيعاب سيناريوهات الفشل الجديدة التي لم يتم النظر فيها مسبقا بشكل كامل ضمن الإجراءات التلقائية الجديدة.

• إجراء اختبارات الاستعداد التشغيلي كجزء من عمليات CI/CD للتحقق من صحة قواعد التنبيه الرئيسية لتحديثات التوزيع.

الإجراءات التنبؤية وعمليات الذكاء الاصطناعي (AIOps)

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

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

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

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

اعتبارات التصميم

• يوفر Azure Synapse Analytics قدرات متعددة للتعلم الآلي (ML).

  • يمكن تدريب نماذج التعلم الآلي وتشغيلها على تجمعات Synapse Spark مع مكتبات بما في ذلك MLLib وSparkML وMMLSpark، بالإضافة إلى المكتبات الشائعة مفتوحة المصدر، مثل Scikit Learn.
  • يمكن تدريب نماذج التعلم الآلي باستخدام أدوات علوم البيانات الشائعة مثل PySpark/Python أو Scala أو .NET.

• تم دمج Synapse Analytics مع التعلم الآلي من Microsoft Azure من خلال دفاتر ملاحظات Azure Synapse، والتي تمكن نماذج التعلم الآلي من التدريب في مساحة عمل التعلم الآلي من Microsoft Azure باستخدام التعلم الآلي التلقائي.

• يتيح Synapse Analytics أيضا قدرات التعلم الآلي باستخدام خدمات Azure المعرفية لحل المشكلات العامة في مجالات مختلفة، مثل الكشف عن الحالات الخارجة عن المألوف. يمكن استخدام الخدمات المعرفية في Azure Synapse وAzure Databricks وعبر SDKs وواجهات برمجة تطبيقات REST في تطبيقات العميل.

• يتكامل Azure Synapse في الأصل مع أدوات Azure Data Factory لاستخراج البيانات وتحويلها وتحميلها (ETL) أو استيعابها داخل مسارات التنسيق.

• يتيح Azure Synapse تسجيل مجموعة البيانات الخارجية للبيانات المخزنة في تخزين Azure Blob أو Azure Data Lake Storage.

  • يمكن استخدام مجموعات البيانات المسجلة في مهام تحليلات بيانات تجمع Synapse Spark.

• يمكن دمج Azure Databricks في مسارات Azure Synapse Analytics للحصول على إمكانات Spark إضافية.

  • ينسق Synapse قراءة البيانات وإرسالها إلى مجموعة Databricks، حيث يمكن تحويلها وإعدادها لتدريب نموذج التعلم الآلي.

• تحتاج بيانات المصدر عادة إلى الاستعداد للتحليات والتعلم الآلي.

  • يوفر Synapse أدوات مختلفة للمساعدة في إعداد البيانات، بما في ذلك Apache Spark ودفاتر ملاحظات Synapse وتجمعات SQL بلا خادم مع T-SQL والمرئيات المضمنة.

• يمكن استخدام نماذج التعلم الآلي التي تم تدريبها وتشغيلها وتوزيعها لتسجيل الدفعات في Synapse.

  • قد تتطلب سيناريوهات AIOps، مثل تشغيل تنبؤات الانحدار أو التدهور في البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD، تسجيل نقاط في الوقت الحقيقي .

• هناك حدود للاشتراك في Azure Synapse، والتي يجب فهمها بالكامل في سياق منهجية AIOps.

• لدمج AIOps بالكامل، من الضروري تغذية بيانات إمكانية المراقبة في الوقت الفعلي تقريبا في نماذج استدلال التعلم الآلي في الوقت الحقيقي على أساس مستمر.

  • يجب تقييم قدرات مثل الكشف عن الحالات الشاذة داخل دفق بيانات إمكانية المراقبة.

توصيات التصميم

• تأكد من أن جميع موارد Azure ومكونات التطبيق مجهزة بالكامل بحيث تتوفر مجموعة بيانات تشغيلية كاملة لتدريب نموذج AIOps.

• استيعاب البيانات التشغيلية ل Log Analytics من حسابات تخزين Azure العالمية والإقليمية إلى Azure Synapse للتحليل.

• استخدم واجهة برمجة تطبيقات تنبيهات Azure Monitor لاسترداد التنبيهات التاريخية وتخزينها داخل التخزين البارد للبيانات التشغيلية لاستخدامها لاحقا داخل نماذج التعلم الآلي. إذا تم استخدام تصدير بيانات Log Analytics، فخزن بيانات التنبيهات التاريخية في نفس حسابات Azure Storage مثل بيانات Log Analytics المصدرة.

• بعد إعداد البيانات التي تم استيعابها لتدريب التعلم الآلي، اكتبها مرة أخرى إلى Azure Storage بحيث تكون متاحة لتدريب نموذج التعلم الآلي دون الحاجة إلى تشغيل موارد حساب إعداد بيانات Synapse.

• تأكد من أن تشغيل نموذج التعلم الآلي يدعم كلا من تسجيل الدفعات والوقت الحقيقي.

• عند إنشاء نماذج AIOps، قم بتنفيذ MLOps وتطبيق ممارسات DevOps لأتمتة دورة حياة التعلم الآلي للتدريب والتشغيل والتسجيل والتحسين المستمر. إنشاء عملية CI/CD متكررة لنماذج التعلم الآلي من Microsoft Azure AIOps.

• تقييم خدمات Azure المعرفية لسيناريوهات تنبؤية محددة بسبب انخفاض النفقات الإدارية والتكاملية. ضع في اعتبارك الكشف عن الحالات الشاذة لوضع علامة بسرعة على التباينات غير المتوقعة في تدفقات بيانات إمكانية الملاحظة.

الخطوة التالية

راجع اعتبارات التوزيع والاختبار.

التوزيع والاختبار