الوحدة 1 — مساحة عمل Azure ML وتنظيم الموارد

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

مساحة العمل: ما هي فعلًا

مساحة عمل Azure ML مورد Azure من نوع Microsoft.MachineLearningServices/workspaces. عمليًّا هي حاوية منطقية تجمع كلّ ما يخصّ مشاريع تعلّم الآلة: التجارب، النماذج، أهداف الحساب، أصول البيانات، نقاط النهاية، والبيئات. تفتحها في Azure ML Studio عبر متصفّح، أو تصل إليها بالبرمجة عبر SDK v2 أو az ml.

عند إنشاء مساحة العمل يُنشئ Azure أربعة موارد مرافقة إلزامية:

المورد	الدور
Storage Account	تخزين البيانات المرفوعة، الدفاتر، السجلّات، مخرجات المهامّ
Key Vault	حفظ المفاتيح والأسرار وسلاسل الاتّصال بأمان
Application Insights	استقبال قياسات وسجلّات نقاط النهاية والمهامّ
Container Registry	تخزين صور conda/Docker التي تُبنى للبيئات

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

إنشاء مساحة العمل بسطر الأوامر

بمجرّد تسجيل الدخول عبر az login، ينشئ الأمر التالي مساحة عمل جاهزة:

az group create --name rg-demand-forecast --location westeurope

az ml workspace create \
  --name aml-demand-forecast \
  --resource-group rg-demand-forecast \
  --location westeurope

يمرّر Azure افتراضيًّا الموارد الأربعة تلقائيًّا. لسيناريو الإنتاج يُفضَّل تحديدها صراحة بمعرّفات الموارد (--storage-account, --key-vault…) لإعادة استعمال موارد موجودة، خاصّة Key Vault مشترك بين عدّة فرق.

الهُويّة المُدارة، لا مفاتيح مبعثرة

كلّ نداء من مساحة العمل نحو مورد آخر (قراءة من Blob، سحب صورة من ACR، كتابة سجلّ) يحتاج تصريحًا. المقاربة الصحيحة هي الهُويّة المُدارة المُعيَّنة من النظام (System-assigned Managed Identity) التي ينشئها Azure للمساحة تلقائيًّا. تمنحها ثمّ الأدوار اللازمة عبر RBAC مباشرة، دون تخزين أيّ مفتاح.

لسلسلة متاجرنا، تحتاج المساحة قراءة بيانات المبيعات من حساب تخزين مشترك:

az role assignment create \
  --assignee-object-id <object-id-de-la-mi> \
  --assignee-principal-type ServicePrincipal \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<id>/resourceGroups/data-shared/providers/Microsoft.Storage/storageAccounts/salesdata

هذا يُبطل الحاجة إلى SAS token مؤقّت، أو مفتاح حساب تخزين في Key Vault، أو ملفّ .env في دفتر — كلّها بذور تسريبات.

أدوار RBAC داخل المساحة

الأدوار المدمجة الرئيسية:

• AzureML Data Scientist: يقدر يشغّل التجارب، ينشئ أصولًا وسحابات صغيرة، لكن لا يديّر الحسابات ولا نقاط النهاية الإنتاجية. الدور اليومي لعالم البيانات.
• AzureML Compute Operator: يديّر مثيلات الحساب والعناقيد، دون رؤية شفرة المشروع. لفريق البنية التحتية.
• AzureML Registry User: صلاحية قراءة من سجلّ النماذج المشترك بين المساحات، لسحب نموذج مُصادق عليه فقط.

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

المساحة الخاصّة والنقاط الطرفية الخاصّة

في بنك أو في مستشفى، منع المساحة من الظهور على الإنترنت العامّ شرط لا يُتفاوض عليه. تُنشَأ المساحة بـ--public-network-access Disabled ثمّ تُربَط بنقطة طرفية خاصّة (Private Endpoint) داخل شبكة افتراضية. تتّصل بها فقط الأجهزة على تلك الشبكة عبر VPN أو ExpressRoute. الأداء متطابق لكن السطح المهاجَم أصغر بكثير.

قاعدة الفصل بين البيئات

لدورة حياة إنتاجية سليمة، أنشئ ثلاث مساحات عمل منفصلة: تطوير، اختبار، إنتاج، كلّ في مجموعة موارد خاصّة بها. سجلّ النماذج المشترك بين هذه المساحات (الوحدة 7) هو ما يسمح بترقية نموذج مصادَق عليه من الاختبار إلى الإنتاج دون إعادة تدريبه.

الخلاصة

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

الوحدة التالية: الحوسبة — كيف نختار بين مثيل دائم، عنقود يتقلّص إلى صفر، وحوسبة عند الطلب دون خادم.