تخطَّ إلى المحتوى
مهند بكار
المدونة

دروس عملية

3 دقائق قراءة

قائمة تحقق عملية للتكامل

القائمة التي أستعرضها قبل تشغيل تكامل، مستخلصة من أنماط الفشل التي تظهر فعلاً في بيئة الإنتاج.

قوائم التحقق تعاني مشكلة سمعة. فهي مرتبطة بالامتثال لا بالحكم السليم. لكن القائمة القصيرة هي عمليًا ما يمنع شخصًا كفؤًا من نسيان تفصيل ممل في الحادية عشرة ليلًا.

هذه هي القائمة التي جمعتها للتكاملات، خصوصًا تلك التي تنقل أموالًا أو بيانات عملاء بين أنظمة صُممت كل واحدة على حدة.

قبل أن تصمّم أي شيء

تُحسم معظم مشكلات التكامل قبل كتابة أول سطر من الشيفرة. الأسئلة التي تستحق الإجابة مبكرًا تدور حول الملكية والتوقعات:

  • أي نظام هو مصدر الحقيقة لكل حقل؟
  • مَن يُسمح له بتغيير قيمة، ومَن يُبلَّغ عند تغيّرها؟
  • ما الحجم الواقعي، وما الحجم في الذروة؟
  • ما التأخير المقبول بين حدث وأثره اللاحق؟
  • ما الذي يجب أن يحدث إذا تعطّل التكامل ساعة؟ ليوم كامل؟

إذا كان نظامان يظنان أنهما يملكان الحقل نفسه، فسوف يختلف التكامل مع نفسه في النهاية. الأفضل اكتشاف ذلك أثناء التصميم.

العقد

عقد الواجهة هو حيث تكمن معظم المخاطر العملية. أحتفظ بجدول قصير من الأسئلة لكل تكامل.

الجانبالسؤال الذي يجب الإجابة عنه
المصادقةكيف يعمل الاعتماد، ومتى تنتهي صلاحيته؟
التكراريةماذا يحدث إذا وصل الطلب نفسه مرتين؟
الوقتأي منطقة زمنية، وأي تنسيق، ومَن يحوّل؟
الترميزهل UTF-8 مضمون للمحتويات وأسماء الملفات؟
الأخطاءهل استجابة الخطأ موثقة، أم حالة النجاح فقط؟
حدود المعدلماذا يفعل العميل عند استجابة 429؟
الترقيمهل الترتيب مستقر بين الصفحات؟
الحجمما أكبر ملف أو حمولة يمكن أن تصل؟

الجدول غير شامل. إنه دعوة للتوقف عن الافتراض.

قبل الإطلاق

الاختبارات التالية هي التي التقطت مشكلات حقيقية. ليست بديلًا عن حزمة اختبار مناسبة؛ إنها الحالات الحرجة التي تميل الحزم إلى تجاوزها.

  1. أرسل طلبًا مشوّهًا عن قصد. تأكد من أن الخطأ مفيد، وأنه لا يكشف تفاصيل حساسة.
  2. أعد تشغيل كتابة ناجحة. تأكد من أن النظام المتلقي لا ينشئ نسخة مكررة.
  3. شغّل ببيانات اعتماد منتهية. تأكد من أن الفشل واضح وقابل للاستعادة.
  4. اختبر حدّ التوقيت الصيفي. الطلب المُرسل الساعة 01:30 في يوم التغيير يجب ألا يقع في اليوم الخطأ.
  5. أرسل أكبر ملف واقعي. لا العينة، بل ذاك الذي يبلغ عشرة أضعاف ما توحي به المواصفات.
  6. تتبّع طلبًا واحدًا من البداية إلى النهاية. تأكد من أن الطرفين يسجّلان معرّف الارتباط نفسه.
  7. اكتب خطة التراجع قبل أن تحتاجها. اعرف كيف توقف التدفق، وما يحدث للبيانات التي في الطريق.

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

curl -X POST https://api.example.com/v1/invoices \
  -H "Authorization: Bearer $TOKEN" \
  -H "Idempotency-Key: 01J9Z6W4K2" \
  -H "X-Correlation-Id: impl-2026-07-12-0007" \
  -H "Content-Type: application/json" \
  -d @invoice.json

بعد الإطلاق

اليوم الأول ليس نهاية المشروع. فترة قصيرة من الانتباه المتعمد تلتقط الأعطال التي لا تظهر إلا مع بيانات حقيقية:

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

هذا السؤال الأخير هو الأكثر كشفًا عادةً.

القائمة ليست الهدف

قائمة التحقق وسيلة لجعل الافتراضات مرئية. المهارة الفعلية هي معرفة أي افتراض يهم أكثر في هذا التكامل، واختباره أولًا.

قائمة تُتَّبع بلا تفكير ليست أفضل من عدم وجود قائمة. أما قائمة قصيرة بما يكفي لتُستخدم، ومحددة بما يكفي لتكون مقلقة، فتستحق أن تُحفظ.

بقلم

مهند بكار

متخصص تقني ومفكّر أنظمة وبانٍ يعمل بيديه عبر البرمجيات والتكاملات والتسليم التقني.

تواصل معي
https://mohannadbakkar.com