العميل خدمة لوجستية تتعامل مع عشرات الآلاف من الطلبات يومياً، وذروات مسائية وذروات خلال التخفيضات، واتفاقيات مستوى خدمة صارمة مع المتاجر الشريكة. نمت البنية التحتية بعشوائية: خوادم VPS متفرقة، وإعدادات محفوظة «على الخوادم»، ونشر يدوي وفق تعليمات في Wiki. كان كل إصدار يعني نشر النسخة ليلاً مع توقف الخدمة، وكل ذروة تنطوي على احتمال فقدان الطلبات. وكانت حادثة تخفيضات ما قبل رأس السنة، حين توقفت المنصة أربع ساعات واضطرت الخدمة إلى تعويض الشركاء، سبب التواصل معنا.
نقل المنصة إلى بنية تحتية قابلة للإدارة من دون إيقاف العمل:
البنية التحتية بوصفها شيفرة، وتسليم آلي، وحاويات وتنسيق، ومراقبة واضحة، واستعادة يمكن توقعها بعد الأعطال. وقد حدد المؤسس معيار النجاح: «النشر خلال ساعات العمل، بلا توقف، ومن دون شخص يملك وصول SSH».
اتبعنا تسلسلاً مجرباً: بدأنا بالحاويات والبيئات القابلة لإعادة الإنتاج، ثم أتمتة التسليم، وبعدها فقط انتقلنا إلى التنسيق والتوسع التلقائي.
- دققنا البنية التحتية: رسمنا الخدمات واعتمادياتها، وقسنا نمط الأحمال عند الذروة، وسجلنا العمليات اليدوية الأكثر تسبباً في الأعطال.
- حوّلنا الخدمات إلى حاويات: وحدنا عمليات البناء، ونقلنا الإعدادات من الشيفرة إلى متغيرات البيئة، وأنشأنا بيئات dev/stage/prod متطابقة.
- وصفنا البنية التحتية بالشيفرة باستخدام Terraform: تُنشأ البيئات من المستودع، ومُنع إجراء تغييرات يدوية في لوحة مزود السحابة.
- أنشأنا خط GitLab CI: تُنفذ الاختبارات وبناء الصور آلياً، ويُنشر الإصدار على stage فوراً، أما الإنتاج فيُنشر بزر بعد المراجعة، ويمكن التراجع عنه بإجراء واحد.
- نقلنا المنصة إلى Kubernetes مع التوسع التلقائي: تواجه المنصة الذروات المسائية وذروات التخفيضات بنسخ إضافية، لا بأعمال يدوية طارئة.
- أعددنا المراقبة والتنبيهات: مؤشرات الإشارة الأساسية، وهي زمن الاستجابة والأخطاء وحركة المرور والتشبع، مع مناوبة وتصعيد وفق جدول.
- أعددنا النسخ الاحتياطية والتعافي من الكوارث: وضعنا إجراءً للاستعادة، وأجرينا تدريباً على عطل في stage وقسنا MTTR الفعلي.
لم تكن قيمة المشروع الأهم في التقنيات، بل في نقل المسؤولية: لم تعد البنية التحتية تعتمد على «شخص يملك وصول SSH». كل نشر قابل لإعادة الإنتاج، وكل بيئة تُستعاد من الشيفرة، وكل عطل يظهر في لوحات المتابعة قبل أن يكتب أول عميل. وهذا ما يحول التوقف من كارثة إلى حادث روتيني له دليل إجراءات واضح ووقت استعادة قابل للقياس.
تكون العائد الاقتصادي من ثلاثة أجزاء: وفر مباشر في البنية التحتية قدره 32% بفضل التوسع التلقائي والاستغناء عن السعات «الاحتياطية للذروة» التي ظلت تعمل باستمرار؛ وتوفير ساعات الفريق التي كانت تذهب إلى عمليات النشر الليلية؛ والأهم، الحفاظ على الإيرادات خلال الذروات التي تمر الآن من دون حوادث. وقد جددت سلسلة متاجر كبيرة عقدها بعد أول موسم تخفيضات على البنية التحتية الجديدة.
| المؤشر | النتيجة |
|---|---|
| نشر إصدار | 3–4 ساعات يدوياً → 15 دقيقة آلياً |
| وتيرة الإصدارات | 2–3 شهرياً → شبه يومية |
| إتاحة المنصة | 97,8% → 99,95% |
| أحمال الذروة | خطر التوقف → توسع تلقائي من دون تدخل بشري |
نُقلت المؤشرات من المواد الأصلية للحالة. وتُذكر الفترة حيثما وردت في المصدر.
- نشر الإصدار (كان يستغرق 3–4 ساعات يدوياً)
- 15 دقيقة
- إتاحة المنصة (كانت 97.8%)
- 99.95%
- الاستعادة بعد الانقطاع (كانت تستغرق 2–4 ساعات)
- 20–30 دقيقة
- تكلفة البنية التحتية
- −32%
تُرسم الحدود العليا للنطاقات (4 ساعات، 30 دقيقة). مدة التوقف = 100% − الإتاحة.
- 01إيداع التغيير
- 02الاختبارات
- 03بناء الصورة
- 04بيئة Stageفوراً
- 05بيئة الإنتاجبزر بعد المراجعة
مجالات تطوير البنية التحتية في الدورة التالية:
- ممارسات FinOps: تنبيهات عند وجود إنفاق غير اعتيادي وشفافية التكاليف بحسب الفرق.
- نهج GitOps: تُوصف حالة الإنتاج في المستودع ولا تُجرى التغييرات إلا عبر pull request.
- Multi-region: نسخة مكررة من الخدمات الحرجة لتعزيز القدرة على الصمود أمام أعطال مزود الخدمة.
كان الإصدار يعني ليلةً وقهوةً ودعاءً. أما الآن فهو زر وخمس عشرة دقيقة. احتفلنا جميعاً بأول تخفيضات مرت بلا حوادث.
— المدير التقني للخدمة اللوجستية