دراسة حالة 02 · منصة محاكاة التصيّد · 2024 – حتى الآن
عامان لتوحيد محركين غير متوافقين لمحاكاة التصيّد في منصة واحدة يستطيع مدير غير تقني تشغيلها
بنقرة واحدة، ينطلق تمرين واقعي لمحاكاة التصيّد، وتظهر جميع نتائجه في لوحة تحكم واحدة.
بقلم Hesham Ghoniem، المهندس الرئيسي ·
- القطاع
- محاكاة التصيّد لفرق الأمن ومزوّدي الخدمات المُدارة (MSPs) والموزّعين
- التعاون
- مستمر منذ 2024 · التصميم والتطوير والصيانة
- نطاق العمل
- منصة SaaS متكاملة متعددة العملاء · تكامل مع محركين · فوترة
- التقنيات
- Laravel 11
- Vue 3
- Inertia
- Tailwind
- MySQL
- Redis
- Horizon
- 2 — محركان مستقلان لمحاكاة التصيّد ضمن سير عمل واحد
- 7 — خدمات خارجية تعمل فعليًا ربطناها بالمنصة
- 305 — تغييرًا في الكود دمجناه على مدار نحو عامين
- 85 — تغييرًا في قاعدة البيانات نشرناه تدريجيًا
- ~31,800 — سطر من كود التطبيق
نظرة عامة
تبدأ اختراقات كثيرة بنقرة واحدة. بنينا منصة للتدرّب على مواجهتها.
تبدأ اختراقات أمنية كثيرة حين ينقر موظف على رسالة بريد مقنعة. احتاج عميلنا إلى منصة تحاكي هذه الهجمات بأمان، لتعرف الشركة أيّ موظفيها قد يقع في الفخ، وتعالج نقاط الضعف هذه قبل أن يكتشفها مهاجم حقيقي.
صمّمت CompertMe المنصة وطوّرتها. ومنذ 2024، وسّعنا تطبيق ويب واحدًا ليصبح منصة يخطّط فيها فريق الأمن لتمرين واقعي لمحاكاة التصيّد، ويرسله إلى موظفي الشركة، ويتابع لحظة بلحظة من يكتشف الفخ ومن يقع فيه. ثم تحوّل المنصة النتائج إلى تقرير يساعد المدير على اتخاذ إجراء.
تتميّز المنصة بطريقة عملها خلف الواجهة. فهي تشغّل في الوقت نفسه محركين مختلفين تمامًا لمحاكاة التصيّد: محركًا قياسيًا لتمارين البريد المعتادة، وآخر متقدمًا لأساليب أحدث، مثل صفحات تسجيل الدخول المزيّفة والاحتيال برموز QR. وتجمعهما خلف شاشة واحدة بسيطة تخفي هذا الاختلاف عن المستخدم.
تطوّر المنتج على 3 مراحل: أداة لشركة واحدة، ثم منتج متكامل متعدد العملاء يعيد مزوّدو خدمات تقنية المعلومات بيعه لعملائهم مع فصل بيانات كل عميل، ثم المرحلة الأصعب: تشغيل المحرك الثاني الذي صَعُب دمجه. استغرق هذا الجزء أشهرًا، وهو محور هذه الدراسة. وإلى جانبه، واجهنا مشكلات أقل ظهورًا كادت تضاهيه صعوبة: أن يرى المدير بالضبط ما سيراه موظفوه، وأن يستورد صفحات قائمة إلى المحرّر دون إفسادها.
التحديات
عشرة تحديات، أصعبها محرك بلا واجهة اتصال.
محرك قياسي صُمّم لفريق واحد، واحتجنا إلى تشغيله لفرق كثيرة
المحرك المستخدم للتمارين المعتادة برنامج مفتوح المصدر يحظى بالتقدير، لكنه صُمّم لفريق أمن واحد يختبر نفسه. احتجنا إلى تشغيل تمارين لشركات مستقلة كثيرة في الوقت نفسه، دون تداخل بينها. واستغرق حل مشكلتين وقتًا أطول من غيرهما.
- نطاق أسماء واحد مشترك. يفترض المحرك أن لكل قائمة مستلمين ولكل مُرسِل اسمًا فريدًا. فإذا سمّى عميلان مجموعة «فريق المبيعات»، اعتبرها المحرك مجموعة واحدة، وقد تحلّ بيانات تمرين شركة محلّ بيانات تمرين الأخرى. أضفنا الفصل بين العملاء في البنية الداخلية، وظللنا نعالج آخر حالات تعارض الأسماء حتى 2026.
- المناطق الزمنية. كانت التمارين المجدولة في 9:00 صباحًا تُرسَل في ساعة أخرى، لاختلاف التعامل مع المناطق الزمنية بين المحرك ولوحة التحكم. أجرينا سلسلة إصلاحات حتى أواخر 2025، ثم إصلاحًا إضافيًا في 2026، لضبط مواعيد الإرسال لكل عميل أينما كان في العالم. لا يلاحظ أحد هذا الخطأ حتى تنطلق حملة في 3 صباحًا.
أصبح المحرك الواحد محركين، وتضاعف معه معظم ما يدعمه
خلال أول 14 شهرًا من عمر المنصة، لم يكن فيها سوى المحرك القياسي. لذلك صمّمنا كل شاشة وخدمة وعمود في قاعدة البيانات على أساس وجود محرك واحد. ثم أضفنا المحرك المتقدم. كان محركًا ثانيًا مستقلًا، لا مجرد إضافة، واحتاج إلى مجموعة مستلمين وملف إعدادات إرسال وحملة وقالب بريد تخصّه، مع إبقاء كل منها متزامنًا مع نظيره في المحرك الأصلي.
في أوائل 2026، نسخنا خدمات الحملات وقوالب البريد من المحرك القياسي كما هي، ثم طوّرنا النسخ لتلائم البنية المختلفة للمحرك المتقدم. وأصبح لـ4 خدمات في المحرك القياسي نظائر في المحرك المتقدم. وبعد عام من إنشاء جداول كانت لا تحتفظ إلا بمعرّف محرك واحد منذ الأسابيع الأولى للمنتج، أضفنا إليها أعمدة جديدة. ثم استكملنا بيانات كل سجل قائم، حتى لا تبدو حسابات العملاء الذين سجّلوا قبل إضافة المحرك المتقدم معطّلة عند تطبيق نموذج البيانات الجديد.
محرك متقدم بقدرات واسعة، بلا واجهة اتصال
يحاكي المحرك المتقدم هجمات لا تدعمها الأدوات الأساسية. ورغم قدراته الواسعة، لم يُصمّم أحد جزأيه ليتحكم فيه برنامج آخر. فجزء الحملات يعمل بطريقة تشبه المحرك القياسي ويسهل الاتصال به. أما الجزء الذي يحاكي صفحة تسجيل الدخول، فيتطلب شخصًا يُدخل الأوامر في الطرفية. لم تكن فيه نقطة اتصال للوحة التحكم. وأصبحت هذه أصعب مشكلة في المشروع، ونفصّلها في الأقسام التالية.
محركان يجب أن تبقى بياناتهما متزامنة
ينطلق التمرين عبر أحد المحركين، ولذلك يجب أن توجد مجموعات المستلمين ونطاقات الإرسال الخاصة بالعميل في كليهما، وأن تبقى متزامنة. يتعامل المحركان مع المستلمين والمُرسِلين والقوالب والحملات بطرق متقاربة جدًا. لكن المحرك الثاني يحتاج أيضًا إلى خطوة إعداد إضافية لا يحتاج إليها الأول، وإلى نوع من التهيئة لا يمكن إنجازه بطلب برمجي عادي. كان علينا ضمان وصول كل عملية حفظ إلى المحركين بصورة صحيحة، مع إبقاء بيانات العميل دون تغيير إذا أخفق أحدهما.
معاينة يمكن الاعتماد عليها
قبل إرسال تمرين إلى 2,000 شخص، يحتاج المدير إلى رؤية ما سيظهر لهم. لكن رسالة البريد تختلف عن صفحة الويب: تتجاهل برامج البريد بعض التنسيقات، وتحجب الصور، وتحذف العناصر المتقدمة، فلا يكفي نموذج بصري تقريبي. احتجنا إلى لقطة فعلية يلتقطها متصفح حقيقي في الخلفية، على خوادم يجب تثبيت المتصفح في كل منها وضبط الوصول إليه. واستقرّ الحل بعد 3 أجيال من التطوير.
استيراد أي صفحة بأكثر من طريقة
لا يبدأ أحد إعداد سيناريو تصيّد من صفحة فارغة. لذا تتيح المنصة استيراد محتوى قائم: رابط لصفحة هبوط، أو كود HTML يلصقه المستخدم لإنشاء رسالة بريد. لكن طرق بناء الصفحات كثيرة؛ بعضها يصل مكتملًا، وبعضها يصل فارغًا حتى يبنيه المتصفح، ومعظمها يوزّع التنسيقات والصور على ملفات أخرى. لذلك لم يكن طلب جلب واحد كافيًا. تطوّرت أداة الاستيراد لتجرّب حتى 3 طرق متتابعة، ثم تنظّف المحتوى، وأصبحت أكبر جزء في طبقة الخدمات.
منصة واحدة لشركات كثيرة، بعلامات الموزّعين التجارية
كان على النظام نفسه أن يُباع بباقات مختلفة في حدودها وأسعارها، وأن يظهر بالعلامة التجارية لكل موزّع، وأن يفصل قوائم الموظفين والنتائج الخاصة بكل عميل عن سائر العملاء. تطلّب ذلك هيكلًا من 3 مستويات: مالك لوحة التحكم، ثم الموزّع، ثم العميل النهائي.
فوترة عادلة وتقارير يعتمد عليها المدير
أراد العملاء الدفع مقابل استخدامهم فقط، دون فواتير مفاجئة، واحتاج الموزّعون إلى تخصيص أرصدة استخدام لعملائهم، وكل ذلك بالخدمة الذاتية. كما يحتاج مدير الأمن إلى عرض استجابة الموظفين للتصيّد على مجلس الإدارة، ما يتطلب تحويل بيانات التتبّع الخام تلقائيًا إلى تقارير واضحة تحمل العلامة التجارية للشركة.
بناء خدمة على الخادم لم تكن موجودة في المحرك المتقدم
تشغيل أداة طرفية بالطريقة التي يستخدمها بها الإنسان هو الجانب الظاهر من المشكلة. لكنه يتطلب أولًا برنامجًا مخصصًا على خادم المحرك المتقدم نفسه ينفّذ هذا التحكم. وكان علينا بناؤه من الصفر، لأن الجزء المسؤول عن صفحة تسجيل الدخول لا يوفّر أي وسيلة لاتصال البرامج الأخرى به.
مستوى الشركاء: تصميم اكتمل مع الاستخدام
إعادة البيع ليست مجرد خيار نفعّله. فالانتقال من أداة لشركة واحدة إلى مستوى يستطيع فيه الموزّع إدارة عملائه احتاج إلى سلسلة متواصلة من الإصدارات. ولم نكتشف بعض النواقص إلا حين بدأ شريك فعلي استخدامه.
المحرك المتقدم · بلا واجهة اتصال
المحرك الذي لا يوفّر واجهة اتصال
يتيح المحرك المتقدم للمنصة محاكاة هجمات تخدع حتى الموظفين الحذرين: صفحات تسجيل دخول مزيّفة مقنعة، وأساليب احتيال برموز QR تنتشر الآن عبر البريد. احتاج العميل إلى هذه القدرات، لكن التخطيط وحده لم يكن ليحلّ مشكلة أساسية: أحد جزأي المحرك لا يوفّر أي وسيلة لاتصال البرامج الأخرى به.
يجمع المحرك المتقدم في الواقع أداتين. يتولى جزء الحملات المستلمين والمُرسِلين والقوالب والإرسال، ويتعامل معها بطريقة قريبة جدًا من المحرك القياسي، ما أتاح إعادة استخدام قدر كبير من الكود. أما الجزء الآخر فيحاكي صفحة تسجيل الدخول.
توفّر كل خدمة أخرى نربطها بالمنصة نقطة اتصال موثّقة، صُمّمت ليتواصل برنامج مع آخر. أما هذا الجزء فلا يوفّرها. فقد صُمّم ليشغّله شخص مباشرةً، بإدخال الأوامر في نافذة الطرفية وقراءة الردود على الشاشة. لذلك لم تجد لوحة التحكم واجهة تتصل بها.
بنينا وسيلة الاتصال بأنفسنا.
بنينا على خادم المحرك نفسه خدمة مخصصة تشغّل الأداة بالطريقة التي يستخدمها بها الإنسان. تُدخل الأوامر الصحيحة في الجلسة الجارية، وتقرأ الردود من الشاشة، ثم تعيد إلى لوحة التحكم إجابة واضحة ومنظّمة. أصبح برنامجنا ينفّذ خطوات التشغيل اليدوي بسرعة الآلة وبالطريقة نفسها في كل مرة.
ثم اكتشفنا فجوة بين خطة التكامل وما يوفّره الخادم.
احتاج التكامل، قبل أي شيء، إلى عملية «إعداد الحملة»: إنشاء المسار الذي يشير إليه رمز QR وإرجاعه إلى لوحة التحكم. لكن الخادم لم يكن يوفّر هذه العملية بعد. لذلك كانت تمارين QR الأولى تُنتج رموزًا لا تقود إلى وجهة عند مسحها، لأن الحملات كانت تُنشأ دون رابط الوجهة. كتبنا العملية الناقصة ورتّبنا خطوات لوحة التحكم ترتيبًا صحيحًا: إنشاء المسار أولًا، ثم إنشاء الحملة وربطها به.
والمحرك لا يحتفظ بإعداداته أيضًا.
يحتاج كل تغيير إلى إعادة تحميل كاملة حتى يسري. واكتشفنا تباعًا قواعد تسمية بسيطة كانت تعطل العمل دون إظهار أي خطأ، مثل وجود مسافة في اسم قالب، أو استخدام شرطة في موضع تستخدم فيه لوحة التحكم شرطة سفلية. استغرق الوصول إلى تشغيل مستقر لكل هذه الأجزاء جهدًا مركّزًا امتد 3 أشهر، من بدء التكامل في أواخر 2025 إلى تشغيل تمارين QR بصورة مستقرة في أوائل 2026.
خط أفقي بثلاث علامات: بدء التكامل في أواخر 2025، ثم كتابة العملية الناقصة، ثم استقرار تمارين QR في أوائل 2026. يظهر المقطع السابق للعملية الناقصة باللون الأحمر، وعليه عبارة «رموز QR الأولى لا تقود إلى وجهة»، ويظهر على المقطع التالي «المسار أولًا، ثم الحملة».
ينقر العميل على «إطلاق». وفي الخلفية، تشغّل لوحة التحكم أداة لم تُصمّم ليتحكم فيها برنامج، دون أن يرى العميل أيًا من ذلك.
على الخادم · بنيناها من الصفر
بناء واجهة API لم تكن موجودة
يوضح القسم السابق جانب المشكلة الذي يحاكي عمل الإنسان: تشغيل أداة طرفية بإدخال الأوامر في جلستها الجارية. ولم يصبح ذلك ممكنًا إلا بعد أن بنينا أولًا برنامجًا على خادم المحرك المتقدم نفسه يتولى إدخال هذه الأوامر.
كان جزء الحملات يملك واجهة API بالفعل. أما هذا الجزء فلم يوفّر أي نقطة نبدأ منها، ولا واجهة API رسمية أو غير رسمية، لأنه صُمّم ليتحكم فيه شخص فقط. لذلك بنينا خدمة مخصصة من ملف فارغ على الخادم نفسه، بمهمة واحدة: توفير واجهة ترسل إليها لوحة التحكم الأوامر وتطلب منها المعلومات.
ترسل لوحة التحكم الأوامر إلى خدمة تحكم بنيناها، فتشغّل الخدمة المحرك المتقدم بالطريقة التي يستخدمها بها الإنسان. وتحتفظ الخدمة بملف يحفظ الحالة حتى بعد إعادة التشغيل. لم يكن أي جزء من هذه الخدمة موجودًا قبل المشروع.
أكثر من عشرين عملية، لم تكن أيّ منها موجودة عند البدء.
غطّت الخدمة عند اكتمالها أكثر من 20 عملية. فهي تتحقق من أن المحرك يعمل وتقرأ حالته وإعداداته. وتعرض قوالب صفحات تسجيل الدخول وتقرأ كل قالب وتنشئه وتعدّله وتنسخه وتفعّله وتوقفه وتحذفه. كما تُعدّ مسار حملة كاملة باستدعاء واحد، وتعرض الروابط الناتجة عن هذه المسارات وتحذفها. وتعيد تشغيل المحرك بصورة سليمة، وترسل إليه أوامر مباشرة، وتحفظ حالته وتستعيدها. أضفنا كل عملية لأن لوحة التحكم احتاجت إليها ولم تتوافر طريقة أخرى لتنفيذها.
المحرك لا يحفظ حالته بنفسه.
يحتاج المحرك إلى إعادة التشغيل كثيرًا، عند كل تغيير في قالب، ويفقد حينها جميع الإعدادات التي تلقاها. لذلك تحتفظ الخدمة بملف صغير يسجّل ما يجب أن يبقى مفعّلًا: القوالب، والنطاق المرتبط بكل منها، ووجهة إعادة التوجيه. وبعد كل إعادة تشغيل، تقرأ الملف وتعيد المحرك إلى حالته السابقة. ومن دون هذا الملف، كانت إعادة تشغيل روتينية ستمحو إعدادات جميع العملاء.
أدوات المحتوى · المعاينة
معاينة تطابق ما يراه المستلم
قبل أن يرسل مدير الأمن تمرينًا إلى 2,000 زميل، يحتاج إلى رؤية ما سيظهر لهم بالضبط. فالرسالة التي تصل بتنسيق معطّل أو شعار مفقود أو زر لا يقود إلى أي وجهة لا تختبر قدرة الموظف على اكتشاف الاحتيال. ستبدو ببساطة رسالة أُعدّت بصورة خاطئة، ولن تكون لنتيجة الاختبار دلالة.
تبدو ميزة صغيرة، لكننا احتجنا إلى 3 محاولات لتنفيذها.
ثلاث نوافذ متصفح من اليسار إلى اليمين: معاينة مباشرة في نافذة منبثقة أواخر 2024، ثم معاينة داخل صفحة الحملة أوائل 2025، وكلتاهما بالرمادي للدلالة على استبدالهما، ثم صورة محفوظة مرفقة بكل قالب في منتصف 2025، مميّزة بوصفها الحل الحالي.
في كل مرة، كان السؤال نفسه: كيف نعرض ما سيظهر فعلًا، بسرعة، لمستخدمين كثيرين في الوقت نفسه؟
رسالة البريد تختلف عن صفحة الويب.
يعرض المتصفح الحديث صفحة الويب ويتعامل بمرونة مع معظم تفاصيلها. أما برامج البريد فأقل مرونة بكثير: تتجاهل معظم تنسيقات المصمّم، وتحذف العناصر المتقدمة، وترفض غالبًا تحميل الصور من مصادر خارجية. وقد يصل قالب يبدو متقنًا داخل المحرّر في صورة رسالة مختلفة تمامًا. لذلك لم يكن التقدير التقريبي كافيًا.
عمودان متجاوران يقارنان ما يعرضه المحرّر، بتنسيقات كاملة وصور ظاهرة وتخطيط سليم، بما يعرضه البريد الوارد، حيث يتجاهل معظم التنسيقات ويحجب الصور ويحذف العناصر المتقدمة.
لقطة الشاشة هي المعاينة الوحيدة التي يمكن الوثوق بها.
تشغّل لوحة التحكم متصفح Chrome حقيقيًا دون واجهة ظاهرة على الخادم، وتفتح القالب أو صفحة الهبوط كما سيظهران على شاشة المستلم، ثم تلتقط صورة للصفحة كاملة. نجح الحل، لكنه أوجد مشكلات جديدة. فالمتصفح برنامج منفصل يجب تثبيته وتحديد مساره وتشغيله بصورة صحيحة على كل خادم، وتختلف طريقة تشغيله في بيئة الإنتاج عن الحاسوب المحمول. وظللنا نعدّل مسار تثبيته حتى أوائل 2026، بعد أكثر من عام من إطلاق النسخة الأولى.
لا ينبغي أن ينتظر المستخدم التقاط الصورة.
يستغرق عرض الصفحة والتقاطها ثواني، ولا يمكن أن نطلب من مدير لديه مكتبة قوالب أن ينتظر كل قالب على حدة. لذلك تُنشأ المعاينات في الخلفية. حين يحفظ المدير قالبًا، تتابع لوحة التحكم عملها، ويتولى عامل طابور المهام التقاط الصورة. ثم تظهر الصورة في أداة إعداد الحملة، حيث يختار المدير ما سيرسله.
المعاينة غير الدقيقة أسوأ من غيابها، لأنها تدفع المدير إلى إرسال التمرين معتقدًا أنه رأى ما سيرسله.
أدوات المحتوى · الاستيراد
استيراد أي صفحة بأكثر من طريقة
لا يرغب أحد في بناء سيناريو تصيّد مقنع من صفحة فارغة؛ فالبداية الطبيعية هي محتوى قائم. لذلك يتيح محرّر صفحات الهبوط للمستخدم إدخال رابط صفحة واستيرادها لتصبح جاهزة للتعديل. أما قوالب البريد، فيلصق المستخدم كود HTML قائمًا، وتنظّفه لوحة التحكم ليحتفظ بتنسيقه داخل البريد الوارد.
بدت المهمة بسيطة، لكنها أصبحت أكبر جزء منفرد في طبقة خدمات المنصة، بحجم 809 أسطر.
لماذا لم يكفِ طلب جلب واحد؟
- بعض الصفحات تصل مكتملة. يكفي طلبها للحصول على محتواها كله.
- وبعضها يصل فارغًا. ترسل المواقع الحديثة هيكلًا فارغًا وتبني الصفحة داخل متصفح الزائر، فلا يعيد الطلب العادي محتوى مفيدًا. في هذه الحالات، تشغّل لوحة التحكم متصفحًا حقيقيًا وتنتظر اكتمال بناء الصفحة.
- وبعضها يغيّر استجابته بحسب طريقة الطلب. فقد تنجح طريقة مع موقع ويتجاهلها موقع آخر.
- والغالبية العظمى منها توزّع مكوّناتها على ملفات متفرقة. فالتنسيقات في ملفات منفصلة، والصور تستخدم مسارات نسبية لا تعمل إلا على الموقع الأصلي، وتحاول السكربتات العمل داخل محرّرنا.
تسلسل بدائل لاستيراد صفحة هبوط برابطها: طلب عادي أولًا، ثم طلب بطريقة أخرى، ثم فتح الصفحة في متصفح حقيقي، مع رسالة خطأ واضحة إذا أخفقت كل المحاولات.
إذا كان المستخدم يعرف أن الصفحة تحتاج إلى متصفح حقيقي، تبدأ الأداة به مباشرةً.
معظم العمل في تنظيف المحتوى.
تجمع أداة الاستيراد التنسيقات المتفرقة وتضيفها مباشرةً إلى كل عنصر، لأن برامج البريد تتجاهل أوراق الأنماط. وتحوّل كل رابط نسبي إلى رابط كامل ليظل صالحًا بعد نقل الصفحة. كما تستطيع تضمين الصور نفسها، مع حدّ للحجم حتى لا يتضخّم القالب، لأن برامج البريد ترفض غالبًا تحميلها من مصادر خارجية. وتحذف السكربتات وتنظّم كود HTML ليقبله المحرّر، وتنقل خلفية الصفحة وخطها وألوانها، ليعرض المحرّر الصفحة بتنسيقها بدل أن تبدو ورقة فارغة.
تنظيف المحتوى في خمس مراحل
- تجميع التنسيقات
- تصحيح الروابط
- معالجة الصور
- إزالة السكربتات
- تهيئة المحتوى للمحرّر
وأضفنا ضوابط للاستخدام.
تنتهي الطلبات عند تجاوز مهلة محددة بدل أن تظل معلّقة. ويمنع تقييد معدل الطلبات أي شخص من إغراق مواقع الآخرين بطلبات صادرة من خوادمنا. ولا تصل السكربتات إلى المحرّر مطلقًا. ونشرنا آخر مجموعة تحسينات مخصصة لهذه الأداة في 2025.
مستوى الموزّعين · اكتمل مع الاستخدام
مستوى الشركاء الذي اكتمل تصميمه بالتجربة
كانت إعادة البيع جزءًا من الخطة منذ البداية: بندًا في العرض ومهمة في خطة التطوير. لكنها احتاجت عمليًا إلى سلسلة متواصلة من الإصدارات، لأن أحدًا لا يستطيع تصميم هذا المستوى بالكامل مسبقًا. فالطريقة الوحيدة لمعرفة احتياجات الموزّع هي أن تتيح له إصدارًا جاهزًا للاستخدام، ثم تراقب ما يتعطّل.
بدأنا بالهيكل الأساسي.
أضفنا مستوى أعلى من العميل، يضم عدة عملاء ويجمع نتائجهم ويخصّص لهم رصيدًا للحملات. وبنيناه ثم أعدنا بناءه على مدار نحو 3 أسابيع في منتصف 2025، مع اتضاح طبيعة العلاقة الفعلية بين الموزّع وعملائه.
ثم ظهرت احتياجات لم يذكرها أحد.
كان موظفو الدعم يستطيعون الدخول إلى حساب العميل لمساعدته، وهي ميزة نسمّيها الدخول بصفة مستخدم آخر، لكن الأداة كانت تدعم مستوى واحدًا فقط من الهيكل. وبعد أكثر من عام، احتاج أحدهم إلى الميزة نفسها لحساب موزّع. وسّعنا الأداة لتدعم نوعًا ثانيًا من الحسابات لم تُصمّم له أصلًا، وأعدنا صياغة الشريط الظاهر على الشاشة ليوضح نوع الحساب المعروض، بدل الاكتفاء بعبارة «أنت مسجّل الدخول بصفة مستخدم آخر».
وتغيّرت التسمية أيضًا.
أطلقنا هذا المستوى باسم عام هو «الشريك»، ثم اتضح أن مستخدمه أكثر تحديدًا: شركة خدمات تقنية معلومات تجري محاكاة التصيّد لعملائها. وفي وقت لاحق من 2026، غيّرنا اسم الدور في المنتج كله من «مسؤول الشريك» إلى «مسؤول مزوّد الخدمات المُدارة (MSP)»، لأن هذه هي الجهة التي كانت تستخدمه منذ البداية.
خط أفقي بثلاث علامات: بناء المستوى في منتصف 2025، ثم توسيع ميزة الدخول بصفة مستخدم آخر لتشمل نوعًا ثانيًا من الحسابات بعد أكثر من عام، ثم تغيير اسم الدور إلى «مسؤول مزوّد الخدمات المُدارة (MSP)» في وقت لاحق من 2026.
لا يكفي المزيد من التفكير لتصميم مستوى الموزّعين. أطلق أبسط نسخة، وأتحها لموزّع، ودعه يوضّح لك ما ينقصها.
ما بنيناه
ثلاث مراحل، ومحركان، ونقرة واحدة بقيت كما هي.
المرحلة الأولى · 2024 · لوحة تحكم لشركة واحدة
مهمة واحدة ننفّذها بإتقان
بدأنا بمهمة واحدة ننفّذها بإتقان: تمكين فريق الأمن من إجراء تمرين تصيّد تقليدي عبر البريد من البداية إلى النهاية. يتحقق المستخدم من ملكية نطاق الإرسال، ويرفع قائمة الموظفين، ويختار قالبًا ويجدول التمرين، ثم يرسل اختبارًا إلى نفسه ويطلق التمرين ويتابع النتائج: من فتح الرسالة، ومن نقر، ومن أفصح عن كلمة مروره. اعتمد ذلك على المحرك الأول، وهو إطار مفتوح المصدر لمحاكاة التصيّد، مع الفوترة والقوالب والتقارير التي جعلت الحل منتجًا متكاملًا يتجاوز مجرد سكربت. وأضفنا معاينات القوالب وصفحات الهبوط خلال الأشهر الأولى، في نهاية 2024.
المرحلة الثانية · 2025 · من شركة واحدة إلى شركات متعددة
من أداة إلى منصة
كان علينا إتاحة بيع المنتج من خلال جهات أخرى. وخلال منتصف 2025، أعدنا بناء الأساس في هيكل من 3 مستويات: مالك لوحة التحكم، ثم الموزّعون، ثم عملاؤهم. وخصّصنا دورًا لكل نوع من الحسابات، لفصل عملاء كل موزّع عن عملاء الموزّعين الآخرين. ترتبط كل قائمة ومُرسِل ونتيجة بالشركة المالكة لها، وتقتصر الاستعلامات التي تقرأها على بيانات تلك الشركة.
هكذا تحوّلت الأداة إلى منصة تستطيع شركات أخرى تقديمها بعلاماتها التجارية. لكن، كما يوضح القسم السابق، واصل استخدام الموزّعين كشف احتياجات جديدة حتى وقت متقدم من العام التالي. وتطوّرت أدوات المحتوى في ذلك العام أيضًا: أضفنا في منتصف 2025 صور معاينة محفوظة لكل قالب وصفحة هبوط، ثم أعدنا بناء أداة استيراد الصفحات القائمة إلى المحرّر في وقت لاحق من 2025.
المرحلة الثالثة · 2026 · المحرك الثاني والهجمات الحديثة
تمرين واحد عبر أي من المحركين
هذه أصعب المراحل، وقد شرحناها في القسمين الأولين أعلاه. بنينا الخدمة التي توفّر واجهة API للجزء المسؤول عن صفحة تسجيل الدخول في المحرك المتقدم، وربطنا المحرك بالمنصة عبرها. وبنينا نظام قوالب صفحات تسجيل الدخول لمحاكاة صفحات مزيّفة واقعية، وأضفنا التصيّد برموز QR، وهو أسلوب أحدث قد تفوته مرشّحات البريد القديمة. ومنذ ذلك الحين، أصبح بالإمكان إطلاق التمرين عبر أي من المحركين من الشاشة نفسها.
في جميع المراحل
نقرة واحدة، محركان
الهدف من هذا العمل كله هو ألّا تظهر للمستخدم أيٌّ من هذه التفاصيل. يُعدّ التمرين مرة واحدة، ثم ترسل المنصة مجموعات المستلمين ونطاقات الإرسال إلى المحركين وتبقيها متزامنة، وتطلق التمرين عبر المحرك المناسب، وتتتبّع كل مستلم على حدة، وتحسب التكلفة، وتفصل بيانات كل شركة. هذا التعقيد موجود فعلًا، ونحن نتولى التعامل معه عن العميل.
تفاصيل تقنية · إجراء واحد، محركان
تفاصيل أصعب تكامل
التحدي الهندسي الأبرز في المنصة ليس أيًا من المحركين منفردًا، بل إبقاء الاثنين متزامنين انطلاقًا من نقرة واحدة. يتعامل المحركان مع المستلمين والمُرسِلين والحملات بطرق متقاربة جدًا، لكن الثاني يحتاج أيضًا إلى خطوة إعداد إضافية وإلى خدمة التحكم التي بنيناها لتشغيل الجزء المسؤول عن صفحة تسجيل الدخول.
الحل الساذج هو الإرسال إلى المحرك الأول، ثم الثاني، وانتظار أن ينجح الاثنان. رفضنا هذا الأسلوب. فإذا أخفق الإرسال الثاني في منتصف العملية، ستوجد مجموعة المستلمين أو نطاق الإرسال في محرك دون الآخر، بلا وسيلة واضحة لمعرفة ذلك. وفي منتج أمني، الإعداد الناقص أسوأ من غياب الإعداد تمامًا.
لذلك تمرّ كل عملية عبر متحكّم واحد يوزّعها على المحركين.
حين يحفظ العميل مجموعة مستلمين أو نطاق إرسال، يرسل منسّق واحد السجل إلى المحركين، ويسجّل نتيجة كل منهما بصورة مستقلة. ولا يمسّ إخفاق أي محرك بيانات العميل في لوحة التحكم. نحفظ السجل، ونضع علامة نجاح للمحرك الذي أتمّ العملية، ونُظهر حالة كل محرك أخفق مع خيار «إعادة المزامنة» بنقرة واحدة. فلا تضيع البيانات، ولا تبقى أي عملية غير مكتملة، ولا يستطيع إخفاق خارجي إفساد بيانات العميل.
يدخل سجل محفوظ إلى لوحة التحكم، وهي المرجع الأساسي للبيانات. يخرج منها سهمان: أحدهما إلى المحرك القياسي المتزامن، والآخر إلى المحرك المتقدم الذي يظهر معطّلًا مع خيار إعادة المزامنة بنقرة واحدة. تتجه الأسهم إلى الخارج فقط، ولا يؤدي تعطل أحد المسارين إلى الإضرار بالأصل.
تتجه الأسهم من لوحة التحكم إلى الخارج فقط، ولا يؤدي تعطل أحد المسارين إلى الإضرار بالأصل.
هذا القرار هو ما يجعل النظام جديرًا بالثقة.
يحتفظ كل سجل بحالة مزامنته مع كل محرك على حدة. لذلك تعرف المنصة في أي لحظة ما وصل إلى المحرك القياسي، وما وصل إلى المحرك المتقدم، وما يحتاج إلى إعادة المحاولة.
وإلى جانب هذا الأساس، تعمل العمليات في الخلفية لجلب النتائج باستمرار. تستعلم المنصة من المحركين دوريًا عن فتح الرسائل والنقرات والبيانات المرسلة عبر النماذج، وتضع علامة الاكتمال على التمارين عند انتهاء مدتها، وتُعدّ التقارير الشهرية، دون أن يضغط أحد أي زر.
يجب أن تصل مجموعة المستلمين أو بيانات المُرسِل المحفوظة إلى المحركين. وإذا أخفق أحدهما، تبقى بيانات العميل آمنة ويظهر الإخفاق بوضوح.
كيف نعمل
اثنتا عشرة قاعدة، تبدأ بـمرجع أساسي واحد للبيانات.
لوحة التحكم هي المرجع الأساسي للبيانات
حين يعتمد المنتج على محرك خارجي، نتعامل مع بيانات المحرك باعتبارها نسخة نزامنها مع الأصل، لا باعتبارها المرجع الأساسي. تبقى بيانات العميل في قاعدة بياناتنا، وتظل آمنة مهما حدث في المحركين.
يجب ألّا يؤدي عطل في جزء إلى إفساد بيانات جزء آخر
قد تخفق المزامنة مع محرك خارجي، لكن يجب ألّا يؤثر ذلك في حفظ سجل العميل. نفصل العمليتين عمدًا، حتى يُظهر الانقطاع الخارجي الحاجة إلى إعادة المحاولة بدل أن يضيّع العمل.
أخفِ التعقيد
يجب ألّا يظهر لمن ينقر على «إطلاق» أن هناك محركين، أو طرفية يتحكم فيها برنامج، أو إعادة تشغيل تجري في الخلفية. نتولى هذا التعقيد عنه.
انسخ الحل، ثم طوّره حسب الحاجة
حين أضفنا المحرك الثاني في منتصف المشروع، لم نعد التصميم من الصفر. نسخنا ما يعمل بالفعل للمحرك الأول، ثم طوّرنا النسخة لتلائم بنية المحرك الثاني، خدمة بعد أخرى وعمودًا بعد آخر، حتى تخلّصنا من الافتراضات المبنية على وجود محرك واحد.
ابنِ واجهة الاتصال حين لا تتوافر
حين افتقرت أداة أساسية إلى وسيلة تتصل بها البرامج الأخرى، لم نتخلّ عن الميزة. بنينا على خادمها خدمة تدعم أكثر من 20 عملية، وأضفنا ملفًا لحفظ الحالة حتى لا تمحو إعادة التشغيل إعدادات العميل، وكتبنا العمليات الناقصة حين اتضح أن الخطة تفترض كودًا لم يُكتب بعد.
أطلق أبسط نسخة، ثم طوّر التصميم مع الاستخدام الفعلي
بعض الأجزاء لا يمكن التخطيط لها بالكامل، وخصوصًا مستوى الموزّعين. أطلقنا إصدارًا جاهزًا للاستخدام، وتابعنا أوجه قصوره مع شركاء فعليين، ثم وسّعناه مرتين بدل محاولة تخمين كل الاحتياجات مسبقًا.
اعرض ما سيظهر فعلًا قبل الإرسال
لا يثبت التمرين شيئًا إذا وصلت رسالته بتنسيق معطّل. لذلك نوفر لكل قالب وصفحة هبوط معاينة فعلية، هي صورة يلتقطها متصفح حقيقي، قبل أن ينقر أحد على «إطلاق».
جرّب الطريقة الأسهل ثم البدائل، ووضّح سبب التوقف
كل ما يعتمد على جهة خارجية، مثل موقع أو خادم أو متصفح، له سلسلة من البدائل، ورسالة خطأ مفهومة إذا أخفقت جميعها. فلا ينتهي المستخدم أمام شاشة فارغة.
نفّذ المهام البطيئة التي لا تحتاج إلى إشراف في الخلفية
تعمل مهام إنشاء المعاينات وجلب النتائج دوريًا وإعداد التقارير عبر طابور المهام، ثم تظهر النتيجة للمستخدم.
ابدأ بنطاق محدود، ثم وسّعه
أطلقنا أولًا منتجًا يعمل لشركة واحدة واختبرنا نجاحه. وبعد التأكد من سلامة النموذج، وسّعناه إلى منصة متعددة العملاء، قابلة لإعادة البيع وتعمل بمحركين. لم نراهن بكل شيء على إطلاق كبير واحد.
أطلق التحسينات بخطوات صغيرة
على مدار عامين من التطوير المتواصل، دمجنا 305 تغييرات، كل منها صغير بما يكفي لاختباره والتراجع عنه، بدل تغيير شامل واحد محفوف بالمخاطر. وكان نحو تغيير واحد من كل 5 تغييرات إصلاحًا، وهو ما يعكس التحصين التدريجي للنظام.
غيّر الإعدادات دون إعادة نشر التطبيق
تضم الإعدادات قواعد احتساب الدرجات وحدود الباقات وأحجام رموز QR وقواعد الرصيد والتسعير، لتتمكن الشركة من تغيير قواعدها التجارية دون انتظار فريقنا.
التقنيات المستخدمة
عشر طبقات، ووظيفة كل منها.
التطبيق
إطار عمل ناضج يتيح التطوير بسرعة، مع عدد كبير من المطوّرين الذين يمكن توظيفهم.
- PHP 8.2
- Laravel 11
الواجهة
تجربة شبيهة بالتطبيقات، دون إعادة تحميل الصفحات، عبر 180 شاشة ومكوّنًا.
- Vue 3
- Inertia
- Tailwind
- Vite
البيانات والتوسّع
تعمل المهام الثقيلة، مثل الإرسال والتتبّع وإعداد التقارير، في الخلفية دون إبقاء المستخدم منتظرًا.
- MySQL
- Redis
- Laravel Horizon
محركات محاكاة التصيّد
محركان للمحاكاة، قياسي ومتقدم، يعملان خلف لوحة تحكم واحدة.
- إطار عمل مفتوح المصدر لمحاكاة التصيّد
- محرك ثانٍ يعتمد على أداة وكيل عكسي
المدفوعات
شراء الرصيد بالخدمة الذاتية بعملات متعددة، مع رموز ترويجية وفواتير تلقائية.
- منصة دفع تحتسب استهلاك الرصيد
البريد والتنبيهات
إرسال موثوق للتقارير والإشعارات، وتنبيهات فورية لفريق العمليات.
- خدمة رسائل البريد الإلكتروني التلقائية
- تنبيهات عبر محادثات الفريق
تسجيل الدخول
تسجيل دخول آمن بالطرق المعتادة، مع تسجيل الدخول الموحّد (SSO) للمؤسسات عند حاجة العميل إليه.
- Jetstream
- تسجيل الدخول الموحّد (SSO) الاختياري
المستندات والمعاينات
معاينات للقوالب تُنشأ تلقائيًا، وتقارير PDF مطابقة لما يظهر على الشاشة وجاهزة للعرض على مجلس الإدارة.
- Headless Chrome
أدوات المحتوى
استيراد الصفحات القائمة إلى المحرّر، والحفاظ على تنسيق الرسائل داخل البريد الوارد، وعرض الصفحات كما يعرضها متصفح حقيقي.
- محرّر TinyMCE
- محلّل DiDOM
- أداة Emogrifier لتضمين التنسيقات داخل العناصر
- Puppeteer
السحابة
تخزين ملفات قوالب صفحات تسجيل الدخول وسجلات المدفوعات.
- AWS S3
الاختبارات الآلية
تتحقق الاختبارات الآلية من كل تغيير قبل وصوله إلى بيئة الإنتاج.
الخدمات الخارجية التي ربطناها بالمنصة حسب وظيفتها
- محرك قياسي لمحاكاة التصيّد
- محرك متقدم لمحاكاة التصيّد
- منصة دفع
- خدمة رسائل البريد الإلكتروني التلقائية
- أداة محادثات للفريق
- مزوّد هوية لتسجيل الدخول الموحّد (SSO) الاختياري
- AWS S3
سبع خدمات خارجية تعمل فعليًا في المجمل.
كيف تعمل المنصة
ست خطوات، من نطاق الإرسال إلى تقرير جاهز لمجلس الإدارة.
الخطوة 1
أعِدّ المُرسِل
تضيف الشركة نطاق بريدها، وترشدها المنصة خلال التحقق من ملكيته لضمان وصول رسائل التمارين بصورة موثوقة. وتمنع الإرسال من النطاقات غير المتحقق منها لحماية سمعة الشركة.
الخطوة 2
ارفع قائمة الموظفين
ارفع قائمة الموظفين من جدول بيانات، أو استخدم مجموعة محفوظة. تتحقق المنصة من صحة البيانات وتوضّح أي مشكلات قبل إرسال أي رسالة.
الخطوة 3
اختر سيناريو
اختر من المكتبة الجاهزة، أو انسخ سيناريو من سيناريوهاتك، أو أنشئ واحدًا في المحرّر، أو الصق كود HTML قائمًا لتنظّفه لوحة التحكم ويحافظ على تنسيقه في البريد الوارد، أو استورد صفحة قائمة برابطها لتستخدمها صفحة هبوط. يتيح كل خيار معاينة فعلية، هي صورة يلتقطها متصفح حقيقي، ويمكنك إرسال اختبار إلى نفسك أولًا.
الخطوة 4
أطلق التمرين عبر أي من المحركين
بنقرة واحدة، تطلق المنصة التمرين عبر المحرك المناسب، القياسي أو المتقدم، وتبقي بيانات المستلمين والمُرسِلين متزامنة في كليهما، وتبدأ تتبّع كل مستلم على حدة. وتحتسب استهلاك الرصيد لتجنّب الفواتير المفاجئة.
الخطوة 5
تابع النتائج مباشرةً
تعرض لوحة التحكم، لحظة بلحظة، من فتح الرسالة ومن نقر ومن وقع في الفخ، مع توقيت كل حدث وموقعه. وعندما تنتهي مدة التمرين، تُنهيه المنصة تلقائيًا.
الخطوة 6
أعِدّ التقرير
تحوّل المنصة النتائج إلى تقرير واضح يحمل العلامة التجارية للشركة، يستطيع المدير مشاركته مع مجلس الإدارة. كما يمكنها إرسال ملخصات شهرية بالبريد تلقائيًا. ويرى الموزّعون نتائج جميع عملائهم مجمّعة في عرض واحد.
ما يجري في الخلفية
تبقى بيانات كل شركة منفصلة عن بيانات الشركات الأخرى، ويدير الموزّعون عملاءهم بعلاماتهم التجارية. وتتولى المنصة إدارة الرصيد والفواتير وحدود الباقات تلقائيًا.
النتائج
ما تستطيع الشركة فعله الآن ولم يكن متاحًا لها في 2024.
محاكاة الهجمات الحديثة إلى جانب التقليدية
تمارين البريد التقليدية، وتمارين تسجيل الدخول المزيّف، والتصيّد برموز QR، وهو الأسلوب الأحدث، كلها من شاشة واحدة. وهذا ما يميّز المنصة عن أدوات المحاكاة الأبسط.
معاينة المحتوى قبل إرساله
لكل قالب وصفحة هبوط معاينة فعلية تُنشأ في الخلفية، ليطّلع المدير على ما سيراه المستلمون، بدل الاعتماد على ما يعرضه المحرّر.
البدء من أي مصدر
المكتبة، أو نسخ محتوى سابق، أو المحرّر، أو كود HTML ملصوق، أو صفحة قائمة تُستورد برابطها. تجرّب أداة الاستيراد حتى 3 طرق لقراءة الصفحة، ثم تنظّف المحتوى للمحرّر.
التحكم في جزء المحرك الذي يفتقر إلى واجهة API
تتوسط خدمة تدعم أكثر من 20 عملية بين لوحة التحكم والجزء المسؤول عن صفحة تسجيل الدخول في المحرك المتقدم. وتحفظ الخدمة ما يجب أن يبقى مفعّلًا، فلا يفقد العميل إعداداته عند إعادة تشغيل روتينية.
البيع من خلال الموزّعين
يدير الموزّعون عملاءهم بعلاماتهم التجارية عبر مستوى وسّعناه مرتين مع استخدام شركاء فعليين له. وأعدنا تسميته أخيرًا ليتوافق مع مستخدمه الفعلي: «مسؤول مزوّد الخدمات المُدارة (MSP)».
فصل بيانات الشركات المتعددة
يتبع كل سجل شركة محددة، فلا يرى كل عميل إلا موظفيه ونتائجه.
إطلاق التمرين عبر أي من المحركين
تطلق نقرة واحدة التمرين عبر المحرك المناسب، وتبقى بيانات مجموعات المستلمين والمُرسِلين متزامنة بين المحركين. ولا يفقد العميل بياناته إذا أخفق أحدهما؛ تكفي إعادة المحاولة بنقرة واحدة بدل أن يضطر العميل إلى إعادة عمله.
الفوترة التلقائية
شراء الرصيد بالخدمة الذاتية، وعملات متعددة، ورموز ترويجية، وفواتير تلقائية، ومنح الموزّعين أرصدة لعملائهم، دون جداول بيانات.
إعداد التقارير دون جهد
تتحوّل بيانات التتبّع الخام إلى تقرير PDF يحمل العلامة التجارية للشركة ورسالة بريد شهرية تلقائية، تساعد المدير على اتخاذ إجراء.
التشغيل دون إشراف
تتولى مهام مجدولة في الخلفية كل شيء، من جلب النتائج كل دقيقة إلى إعداد التقارير الشهرية للإدارة، دون تدخل بشري.
الهندسة بالأرقام
- 2 محركان لمحاكاة التصيّد ضمن سير عمل واحد
- 7 خدمات خارجية ربطناها بالمنصة
- 22 نموذج بيانات
- 32 خدمة، منها 14 مخصصة للمحركين
- 85 تغييرًا في قاعدة البيانات نشرناه تدريجيًا
- 180 شاشة ومكوّن Vue
- 3 محاولات تجريها أداة استيراد الصفحات قبل التوقف
- 809 أسطر في أداة استيراد الصفحات، وهي أكبر خدمة
- 20+ عملية في خدمة التحكم بالمحرك المتقدم التي بنيناها من الصفر
- 4 خدمات للمحرك القياسي أصبحت لها نظائر في المحرك المتقدم
- 305 تغييرًا في الكود دمجناه على مدار نحو عامين
- ~31,800 سطر من كود التطبيق
قرارات معمارية
هذه هي القرارات التي تجعل المنصة جديرة بالثقة، لا مجرد منصة تؤدي وظائفها:
لوحة التحكم هي المرجع الأساسي للبيانات
المحركات الخارجية تحتفظ بنسخ نزامنها مع الأصل، وليست هي المرجع الأساسي. لذلك تبقى بيانات العميل آمنة مهما حدث في المحركين.
مزامنة المحركين دون تعطيل الحفظ
نفصل عمدًا بين حفظ سجل العميل ومزامنته مع المحرك. فإذا أخفقت الخدمة الخارجية، نُظهر خيار إعادة المحاولة بنقرة واحدة بدل أن تتلف البيانات أو تضيع.
حصر البيانات في نطاق كل عميل
تحصر الاستعلامات البيانات في الشركة المالكة لها، فلا يتعامل كل عميل إلا مع سجلاته.
سجلات تدقيق وحذف منطقي في جميع أجزاء النظام
تسجّل السجلات الأساسية هوية من أنشأها ومن عدّلها، وتُؤرشف بدل حذفها نهائيًا، لتبقى بيانات التمارين السابقة متاحة وقابلة للتدقيق.
الوضع الفعلي للمنصة
المنصة تعمل فعليًا، ونواصل تطويرها، وكل رقم في هذه الصفحة مستخرج من الكود الحالي. ولا تتوافر أي مؤشرات أعمال متحقق منها: لا عدد العملاء، ولا عدد التمارين المنفّذة، ولا الإيرادات، ولا مقدار انخفاض معدل النقر. لذلك تركّز الصفحة على ما يفعله البرنامج وكيف بنيناه، لا على أرقام الاستخدام، لأن إحصائية مختلقة واحدة تكفي للطعن في مصداقية سائر الأرقام.
أعمال ذات صلة
منصة التعرّض السيبراني
الأمن السيبراني · 2021 – حتى الآن · بناء وتشغيل وصيانة
10 — خدمات أمنية، تجمع خمس منها نتائجها في درجة واحدة
منصة الشحن الجوي والجمارك
الخدمات اللوجستية · 2025 – 2026 · تحديد المواصفات والبناء والنشر
7 أيام — من مستودع فارغ إلى واجهة API موثّقة تعمل فعليًا، وقّع الطرفان العقد بناءً عليها
الخطوة التالية
هل يعتمد منتجك على أدوات لم تُصمّم لتتصل ببعضها؟
اعمل مع فريق هندسي يبني وسائل التكامل حين لا تتوافر، ويحمي بياناتك حين تخفق خدمة خارجية، ويتولى التعقيد بحيث لا يراه عملاؤك.
أخفينا هوية العميل · كل رقم محسوب من الكود المصدري · أكتوبر 2026