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

اختبار الجاهزية للإنتاج — 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. هذا الترتيب يمنع أخطاء متقطعة يصعب تتبعها.

مراجعة سريعة

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

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

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

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

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

خلاصة

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