معمارية السحابة ومناطق الهبوط

استراتيجيات الهجرة إلى السحابة

18 دقيقة الدرس 9 من 28

استراتيجيات الهجرة إلى السحابة

الانتقال بأعباء عمل مؤسسية حقيقية إلى السحابة لم يكن يومًا مجرد رفع ونقل نظيف. الأنظمة الأكثر أهمية — نظام ERP الذي يلمس كشوف الرواتب، والمونوليث الذي يعمل منذ اثني عشر عامًا، وكتلة قواعد البيانات التي لن تسمح لك المالية بلمسها دون سلسلة موافقات — تصل جميعها بمستويات مخاطر مختلفة وبنى ملكية ومطامح تحديث متباينة. طوّرت AWS المصطلحات عام 2011 بالـ 5 Rs الأصلية، ثم وسّعتها Gartner وAWS لاحقًا إلى 7 Rs، وهي الآن التصنيف المعياري في الصناعة المستخدم في كل برنامج هجرة مؤسسي.

يعلمك هذا الدرس كيف تصنّف أعباء العمل وفق الـ 7 Rs، وكيف تنظّم العمل الفعلي في موجات الهجرة، وكيف تطبّق نمط التين الخانق لاستبدال الأنظمة القديمة تدريجيًا دون تحوّل مباغت يخاطر بالعمل كله.

الـ 7 Rs — تصنيف أعباء العمل

كل R هي استراتيجية هجرة. هدف مرحلة الاكتشاف هو تعيين كل عبء عمل مشمول لـ R واحدة بالضبط. يقود هذا التصنيف اختيارات الأدوات وتقديرات الجدول الزمني وهيكل الفريق وضوابط المخاطر.

التقاعد (Retire) — إيقاف التشغيل. نحو 10-20% من أسطول المؤسسة النموذجية يقع هنا: تطبيقات متكررة، وتقنية ظل، وأنظمة بلا مستخدمين نشطين. التقاعد قبل الهجرة هو أعلى نشاط بعائد على الاستثمار في أي برنامج. لا تُهاجر ما يمكنك حذفه.
الاحتفاظ (Retain) — ابقِ على البنية التحتية المحلية مؤقتًا مع تحديد موعد إعادة تقييم. ينطبق على الأنظمة ذات القيود التنظيمية، أو تراخيص البرمجيات المرتبطة بالعتاد، أو تلك التي تبقى أقل من 18 شهرًا قبل نهاية عمرها. الاحتفاظ ليس قرارًا دائمًا — ضع دورة مراجعة ربعية.
إعادة الاستضافة (Rehost) — "الرفع والنقل". نقل عبء العمل إلى السحابة دون تغييرات في الكود. أسرع مسار هجرة؛ يستخدم AWS MGN لنسخ الخوادم أو النهج القائم على اللقطات. يحقق توفيرًا فوريًا بنحو 30% من التحجيم الصحيح وحده. لا تحديث — الدين التقني ينتقل معه.
الانتقال (Relocate) — نقل طبقة المنصة لا الخادم فقط. يُستخدم كلاسيكيًا لأعباء العمل على VMware المحلي المُهاجَرة إلى VMware Cloud على AWS مع الحفاظ على بيئة المحاكاة الافتراضية الدقيقة وأدوات التشغيل. كثيرًا ما يكون خطوة انتقالية نحو إعادة المنصة أو إعادة البناء لاحقًا.
إعادة المنصة (Replatform) — "رفع وتعديل ونقل". الهجرة مع تحسينات مستهدفة لا تغير البنية الجوهرية. أمثلة: نقل MySQL المدار ذاتيًا إلى Amazon RDS، أو نقل تطبيق Java إلى Elastic Beanstalk، أو وضع التطبيق في حاويات دون إعادة كتابته. عادةً يحقق توفيرًا تشغيليًا 40-60% مقارنةً بإعادة الاستضافة.
إعادة الشراء (Repurchase) — الاستعاضة بمنتج SaaS. الانتقال من نظام CRM مستضاف ذاتيًا إلى Salesforce، أو من برمجيات HR محلية إلى Workday، أو من بريد إلكتروني مُدار ذاتيًا إلى Google Workspace. الهجرة هنا هجرة بيانات وتدريب مستخدمين في معظمها، لا هندسة بنية تحتية.
إعادة البناء / إعادة المعمارية (Refactor / Re-architect) — إعادة تصميم التطبيق ليكون أصيلًا في السحابة. تفكيك المونوليث إلى خدمات مصغّرة، والانتقال من مخزن علائقي إلى DynamoDB لنمط وصول عالي الإنتاجية، واعتماد المعمارية المدفوعة بالأحداث مع SQS/EventBridge. أعلى تكلفة ومخاطرة؛ أعلى قيمة أعمال على المدى البعيد. محجوزة لأعباء العمل التي تُعيق بنيتها الحالية النمو.

