الخدمات التقنية
السحابة والبنية التحتية
هذه هي الأرض التي يقف عليها المنتج. نصمّم البيئة، ونؤتمت طريقة وصول الشيفرة إليها، ونبقي النظام العامل محدَّثاً ومنسوخاً احتياطياً ومراقَباً. وكل ذلك يُهيّأ داخل حساباتك أنت، فتصلك الفواتير مباشرة ولا يبقى شيء محبوساً عندنا. وسنقول لك بوضوح أين تنتهي سيطرتنا: شبكة مزوّد الاستضافة ليست ملكنا، وكذلك كلمة مرور يسلّمها موظف لغيره.
المعمارية السحابية
مركز البيانات الافتراضي الذي يعيش فيه تطبيقك، بمقاس الحركة التي لديك فعلاً، وقادر على استيعاب الذُّرى التي تستطيع تسميتها. أكثر الفواتير السحابية المرتفعة سببها أن أحداً لم يختر شكل البيئة: تُضاف الخوادم ولا تُزال. لذلك نصمّم قبل أن نجهّز، على AWS أو Azure أو Google Cloud، ويكون الاختيار بحسب ما تشغّله لا بحسب ما نفضّله نحن.
ما تحصل عليه
- بيئة مهيّأة على AWS أو Azure أو Google Cloud، داخل حسابك أنت
- موارد حوسبة بمقاس الأحمال التي تصفها: خوادم افتراضية أو Kubernetes، ووظائف بلا خوادم (serverless) حيث تناسب فعلاً
- قواعد بيانات مُدارة بنسخ احتياطي آلي، ومسار استرجاع مكتوب لا شفهي
- شبكة خاصة ومجموعات أمان وقواعد وصول، فلا يبقى مكشوفاً إلا ما يجب أن يكون كذلك
- وثيقة معمارية: ما الذي يعمل وأين، وما الذي يرفع الفاتورة الشهرية، وأي جزء سينحني أول عند الضغط
ما نحتاجه منك
- الحركة المتوقعة وحجم البيانات وأي ذروة يمكنك توقّعها: إطلاق، أو حملة، أو موسم
- حسابك السحابي الخاص، أو قرار بفتح واحد، لأن الفاتورة تخصّك
- أي متطلب لموقع تخزين البيانات أو للامتثال، قبل التصميم لا بعده
- صلاحية الوصول إلى البيئة الحالية وإعداداتها إن كان العمل نقلاً
أين تتوقف الخدمة
- التكاليف السحابية يحاسبك عليها المزوّد على حسابك أنت. نحن نحدّد المقاس ونهيّئ، ولا نعيد بيع السعة ولا نضيف عليها هامشاً
- نستطيع إزالة الهدر، لكن لا أحد يستطيع أن يعدك برقم شهري؛ استهلاكك هو ما يحدّد الفاتورة
- نقل نظام إنتاج قائم يُسعَّر على حدة، منفصلاً عن تصميم البيئة
- بيئة مهيّأة لا يراقبها أحد ليست بنية تحتية مُدارة. تشغيلها يحتاج خطة رعاية أو ارتباط DevOps
- تراخيص الطرف الثالث ورسوم الخدمات المُدارة وكلفة نقل البيانات تكاليف تخصّك
أتمتة التطوير والإصدار (DevOps و CI/CD)
خط تجميع آلي لشيفرتك: كل تعديل يُبنى ويُختبر ويُنشر بالطريقة نفسها، عبر نص برمجي لا عبر من يتذكّر الخطوات. والهدف ليس السرعة لذاتها. الفرق التي تستطيع النشر خلال دقائق تُصدر تغييرات أصغر، والتغيير الصغير هو الذي يمكن التراجع عنه. لذلك يُبنى مسار التراجع ويُختبر قبل أول إصدار، لا يُرتجل أثناء أول عُطل.
ما تحصل عليه
- خطوط نشر آلية على GitHub Actions أو GitLab CI تبني وتختبر وتنشر مع كل تعديل
- بيئات منفصلة للتطوير والاختبار والإنتاج، فلا يُختبر شيء على النظام الحي
- بنية تحتية ككود عبر Terraform أو CloudFormation، فتُعاد البيئة من ملف لا من الذاكرة
- إعداد حاويات (Docker) ليتصرّف التطبيق بالطريقة نفسها على أي جهاز يعمل عليه
- مسار تراجع مكتوب ومختبَر، ونشر بلا إيقاف الموقع حيث تسمح المعمارية بذلك
- توثيق لخط النشر وللأسرار التي يحتاجها ولمن يحقّ له الإصدار
ما نحتاجه منك
- صلاحية الوصول إلى المستودع، ونموذج للفروع البرمجية، أو قرار باعتماد واحد
- بيانات الدخول إلى الحساب السحابي أو الاستضافة التي سينشر إليها الخط
- قرار بمن يعتمد الإصدار إلى الإنتاج
- خطوات البناء والنشر الحالية، بما فيها الخطوات غير الموثّقة التي ينفّذها أحدهم يدوياً
أين تتوقف الخدمة
- باقة بناء النسخة الأولى تتضمّن خط نشر أساسياً للمنتج الذي نسلّمه؛ أما ارتباط DevOps الكامل فيُسعَّر على حدة
- إعادة كتابة تطبيق ليصبح قابلاً للنشر الآلي — تفكيك نظام متراص، أو إخراج الإعدادات المكتوبة داخل الشيفرة — مشروع قائم بذاته لا مهمة ضمن خط النشر
- تشغيل الإصدارات يوماً بيوم يبقى عند مالك الشيفرة، ما لم تغطّه خطة شهرية
- دقائق التشغيل على منصات CI، ومساحة سجل الحاويات، وتراخيص الأدوات، تُحسب على حسابك أنت
- خطوط النشر تتقادم. وحين تتغيّر الأدوات أو المنصة ولا تغطّي ذلك خطة، لا أحد يبقيها عاملة
الاستضافة والأمان
ندير النطاق والخوادم والبوابات: شهادة SSL، وسجلات DNS، وقواعد جدار الحماية، وتصفية هجمات الحرمان من الخدمة، والنسخ الاحتياطي، والتحديثات وفق جدول لا وفق التذكّر. أغلب المواقع التي تُخترق لم تكن مستهدفة أصلاً؛ كانت تشغّل إضافة نُشرت ثغرتها قبل ثمانية أشهر. التحديث بإيقاع منتظم هو كل الحيلة، وهو عمل ممل لا بد أن يجري.
ما تحصل عليه
- استضافة مُدارة مع إعداد SSL و DNS، وعنوان https يعمل
- حماية من هجمات الحرمان من الخدمة وقواعد جدار حماية توقف الحركة الآلية قبل أن تصل إلى التطبيق
- نسخ احتياطي مجدول بمدد حفظ تختلف بالدرجة — أسبوعي وثلاثون يوماً في «انطلاق»، ويومي وتسعون يوماً في «نمو»، ويومي وعند الطلب مع حفظ سنة كاملة في «توسّع» — واسترجاع عند الطلب
- تحديث النواة والإضافات والاعتماديات: شهرياً في «انطلاق»، وأسبوعياً في «نمو»، وأسبوعياً مع ترقيعات أمنية طارئة في «توسّع»
- بيئة اختبار من درجة «نمو» فصاعداً، فيُجرَّب التغيير قبل أن يمسّ الموقع الحي
- مراقبة التوفّر: فحص كل خمس دقائق مع تنبيه بالبريد في «انطلاق»، وكل دقيقة في «نمو»، وكل دقيقة مع تنبيه آلي على مدار الساعة وتصعيد في «توسّع»
- فحص البرمجيات الخبيثة في كل الدرجات، مع التنظيف والاسترجاع من «نمو»، ومراجعة تحصين مرتين سنوياً في «توسّع»
- تقرير صحّة شهري
ما نحتاجه منك
- صلاحية الوصول إلى مسجّل النطاق وإلى سجلات DNS
- صلاحية إدارة على الاستضافة الحالية وعلى الموقع أو التطبيق نفسه
- قائمة متّفق عليها بكل من يملك صلاحيات إدارية غيرنا
- جهة اتصال واحدة تعتمد التغيير العاجل دون انتظار اجتماع
أين تتوقف الخدمة
- التوفّر يعتمد على مزوّد الاستضافة نفسه. نحن نراقب ونبلّغ ونصعّد، ولا نتحكّم بشبكته. درجتا «انطلاق» و«نمو» بأفضل جهد ممكن، ودرجة «توسّع» تحمل هدفاً شهرياً قدره 99.9% نرفع عنه تقريراً — هدف لا ضمان
- التنبيه على مدار الساعة في «توسّع» مراقبة آلية مع تصعيد. أما مهل الرد البشري فمحسوبة بأيام العمل: اليوم نفسه في «توسّع»
- نؤمّن البنية التحتية. ولا نستطيع تأمين كلمة مرور يسلّمها موظف لغيره — الهندسة الاجتماعية خارج ما يبلغه أي جدار حماية
- الاسترجاع بعد تغييرات أجراها شخص آخر يملك صلاحية إدارية غير مشمول بساعات الخطة
- لا نتحمّل مسؤولية بنية تحتية لم نبنِها أو لا نملك الوصول إليها
- موارد الاستضافة الزائدة عن حصة خطتك، ورسوم النطاق، وتراخيص الطرف الثالث، تُحسب على حسابك أنت
- الصفحات الجديدة والميزات الجديدة وإعادة التصميم ليست صيانة، وتُسعَّر على حدة
أين تُشترى هذه الخدمات
الاستضافة والأمان هما خطة الرعاية بدرجاتها الثلاث، تُضاف في نهاية كل بناء وتُباع وحدها لموقع قائم. أما المعمارية السحابية وارتباطات DevOps الكاملة فتندرج تحت الحلول المخصّصة، وتُسعَّر بعد مرحلة تحديد نطاق مدفوعة: تشخيص الأنظمة والأتمتة لمشكلة تشغيلية، أو مرحلة الاستكشاف لمنتج. وباقة بناء النسخة الأولى تتضمّن أصلاً خط نشر أساسياً لما نسلّمه. وكل بناء ينتهي بضمان إصلاح الأخطاء لثلاثين يوماً على النطاق المسلَّم، ثم تتولّى خطة الرعاية بعده.