مشاركة عبر

إدارة التحليلات على نطاق السحابة

  • مقالة

اليوم، قامت DevOps بتحويل ثقافة كيفية تفكير الناس وعملهم، وتسريع معدل تحقيق الشركات للقيمة من خلال مساعدة الأفراد والمنظمات على تطوير ممارسات العمل المستدامة والحفاظ عليها. يجمع DevOps بين التطوير والعمليات، وغالبا ما يرتبط بأدوات هندسة البرامج التي تدعم ممارسات التكامل المستمر (CI) والتسليم المستمر (CD). تتضمن هذه الأدوات والممارسات مديري التعليمات البرمجية المصدر (مثل Git أو Apache Subversion أو Team Foundation Version Control) ومديري البناء والتسليم التلقائيين (مثل Azure Pipelines أو GitHub Actions).

DevOps جنبا إلى جنب مع إمكانية الملاحظة هو المفتاح لتوفير نظام أساسي مرن وقابل للتطوير. تمنح DevOps الفرق القدرة على تنفيذ التحكم بالمصادر، وتدفقات CI/CD، والبنية الأساسية كتعلم برمجي، وسير العمل والأتمتة. في حين أن إمكانية المراقبة تمكن مالكي الأعمال ومهندسي DevOps ومهندسي البيانات ومهندسي البيانات ومهندسي موثوقية الموقع من اكتشاف المشكلات والتنبؤ بها ومنعها وحلها بطريقة تلقائية وتجنب التخلص من وقت التعطل الذي من شأنه أن يكسر تحليلات الإنتاج الذكاء الاصطناعي.

التحكم في المصادر

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

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

هام

اتبع هذه الإرشادات لمستودعات التحليلات على نطاق السحابة:

  • تأمين الفرع الرئيسي للمستودع عن طريق فرض الفروع وطلبات السحب لضمان عمليات المراجعة الخاضعة للرقابة.
  • يجب استخدام مستودعات Azure DevOps أو GitHub للتحكم في المصدر لتعقب التغييرات على التعليمات البرمجية المصدر والسماح لعدة أعضاء في الفريق بتطوير التعليمات البرمجية في نفس الوقت.
  • يجب التحقق من التعليمات البرمجية للتطبيق وتكوينات البنية الأساسية في مستودع.

CI/CD pipelines

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

يمكن أن تحتوي المسارات على مراحل متعددة مع مهام مختلفة ويمكن أن يكون لها تدفقات موافقة بسيطة ومعقدة لضمان التوافق والتحقق من الصحة. استنادا إلى التفضيل، يمكن أيضا تكوين المسارات مع مشغلات تلقائية مختلفة. بالنسبة للنشر على نطاق المؤسسة الذكاء الاصطناعي، يجب أن يكون لخطوات الإنتاج دائما موافقة مسبقة من قبل الإنسان، وهذا مضمن في نموذج العملية. يجب إنشاء مسارات CI/CD باستخدام GitHub Actions أو Azure Pipelines، ويجب أن تكون مشغلات تلقائية.

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

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

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

النهجان تجاه IaC تعريفيان وضروريان:

  • يشير التعريفي إلى تحديد الحالة المطلوبة للبنية الأساسية ووجود محرك تنسيق ينفذ الإجراءات اللازمة لتحقيق الحالة المطلوبة. في Azure، يتم ذلك باستخدام قوالب Azure Resource Manager. طبقات تجريد الجهات الخارجية مثل Terraform متاحة أيضا لهذا النهج.

  • يشير النهج الإلزامي إلى تنفيذ أوامر محددة بترتيب محدد. بالنسبة إلى Azure، يمكن تحقيق ذلك باستخدام واجهة سطر الأوامر أو PowerShell، ولكن تتوفر أيضا مجموعات مطوري برامج لغة البرمجة الأصلية، على سبيل المثال، .NET وPython وJava، إذا كانت هناك حاجة إلى حلول متكاملة.

في قوالب Azure Resource Manager، يكون التوفير الأساسي في قسم الموارد، ويتم تعريف تكوين الموارد الفردية في قسم الخصائص. بالنسبة إلى Azure Data Lake Storage Gen2، يبدو التكوين كما يلي:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.MachineLearningServices/workspaces/datastores",
            "name": "[concat(parameters('workspaceName'), '/', parameters('datastoreName'))]",
            "apiVersion": "2020-05-01-preview",
            "location": "[parameters('location')]",
            "properties": {
                "DataStoreType": "adls-gen2",
                "SkipValidation": "[parameters('skipValidation')]",
                "ClientId": "[parameters('clientId')]",
                "ClientSecret": "[parameters('clientSecret')]",
                "FileSystem": "[parameters('fileSystem')]",
                "AccountName": "[parameters('accountName')]",
                "TenantId": "[parameters('tenantId')]",
                "ResourceUrl": "[parameters('resourceUrl')]",
                "AuthorityUrl": "[parameters('authorityUrl')]"
            }
        }
    ]
}

هام

يجب تعريف كل طبقة من التحليلات على نطاق السحابة مثل المنطقة المنتقل إليها لإدارة البيانات أو مناطق هبوط البيانات أو تطبيقات البيانات (التي تنشئ منتجات بيانات)، بلغة تعريفية مثل Azure Resource Manager أو Terraform، وفحصها في مستودع، ونشرها من خلال مسارات CI/CD. يسمح هذا للفرق بتعقب التغييرات وإصدارها للبنية الأساسية وتكوين نطاق Azure مع دعم مستويات البنية المختلفة ليتم أتمتتها بطريقة مرنة. تقود هذه الإرشادات الفرق إلى استخدام مستودعات Git للحصول دائما على رؤية لحالة نطاقات Azure محددة.

مهام سير العمل والأتمتة

يجب على Teams استخدام البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD في مراحل متعددة لضمان أن التعليمات البرمجية المطورة بدون أخطاء وجاهزة للإنتاج. بعض أفضل الممارسات هي أن يكون لديك بيئة تطوير وبيئة اختبار وبيئة إنتاج. يجب أن تنعكس هذه المراحل أيضا في Azure باستخدام خدمات منفصلة لكل بيئة.

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

يجب إدارة عمليات التوزيع للاختبار والإنتاج فقط من خلال مسار CI/CD واتصال خدمة بأذونات مرتفعة لفرض أفضل الممارسات الشائعة (على سبيل المثال، قوالب Azure Resource Manager).

تنبيه

يجب أن يكون لدى فرق تطبيقات البيانات حق الوصول للقراءة فقط إلى بيئات الاختبار والإنتاج، ويجب تنفيذ عمليات التوزيع في هذه البيئات فقط من خلال مسارات CI/CD واتصالات الخدمة بأذونات مرتفعة. لتسريع المسار إلى الإنتاج، يجب أن يكون لدى فرق تطبيقات البيانات حق الوصول للكتابة إلى بيئة التطوير.

الخطوات التالية

أتمتة النظام الأساسي