مليون مستخدم ليس معمارية: خطط للسعة قبل اختيار AWS أو Google Cloud

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

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

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

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

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

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

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

البندالقرار
الطلبالمستخدم اليومي والجلسات والإجراءات ومعامل الذروة
التزامنطلبات الذروة × زمن الخدمة عند p95
البياناتالسجلات والملفات والنمو والاحتفاظ والإصدارات
الاعتماديةSLO وRTO وRPO وسعة فشل المنطقة
الاختبارالتدرج والمدة وحالة الكاش وحدود النجاح

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

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

1. الطلب

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

2. التزامن

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

3. البيانات

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

4. الاعتمادية

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

5. الاختبار

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

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

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

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

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

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

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

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

قسمة طلبات اليوم على 86400 واعتبار المتوسط هو الذروة.

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

اختبار GET المخزن فقط وترك الدخول والدفع والرفع والتقارير بلا قياس.

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

توسيع الخوادم عديمة الحالة بينما تختنق قاعدة البيانات أو الطوابير أو اتصالاتها أو API خارجي.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تابع السلسلة

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

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

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

اقرأ أيضاً