قاعدة 80/20 في الواقع العملي: في محفظة نموذجية من 200 تطبيق، توقّع تقريبًا: 15% تقاعد، 15% احتفاظ، 40% إعادة استضافة، 10% إعادة منصة، 5% إعادة شراء، 15% إعادة بناء. تتغير هذه النسب مع الانتقال من موجة الهجرة الأولى (كثيفة إعادة الاستضافة) نحو موجات التحديث (كثيفة إعادة البناء). تتبّعها في جدول تتبّع الهجرة مرتبط بعملية إصدار حسابات المنطقة المهبطية.

الاكتشاف — تعيين R المناسبة

لا يمكنك تصنيف ما لا تراه. أدوات الاكتشاف ترسم خريطة محفظة التطبيقات قبل انتقال أول عبء عمل. تقدّم AWS أداتين أوليتين لهذا الغرض:

AWS Application Discovery Service (ADS) — يعمل بوكلاء (aws-discovery-agent) أو بلا وكلاء (عبر vCenter API). يلتقط بيانات المعالج والذاكرة والقرص وتبعيات الشبكة على مدى 30+ يومًا. يُغذّي مباشرةً AWS Migration Hub.
AWS Migration Hub — مستوى التتبع المركزي. كل مهمة هجرة من MGN أو DMS أو Server Migration Service أو أداة شريك تُبلّغ حالتها هنا. استخدمه كنافذة واحدة لقيادة البرنامج.

# ── تفعيل Migration Hub في المنطقة الرئيسية (مرة واحدة لكل مؤسسة) ──────────
aws migrationhub-config create-home-region-control \
  --home-region us-east-1 \
  --target '{"Type":"ACCOUNT"}'

# ── التحقق من المنطقة الرئيسية الحالية ────────────────────────────────────────
aws migrationhub-config describe-home-region-controls \
  --query 'HomeRegionControls[0].HomeRegion'

# ── عرض جميع الخوادم المكتشفة في ADS ─────────────────────────────────────────
aws discovery describe-servers \
  --query 'servers[*].{ServerId:serverId,Hostname:serverInfo.agentNetworkInfoList[0].ipAddress,OS:osInfo.name,RAM:systemInfo.totalRamInMB}' \
  --output table

# ── تصدير بيانات التبعية للتحليل خارج الشبكة ─────────────────────────────────
EXPORT_ID=$(aws discovery start-export-task \
  --export-data-format "CSV" \
  --query 'exportId' --output text)
echo "Export started: $EXPORT_ID"
aws discovery describe-export-tasks --export-ids $EXPORT_ID \
  --query 'exportsInfo[0].{Status:exportStatus,S3Url:configurationsDownloadUrl}'

موجات الهجرة — تسلسل العمل

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

بنية الموجات الثلاث للهجرة: الأساسيات أولًا، ثم تطبيقات الأعمال، ثم التحويل النهائي للأنظمة الحيوية.

الموجة الأولى (التجريب): انقل بيئات التطوير والاختبار أولًا — لا تأثير إنتاجي على الإطلاق، وتعلّم فريقك كيف تعمل المنطقة المهبطية وأنماط الشبكة وIAM مع أعباء عمل حقيقية. تعلّم أخطاءك هنا، لا في الموجة الثالثة.

الموجة الثانية (تطبيقات الأعمال): انقل الأنظمة متوسطة الأولوية ذات الملاك الواضحين ومسارات التراجع المُختبرة. شغّل AWS Database Migration Service بالنسخ المستمر حتى تظل قاعدة البيانات المصدر حية أثناء الهجرة — مما يُتيح نافذة تراجع بالساعات لا الأيام.

الموجة الثالثة (الحيوي): انقل الأنظمة التي لا يمكن إيقافها دون تصعيد تنفيذي. بحلول الموجة الثالثة أجرى فريقك هذا العمل عشرات المرات. استخدم AWS MGN مع التحويل في وضع الاختبار، وتحقق من الحمل المكافئ للإنتاج، ثم اقلب DNS.

# ── AWS MGN: تهيئة النسخ لخادم مصدر ──────────────────────────────────────────
# (شغّل بعد تثبيت وكيل MGN على المضيف المصدر)
aws mgn initialize-service --region us-east-1

