استضافة موقع ليست استضافة تطبيق: اختر البنية قبل أن تدفع

ياسر نجيب
•
•
آخر مراجعة:
•
9 دقائق قراءة

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

هذه المقالة لا تقدم مزوداً فائزاً لكل الحالات ولا رقماً سحرياً للسعة أو التكلفة. تقدم طريقة قابلة للمراجعة، ثم تطلب قياسها على عبء العمل الحقيقي. راجعت المصادر الرسمية في 2026-08-28، وأي مقارنة مع Google Cloud هنا مبنية على الوثائق وليست ادعاء خبرة تشغيل مباشرة.

القرار في دقيقة

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

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

الأداة القابلة لإعادة الاستخدام

البندالقراردليل القبول
صفحات ثابتةاستضافة ثابتة وCDNلا Runtime على الخادم
حدث أو APIServerlessتنفيذ محدود وتوسع مُدار
خدمة طويلةحاويات مُدارةImage وفحص صحة وتوسع
نظام قديم أو تحكم كاملVPS أو VMالفريق يملك النظام والتوافر
الحالةقاعدة وملفات وطابور مُدارنسخ وفشل واحتفاظ محدد

ضع هذه المصفوفة داخل قرار المعمارية أو تذكرة التنفيذ. كل صف بلا مالك أو دليل قبول هو خطر مؤجل.

كيف تستخدم الأداة فعلياً

1. صفحات ثابتة

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

2. حدث أو API

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

3. خدمة طويلة

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

4. نظام قديم أو تحكم كامل

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

5. الحالة

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

تسلسل التنفيذ

  1. الموقع الثابت يقدم ملفات مبنية مسبقاً ويمكن وضع معظم حركته خلف CDN. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 1 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  2. التطبيق ينفذ منطقاً لكل طلب ويوثق المستخدم ويكتب البيانات ويتصل بخدمات ويحتاج نشراً ورجوعاً. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 2 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  3. Serverless يقلل تشغيل الخوادم لكنه يضيف حدود Runtime وبداية باردة وسلوك تزامن وارتباطاً بالمزود. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 3 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  4. الحاويات المُدارة تناسب خدمات HTTP طويلة التشغيل والصور القابلة للنقل، بينما ينقل VPS الترقيع ومراقبة العمليات والتوسع والاستعادة إلى المشغل. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 4 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.
  5. توافر المؤسسات يحتاج أيضاً بيانات وطوابير وأسراراً ومراقبة واستعادة مجربة ومسؤول عطل. ابدأ في بيئة غير إنتاجية، واجعل نتيجة الخطوة 5 ملفاً أو إعداداً أو مقياساً قابلاً للمراجعة.

لا تنقل الإعداد يدوياً بين البيئات. ضع السياسة والبنية ومسار النشر تحت التحكم بالإصدار عندما تسمح الخدمة، وافصل سر الإنتاج عن Build. يجب أن يتمكن شخص آخر من إعادة الخطوات من المستودع وRunbook دون معرفة مخفية.

عقد التسليم بين DevOps والمطورين

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

يعيد مسؤول DevOps عنوان البيئة وحدود الصلاحية ومسار السجلات ولوحة القياس ومدة الاحتفاظ وخطة النشر والرجوع. قبل الموافقة يتفق الطرفان على مسؤول مراقبة الإصدار ومدة نافذة القرار وحد الإحصائي الذي يوقف Canary أو يعيد النسخة. بعد النشر لا تكفي رسالة «تم». أرفق Digest المنشور ووقت النشر ونتيجة Smoke والرابط الفعلي وحالة الترحيل وأي انحراف مقبول مع تذكرة متابعة. هذا العقد يمنع أن يصبح فشل الإعداد مشكلة مجهولة بين فريقين.

أنماط الفشل التي يجب تصميم الاختبار حولها

شراء VPS كبير لموقع تسويقي ثابت.

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

تشغيل تطبيق ذي حالة في حاوية واحدة مع ملفات محلية وجلسات في الذاكرة.

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

اختيار Serverless قبل اختبار الاتصالات ومدة التنفيذ والمهام الخلفية.

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

وصف نسختين من التطبيق بالتوافر العالي وهما تعتمدان على قاعدة واحدة غير محمية.

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

بوابات الاختبار والنشر

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

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

التكلفة دون رقم تسويقي

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

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

ملاحظة من التشغيل

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

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

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

  1. انسخ الأداة أعلاه واملأها بأرقام النظام ومسؤوليه لا بتوقعات المبيعات.
  2. اختر أخطر فرضيتين ونفذ لهما اختبار فشل واستعادة في بيئة غير إنتاجية.
  3. سجل القرار والبدائل والتكلفة ودليل القبول وتاريخ المراجعة.
  4. اربط هذه المقالة بالمقالات الأخرى في سلسلة DevOps والسحابة واختر الخطوة التالية حسب الفجوة.

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

تابع السلسلة

استخدم الروابط كمسار تعلم، لكن نفذ كل قرار على بيانات النظام الفعلية.

المصادر وتاريخ المراجعة

آخر مراجعة: 2026-08-28. راجع الأسعار والحصص وتوافر الميزات في المنطقة مباشرة قبل التنفيذ.

اقرأ أيضاً