مراجعة أنظمة حيّة NYXLOR · CASE FILE 01
هندسة أنظمة · حوكمة رقمية · Trust & Safety

أُصمّم الأنظمة، قبل أن أُصمّم الشاشات.

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

ماذا يوثّق هذا الملف

دراسة حالة تقنية واحدة — منصّة NYXLOR — من منظور بنية الأنظمة، وهندسة البيانات، وهندسة الحماية. لا تسويق، أرقام وقرارات فعلية من الكود المصدري.

92
واجهة تشغيلية داخل لوحة التحكم، تتشارك نظام تصميم واحد
776
ملفاً تحت بيان تحقّق تكامل SHA-256 عند الإقلاع
20
وحدة حماية قابلة للتهيئة عبر 6 فئات تهديد
40+
دفعة إصدار، كل دفعة مربوطة بسكربت تحقّق آلي مستقل
2
لغتان كاملتا الاتجاه AR/RTL و EN/LTR — كما في هذه الصفحة الآن
ملف رقم 01 — دراسة حالة هندسية

NYXLOR — محرك حوكمة وحماية ذاتية لخوادم Discord

نظام واحد بواجهتي دخول: نواة بوت حيّة على بوابة Discord (Gateway)، ولوحة تحكم تشغيلية على الويب — يتشاركان طبقة بيانات وطبقة أمان واحدة. هذا التوثيق يشرح القرارات الهندسية، لا الميزات.

المحرك: Titan Engine v4.0
الدور: مهندس النظام الوحيد
الطبقات: Bot Core · Web Dashboard · Data Layer
§ 01

نظرة تنفيذية

NYXLOR منصّة حوكمة وحماية تعمل داخل مجتمعات Discord، تحوّل تدفقات أحداث خام من بوابة Discord إلى قرارات آلية، وإلى لوحة تحكم تشغيلية يديرها بشر تحت ضغط.

المشروع ليس «بوت أوامر». هو نظام داخلي بانضباط إصدار أقرب لما تراه في فِرق SaaS ممولة منه لمشروع فردي: بيان تكامل مشفّر لكل ملف حسّاس، نموذج صلاحيات ثلاثي المستويات، محرك حماية من 20 وحدة قابلة للتهيئة، ومسار ترحيل بيانات مخطَّط له بالكامل قبل أن تصبح الحاجة إليه ملحّة. بُني على مدى أكثر من 40 دفعة إصدار متتابعة، كل دفعة مرتبطة بسكربت تحقّق آلي مستقل يفشل بصوت مرتفع إن لم يتحقق شرطه.

يشرح هذا الملف القرارات وراء النظام — لماذا اختير تخزين JSON بدل قاعدة بيانات فورية، كيف يُميَّز الهجوم عن نشاط إداري طبيعي، ولماذا يمتلك النظام «خط رجعة» آمن دائماً — وليس فقط قائمة الميزات.

§ 02

المشكلة الهندسية

يمنح Discord صلاحية Administrator سلطة تدميرية كاملة — حذف أي قناة، حذف أي رتبة، طرد أو حظر أي عضو — ضمن نموذج صلاحيات مسطّح شبه ثنائي، وسجل تدقيق (Audit Log) بطيء وصعب الاستعلام كأثر جنائي وحيد. حين يُخترق حساب مشرف، أو يرتكب متطوع خطأً بشرياً في أمر جماعي، يمكن لخادم بأكمله أن يُدمَّر خلال ثوانٍ — و Discord نفسه لا يفرض أي تحديد معدّل على هذه الأفعال.

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

سطح الهجوم بلا نظام

  • توكن OAuth أو حساب إداري مخترَق يملك صلاحية تدميرية فورية
  • نموذج صلاحيات Discord الأصلي شبه ثنائي: إمّا صلاحية كاملة أو لا شيء
  • سجل التدقيق أرشيف بعد وقوع الحدث، لا طبقة منع استباقي
  • لا حد جماعي (Rate Limit) على حذف القنوات أو الرتب من منصّة Discord نفسها
  • خطأ بشري في أمر جماعي واحد قد لا يكون قابلاً للتراجع

استجابة NYXLOR

  • تقييم مخاطر سلوكي متدرّج (Behavioral Heat) يتحلّل مع الزمن بدل عدّاد صلب
  • صلاحيات ثلاثية المستوى + قائمة سماح على مستوى كل ميزة على حدة
  • مركز حماية من 20 وحدة، كل وحدة بعتبة ونافذة زمنية وعقوبة مستقلة
  • وضع ذعر تلقائي يرفع مستوى تحقق الخادم عند موجة انضمام مشبوهة
  • «حصانة المالك المطلقة» — قاعدة نظامية تمنع معاقبة المالك الحقيقي مهما كانت النتيجة
§ 03

بنية النظام — System Thinking

