الأسئلة المتداولة حول منطقة هبوط Azure (FAQ)

تجيب هذه المقالة على الأسئلة المتداولة حول بنية منطقة Azure المنتقل إليها.

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

ما هو مسرع منطقة Azure المنتقل إليها؟

مسرع منطقة Azure المنتقل إليها هو تجربة توزيع مستندة إلى مدخل Microsoft Azure. ينشر تنفيذا مراعيا للرأي استنادا إلى البنية المفاهيمية لمنطقة Azure المنتقل إليها.

ما هي المسرعات والتطبيقات الموصى بها لمناطق هبوط Azure؟

تعمل Microsoft بنشاط على تطوير وصيانة النظام الأساسي ومسرعات التطبيقات والتطبيقات وفقا لمبادئ تصميم منطقة Azure المنتقل إليها وإرشادات منطقة التصميم .

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

لمعرفة كيفية تخصيص توزيع مناطق هبوط Azure لتلبية احتياجاتك، راجع تخصيص بنية منطقة Azure المنتقل إليها لتلبية المتطلبات

تلميح

لطلب إضافة إلى قائمة المسرع والتنفيذ، قم برفع مشكلة GitHub في مستودع ALZ.

ما هي البنية المفاهيمية لمنطقة Azure المنتقل إليها؟

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

ما الذي تعينه المنطقة المنتقل إليها في Azure في سياق بنية منطقة هبوط Azure؟

من وجهة نظر منطقة Azure المنتقل إليها، المناطق المنتقل إليها هي اشتراكات Azure الفردية.

ماذا تعني الحوكمة المستندة إلى السياسة، وكيف تعمل؟

الحوكمة المستندة إلى النهج هي أحد مبادئ التصميم الرئيسية للبنية على نطاق المؤسسة.

تعني الحوكمة المستندة إلى النهج استخدام نهج Azure لتقليل الوقت الذي تحتاجه للمهام التشغيلية الشائعة والمتكررة عبر مستأجر Azure. استخدم العديد من تأثيرات نهج Azure، مثل Appendو DenyDeployIfNotExistsو و Modifyلمنع عدم الامتثال إما عن طريق تقييد الموارد غير المتوافقة (كما هو محدد في تعريف النهج) من الإنشاء أو التحديث أو عن طريق نشر الموارد أو تعديل إعدادات إنشاء مورد أو طلب تحديث لجعلها متوافقة. لا تمنع بعض التأثيرات، مثل Auditو Disabledو AuditIfNotExists، أو تتخذ إجراء؛ بل تقوم فقط بمراجعة عدم الامتثال والإبلاغ عن ذلك.

بعض الأمثلة على الحوكمة المستندة إلى النهج هي:

• Deny التأثير: يمنع إنشاء الشبكات الفرعية أو تحديثها لعدم وجود مجموعات أمان شبكة مقترنة بها.

• DeployIfNotExists التأثير: يتم إنشاء اشتراك جديد (المنطقة المنتقل إليها) ووضعه في مجموعة إدارة داخل توزيع منطقة Azure المنتقل إليها. يضمن نهج Azure تمكين Microsoft Defender للسحابة (المعروف سابقا باسم Azure Security Center) على الاشتراك. كما أنه يقوم بتكوين إعدادات التشخيص ل Activity Log لإرسال السجلات إلى مساحة عمل Log Analytics في اشتراك الإدارة.

  بدلا من تكرار التعليمات البرمجية أو الأنشطة اليدوية عند إنشاء اشتراك جديد، DeployIfNotExists يقوم تعريف النهج تلقائيا بتوزيعها وتكوينها لك.

ماذا لو لم نتمكن من استخدام نهج DeployIfNotExists (DINE) أو لم نكن مستعدين بعد لاستخدامها؟

لدينا صفحة مخصصة تستعرض المراحل والخيارات المختلفة التي يجب عليك إما "تعطيل" نهج DINE أو استخدام نهج المراحل الثلاث لاعتمادها بمرور الوقت داخل بيئتك.

راجع الإرشادات اعتماد حواجز الحماية المستندة إلى النهج

هل يجب علينا استخدام نهج Azure لنشر أحمال العمل؟

باختصار، لا. استخدم نهج Azure للتحكم في أحمال العمل والمناطق المنتقل إليها والتحكم فيها والحفاظ عليها متوافقة. لم يتم تصميمه لتوزيع أحمال العمل بأكملها والأدوات الأخرى. استخدم مدخل Microsoft Azure أو عروض البنية الأساسية كتعلم برمجي (قوالب ARM، Bicep، Terraform) لنشر وإدارة حمل العمل الخاص بك والحصول على الاستقلالية التي تحتاجها.

ما هي مناطق هبوط إطار اعتماد السحابة ل Terraform (aztfmod)؟

