جودة الإنتاج والمراقبة

لماذا يهم

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

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

جودة الإنتاج كأهداف متفق عليها

عرّفك درس الإزاحة لليسار والإزاحة لليمين بالإشارات الذهبية الأربع. وللحكم على جودة الإنتاج حوّلها إلى أهداف. يستخدم كتاب «هندسة موثوقية المواقع» (Site Reliability Engineering, SRE) من Google ثلاثة مصطلحات: مؤشر مستوى الخدمة (SLI) مقياس معرَّف بدقة للخدمة كما يتلقاها المستخدمون، مثل نسبة طلبات الشراء التي تنجح خلال ثانيتين. وهدف مستوى الخدمة (SLO) هو القيمة المستهدفة لهذا المؤشر، مثل ⁦99.5%⁩ على مدى ⁦30⁩ يوماً. واتفاقية مستوى الخدمة (SLA) عقد مع العملاء يحدد عواقب عدم تحقيق الأهداف، مثل استرداد جزء من المبلغ.

ويحدد هدف مستوى الخدمة أيضاً ميزانية الخطأ (Error Budget): مقدار الإخفاق الذي يسمح به، أي ⁦100%⁩ ناقص الهدف. فعند ⁦99.5%⁩ ونحو ⁦200,000⁩ طلب شراء في الشهر، تبلغ الميزانية نحو ⁦1,000⁩ طلب فاشل أو بطيء. وفي النهج الذي يصفه كتاب SRE، يوقف الفريق الذي استنفد ميزانيته الإصدارات مؤقتاً ويستثمر في الموثوقية والاختبار، فيتحول سؤال «هل الإنتاج بخير؟» إلى رقم اتفق عليه الجميع.

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

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

خمسة أنواع من إشارات المراقبة

يقول كتاب SRE إن على المراقبة أن تجيب عن سؤالين: ما الذي تعطّل، ولماذا؟ ومراقبة الصندوق الأبيض (White-box) تعتمد على ما يسجّله النظام عن نفسه، ومراقبة الصندوق الأسود (Black-box) تختبر السلوك من الخارج كما يراه المستخدم. ويجيب كل نوع من الإشارات عن سؤال مختلف، وتعمل الأنواع معاً كسلسلة: العَرَض يُطلق التنبيه، والتفاصيل تقود إلى السبب.

• المقاييس (Metrics): أرقام عبر الزمن، مثل عدد الطلبات في الدقيقة ومعدل الأخطاء وزمن الاستجابة p95 (الزمن الذي تنتهي خلاله ⁦95%⁩ من الطلبات) وعدد الطلبات في الساعة. وحفظها شهوراً قليل التكلفة، وهي تُظهر الاتجاهات والتغيرات المفاجئة، لكنها لا تقول أي مستخدم تأثر ولا لماذا.
• السجلات (Logs): قيود مؤرَّخة بالوقت لأحداث مفردة. والسجلات المهيكلة، أي كائن JSON واحد في كل سطر بحقول مثل الوقت والمستوى والخدمة ونقطة النهاية (Route) ومعرّف الطلب، يمكن تصفيتها. اكتب الأوقات بتوقيت UTC، لتُقارَن أحداث الخوادم الموجودة في مناطق زمنية مختلفة. وكما توصي ورقة OWASP المرجعية للتسجيل (Logging Cheat Sheet)، لا تسجّل في السجلات كلمات المرور أو معرّفات الجلسات أو رموز الوصول أو بيانات البطاقات أو البيانات الشخصية الحساسة.
• مسارات الطلبات (Traces): الطريق الذي يقطعه طلب واحد عبر كل خدمة يمرّ بها، في صورة خطوات متداخلة موقوتة تُسمّى المقاطع (Spans). يُظهر المسار أين ذهب الوقت وأي استدعاء فشل. وتمرّر الخدمات معرّف المسار في ترويسة الطلب (يسمّيها معيار W3C Trace Context باسم traceparent)، وكتابة المعرّف نفسه في السجلات تربط بين الاثنين.
• التنبيهات (Alerts): قواعد تراقب الإشارات وتُبلغ شخصاً. والتنبيه العاجل الذي يصل إلى الشخص المناوب (On-call)، أي من يتولّى الرد على التنبيهات في تلك النوبة، يُسمّى استدعاءً (Page). استدعِ المناوب عند أعراض يشعر بها المستخدمون، مثل انخفاض مؤشر مستوى الخدمة، لا عند كل سبب محتمل؛ وكل استدعاء ينبغي أن يتطلب تصرفاً عاجلاً يحتاج إلى تفكير، وكثير من الفرق تربطه بدليل تشغيل (Runbook) يكتب خطوات التعامل معه. أما المشكلات الأقل إلحاحاً فتصبح تذاكر. وكثرة الاستدعاءات تعلّم الناس تجاهلها.
• الفحوص الاصطناعية (Synthetic Checks): رحلات مكتوبة تُشغَّل من خارج النظام كل بضع دقائق، مثل حساب مراقبة يسجّل الدخول ويبحث. تلتقط الأعطال في المسارات الهادئة وفي الليل، لكنها لا تغطي إلا ما كتبه أحدهم.

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

