مشاركة عبر

Automation

  • مقالة

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

اعتبارات أتمتة النظام الأساسي

  • يتيح تنفيذ منهجية "كل شيء كتعلم برمجي" (EaC) لفرقك إطلاق العنان للفوائد الرئيسية، وإنشاء ثقافة تطوير قوية، وتمكين كل شخص في كل فريق من تحديد كيفية نشر الموارد والموارد التي يتم نشرها. كما تساعد EaC فرق النظام الأساسي على اعتماد ممارسات التطوير الرئيسية التي تحسن خفة حركتها وكفاءتها. يمكن لفرقك تعقب التغييرات والتحكم في التغييرات التي تنتقل إلى الإنتاج بواسطة رمز الإسكان في المستودعات واستخدام أنظمة التحكم في الإصدار لإدارتها.
  • يمكن للفرق اتباع مبدأ العيون الأربع واستخدام برمجة النظراء أو مراجعة النظراء لضمان عدم إجراء تغييرات التعليمات البرمجية وحدها. تعمل برمجة الأقران ومراجعة النظراء على تحسين جودة التعليمات البرمجية، والسماح للفرق بمشاركة المسؤولية عن التغييرات، وزيادة معرفة الفريق بما يتم الاتفاق عليه وتوزيعه. تعد مراجعة التعليمات البرمجية طريقة رائعة لأعضاء الفريق لتعلم تقنيات وأساليب جديدة للتشفير والأتمتة.
  • يجب على الفرق استخدام أنظمة التحكم في الإصدار مثل Git، جنبا إلى جنب مع مستودعات Git، لفرض مراجعة الأقران. تتيح مستودعات Git لفرقك تحديد الفروع المهمة وحمايتها باستخدام نهج الفروع. يمكنك استخدام النهج لطلب تغييرات التعليمات البرمجية على هذه الفروع لتلبية معايير معينة، مثل الحد الأدنى لعدد موافقات أعضاء الفريق، قبل أن يتمكنوا من الدمج في فرع محمي.
  • يجب على الفرق ربط منهجية EaC وعملية مراجعة التغيير جنبا إلى جنب مع عملية التكامل المستمر والتسليم المستمر (CI/CD ). يجب أن يؤدي كل تغيير في التعليمات البرمجية تلقائيا إلى تشغيل عملية CI التي تنفذ تحليل التعليمات البرمجية الثابتة والتحقق من الصحة وتوزيع الاختبار. يضمن CI أن يتحقق المطورون من التعليمات البرمجية الخاصة بهم في وقت مبكر (يشار إليه غالبا باسم اختبار الفشل السريع أو اختبار التحول إلى اليسار) بحثا عن الأخطاء التي يمكن أن تسبب مشكلات مستقبلية. اعتمادا على استراتيجية التفريع التي يستخدمها فريقك، يجب أن تؤدي التغييرات التي يتم إجراؤها على أي فرع مهم إلى التوزيع إلى بيئات مختلفة. بمجرد الموافقة على التغييرات ودمجها في main، تنشر عملية CD هذه التغييرات في الإنتاج. يوفر نظام إدارة التعليمات البرمجية هذا لفريقك مصدرا واحدا للحقيقة لما يتم تشغيله في كل بيئة.
  • لضمان أن النظام الأساسي الخاص بك هو الإصلاح الذاتي بالكامل ويوفر الخدمة الذاتية لفرق حمل العمل الخاصة بك، يجب أن يعمل فريق النظام الأساسي الخاص بك لأتمتة كل شيء (يشار إليه غالبا باسم الأتمتة القصوى) من التزويد والتكوين وإدارة النظام الأساسي إلى توفير اشتراك المنطقة المنتقل إليها لفرق حمل العمل. تسمح الأتمتة القصوى لفريق النظام الأساسي بالتركيز على توفير القيمة بدلا من توزيع النظام الأساسي وتكوينه وإدارته. كما تنشئ الأتمتة القصوى دورة تحسين ذاتي تمنح فريقك مزيدا من الوقت لبناء المزيد من الأتمتة.
  • مع أتمتة فرق النظام الأساسي للأنشطة التشغيلية وتقليل التدخل البشري، يجب عليهم تحويل تركيزهم إلى مهام مهمة تمكن وتسريع ابتكار فريق حمل العمل على Azure. لتحقيق ذلك، يجب على فريق النظام الأساسي الخاص بك التكرار من خلال دورات متعددة من البناء والتطوير أثناء وضعها في مكان أدوات النظام الأساسي والبرامج النصية وتحسينات القدرة.
  • هناك خيارات متعددة متاحة لمساعدة فريقك على البدء في نشر منطقة Azure المنتقل إليها. تعتمد هذه الخيارات على قدرات الفريق الحالية ويمكن أن تنمو مع تطور فريقك. وبشكل أكثر تحديدا، بالنسبة لنشر النظام الأساسي، يمكن للمرء الاختيار بين التجارب المستندة إلى المدخل أو Bicep أو Terraform، اعتمادا على كفاءة IaC الخاصة ب Teams وتفضيل الأدوات.
    • يمكن لفرق النظام الأساسي الجديدة والناشئة التي لا تزال تتعرف على البنية الأساسية كتعليق برمجي (IaC) وأكثر دراية باستخدام مدخل لنشر الموارد وإدارتها استخدام مسرع منطقة Azure المنتقل إليها للبدء، والذي يدعم الفرق التي لا تزال تستخدم نهج ClickOps . ClickOps هي عملية توفير الموارد وتكوينها وإدارتها بالنقر في المداخل ووحدات التحكم بالإدارة والمعالجات. يسمح هذا المسرع لفريقك باستخدام المدخل كأداة نشر أولية، وبشكل تدريجي، مع نمو نضج هندسة النظام الأساسي، لمزيد من استخدام Azure CLI أو PowerShell أو IaC.
    • يتيح حل AzOps للفرق تطوير ممارسات أتمتة النظام الأساسي وإدارتها من ClickOps المدفوعة إلى DevOps القادرة. يمكن لفريقك الانتقال من استخدام وصول حسابه الشخصي إلى استخدام مبادئ وممارسات DevOps التي تعتمد فقط على CI/CD مع AzOps وIaC. يتيح AzOps لفريقك إحضار بنيته الخاصة، أو استخدام البنية التي تم نشرها بواسطة مسرع مدخل منطقة Azure المنتقل إليها (بعد التوزيع الأولي المستند إلى المدخل، حيث إن تكامل AzOps ليس جزءا من تجربة مدخل ALZ)، أو التكامل مع توزيع brownfield، أو استخدام قوالب مخصصة (Bicep أو ARM) لإنشاء نظامك الأساسي وتشغيله.
    • يمكن لفرق النظام الأساسي ذات المهارات والقدرات الراسخة اعتماد نهج مقنن يتبع مبادئ وممارسات DevOps. يجب أن يعتمد فريقك بشكل كبير على IaC وممارسات التطوير الحديثة، والانتقال بعيدا عن استخدام وصول Azure على حساباتهم الشخصية وإلى تشغيل جميع العمليات من خلال البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD. يجب على فريقك استخدام المسرعات المستندة إلى IaC، مثل ALZ-Bicep أو وحدة Terraform لمناطق هبوط Azure لتسريع هذا الانتقال.
  • المسرعات المستندة إلى IaC لها نطاق إدارة محدود. توفر الإصدارات الجديدة المزيد من القدرات وزيادة قدرة إدارة الموارد. إذا كنت تستخدم مسرعا، فيجب على فريقك التفكير في نهج متعدد الطبقات يبدأ بمسرع، ثم يضيف طبقة من الأتمتة. توفر طبقة الأتمتة القدرات التي يحتاجها فريقك من أجل دعم فرق حمل العمل بشكل كامل مع ميزات النظام الأساسي مثل نشر وحدة التحكم بالمجال للتطبيقات القديمة.
  • مع انتقال فريق النظام الأساسي إلى نهج DevOps، يحتاجون إلى إنشاء عملية للتعامل مع إصلاحات الطوارئ. يمكنهم استخدام الأذونات المؤهلة إدارة الهويات المتميزة (PIM) لطلب الوصول لإجراء الإصلاحات وإعادتها لاحقا إلى التعليمات البرمجية للحد من انحراف التكوين، أو يمكنهم استخدام التعليمات البرمجية لتنفيذ إصلاح سريع. يجب على فريقك دائما تسجيل إصلاحات سريعة في تراكماتهم حتى يتمكنوا من إعادة صياغة كل إصلاح في وقت لاحق والحد من ديونهم التقنية. يؤدي الكثير من الديون التقنية إلى التباطؤ في المستقبل نظرا لأن بعض التعليمات البرمجية للنظام الأساسي لا تتم مراجعتها بالكامل ولا تفي بإرشادات ومبادئ ترميز الفريق.
  • يمكنك استخدام نهج Azure لإضافة بعض الأتمتة إلى النظام الأساسي الخاص بك. ضع في اعتبارك استخدام IaC لنشر نهج Azure وإدارتها، وغالبا ما يشار إليها باسم Policy-as-Code (PaC). تتيح لك هذه النهج أتمتة الأنشطة مثل مجموعة السجلات. تنفذ العديد من أطر عمل PaC أيضا عملية إعفاء، لذا خطط لفرق حمل العمل لطلب إعفاءات من النهج.
  • استخدم "الحوكمة المستندة إلى النهج" للإشارة إلى فرق حمل العمل عند محاولة توزيع الموارد التي لا تفي بعنصر تحكم الأمان. ضع في اعتبارك نشر النهج مع deny تأثير هذه الحالات، ما يسمح لفرق حمل العمل لديك أيضا بمعاملة كل شيء كتعلم برمجي وتجنب انحراف التكوين حيث تعلن التعليمات البرمجية عن شيء واحد وتغيير النهج لإعداد في وقت النشر. تجنب استخدام modify التأثيرات، مثل ما إذا كان فريق حمل العمل ينشر حساب تخزين مع supportOnlyHttpsTraffic = false تعريف في التعليمات البرمجية modify الخاصة به حيث يتغير النهج إلى true في وقت التوزيع للحفاظ على توافقه. يؤدي هذا إلى انحراف التعليمات البرمجية عما يتم نشره.

