البنية التحتية لشركات SaaS الناشئة: من أول سيرفر إلى أول سنة

في السنة الأولى تحتاج شركة SaaS الناشئة بنية أبسط مما يتخيله أغلب المؤسسين: سيرفر إنتاج واحد بموارد مخصصة وحجم مناسب، وسيرفر staging صغير منفصل، ونسخ احتياطية تلقائية لقاعدة البيانات تجرّب استرجاعها فعلًا بشكل دوري، ومراقبة أساسية، وقرار واعٍ بخصوص مكان تخزين بيانات العملاء. أما Kubernetes وتعدد المناطق والـ microservices فيمكن تأجيلها حتى يكون عندك أكثر من خدمة وشخص مسؤول عن تشغيلها. في هذا المقال نرتب ما تبنيه، وبأي ترتيب، والأخطاء التي يصعب إصلاحها لاحقًا.

ما تحتاجه من أول يوم

• سيرفر الإنتاج: عليه التطبيق والـ API والعمليات الخلفية، وقاعدة البيانات في البداية.

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

• نسخ احتياطية في مكان آخر: ملفات dump لقاعدة البيانات تُنقل خارج سيرفر الإنتاج، إضافة إلى نسخ السيرفر نفسه.

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

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

كل ما عدا ذلك اختياري في السنة الأولى. والفرق التي تتجاهل الـ staging أو تجارب الاسترجاع تدفع الثمن غالبًا خلال الشهور الأولى.

سيرفر واحد قوي أم Kubernetes مبكرًا؟

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

• عبء التشغيل: الـ cluster له تحديثاته وشبكته والـ ingress والتخزين والشهادات. السيرفر الواحد يحتاج تحديثات النظام ومدير عمليات.

• تتبع الأعطال: على سيرفر واحد تفحص جهازًا واحدًا. في الـ cluster قد يمر الطلب الفاشل على pod وnode وشبكة داخلية وDNS داخلي.

• التكلفة: الـ cluster يحتاج عدة أجهزة قبل أن يعطيك أي حماية من التعطل، بينما سيرفر قوي مع نسخ احتياطية جيدة كثيرًا ما يكلف أقل.

• المرونة المستقبلية: غلّف التطبيق في Docker من البداية، فيبقى الانتقال إلى Kubernetes ممكنًا لاحقًا بدون أن تدفع ثمنه الآن.

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

بيئة staging وإنتاج بشكل صحيح

الـ staging مفيد فقط إذا كان يشبه الإنتاج: نفس إصدار النظام، ونفس الإصدار الرئيسي لقاعدة البيانات، ونفس إعدادات الـ reverse proxy، ونفس أسماء متغيرات البيئة. الاختلاف يكون في القيم فقط.

1. كل تعديل ينزل على staging أولًا، بما في ذلك الـ migrations.

2. بيانات الـ staging مجهّلة أو تجريبية. لا تنسخ بيانات عملاء حقيقية إليه بدون نفس حماية الإنتاج.

3. اجعل الـ migration متوافقًا مع الإصدار السابق: أضف العمود الجديد، ثم انشر كودًا يكتب في الاثنين، ثم احذف القديم في إصدار لاحق.

4. احتفظ بالإصدار السابق على السيرفر، ليكون الرجوع تبديل symlink أو tag، لا إعادة بناء.

النسخ الاحتياطي وتجارب الاسترجاع

قبل اختيار طريقة النسخ اكتب رقمين: RPO وهو أقصى كمية بيانات يمكنك تحمّل فقدها، وRTO وهو أقصى مدة توقف مقبولة. النسخة الليلية تعني أنك قد تفقد حتى 24 ساعة من البيانات. لو عملاؤك لا يقبلون ضياع يوم من الفواتير، أضف أرشفة WAL المستمرة في PostgreSQL للاسترجاع إلى لحظة محددة.

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

createdb restore_test
time pg_restore --no-owner -d restore_test /backups/app-latest.dump
psql -d restore_test -c "SELECT count(*) FROM tenants;"

سجّل المدة وتأكد أن أعداد الصفوف منطقية. هذه المدة هي الـ RTO الحقيقي، وليس الرقم المكتوب في الخطة.

عزل بيانات العملاء في نظام multi-tenant

أغلب منتجات SaaS تخزن عملاء كثيرين في نظام واحد، وأمامك ثلاثة نماذج شائعة:

• جداول مشتركة بعمود tenant_id: الأسهل في التشغيل والتحديث، وخطره أن استعلامًا ينقصه شرط WHERE قد يكشف بيانات عميل لعميل آخر.

