ما يجب مراقبته بعد كل نشر: خمس إشارات تخبرك ما إذا كان الإصدار الجديد سليمًا
لقد نشرت للتو إصدارًا جديدًا. خط الأنابيب يقول "أخضر". الفريق يراقب لوحة القيادة. ولكن هل التطبيق يعمل بشكل جيد للمستخدمين بالفعل؟
بدون إشارات ملموسة، أنت تخمن. التخمين قد ينجح عندما تستخدم التطبيق وحدك. ولكن عندما يعتمد عليه آخرون، فأنت بحاجة إلى بيانات. تحتاج إلى معرفة، في غضون دقائق، ما إذا كان الإصدار الجديد سليمًا أم معطوبًا.
إليك خمس إشارات أساسية يجب على كل فريق مراقبتها بعد النشر. ابدأ بإشارة أو اثنتين، ثم أضف الباقي بمرور الوقت.
التوفر: هل يمكن للمستخدمين الوصول إلى التطبيق؟
السؤال الأساسي بعد النشر بسيط: هل التطبيق قابل للوصول؟ إذا كان الخادم معطلاً، أو التطبيق تعطل عند بدء التشغيل، أو المنفذ غير مفتوح، فإن التوفر ينخفض إلى الصفر.
عادةً ما تراقب الفرق ذلك من خلال نقطة نهاية فحص الصحة. هذا عنوان URL خاص يوفره التطبيق فقط للإجابة على "هل أنا على قيد الحياة؟". أدوات المراقبة تصل إلى نقطة النهاية هذه بانتظام. إذا توقفت عن الاستجابة، فهناك خطأ ما.
عادةً ما يُقاس التوفر كنسبة مئوية: 99% أو 99.9% أو 99.99% من وقت التشغيل المتوقع. كلما كان الهدف أعلى، قل تحملك للانقطاعات. هدف 99% يعني أنه يمكنك تحمل حوالي 7 ساعات من التوقف شهريًا. هدف 99.99% يعني حوالي 4 دقائق شهريًا.
للتحقق من التوفر فورًا بعد النشر، قم بتشغيل أمر curl بسيط ضد نقطة نهاية الصحة الخاصة بك:
curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"
العلامة -f تجعل curl يُرجع رمز خروج غير صفري إذا كان استجابة HTTP خطأ (4xx أو 5xx). رمز الخروج الصفري يعني أن نقطة النهاية قابلة للوصول وسليمة. يمكنك استخدام هذا في سكريبت النشر لاتخاذ قرار تلقائي بالمتابعة أو التراجع.
بعد النشر، تحقق من التوفر أولاً. إذا كان التطبيق غير قابل للوصول، فلا شيء آخر يهم.
معدل الأخطاء: كم عدد الطلبات التي تفشل؟
يمكن أن يكون التطبيق حيًا ولكنه معطوب. كل طلب يرد قد يفشل. يقيس معدل الأخطاء عدد الطلبات التي تنتهي برمز خطأ، مثل HTTP 500 أو انتهاء المهلة.
قبل النشر، يجب أن تعرف معدل الأخطاء الأساسي. ربما يكون 0.5% من جميع الطلبات. بعد النشر، إذا قفز هذا الرقم إلى 5%، فهناك شيء في الإصدار الجديد يسبب الفشل.
ارتفاعات معدل الأخطاء غالبًا ما تكون أول إنذار على أن شيئًا ما خطأ. من السهل اكتشافها وعادةً ما تشير إلى مشكلة حقيقية. الزيادة المفاجئة في الأخطاء يجب أن تؤدي إلى تحقيق فوري، وليس "دعنا ننتظر ونرى".
زمن الاستجابة: ما مدى سرعة استجابة التطبيق؟
المستخدمون لا يحبون الانتظار. إذا كانت الصفحة التي اعتادت التحميل في ثانية واحدة تستغرق الآن خمس ثوانٍ، سيغادر المستخدمون. يقيس زمن الاستجابة مدى سرعة استجابة التطبيق للطلبات.
يمكن أن يزيد زمن الاستجابة لأسباب عديدة. قد يكون الكود الجديد أبطأ. قد يكون تجمع اتصالات قاعدة البيانات ممتلئًا. قد يكون الخادم مثقلًا بحركة المرور. مهما كان السبب، فإن زمن الاستجابة الأعلى يضعف تجربة المستخدم بشكل مباشر.
تحتاج إلى معرفة نطاق زمن الاستجابة الطبيعي قبل النشر. بعد النشر، قارن الأرقام. إذا تضاعف متوسط وقت الاستجابة، فقد تغير شيء. حتى الزيادات الصغيرة في زمن الاستجابة يمكن أن تشير إلى مشاكل ستزداد سوءًا تحت الحمل الأعلى.
التشبع: ما مدى امتلاء مواردك؟
كل نظام له حدود. وحدة المعالجة المركزية، الذاكرة، مساحة القرص، اتصالات قاعدة البيانات، تجمعات الخيوط، عرض النطاق الترددي للشبكة—كلها لها سقف. يقيس التشبع مدى قربك من تلك الحدود.
بعد النشر، راقب استخدام الموارد. إذا ارتفع استخدام وحدة المعالجة المركزية من 40% إلى 90%، فإن الإصدار الجديد يستهلك موارد أكثر. قد يكون ذلك مقبولاً إذا كانت لديك سعة احتياطية. ولكن إذا زادت حركة المرور لاحقًا، ستصبح تلك الـ 90% 100%، وسيتباطأ التطبيق أو يتعطل.
يساعد التشبع أيضًا في تخطيط السعة. إذا كان الخادم باستمرار عند استخدام 80%، فربما تحتاج إلى إضافة خادم آخر قبل ذروة حركة المرور التالية. مراقبة التشبع بعد النشر تخبرك ما إذا كان الإصدار الجديد قد غير ملف الموارد الخاص بتطبيقك.
السجلات: ماذا حدث بالفعل في الداخل؟
ليس كل شيء يمكن التقاطه كرقم. عندما يرتفع معدل الأخطاء، تحتاج إلى معرفة السبب. هنا يأتي دور السجلات. السجلات هي سجلات للأحداث التي يكتبها التطبيق أثناء التشغيل.
السجلات الجيدة لها مستويات: info للعمليات العادية، warning للأحداث غير المعتادة ولكنها غير حرجة، error للفشل. كما أن لها سياق: طابع زمني، معرف الطلب، اسم الدالة، والبيانات ذات الصلة. بدون سياق، السجلات مجرد ضوضاء.
عندما يحدث خطأ ما بعد النشر، السجلات هي أول مكان تنظر إليه. هل ظهر استثناء معين؟ هل تسبب إدخال معين في تعطل؟ هل قاعدة البيانات لا تستجيب؟ السجلات تروي القصة التي لا تستطيع الأرقام وحدها روايتها.
ابدأ صغيرًا، وكن متسقًا
لست بحاجة إلى مراقبة جميع الإشارات الخمس من اليوم الأول. ابدأ بالتوفر ومعدل الأخطاء. هاتان ستلتقطان معظم المشاكل. أضف زمن الاستجابة عندما تحتاج إلى فهم الأداء. أضف التشبع عندما تبدأ في تخطيط السعة. أضف السجلات عندما تحتاج إلى تصحيح أخطاء أعمق.
المهم هو الاتساق. يجب قياس كل نشر بنفس الطريقة. استخدم نفس نقطة نهاية فحص الصحة. اجمع معدلات الأخطاء من نفس المصدر. قس زمن الاستجابة بنفس الأدوات. عندها فقط يمكنك مقارنة الإصدارات بصدق: هل الإصدار الجديد أفضل أم أسوأ من القديم؟
هذه الإشارات الخمس تمنحك بيانات بدلاً من المشاعر. البيانات تخبرك بما إذا كنت ستستمر أو تتراجع أو تحقق أكثر.
قائمة مراجعة سريعة لمراقبة ما بعد النشر
- نقطة نهاية فحص الصحة تستجيب
- معدل الأخطاء ليس أعلى بشكل ملحوظ من خط الأساس
- متوسط زمن الاستجابة ضمن النطاق الطبيعي
- استخدام وحدة المعالجة المركزية والذاكرة ومساحة القرص ليست قريبة من السعة
- السجلات لا تظهر أخطاء أو استثناءات غير متوقعة
ما التالي
هذه الإشارات تخبرك ما إذا كان التطبيق سليمًا، لكنها لا تخبرك ما إذا كانت الميزة الجديدة تعمل كما هو متوقع. يمكن أن يكون للإصدار توفر مثالي، ومعدل أخطاء منخفض، وزمن استجابة سريع، ومع ذلك يقدم نتيجة خاطئة. هنا يأتي دور التحقق.
ولكن قبل أن تصل إلى هناك، تأكد من أن هذه الإشارات الخمس في مكانها. بدونها، أنت تطير أعمى. معها، لديك أساس لمعرفة ما يحدث بعد كل نشر.