تحديث وتدمير الموارد السحابية بأمان دون التأثير على الخدمات الأخرى

في البيئات الحديثة، لا تكمن الخطورة الحقيقية في إنشاء الموارد السحابية فقط، بل في تعديلها أو حذفها دون إسقاط مكونات أخرى مرتبطة بها. كثير من الأعطال الإنتاجية تحدث لأن فريقاً نفّذ destroy على مورد يبدو منفصلاً، بينما كان متصلاً بموازن حمل أو قاعدة بيانات أو مسار نشر تلقائي.

لهذا السبب، فإن جوهر العمل في ما هو DevOps؟ ولماذا تدفع الشركات ثروات لمهندسي الأتمتة السحابية؟ لا يتعلق بالسرعة فقط، بل بإدارة التغيير المحسوب. عندما تُدار البنية عبر IaC وخطوط CI/CD واضحة، يصبح تحديث الموارد أو إزالتها إجراءً يمكن التنبؤ به بدلاً من مغامرة تشغيلية.

فهم العلاقة بين الموارد قبل أي تحديث أو حذف

أكبر خطأ تشغيلي هو التعامل مع الخادم أو قاعدة البيانات كمورد مستقل. في الواقع، أغلب الموارد السحابية جزء من رسم بياني مترابط: شبكة، جدار حماية، موازن حمل، سجلات DNS، أسرار، تخزين دائم، ومراقبة.

قبل أي عملية تحديث أو تدمير، يجب تحديد ثلاثة محاور: من يعتمد على المورد، وما الذي يعتمد عليه المورد، وما الذي سيحدث إن اختفى فجأة. هذه القراءة تمنع حذف مورد مشترك تستخدمه خدمات متعددة داخل نفس VPC أو نفس بيئة الإنتاج.

أسئلة يجب الإجابة عنها قبل التنفيذ

• هل المورد مخصص لخدمة واحدة أم مشترك بين عدة خدمات؟
• هل توجد تبعيات خفية مثل Security Groups أو أقراص مرتبطة أو سجلات TLS؟
• هل العملية ستؤدي إلى replacement بدلاً من تحديث مباشر؟
• هل توجد خطة رجوع سريعة rollback؟

لا تنفذ أي حذف مباشر على مورد إنتاجي مشترك ما لم يكن موثقاً في خريطة تبعيات واضحة. كثير من كوارث Downtime تبدأ من افتراض خاطئ بأن المورد “غير مستخدم”.

استخدام Terraform لتحديث آمن ومدروس

عند إدارة البنية عبر البنية التحتية ككود (IaC): لماذا يجب أن نتخلى عن إنشاء السيرفرات يدوياً؟، يصبح القرار الصحيح مبنياً على معاينة التغيير قبل تنفيذه. لهذا يُعد فهم أوامر Terraform الأساسية المذهلة (Init, Plan, Apply, Destroy) خطوة محورية في تقليل المخاطر.

الأداة لا تحميك وحدها، لكن استخدامها بطريقة صحيحة يمنحك رؤية دقيقة لما إذا كان التغيير سيؤدي إلى إنشاء جديد أو تعديل أو حذف. كما أن إدارة حالة البنية التحتية (Terraform State) وكيف تحافظ عليها من الضياع أساسية لأن فقدان الحالة قد يدفع النظام لإعادة إنشاء موارد موجودة فعلاً.

ممارسات عملية داخل Terraform

• استخدم plan دائماً داخل بيئة مراجعة قبل apply.
• فعّل حماية الموارد الحرجة باستخدام prevent_destroy.
• افصل الوحدات المشتركة باستخدام استخدام الوحدات (Modules) في Terraform لتنظيم الكود وإعادة استخدامه.
• لا تضع قواعد البيانات، الشبكات، والتطبيقات المؤقتة في نفس ملف الحالة إن كانت دورات حياتها مختلفة.

terraform init
terraform plan -out=tfplan
terraform apply tfplan

# مثال مفاهيمي لحماية مورد حساس داخل Terraform
lifecycle:
  prevent_destroy: true
  create_before_destroy: true

الخيار create_before_destroy مهم عند استبدال خوادم أو موازنات حمل، لأنه يضمن إنشاء المورد البديل أولاً ثم إزالة القديم بعد نجاح الربط والتحقق الصحي.

التحديث بدون انقطاع عبر استراتيجيات النشر التدريجي

إذا كانت خدمتك تعمل داخل حاويات، فالتحديث الآمن يعتمد على طريقة توزيع النسخة الجديدة، لا على مجرد تشغيل صورة جديدة. من المفيد ربط هذا المفهوم بما تعلمته في ما هو الـ CI/CD؟ ولماذا نؤتمت عمليات اختبار ونشر الأكواد؟ ومشروع عملي: بناء CI/CD كامل يختبر وينشر تطبيق ويب إلى السيرفر آلياً.

