اختبار التحقق من النشر

ما الذي يغطيه التحقق من النشر

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

من المفيد الفصل بين النشر (Deploying) والإصدار (Releasing). النشر يضع الكود الجديد على الخوادم؛ والإصدار يعرّض السلوك الجديد للمستخدمين. وتقنيات مثل إصدارات الكناري والتبديل الأزرق-الأخضر وأعلام الميزات موجودة للفصل بينهما، ليتمكن الفريق من التحقق من النشر بتعرّض قليل للمستخدمين أو دون تعرّض قبل الإصدار. وحزمة الدخان هي نفسها الموصوفة في دليل اختبار الدخان والسلامة والانحدار، موجّهة الآن إلى البيئة المنشورة للتو.

• فحص الإصدار — البيئة تقدّم الإصدار المقصود نشره، على كل مثيل (instance).
• الصحة والاعتماديات — الخدمات تعمل وتستطيع الوصول إلى قواعد بياناتها وطوابيرها وذاكراتها المؤقتة والأطراف الثالثة.
• المسارات الحرجة — تسجيل الدخول والمعاملة التجارية الرئيسية وواجهتها البرمجية تستجيب بشكل صحيح.
• الإعدادات والأمان — عناوين URL والشهادات وإعادات التوجيه وترويسات الأمان صحيحة؛ ولا وضع تصحيح مفعّل.
• السلوك تحت الحركة الحقيقية — الأخطاء وزمن الاستجابة ومقاييس العمل مماثلة للإصدار السابق.

حدّد معايير النجاح والتراجع قبل النشر

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

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

• الإطلاق والتحضير: كناري 5% ثم 25% ثم 100%، بخمس عشرة دقيقة لكل خطوة، والعلم new_checkout مطفأ عند النشر؛ ومهندس الإصدار ومختبِر مناوب مسمّيان في تذكرة الإصدار؛ وقبل النشر نسخة احتياطية مؤكدة وترحيل 0042 إضافي فقط (خطوة التوسيع). وتعمل حزمة الدخان بعد النشر على الكناري ثم على عنوان الإنتاج.
• إشارات النجاح، مقارنةً بخط الأساس عند كل خطوة: معدل HTTP 5xx لا يزيد على خط الأساس بأكثر من 0.5 نقطة مئوية؛ وزمن استجابة p95 لا يتجاوز 1.2 ضعف خط الأساس؛ ومعدل إتمام الشراء ضمن 10% من خط الأساس في النافذة الزمنية نفسها؛ ولا توقيعات أخطاء جديدة في السجلات.
• معايير التراجع، ويكفي أيٌّ منها للتراجع دون نقاش: إخفاق اختبار الدخان على الكناري أو الإنتاج؛ أو معدل 5xx فوق 2% لخمس دقائق متتالية؛ أو إخفاقات الدفع فوق ضعفي خط الأساس؛ أو تنبيه سلامة بيانات (طلبات مكررة أو مفقودة).
• التراجع والاكتمال: يُعاد نشر الصورة 5.8.3 ويبقى العلم new_checkout مطفأ ويُبقى على الترحيل 0042 لأنه إضافي؛ ويُعدّ التراجع مُتحقَّقاً منه حين ينجح smoke.sh وتُبلغ نقطة النهاية ⁦/version⁩ عن 5.8.3 على كل مثيل (instance). ولا يكتمل الإطلاق إلا بعد ساعة كاملة على 100% من الحركة وكل الإشارات خضراء.

Release verification plan: orders-service 5.9.0 (example)
Deployment:   canary 5% -> 25% -> 100%, 15 min per step; flag new_checkout OFF at deploy
People:       release engineer + tester on call (named in the release ticket)
Before:       backup confirmed; migration 0042 is additive only (expand step)

Post-deploy smoke:  smoke.sh against the canary, then against the production URL

Success signals, canary compared with baseline, at every step:
  - HTTP 5xx rate           <= baseline + 0.5 percentage points
  - p95 latency             <= baseline x 1.2
  - checkout conversion     within 10% of baseline (same window)
  - no new error signatures in the logs

