اختبار الجاهزية للإنتاج

اختبار الجاهزية للإنتاج — Production Readiness Quiz

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

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

ابدأ من هذا المثال البسيط: البرنامج يطبع حالة جاهزية بحقول ثابتة. في تطبيق حقيقي قد تستخدم log/slog أو نظام مراقبة، لكن الفكرة واحدة: السجل الجيد يحمل معلومة يمكن البحث عنها، لا جملة مبهمة فقط.

main.go

package main

import "fmt"

func main() {
    service := "api"
    status := "ready"
    port := 8080

    fmt.Printf("service=%s status=%s port=%d\n", service, status, port)
}

Output:

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

السؤال 1: ملخص Docker صحيح

اكتب ملخصاً يعكس صورة Go إنتاجية: build stage ثم runtime صغير.

تحدي — Challenge

package main

import "fmt"

func main() {
    // اطبع ملخص Docker الإنتاجي
}

المقصود هنا أن تفهم فكرة multi-stage build. مرحلة البناء تحتاج صورة Go وأدوات compile. مرحلة التشغيل لا تحتاج كل ذلك؛ تحتاج binary فقط وبيئة صغيرة. اختيار runtime صغير يقلل الحجم ومساحة الهجوم، لكنه يتطلب أن تفهم احتياجات برنامجك مثل الشهادات وملفات المنطقة الزمنية إن احتاجها.

السؤال 2: سجل منظم

استخدم slog لطباعة رسالة تحمل حقولاً مفيدة. في التطبيق الحقيقي هذه الحقول تساعدك عند البحث في السجلات.

تحدي — Challenge

package main

import "fmt"

func main() {
    service := "api"
    status := "ready"
    port := 8080

    // اطبع الحقول بالتنسيق المطلوب
    _ = service
    _ = status
    _ = port
}

في التحدي نطبع نصاً ثابتاً حتى يبقى الناتج مستقراً، لكن الدرس العملي هو structured logging. الحقول مثل service وstatus وport أفضل من جملة “server started” فقط. في الإنتاج ستحتاج أيضاً request id، مدة الطلب، status code، وربما user أو tenant بحسب الخصوصية والحاجة.

السؤال 3: ترتيب الإيقاف اللطيف

رتّب الخطوات ذهنياً ثم اطبعها. المهم أن لا تغلق قبل انتظار الطلبات النشطة.

تحدي — Challenge

package main

import "fmt"

func main() {
    steps := []string{
        // أكمل الخطوات هنا
    }

    for i, step := range steps {
        fmt.Printf("%d. %s\n", i+1, step)
    }
}

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

مراجعة المفاهيم

الجاهزية للإنتاج ليست ميزة تُضاف في النهاية، بل سلسلة قرارات صغيرة اتخذتها في كل فصل سابق. هذه الأسئلة تراجع تلك القرارات.

سؤال — Question

لماذا نستخدم بناء Docker متعدد المراحل لخدمة Go؟

لأن Go لا تعمل في صورة واحدة لتسريع الترجمة على جهاز المطور لأن الصورة النهائية تحمل الملف التنفيذي وحده — أصغر حجماً وأقل سطح هجوم لأنه يمنع تسريب متغيرات البيئة

سؤال — Question

ما الفائدة العملية للسجل المنظم (structured logging) مقارنة بـ fmt.Println؟

أنه أسرع في الكتابة على القرص أن كل سطر يصبح بيانات قابلة للتصفية والاستعلام حسب الحقول أنه يمنع تسرب المعلومات الحساسة تلقائياً أنه يقلل حجم ملف السجل دائماً

سؤال — Question

عند وصول إشارة إيقاف، ما الخطأ الأخطر في ترتيب الإيقاف اللطيف؟

إغلاق قاعدة البيانات قبل انتهاء الطلبات النشطة تسجيل رسالة قبل بدء الإيقاف انتظار الطلبات النشطة قبل إغلاق الموارد إيقاف استقبال الطلبات الجديدة أولاً

استرجع الآن التفاصيل التي تحتاجها وقت النشر فعلاً.

أكمل الفراغ — Fill in the blank

ما المسار المتعارف عليه لنقطة فحص صحة الخدمة التي يستدعيها المنسّق؟

أكمل الفراغ — Fill in the blank

ما الدالة التي تقرأ بها إعدادات الإنتاج والأسرار من متغيرات البيئة؟

الأسرار تُقرأ من البيئة وقت التشغيل، لا تُكتب في الكود. استخدم os.LookupEnv عندما تحتاج التمييز بين متغير غير موجود ومتغير قيمته فارغة — الفرق مهم عند التحقق من الإعدادات وقت الإقلاع.

مراجعة سريعة

قبل نشر خدمة Go، اسأل:

هل الاختبارات تعمل في CI؟
هل الصورة صغيرة ولا تعمل بصلاحيات زائدة؟
هل السجلات تحمل حقولاً قابلة للبحث؟
هل الإيقاف اللطيف موجود ومجرّب؟

أخطاء شائعة قبل الإنتاج

أول خطأ هو اعتبار نجاح go run محلياً دليلاً على الجاهزية. الإنتاج يحتاج build قابل للإعادة، إعدادات موثقة، ومراقبة. ثاني خطأ هو السجلات العاطفية مثل “something went wrong” بدون error أو context. ثالث خطأ هو استخدام Docker image ضخمة تعمل بصلاحيات root بلا حاجة. رابع خطأ هو إغلاق الخدمة فوراً عند الإشارة، فتفشل طلبات كانت على وشك الانتهاء.

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

خلاصة

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