السحابة وDevOps

منطقة الهبوط أولاً، ثم الأحمال

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

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

• خط أساس للحسابات والاشتراكات والشبكة كشيفرة
• سياسة مركزية للهوية والتسجيل والنسخ الاحتياطي
• معيار وسم يجعل الكلفة قابلة للنسب إلى كل فريق

موجات ترحيل مرتّبة حسب المخاطر

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

وبعض الأنظمة ينبغي ألا تنتقل. وقول ذلك مبكراً يوفّر مالاً أكثر مما توفّره أي عملية تحسين لاحقة.

الكلفة قيد تصميمي

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

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

عمليات النشر ينبغي أن تكون مملّة

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

ما الذي تحصل عليه

النتائج المعتادة

التقنيات التي نستخدمها

أسئلة