الوحدة 10 — المراقبة والحصص والتكاليف

الوحدة 9 أنتجت خطّ معالجة يعمل أسبوعيًّا. يبدو أنّ كلّ شيء ينبغي أن يستقرّ الآن. الوحدة الحالية هي الوعد الذي ينبغي إبقاؤه: أن يعمل النظام دون مفاجآت في الفاتورة، ودون أن يتراجع النموذج بصمت.

مراقبة النموذج (Model Monitoring)

بعد شهر من نشر نموذج تنبّؤ الطلب، الواقع يتغيّر: حملة تسويقية، فصل جديد، منافس جديد. الإدخالات التي رأى النموذج في التدريب لم تعد تُمثّل الإدخالات الحيّة. هذا انزياح البيانات (Data Drift).

Azure ML يوفّر نظام مراقبة مدمج:

# monitoring/drift-monitor.yml
$schema: https://azuremlschemas.azureedge.net/latest/monitorSchedule.schema.json
name: forecast-drift-weekly
trigger:
  type: recurrence
  frequency: week
  interval: 1
create_monitor:
  compute:
    instance_type: standard_ds3_v2
    runtime_version: "3.3"
  monitoring_target:
    endpoint_deployment_id: azureml:demand-forecast-online:blue
  monitoring_signals:
    data_drift:
      type: data_drift
      production_data:
        input_data:
          type: uri_folder
          path: azureml://datastores/inference_logs/paths/blue/
      reference_data:
        input_data:
          type: mltable
          path: azureml:sales_table:2026.36
      alert_enabled: true

النظام يُقارن كلّ أسبوع الإحصائيات على المتغيّرات بين بيانات الإنتاج وبيانات المرجع (التي دُرِّب عليها النموذج). حين يتجاوز اختبار كولموغوروف-سميرنوف عتبةً، يُصدر تنبيهًا على Azure Monitor.

مقياسان مكمّلان:

• انزياح المدخَل (Data drift): تغيّر توزيع المتغيّرات.
• انزياح المخرَج (Prediction drift): تغيّر توزيع التنبّؤات. قد يظهر قبل انهيار الأداء.
• الأداء المباشر: إن كانت الحقائق تتوفّر بسرعة (بيع/عدم بيع)، يُحسَب MAE أسبوعيّ مباشر ويقارَن بحدّ.

Azure Monitor: ما يستحقّ المراقبة

كلّ نقطة نهاية ترسل قياسات تلقائيًّا إلى Application Insights المرافق:

• RequestsPerMinute: لرصد الفيض غير المتوقّع.
• RequestLatency (p50, p95, p99): p99 مؤشّر أفضل من المتوسّط على تجربة المستخدم.
• ModelStatusCode: نسبة 5xx تعني نموذجًا يُعطي أخطاء (مدخلات غير متوقّعة، ذاكرة استُنفدت).
• CpuUtilizationPercentage و**MemoryUtilizationPercentage**: للتوسّع التلقائي.

قواعد التنبيه العملية:

p95 latency > 2 s      pendant 10 min   → تنبيه فوري
5xx rate    > 1%       pendant 5 min    → تنبيه فوري
CPU         > 80%      pendant 15 min   → توسيع العنقود
data drift score > 0.3                  → مراجعة النموذج

الحصص (Quotas)

كلّ اشتراك له حصص على مستوى:

• أنوية VM لكلّ عائلة: Standard DSv2 Family vCPUs مثلًا سقف 100 نواة في westeurope.
• عدد النقاط النهاية المتّصلة: افتراضيًّا 100 لكلّ اشتراك.
• عدد النشرات: 200 لكلّ نقطة نهاية.

عرض الاستعمال:

az ml compute list-usage --location westeurope

طلب زيادة يمرّ عبر بوّابة Azure (Support > New request > Quota). مجاني، لكن يستغرق 24 إلى 48 ساعة. اطلب الزيادة قبل الحاجة، لا في وقت الأزمة.

تحليل التكاليف بالوسوم

