تخطيط بيئاتك
تتكون ملكية Azure من العديد من المكونات، بما في ذلك التكوين الأساسي والموارد والإعدادات على مستوى المؤسسة وأحمال عمل التطبيق. من المحتمل أيضا أن تكون قد نشرت ممتلكاتك عبر بيئات متعددة، ولكل منها غرض مختلف.
في هذه الوحدة، ستتعرف على فائدة استخدام التعليمات البرمجية باستمرار لجميع عمليات النشر والتكوين. بعد ذلك، يمكنك مراعاة مستويات التحكم والأتمتة التي قد تطبقها على كل بيئة من بيئاتك. يمكنك أيضا التفكير في كيفية تقدم تغييراتك خلال كل مرحلة من مراحل عملية التوزيع، وعناصر التحكم وأنواع الحوكمة التي تحتاجها لدعم استراتيجية التوزيع التي اخترتها.
حدد بنيتك الأساسية كتعليمة برمجية
يغطي توزيع وتكوين Azure أكثر بكثير من مجرد التطبيقات والأجهزة الظاهرية وخدمات التخزين والربط الشبكي. على سبيل المثال، كل عنصر من العناصر التالية هو شكل من أشكال التكوين، مع موارد Azure المقابلة:
- تنظيم مواردك عن طريق إنشاء مجموعات الموارد والاشتراكات ومجموعات الإدارة.
- التحكم في كيفية تكوين مواردك الأخرى، من خلال تعريف وتطبيق تعريفات ومبادرات وتعيينات نهج Azure.
- تعيين أدوار للسماح للمستخدمين والمجموعات وهويات حمل العمل بالوصول إلى موارد Azure.
- تكوين المراقبة، بما في ذلك التنبيهات، لمراقبة موارد Azure والتأكد من أنها تتصرف بالطريقة التي تتوقعها.
عند البدء في تعريف البنية الأساسية كتعليفات برمجية لأول مرة، قد لا تكون على دراية بجميع العناصر التي يمكن تعريفها في القوالب أو التعريفات. ولكن مع نضوج استخدامك للأتمتة، من الجيد تحديد كل شيء عن بيئتك كتعليمة برمجية. من خلال ذلك، يمكنك استخدام عملية متسقة ومختبرة ومعتمدة لتكوين Azure بأكمله. ولأن التعليمات البرمجية يتم إصدارها وتتبعها في مستودع Git، يمكنك مراجعة كيفية تغيير بيئة Azure خاصتك بمرور الوقت. يمكنك استخدام مستودع Git لتتبع محفوظات كل تغيير.
على سبيل المثال، افترض أنك بحاجة إلى تكوين تنبيهات Azure Monitor لديك. في البداية، قد تعتقد أن استخدام الأتمتة لتوزيع التنبيهات لن يكون منطقياً. ولكن التنبيهات جزءٌ مهمٌ من تكوين Azure خاصتك. في حالة عدم إنشاء تنبيه على نحوٍ صحيحٍ، فقد تفوتك إشعارات بمشكلات التشغيل الحرجة. من خلال تحديد تنبيهاتك في التعليمات البرمجية:
- يمكن لأعضاء فريقك مراجعة التنبيهات وتكوينها.
- يمكنك نشر التنبيهات إلى بيئات غير إنتاجية أولا حتى تتمكن من اختبارها.
- لديك إمكانية التتبع الكامل للتغييرات التي تم إجراؤها على تكوين Azure لديك.
البيئات
عندما تخطط لتوزيع بنيتك الأساسية تلقائياً، من المفيد سرد البيئات التي تخطط لاستخدامها. لدى العديد من المؤسسات أنواع بيئة مختلفة، ولكل منها خصائص مختلفة. على سبيل المثال:
- تقوم بعض البيئات بتشغيل التعليمات البرمجية للإنتاج، بينما تقوم بيئات أخرى بتشغيل إصدارات غير إنتاجية من نفس التعليمات البرمجية، ربما بتكوينات مختلفة.
- بعض البيئات طويلة الأمد ولا يُقصد حذفها أبداً. والبعض الآخر سريع الزوال: يتم إنشاؤه تلقائيا وإتلافه عند عدم استخدامه.
- يستخدم فريق تطوير البنية الأساسية أو البرامج بعض البيئات. يتم استخدام الآخرين من قبل فريق الأمان الخاص بك، أو حتى من قبل فريق المبيعات الخاص بك عندما يحتاج إلى إظهار منتج للعملاء المحتملين.
ضع في اعتبارك البيئات التي قد تستخدمها شركة الألعاب لموقع الويب خاصتك:
عند إجراء تغييرات على تطبيقك أو بنيتك الأساسية وتثبيتها، يقوم المسار الخاص بك بنشر التغييرات الخاصة بك من خلال سلسلة من البيئات غير المنتجة: التطوير والاختبار والتقسيم المرحلي. قد يكون لديك أيضاً خطوات الموافقة اليدوية في نقاط معينة بحيث يمكن لأعضاء الفريق المحددين التحقق من التكوين أو إلقاء نظرة على سجل البنية الأساسية لبرنامج ربط العمليات التجارية قبل متابعة التوزيع. بعد ذلك، توزع بنيتك الأساسية لبرنامج ربط العمليات التجارية في نهاية المطاف تغييراتك إلى بيئة التشغيل لديك.
بالإضافة إلى تلك البيئات، يتمتع فريق المبيعات لديك ببيئة العرض التوضيحي الخاصة التي يستخدمها للتحدث إلى العملاء. يأخذ فريق المبيعات نسخةً من بيئة التشغيل لإنشاء بيئة العرض التوضيحي خاصته. تنشئ فرق الأمان والاختبار أحياناً نُسخ مؤقتة من بيئة التشغيل لاختبار الاختراق واختبار الأداء، على التوالي.
يمتلك فريق التطوير خاصته مجموعاته الخاصة من البيئات أيضاً. يحتوي على بيئة الاختبار المعزولة لأعضاء فريق التطوير لاستخدامها عند استكشاف ميزات جديدة أو تجربة خدمات Azure. ينشئ فريق التطوير أيضاً بيئات مراجعة طلبات السحب لكل طلب سحب GitHub يراجعه ويدمجه.
البيئات الخاضعة للرقابة
في بعض هذه البيئات، من المنطقي طلب عملية رسمية لمراجعة التغييرات وتطبيقها. تسمى البيئات من هذا النوع البيئات الخاضعة للرقابة. يجب دائماً التحكم في بيئة التشغيل. من الممارسات الجيدة تطبيق عناصر التحكم على بعض البيئات غير المنتجة أيضا. بهذه الطريقة، يمكنك التأكد من أن أي قيود تفرضها عناصر التحكم مفهومة ومختبرة جيدا قبل نشر الإنتاج.
وعلى النقيض من ذلك، لا تحتوي البيئات غير الخاضعة للرقابة على العديد من عناصر التحكم الرسمية أو أي عناصر تحكم رسمية. قد يكون لديهم نفس التعليمات البرمجية والتكوين المماثل لبيئاتك الأخرى، ولكنها تسمح بمزيد من التجريب وتغييرات التكوين المخصصة. في بيئة غير خاضعة للرقابة، قد يُسمح للمستخدمين بتعديل التكوين باستخدام مدخل Azure أو عن طريق تشغيل أوامر Azure CLI/Azure PowerShell مباشرةً. قد يكونوا قادرين أيضاً على إنشاء موارد دون استخدام العملية المعتمدة من المؤسسة. يجب التقاط التغييرات التي تم إجراؤها في بيئات غير خاضعة للرقابة في التعليمات البرمجية قبل أن تتمكن من البدء في تطبيقها على البيئات الخاضعة للرقابة مثل بيئة التشغيل.
إشعار
في بعض الأحيان، قد تمثل البيئة بالفعل عدة بيئات فعلية أو عمليات توزيع. على سبيل المثال، عند إنشاء بيئات سريعة الزوال لمراجعات طلب السحب، قد تكون بيئات منفصلة متعددة نشطة في نفس الوقت لأن فريقك لديه طلبات سحب متعددة مفتوحة. ولكن لغرض تخطيط بيئاتك، يمكنك اعتبارها مكافئة لأنها لها نفس الخصائص وعناصر التحكم.
بعد بعض المناقشات مع فريقك، يمكنك تعيين البيئات الخاضعة للرقابة وغير الخاضعة للرقابة. يمكنك أيضاً تحديد من يملك كل بيئة.
| اسم البيئة | الوصف | المالك | العمر | مستوى التحكم |
|---|---|---|---|---|
| التطوير | دمج التغييرات من عدة مُطوِّرين في بيئةٍ واحدةٍ. | فريق العمليات | طويلة الأمد | خاضعة للرقابة |
| اختبار | بيئة لتشغيل الاختبارات اليدوية والآلية مقابل التغييرات. | فريق العمليات | طويلة الأمد | خاضعة للرقابة |
| التدريج | البيئة النهائية غير المنتجة حيث يتم نشر التغييرات قبل الإنتاج، مع تكوين يشبه الإنتاج. | فريق العمليات | طويلة الأمد | خاضعة للرقابة |
| الإنتاج | تشغيل أحمال عمل التشغيل خاصتك. | فريق العمليات | طويلة الأمد | خاضعة للرقابة |
| العرض التوضيحي | يستخدمه فريق المبيعات لإظهار المنتج للعملاء الجدد. | فريق المبيعات | طويلة الأمد | غير خاضعة للرقابة |
| اختبار الأداء | يتم إنشاؤها ديناميكياً كنسخة مكررة من بيئة التشغيل لتشغيل اختبارات الأداء والضغط، ثم تُحذَف عند اكتمال الاختبارات. | فريق الاختبار | قصيرة الأمد | غير خاضعة للرقابة |
| اختبارات الاختراق | يتم إنشاؤها ديناميكياً كنسخة مكررة من بيئة التشغيل لتشغيل اختبارات الاختراق والأمان، ثم تُحذَف عند اكتمال الاختبارات. | فريق الأمان | قصيرة الأمد | غير خاضعة للرقابة |
| مراجعات طلبات السحب | تم إنشاؤه ديناميكيا لكل طلب سحب يقوم أحد أعضاء الفريق بإنشائه لتغيير التطبيق أو البنية الأساسية. يتم حذف البيئة عند إغلاق طلب السحب. | فريق التطوير | قصيرة الأمد | غير خاضعة للرقابة |
| بيئة الاختبار المعزولة للتطوير | يتم إنشاؤها بواسطة أعضاء فريق التطوير للتجربة أو الاستكشاف، ثم تُحذَف عند انتهاء الحاجة إليه. | فريق التطوير | قصيرة الأمد | غير خاضعة للرقابة |
قائمة البيئات السابقة هي مجرد أمثلة. في مؤسستك، تحتاج إلى تحديد البيئات التي تستخدمها، وما هي مدة بقائها، ومستوى التحكم الذي تحتاجه كل بيئة.
تلميح
من الأسهل بكثير تحليل التعليمات البرمجية للبنية الأساسية واختبارها ومراجعتها عند تطبيق هذه العمليات في وقت مبكر من عمليات التوزيع بدلا من إضافتها لاحقا والاضطرار إلى إصلاح الكثير من التعليمات البرمجية المعطلة.
وبالمثل، من الأسهل بكثير التعامل مع عناصر التحكم في الأمان عندما تكون موجودة من البداية، وعندما يتم تطبيقها أيضا على بعض بيئاتك غير التشغيلية. وبهذه الطريقة، يعتاد فريقك على العمل ضمن بيئة خاضعة للرقابة.
خلال مسارات التعلم، قدمنا بعض هذه المفاهيم تدريجياً. غالباً ما يكون من الجيد إضافة هذه العناصر إلى عملية التوزيع في أقرب وقت ممكن.
عزل كل بيئة
من المهم فصل كل بيئة من بيئاتك وجعلها قائمة بذاتها كلما أمكن ذلك. يمكن أن يساعد استخدام اشتراكات Azure المخصصة لكل بيئة، ولكنك لا تزال بحاجة إلى توخي الحذر للحفاظ على بيئاتك منفصلة.
تجنب الاتصال من بيئةٍ إلى أخرى. على سبيل المثال، لا تقم بتناظر الشبكة الظاهرية لبيئة الإنتاج بالشبكة الظاهرية لبيئة غير إنتاجية. إذا قمت بذلك، فمن السهل على شخص ما تغيير بيانات الإنتاج عن طريق الخطأ من داخل بيئة غير إنتاجية، أو تسرب بيانات الإنتاج الحساسة إلى بيئة غير إنتاجية.
عمليات التحقق والبوابات
مع متابعة عملية التوزيع لديك، يجب أن تشغل سلسلة من عمليات التحقق لزيادة ثقتك في التوزيع. تحتاج إلى تحديد عمليات التحقق المنطقية لكل بيئة من بيئاتك التي تتقدم عمليات التوزيع خاصتك من خلالها.
غالباً ما تتضمن عمليات التحقق من البنية الأساسية ما يلي:
- عمليات استعراض التعليمات البرمجية.
- نشر التعليمات البرمجية قيد المراجعة إلى بيئات سريعة الزوال وتشغيل الاختبارات التلقائية أو اليدوية مقابل البيئات.
- الفحص.
- التحقق من الصحة المبدئي.
- الاختبار اليدوي.
- الموافقة اليدوية.
- الاختبار الوظيفي التلقائي.
- اختبار التحقق من البناء التلقائي.
- في انتظار الإشارات الصحية من بيئةٍ سابقةٍ قبل التقدم إلى البيئة التالية.
يمكنك تشغيل بعض عمليات التحقق هذه عدة مرات داخل عملية التوزيع خاصتك، على سبيل المثال لكل بيئة خاضعة للرقابة.
تلميح
عند تصميم عملية التوزيع لديك، بادر بإدراج جميع الخطوات التي تحتاج إلى تنفيذها، بغض النظر عن مدى صغرها أو وضوحها. كن مُفصَّلاً قدر الإمكان. قد لا تختار أتمتة كل شيء في البداية، ولكن اتباع هذه الممارسة سيساعدك على إنشاء مخطط لعمليات التوزيع التلقائية لديك في المستقبل.
البوابة هي فحص تلقائي أو يدوي يجب أن ينجح حتى يستمر التوزيع.
التدخل اليدوي
من الجيد أتمتة أكبر عدد ممكن من عمليات التحقق أثناء مراجعة التعليمات البرمجية وعمليات التوزيع. ومع ذلك، قد تحتاج مؤسستك إلى موافقة يدوية للتوزيع في بيئة التشغيل أو بيئات أخرى خاضعة للرقابة.
إذا كنت تستخدم بوابات الموافقة اليدوية للتوزيع، فاتبع هذه الممارسات الموصى بها:
- حدد بوضوح من يُسمَح له بالموافقة على التوزيع. استخدم مجموعات Microsoft Entra لتعريف الموافقين، بدلا من تحديد المستخدمين الفرديين. يمكنك بسهولة تغيير قائمة الموافقين في المستقبل.
- لديك عملية معالجة لعمليات توزيع الطوارئ. خطط لمن يمكنه الموافقة على التوزيع إذا لم يكن الموافقون العاديون متاحين. قد يلزم إجراء عملية توزيع طارئة في منتصف الليل أو خلال فترة العطلة.
- قصر التدخل البشري على مجرد الموافقة على التوزيع أو رفضه. تجنب مطالبة البشر بتشغيل أي من عمليات التوزيع ما لم تكن هناك خطوة لا يمكنك أتمتتها.
الإدارة
يوفر Azure أدوات وقدرات لمساعدتك في التحكم في بيئتك، بما في ذلك:
- نهج Azure للكشف عن الموارد التي تم تكوينها بطرق لا تتناسب مع متطلبات مؤسستك. كما يمكن أن يساعد في منع إنشاء الموارد أو إعادة تكوينها بطريقة تجعلها غير متوافقة.
- تأمين لمنع التغييرات على الموارد الهامة أو حذفها.
- مجموعات الإدارة لمساعدتك في تنظيم اشتراكات Azure وتكوين التحكم في الوصول المستند إلى الأدوار والنهج باستمرار عبر بيئاتك.
- Azure Monitor لتسجيل المقاييس والسجلات من مواردك، وتقديمها في لوحات المعلومات، وتنبيهك تلقائيا عندما تنحرف عن القيم المتوقعة.
عند إنشاء ملكية Azure خاصتك، ضع في اعتبارك استخدام مناطق Azure المُنتقل إليها. باستخدام منطقة مُنتقل إليها، يمكنك بناء الحوكمة في بيئتك من البداية. تتضمن العديد من المناطق المُنتقل إليها ملفات Bicep وTerraform التي تم إنشاؤها مسبقاً لمساعدتك في تكوين بيئتك. نحن نربط بمزيد من المعلومات في الملخص.