Rollback criteria (any one => roll back, no debate):
  - smoke failure on canary or production
  - 5xx rate above 2% for 5 consecutive minutes
  - payment failures above baseline x 2
  - data integrity alert (duplicate or missing orders)

Rollback method:    redeploy image 5.8.3; new_checkout stays OFF; migration 0042 is kept (additive)
Rollback verified:  smoke.sh passes and /version reports 5.8.3 on every instance
Done when:          100% of traffic for 1 hour with all signals green

اختبارات الدخان بعد النشر

شغّل حزمة الدخان كآخر خطوة في مهمة النشر، على البيئة المنشورة للتو، واجعل خط الأنابيب يفشل إن فشلت. أبقِها قصيرة (بضع دقائق)، ومستقلة عن بيانات اختبار قد لا توجد في الإنتاج، وآمنة للتشغيل على الإنتاج: استدعاءات للقراءة فقط، أو كتابات بحساب اختبار مخصص تُستبعد بياناته من التقارير والفوترة. وافحص السلوك السلبي أيضاً — فنقطة النهاية المحمية التي تعيد فجأة 200 دون رمز عيبُ نشر.

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

• استهدف كل نسخة أو منطقة إن استطعت، لا موازن الحمل فقط — فنسخة واحدة قديمة عيب نشر جزئي كلاسيكي.
• تجاوز الذاكرات المؤقتة في فحص واحد على الأقل؛ فشبكة CDN قد تقدّم صفحة مخزّنة تبدو سليمة بينما يعيد الخادم الأصلي أخطاء.
• اجعل نقطة الصحة ذات معنى: ينبغي أن تُبلغ عن حالة الاعتماديات، لا أن تعيد 200 لمجرد أن العملية حية.
• افحص ترويسات الأمان وTLS وإعادات التوجيه بعد تغييرات البنية التحتية؛ فهي تُعدّ خارج الكود ويسهل فقدانها.

#!/usr/bin/env bash
# Example post-deployment smoke script. Usage: ./smoke.sh https://staging.example.com
set -euo pipefail
BASE_URL="$1"
EXPECTED_VERSION="${EXPECTED_VERSION:-}"

check() {  # name, path, expected HTTP status
  local name="$1" path="$2" expected="$3" status
  status=$(curl -s -o /dev/null -w '%{http_code}' --max-time 10 "$BASE_URL$path" || true)
  if [ "$status" != "$expected" ]; then
    echo "FAIL $name: $path returned $status, expected $expected"
    exit 1
  fi
  echo "ok   $name ($status)"
}

check "health"            "/health"                200
check "home page"         "/"                      200
check "product API"       "/api/v1/products/1001"  200
check "auth still needed" "/api/v1/orders"         401

# Only if the service exposes its version
if [ -n "$EXPECTED_VERSION" ]; then
  deployed=$(curl -s --max-time 10 "$BASE_URL/version" || true)
  if [ "$deployed" != "$EXPECTED_VERSION" ]; then
    echo "FAIL version: got $deployed, expected $EXPECTED_VERSION"
    exit 1
  fi
  echo "ok   version ($deployed)"
fi

جرّبها: فاحص صحة API جرّبها: مختبِر نقاط نهاية API جرّبها: محلّل ترويسات الأمان جرّبها: فاحص إعادة التوجيه

الفحوص الاصطناعية بعد النشر

اختبار الدخان يعمل مرة واحدة؛ أما المراقبة الاصطناعية (Synthetic monitoring) فتستمر في العمل. الفحوص الاصطناعية معاملات مكتوبة — تحميل الصفحة الرئيسية، وتسجيل الدخول بحساب مراقبة، والبحث، والإضافة إلى السلة، واستدعاء API أساسية — تُنفّذ وفق جدول من خارج النظام، كل بضع دقائق، مع تنبيهات عند الفشل أو البطء. وهي تلتقط مشكلات تظهر بعد مدة من النشر: تسرّب ذاكرة، أو شهادة تقترب من الانتهاء، أو مهمة مجدولة تكسر ذاكرة مؤقتة، أو طرف ثالث غيّر سلوكه.

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