المفتاح الأوحد لتحكّم فعلي في التكاليف: الوسم. كلّ مورد Azure يقبل وسومًا (tags) مفتاح/قيمة. اعتماد اتّفاقية مشتركة:

project = demand-forecast
env     = production | staging | dev
team    = data-science
owner   = alice@example.com

طبّق الوسوم عند إنشاء كلّ مورد:

az ml compute create \
  --name cpu-cluster \
  --tags project=demand-forecast env=production team=data-science

ثمّ في Microsoft Cost Management، صنّف الفاتورة الشهرية حسب الوسم:

• حسب project: كم يكلّف كلّ مشروع؟
• حسب env: كم يستهلك التطوير مقابل الإنتاج؟
• حسب team: أيّ فريق يستهلك 40% من ميزانية الشهر؟

بدون وسوم، فاتورة الاشتراك جدول واحد بلا مفاتيح فرز، وأيّ محاولة تحسين هي حَدس.

الميزانيات والتنبيهات

في Cost Management، تُنشَأ ميزانية شهرية لمجموعة موارد أو مجال وسم:

• ميزانية demand-forecast: 500 يورو/شهر.
• تنبيه عند 50% (منتصف الشهر): «الاستهلاك على الطريق العادي».
• تنبيه عند 80%: «تحقّق قبل الفيض».
• تنبيه عند 100%: «أوقف موارد غير ضرورية».

التنبيه بريد إلكتروني إلى فريق. لا يمنع الاستهلاك تلقائيًّا (Azure نادرًا ما يقطع الفوترة)، لكنّه يعطي وقت الردّ.

الإيقاف التلقائي (Auto-shutdown)

الوحدة 2 عرّجت على جدولة إيقاف مثيلات الحساب. لتكرارها لسياق كامل:

# compute/instances/analyst.yml
name: ci-analyst-01
type: computeinstance
size: Standard_DS3_v2
schedules:
  compute_start_stop:
    - action: stop
      cron:
        hours: "19"
        minutes: "0"
        time_zone: "W. Europe Standard Time"
    - action: start
      cron:
        hours: "8"
        minutes: "0"
        week_days: [Monday, Tuesday, Wednesday, Thursday, Friday]

على مستوى المؤسّسة، يستطيع مدير Azure فرض سياسة Azure Policy ترفض إنشاء مثيل حساب بلا جدولة إيقاف. سياسة واحدة تحمي من 90% من نزيف نهاية الشهر.

قراءة الفاتورة الأسبوعية

ممارسة عملية بسيطة: كلّ يوم اثنين صباحًا، افتح Cost Management، قارن استهلاك الأسبوع الماضي بالسابق. كلّ ارتفاع غير مبرَّر ينبغي أن يوضَع اسمه:

• عنقود ترك min_instances = 2 بعد التجربة؟
• مثيل حساب نُسي مفتوحًا في العطلة؟
• نشر جديد لم يحلّ محلّ القديم فتضاعف الاستهلاك؟

خمس عشرة دقيقة أسبوعيًّا تُوفّر آلاف اليوروهات سنويًّا.

اللحظة التي تتأكّد فيها من ميزانيتك هي فاتورة الشهر الأوّل

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

الخلاصة

• مراقبة الانزياح (بيانات وتنبّؤات) والأداء المباشر ينبغي جدولتهما مع النشر، لا بعد شهر.
• Azure Monitor يجمع p95 و5xx والحوسبة؛ اضبط تنبيهات على العتبات الحرجة.
• الحصص إقليمية وطلب زيادتها مجاني لكن يستغرق أيّامًا — اطلب قبل الحاجة.
• الوسوم (project, env, team) شرط لكلّ تحليل تكاليف ذي معنى.
• الميزانيات + التنبيهات + جدولة الإيقاف ثلاثية تحمي من نزيف نهاية الشهر.

نصل الآن إلى نهاية الدورة: المراجعة النهائية تُلخّص الوحدات العشر، وتُعدّك للاختبار وشهادة الإتمام.