المناطق المنتقل إليها في إطار اعتماد السحابة مصدر مفتوح المشروع (OSS) (المعروف أيضا باسم aztfmod) هو مشروع مدفوع بالمجتمع مملوك ومصان خارج الفريق الأساسي لمنطقة Azure المنتقل إليها ومؤسسة Azure GitHub. إذا اختارت مؤسستك استخدام مشروع OSS هذا، فيجب مراعاة الدعم المتاح لأن هذا مدفوع بجهد المجتمع من خلال GitHub.

ماذا لو كان لدينا بالفعل موارد في مناطق الهبوط الخاصة بنا وقمنا لاحقا بتعيين تعريف نهج Azure الذي يتضمنها في نطاقه؟

راجع أقسام الوثائق التالية:

• نقل بيئات Azure الحالية إلى البنية المفاهيمية لمنطقة Azure المنتقل إليها - قسم "النهج"
• التشغيل السريع: إنشاء تعيين نهج لتحديد الموارد غير المتوافقة - قسم "تحديد الموارد غير المتوافقة"

كيف نتعامل مع مناطق هبوط حمل العمل "التطوير/الاختبار/الإنتاج" في بنية منطقة Azure المنتقل إليها؟

ملاحظة

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

إذا كان حمل عمل التطبيق أو الخدمة يتطلب فصل مناطق الهبوط "dev/test/production"، فاستخدم اشتراكا منفصلا لكل منطقة هبوط في حمل العمل. من المهم العمل مع مالكي أحمال عمل التطبيق أو الخدمة لتحديد ما إذا كانت الاشتراكات المنفصلة هي أفضل طريقة لهم لإنشاء أحمال العمل وإدارتها وتشغيلها وتسليمها. لا ينبغي أن يكون إلزاميا لجميع أحمال العمل.

مثال جيد هو حمل العمل الذي يستخدم Azure App Service. عند استخدام Azure App Service، فإن أفضل الممارسات هي استخدام فتحات التوزيع لمساعدتك في إدارة التغييرات والتحديثات لتطبيق الويب. ومع ذلك، لا يمكن استخدام هذه الميزة إلا على نفس التطبيق على خطة خدمة التطبيقات، والتي يمكن أن تعيش فقط ضمن اشتراك واحد. من خلال تفويض أن مالكي حمل عمل التطبيق أو الخدمة يستخدمون اشتراكات منفصلة ل "التطوير/الاختبار/الإنتاج"، قد تجعل إدارة دورة حياة التوزيع الخاصة بهم أكثر صعوبة. في هذا المثال، قد يكون الاشتراك الفردي للتطبيق أو حمل عمل الخدمة هو الأنسب باستخدام التحكم في الوصول المستند إلى الدور في Azure (RBAC) مع إدارة الهويات المتميزة في نطاق مجموعة الموارد لزيادة الأمان.

نقترح العمل مع كل فريق حمل عمل تطبيق أو خدمة (مالكي المنطقة المنتقل إليها) لفهم متطلباتهم. ثم يمكنك توفير الاشتراكات بناء على متطلباتها وخططها. قد تقرر أيضا تعيين "خطوط المنتج" للأنواع المختلفة من أحمال العمل بحيث يمكنك إنشاء عمليات إنشاء الاشتراك والأدوات بناء على المتطلبات الشائعة من فرق حمل عمل التطبيق أو الخدمة.

ماذا عن التسلسل الهرمي لمجموعة الإدارة لدينا؟

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

تعني محاذاة النموذج الأصلي أنه يتم إنشاء مجموعات الإدارة فقط للأطر الأصلية المختلفة لحمل العمل. على سبيل المثال، في البنية المفاهيمية، تحتوي مجموعة إدارة "المناطق المنتقل إليها" على مجموعات إدارة تابعة "corp" و"online". تتوافق مجموعات الإدارة التابعة هذه مع أنماط النماذج الأصلية المميزة لأحمال العمل التي تحتفظ بها، وتركز على متطلبات الاتصال المختلط (VPN/ExpressRoute) (الداخلية فقط مقابل التطبيقات/الخدمات العامة). ومع ذلك، يتم الاحتفاظ بجميع البيئات ("dev/test/production")، سواء كانت مقسمة عبر اشتراكات منفصلة أو في اشتراك واحد، ضمن نفس مجموعة الإدارة الفردية ("Corp" أو "Online") اعتمادا على نموذجها الأصلي ومتطلباتها.

تساعد المعادلة التالية على تمييز سبب عدم تغير حجم مجموعات الإدارة لكل بيئة و/أو لكل حمل عمل بشكل جيد: N workloads x Z management groups = إجمالي مجموعات الإدارة.

