سيناريوهات DevOps في الوقت الفعلي - تعرف على ما يحدث في الوقت الفعلي



تتحدث هذه المدونة عن سيناريوهات الوقت الفعلي لـ DevOps لمساعدتك على فهم التحديات التي قد تواجهها في الوقت الفعلي وكيفية التغلب عليها.

قد يكون الكثير منكم على دراية بجميع النظريات المتعلقة . لكن هل تعرف كيفية تطبيق مبادئ DevOps في الحياة الواقعية؟ في هذه المدونة ، سأناقش سيناريوهات DevOps Real Time التي ستساعدك في الحصول على فهم موجز لكيفية عمل الأشياء في الوقت الفعلي.

المؤشرات التي سأغطيها في هذامقالة سيناريوهات DevOps في الوقت الفعليهي:





فلنبدأ بموضوعنا الأول.

أدوار ومسؤوليات مسؤول نظام لينوكس

ما هو DevOps؟

devops-devops سيناريوهات الوقت الحقيقي-EdurekaDevOps هو نهج تطوير برمجي يتضمن التطوير المستمر والاختبار المستمر والتكامل المستمر والنشر المستمر والمراقبة المستمرة للبرنامج طوال دورة حياته التطويرية. هذه الأنشطة ممكنة فقط في DevOps ، وليس في Agile أو في الشلال. هذا هو السبب وراء اختيار Facebook وشركات كبرى أخرى DevOps كطريقة للمضي قدمًا في تحقيق أهداف أعمالهم.يُفضل DevOps بشكل أساسي لتطوير برامج عالية الجودة في دورات تطوير أقصر مما يؤدي إلى زيادة رضا العملاء.



في القسم التالي من هذامقالة DevOps Real Time Scenarios ، سنلقي نظرة على المشكلات المختلفة التي تم حلها بواسطة DevOps.

تم حل المشكلات بواسطة DevOps

1. تقديم قيمة للعملاء

  • DevOps يقلل الوقت يتطلب الأمر تقديم قيمة للعملاء. تقل مدة الدورة من انتهاء المطور للقصة / المهمة حتى الإنتاج بشكل كبير ، مما يسمح بتحقيق القيمة في أسرع وقت ممكن.
  • أهم قيمة تحققها DevOps هي أنها تتيح لمؤسسات تكنولوجيا المعلومات ذلك التركيز على أنشطتهم التجارية 'الأساسية' . من خلال إزالة القيود داخل تدفق القيمة وأتمتة خطوط أنابيب النشر ، يمكن للفرق التركيز على الأنشطة. يساعد هذا في إنشاء قيمة للعميل بدلاً من مجرد نقل وحدات البايت والبايت. تزيد هذه الأنشطة من الميزة التنافسية المستدامة للشركة وتخلق نتائج أعمال أفضل.



2. تقليل وقت الدورة

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

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

3. حان الوقت للتسويق

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

4. حل المشكلة

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

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

CI (التكامل المستمر) فيسيناريوهات الوقت الحقيقي DevOps

1. قد يرى الأفراد التكامل المستمر يؤدي إلى نتائج عكسية

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

للتغلب على هذا:

  • أولاً ، تأكد من مشاركة فريقك بالكامل قبل اعتماد التكامل المستمر.

  • يجب أن يساعد كبار المديرين التنفيذيين وقادة الفريق أعضاء الفريق على فهم تكاليف وفوائد التكامل المستمر.

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

2. دمج CI في تدفق التطوير الحالي

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

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

للتغلب على هذا:

  • يجب أن تتأكد من إعطاء الوقت الكافي لفريقك لتطوير سير العمل الجديد. يتم ذلك من أجل تحديد حل تكامل مستمر مرن يمكنه دعم سير العمل الجديد.

  • تأكد أيضًا من أن الشركة تدعمهم حتى لو لم تسر الأمور بسلاسة في البداية.

3. العودة إلى عادات الاختبار السابقة

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

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

للتغلب على هذا:

  • يجب التأكيد على أن كتابة حالات الاختبار من البداية يمكن أن توفر الكثير من الوقت لفريقك ويمكن أن تضمن تغطية اختبار عالية لمنتجك.

  • أيضًا ، قم بتضمين الفكرة في ثقافة شركتك بأن حالات الاختبار هي أصول قيمة مثل قاعدة الشفرة نفسها.

4. تجاهل المطورين لرسائل الخطأ

إنها مشكلة شائعة عندما تعمل الفرق الكبيرة معًا ، يصبح مقدار إشعارات CI ساحقًا ويبدأ المطورون في تجاهلها وكتمها. لذلك ، من المحتمل أن يفوتهم التحديثات ذات الصلة بهم.

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

للتغلب على هذا:

  • يجب عليك فقط إرسال التحديثات الهامة.

  • أرسل الإشعار فقط إلى المطورين المعنيين المسؤولين عن إصلاحه.

