<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>حسوب I/O - مساهمات المستخدم musheghmanukyan</title>
		<description>المساهمات التي أرسلها musheghmanukyan - حسوب I/O</description>
		<language>ar</language>
		<generator>حسوب I/O</generator>
		<item>
			<title>هل يجب أن تحمل كل إشارة سوق «إيصال قرار» يمكن إعادة بنائه؟</title>
			<pubDate>Wed, 23 Sep 2026 16:59:10 +0000</pubDate>
			<link>https://io.hsoub.com/tech/185585-%D9%87%D9%84-%D9%8A%D8%AC%D8%A8-%D8%A3%D9%86-%D8%AA%D8%AD%D9%85%D9%84-%D9%83%D9%84-%D8%A5%D8%B4%D8%A7%D8%B1%D8%A9-%D8%B3%D9%88%D9%82-%D8%A5%D9%8A%D8%B5%D8%A7%D9%84-%D9%82%D8%B1%D8%A7%D8%B1-%D9%8A%D9%85%D9%83%D9%86-%D8%A5%D8%B9%D8%A7%D8%AF%D8%A9-%D8%A8%D9%86%D8%A7%D8%A6%D9%87</link>
			<description><![CDATA[تصل إلى المستخدم رسالة تقول: «تحرك السعر بنسبة 4%». تبدو العبارة بسيطة وحاسمة، لكنها تخفي سلسلة طويلة من القرارات. أي سعر استُخدم؟ ومن أي مزود؟ وما النافذة الزمنية التي حُسبت عليها النسبة؟ وهل كانت البيانات حديثة عند التقييم؟ وماذا حدث إذا وصل تحديث متأخر بعد إرسال التنبيه؟  تظهر المشكلة بوضوح عندما يفتح المستخدم الرسم البياني بعد دقائق فلا يجد الحركة نفسها. قد يكون المخطط قد صحح قيمة شاذة، أو بدّل مزود البيانات، أو أعاد ترتيب أحداث وصلت خارج تسلسلها الزمني. في هذه اللحظة لا يكفي أن نقول إن «النظام كان يرى ذلك وقتها». نحتاج إلى أثر صغير ودقيق يشرح ما رآه النظام، وما القاعدة التي طبقها، ولماذا اختار الإرسال.  أسمي هذا الأثر «إيصال القرار». ليس المقصود مستندًا قانونيًا، ولا سجلًا ضخمًا لكل ما حدث في البنية التحتية، بل بنية بيانات محدودة تسمح لفريق المنتج والدعم، وربما للمستخدم نفسه، بإعادة بناء سبب التنبيه دون تخمين.  التنبيه ادعاء، وليس مجرد رسالة  كل تنبيه سوق يتضمن ادعاءً ضمنيًا: في لحظة معينة، وبحسب مصادر وشروط محددة، تحققت قاعدة ما. إذا احتفظنا بالنص النهائي فقط فقدنا معظم عناصر هذا الادعاء. أما إذا احتفظنا بإيصال القرار، فيمكننا التمييز بين أربع حالات مختلفة تبدو للمستخدم متشابهة:  1. تحققت القاعدة على بيانات حديثة ومتسقة. 2. تحققت على مصدر احتياطي بعد تعطل المصدر الأساسي. 3. تحققت على قيمة وصلت متأخرة، ثم صُححت لاحقًا. 4. لم تتحقق أصلًا، لكن تكرار حدث أو خطأ في حالة الذاكرة أدى إلى إرسال مكرر.  هذا التمييز مهم لأن العلاج يختلف. الحالة الثانية قد تكون سلوكًا صحيحًا يجب شرحه، والثالثة تحتاج سياسة تصحيح واضحة، والرابعة عيب برمجي ينبغي منعه باختبار عدم التكرار.  أربعة أزمنة بدل طابع زمني واحد  من أكثر الأخطاء شيوعًا أن يحمل السجل حقلًا واحدًا باسم timestamp. هذا الحقل لا يجيب عن السؤال: طابع زمن ماذا؟ في نظام تنبيهات عملي أفضّل فصل أربعة أزمنة على الأقل:  - زمن الحدث: الوقت الذي ينسبه المصدر إلى الصفقة أو السعر. - زمن الاستلام: الوقت الذي وصلت فيه البيانات إلى نظامنا. - زمن التقييم: الوقت الذي شغّل فيه المحرك القاعدة. - زمن الإرسال: الوقت الذي سلّم فيه النظام الرسالة إلى قناة الإشعار.  الفروق بين هذه الأزمنة تحمل معنى. إذا كان زمن الحدث قديمًا لكن الاستلام حديث، فلدينا وصول متأخر. وإذا كان التقييم سريعًا لكن الإرسال متأخر، فالمشكلة في طابور الإشعارات لا في بيانات السوق. وإذا بدا كل شيء متزامنًا على الورق، فقد يكون انحراف ساعات الخوادم قد أخفى الخلل، ولهذا ينبغي تسجيل مصدر الساعة ودقة القياس عند الحاجة.  ما الحد الأدنى المفيد داخل الإيصال؟  لا توجد صيغة واحدة تناسب كل المنتجات، لكن الإيصال الصغير يمكن أن يحتوي على العناصر التالية:  - معرّف فريد للقرار، مستقل عن معرّف الرسالة. - نسخة قاعدة التنبيه، لا اسمها فقط. - تعريف الأداة والسوق بعد التطبيع، مع رمز المصدر الأصلي. - معرّف المصدر ومسار التحويل أو المزود الاحتياطي إن استُخدم. - القيم الداخلة إلى الحساب والنافذة الزمنية المختارة. - أزمنة الحدث والاستلام والتقييم والإرسال. - حالة الجودة: حديثة، قديمة، متعارضة، ناقصة، أو مجهولة. - نتيجة كل شرط فرعي، وليس النتيجة النهائية وحدها. - سياسة البيانات المفقودة وسياسة إزالة التكرار المطبقتان. - بصمة لإعدادات القاعدة ولنسخة المحول البرمجي. - سبب ثابت ومقروء آليًا مثل THRESHOLD_CROSSED أو SOURCE_STALE.  يمكن تمثيل ذلك منطقيًا على النحو الآتي، من دون ربطه بلغة برمجة معينة:  decision_id: d_01 rule_version: price_move_v3 instrument: BTC-USD source_symbol: XBTUSD event_time: 12:00:01.200Z received_time: 12:00:02.840Z evaluated_time: 12:00:02.901Z quality_state: STALE condition: change_5m &amp;gt;= 4.0 observed_change: 4.2 result: HOLD reason_code: SOURCE_STALE  المثال اصطناعي، لكنه يوضح نقطة مهمة: قد تتجاوز القيمة العتبة ومع ذلك تكون النتيجة HOLD لأن سياسة المنتج تمنع إرسال تنبيه مبني على مصدر قديم. لو سجّلنا النتيجة فقط، فلن نعرف إن كان النظام تجاهل الحركة أم طبّق حاجز الجودة كما صُمم.  إعادة البناء ليست سفرًا إلى الماضي  وجود إيصال لا يضمن أن إعادة التشغيل بعد أسبوع ستنتج البتات نفسها. قد تتغير مكتبة حساب، أو قاعدة مناطق زمنية، أو خريطة الرموز، أو طريقة التقريب. لذلك يجب أن نحدد ما الذي نعنيه بإعادة البناء:  - إعادة تفسير: يستطيع الإنسان فهم سبب القرار من القيم والحالات المسجلة. - إعادة تقييم: يستطيع المحرك تشغيل نسخة القاعدة نفسها على المدخلات المحفوظة. - إعادة إنتاج كاملة: تنتج البيئة نفسها المخرجات نفسها على مستوى البتات.  غالبًا تكفي إعادة التفسير وإعادة التقييم. أما إعادة الإنتاج الكاملة فتكلف أكثر، وقد تتطلب تثبيت إصدارات التبعيات وبيئة التنفيذ. المهم ألا نعد بدرجة ضمان لا يوفرها النظام فعليًا.  لا تمحُ التصحيح؛ اربطه بالقرار الأصلي  إذا اكتشفنا بعد الإرسال أن مصدرًا صحح السعر، فأسهل تنفيذ هو تعديل السجل القديم. لكنه أسوأ تنفيذ للتحقيق، لأنه يمحو ما عرفه النظام لحظة القرار. الأفضل إبقاء الإيصال الأصلي وإضافة حدث تصحيح يشير إليه:  - ما القيمة التي تغيرت؟ - متى وصل التصحيح؟ - هل كان سيغيّر نتيجة القاعدة؟ - هل أُرسل إشعار توضيحي؟ - ما السياسة التي قررت الإرسال أو عدمه؟  بهذا نحافظ على خط زمني صادق: القرار كان مبررًا أو غير مبرر وفق المعلومات المتاحة وقتها، ثم ظهرت معلومة جديدة. لا نعيد كتابة التاريخ ليبدو النظام معصومًا.  الإيصال ليس مبررًا لجمع كل شيء  قابلية التدقيق قد تتحول بسهولة إلى تخزين مفرط. لا يحتاج إيصال تنبيه سعري إلى عنوان المستخدم أو نص جهازه أو رمز دخول أو حمولة كاملة من مزود خارجي. الأفضل فصل هوية القرار عن هوية الشخص، وتخزين أقل قدر يسمح بالتفسير، مع سياسة احتفاظ واضحة.  يمكن أن تبقى تفاصيل حساسة في سجل داخلي ذي وصول مقيد، بينما يحصل المستخدم على نسخة مبسطة: المصدر، وقت آخر تحديث، القاعدة، القيمة التي شوهدت، وحالة الجودة. وإذا احتجنا إلى ربط الإيصال بحساب، يمكن استخدام معرّف غير مباشر مع ضوابط حذف واحتفاظ منفصلة.  واجهة «لماذا وصلني هذا التنبيه؟»  لا ينبغي عرض بنية الإيصال الخام لكل مستخدم. يمكن بناء ثلاث طبقات:  1. طبقة سريعة: «وصل التنبيه لأن الحركة خلال خمس دقائق بلغت 4.2%، لكن الإرسال عُلّق لأن المصدر كان قديمًا». 2. طبقة تفاصيل: المصدر، الأوقات الأربعة، نسخة القاعدة، وحالة الجودة. 3. طبقة دعم هندسية: البصمات، نتائج الشروط الفرعية، مسار المزود الاحتياطي، وأحداث التصحيح.  هذه الطبقات تجعل الشفافية قابلة للاستخدام. كثرة الحقول ليست شفافية إذا لم يعرف القارئ لماذا تهمه.  الاختبار قبل تخزين مليارات الإيصالات  قبل إضافة سجل دائم، يمكن اختبار التصميم بسلاسل بيانات اصطناعية صغيرة. من السيناريوهات التي أراها أساسية:  - وصول حدثين بترتيب معكوس. - تكرار الحدث نفسه بمعرّف واحد ثم بمعرّفين مختلفين. - توقف المصدر الأساسي والتحول إلى مصدر احتياطي بوحدات مختلفة. - قفزة في ساعة خادم التقييم. - تغيير نسخة القاعدة بينما توجد أحداث في الطابور. - تصحيح قيمة بعد إرسال التنبيه. - فشل قناة الإرسال ثم إعادة المحاولة. - حذف بيانات شخصية مع بقاء الإيصال التقني قابلًا للفهم.  لكل سيناريو نكتب النتيجة المتوقعة والإيصال المتوقع. إذا لم نستطع شرح الفرق بين سجلين في اختبار صغير، فلن نتمكن من شرحه تحت ضغط حادث إنتاجي.  التكلفة الحقيقية ليست التخزين فقط  الإيصالات تزيد حجم البيانات، لكنها تفرض أيضًا انضباطًا في إدارة نسخ القواعد، وتعريف حالات الجودة، وربط التصحيحات، وحماية الحقول الحساسة. وقد تكشف أن المنتج نفسه لا يملك تعريفًا واضحًا لكلمة «حديث» أو «موثوق».  لهذا لا أرى الإيصال ميزة تُضاف في النهاية. هو اختبار لتماسك قرار المنتج. إذا عجز الفريق عن كتابة سبب ثابت للقرار، فربما القاعدة غامضة أصلًا. وإذا تعذر تحديد المدخلات الضرورية، فربما التنبيه يعتمد على حالة خفية لا ينبغي الاعتماد عليها.  في المقابل، لا أعتقد أن كل إشعار بسيط يحتاج إلى البنية نفسها. يمكن تحديد مستويات: إيصال مختصر للتنبيهات منخفضة الأثر، وإيصال أغنى للقرارات التي قد تغيّر سلوك المستخدم أو تحتاج إلى دعم ومراجعة. المهم أن يكون الاختيار صريحًا، لا نتيجة صدفة في طريقة التسجيل.  سؤالان للنقاش  إذا كنتم تبنون تنبيهات أو قواعد آلية، فما الحقول الثلاثة التي لا يمكنكم التحقيق في قرار من دونها؟ وهل ترون أن تصحيحًا لاحقًا يجب أن يولّد إشعارًا جديدًا للمستخدم، أم يكفي تحديث صفحة التفاصيل مع الحفاظ على السجل الأصلي؟  إفصاح: استُخدمت أدوات ذكاء اصطناعي للمساعدة في تنظيم الأفكار والصياغة العربية. تستند الحدود التقنية إلى خبرة المؤلف، ولم يخضع النص لمراجعة لغوية مستقلة من متحدث عربي أصلي. جميع الأمثلة تعليمية واصطناعية، ولا تصف نظامًا إنتاجيًا بعينه، وليست نصيحة مالية أو استثمارية أو قانونية.  Mushegh Manukyan — Founder &amp;amp; CEO of ARMCP، يريفان، أرمينيا.]]></description>
		</item>
	</channel>
</rss>