لذلك، إذا كان لديك 30 حمل عمل مختلفا يتطلب كل منها مجموعة إدارة ومجموعة إدارة تابعة ل "dev/test/production"، فستترك لك:

N = عدد أحمال العمل/التطبيقات = 30

Z = عدد مجموعات الإدارة لحمل العمل والبيئات (1 لكل حمل عمل + 3 ل envs) = 4

N (30) x Z (4) = 120 مجموعة إدارة إجمالية

مثال على التسلسل الهرمي لمجموعة الإدارة دون المستوى الأمثل

يجب أن يكون لدى منطقة الهبوط MG نهج عالمية تفرض حواجز حماية لكل من Corp و Online. لدى Corp و Online نهج فريدة لفرض إرشادات الشركة حول أحمال العمل العامة والخاصة. إذا كان من الضروري تنفيذه على مستوى أعلى لمجموعة الإدارة، فيجب التحدث عنه مع فريق Cloud Platform أو فريق آخر. هناك قيمة ضئيلة في تغيير تكوين حمل العمل كما يتم ترقيته من خلال البيئات المختلفة. ينتج عن التغيير المستمر تجربة تطوير سيئة لمستخدمي المنطقة المنتقل إليها ومالكيها. قد تفكر أيضا في استخدام اشتراكات بيئة الاختبار المعزولة لأغراض التطوير الحقيقية حيث تكون هناك حاجة إلى بيئة أقل تقييدا، مثل عندما يقوم فريق حمل عمل تطبيق أو خدمة بتجربة خدمات Azure مختلفة لمعرفة ما يناسب متطلباتهم بشكل أفضل. بمجرد معرفة الخدمات، يمكن توفير منطقة هبوط (في مجموعة الإدارة المتوافقة مع النموذج الأصلي لحمل العمل الصحيح في التسلسل الهرمي لمجموعة إدارة "المناطق المنتقل إليها") للفريق.

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

• استخدم العلامات في تعريفات النهج للمساعدة في تصفيتها وتطبيقها على البيئة الصحيحة.

  هام

  يمكن تغيير العلامات من قبل المستخدمين الذين لديهم أذونات Azure RBAC المناسبة، لذلك بالنسبة للنهج التي تركز على الأمان، لا ننصح باستخدام العلامات في النهج. قد يغير المستخدمون العلامات على مورد ويحتمل أن يتجاوزوا تعريف نهج آخر أو يطبقونه على الموارد.

• تطبيق النهج على مستوى الاشتراك كما هو مطلوب، من الناحية المثالية أثناء عملية إنشاء الاشتراك (كما ذكرنا سابقا).

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

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

مثال على التسلسل الهرمي الأمثل لمجموعة الإدارة المتوافقة مع بنية منطقة Azure المنتقل إليها

تمت إزالة بعض مجموعات الإدارة لأغراض وضوح التوضيح.

تلميح

ناقشنا هذا الموضوع في فيديو YouTube الأخير: مناطق هبوط Azure - التعامل مع Dev/Test/Prod لأحمال عمل التطبيق

لماذا يطلب منا تحديد مناطق Azure أثناء توزيع مسرع منطقة Azure المنتقل إليها وما الذي تستخدم من أجله؟

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

يتم أيضا استخدام محدد المنطقة في علامة التبويب Deployment location لتحديد منطقة Azure التي يجب تخزين أي موارد خاصة بالمنطقة، مثل مساحة عمل Log Analytics وحساب التنفيذ التلقائي، إذا لزم الأمر.

إذا قمت بتوزيع مخطط شبكة على علامة التبويب تخطيط الشبكة والاتصال ، فأنت بحاجة إلى تحديد منطقة Azure لنشر موارد الشبكة إليها. يمكن أن تختلف هذه المنطقة عن المنطقة المحددة في علامة التبويب Deployment location .

لمزيد من المعلومات حول المناطق التي تستخدمها موارد المنطقة المنتقل إليها، راجع مناطق المنطقة المنتقل إليها.

كيف يمكننا تمكين المزيد من مناطق Azure عند استخدام بنية منطقة Azure المنتقل إليها؟

لفهم كيفية إضافة مناطق جديدة إلى منطقة هبوط، أو كيفية نقل موارد المنطقة المنتقل إليها إلى منطقة مختلفة، راجع مناطق المنطقة المنتقل إليها.

هل يجب علينا إنشاء اشتراك Azure جديد في كل مرة أو هل يجب علينا إعادة استخدام اشتراكات Azure؟

ما المقصود بإعادة استخدام الاشتراك؟

إعادة استخدام الاشتراك هي عملية إعادة إصدار اشتراك موجود لمالك جديد. يجب أن تكون هناك عملية لإعادة تعيين الاشتراك إلى حالة نظيفة معروفة ثم إعادة تعيينها إلى مالك جديد.

