استشارات DevOps وهندسة المنصات
DevOps أسلوب عمل تُدار فيه عمليات تطوير البرمجيات واختبارها ونقلها إلى بيئة الإنتاج بالأتمتة والمسؤولية المشتركة. نحدّد النطاق وفق احتياجاتكم: أحيانًا خط تسليم CI/CD (التكامل المستمر والتسليم المستمر) لتطبيق واحد، وأحيانًا منصة Kubernetes تتشاركها عدة فرق، إلى جانب أتمتة البنية التحتية والمراقبة. نعمل في السحابة، وفي مركز بياناتكم الخاص، وفي البيئات الهجينة.
- البيئات
- AWS وAzure وGoogle Cloud، ومزوّدو السحابة المحليون، ومركز البيانات، والبيئات الهجينة
- المنصات
- Kubernetes (EKS وAKS وGKE)، وOpenShift، وRancher
- نموذج العمل
- مشروع · استشارات مستمرة · خدمات مُدارة
- الخطوة الأولى
- الاجتماع التمهيدي المجاني أو التقييم المجاني
متى تبرز الحاجة إلى دعم DevOps؟
مع نمو فريق البرمجيات وتزايد عدد الأنظمة، ينبغي أن تنضج عملية التسليم معهما. نحدّد معًا نقطة البداية بناءً على وضعكم الحالي.
- عمليات الإصدار تعتمد على خطوات يدوية. أتمتة هذه الخطوات تتيح الإصدار بوتيرة أعلى وتجعل التراجع عن الإصدار قابلًا للتوقّع.
- البيئات تختلف بعضها عن بعض. بناء بيئتي الاختبار والإنتاج من التعريفات نفسها يقلّل الفروق غير المتوقعة.
- تستخدمون Kubernetes وعبء التشغيل يتزايد. تظهر الحاجة إلى ترقيات الإصدارات وتخطيط السعة ونمط تشغيل موحّد.
- تغييرات البنية التحتية تحتاج إلى توثيق. تتبّع من غيّر ماذا ومتى أمر مهم للتشغيل وللتدقيق على حدّ سواء.
- منظومة المراقبة والتنبيه تحتاج إلى مراجعة. جمع المقاييس والسجلات والتنبيهات في منظومة واحدة لرصد المشكلات قبل أن يلاحظها المستخدمون.
- الفرق تنفّذ أعمال بنية تحتية متشابهة كلٌّ على حدة. القوالب المشتركة والبيئات ذاتية الخدمة تقلّل العمل المتكرر وفترات الانتظار.
ما الذي يتغيّر مع العمل؟
الهدف ليس تثبيت أدوات، بل تحسين طريقة سير العمل اليومي لفريقكم. يلخّص الجدول نقاط البداية التي نصادفها كثيرًا والبنية المستهدفة.
مبادئ عملنا
- تُعرَّف البنية التحتية وخطوط التسليم (pipelines) والسياسات على شكل رمز.
- تخضع التغييرات للمراجعة ويُحتفظ بسجلّ لها.
- المنصة نفسها تُختبر وتُدار إصداراتها.
- يُقاس النجاح بمؤشرات التسليم، لا بعدد الأدوات المثبّتة.
- تُفضَّل الأدوات المفتوحة والقابلة للنقل حيثما أمكن.
| نقطة البداية | الوضع المستهدف |
|---|---|
| خطوات إصدار يدوية | خط آلي قابل للتكرار يعمل مع كل تغيير |
| تغييرات بنية تحتية تُجرى من لوحة التحكم | رمز بنية تحتية بإصدارات مُدارة وخاضع للمراجعة |
| خطوط تسليم مختلفة من فريق إلى آخر | قوالب مشتركة ومسار موصى به |
| بيئات تُنشأ عند الطلب | بيئات ذاتية الخدمة بقواعد محددة مسبقًا |
| سجلات وتنبيهات متفرقة | مراقبة في مكان واحد وتنبيهات ذات معنى |
| معرفة تشغيلية مرتبطة بأفراد | أدلة تشغيل (runbooks) وإجراءات موثّقة |
ماذا نقدّم في DevOps وهندسة المنصات؟
في مجال واحد أو من البداية إلى النهاية، بحسب احتياجاتكم.
منصة Kubernetes
التثبيت وترقية الإصدارات وإدارة العناقيد المتعددة وتخطيط السعة على EKS أو AKS أو GKE أو OpenShift أو Rancher أو في مركز بياناتكم.
خطوط CI/CD
خطوط تؤتمت البناء والاختبار والفحص الأمني والنشر، قائمة على قوالب مشتركة وقابلة للتكرار بين الفرق.
البنية التحتية كرمز (IaC) وGitOps
Terraform/OpenTofu لموارد البنية التحتية، وAnsible لإعداد الخوادم، وArgo CD أو Flux لنشر التطبيقات، وكل تغيير مسجّل في Git.
قابلية الرصد (Observability)
لوحات تجمع المقاييس والسجلات والتتبّعات في مكان واحد، مع تنبيهات ذات معنى وأهداف مستوى الخدمة (SLO).
منصة المطوّرين الداخلية
بنية ذاتية الخدمة تُنشئ فيها الفرق بيئاتها وخدماتها وخطوط تسليمها بنفسها ضمن قواعد محددة.
الحاويات
نقل التطبيقات إلى الحاويات وترحيلها إلى Kubernetes، بتخطيط يشمل جانبي البنية التحتية والرمز معًا.
ما هندسة المنصات، ومتى تحتاجون إليها؟
هندسة المنصات هي بناء منصة داخلية ذاتية الخدمة تتشاركها الفرق، كي تبقى ممارسات DevOps مستدامة مع ازدياد عدد الفرق. فبدلًا من إعادة بناء البنية التحتية، تستخدم الفرق مسارات المنصة الجاهزة والمعتمدة.
المسار الموصى به (golden path)
مسار جاهز ومعتمد لأي خدمة جديدة: القالب وخط التسليم والمراقبة والضوابط الأمنية مُضمّنة فيه منذ البداية.
الخدمة الذاتية
تُنشئ الفرق البيئات أو قواعد البيانات أو خطوط التسليم بنفسها، ضمن حدود محددة، من دون فتح طلبات.
القواعد داخل المنصة
تُدمج قواعد الأمن والتكلفة والامتثال في المنصة، فلا يضطر كل فريق إلى تطبيقها على حدة.
متى تحتاجون إليها؟
حين تنفّذ عدة فرق أعمال بنية تحتية متشابهة كلٌّ على حدة، تلزم منصة؛ أما للفريق الواحد فخط CI/CD جيد يكفي غالبًا.
التجربة الأولية أولًا، ثم التعميم.
نُدخل التغييرات على مراحل. تُحدَّد مخرجات كل مرحلة ومعايير نجاحها عند بدء العمل، وتتابعون التقدّم بالمعايير نفسها.
ماذا نقيس؟
المؤشرات الخمسة التي يعتمدها برنامج DORA البحثي لقياس أداء تسليم البرمجيات. نختار معًا ما سنتابعه منها بناءً على البيانات المتوفرة لديكم:
- تواتر النشر
- مدة وصول التغيير إلى الإنتاج
- نسبة التغييرات المسبّبة للأعطال
- مدة التعافي بعد نشر فاشل
- نسبة عمليات النشر التي تتطلّب إصلاحًا غير مخطط
الاستكشاف والتحليل
نراجع البنية الحالية وعملية الإصدار وهيكل الفريق والمخاطر.
المُخرَج: النتائج والأهدافالبنية المستهدفة وخارطة الطريق
نختار الأدوات والمنصات مع توثيق مبرّراتها، ونرتّب أولويات العمل.
المُخرَج: وثيقة البنية، خطة مرحليةالتجربة الأولية
نبني الحل من البداية إلى النهاية مع تطبيق واحد وفريق واحد، ثم نقيس ونحسّن.
المُخرَج: تجربة أولية عاملة وقياسات أولىالتعميم
ننقل البنية التي ثبتت صلاحيتها في التجربة الأولية إلى الخدمات والفرق الأخرى.
المُخرَج: خطوط التسليم والبيئاتالتسليم والتشغيل
ندرّب فريقكم ونسلّم أدلة التشغيل؛ وإن رغبتم نواصل تشغيلها معكم ضمن الخدمات المُدارة.
المُخرَج: التوثيق، فريق مدرَّبما تحصلون عليه في نهاية العمل على DevOps.
تُحدَّد المخرجات وفق نطاق العمل، وتُسلَّم موثّقة وقابلة للاستخدام من فريقكم، ضمن أدواتكم أنتم.
توثيق البنية
البنية المستهدفة وسجلات القرارات ومبرّراتها.
رمز البنية التحتية
رمز Terraform وAnsible، والوحدات، ودليل الاستخدام.
تعريفات CI/CD
خطوط التسليم والقوالب واستراتيجيات النشر.
لوحات المراقبة والتنبيهات
لوحات جاهزة وقواعد تنبيه وتعريفات SLO.
أدلة التشغيل
إجراءات الاستجابة للحوادث والنسخ الاحتياطي والتراجع والترقية.
التدريب ونقل المعرفة
جلسات تطبيقية لفريقكم مع تسجيلاتها.
نعمل مع استثماراتكم القائمة.
نبدأ بتقييم الأدوات المتوفرة لديكم، ولا نوصي بالتغيير إلا حين تكون له فائدة واضحة.
الحاويات وتنسيقها
- Kubernetes
- OpenShift
- Rancher
- Amazon EKS
- Azure AKS
- Google GKE
- Docker
- Helm
CI/CD وGitOps
- GitLab CI
- GitHub Actions
- Jenkins
- Azure DevOps
- Argo CD
- Flux
البنية التحتية كرمز (IaC)
- Terraform
- OpenTofu
- Ansible
- Packer
هندسة المنصات
- Backstage
- Crossplane
- HashiCorp Vault
قابلية الرصد
- Prometheus
- Grafana
- Loki
- OpenTelemetry
- Elastic / OpenSearch
السحابة والمحاكاة الافتراضية
- AWS
- Microsoft Azure
- Google Cloud
- مزوّدو السحابة المحليون
- VMware
- Proxmox
من أين تبدؤون بحسب حجم فريقكم؟
الشركات الصغيرة والمتوسطة والفرق الصغيرة
يبدأ العمل غالبًا بخط CI/CD لتطبيق واحد مع مراقبة أساسية ونسخ احتياطي، والهدف بنية بسيطة سهلة التشغيل.
فرق البرمجيات النامية
مع ازدياد عدد الفرق، جعل عملية الإصدار قابلة للتوسّع عبر القوالب المشتركة وKubernetes والبيئات ذاتية الخدمة.
فرق تقنية المعلومات في المؤسسات
دعم متخصص في مجال محدد إلى جانب فريقكم الحالي، وتصميم يراعي متطلبات التحديث والأنظمة التنظيمية.
لجعل الاجتماع الأول مثمرًا.
لا شيء من ذلك شرط مسبق؛ وكل ما يتوفر لديكم يجعل الحديث الأول أكثر تحديدًا.
ما يمكنك تحضيره إن توفّر
- مخططات البنية الحالية وقائمة البيئات
- وصف موجز لعملية الإصدار لديكم وأمثلة على انقطاعات حديثة
- هيكل الفريق: من المسؤول عن ماذا
- المتطلبات التنظيمية أو المتطلبات النابعة من العملاء
حول استشارات DevOps
المراجع والمعايير
- دليل مقاييس DORA (يُفتح في علامة تبويب جديدة)مؤشرات أداء تسليم البرمجيات
- توثيق Kubernetes (يُفتح في علامة تبويب جديدة)التوثيق الرسمي للمشروع
- توثيق OpenTofu (يُفتح في علامة تبويب جديدة)أداة مفتوحة المصدر للبنية التحتية كرمز
- توثيق Argo CD (يُفتح في علامة تبويب جديدة)التسليم المستمر باستخدام GitOps
- Google SRE: أهداف مستوى الخدمة (يُفتح في علامة تبويب جديدة)مفهوم SLO
لنحدّد احتياجاتك معًا.
في الاجتماع التمهيدي المجاني نناقش وضعك الحالي وأهدافك، ونشاركك انطباعاتنا الأولية والخطوات التالية الممكنة في الاجتماع نفسه.
- نقاش تقني مع مختصين في مجالك
- انطباعات أولية عن وضعك والأساليب الممكنة
- عند الملاءمة، خطوة تالية: التقييم أو مقترح مشروع أو استشارات
- اتفاقية عدم إفصاح قبل الاجتماع عند الحاجة
- الرد على الطلبات خلال 4 ساعات عمل
أمثلة DevOps من التطبيق العملي
نعرض بسيناريوهات توضيحية، خطوة بخطوة، كيف تعمل البنى التي نُنشئها في أغلب الأحيان.
خط CI/CD من الشيفرة إلى بيئة الإنتاج
ينتقل التغيير تلقائيًا وتحت السيطرة من طلب الدمج إلى بيئة الإنتاج. لكل خطوة معيار اجتياز، وإذا لم يتحقق يتوقف خط التسليم.
طلب الدمج
يصل التغيير على فرع منفصل، ويبدأ خط التسليم (CI/CD pipeline) تلقائيًا عند فتح طلب الدمج (merge request).
- $ git push origin feature/payment-limit
- Merge request !214 opened
- Pipeline #4821 started
البناء والاختبار
يُبنى التطبيق على شكل صورة حاوية (container image)، وتُشغَّل اختبارات الوحدات واختبارات التكامل.
- $ docker build -t registry.example.local/payments-api:1.9.0 .
- => naming to registry.example.local/payments-api:1.9.0
- $ pytest -q
- ✓ 214 passed in 38.2s
الفحص الأمني
تُفحص الصورة بحثًا عن الثغرات المعروفة، ويتوقف خط التسليم عند وجود أي نتيجة عالية أو حرجة الخطورة.
- $ trivy image --severity HIGH,CRITICAL --exit-code 1 payments-api:1.9.0
- Total: 0 (HIGH: 0, CRITICAL: 0)
- ✓ quality gate passed
النشر في بيئة الاختبار
يُكتب وسم الإصدار الجديد في مستودع الإعدادات، ويُزامن Argo CD بيئة الاختبار مع هذا التعريف.
- $ argocd app sync payments-api-staging
- Sync Status: Synced
- ✓ Health Status: Healthy
الإطلاق التدريجي في الإنتاج
بعد الموافقة، يُتاح الإصدار الجديد أولًا لحصة صغيرة من حركة المرور، وإذا بقيت المقاييس ضمن الهدف تُزاد الحصة.
- $ kubectl argo rollouts get rollout payments-api
- Step: 1/3 SetWeight: 10
- $ kubectl argo rollouts promote payments-api
- ✓ SetWeight: 100 Status: Healthy
المراقبة
يُتابَع معدل الأخطاء وزمن الاستجابة على لوحات المتابعة، وإذا تجاوز أحدهما الحد يصدر تنبيه ويمكن الرجوع إلى الإصدار السابق.
- PromQL: error rate (5 min)
- → 0.0021 (threshold 0.01)
- ✓ within service level objective
- GitLab CI
- Docker
- Trivy
- Argo CD
- Argo Rollouts
- Prometheus
إعداد البيئات باستخدام Terraform وAnsible
تُعرَّف البيئة الجديدة بالشيفرة، ثم تُراجَع، ثم تُبنى. يدير Terraform موارد البنية التحتية، ويدير Ansible الإعدادات داخل الخوادم.
التعريف
تُعرَّف الشبكة والأجهزة الافتراضية وموازن الأحمال بوحدات Terraform، وتُحفظ الفروق بين البيئات في ملفات المتغيرات.
- $ terraform fmt -check && terraform validate
- ✓ Success! The configuration is valid.
الخطة
يُخرج خط التسليم التغيير المزمع على شكل خطة (plan) ويُرفقها بطلب الدمج.
- $ terraform plan -out=tfplan
- Plan: 12 to add, 0 to change, 0 to destroy.
المراجعة
يراجع أحد أعضاء الفريق الخطة ويوافق عليها، وتبقى الموافقة مسجّلة.
- Merge request !87 · 1 approval
- ✓ review completed
التطبيق
تُطبَّق الخطة المعتمدة كما رُوجعت تمامًا، ويُحفظ ملف الحالة مقفلًا في مخزن بعيد.
- $ terraform apply tfplan
- ✓ Apply complete! Resources: 12 added, 0 changed, 0 destroyed.
إعداد الخوادم
تُضبط إعدادات نظام التشغيل والحزم والخدمات بالطريقة نفسها على جميع الخوادم باستخدام Ansible.
- $ ansible-playbook -i inventories/prod site.yml
- web-01 : ok=38 changed=6 unreachable=0 failed=0
- web-02 : ok=38 changed=6 unreachable=0 failed=0
فحص الانحراف
تقارن مهمة مجدولة البيئة بالشيفرة بانتظام لرصد التغييرات اليدوية.
- $ terraform plan -detailed-exitcode
- ✓ No changes. Your infrastructure matches the configuration.
- Terraform / OpenTofu
- Ansible
- GitLab CI
النشر على Kubernetes بأسلوب GitOps
يُعرَّف في Git كيف يعمل التطبيق داخل العنقود، ويُزامن Argo CD العنقود مع هذا التعريف. والتراجع يعني إلغاء التغيير في Git.
الحالة المطلوبة في Git
يُعرَّف الإصدار وعدد النسخ والإعدادات في مستودع الإعدادات.
- # values-prod.yaml
- image.tag: 1.9.0
- replicaCount: 3
رصد الفروق
يقارن Argo CD باستمرار حالة العنقود بالتعريف الموجود في المستودع ويُظهر الفرق.
- $ argocd app get payments-api-prod
- ! Sync Status: OutOfSync from main (a41c9e2)
المزامنة
يُطبَّق التغيير المعتمد على العنقود، ويستبدل Kubernetes النسخ القديمة بالجديدة تباعًا.
- $ argocd app sync payments-api-prod
- deployment.apps/payments-api configured
- ✓ Synced · Healthy
التراجع
إذا ظهرت مشكلة، يُلغى التغيير في Git ويُطبَّق التعريف السابق من جديد. ولا تتأثر البيانات بذلك، فلها خطة نسخ احتياطي مستقلة.
- $ git revert a41c9e2 && git push
- ✓ Synced to main (7be2d10)
سجل التدقيق
يبقى كل تغيير في سجل Git مع من أجراه ومتى ولماذا.
- $ git log --oneline -2
- 7be2d10 Revert "payments-api 1.9.0"
- a41c9e2 payments-api 1.9.0
- Argo CD
- Helm
- Kubernetes
- Git
المراقبة وأهداف مستوى الخدمة والتنبيهات
تستند التنبيهات إلى جودة الخدمة التي يلمسها المستخدمون، لا إلى مقاييس الخوادم. ولا يُبلَّغ المهندس المناوب إلا عندما يلزم التدخل فعلًا.
جمع البيانات
تُجمع مقاييس التطبيق وسجلاته وتتبّعات الطلبات بصيغة موحّدة باستخدام OpenTelemetry.
- $ kubectl get pods -n observability
- otel-collector-6d9f 1/1 Running
- prometheus-0 2/2 Running
هدف مستوى الخدمة
يُحدَّد هدف لمعدل النجاح الذي يراه المستخدمون، مثل نجاح 99.9% من الطلبات خلال 30 يومًا.
- SLO: successful requests ≥ 99.9% / 30 days
- error budget: 43 min 12 s
التنبيه
إذا بدأت ميزانية الأخطاء تنفد بسرعة، يُبلَّغ المهندس المناوب، أما التذبذبات القصيرة فلا تُطلق تنبيهات.
- ! ALERT ErrorBudgetBurn severity=page
- burn rate 14.4x (1 h) · 14.4x (5 min)
- → on-call engineer notified
التشخيص
تُفتح لوحات المتابعة والسجلات وتتبّعات الطلبات للفترة الزمنية نفسها، وتُتّبع خطوات دليل التشغيل (runbook).
- {app="payments-api"} |= "timeout"
- 12:04:31 upstream timeout: bank-service 3000ms
مراجعة ما بعد الحادثة
يُشارَك السبب الجذري والتحسينات الدائمة كتابيًا، وتُحدَّث التنبيهات ولوحات المتابعة عند الحاجة.
- Incident #23 · duration 18 min
- ✓ action: timeout and retry settings updated
- OpenTelemetry
- Prometheus
- Alertmanager
- Grafana
- Loki