توصية بتصميم أتمتة النظام الأساسي

  • اتبع نهج كل شيء كتعلم برمجي للشفافية الكاملة والتحكم في التكوين للنظام الأساسي ل Azure والوثائق والتوزيع وعملية الاختبار.
  • استخدم التحكم بالإصدار لإدارة جميع مستودعات التعليمات البرمجية الخاصة بك، بما في ذلك:
    • البنية الأساسية كتعليمة برمجية
    • النهج كتعلم برمجي
    • Configuration as Code
    • النشر كتعلم برمجي
    • الوثائق كتعليق برمجي
  • تنفيذ مبدأ العيون الأربع وعملية لبرمجة الأقران أو مراجعة النظراء لضمان مراجعة جميع تغييرات التعليمات البرمجية من قبل فريقك قبل توزيعها في الإنتاج.
  • اعتماد استراتيجية تفريع لفريقك وتعيين نهج الفروع للفروع التي تريد حمايتها. مع نهج الفرع، يجب على الفرق استخدام طلبات السحب لإجراء تغييرات الدمج.
  • استخدم التكامل المستمر والتسليم المستمر (CI/CD) لأتمتة اختبار التعليمات البرمجية وتوزيعها في بيئات مختلفة.
  • اعمل على أتمتة كل شيء، مثل توفير النظام الأساسي وتكوينه وإدارته وتوفير اشتراكات المنطقة المنتقل إليها لفرق حمل العمل.
  • استخدم أحد المسرعات المتوفرة التي تطابق قدرات فريقك للبدء في نشر مناطق Azure المنتقل إليها.
  • خطط لاستخدام نهج نشر متعدد الطبقات لإضافة قدرات لا يغطيها مسرع ولكن هناك حاجة إليها لدعم فرق حمل العمل بشكل كامل.
  • إنشاء عملية لاستخدام التعليمات البرمجية لتنفيذ الإصلاحات السريعة. سجل دائما الإصلاحات السريعة في تراكم فريقك بحيث يمكن إعادة صياغة كل إصلاح في وقت لاحق ويمكنك الحد من الديون التقنية.
  • استخدام البنية الأساسية كتعلم برمجي لنشر نهج Azure وإدارتها (يشار إليها غالبا باسم Policy-as-Code)
  • تنفيذ عملية إعفاء للنهج. خطط لفرق حمل العمل لطلب إعفاءات من النهج، وأن تكون مستعدا لإلغاء حظر الفرق عند الحاجة.
  • استخدم "الحوكمة المستندة إلى النهج" لحظر فرق حمل العمل عند محاولة توزيع الموارد التي لا تفي بعنصر تحكم الأمان. يساعد هذا في تقليل انحراف التكوين، حيث تعلن التعليمات البرمجية عن حالة مختلفة عما ينتهي به الأمر إلى التوزيع.

اقرأ المزيد