تقاريرنا اليومية كانت سباقًا مع الزمن: كيف أنقذتنا ‘منصات تنسيق المهام’ (Workflow Orchestration) من جحيم العمليات اليدوية؟

“يا زلمة، السكريبت الخامس علّق كمان مرة!”

أذكر تلك الأيام جيدًا، كانت الساعة تقارب الثانية صباحًا. أجلس في مكتبي الصغير، عيناي محمرّتان من التعب والتحديق في شاشة سوداء تعرض سجلات (logs) لا نهاية لها. كان يوم “توليد التقرير الشهري”، وهو اليوم الذي يتحول فيه فريق هندسة البيانات لدينا إلى فريق إطفاء حرائق.

العملية كانت تبدو “بسيطة” على الورق: عشرة سكربتات بلغة بايثون يجب أن تعمل بالترتيب. الأول يسحب البيانات من قاعدة البيانات، الثاني ينظفها، الثالث يدمجها مع بيانات من واجهة برمجية (API)، الرابع يقوم بحسابات معقدة… وهكذا حتى السكريبت العاشر الذي يرسل التقرير النهائي عبر البريد الإلكتروني للإدارة. لكن في الواقع، كانت “شغلانة” ما يعلم فيها إلا الله.

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

في إحدى تلك الليالي المظلمة، وبعد إعادة تشغيل العملية للمرة الثالثة، قلت لزميلي: “لازم نلاقي حل، هذه ورطة حقيقية ومش هيك بنبني أنظمة محترمة”. ومن هنا بدأت رحلتنا لاكتشاف عالم “منصات تنسيق المهام” أو الـ Workflow Orchestration.

ما هو “جحيم العمليات اليدوية” الذي كنا نعيشه؟

قبل أن نغوص في الحل، دعوني أفصّل لكم طبيعة المعاناة التي كنا نعيشها، والتي قد يجد الكثير من المطورين ومهندسي البيانات أنفسهم فيها اليوم:

الاعتمادية الهشة (Fragile Dependencies)

كانت أكبر مشاكلنا هي إدارة الاعتماديات بين المهام. سكربت “ب” لا يمكن أن يبدأ قبل أن ينتهي سكربت “أ” بنجاح. كنا ندير هذا باستخدام سكربتات Bash بسيطة أو أدوات مثل Cron Jobs، لكن هذا النظام كان هشًا للغاية. ماذا لو فشل “أ”؟ لا يوجد نظام تلقائي لإعلام “ب” بذلك، ولا آلية ذكية لإعادة المحاولة.

غياب الرؤية والمراقبة (Lack of Visibility & Monitoring)

عندما تفشل مهمة ما في منتصف الليل، يبدأ التحقيق البوليسي. أين ملف السجل (log file)؟ هل هو على السيرفر الأول أم الثاني؟ لا توجد لوحة تحكم مركزية (dashboard) تمنحنا نظرة شاملة على حالة جميع العمليات. كنا نتنقل بين عشرات النوافذ والملفات لنفهم ما الذي حدث بالضبط.

صعوبة إعادة التشغيل (Difficulty of Reruns)

تخيل أن لديك عملية مكونة من 20 خطوة، وفشلت الخطوة رقم 15. هل من المنطقي إعادة تشغيل كل شيء من الخطوة الأولى؟ هذا ليس فقط مضيعة للوقت، بل قد يؤدي إلى تكرار البيانات أو نتائج خاطئة. كنا نفتقر إلى آلية ذكية تقول: “أعد تشغيل المهمة الفاشلة فقط وواصل من حيث توقفت”.

استنزاف الوقت والجهد (Drain on Time & Effort)

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

طوق النجاة: لنتعرف على “منصات تنسيق المهام”

منصات تنسيق المهام هي ببساطة “المايسترو” الذي يقود أوركسترا مهام البيانات والعمليات الخاصة بك. بدلاً من تشغيل كل سكربت بشكل منفصل والقلق بشأن الترتيب والأخطاء، أنت تقوم بتعريف “سير العمل” (Workflow) بأكمله في مكان واحد، وهذه المنصة تتكفل بالباقي.

المفهوم الجوهري خلف معظم هذه المنصات هو ما يسمى بـ “الرسم البياني الموجه غير الدائري” (Directed Acyclic Graph – DAG). لا تدع الاسم يخيفك، فالдея، ببساطة، هي خريطة أو مخطط انسيابي لمهامك. كل مهمة هي “عقدة” (node) في الرسم، والأسهم بينها تحدد ترتيب التنفيذ (“موجه”). وكونه “غير دائري” يعني أنه لا توجد حلقات لا نهائية؛ العملية تبدأ وتنتهي.