CT (اختبار مستمر) فيسيناريوهات الوقت الحقيقي DevOps

  1. الحصول على مواصفات المتطلبات بشكل صحيح

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

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

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

  2. تنسيق خطوط الأنابيب

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

    لكن السبب وراء ارتباك الفرق هو أنه لا يوجد حل واحد يوفر سلسلة الأدوات الكاملة المطلوبة لبناء خط أنابيب للقرص المضغوط.

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

    عكس رقم في جافا

    باختصار ، من المستحيل تنفيذ اختبار مستمر بدون سرعة وموثوقية خط أنابيب معياري وآلي.

  3. تصعيد وإدارة التعقيد

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

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

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

  4. إنشاء حلقات التغذية الراجعة

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

    لم تعد حلقات التعليقات التقليدية مثل أدوات التسجيل ومعرفات التعليمات البرمجية وأدوات مراقبة الأداء فعالة بعد الآن. لا يعملان معًا ولا يوفران عمق البصيرة المطلوبة لإصلاح المشكلات. تساعد لوحات المعلومات في الوقت الفعلي التي تنشئ التقارير تلقائيًا وردود الفعل القابلة للتنفيذ عبر SDLC بالكامل على إطلاق البرنامج بشكل أسرع في الإنتاج مع عيوب أقل. يساعد الوصول في الوقت الفعلي إلى لوحات المعلومات والوصول لجميع أعضاء الفريق إلى آلية التعليقات المستمرة.

  5. قلة البيئات

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

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

قرص مضغوط (توصيل مستمر) فيسيناريوهات الوقت الحقيقي DevOps

  1. عمليات النشر تستغرق وقتًا طويلاً

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

    ما الذي تقدمه DevOps إلى الطاولة؟ تحدد فرق عمليات التطوير وتكنولوجيا المعلومات عملية النشر في جلسة تعاون بلا لوم. أولاً ، يتحققون مما ينجح ثم ينتقلون به إلى المستوى التالي بالأتمتة لتسهيل التسليم المستمر. هذا يقلل بشكل كبير من توقيت النشر ، كما أنه يمهد الطريق لمزيد من عمليات النشر المتكررة.

  2. القطع الأثرية والنصوص والاعتمادات الأخرى المفقودة

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

    عندما يتعلق الأمر بالأتمتة ، يمكنك تحديد التبعيات التي تساعد كثيرًا في تسريع عمليات النشر. أدوات إدارة التكوين مثل دمية أو رئيس المساهمة بمستوى إضافي من تعريف التبعيات. يمكننا تحديد ليس فقط التبعيات داخل تطبيقنا ولكن أيضًا على مستوى تكوين البنية التحتية والخادم. على سبيل المثال ، يمكننا إنشاء جهاز افتراضي للاختبار والتثبيت / التكوين هر قبل نشر القطع الأثرية لدينا.

  3. مراقبة الإنتاج غير الفعالة

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

يجب أن توافق على ما يجب مراقبته والمعلومات التي يجب إنتاجها ، ثم وضع الضوابط في مكانها الصحيح. تُعد أدوات إدارة أداء التطبيق مساعدة كبيرة إذا كانت مؤسستك قادرة على تحمل تكاليفها ، ألق نظرة على AppDynamics و New Relic و AWS X-Ray.

سيناريوهات بيانات DevOps

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

1. وقت أقل لتحليل البيانات

مع كل البيانات التي يتم إنشاؤها في أي وقت ، تحتاج المؤسسات إلى قبول حقيقة أنها لا تستطيع تحليلها كلها. ببساطة ، ليس هناك ما يكفي من الوقت في اليوم - وللأسف ، الروبوتات ليست متطورة بما يكفي للقيام بكل ذلك من أجلنا حتى الآن.

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

بعض النصائح السريعة لتحديد البيانات الأكثر أهمية لتحليلها:

  • قم بعمل مخطط: حدد تأثير الانقطاعات على عملك ، وطرح أسئلة مثل ، 'إذا X فواصل ، ما هو تأثير ذلك على الميزات الأخرى؟ '

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

2. صعوبة التواصل

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

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

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

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

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

3. نقص القوى العاملة

عند نقص الموظفين ، نحتاج إلى أدوات أكثر ذكاءً تستخدم التعلم العميق لإدخال البيانات التي نجمعها والوصول إلى القرارات بسرعة. بعد كل شيء ، لا أحد لديه الوقت للنظر في كل اختبار منفرد (وبالنسبة لبعض المؤسسات الكبيرة ، يمكن أن يكون هناك حوالي 75000 في يوم معين). الحيلة هي التخلص من الضوضاء والعثور على الأشياء المناسبة للتركيز عليها.

هذا هو المكان الذي يمكن أن يساعد فيه الذكاء الاصطناعي والتعلم الآلي. تستخدم العديد من الأدوات في السوق اليوم الذكاء الاصطناعي والتعلم الآلي للقيام بأشياء مثل:

  • تطوير البرامج النصية والاختبارات لنقل والتحقق من صحة أجزاء مختلفة من البيانات

    كيفية استخدام ملف جافا
  • الإبلاغ عن الجودة بناءً على السلوكيات التي تم تعلمها مسبقًا

  • العمل استجابة للتغييرات في الوقت الفعلي.

بهذا نكون قد وصلنا إلى نهاية هذه المقالة في سيناريوهات DevOps Real Time.

الآن بعد أن فهمت ما هي سيناريوهات DevOps Real Time ، تحقق من هذا من Edureka ، وهي شركة تعليمية موثوقة عبر الإنترنت مع شبكة تضم أكثر من 250000 متعلم راضٍ منتشرين في جميع أنحاء العالم. تساعد الدورة التدريبية لشهادة Edureka DevOps المتعلمين على فهم ما هو DevOps واكتساب الخبرة في عمليات وأدوات DevOps المختلفة مثل Puppet و Jenkins و Nagios و Ansible و Chef و Saltstack و GIT لأتمتة خطوات متعددة في SDLC.

لديك سؤال لنا؟ يرجى ذكرها في قسم التعليقات من هذامقالة سيناريوهات DevOps في الوقت الفعليوسنعاود الاتصال بك.