وعد أتمتة الاستضافة بسيط: يدفع العميل، ويصبح حسابه موجودًا بعد ثوانٍ، دون تدخل بشري. الجزء الصعب هو كل ما يمكن أن يسوء في تلك الثواني: لوحة التحكم بطيئة، اسم المستخدم محجوز، الباقة غير موجودة على ذلك الخادم، رمز API انتهى الأسبوع الماضي.
الخطوات الخمس
- يختار العميل منتجًا ويكمل الدفع؛ يُنشأ الطلب ببنوده.
- تُنشأ الفاتورة ويُرسل رابط الدفع.
- يؤكد Stripe أو PayPal الدفع عبر Webhook موقّع، وتُعلَّم الفاتورة كمدفوعة.
- تُدفع مهمة التفعيل إلى الطابور الحرج مع خادم المنتج وباقته ونطاقه.
- ينشئ المشغّل الحساب على cPanel/WHM أو Plesk، وتصبح الخدمة نشطة، ويصل العميل بريد ببياناته.
لماذا طابور وليس نداءً مباشرًا
نداء لوحة التحكم قد يستغرق عشر ثوانٍ أو ينتهي بمهلة. لو انتظره طلب الدفع، لرأى عملاؤك دوائر التحميل ولتجاوزت نقطة الـ Webhook مهلة بوابة الدفع. الطابور يأخذ المهمة فورًا، ويؤكد الـ Webhook، ويترك الجزء البطيء لعامل الطابور. حين تفشل اللوحة، تعيد المهمة المحاولة بتباعد متزايد، وبعد آخر محاولة تستقر في حالة فشل تراها وتعيد تشغيلها.
الإيقاف والإنهاء بالمسار نفسه
الفواتير المتأخرة تطلق مهام إيقاف بالجدول الذي تحدده (التحصيل)، ودفع فاتورة متأخرة يطلق إعادة التفعيل، وطلب الإلغاء أو التأخر الطويل يطلق الإنهاء. كل منها مهمة بسطر في السجل، فالعميل الذي يقول "أوقفتموني بلا سبب" يصبح بحثًا لا تخمينًا.
ما الذي تراقبه
- عمق الطابور: تراكم متزايد يعني أن عاملًا توقف أو خادمًا بطيء.
- المهام الفاشلة حسب الخادم: خادم واحد يفشل بينما يعمل الباقون يعني غالبًا رمزًا أو اسم باقة.
- زمن التفعيل: القفزة المفاجئة تسبق عادةً انقطاع اللوحة.
- فشل توقيعات الـ Webhook: القليل منها بوتات؛ الكثير يعني سرًّا مُبدَّلًا.
تشغّل Hostinvo هذا التدفق بمشغّلات أصلية لـ cPanel/WHM وPlesk، وطابور Redis بأربعة مستويات، وإعادة محاولة بتباعد، وسجل تفعيل لكل خدمة. وكل إجراء في دورة حياة الخدمة هو زر في لوحة الإدارة أيضًا، فالمسار اليدوي موجود دائمًا حين تريده.