بدلًا من «نأمل أن يعمل»
اعتمد git push origin main
الحاويات وخطوط CI/CD ومنصة Kubernetes والبنية التحتية ككود (IaC)، وقابلية المراقبة (Observability)، وأتمتة الإصدارات: كل ذلك من فريق واحد. ينفّذ المطوّر «git push»، فتجري عمليات التدقيق البرمجي (Lint)، والاختبار، والبناء، والفحص الأمني، ورفع الصورة، والنشر تلقائيًا خلال دقائق. وإذا حدث أي خلل، يتم التراجع خلال 18 ثانية. وكل ذلك وفق معايير DevOps الألمانية.
السبيل الوحيد كي لا يعود الإصدار «حدثًا» استثنائيًا هو الأتمتة المنضبطة. إذا كنت تريد التوقف عن المناوبات ليلة الجمعة، فأنت في المكان الصحيح.
إصدارات «نأمل أن تعمل» تُنهك فريقك
لنتحدث عن الأرقام بصراحة: الإصدار الفاشل لا يعني خسارة الإيرادات فحسب، بل خسارة الثقة داخل الفريق أيضًا. في ما يلي أكثر خمس مشكلات شيوعًا نراها.
إذا كان شخص ما يتصل بالخادم عبر SSH ويسحب الملفات ويعيد تشغيل الخدمات يدويًا، فإن ذلك الإصدار يستهلك نصف يوم العمل. وإذا أُغفلت خطوة، فلن يُكتشف ذلك إلا يوم الاثنين. أما النشر المقرر مساء الجمعة فيمتد إلى منتصف الليل، ومهندس DevOps الذي يُفترض أن يكون في إجازة تلك الليلة لا يكون كذلك في الواقع. وبنهاية الشهر تؤدي هذه الدوامة إلى الاحتراق الوظيفي، وبنهاية الربع السنوي إلى الاستقالات. الحل: دع خط CI/CD يضغط زر النشر، لا الإنسان.
عند ظهور خطأ بعد الإصدار، يستغرق أسلوب «git revert ثم إعادة النشر» ساعات لا دقائق. وخلال تلك الساعات تتعذر عمليات الدفع والتسجيل، ويغرق مركز الاتصال بالمكالمات. أما في خط CI/CD السليم فالتراجع مجرد زر: الصورة السابقة ما زالت في السجل (Registry)، ويُعاد Deployment في Kubernetes إلى المراجعة السابقة، وخلال 18 ثانية يعود كل شيء إلى ما كان عليه. فالتراجع لا يحتاج إلى «خطة»، بل إلى آلية.
من دون خط CI لا تُشغَّل الاختبارات، لأن الجملة المعتادة هي «نحن مستعجلون الآن». وكل خطأ صغير يظهر في بيئة الإنتاج يتراكم داخليًا لأن العميل لا يُبلَّغ به. وبعد فترة يتوقف المطوّرون عن كتابة الكود ويبدأون في الرد على طلبات الدعم. الحل: أن تعمل مع كل Commit تلقائيًا مجموعة الاختبارات الكاملة والتحليل الثابت وفحص الأنواع والفحص الأمني. والكود الذي لا يجتازها لا يُدمج في الفرع main أبدًا.
قبل 6 أشهر غيّر أحدهم إعدادات nginx على خادم الإنتاج. هذا الشخص لم يعد في الشركة، ولا أحد يتذكر ذلك التغيير. وعند إعداد خادم جديد لا يمكنك إعادة إنتاج السلوك نفسه. والحل هو البنية التحتية ككود (IaC): فمع Terraform وPulumi ومخططات Helm وملفات Kubernetes يصبح git موطن كل شيء. احذف الخادم وأعِد بناء نسخة مطابقة تمامًا منه خلال 8 دقائق.
عند الساعة 03:14 من يوم السبت توقف النظام. لا تنبيه عبر Slack بل عميل يقول صباح الاثنين «لا يفتح». تمضي 4 ساعات في العثور على السجلات و3 ساعات في فهم السبب. أما DevOps الحقيقي فيعني أن تنبيه Prometheus يوقظك عند الساعة 03:14 من يوم السبت، وأن لوحة Grafana تُظهر السبب بوضوح، وأن دليل التشغيل (Runbook) يُنفَّذ، فتُحل المشكلة خلال 12 دقيقة. وتبقى عطلة نهاية الأسبوع عطلة.
بيئة إنتاج تُصلح نفسها وتتحسن باستمرار
من الإصلاح الذاتي لوحدات Pod في Kubernetes إلى البنية التحتية ككود (Terraform)، ومن مقاييس DORA إلى التراجع بنقرة واحدة: نعرض أدناه كيف تبدو العمليات اليومية فعليًا.
> الوحدة web-7d4 جاهزة خلال 2.1 ثانية، والخدمة مستمرة
resource "aws_eks_cluster" "prod" {
name = "partnerfy-prod"
version = "1.29"
role_arn = aws_iam_role.eks.arn
vpc_config {
subnet_ids = aws_subnet.priv[*].id
}
}
Plan: 14 to add, 0 to change, 0 to destroy.
Apply complete! Resources: 14 added.
أربعة مؤشرات أساسية لصحة بيئة الإنتاج
الرجوع إلى المراجعة السابقة
kubectl rollout undo deployment/web
لأي الفرق يُحدث فارقًا حقيقيًا؟
على مدى سنوات بنينا منظومات DevOps في قطاعات مختلفة. وفي ما يلي ثمانية أنماط من الفرق التي تحقق أكبر قيمة من عملنا معها.
منصات SaaS ذات النشر اليومي
من طلب العميل إلى الفرع ثم المراجعة ثم الإنتاج خلال 30 دقيقة. ويجب أن تكون 5-15 إصدارًا في اليوم أمرًا معتادًا.
التجارة الإلكترونية مع اختبارات A/B متكررة
ترسل أعلام الميزات (Feature Flags) النسخة التجريبية إلى 5% من الزيارات، وتُقارَن المقاييس تلقائيًا، ويُفعَّل الخيار الفائز تلقائيًا.
شركات التقنية المالية الخاضعة للتنظيم
سلسلة موافقات، وسجل تدقيق، وعمليات بناء غير قابلة للتعديل، وفصل المهام. خط CI/CD جاهز لمعياري SOC2 وPCI معًا.
منصات B2B متعددة المستأجرين
بيئة لكل عميل، ونشر تدريجي، وأعلام ميزات حسب المستأجر، ومراقبة اتفاقية مستوى الخدمة (SLA) لكل عميل.
التسليم المستمر إلى TestFlight / Play
Fastlane وBitrise وأتمتة التوقيع. كل طلب سحب (PR) يُنتج تلقائيًا ملف IPA/AAB ويوزّعه على أجهزة الاختبار.
شركة ناشئة تنتقل من التطبيق الأحادي إلى الخدمات
نمط الخنق التدريجي (Strangler Fig)، وشبكة الخدمات (Istio/Linkerd)، وانتقال تدريجي. يعمل العالمان جنبًا إلى جنب.
شركات كبيرة تحدّث أنظمتها القديمة
ترحيل Active Directory إلى OIDC وJenkins القديم إلى GitOps وتحويل الأجهزة الافتراضية المحلية (On-Prem) إلى حاويات.
وكالة تدير أكثر من 20 مستودعًا
قوالب خطوط جاهزة، ومستودعات موحّدة (Repo-of-Repos)، وإدارة مركزية للأسرار. عميل جديد = إطلاق خلال ساعتين.
الطبقات العشر لمنظومة DevOps
نختار في كل طبقة الأداة الأنسب: فبدلًا من فرض تقنية بعينها، نوازن بين عادات فريقك الحالية والاستدامة على المدى الطويل.
التحويل إلى حاويات
يُوضع التطبيق في ملف Dockerfile ثم تُنتج عمليات البناء متعددة المراحل صورًا صغيرة الحجم تُرفع تلقائيًا إلى السجل (Registry). وتنتقل الصورة نفسها من بيئة التطوير إلى بيئة ما قبل الإنتاج (Staging) ثم بيئة الإنتاج.
خط CI
مع كل عملية Commit نشغّل تدقيق الكود، واختبارات الوحدة والتكامل، والتحليل الثابت، والفحص الأمني، وبناء الصورة. والكود الذي لا يجتازها لا يُدمج.
خط CD
وفق نهج GitOps تكون ملفات الإعداد في git مصدر الحقيقة الوحيد. يزامن ArgoCD باستمرار، وعند حدوث انحراف (Drift) يصححه فورًا أو يطلق تنبيهًا.
إعداد Kubernetes
خدمة مُدارة (EKS/GKE/AKS) أو استضافة ذاتية (k3s وkubeadm). ونصمم معًا حجم المجموعة (Cluster) ومجموعات العُقد والتوسع التلقائي وسياسات الشبكة.
مخططات Helm
يُحزَّم التطبيق في مخطط قابل للتخصيص بالمعاملات، ولكل من بيئتي Staging وProd ملفات قيم خاصة بها. والترقية إلى إصدار أحدث تتم بأمر واحد.
البنية التحتية ككود عبر Terraform / Pulumi
تُعرَّف الموارد السحابية (VPC وRDS وS3 وIAM) في صورة كود. دورة من التخطيط إلى المراجعة ثم التطبيق، مع حفظ الحالة (State) عن بُعد وقفلها، وكشف الانحراف.
إدارة الأسرار
تصبح ملفات env المعرّضة للتسريب من الماضي. تُشفَّر الأسرار عبر Vault أو SOPS ويجلبها خط CI/CD ديناميكيًا أثناء التشغيل، ولا يراها المطوّر أبدًا.
قابلية المراقبة (Observability)
المقاييس (Prometheus) والسجلات (Loki) والتتبعات (Tempo) ولوحات المتابعة (Grafana). مع تنبيهات قائمة على SLO ومتابعة ميزانية الأخطاء.
المناوبة والتنبيهات
أي تنبيه يوقظ من؟ مناوبات وتصعيد وتنبيهات مرتبطة بأدلة التشغيل (Runbooks). لا مزيد من إيقاظ الشخص الخطأ في الثالثة فجرًا.
الفحص الأمني
ثغرة CVE في الصورة؟ ثغرة حرجة في إحدى التبعيات؟ يوقف خط CI/CD عملية البناء ويقترح إصلاحًا تلقائيًا في طلب السحب (PR). إنه الأمن المبكر (Shift-Left).
من الخط القديم إلى خط CI/CD الحديث في ست خطوات
لا نغيّر البنية التحتية بأكملها بين ليلة وضحاها. بل نتقدم مرحلة بعد مرحلة، دون تعطيل أعمالك، وبمشاركة فريقك.
تدقيق الخط الحالي
دورة عمل (Sprint) مدتها أسبوعان: كيف تنشر اليوم، وأي خطوة يدوية، وأي خدمة تمثل نقطة فشل واحدة، وأين تُحفظ الأسرار.
تحويل التطبيقات إلى حاويات
تحصل كل خدمة على ملف Dockerfile ويُقلَّص حجمها عبر البناء متعدد المراحل، ثم تُرفع إلى السجل (Registry). الحزمة نفسها في بيئتي التطوير والإنتاج.
بناء خط CI
تتم أتمتة التدقيق والاختبار والبناء والفحص. عند فتح طلب سحب (Pull Request)، يعطي البوت نتيجة خضراء أو حمراء خلال 6-8 دقائق.
بناء خط CD
نعتمد GitOps عبر ArgoCD أو Flux بحيث يكون النشر إلى Staging تلقائيًا مع كل دمج، وإلى Prod بموافقة واحدة. والإطلاق التجريبي (Canary) والتراجع جاهزان.
ربط قابلية المراقبة
نربط Prometheus وGrafana وLoki ثم نكتب أهداف مستوى الخدمة (SLO)، ونربط قواعد التنبيه بأدلة التشغيل (Runbooks)، وننظم جدول المناوبات.
تدريب الفريق وتسليم العمل
ورشة عمل مدتها يومان، ووثائق، ومجموعة أدلة تشغيل (Runbooks). ثم دعم هادئ طوال 3 أشهر، مع الرد على أسئلتك خلال ساعة.
التقنيات التي نستخدمها في بيئة الإنتاج
قبل وبعد بالأرقام
الانتقال من Jenkins إلى GitHub Actions وArgoCD أوصل التغيير إلى الإنتاج خلال 12 دقيقة من لحظة الدمج، وأنهى الخوف من النشر مساء الجمعة.
Prometheus وPagerDuty وأتمتة أدلة التشغيل. يصل التنبيه قبل حدوث التوقف، إلى الشخص المناسب، ومعه خطوات الحل.
عمليات بناء غير قابلة للتعديل، وفصل المهام، ومسار تدقيق كامل، وأسرار مشفّرة. جاهزية للتدقيق خلال 6 أشهر، دون ملاحظة واحدة من المدقق.
التحديث المتدرج (Rolling Update) وفحوص الجاهزية والإطلاق التجريبي (Canary). لا انقطاع واحدًا لاحظه العملاء خلال 6 أشهر.
Fastlane وBitrise وأتمتة التوقيع. يرى فريق ضمان الجودة (QA) النسخة الجديدة على جهازه بعد 4 دقائق من كل طلب سحب.
سير عمل قابل لإعادة الاستخدام على GitHub Actions مع أداة CLI للتهيئة. يفتح العميل الجديد مستودعًا فيتم الإطلاق خلال ساعتين.
الأسئلة الأكثر طرحًا
الإجابة المختصرة: لا. إذا كان حجم أعمالك صغيرًا (من 1 إلى 3 خوادم في منطقة واحدة، وأقل من 20,000 طلب في الدقيقة)، فإن خيارات مثل Docker Compose وAWS ECS Fargate وGCP Cloud Run وFly.io وRender تفرض عبئًا تشغيليًا أقل بكثير. وتظهر القيمة الحقيقية لمنصة Kubernetes عند الحاجة إلى أكثر من 5 خدمات، ومناطق متعددة، وتوسع تلقائي، واستراتيجيات نشر متقدمة (Canary/Blue-Green)، وشبكة بين الخدمات. ويُتخذ القرار معًا في اجتماع التدقيق، ولن نثقل عليك بدعوى «مواكبة الموضة». وإذا تقرر الانتقال إلى K8s فنوصي بخدمة مُدارة (EKS/GKE/AKS)، فلا تضطر إلى إدارة مجموعتك (Cluster) بنفسك.
في الغالب لا، على الأقل ليس فورًا. إذا كان Jenkins يعمل، فإننا ننشئ الخط الجديد بالتوازي (GitHub Actions / GitLab CI / Drone). تمر الخدمات الجديدة عبر الخط الجديد، وتبقى الخدمات القديمة على Jenkins كما هي. ويعمل الاثنان معًا لمدة 2-3 أشهر، وبعد أن يعتاد الفريق تكتمل عملية الترحيل. أما نهج «تخلّص من كل شيء وأعِد الكتابة من الصفر» فيستغرق 6 أشهر ويترك كل شيء نصف مكتمل. وخبرتنا تقول إن استراتيجية Strangler Fig تعطي دائمًا نتائج أفضل. وإذا كان Jenkins غير قابل للصيانة فعلًا (إصدار قديم، وتضخم في الإضافات، ولا أحد يفهمه)، فسنخبرك بذلك بصراحة.
الجدول الزمني المعتاد: CI/CD الأساسي (الحاويات والاختبار والبناء والنشر) من 2 إلى 4 أسابيع. وإضافة Helm وKubernetes من 2 إلى 4 أسابيع إضافية. وقابلية المراقبة الكاملة (Prometheus وGrafana وLoki والتنبيهات) من 2 إلى 3 أسابيع إضافية. وإدارة السحابة عبر Terraform/IaC من 3 إلى 6 أسابيع إضافية (بحسب الموارد الحالية). الإجمالي: 4 أسابيع للفريق الصغير، و8-10 أسابيع للفريق المتوسط، و12-16 أسبوعًا للشركات الكبيرة. والأهم أن العمل يتقدم مرحلة بعد مرحلة دون تعطيل أعمالك. فأنت تستفيد فور انتهاء المرحلة الأولى، وكل مرحلة لاحقة تضيف قيمة. ولا ننتظر لحظة واحدة يكون فيها «كل شيء جاهزًا».
نعم، ونعدّ ذلك جزءًا من العمل. عند اكتمال الإعداد نقدّم: (1) توثيقًا كاملًا للخط (بصيغة Markdown)، و(2) ورشة عمل مباشرة لمدة يومين، و(3) فترة مرافقة مدتها 30 يومًا: نراقب من الخلف، ويتصدر الفريق المشهد، ونجيب عن الأسئلة. في الواقع لا يتغير الكثير في يوم المطوّر: ينفّذ git push فيعمل الخط. فالتعقيد كله مخفي في جانب البنية التحتية. أما الجانب التشغيلي (معالجة التنبيهات، وأدلة التشغيل، والتراجع) فننظم له جدول مناوبات. وبعد 3 أشهر يصبح فريقك ناضجًا بما يكفي لتولي الخط بنفسه.
هناك بندان: (أ) الإعداد من جانبنا مع خدمة تسليم لمدة 3 أشهر: يُحدَّد السعر حسب المشروع، ويكون في الفئة الدنيا من الأرقام الأربعة للمشروع الصغير، وفي الفئة المتوسطة من الأرقام الخمسة للمشروع المؤسسي (باليورو أو الدولار الأمريكي، وبسعر ثابت). (ب) تكلفة البنية التحتية المستمرة: تدفعها من حسابك السحابي مباشرة، فنحن لسنا وسيطًا. الأرقام المعتادة للسحابة: 200-600 يورو شهريًا لمنصة SaaS صغيرة، و1,500-4,000 يورو للمتوسطة، وأكثر من 8,000 للمؤسسية. ملاحظة مهمة: يوفّر التصميم الصحيح 30-50% من تكلفة السحابة (ضبط حجم الموارد والتوسع التلقائي ونسخ Spot). وعادةً ما يغطي الاستثمار في DevOps تكلفته خلال ستة أشهر.
نعم. لدينا خبرة إنتاجية فعلية مع AWS وGCP وAzure وHetzner وDigitalOcean جميعًا. يوفّر Terraform/Pulumi تجريدًا مستقلًا عن المزوّد، وتعمل ملفات Kubernetes على أي مجموعة (Cluster). وكثيرًا ما لا يكون تعدد السحابات ما تحتاجه فعلًا (إذ يزيد التعقيد التشغيلي 2.5 مرة)، لذا نوصي عادةً بسحابة أساسية واحدة مع منطقة مختلفة (Multi-Region) ومزوّد ثانٍ للتعافي من الكوارث. وإذا تطلّب الأمر تعددًا حقيقيًا للسحابات (مثل بيانات الاتحاد الأوروبي على AWS وبيانات الولايات المتحدة على GCP)، فإننا ننفذه أيضًا. ويُعد اختيار المنطقة بسبب سيادة البيانات (GDPR/KVKK) موضوعًا نواجهه كثيرًا.
نعم. أنشأنا خطوط CI/CD متوافقة مع ISO 27001 وSOC2 Type II وPCI DSS وGDPR وقانون حماية البيانات الشخصية التركي رقم 6698 (KVKK). وما ننفذه يشمل: عمليات بناء غير قابلة للتعديل (لا يمكن تغييرها لاحقًا)، وفصل المهام (من يكتب الكود لا يمكنه نشره)، ومسار تدقيق كامل (من وافق على ماذا ومتى)، وأسرارًا مشفّرة (Vault/SOPS)، وتشفير البيانات أثناء التخزين والنقل، ووصولًا إلى بيئة الإنتاج محميًا بالمصادقة متعددة العوامل (MFA)، وفحص الثغرات مع كل عملية بناء. والوثائق المطلوبة للمدقق متوفرة في قوالب جاهزة. ولدينا أكثر من 6 حالات وافق فيها مدققون مستقلون على خطوط أنشأناها، ويمكننا مشاركة المراجع.
إذا اكتُشفت مشكلة بعد الإصدار، فهناك طريقان. (1) التراجع عبر الأمر (Kubernetes rollout undo): تبقى المراجعة السابقة في سجل عمليات النشر (Deployment)، وبأمر واحد أو بزر في واجهة ArgoCD تعود الصورة القديمة إلى العمل خلال ثوانٍ لا دقائق. والمدة المعتادة من 12 إلى 25 ثانية. (2) إذا كانت هناك عملية ترحيل لقاعدة البيانات، فالأمر يتطلب حذرًا أكبر: أولًا الترحيل العكسي، ثم التراجع عن الحاوية. لذلك نصمم عمليات الترحيل دائمًا لتكون متوافقة مع الإصدارات السابقة (نمط من خطوتين مثل NULL allow ثم fill ثم NOT NULL). وقاعدة التراجع التلقائي هي أن انتهاك SLO أو ارتفاعًا مفاجئًا في معدل الأخطاء يوقف تلقائيًا النشر التدريجي عبر ArgoCD ويتراجع عنه عند الحاجة. والتدخل البشري اختياري.
لا تجعل الإصدار مصدر خوف بعد اليوم
لنقيّم معًا خطك الحالي في مكالمة مدتها 30 دقيقة: أين تكمن المكاسب، وأي الخطوات حرجة، ثم نضع خطة ملموسة لمدة 90 يومًا.