دروس عملية
3 دقائق قراءة
قائمة تحقق عملية للتكامل
القائمة التي أستعرضها قبل تشغيل تكامل، مستخلصة من أنماط الفشل التي تظهر فعلاً في بيئة الإنتاج.
قوائم التحقق تعاني مشكلة سمعة. فهي مرتبطة بالامتثال لا بالحكم السليم. لكن القائمة القصيرة هي عمليًا ما يمنع شخصًا كفؤًا من نسيان تفصيل ممل في الحادية عشرة ليلًا.
هذه هي القائمة التي جمعتها للتكاملات، خصوصًا تلك التي تنقل أموالًا أو بيانات عملاء بين أنظمة صُممت كل واحدة على حدة.
قبل أن تصمّم أي شيء
تُحسم معظم مشكلات التكامل قبل كتابة أول سطر من الشيفرة. الأسئلة التي تستحق الإجابة مبكرًا تدور حول الملكية والتوقعات:
- أي نظام هو مصدر الحقيقة لكل حقل؟
- مَن يُسمح له بتغيير قيمة، ومَن يُبلَّغ عند تغيّرها؟
- ما الحجم الواقعي، وما الحجم في الذروة؟
- ما التأخير المقبول بين حدث وأثره اللاحق؟
- ما الذي يجب أن يحدث إذا تعطّل التكامل ساعة؟ ليوم كامل؟
إذا كان نظامان يظنان أنهما يملكان الحقل نفسه، فسوف يختلف التكامل مع نفسه في النهاية. الأفضل اكتشاف ذلك أثناء التصميم.
العقد
عقد الواجهة هو حيث تكمن معظم المخاطر العملية. أحتفظ بجدول قصير من الأسئلة لكل تكامل.
| الجانب | السؤال الذي يجب الإجابة عنه |
|---|---|
| المصادقة | كيف يعمل الاعتماد، ومتى تنتهي صلاحيته؟ |
| التكرارية | ماذا يحدث إذا وصل الطلب نفسه مرتين؟ |
| الوقت | أي منطقة زمنية، وأي تنسيق، ومَن يحوّل؟ |
| الترميز | هل UTF-8 مضمون للمحتويات وأسماء الملفات؟ |
| الأخطاء | هل استجابة الخطأ موثقة، أم حالة النجاح فقط؟ |
| حدود المعدل | ماذا يفعل العميل عند استجابة 429؟ |
| الترقيم | هل الترتيب مستقر بين الصفحات؟ |
| الحجم | ما أكبر ملف أو حمولة يمكن أن تصل؟ |
الجدول غير شامل. إنه دعوة للتوقف عن الافتراض.
قبل الإطلاق
الاختبارات التالية هي التي التقطت مشكلات حقيقية. ليست بديلًا عن حزمة اختبار مناسبة؛ إنها الحالات الحرجة التي تميل الحزم إلى تجاوزها.
- أرسل طلبًا مشوّهًا عن قصد. تأكد من أن الخطأ مفيد، وأنه لا يكشف تفاصيل حساسة.
- أعد تشغيل كتابة ناجحة. تأكد من أن النظام المتلقي لا ينشئ نسخة مكررة.
- شغّل ببيانات اعتماد منتهية. تأكد من أن الفشل واضح وقابل للاستعادة.
- اختبر حدّ التوقيت الصيفي. الطلب المُرسل الساعة 01:30 في يوم التغيير يجب ألا يقع في اليوم الخطأ.
- أرسل أكبر ملف واقعي. لا العينة، بل ذاك الذي يبلغ عشرة أضعاف ما توحي به المواصفات.
- تتبّع طلبًا واحدًا من البداية إلى النهاية. تأكد من أن الطرفين يسجّلان معرّف الارتباط نفسه.
- اكتب خطة التراجع قبل أن تحتاجها. اعرف كيف توقف التدفق، وما يحدث للبيانات التي في الطريق.
معرّف الارتباط يستحق أكثر من لوحة متابعة أثناء الحادثة الأولى. ينبغي أن يولّده المستدعي، ويُسجَّل على الطرفين، ويُدرَج في كل تذكرة دعم.
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بعد الإطلاق
اليوم الأول ليس نهاية المشروع. فترة قصيرة من الانتباه المتعمد تلتقط الأعطال التي لا تظهر إلا مع بيانات حقيقية:
- راقب معدل الأخطاء، لا معدل النجاح وحده.
- تأكد من أن إعادات المحاولة لا تُنشئ نسخًا مكررة بصمت.
- تحقق من تاريخ تدوير بيانات الاعتماد وضعه في مكان يراه الناس.
- اسأل فريق العمليات عمّا سيحتاجه إذا تعطّل هذا في الثانية صباحًا.
هذا السؤال الأخير هو الأكثر كشفًا عادةً.
القائمة ليست الهدف
قائمة التحقق وسيلة لجعل الافتراضات مرئية. المهارة الفعلية هي معرفة أي افتراض يهم أكثر في هذا التكامل، واختباره أولًا.
قائمة تُتَّبع بلا تفكير ليست أفضل من عدم وجود قائمة. أما قائمة قصيرة بما يكفي لتُستخدم، ومحددة بما يكفي لتكون مقلقة، فتستحق أن تُحفظ.
بقلم
مهند بكار
متخصص تقني ومفكّر أنظمة وبانٍ يعمل بيديه عبر البرمجيات والتكاملات والتسليم التقني.
المقال السابق
تشغيل نموذج محلي على عتاد متواضعالمقال التالي
التكاملات تفشل عند الأطرافمقالات ذات صلة
كل المقالاتالتكاملات تفشل عند الأطراف
المسار السعيد هو الجزء السهل. معظم مشكلات التكامل تكمن في الطوابع الزمنية وإعادة المحاولة والهوية والافتراضات حول مَن يملك البيانات.
تصميم المزامنة دون اتصال في Basket
قبو متجر بقالة مكان سيئ للاعتماد على الشبكة. إليك كيف يتشكّل طابور المزامنة دون اتصال في Basket، وأين تكمن القرارات الصعبة.
ما علّمني إياه المختبر المنزلي عن DNS
حين يسقط خادم التحليل، يسقط كل شيء معه. كان الانقطاع من صنع يدي، وقد رسخ الدرس.