حالة واضحة لبيانات بداية الدوام

1. اتفق على البيانات المطلوبة وموعدها

المصدر هو النظام الذي يحتوي على الطلبات الأصلية. والنظام المستقبِل هو الذي تصله نسخة التقارير. كل تشغيل هو محاولة واحدة لنقل هذه البيانات.

البيانات

تشمل النسخة طلبات 2 أكتوبر 2026 فقط: من 00:00 في بدايته حتى ما قبل 00:00 يوم 3 أكتوبر. جميع الأوقات بتوقيت الرياض (UTC+3).

المواعيد

يجهز المصدر بحلول السادسة صباح 3 أكتوبر. يبدأ النقل عند السادسة فقط بعد تأكيد توفر الدفعات الثلاث. الموعد المطلوب لوصولها 06:10، والفحص عند 06:15. يحتاج الفريق النسخة عند السابعة.

المحتوى المتوقع

نسخة يومية مكتملة ومعتمدة: ثلاث مجموعات من الطلبات، نسمي كلًا منها دفعة، وستة أرقام طلبات مختلفة، بإجمالي 600 ريال. لا استبعاد ولا تغيير للبيانات. يعتمد مسؤول المصدر هذه القائمة بشكل مستقل عن سجل تشغيل النقل.

الأعمدة المطلوبة

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

المسؤوليات

المصدر: منسق العمليات. النقل والمعالجة: مسؤول البيانات. اعتماد الاستخدام: مسؤول التقارير. البديل: مسؤول الدعم. هذه أدوار للمثال وليست التزامات خدمة.

2. احتفظ بقائمة واضحة لما تتوقع وصوله

تاريخ كل طلب هو 2026-10-02. مجموع كل دفعة 200 ريال. الإجمالي: ستة طلبات بقيمة 600 ريال.

عند 06:15، قارن الإصدار نفسه ببيانات النظام المستقبِل. تأكد من تطابق رقم كل طلب ومبلغه، وعدم تكرار أي رقم، ووجود الدفعات الثلاث. ثم تحقق من أن العدد ستة والإجمالي 600 ريال. سجّل وقت جاهزية المصدر وانتهاء النقل والتحقق كلًا على حدة. تطابق العدد وحده قد يخفي طلبًا ناقصًا حل مكانه طلب مكرر.

راجع اليوم الذي تغطيه البيانات ووقت وصولها الفعلي. تاريخ تحميل جديد لنسخة تخص يومًا أقدم لا يكفي. وإذا غابت القائمة المتوقعة أو تعذر فحص النظام المستقبِل، فالجاهزية غير معروفة؛ غياب المعلومة لا يعني صفرًا.

3. حدد التصرف المناسب لكل حالة

هذه حالات بديلة للعملية نفسها، وليست أحداثًا متتابعة أو قياسًا لأداء خدمة.

سجّل المشكلة واليوم الذي تخصه البيانات، وما كان يجب أن يصل وما وصل فعلًا. وسجّل آخر نسخة تم التحقق منها، واسم المسؤول، وموعد الفحص التالي. عند 06:15، يبلغ مسؤول البيانات مسؤول التقارير بأي نقل لم يُعتمد بعد. إذا استمرت المشكلة عند 06:20، يشارك مسؤول الدعم في المتابعة، ويُحدد موعد إبلاغ الفريق بالمستجدات. يبلغ مسؤول التقارير الزملاء المتأثرين بأن نسخة 2 أكتوبر المطلوبة لم تجهز بعد. هذه أوقات افتراضية وليست وعود استجابة.

4. استكمل النسخة الناقصة دون تكرار الطلبات