# ── وسم خادم لموجة هجرة محددة ────────────────────────────────────────────────
SERVER_ID="s-0a1b2c3d4e5f67890"
aws mgn tag-resource \
  --resource-arn "arn:aws:mgn:us-east-1:123456789012:source-server/$SERVER_ID" \
  --tags MigrationWave=wave-2,Application=crm,Strategy=rehost

# ── فحص تأخر النسخ قبل جدولة التحويل ────────────────────────────────────────
aws mgn describe-source-servers \
  --filters "replicationTypes=AGENT_BASED" \
  --query 'items[*].{ID:sourceServerID,State:dataReplicationInfo.dataReplicationState,Lag:dataReplicationInfo.lagDuration}' \
  --output table

# ── تشغيل نسخة اختبارية (بلا تأثير إنتاجي) ──────────────────────────────────
aws mgn start-test \
  --source-server-ids $SERVER_ID

# ── إنهاء الاختبار وبدء التحويل الفعلي ───────────────────────────────────────
aws mgn finish-test \
  --source-server-ids $SERVER_ID

aws mgn start-cutover \
  --source-server-ids $SERVER_ID

نمط التين الخانق

شجرة التين الخانق في الطبيعة تنمو حول شجرة قائمة وتحلّ تدريجيًا محلها حتى تُحاصر المضيف وتموت. أطلق مارتن فاولر اسم النمط البرمجي المقابل عام 2004، وهو يظل المقاربة السائدة لاستبدال المونوليث بأمان في وقت التشغيل — دون إعادة كتابة مباغتة تُشلّ التسليم 18 شهرًا وتفشل بانتظام.

الآلية: تُقيم نظامًا جديدًا جنبًا إلى جنب مع القديم، وتوجّه شريحة متنامية من الحركة إلى النظام الجديد قطعة قطعة، وتسحب مسار الكود القديم فقط عندما يُثبت المسار الجديد جدارته بالحركة الإنتاجية. المونوليث القديم لا يُعطى مرةً واحدة؛ بل يتوقف تدريجيًا عن استقبال الحركة حتى يمكن إيقافه بأمان.

نمط التين الخانق: الوكيل يعترض كل الحركة ويوجّه حصة متنامية إلى الخدمات الجديدة حتى يصبح المونوليث خاملًا ويمكن تقاعده.

الوكيل — عادةً API Gateway، أو Application Load Balancer بمجموعات هدف موزونة، أو شبكة خدمات مثل Istio — هو مستوى التحكم في عملية الخنق. يجعل الهجرة قابلة للتراجع في كل خطوة.

أعلام الميزات كمستوى تحكم في نمط الخانق: في Netflix وAmazon، لا يقتصر نمط الخانق على طبقة التوجيه — بل يُتحكم فيه أيضًا بأعلام الميزات (LaunchDarkly، AWS AppConfig). يمكن لعلم واحد توجيه 1% من المستخدمين إلى الخدمة الجديدة، ومراقبة معدلات الأخطاء، والتراجع في ثوانٍ دون لمس أوزان ALB. هذا أكثر أمانًا من التبديل على مستوى DNS للتدفقات عالية القيمة مثل الدفع.

هجرة قواعد البيانات — الجزء الأصعب

خوادم التطبيقات عديمة الحالة ويسهل استبدالها. قاعدة البيانات لا كذلك. أكثر أوضاع فشل الهجرة شيوعًا هو التحويل الفاشل لقاعدة البيانات الذي يفسد البيانات أو يضيعها. يحلّ AWS Database Migration Service هذا بالنسخ المستمر: يبثّ التغييرات من قاعدة البيانات المصدر إلى الهدف في الوقت شبه الحقيقي، بحيث يتأخر الهدف دائمًا بثوانٍ عن المصدر. حين تستعد للتحويل، تقلب سلسلة الاتصال ويصل التأخر إلى الصفر.

# ── إنشاء نسخة تكرار DMS ────────────────────────────────────────────────────
aws dms create-replication-instance \
  --replication-instance-identifier prod-migration-ri \
  --replication-instance-class dms.r6i.xlarge \
  --allocated-storage 200 \
  --vpc-security-group-ids sg-0abc123def456789 \
  --replication-subnet-group-identifier prod-migration-subnet-group \
  --multi-az \
  --engine-version 3.5.1

# ── إنشاء نقطة نهاية المصدر (MySQL محلي) ───────────────────────────────────
aws dms create-endpoint \
  --endpoint-identifier onprem-mysql-src \
  --endpoint-type source \
  --engine-name mysql \
  --server-name 10.0.1.50 \
  --port 3306 \
  --username dms_user \
  --password "$DB_PASSWORD" \
  --database-name orders_db