جرّبها: مولّد تعابير cron جرّبها: شارح تعابير cron جرّبها: محلّل زمن الاستجابة

إصدارات الكناري والنشر الأزرق-الأخضر وأعلام الميزات

التسليم التدريجي (Progressive delivery) يعرّض التغيير لحصة متزايدة من الحركة، مع فحص عند كل خطوة. في إصدار الكناري (Canary release) يتلقى الإصدار الجديد أولاً حصة صغيرة من الحركة — بضعة في المئة، أو المستخدمين الداخليين — ويُقارن سلوكه بخط الأساس الذي يشغّل الإصدار القديم قبل زيادة الحصة. ويصف دليل SRE العملي من Google الكناري بأنه مقارنة مجموعة الكناري بمجموعة ضابطة، وهذه هي النقطة الأساسية للمختبِرين: قارن المتماثل بالمتماثل، في النافذة الزمنية نفسها، لا الكناري بأسطول الأمس كله.

النشر الأزرق-الأخضر (Blue-green deployment) يُبقي بيئتين متطابقتين؛ يُنشر الإصدار الجديد في الخاملة منهما، ويُتحقق منه هناك بحزمة الدخان، ثم تُحوَّل الحركة إليها، مع إبقاء البيئة القديمة جاهزة للعودة الفورية. وأعلام الميزات (Feature flags) تفصل الإصدار عن النشر داخل الكود: السلوك الجديد يُشحن مطفأً، ثم يُفعَّل للمستخدمين الداخليين، ثم لنسبة من العملاء، ويمكن إطفاؤه دون إعادة نشر.

• اختبر حالتي العلم، والانتقال بينهما للمستخدمين في منتصف مسار (سلة أُنشئت والعلم مطفأ، وأُتمّ شراؤها وهو مفعّل).
• تحقق من الاستهداف: العلم مفعّل تماماً للمستخدمين أو المناطق أو النسبة المقصودة، ومطفأ لكل من سواهم.
• شغّل حزمة الدخان على الكناري أو البيئة الخاملة مباشرة، قبل أن تصلها أي حركة حقيقية.
• أبقِ الإصدارين متوافقين أثناء الإطلاق: واجهات API وصيغ الرسائل ومخطط قاعدة البيانات يجب أن تعمل مع الكود القديم والجديد في آن واحد.
• أزل الأعلام بعد الإصدار الكامل؛ فالأعلام طويلة العمر تضاعف التوليفات التي يجب اختبارها.

جرّبها: مقارنة استجابات API

إشارات المراقبة التي تُتابع

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

• الأخطاء — معدل HTTP 5xx، والمهام الفاشلة، وأخطاء JavaScript في المتصفح، ورسائل خطأ جديدة لم تكن موجودة قبل النشر.
• زمن الاستجابة — p95 وp99 لنقاط النهاية الأساسية، لا المتوسط فقط؛ فالطلبات الناجحة البطيئة انحدار أيضاً.
• الحركة — الانخفاض المفاجئ قد يعني أن المستخدمين لا يصلون إلى ميزة؛ والارتفاع المفاجئ قد يعني عواصف إعادة المحاولة.
• التشبّع — المعالج والذاكرة ومجمّعات الاتصالات وعمق الطوابير؛ فالتسرّب البطيء يظهر هنا بعد ساعات من اختبار دخان نظيف.
• العمل — التسجيلات وعمليات الدخول والشراء والدفع والرسائل المرسلة، مقارنةً بالساعة نفسها في الأيام السابقة.
• صحة التسليم عبر الزمن — نسبة فشل التغييرات وزمن التعافي من النشر الفاشل، وهما من مقاييس DORA، يُظهران ما إذا كان التحقق من النشر والتراجع يعملان عبر إصدارات كثيرة.

جرّبها: محلّل زمن الاستجابة

التراجع والتحقق من الإصدار