1. احتفظ بما يوضح المشكلة. احفظ سجل التشغيل والنسخة ذات الطلبات الأربعة. أبقِ آخر يوم تم التأكد منه ظاهرًا بتاريخه؛ لا تستبدله بنتيجة جزئية.
2. تأكد مما يمكن إعادته. افحص النظام المستقبِل، واحتفظ بنسخة ثابتة من بيانات 2 أكتوبر التي اعتمدها مسؤول المصدر. راجع أعمدتها وأرقام الطلبات الستة. توقف إذا تغير المصدر، أو وجدت نسخة أحدث معتمدة، أو لم تكن طريقة منع التكرار واضحة.
3. جهّز البديل بشكل منفصل. بعد معالجة سبب تجاوز الدفعة، أعد تجهيز الطلبات الستة في مساحة منفصلة. يفترض المثال أن النظام يستطيع استبدال بيانات يوم كامل بخطوة واحدة، ومنع تكرار رقم الطلب ضمن اليوم نفسه. تأكد من توفر هذين الشرطين قبل المتابعة. وتأكد أن أي عملية أخرى لن تعدّل بيانات ذلك اليوم أثناء الاستبدال. إذا لم يتوفرا، توقف واتفق على معالجة تناسب النظام. لا تضف النسخة الجديدة إلى السجلات الموجودة.
4. افحص قبل الاستبدال. طابق الأرقام الستة ومبلغ كل طلب ومجموع كل دفعة وإجمالي 600 ريال مع نسخة المصدر الثابتة. بعد نجاح الفحوص، استبدل بيانات 2 أكتوبر فقط. احتفظ بالنسخة الناقصة ضمن سجل المشكلة، خارج النسخة التي يستخدمها الفريق.
5. تحقق بعد الاستبدال. عند 06:35، اقرأ النتيجة من النظام المستقبِل مجددًا: ستة طلبات بقيمة 600 ريال، والفترة والأعمدة والأرقام صحيحة. يعتمد مسؤول التقارير استخدامها. تظهر عبارة جاهزة بعد المعالجة · وصلت 06:32 · تم التحقق 06:35. يبقى التأخير الأصلي مسجلًا. قبل إغلاق متابعة المشكلة، سجّل اسم المسؤول وسبب النقص وما فعله لمعالجته، وأرفق ما يثبت نجاح الفحص.

إعادة النسخة اليومية نفسها وفق قاعدة الاستبدال تبقي النتيجة ستة طلبات بقيمة 600 ريال، لا اثني عشر طلبًا بقيمة 1,200 ريال. هذا شرط للمثال، وليس ضمانًا بأن إعادة التشغيل آمنة في كل نظام. والمصدر المتأخر يحتاج إلى الفحوص كلها بعد وصوله؛ ظهور الملف وحده لا يعني الجاهزية.

5. جرّب الحالات التي قد تعطي انطباعًا خاطئًا

• ستة صفوف وإجمالي 600 ريال، لكن رقم الطلب O-106 تغير إلى O-105 مع بقاء مبلغه 110 ريالات كما هو: لا تعتمد النسخة. الأرقام لا تتطابق وأحدها مكرر.
• الأرقام الستة صحيحة، لكن مبلغ O-106 أصبح 100 ريال: لا تعتمد النسخة. الإجمالي 590 ريال وهذا الطلب يختلف عن المصدر.
• البيانات تخص يومًا أقدم رغم وقت التحميل الجديد: لا تعتمد النسخة. وصولها الآن لا يغير الفترة التي تغطيها.
• عمود المبلغ ناقص أو صيغته تغيرت دون اعتماد: أوقف الاعتماد للمراجعة. لا تحذف الصفوف المتأثرة لمجرد إكمال التشغيل.
• العدد المتوقع غير متوفر أو تعذر فحص البيانات المنقولة: لم يتم التحقق. يوم بلا طلبات يحتاج إلى تأكيد صريح من مسؤول المصدر بأن العدد المتوقع صفر، مع فحص الفترة والبيانات في النظام المستقبِل كالمعتاد.

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

مراجع الطريقة: تفصل إرشادات Google Cloud حالة التشغيل عن المقاييس والسجلات. وتوضح إرشادات إعادة المحاولة من Microsoft أهمية نوع الخطأ وما قد يحدث عند تكرار الإجراء. لا يحدد أي منهما مواعيد المثال ولا يضمن استكمال النقل.