# ── إنشاء نقطة نهاية الهدف (Amazon RDS MySQL) ────────────────────────────────
aws dms create-endpoint \
  --endpoint-identifier rds-mysql-target \
  --endpoint-type target \
  --engine-name mysql \
  --server-name orders-db.cluster-xyz.us-east-1.rds.amazonaws.com \
  --port 3306 \
  --username dms_user \
  --password "$RDS_PASSWORD" \
  --database-name orders_db

# ── إنشاء مهمة تكرار full-load + CDC وتشغيلها ─────────────────────────────
aws dms create-replication-task \
  --replication-task-identifier orders-full-load-cdc \
  --source-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:XXXXXXXX \
  --target-endpoint-arn arn:aws:dms:us-east-1:123456789012:endpoint:YYYYYYYY \
  --replication-instance-arn arn:aws:dms:us-east-1:123456789012:rep:ZZZZZZZZ \
  --migration-type full-load-and-cdc \
  --table-mappings file://table-mappings.json \
  --replication-task-settings file://task-settings.json

aws dms start-replication-task \
  --replication-task-arn arn:aws:dms:us-east-1:123456789012:task:AAAAAAAA \
  --start-replication-task-type start-replication

# ── مراقبة التأخر قبل التحويل (الهدف: < 5 ثوانٍ) ───────────────────────────
aws dms describe-replication-tasks \
  --filters Name=replication-task-arn,Values=arn:aws:dms:... \
  --query 'ReplicationTasks[0].ReplicationTaskStats.{Lag:CdcLatencySource,Applied:TablesLoaded}'

لا تُجرِ تحويلًا بارد الإيقاف على قاعدة بيانات حية أبدًا. النمط الصحيح: (1) أوقف الكتابات إلى المصدر — ضع التطبيق في وضع الصيانة 60 ثانية، (2) انتظر حتى يصل تأخر DMS إلى الصفر، (3) رقّ الهدف، (4) حدّث سلسلة الاتصال، (5) أعد تشغيل التطبيق. إن فشل أي شيء بين الخطوتين 3 و5، تراجع بالإشارة إلى المصدر مجددًا — يمكن لـ DMS مواصلة النسخ في الاتجاه العكسي. الفرق التي تتخطى خطوة الإيقاف تُحدث بانتظام حالات تنافر بيانات تتطلب ساعات من المصالحة اليدوية.

أوضاع الفشل في الهجرة على نطاق واسع

هذه هي الأنماط التي تُخرج برامج الهجرة المؤسسية عن مسارها:

اكتشاف تشعّب التبعيات في منتصف الموجة. تطبيق وصفته بـ"مستقل" يتضح أنه يستدعي سبع عشرة خدمة أخرى عبر IPs مكتوبة بشكل ثابت. أدوات الاكتشاف تحلّ هذا — 30+ يومًا من بيانات تدفق الشبكة قبل بدء الموجة الأولى، لا بعدها.
انتهاكات امتثال التراخيص. بعض تراخيص البرمجيات مرتبطة بعنوان MAC للمضيف الفيزيائي أو بعدد مآخذ المعالج المحددة. نقل صورة نظام التشغيل إلى EC2 ينتهك الترخيص. أجرِ دائمًا تدقيقًا على التراخيص قبل إعادة استضافة البرامج التجارية.
خطط التراجع التي لم تُختبر قط. كل تحويل يجب أن يمتلك مسار تراجع مُختبرًا. "سنستعيد النسخة الاحتياطية" ليست خطة تراجع — إنها خطة استرداد بـRTO مجهول. إن لم يُنفَّذ التراجع في تدريب، فسيفشل تحت الضغط.
زحف نطاق الموجة. السماح لموجة بالتضخم من 10 خوادم إلى 40 ثم "بضعة أخرى" يُلغي نطاق التأثير المحكوم. حدّد حجم الموجة بسقف صارم واجعل الخوادم المتبقية بذرة الموجة التالية.

درجة استعداد الهجرة: تقدّم AWS تقييم استعداد الهجرة (MRA) — مقابلة منظّمة وفق ستة أبعاد (حالة الأعمال، المنطقة المهبطية، نموذج التشغيل، الأمان والامتثال، تجربة الهجرة، هيكل الفريق). إجراء MRA قبل الموجة الأولى يكشف عقبات تنظيمية لا يستطيع أي أداة حلّها. مديرو البرامج الذين يتخطّون هذه الخطوة يواجهون باستمرار في الشهر السادس العقبات ذاتها التي كان MRA سيكشفها في الشهر الأول.