اختبر المراقبة أيضاً

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

• اجعل خدمة يعتمد عليها النظام تفشل، مثلاً ببديل (Stub) يُرجع الرمز ⁦503⁩، وتأكد أن الخطأ يظهر في المقاييس والسجلات ومسارات الطلبات تحت معرّف طلب واحد، وأن التنبيه يصل إلى شخص.
• اقرأ عيّنة من أسطر السجلات: بنية صحيحة، وأوقات بتوقيت UTC، وسياق كافٍ للتصرف، ولا بيانات شخصية أو سرية.

جرّبها: محاكي رموز حالة API جرّبها: مدقّق JSON Lines

الاختبار في الإنتاج بأمان

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

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

جرّبها: فاحص صحة API

مثال تطبيقي: تنبيه في خدمة الطلبات

لمتجر إلكتروني في الرياض (UTC+3) هدف مستوى خدمة لنقطة النهاية POST /orders: أن تنجح ⁦99.5%⁩ من الطلبات خلال ثانيتين على مدى ⁦30⁩ يوماً، أي ميزانية خطأ تقارب ⁦1,000⁩ إخفاق في الشهر. يُنشر الإصدار ⁦4.2⁩ الساعة ⁦10:20⁩، وفي الساعة ⁦10:31⁩ يستدعي التنبيه أدناه المطوّر المناوب، وينضم إليه المختبِر الذي اختبر الإصدار.

الفحص الاصطناعي لإتمام الشراء ما زال ناجحاً لأنه يدفع بالبطاقة. وعند تقسيم نسبة النجاح حسب طريقة الدفع يتبيّن أن مدفوعات المحفظة وحدها تفشل، وهي نحو ⁦30%⁩ من الطلبات. وتصفية السجلات حسب نقطة النهاية والمستوى تعطي السطر أدناه، ومعرّف مسار الطلب (Trace ID) فيه يفتح مساراً تنتظر فيه خدمة الدفع مزوّد المحفظة ⁦10⁩ ثوانٍ ثم تُنهي المحاولة.

• السبب: نسخ الإصدار إعداداً من بيئة Staging، فاستدعى الإنتاج خادماً للمحفظة لا يستطيع الوصول إليه. وقد كشف الحقل provider_host ذلك في سطر واحد.
• الإجراء: استُوفي أحد معايير التراجع في خطة الإصدار، فتراجع الفريق إلى الإصدار ⁦4.1⁩ الساعة ⁦10:52⁩، ولم يُغلق التنبيه إلا بعد عودة المؤشر إلى وضعه الطبيعي. فشل نحو ⁦90⁩ طلباً، أي قرابة عُشر ميزانية الخطأ الشهرية.
• ثغرات للمراجعة اللاحقة، وهي موضوع الدرس التالي: الفحص الاصطناعي يدفع بالبطاقة فقط، ولم يقارن شيء إعدادات الإنتاج بالقيم المتوقعة، ولم يراقب أي تنبيه نسبة النجاح لكل طريقة دفع.

ALERT 10:31 (UTC+3)  orders-api  page: developer on call
  POST /orders succeeded within 2 s: 72% over the last 10 min (SLO 99.5%)

Log line, pretty-printed (times in UTC):
{ "ts": "2026-10-04T07:29:12.418Z", "level": "error",
  "service": "payment-service", "route": "POST /orders",
  "trace_id": "7d2a91c4e0b54f3a9b18c6e2f4a05d71",
  "method": "wallet", "error": "provider_timeout",
  "elapsed_ms": 10001, "provider_host": "wallet.staging.internal" }

Trace 7d2a91c4...  total 10.05 s, failed
  api-gateway           POST /orders        10.05 s
    orders-service      create order        10.04 s
      payment-service   charge wallet       10.01 s   timeout
        wallet provider (no response)       10.00 s

جرّبها: محوّل الطوابع الزمنية

أسئلة شائعة

المراجع

• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016أهداف مستوى الخدمة وميزانيات الخطأ ومراقبة «الإشارات الذهبية الأربع» والتعامل مع الحمل الزائد — الجانب التشغيلي للمرونة.
• OWASP Cheat Sheet Series: LoggingOWASP Foundationما يُسجَّل وما لا يُسجَّل أبداً (كلمات المرور والرموز والبيانات الشخصية)، وكيف تُبقى السجلات قابلة لكشف العبث.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.