التراجع (Rollback) نشرٌ بحد ذاته ويجب التحقق منه بالطريقة نفسها: شغّل حزمة الدخان مجدداً وتأكد أن نقطة الإصدار تُبلغ عن الإصدار السابق على كل مثيل. تدرّب على التراجع في staging لأي إصدار يغيّر البنية التحتية أو البيانات، وقِس زمنه — فالتراجع الذي يستغرق ساعة ليس شبكة أمان لعيب يكلّف مالاً كل دقيقة. وأحياناً يكون الإصلاح الأمامي (forward fix) أسرع وأكثر أماناً من التراجع؛ فقرّر أيهما ينطبق في الخطة لا أثناء الحادثة.

ترحيلات قاعدة البيانات هي أكثر ما يجعل التراجع صعباً. فبمجرد أن يحذف الترحيل عموداً أو يعيد تسمية جدول أو يعيد كتابة بيانات، قد لا يعود الإصدار السابق من الكود قادراً على العمل مع المخطط الجديد، وقد يُفقد عكسُ الترحيل بياناتٍ كُتبت منذ النشر. والتخفيف الشائع هو نهج التوسيع ثم التقليص (expand and contract): أضف أولاً البنى الجديدة بطريقة متوافقة مع السابق، وانشر كوداً يعمل مع كلتيهما، وانقل البيانات، ولا تُزِل البنى القديمة إلا في إصدار لاحق. أما اختبار الترحيلات — على نسخة بحجم الإنتاج، ومع الكود القديم مقابل المخطط الجديد، مع قياس الأقفال والمدة — فيغطيه دليل اختبار معاملات قاعدة البيانات وترحيلاتها.

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

عيوب نشر نموذجية

• الإنتاج يعيد 5.8.3 على نسختين من ست بعد نشر 5.9.0 (إطلاق جزئي).
• نقطة الصحة تعيد 200 بينما مجمّع اتصالات قاعدة البيانات مستنفد.
• اختبار الدخان ينجح على صفحة CDN مخزّنة بينما يعيد الخادم الأصلي 502.
• GET /api/v1/orders يعيد 200 دون رمز بعد تغيير إعدادات البوابة.
• ترويسة Strict-Transport-Security مفقودة على موازن الحمل الجديد.
• الكناري يُظهر ثلاثة أضعاف معدل 5xx في خط الأساس على POST /orders للمستخدمين ذوي البطاقات المحفوظة.
• العلم new_checkout المفعّل لـ 5% يعرض المسار الجديد أيضاً للزوار غير المسجلين.
• التراجع إلى 5.8.3 يفشل: الكود القديم لا يستطيع قراءة الطلبات ذات الحالة الجديدة PENDING_REVIEW.
• فحص تسجيل الدخول الاصطناعي يفشل منذ ستة أيام لأن كلمة مرور حساب الاختبار انتهت صلاحيتها.

قائمة تحقق للتحقق من النشر

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

الأسئلة الشائعة

المراجع

• Canarying Releases — The Site Reliability WorkbookGoogle / O'Reilly Mediaإطلاق التغيير لنسبة صغيرة من الحركة أولاً ومقارنته بخط الأساس قبل التعميم — التحقق من النشر كما يُمارس في هندسة موثوقية المواقع.
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016أهداف مستوى الخدمة وميزانيات الخطأ ومراقبة «الإشارات الذهبية الأربع» والتعامل مع الحمل الزائد — الجانب التشغيلي للمرونة.
• DORA's software delivery performance metricsDORA (Google Cloud)مقاييس DORA للتسليم — زمن تنفيذ التغيير وتكرار النشر وزمن التعافي من النشر الفاشل ونسبة فشل التغييرات وما يتصل بها — مجمّعة حسب الإنتاجية وعدم الاستقرار.
• Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018أنماط الاستقرار — المهل الزمنية وقواطع الدائرة والحواجز والضغط العكسي — وأنماط الفشل التي يُفترض أن يكشفها اختبار الحمل.
• Continuous Integration (Martin Fowler)martinfowler.com · 2024الوصف الأكثر استشهاداً للتكامل المستمر: ادمج كثيراً، واجعل البناء يختبر نفسه وسريعاً، وأصلح البناء المكسور فوراً.
• GitHub Actions documentationGitHubكيف تُعرَّف مسارات العمل والمهام والمشغّلات والمخرجات في GitHub Actions — حيث تعمل الاختبارات الآلية عند كل دفع أو طلب دمج.