تخطَّ إلى المحتوى الرئيسي
AMA GROUP

السحابة

قبل أن تتوسع: مراجعة معمارية لتكلفة السحابة وموثوقيتها

التوسع يضاعف كل ما في معماريتك: الكفاءة والهدر، والمتانة والهشاشة. قائمة مراجعة من سبعة محاور ينبغي إنجازها قبل أن تنمو الحركة والبيانات والفرق.

الموضوع
السحابة
تاريخ النشر
مدة القراءة
5 دقائق قراءة
الكاتب
فريق تحرير AMA GROUP

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

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

1. حدّد معنى «الموثوقية» لهذا النظام

  • ضع أهداف مستوى الخدمة (SLOs) لكل رحلة مستخدم حرجة، مثل تسجيل الدخول وإتمام الدفع وتقديم الطلب، تشمل التوافر وزمن الاستجابة، بدل رقم واحد لنسبة التشغيل للمنصة كلها.
  • اعتمد «ميزانية أخطاء» متفقًا عليها، تجعل المفاضلة بين سرعة الإطلاق والاستقرار قرارًا مشتركًا وصريحًا.
  • حدّد لكل مخزن بيانات هدفي زمن الاستعادة ونقطة الاستعادة (RTO وRPO)، وتأكد أن المعمارية قادرة فعلًا على تحقيقهما.
  • ارسم خريطة الاعتماديات الخارجية، كبوابات الدفع ومزودي الرسائل النصية وخدمات الهوية، وحدّد سلوك النظام عند تعطل كلٍّ منها.

2. وضوح التكاليف قبل خفضها

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

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

3. الحوسبة: اضبط الحجم أولًا ثم التزم

  • اضبط أحجام الخوادم والحاويات بناءً على الاستهلاك الفعلي المرصود، لا على تقديرات يوم الإطلاق.
  • هيّئ التوسع التلقائي بحدود دنيا وعليا معقولة، واختبر أنه يتقلص كما يتوسع.
  • أوقف بيئات التطوير والاختبار خارج ساعات العمل، أو قلّصها إلى الصفر حيث تسمح المنصة.
  • لا تشترِ خصومات الالتزام طويلة الأجل إلا بعد استقرار أنماط الاستخدام؛ فالالتزام بأساس مُضخّم يثبّت الهدر.
  • استخدم السعة منخفضة التكلفة القابلة للمقاطعة (spot) لأعباء العمل التي تحتمل الانقطاع، كالمعالجة الدفعية وخطوط التكامل المستمر.

4. البيانات: مركز التكلفة الصامت

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

5. معمارية الموثوقية

  • شغّل المكونات ذات الحالة عبر أكثر من منطقة توافر، وابحث عن نقاط الفشل المفردة الخفية، مثل بوابة NAT واحدة أو وسيط رسائل وحيد.
  • ضع مهلة زمنية لكل اتصال شبكي، وأعد المحاولة بتأخير متصاعد مع عشوائية، واستخدم قواطع الدائرة (circuit breakers) لمنع تسلسل الأعطال.
  • اجعل العمليات متساوية الأثر (idempotent) حتى لا تُنشئ إعادة المحاولة طلبات أو مدفوعات مكررة.
  • استخدم الطوابير لامتصاص الذروات بدل تحجيم كل شيء على أعلى حمل.
  • صمّم لتراجع الأداء بتدرّج منضبط (graceful degradation): حين تتعطل خدمة غير حرجة، ينبغي أن تستمر الرحلة الأساسية.

6. الجاهزية التشغيلية

  • أدِر البنية التحتية كلها كشيفرة (مثل Terraform أو OpenTofu)، دون أي تعديلات يدوية في بيئة الإنتاج.
  • اجمع المقاييس والسجلات والتتبع وفق معيار موحد مثل OpenTelemetry.
  • اجعل التنبيهات مبنية على ما يشعر به المستخدم، كمعدلات الأخطاء وزمن الاستجابة مقارنة بالأهداف، لا على استهلاك المعالج والذاكرة وحدهما.
  • احتفظ بأدلة تشغيل للأعطال الأكثر احتمالًا، وبجدول مناوبة واضح ومسارات تصعيد محددة.
  • اختبر الأحمال عند الذروة المتوقعة مع هامش أمان، ونفّذ تمارين محاكاة لسيناريوهات أعطال حقيقية.

7. سيادة البيانات وموقع الاستضافة

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

مؤشرات على أن المراجعة تأخرت

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

كيف تُجرى المراجعة؟

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

اسعَ إلى أقل تكلفة لكل وحدة قيمة، لا إلى أصغر فاتورة.

موضوعات المقال

  • الهندسة السحابية
  • إدارة تكاليف السحابة
  • الموثوقية
  • DevOps
  • سيادة البيانات

شارك المقال

كل المقالات
كل المقالات

من المقال إلى التنفيذ

هل تواجه قرارًا مشابهًا في منشأتك؟

حدّثنا عن السياق والقيود، وسنساعدك على تحويل الفكرة إلى خطة تنفيذ واضحة.