في بيئات Kubernetes أو حتى مع Docker، يجب أن تكون هناك فحوصات صحة، وسعة إضافية مؤقتة، وإزالة تدريجية للنسخ القديمة. هذا هو الفارق بين تحديث احترافي وآخر يقطع الخدمة فوراً.

أنماط شائعة لتحديث آمن

• Rolling Update لتبديل النسخ تدريجياً.
• Blue/Green Deployment لعزل النسخة الجديدة بالكامل قبل تحويل المرور.
• Canary Release لاختبار نسبة صغيرة من المستخدمين أولاً.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

أي تحديث بدون health checks حقيقية هو رهان خطير. لا تعتبر الحاوية سليمة فقط لأنها بدأت، بل لأنها أصبحت جاهزة لاستقبال الطلبات والاتصال بقاعدة البيانات والعمل تحت الضغط.

التدمير الآمن للموارد: عزل، نقل، ثم حذف

التدمير الآمن ليس أمراً تنفيذياً أخيراً، بل عملية متعددة المراحل. قبل حذف خادم أو Pod أو قاعدة بيانات، يجب نقل الحمل عنه، وفصل الاتصالات، والتحقق من عدم وجود جلسات أو مهام خلفية نشطة.

في البنى القديمة، يفيد ما هو Ansible؟ وكيف تتحكم في 100 سيرفر Linux من حاسوبك المكتبي؟ في تنفيذ خطوات منظمة مثل إخراج الخادم من موازن الحمل، إيقاف الخدمات، أخذ نسخة احتياطية، ثم الحذف النهائي. ويمكن الاعتماد على المعالجات (Handlers): إعادة تشغيل الخدمات فقط عند حدوث تغيير في السيرفر لتجنب التأثير غير الضروري على بقية العقد.

تسلسل آمن قبل الحذف

1. تعطيل استقبال المرور على المورد المستهدف.
2. انتظار تفريغ الجلسات والطلبات الحالية.
3. أخذ نسخة احتياطية من البيانات والسجلات المهمة.
4. تحديث أنظمة المراقبة والتنبيه.
5. تنفيذ الحذف بعد التحقق من أن البديل يعمل فعلاً.

ansible-playbook drain-and-remove.yml --limit old-web-01

دمج الحماية داخل CI/CD لمنع الأخطاء البشرية

أفضل مكان لمنع التدمير الخاطئ هو خط الأنابيب نفسه. عند بناء مسار نشر باستخدام مقدمة في GitHub Actions: كتابة أول مسار عمل (Workflow) أو غيرها، اجعل الموافقات البشرية إلزامية لعمليات الإنتاج الحساسة، وخاصة أوامر destroy أو تغييرات الشبكات.

كما يُنصح بجعل خطوط النشر ترفض التغييرات غير المختبرة، تماماً كما في إنشاء خط أنابيب (Pipeline) يرفض الأكواد التي تفشل في الاختبارات. ويمكن إضافة إشعارات فورية عبر إرسال إشعارات فورية إلى Telegram أو Slack عند نجاح أو فشل نشر التحديثات حتى يعرف الفريق أن هناك عملية حذف أو استبدال قيد التنفيذ.

name: safe-infra-change

on:
  workflow_dispatch:

jobs:
  terraform-plan:
    runs-on: ubuntu-latest
    steps:
      - name: Run plan
        run: terraform plan

  manual-approval:
    needs: terraform-plan
    runs-on: ubuntu-latest
    steps:
      - name: Await approval
        run: echo "Production approval required"

أفضل ممارسات أمنية ومعمارية لا يجب تجاهلها

• افصل بيئات dev وstaging وproduction على مستوى الحالة والصلاحيات.
• طبّق أقل قدر ممكن من الامتيازات Least Privilege.
• احمِ الأسرار باستخدام إدارة الأسرار (GitHub Secrets) لحماية كلمات المرور ومفاتيح الـ API في الأتمتة.
• أتمتة الوصول الآمن للخوادم عبر إعداد الاتصال الآمن (SSH Keys) بدون كلمات مرور بين جهازك والخوادم.
• وثّق كل مورد مشترك داخل الشبكات وقواعد البيانات وموازنات الحمل.

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

خلاصة عملية

تحديث وتدمير الموارد السحابية بأمان يتطلب عقلاً معمارياً لا تنفيذياً فقط. افهم التبعيات، استخدم Terraform بمراجعة دقيقة، وانشر تدريجياً عبر CI/CD، ونفّذ التدمير بعد العزل والنسخ الاحتياطي والتحقق.

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