عندما تخبرك خمسة بالمائة من حركة المرور أكثر من بيئة الاختبار

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

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

هذه هي الفجوة التي تحاول استراتيجيات التوزيع التدريجي (Progressive Delivery) سدها. بدلاً من تشغيل المفتاح للجميع، تقوم أولاً بتعريض مجموعة فرعية صغيرة من المستخدمين أو حركة المرور للإصدار الجديد. تراقب ما يحدث. ثم تقرر ما إذا كنت ستستمر أم تتوقف أم تتراجع.

هناك استراتيجيتان شائعتان لهذا هما الإصدار التجريبي (Canary Releases) والنشر المرحلي (Staged Rollouts). تبدوان متشابهتين، لكنهما يحلان مشاكل مختلفة. يساعدك فهم الفرق في اختيار النهج الصحيح لكل تغيير تنشره.

الإصدار التجريبي (Canary Releases): دع حركة المرور تقرر

يبدأ الإصدار التجريبي بتوجيه نسبة صغيرة من حركة المرور إلى الإصدار الجديد. تخيل أن تطبيقك يتلقى مئة طلب في الثانية. تقوم بتكوين موازن التحميل (Load Balancer) أو شبكة الخدمات (Service Mesh) لإرسال خمسة من تلك الطلبات إلى الخوادم التي تعمل بالإصدار الجديد. أما الطلبات الخمسة والتسعون المتبقية فلا تزال تصل إلى الإصدار القديم.

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

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

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

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

النشر المرحلي (Staged Rollouts): اختر من يحصل عليه أولاً

يتبع النشر المرحلي نهجًا مختلفًا. بدلاً من تقسيم حركة المرور عشوائيًا، تقرر أي مجموعات المستخدمين تتلقى الإصدار الجديد أولاً. غالبًا ما تسمى هذه المجموعات حلقات (Rings).

قد تحتوي الحلقة الأولى على فريقك الداخلي وحفنة من مختبري النسخة التجريبية. يمكن أن تكون الحلقة الثانية نسبة مئوية من المستخدمين في منطقة معينة أو بنوع جهاز معين. قد تكون الحلقة الثالثة جميع مستخدمي الطبقة المجانية. يمكن أن تكون الحلقة الرابعة عملاء المؤسسات الذين لديهم اتفاقيات مستوى خدمة (SLA) صارمة.

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

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

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

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

الجمع بين كلتا الاستراتيجيتين

من الناحية العملية، الإصدارات التجريبية والنشر المرحلي ليسا حصريين. تجمع العديد من الفرق بينهما في خط أنابيب توزيع تدريجي واحد.

يوضح الرسم البياني أدناه الاستراتيجيتين جنبًا إلى جنب وكيف يمكن ربطهما معًا.

flowchart TD A[New Version Ready] --> B{Choose Strategy} B --> C[Canary Release] B --> D[Staged Rollout] C --> C1[Route 5% traffic] C1 --> C2{Healthy?} C2 -->|Yes| C3[Increase to 20%] C2 -->|No| C4[Rollback] C3 --> C5[Continue to 100%] D --> D1[Ring 1: Internal] D1 --> D2{Issues?} D2 -->|No| D3[Ring 2: Beta] D2 -->|Yes| D4[Rollback] D3 --> D5[Ring 3: All Users] C5 --> E[Combined Pipeline] D5 --> E E --> F[Canary 5% → Staged Rings → Full Release]

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

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

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

ما تحتاجه قبل أن تبدأ

استراتيجيات التوزيع التدريجي مفيدة فقط بقدر البيانات التي تستخدمها لاتخاذ القرارات. بدون مراقبة جيدة (Observability)، فإن الإصدار التجريبي هو مجرد طريقة أبطأ لتعطيل الإنتاج.

تحتاج إلى:

  • مراقبة معدل الخطأ في الوقت الفعلي، مقسمة حسب الإصدار
  • النسب المئوية لزمن الاستجابة للإصدار الجديد مقارنة بالإصدار القديم
  • مقاييس الأعمال التي تهم منتجك، مثل معدل التحويل أو إتمام التسجيل
  • طريقة لربط تقارير المستخدمين بالإصدار الذي يعملون عليه

تحتاج أيضًا إلى القدرة على التراجع بسرعة. إذا أظهر الإصدار التجريبي مشاكل، فيجب أن تكون قادرًا على سحب حركة المرور من الإصدار الجديد في ثوانٍ، وليس ساعات. يتطلب هذا بنية تحتية تدعم تحويل حركة المرور، مثل موازن التحميل، أو شبكة الخدمات، أو نظام أعلام الميزات (Feature Flag System).

قائمة مرجعية عملية سريعة

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

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

الخلاصة الملموسة

الإصدارات التجريبية والنشر المرحلي لا تتعلق بالحذر من أجل الحذر. إنها تتعلق بتعلم ما يفعله الإنتاج فعليًا بكودك قبل أن يصل إلى الجميع. تمنحك بيئة الاختبار الثقة في اختباراتك. يمنحك الإصدار التجريبي أو النشر المرحلي الثقة في الواقع.

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