ملاحظة
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
يعد توزيع الأدوار والمسؤوليات والثقة بين فرق تكنولوجيا المعلومات وفرق التطبيقات أمرا بالغ الأهمية للتحول التشغيلي المتضمنة في اعتماد السحابة على نطاق واسع.
تسعى فرق تكنولوجيا المعلومات جاهدة للحفاظ على التحكم. يسعى مالكو التطبيقات إلى زيادة السرعة إلى أقصى حد. يؤثر التوازن الذي تقيمه في نهاية المطاف بين هذين الهدفين بشكل كبير على نجاح نموذج التشغيل السحابي الخاص بك.
وفقا لقانون Conway، تنتج الفرق بنيات بناء على هيكل الاتصال الخاص بها. يعد فهم هذا المبدأ أمرا بالغ الأهمية أثناء العمل على تحقيق التوازن الضروري بين الاستقلالية والتحكم. أي مؤسسة تصمم نظاما (محددا على نطاق واسع) ستنتج بنية تصميم نسخة من بنية الاتصال لتلك المؤسسة.
من منظور DevOps، يجب على المؤسسات التحسين للاستجابة السريعة لاحتياجات العملاء. تجد الفرق التي تمتلك تطبيقاتها وأنظمتها وتصممها وتنفذها أعلى مستوى من الاستقلالية في البنيات ذات الخصائص التالية:
- البنية التطورية التي تدعم التغييرات المستمرة
- إمكانية التوزيع
- قابلية الاختبار
حل Conway هو تجاوز قانون Conway. إذا كانت مؤسستك تتبع بنية معينة لإنتاج الخدمات والمنتجات وتتطلع إلى التحسين، فأنت بحاجة إلى إعادة التفكير في بنيتك التنظيمية. تطوير فريقك وهيكلك التنظيمي لتحقيق البنية المطلوبة.
يؤدي هذا المبدأ إلى تخطيطات الفريق المصممة عمدا حيث تكون الفرق مسؤولة عن شاملة لأي تطبيقات أو أنظمة أو منصات تمتلكها من أجل تحقيق الانضباط الكامل ل DevOps.
يوفر الجدول التالي تصنيفا مبسطا لهذه الفرق.
| نوع الفريق | التعريف |
|---|---|
| فرق حمل عمل التطبيق | تنشئ هذه الفرق تطبيقات تدفع نتائج الأعمال المباشرة لقطاع من مجال الأعمال. في سياق مناطق Azure المنتقل إليها، تكون هذه الفرق مسؤولة عن دورة حياة أحمال عمل التطبيق من طرف إلى طرف. |
| فرق النظام الأساسي | تقوم هذه الفرق ببناء أنظمة أساسية داخلية مقنعة لتسريع التسليم وتقليل الحمل المعرفي لفرق حمل عمل التطبيق. في سياق مناطق Azure المنتقل إليها، تتحمل هذه الفرق مسؤولية دورة الحياة الشاملة لمنطقة Azure المنتقل إليها. |
| تمكين الفرق | تساعد هذه الفرق في التغلب على فجوات المهارات من خلال مساعدة الفرق الأخرى ذات القدرات المتخصصة مثل DevOps. |
اعتبارات التصميم
إنشاء فريق نظام أساسي متعدد الوظائف لتصميم دورة حياة منطقة Azure المنتقل إليها وبناها وتوفيرها وإدارتها وصيانتها. يمكن أن يتضمن هذا الفريق أعضاء من فريق تكنولوجيا المعلومات المركزي والأمان والتوافق ووحدات الأعمال لضمان تمثيل مجموعة واسعة من مؤسستك. تأكد من تجنب مضادات الأنماط.
ضع في اعتبارك إنشاء فريق تمكين يمكنه توفير وظائف DevOps لدعم التطبيقات والأنظمة الأساسية التي لا تحتوي على قدرات DevOps موجودة، أو حالة عمل لإنشاء واحدة (على سبيل المثال، التطبيقات القديمة بأقل قدر من قدرات التطوير).
لا تقيد فرق حمل عمل التطبيق الخاص بك بالقطع الأثرية المركزية، لأنها يمكن أن تعوق خفة الحركة الخاصة بها. يمكنك استخدام الحوكمة المستندة إلى النهج والتحكم في الوصول المستند إلى الدور في Azure (Azure RBAC) لفرض تكوينات أساسية متسقة والتأكد من أن فرق التطبيق (وحدة الأعمال) مرنة بما يكفي للابتكار ولكنها لا تزال قادرة على الاستفادة من مجموعة محددة مسبقا من القوالب.
لا تجبر فرق التطبيق على استخدام عملية مركزية أو البنية الأساسية لبرنامج ربط العمليات التجارية للتوفير لإنشاء مثيل لمورد التطبيق أو إدارته. لا يزال بإمكان الفرق الحالية التي تعتمد بالفعل على مسار DevOps لتسليم التطبيق استخدام أدواتها الحالية. تذكر أنه يمكنك استخدام Azure Policy يساعد على فرض المعايير التنظيمية وتقييم التوافق على نطاق واسع ومعالجة اعتبارات الأمان لعمليات DevOps الخاصة بك.
لا ينشئ التطبيق الشامل لنموذج DevOps فرق DevOps قادرة على الفور.
يعد الاستثمار في القدرات والموارد الهندسية أمرا بالغ الأهمية.
قد لا تمتلك فرق التطبيقات لبعض التطبيقات القديمة الموارد الهندسية المطلوبة للتوافق مع استراتيجية DevOps.
توصيات التصميم
تحتوي الأقسام التالية على توصيات تصميم لإرشادك أثناء تصميم طبولوجيا فريقك.
محاذاة طبولوجيا الفريق مع نموذج تشغيل السحابة
تأكد من محاذاة طبولوجيا فريقك مع نموذج التشغيل السحابي المطلوب.
قم بإنشاء عملية أساسية لمراجعات اللياقة البدنية التشغيلية حتى تفهم تماما المشكلات التي يمكن أن تنتج عن هياكل فريقك.
تحديد الوظائف لفريق النظام الأساسي الخاص بك
توفر القائمة التالية مجموعة موصى بها من الوظائف لفريق النظام الأساسي المسؤول عن مناطق Azure المنتقل إليها:
- إدارة البنية
- توفير الاشتراك وتفويض نهج إدارة الشبكة والهوية والوصول المطلوبة
- إدارة النظام الأساسي ومراقبته (شامل)
- إدارة التكاليف (شاملة)
- النظام الأساسي كتعلم برمجي (إدارة القوالب والبرامج النصية والأصول الأخرى)
- العمليات الإجمالية على Microsoft Azure داخل مستأجر Azure Active Directory (إدارة كيانات الخدمة وتسجيل واجهة برمجة تطبيقات Microsoft Graph وتعريفات الأدوار)
- Azure RBAC (شامل)
- إدارة المفاتيح للخدمات المركزية (بروتوكول نقل البريد البسيط ووحدات التحكم بالمجال)
- إدارة السياسات وإنفاذها (شامل)
- المراقبة والتدقيق الأمني (شامل)
- إدارة الشبكة (شاملة)
تحديد الوظائف لفرق حمل عمل التطبيق الخاص بك
توفر القائمة التالية مجموعة موصى بها من الوظائف لفرق التطبيقات المسؤولة عن أحمال عمل التطبيق:
- إنشاء موارد التطبيق وإدارتها من خلال نموذج DevOps
- إدارة قاعدة البيانات
- ترحيل التطبيق أو تحويله
- إدارة التطبيقات ومراقبتها (موارد التطبيق)
- Azure RBAC (موارد التطبيق)
- مراقبة الأمان وتدقيقه (موارد التطبيق)
- إدارة البيانات السرية والمفاتيح (مفاتيح التطبيق)
- إدارة التكلفة (موارد التطبيق)
- إدارة الشبكة (موارد التطبيق)
تحديد الوظائف لتمكين الفرق
توفر القائمة التالية مجموعة موصى بها من الوظائف لفريق تمكين مسؤول عن مساعدة فرقك الأخرى:
- تعريف الإرشادات والقدرات الأفقية (عبر الوظائف) للمساعدة في الحصول على الخبرة الصحيحة عبر مؤسستك، ما يضمن المواءمة مع نموذج التشغيل السحابي المستهدف الإجمالي (مثل DevOps)
- الدعم والتدريب والتدريب للفرق الأخرى للوصول إلى المستوى اللازم من الخبرة
- إنشاء مجموعة مشتركة من القوالب والمكتبات القابلة لإعادة الاستخدام لتطبيقك أو فرق النظام الأساسي، وتعزيز InnerSourcing، مثل Common Azure Resource Modules Library.
تحديد أوضاع التفاعل بين الفرق
أهداف التفاعلات بين فرقك هي:
- تحقيق الاستقلالية
- إلغاء حظر التبعيات
- تقليل وقت الإهدار
- تجنب الازدحام
مخطط الفريق يوضح ثلاثة أوضاع لتفاعل الفريق:
| وضع التفاعل | الوصف |
|---|---|
| التعاون | تعمل الفرق معا بشكل وثيق. |
| X-as-a-Service | تستهلك الفرق أو توفر شيئا ما للفرق الأخرى بأقل تعاون، على غرار تفاعلات موردي الجهات الخارجية. |
| تيسير | يساعد فريق آخر الفرق أو يساعدهم لإزالة العوائق. |