عندما تقرر البيانات: استخدام المراقبة لدفع التوصيل التدريجي

لقد قمت للتو بدفع إصدار جديد من تطبيقك. يبدأ نشر الكناري (Canary) في توجيه 10 بالمائة من حركة المرور إلى المثيلات الجديدة. الجميع في الفريق يحدقون في لوحة القيادة. هل يعمل؟ هل يفشل؟ هل تستمر أم تسحب القابس؟

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

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

الإشارات الأربع المهمة أثناء الإصدار

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

معدل الخطأ

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

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

زمن الاستجابة

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

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

حركة المرور

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

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

التشبع

يقيس التشبع مدى امتلاء موارد الخادم لديك. يجب مراقبة وحدة المعالجة المركزية (CPU)، والذاكرة، وإدخال/إخراج القرص، واتصالات قاعدة البيانات. إذا استخدم الإصدار الجديد فجأة ضعف ذاكرة الإصدار القديم، فقد تنفد الموارد من خوادمك وتتعطل.

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

وضع الحدود قبل الإصدار

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

ضع أرقامًا محددة لكل مقياس. على سبيل المثال:

  • يجب أن يظل معدل الخطأ أقل من 0.5 بالمائة
  • يجب ألا يزيد متوسط زمن الاستجابة عن 20 بالمائة مقارنة بالإصدار القديم
  • يجب أن يظل استخدام وحدة المعالجة المركزية أقل من 80 بالمائة
  • يجب ألا يتجاوز استخدام الذاكرة 90 بالمائة من السعة المتاحة

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

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

اتخاذ القرارات بناءً على البيانات

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

إذا بقيت جميع المقاييس ضمن الحدود الآمنة لفترة مراقبة محددة - لنقل خمس دقائق من البيانات المستقرة - فانتقل إلى المرحلة التالية. قم بزيادة النسبة المئوية لحركة المرور من 10 بالمائة إلى 25 بالمائة، أو انقل المزيد من المستخدمين إلى الإصدار الجديد. ثم لاحظ مرة أخرى.

تتبع عملية اتخاذ القرار تدفقًا واضحًا بناءً على الإشارات الأربع وحدودها:

flowchart TD A[مراقبة الإشارات الأربع] --> B{الكل ضمن الحدود الآمنة؟} B -->|نعم| C[المتابعة إلى المرحلة التالية] B -->|لا| D{أي منها يتجاوز الحد الحرج؟} D -->|لا| E[إيقاف الإصدار مؤقتًا، التحقيق] D -->|نعم| F[التراجع فورًا] C --> G[زيادة نسبة حركة المرور] G --> A E --> A

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

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

أتمتة حلقة القرار

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

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

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

قائمة مراجعة عملية لإصدارك القادم

قبل تشغيل التوصيل التدريجي التالي، تأكد من توفر هذه العناصر:

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

الخلاصة

تحول المراقبة التوصيل التدريجي من لعبة تخمين إلى عملية تعتمد على البيانات. عندما يكون لديك مقاييس في الوقت الفعلي، وحدود واضحة، واتخاذ قرارات آلي، تتوقف عن سؤال "هل هذا الإصدار آمن؟" وتبدأ في سؤال "ماذا تقول البيانات؟" الإجابة تنتظر دائمًا في لوحات القيادة والسجلات الخاصة بك. الجزء الصعب هو إعداد النظام للاستماع.