أشهر اللاعبين في هذا المجال هم: Apache Airflow، Prefect، Dagster، و Mage. في هذه المقالة، سأركز على Apache Airflow لأنه الأكثر نضجًا وشيوعًا، وهو الذي استخدمناه لإنقاذ أنفسنا.

مثال عملي: بناء أول خط أنابيب (Pipeline) لنا مع Apache Airflow

Airflow يعتمد على كتابة تعريفات الـ DAGs باستخدام لغة بايثون. هذا يعني أن سير عملك هو مجرد كود، مما يجعله قابلاً للاختبار، ووضعه في نظام إدارة الإصدارات (مثل Git)، والتعاون عليه مع فريقك.

المفاهيم الأساسية في Airflow

• DAG: الكائن الذي يمثل سير العمل بأكمله. أنت تعرّف متى يبدأ، وكم مرة يتكرر، إلخ.
• Operator: قالب لمهمة واحدة. هناك أنواع كثيرة مثل BashOperator لتشغيل أوامر Bash، و PythonOperator لتشغيل دوال بايثون، و PostgresOperator لتنفيذ استعلامات SQL، والمئات غيرها.
• Task: نسخة (instance) من الـ Operator. هي المهمة الفعلية التي ستعمل.
• Dependencies: طريقة تعريف الترتيب بين المهام. في Airflow، هي بسيطة جدًا، تبدو هكذا: task_a >> task_b (شغل “أ” ثم شغل “ب”).

من الفوضى إلى الكود المنظم: لنكتب DAG بسيط

لنتخيل أننا نريد أتمتة عملية ETL (Extract, Transform, Load) بسيطة. بدلاً من ثلاثة سكربتات منفصلة، سنكتب DAG واحدًا في Airflow.

نصيحة من أبو عمر: قبل كتابة الكود، ارسم الـ DAG على ورقة أو سبورة بيضاء. تحديد المهام والاعتماديات بينها بصريًا يسهل المهمة بشكل لا يصدق.

# import المكتبات اللازمة
from __future__ import annotations

import pendulum

from airflow.models.dag import DAG
from airflow.operators.python import PythonOperator

# ========== دوال البايثون التي ستمثل مهامنا ==========

def extract_data():
    """
    مهمة وهمية لسحب البيانات. في الواقع، قد تتصل بـ API أو قاعدة بيانات.
    """
    print("بدء سحب البيانات...")
    # لنفترض أننا سحبنا هذه البيانات
    data = {"user_id": 1, "name": "Abu Omar", "visits": 10}
    print("تم سحب البيانات بنجاح.")
    return data # نمرر البيانات للمهمة التالية

def transform_data(ti):
    """
    مهمة لتنظيف وتحويل البيانات.
    """
    print("بدء تحويل البيانات...")
    # نسحب البيانات التي أرجعتها المهمة السابقة
    extracted_data = ti.xcom_pull(task_ids='extract_task')
    
    # نضيف حقل جديد
    transformed_data = extracted_data.copy()
    transformed_data["status"] = "active"
    
    print("تم تحويل البيانات بنجاح.")
    return transformed_data

def load_data(ti):
    """
    مهمة لتحميل البيانات في وجهتها النهائية (قاعدة بيانات، ملف, etc.).
    """
    print("بدء تحميل البيانات...")
    # نسحب البيانات المحوّلة
    final_data = ti.xcom_pull(task_ids='transform_task')
    
    # هنا تكتب الكود لحفظ البيانات في قاعدة البيانات مثلاً
    print(f"جاري تحميل البيانات: {final_data}")
    print("تم تحميل البيانات بنجاح.")


# ========== تعريف الـ DAG ==========

