الوحدة 8 — المتغيّرات المشتركة بين الفِرَق

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

من مالك واحد إلى مستهلكين متعدّدين

في اللحظة التي يُصبح فيها المتغيّر مشتركًا، تتغيّر المسؤوليّات. المالك (فريق الاحتيال في مثالنا) يعرف أنّ التعديل لم يعد يمسّ نموذجه فقط. المستهلك (فريق التسويق) يعرف أنّه يعتمد على شيء لا يملكه.

هذه العلاقة تحتاج ثلاث آليّات تدعمها كلّ المخازن الجادّة:

1. الاكتشاف: كيف يجد فريق التسويق أنّ العدّاد موجود أصلًا؟
2. العقد: كيف يفهم بالضبط ما يعني، وبأيّ نضارة، وبأيّ ضمانات؟
3. التغيير المُتّفق عليه: كيف يُغيَّر التعريف بلا كسر مفاجئ للمستهلكين؟

الاكتشاف: كتالوج قابل للبحث

من دون اكتشاف، لا إعادة استعمال. الفريق الجديد يبني ما لديه بالفعل لأنّه لا يعلم بوجوده. المخازن الحديثة (Tecton، Feast UI، Databricks Feature Store) تعرض لوحة اكتشاف فيها لكلّ وصفة:

• الاسم، والوصف، والوسوم
• المالك ووسائل الاتّصال
• مخطّط الحقول مع الأنواع والوحدات
• النضارة الحاليّة، والإدارة على 30 يومًا
• قائمة النماذج التي تستهلكها

في Feast مع Feast UI:

feast ui

يُشغَّل خادم ويب محلّيّ يعرض هذا. في الإنتاج يُنشَر كخدمة داخليّة، ويُربَط بـSSO الشركة ليكون كلّ فرد قادرًا على البحث والقراءة (بلا حاجة إلى إذن كتابة).

الوسوم مهمّة أكثر ممّا يظنّ. domain: payments, pii: false, regulated: pci-dss تسمح بترشيح سريع. فريق تسويق يبحث «متغيّرات على العملاء، لا هويّة، مجدَّدة كلّ ساعة» يجد بسرعة ما يستحقّ.

العقد: التوثيق داخل الكود

الوصف لا يُكتب في ملفّ منفصل. يعيش في تعريف الوصفة (الوحدة 4). كلّ حقل يحمل جملة أو جملتين توضح معنى لا حسابًا:

Field(
    name="count_1h",
    dtype=Int64,
    description=(
        "عدد المعاملات الناجحة للعميل في آخر 60 دقيقة، "
        "بحسب طابع event_time بتوقيت UTC. "
        "لا يُعدّ الطلب الحاليّ. يستثني المرفوضة من البنك."
    ),
)

المستهلك الذي يقرأ هذا يعرف مباشرة أنّه لا يستطيع استعمال العدّاد لعرض «مجموع المعاملات هذا الأسبوع» لأنّ الطلب الحاليّ ليس محسوبًا. لا حاجة إلى بريد إلكترونيّ مع المالك.

اتفاقيّات مستوى الخدمة على المتغيّر

فوق التوثيق التقنيّ، تفرض المخازن الناضجة اتفاقيّة SLA لكلّ وصفة:

• الحداثة المضمونة (مثلًا: عمر أقصى 10 دقائق في 99% من الأحيان)
• استمراريّة (مثلًا: نشرة الفشل خلال 5 دقائق)
• وتيرة التغييرات (مثلًا: لا تعديل بلا 14 يومًا من الإخطار المسبق)

هذه الاتفاقيّات تُصبح ملزمة لأنّ المالك يعرف أنّ نماذج إنتاج تعتمد عليه. وحين ينهار متغيّر، يعرف المستهلكون من عليهم اللجوء إليه — لا فوضى تُلقى فيها المسؤوليّة كرة نار.

نمط RACI للمتغيّرات المشتركة

في المؤسّسات الكبيرة، تُطبَّق مصفوفة RACI:

الدور	مثال
Responsible (المُنفِّذ)	مُهندسة بيانات في فريق الاحتيال
Accountable (المُساءل)	قائد فريق الاحتيال
Consulted (المُستشار)	فرق التسويق والمخاطر (مستهلكون)
Informed (المُخبَر)	حوكمة البيانات المركزيّة

مصفوفة كهذه تُلحق كوسوم في السجلّ نفسه، فتصبح البيانات صريحة، لا شفويّة.

متغيّرات فرعيّة: التفرّع بدل النسخ

كثيرًا ما يحتاج فريق ثانٍ متغيّرًا قريبًا لا مطابقًا: مثلًا count_24h بدل count_1h. الحلّ ليس نسخ التعريف. الحلّ:

• إذا كان الفارق تجميعيّ (نافذة زمنيّة)، فوصفة واحدة تحمل عدّة نوافذ.
• إذا كان الفارق فلترة (استبعاد فئة معيّنة)، متغيّر مشتقّ يُبنَى فوق الأوّل.
• إذا كان الفارق دلاليًّا (لا يقيس الشيء نفسه)، وصفة جديدة بمالك جديد ووصف يقول لماذا لا يُعاد استعمال القديم.

النسخ الأعمى هو أخطر من عدم الاستعمال: يُنتج تعريفَين شبه متطابقَين، كلاهما ينحرف مستقلًّا، ولا أحد يعرف أيّهما مرجعيّ.

قصّة صغيرة: مكسب مقاس

فريق دفع في متجر إلكترونيّ متوسّط الحجم بنى في ستّة أشهر مخزن متغيّرات (Feast + Redis). قبل ذلك، ثلاثة فرق (الاحتيال، التسويق، التحصيل) كانت كلّ منها تحسب متغيّراتها. بعد أن اعتمد فريق التسويق على وصفات فريق الاحتيال:

• عدد سطور شفرة تحضير المتغيّرات في مشاريع التسويق نزل من 900 إلى 40
• الوقت الوسطيّ لدمج ميزة جديدة انخفض من 3 أسابيع إلى 5 أيّام
• فجوة معتادة (اختلاف تعريف active_customer بين الفريقين) اختفت مباشرة

الأرقام ليست معيار حكم لأيّ حالة، لكنّها تُظهر أنّ إعادة الاستعمال ليست فكرة نظريّة.

اختبار «لو غادرت غدًا»

لكلّ وصفة، اسأل: لو ترك المالك الفريق غدًا، هل يستطيع شخص جديد فهمها من الكود واستكمال صيانتها؟ إن كانت الإجابة لا، فالتوثيق ناقص. هذا الاختبار يكشف المتغيّرات «العرشيّة» (tribal knowledge) التي هي بذور فجوات مستقبليّة.

الخلاصة

• إعادة الاستعمال هي الحجّة الاقتصاديّة الرئيسة، وتوفّر أسابيع من العمل وتُلغي فجوات صامتة بين نماذج.
• الاكتشاف يحتاج لوحة كتالوج قابلة للبحث، مع وسوم دلاليّة، ومقاييس نضارة.
• العقد يعيش داخل تعريف الوصفة عبر أوصاف الحقول واتفاقيّات SLA.
• تجنّب النسخ الأعمى: إن كان الفارق تجميعيًّا، أضِف نافذة للوصفة القائمة؛ وإلّا، أنشئ وصفة جديدة بمالك جديد.

الوحدة التالية: كيف نُراقب جودة المتغيّرات نفسها، قبل أن نُراقب أداء النموذج.