• schema لكل عميل: فصل أقوى داخل قاعدة واحدة، لكن الـ migrations تتكرر لكل عميل وتبطؤ مع المئات.

• قاعدة بيانات لكل عميل: أقوى عزل وأسهل تصدير أو حذف لبيانات عميل بعينه، مع أعلى تكلفة تشغيل. يُستخدم عادة للعملاء الكبار أو الخاضعين لقواعد خاصة.

إذا بدأت بالجداول المشتركة، اجعل قاعدة البيانات نفسها تفرض العزل بدل الاعتماد على كل استعلام. ميزة row-level security في PostgreSQL تفعل ذلك:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

ثم ينفذ التطبيق SET LOCAL app.tenant_id = '...' في بداية كل transaction. واتصل بمستخدم لا يملك الجداول، لأن مالك الجدول يتجاوز هذه السياسات ما لم تستخدم FORCE ROW LEVEL SECURITY.

مراقبة تكشف المشكلة قبل العميل

• فحص توفر خارجي على مسار health يستعلم من قاعدة البيانات.

• معدل الأخطاء وزمن p95 لكل endpoint، حتى لا تختفي صفحة تقارير بطيئة خلف متوسط جيد.

• تنبيهات الموارد: قرص فوق 80%، وضغط على الذاكرة، ومهام نسخ احتياطي لم تكتمل.

• مؤشرات العمل: التسجيلات والمدفوعات في الساعة. الصفر المفاجئ غالبًا يعني خطوة معطلة وليس يومًا هادئًا.

مكان البيانات: مصر والاتحاد الأوروبي وعملاؤك

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

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

ضبط التكاليف في السنة الأولى

• فضّل السعر الشهري الثابت على التسعير حسب الطلبات أو الجيجابايت ما دامت الزيارات غير متوقعة.

• راجع حجم السيرفرات كل ربع سنة، وانتقل لباقة أعلى أو أقل حسب الذروة الفعلية.

• انتقل للدفع السنوي بعد استقرار الإعداد؛ في IM HOST يوفر ذلك 20%، والباقة تتجدد بنفس السعر.

• احذف ما لا تستخدمه: snapshots قديمة وسيرفرات تجارب منسية.

• احسب ساعات الفريق. الإعداد الأرخص الذي يأكل يومًا في الأسبوع هو الأغلى فعليًا.

ومن يتولى تحديثات النظام والترقيعات الأمنية والمراقبة قرار تكلفة أيضًا؛ راجع المقارنة بين VPS المُدار وغير المُدار.

خطة النمو خلال 12 شهرًا

1. الشهور 0 إلى 3: سيرفر إنتاج وسيرفر staging، ونسخ ليلية خارج السيرفر، ومراقبة توفر.

2. الشهور 3 إلى 6: تجارب استرجاع منتظمة، وتتبع الأخطاء، ودليل مكتوب لأكثر خمسة أعطال متوقعة.

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

4. بعد ذلك: سيرفر مخصص لقاعدة بيانات كبيرة أو orchestration عندما تتعدد الخدمات. الفروق مشروحة في السيرفر المخصص مقابل Cloud VPS.

ولو منتجك له تطبيق موبايل، فنفس الخطة تنطبق على الـ API الخاص به؛ راجع استضافة باك إند تطبيق الموبايل لملاحظات الحجم والسرعة الخاصة بالهواتف.

لماذا نهتم بهذه التفاصيل؟

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

أسئلة شائعة

هل تحتاج شركة SaaS ناشئة إلى Kubernetes؟

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

ما حجم أول سيرفر لمنتج SaaS؟

كقاعدة تقريبية، 8 GB RAM مع معالج مخصص تكفي لتطبيق ويب وAPI وworkers وقاعدة بيانات عند الإطلاق. راقب الذروة وكبّر قبل أن يستقر المعالج عند 70%.

هل أضع staging والإنتاج على نفس السيرفر؟

لا. اختبار خرج عن السيطرة أو migration فاشل يجب ألا يصل أثره للعملاء. سيرفر منفصل أصغر يكفي.

هل الاستضافة في مصر تجعلني ملتزمًا بقانون 151 لسنة 2020؟

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

عندما تكون جاهزًا لتجهيز الإنتاج والـ staging، فإن Cloud VPS بمعالج ورام وNVMe مخصصة يتيح لك البدء صغيرًا والانتقال بين الباقات مع النمو. ومهندسونا متاحون 24/7 لمساعدتك في تخطيط أول سيرفر.