تشغيل يمكن مراقبته واستعادته
لأن الواجهة قد تكون سليمة بينما MySQL أو S3 متوقف، افصل liveness عن readiness وراقب رحلة العمل لا الخادم فقط.
01
المراقبة
ابنِ لوحات وتنبيهات حول الإشارات الموجودة.
- /api/health: حياة عملية Node
- /api/ready: MySQL + S3 + latency
- معدلات 4xx/5xx وزمن endpoint
- test command waiting/running/failed age
- issues حسب queue/status
- system_logs المفتوحة وفشل webhook
02
نسخ واستعادة
MySQL وS3 يشكلان نسخة منطقية واحدة.
- نسخة MySQL يومية واختبار restore شهري
- S3 versioning أو snapshot وlifecycle policy
- تسجيل RPO/RTO مع مالك العمل
- استعادة قاعدة البيانات والbucket من نقطة متوافقة
- عدم حذف migration history
- اختبار روابط الأدلة بعد الاستعادة
03
إدارة الحوادث
أوقف الأثر أولاً ثم احتفظ بالدليل.
- حدد المشروع والبيئة والـcorrelation/run/issue ID
- عطّل scoped token المتأثر
- احفظ logs ووقت الحدث والنسخة المنشورة
- افصل فشل UI/API/MySQL/S3/AI/webhook
- استعد أو rollback عبر release معروف
- وثّق السبب والإجراء الوقائي
04
الصيانة الدورية
جدول بسيط يمنع تراكم المخاطر.
- أسبوعياً: فشل الاختبارات والويب هوك والسجلات المفتوحة
- شهرياً: restore drill وتدقيق التوكنات والاعتمادات
- لكل إصدار: migration dry run وsmoke/UAT
- ربع سنوي: dependency/image scan وaccess review
- عند تغيير SRS: reconciliation وimpact وإعادة validation