القرار المعماري المحوري: عملية واحدة، بواجهتي دخول، تتشاركان الذاكرة والقرص — لا خدمتان منفصلتان تتفاوضان على حالة مشتركة عبر الشبكة.

البوت (اتصال Discord Gateway) ولوحة التحكم (خادم Express) لا يتواصلان عبر واجهة برمجية داخلية؛ كلاهما يستدعي مباشرة نفس وحدات النطاق (Utils/*Center) ونفس طبقة بيانات JSON. هذا تفادٍ متعمَّد لمشكلة أنظمة موزّعة كلاسيكية — اتساق الحالة بين عمليتين — باختيار عدم إضافتها أصلاً قبل أن تفرضها الحاجة. الوصل بين الأجزاء يتم عبر ناقل أحداث داخلي (Event Bus) يُغلّف EventEmitter الأصلي في Node بثلاث إضافات: عزل الأعطال (فشل مستمع واحد لا يوقف البقية)، عدّادات تشغيل حيّة، وسجل تدقيق دائم لآخر 250 حدثاً على القرص.

تسلسل الإقلاع نفسه مصمَّم لِـ«الفشل المغلق»: تحميل البيئة → فحص تسرّب أسرار → تحقّق بيان التكامل → تحقّق الترخيص → تحقّق العبث (Tamper) — كل هذا قبل محاولة تسجيل الدخول إلى Discord. وفوق كل هذا، طبقة «Immortal Shield»: معالِجات استثناء عامة (unhandledRejection / uncaughtException) تضمن أن خللاً في رسالة واحدة أو استجابة API خارجية لن يُسقط نظام الحوكمة بأكمله لمجتمع حيّ.

Discord Gateway Bot Client · discord.js v14 31 event handlers · command loader Internal Event Bus Domain Modules Utils / *Center.js Security Core RBAC · CSRF · Protection Live Hub Authenticated WebSocket JSON Data Layer atomic writes · content hashed Express Dashboard · 92 views Passport OAuth2 · Discord identity Browser — Operator
شكل 01 عملية واحدة، واجهتا دخول (Gateway + HTTP)، طبقة بيانات وأمان مشتركة.
§ 04

هندسة البيانات — Data Engineering

أكثر من عشرين مخزن JSON مستقلاً، كل واحد مسؤول عن نطاق واحد فقط — لا ملف حالة ضخم واحد، ولا قاعدة بيانات فُرِضت قبل أن تُثبِت الحاجة نفسها.

كل كتابة تمرّ عبر نمط الكتابة الذرّية: تُكتب البيانات أولاً إلى ملف مؤقّت، ثم يُستبدَل الملف الهدف عبر rename على مستوى نظام الملفات. هذا يمنع أي قارئ من رؤية ملف نصف مكتوب حتى لو تعطّلت العملية أو انقطعت الكهرباء منتصف الكتابة — بديل بسيط وموثوق عن معاملات قاعدة بيانات كاملة، حين لا تكون تلك المعاملات مبرَّرة بعد.

فوق طبقة التخزين، يعمل كتالوج بيانات ذاتي الوصف: سكربت يمسح كل مخزن JSON، يستنتج أسماء الحقول وأنواعها وعدد السجلات من البيانات الحيّة نفسها — لا من وثيقة مخطط قد تنحرف عن الواقع — ويحسب بصمة SHA-256 لكل ملف لتتبّع أي تغيير. هذا فعلياً بناء information_schema خاص لمخازن JSON، لكنه مُولَّد لا مُدار يدوياً.

من ذلك الكتالوج، تُولَّد آلياً بنية جداول SQL بلهجتين — SQLite و PostgreSQL — ضمن خطة ترحيل من خمس مراحل، غير هدّامة بتصميمها: JSON يبقى مصدر الحقيقة حتى يؤكّد المشغّل الاتساق يدوياً، والتشغيل التجريبي (Dry-run) هو الافتراضي دائماً، والأسرار مُستبعدة صراحةً من أي ملف تصدير. لماذا لم يُستبدل JSON بقاعدة بيانات من اليوم الأول؟ لأن قابلية النشر على استضافة VPS محدودة الموارد بلا أي اعتمادية أصلية (Native Dependency) كانت قيداً حقيقياً على المنتج — فكان القرار الصحيح تصميم مخرج آمن وقابل للرجوع نحو قاعدة علائقية، لا تبنّيها قبل أوانها، ولا استبعادها للأبد.

data/*.json 20+ stores Schema Inference fields · rows · SHA-256 Data Catalog generated, not hand-kept SQLite DDL PostgreSQL DDL 5-phase rollout — dry-run default · JSON stays source-of-truth until confirmed
شكل 02 كتالوج مُستنتَج آلياً ← توليد DDL بلهجتين ← ترحيل تدريجي غير هدّام.
01
فهرسة مخازن JSON
مسح كامل لمجلد البيانات، استنتاج البنية من المحتوى الحي.
02
توليد بنية SQLite / PostgreSQL
DDL مولَّد آلياً من الكتالوج، بلهجتين متوازيتين.
03
استيراد تجريبي (Dry-run)
لا كتابة فعلية؛ التحقق من التحويل قبل أي التزام.
04
مهايئ قراءة مزدوج
تفعيل القراءة من القاعدة الجديدة يدوياً بعد تجهيز الاستضافة.
05
تحويل مسار الكتابة
التحويل النهائي يدوي، بعد نسخة احتياطية مؤكَّدة فقط.
§ 05

هندسة الحماية — Security Engineering

دفاع متعدد الطبقات: تحقّق عند الإقلاع، صلاحيات على مستوى كل ميزة، ومحرك كشف سلوكي يتحلّل مع الزمن بدل عدّاد صلب.

نموذج الصلاحيات ثلاثي المستوى (administrator < serverOwner < botOwner) يُكتشف تلقائياً من نمط المسار (Route Pattern) لكل طلب، مع قائمة سماح مستقلة لكل ميزة (أدوار/مستخدمون)، وتسجيل تدقيق لكل عملية كتابة حسّاسة ولكل محاولة مرفوضة. الوضع الافتراضي «آمن عند الإقلاع» — يعمل فوراً لمالك خادم جديد دون إجباره على تهيئة صلاحيات معقّدة أولاً — لكنه يسجّل كل قرار سماح، وهذا اختيار واعٍ بين الأمان الصارم وقابلية الاستخدام الأولى، وليس إغفالاً.

حماية CSRF مبنية على رمز مرتبط بالجلسة (32 بايت عشوائية)، يُرسَل عبر ترويسة مخصّصة، مع استثناء صريح للطرق الآمنة (GET/HEAD/OPTIONS) ولمسارات محدَّدة كنقاط استقبال Webhook وعودة OAuth.

مركز الحماية يضم 20 وحدة موزّعة على 6 فئات، كل وحدة قابلة للتهيئة بعتبة عدّية (Threshold) ونافذة زمنية (Window) ومستوى عقوبة مستقل من سلّم متدرّج من 9 درجات — لا خيار ثنائي بين «تجاهل» و«حظر»:

none warn delete_message remove_roles timeout kick ban lockdown freeze_admin
الوحدةالفئةالخطورة
Anti NukecoreCRITICAL
Anti RaidcoreHIGH
Anti Bot AddcoreHIGH
Anti Mass BanmoderationCRITICAL
Anti Mass KickmoderationHIGH
Anti Mass TimeoutmoderationMEDIUM
Anti Channel DeletestructureCRITICAL
Anti Channel CreatestructureMEDIUM
Anti Channel UpdatestructureHIGH
Webhook GuardstructureHIGH
Anti Role DeleterolesCRITICAL
Anti Role CreaterolesMEDIUM
Anti Role UpdaterolesHIGH
High Role GuardrolesCRITICAL
Invite GuardcontentMEDIUM
Link ControllercontentMEDIUM
Phishing ProtectioncontentCRITICAL
Spam ShieldcontentMEDIUM
Mention Raid GuardcontentHIGH
Owner Absolute ImmunitysovereignSYSTEM
Basic
أمان أساسي

افتراضي هادئ للخوادم الصغيرة: حماية Phishing والروابط والدعوات وحصانة المالك فقط، بعقوبة افتراضية Timeout.

Recommended
أمان موصى به

يضيف Anti-Raid و Anti-Nuke وحماية الرتب والقنوات والـ Webhook، بعقوبة افتراضية تجميد صلاحيات المشرف مؤقتاً.

Strict
أمان صارم

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

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

على مستوى الواجهة الأمامية، جرت هجرة منهجية لأكثر من 90 صفحة داخل لوحة التحكم من السكربتات والأنماط المضمَّنة (Inline) إلى ملفات خارجية قابلة للسماح بها (Allowlisting) — تمهيداً لسياسة Content-Security-Policy صارمة تقلّص مساحة أي ثغرة XSS محتملة. عمل غير لامع، لكنه العمل الذي يفرّق فعلياً بين مشروع فردي ومنتج جاهز للإنتاج. «صندوق الحماية» (Security Inbox) نفسه محكوم بحدود صريحة: مراجعة محلية فقط، بلا تسليم خارجي وبلا أي تعديل على Discord من داخل واجهة المراجعة، وإلغاء الحظر اليدوي قابل للتراجع دائماً — تصميم واعٍ بأن أداة الحماية نفسها يجب ألا تتحوّل إلى سطح هجوم أو التزام احتفاظ بيانات إضافي.

§ 06

الطبقة اللحظية — Real-Time Layer

محور الاتصال الحيّ (Live Hub) يستخدم مكتبة ws الخام بوضع noServer: true ومعالجة يدوية لحدث upgrade على خادم HTTP — بدل مكتبة جاهزة كـ Socket.IO. الفرق ليس تفضيلاً تقنياً فقط: هذا يسمح بالتحقق من رمز قصير الأجل، صادر من مسار موثَّق في لوحة التحكم، قبل اكتمال المصافحة نفسها — لا بعد الاتصال عبر رسالة أولى، وهو نمط أضعف أمنياً لأنه يمنح قناة حيّة لاتصال غير موثَّق ولو للحظة.

الاتصال يتضمّن نبضاً دورياً (Heartbeat) كل عشر ثوانٍ، وتحلّلاً برمجياً كاملاً حين لا تكون حزمة ws مثبَّتة أصلاً — تستمر لوحة التحكم في العمل بلا بطاقات حيّة بدل الانهيار. الجسر بين ناقل الأحداث الداخلي وهذا المحور يعني أن أي وحدة نطاق يمكنها بث تحديث حيّ بمجرد إطلاق حدث واحد، دون أن تعرف أي شيء عن بروتوكول WebSocket نفسه.

§ 07

سطح المنتج ونظام اللغتين

لوحة التحكم تضم 92 واجهة تشغيلية — من الإشراف والتذاكر والموسيقى، إلى الفوترة والاشتراكات، إلى أدوات المالك والموظفين — تتشارك جميعها نظام تصميم داخلي واحد (تخطيط، مكوّنات، حالات، طبقة JS أساسية) بدل الاعتماد على ذاكرة المطوّر لإعادة إنتاج نفس النمط 92 مرة.

النظام ثنائي اللغة بالكامل عربي/إنجليزي: قاموس ترجمة بالمفاتيح يتجاوز 1200 سطر، وتبديل تلقائي لخاصيتي dir و lang على عنصر المستند مع أصناف CSS منطقية. النمط نفسه — تبديل الاتجاه والخاصية على مستوى الجذر — هو ما يشغّل زر التبديل الذي استخدمته للتو في أعلى هذه الصفحة، مصغَّراً من قاموس بآلاف المفاتيح إلى ملف دراسة حالة واحد.

الأدوات والتقنيات المستخدمة فعلياً
discord.js v14 Node.js Express 5 Passport + Discord OAuth2 express-session Helmet express-rate-limit ws (WebSocket) DisTube + yt-dlp/Spotify/SoundCloud ffmpeg-static PM2 + Nginx GitHub Actions CI
§ 08

الموثوقية ومنهجية الإصدار

كل دفعة تطوير من أكثر من 40 دفعة مرتبطة بسكربت «تحقّق» مستقل يفحص أن التغيير حقّق ما ادّعاه فعلاً — أكثر من 150 سكربت تحقّق متراكم عبر الزمن، أقرب لاختبارات تعاقد (Contract Tests) مكتوبة يدوياً منها لأمل أن يعمل الكود. هذا مربوط بخط أنابيب CI فعلي عبر GitHub Actions: مسار «Production Verify» يعمل عند كل دفع إلى الفرع الرئيسي، ومسار «Security Check» يعمل عند كل Push و Pull Request، بما في ذلك تثبيت الاعتماديات بخيار --ignore-scripts — تحديداً لمنع أي سكربت ما بعد تثبيت خبيث من التنفيذ التلقائي ضمن سلسلة التوريد.

معالِجات الاستثناء العامة تبقي النظام يعمل عند عطل غير متوقّع بدل الانهيار الكامل، وملفات نشر PM2 و Nginx مع قائمة تحقّق تشغيلية صريحة (VPS Operator Checklist) تعني أن النشر ليس معرفة ضمنية حبيسة في رأس شخص واحد.

§ 09

خلاصة هندسية — وما كنت سأغيّره

الكتابة الهندسية الصادقة تسمّي المقايضات، لا تخفيها. هذه ثلاثة قرارات كنت سأعيد النظر فيها اليوم:

JSON كان القرار الصحيح للبداية — لا للنهاية

عدد المخازن اليوم يعني أن خطة الترحيل في القسم 04 لم تعد رفاهية اختيارية، بل الخطوة التالية الفعلية، لا نظرية جاهزة على الرف.

«الآمن عند الإقلاع» سخي أكثر من اللازم بصمت

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

ملكية فردية لأكثر من 150 سكربت تحقّق مخاطرة حقيقية

عامل الحافلة (Bus Factor) هنا يساوي واحداً. توثيق كل «دفعة» بتقرير مستقل كان محاولة تخفيف جزئية، لكنه ليس بديلاً عن مراجعة خارجية حقيقية.

مهتم بمناقشة هذا النظام بالتفصيل؟

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