with DAG(
    dag_id="daily_report_dag_v1", # اسم فريد للـ DAG
    start_date=pendulum.datetime(2023, 1, 1, tz="UTC"), # تاريخ بدء التشغيل
    schedule="@daily", # جدولة التشغيل: مرة كل يوم
    catchup=False, # لا تقم بتشغيل المهام الفائتة منذ تاريخ البدء
    tags=["example", "etl"],
) as dag:

    # ========== تعريف المهام (Tasks) ==========

    extract_task = PythonOperator(
        task_id="extract_task", # اسم فريد للمهمة
        python_callable=extract_data, # الدالة التي ستنفذها المهمة
    )

    transform_task = PythonOperator(
        task_id="transform_task",
        python_callable=transform_data,
    )

    load_task = PythonOperator(
        task_id="load_task",
        python_callable=load_data,
    )

    # ========== تعريف الاعتماديات (Dependencies) ==========
    # هذا هو السحر!
    # شغل مهمة السحب، ثم التحويل، ثم التحميل
    extract_task >> transform_task >> load_task

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

كيف تغيرت حياتنا بعد تبني هذه المنصات؟

التحول كان جذريًا. لم نعد رجال إطفاء، بل عدنا مهندسين. إليكم أبرز المكاسب:

الموثوقية وإعادة المحاولة التلقائية

أول وأهم مكسب. يمكننا الآن ضبط أي مهمة لتعيد المحاولة 3 مرات مع فاصل زمني 5 دقائق بين كل محاولة في حال فشلها. هذا حلّ 90% من المشاكل المؤقتة (مثل مشاكل الشبكة) دون أي تدخل بشري. نومنا أصبح أعمق!

المراقبة المركزية والتنبيهات

واجهة Airflow أصبحت صديقتنا الصدوقة. بلمحة واحدة، نعرف ما الذي يعمل، وما الذي فشل، وما الذي نجح. قمنا بربطها مع Slack، والآن يصلنا تنبيه فوري عند فشل أي مهمة حرجة، مع رابط مباشر للسجلات (logs) لتشخيص المشكلة بسرعة.

سهولة التطوير والتوسع

إضافة خطوة جديدة للعملية أصبحت مسألة إضافة دالة بايثون وسطر واحد لتعريف الاعتمادية. كل شيء موجود في Git، مما يعني أننا نستطيع مراجعة التغييرات (Code Review) والعودة للإصدارات السابقة بسهولة.

تحرير وقت المطورين للإبداع

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

نصائح من “أبو عمر” لبداية ناجحة

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

1. ابدأ ببساطة (Start Simple): لا تحاول أتمتة كل شيء في شركتك من اليوم الأول. اختر عملية واحدة يدوية، متكررة، ومؤلمة. قم بأتمتتها بنجاح. هذا النجاح الصغير سيعطيك الزخم والدعم من الإدارة للمشاريع الأكبر.
2. اجعل مهامك مستقلة وقابلة للتكرار (Idempotent): هذه نقطة تقنية مهمة جدًا. المهمة القابلة للتكرار هي التي إذا شغلتها 10 مرات بنفس المدخلات، ستعطي نفس النتيجة النهائية دون آثار جانبية. مثلاً، بدلاً من استخدام INSERT في قاعدة البيانات (الذي سيضيف 10 صفوف مكررة)، استخدم UPSERT (UPDATE or INSERT) الذي سيضيف الصف مرة واحدة ويقوم بتحديثه في المرات اللاحقة. هذا يجعل إعادة المحاولة آمنة.
3. استثمر في المراقبة والتنبيهات (Invest in Monitoring & Alerting): لا يكفي أن تقوم بالأتمتة. يجب أن تعرف فورًا عندما تسوء الأمور. اضبط التنبيهات للمهام الحرجة. لا تفترض أن كل شيء سيعمل بسلاسة دائمًا.
4. لا تخترع العجلة (Don’t Reinvent the Wheel): مجتمع Airflow ضخم. قبل أن تكتب كودًا للتعامل مع خدمة سحابية مثل Amazon S3 أو Google BigQuery، ابحث عن الـ Operator أو الـ Provider الجاهز. في معظم الأحيان، ستجد أن شخصًا آخر قد قام بالعمل الشاق نيابة عنك.

الخلاصة: من سباق مع الزمن إلى التحكم الكامل 🏁

رحلتنا من “جحيم العمليات اليدوية” إلى عالم الأتمتة المنظم مع منصات تنسيق المهام لم تكن مجرد ترقية تقنية، بل كانت تحولاً في ثقافة العمل. لقد استعدنا أثمن ما نملك: وقتنا وسلامنا العقلي. لم نعد نخشى يوم التقرير الشهري، بل أصبح مجرد حدث آخر يعمل بصمت في الخلفية بينما نركز نحن على ما يهم حقًا: حل المشكلات وبناء المستقبل.

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