لماذا يجب أن أدرس إعادة استخدام الاشتراكات؟

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

تلميح

شاهد فيديو YouTube حول مبدأ تصميم إضفاء الطابع الديمقراطي للاشتراك هنا: مناطق هبوط Azure - كم عدد الاشتراكات التي يجب استخدامها في Azure؟

يجب أن تفكر في إعادة استخدام الاشتراك إذا كنت تفي بأحد الظروف التالية:

• لديك اتفاقية Enterprise (EA) وتخطط لإنشاء أكثر من 5000 اشتراك على حساب مالك حساب EA واحد (حساب فوترة)، بما في ذلك الاشتراكات المحذوفة.
• لديك اتفاقية عملاء Microsoft (MCA) أو Microsoft Partner Agreement MPA وتخطط للحصول على أكثر من 5000 اشتراك نشط
• أنت عميل الدفع أولا بأول
• يمكنك استخدام رعاية Microsoft Azure
• عادة ما تقوم بإنشاء:
  1. بيئات المختبر أو بيئة الاختبار المعزولة سريعة الزوال
  2. بيئات العرض التوضيحي لإثبات المفهوم (POCs) أو الحد الأدنى من المنتجات القابلة للتطبيق (MVP)، بما في ذلك موردي البرامج المستقلين (ISV) للوصول التجريبي/التجريبي للعميل
  3. بيئات التدريب، مثل بيئات متعلم MSPs/المدرب

كيف أعمل إعادة استخدام الاشتراكات؟

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

تنظيف الاشتراك القديم

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

• إزالة مجموعات الموارد والموارد المضمنة.
• قم بإزالة تعيينات الأدوار، بما في ذلك تعيينات دور إدارة الهويات المتميزة (PIM)، في نطاق الاشتراك.
• قم بإزالة تعريفات التحكم في الوصول المستندة إلى الدور المخصصة (RBAC)، في نطاق الاشتراك.
• إزالة تعريفات النهج والمبادرات والتعيينات والإعفاءات في نطاق الاشتراك.
• إزالة عمليات التوزيع في نطاق الاشتراك.
• إزالة العلامات في نطاق الاشتراك.
• قم بإزالة أي Resource Locks في نطاق الاشتراك.
• قم بإزالة أي ميزانيات Azure Cost Management في نطاق الاشتراك.
• إعادة تعيين Microsoft Defender لخطط السحابة إلى المستويات المجانية ما لم تفرض المتطلبات التنظيمية تعيين هذه السجلات إلى المستويات المدفوعة. يمكنك عادة فرض هذه المتطلبات عبر نهج Azure.
• قم بإزالة إعادة توجيه سجلات نشاط الاشتراك (إعدادات التشخيص) إلى مساحات عمل Log Analytics أو مراكز الأحداث أو حساب التخزين أو الوجهات الأخرى المدعومة ما لم تفرض المتطلبات التنظيمية إعادة توجيه هذه السجلات أثناء تنشيط الاشتراك.
• قم بإزالة أي تفويضات Azure Lighthouse في نطاق الاشتراك.
• إزالة أي موارد مخفية من الاشتراك.

تلميح

سيساعدك استخدام Get-AzResource نطاق الاشتراك أو az resource list -o table استهدافه في العثور على أي موارد مخفية أو متبقية لإزالتها قبل إعادة التعيين.

إعادة تعيين الاشتراك

يمكنك إعادة تعيين الاشتراك بعد تنظيف الاشتراك. فيما يلي بعض الأنشطة الشائعة التي قد ترغب في تنفيذها كجزء من عملية إعادة التعيين:

• أضف علامات جديدة وقم بتعيين قيم لها على الاشتراك.
• أضف تعيينات دور جديدة، أو تعيينات دور إدارة الهويات المتميزة (PIM)، في نطاق الاشتراك للمالكين الجدد. عادة ما تكون هذه التعيينات لمجموعات Azure Active Directory بدلا من الأفراد.
• ضع الاشتراك في مجموعة الإدارة المطلوبة بناء على متطلبات الحوكمة الخاصة بها.
• إنشاء موازنات Azure Cost Management جديدة وتعيين التنبيهات إلى المالكين الجدد عند استيفاء الحدود.
• قم بتعيين Microsoft Defender لخطط السحابة إلى المستويات المطلوبة. يجب عليك فرض هذا الإعداد عبر نهج Azure بمجرد وضعه في مجموعة الإدارة الصحيحة.
• تكوين إعادة توجيه سجلات نشاط الاشتراك (إعدادات التشخيص) إلى مساحات عمل Log Analytics أو مراكز الأحداث أو حساب التخزين أو الوجهات الأخرى المدعومة. يجب عليك فرض هذا الإعداد عبر نهج Azure بمجرد وضعه في مجموعة الإدارة الصحيحة.