AWS CAF ومسارات الترحيل
2 دقيقة قراءة
أهداف الدرس
- اشرح اختيار منظور الاستعداد ومسار الترحيل من القيود والقيمة.
- طبّق قاعدة القرار على حالة جديدة مع تبرير البدائل.
AWS CAF ومسارات الترحيل
CAF ينظم التحول عبر الأعمال والأشخاص والحوكمة والمنصة والأمن والعمليات؛ ومسار الترحيل يقرر لكل عبء لا للمحفظة كلها. اختيار منظور الاستعداد ومسار الترحيل من القيود والقيمة.
يفوض فريق الأمن المطورين إنشاء أدوار، لكن يجب ألا تتجاوز الأدوار سقفًا معتمدًا حتى إذا أضيفت لاحقًا سياسة هوية أوسع. ما القرار الأدق؟ القرار: فرض السياسة المعتمدة permissions boundary مع منح المهمة بسياسة هوية منفصلة. السبب: التقاطع بين identity grant وboundary يتيح المهمة ويمنع تجاوز السقف المفروض.
حساب قائم في Organizations يجب أن يحتفظ بأحماله ومعرفه ويصبح محكومًا بـControl Tower. ما الإجراء؟ القرار: استيفاء المتطلبات ثم enroll للحساب القائم في OU مسجلة. السبب: enrollment يجلب الحساب القائم تحت الضوابط مع حفظ معرفه وأحماله.
يخدم تطبيق عالمي مستخدمين في إقليمين، ويحتاج قراءة وكتابة محلية في كليهما مع replication مُدار واستمرار متعدد الأقاليم. ما قدرة DynamoDB المناسبة؟ القرار: DynamoDB global table بنسخ متعددة نشطة عبر الإقليمين. السبب: الجداول العالمية توفر replication مُدارًا ونسخًا متعددة نشطة تخدم القراءة والكتابة.
يفترض مزود SaaS دورًا في حسابات عملاء متعددة. يجب منع confused deputy بحيث لا يستطيع عميل دفع المزود لاستخدام دور عميل آخر. ما الشرط؟ القرار: اشتراط external ID فريد يقدمه المزود في trust policy مع principal وصلاحيات محدودة، من دون معاملته كسر. السبب: external ID يربط طلب AssumeRole بسياق العميل المقصود ويعالج confused deputy.
تريد المؤسسة اكتشاف S3 buckets وKMS keys وغيرها عندما تسمح resource policies بوصول من خارج الحسابات الموثوقة. ما الأداة؟ القرار: IAM Access Analyzer بمنطقة ثقة معرفة. السبب: Access Analyzer يحلل السياسات ويولد findings للوصول الخارجي عن منطقة الثقة.
يحتاج الموظفون نقطة SSO مركزية إلى حسابات AWS متعددة وتطبيقات مخصصة بحسب assignments، مع مصدر هوية واحد. ما الخدمة؟ القرار: IAM Identity Center. السبب: Identity Center يدير وصول workforce وSSO وتعيينات الحسابات والتطبيقات مركزيًا.
ستوقف المؤسسة نظام CRM الحالي وتشتري منتج SaaS مختلفًا، ثم تنقل البيانات والعمليات إليه. ما استراتيجية 7Rs؟ القرار: Repurchase. السبب: Repurchase يستبدل التطبيق بمنتج مختلف مثل SaaS مع نقل البيانات أو العمليات.
تريد المؤسسة نقل مجموعة كبيرة من الأحمال الافتراضية إلى نسخة سحابية متوافقة من المنصة نفسها، بلا إعادة تصميم كل تطبيق أو تغيير معماريته. ما استراتيجية 7Rs؟ القرار: Relocate. السبب: Relocate ينقل البيئة المتوافقة على مستوى المنصة دون إعادة كتابة التطبيقات.
لا يستطيع التطبيق الأحادي تلبية متطلب إطلاق ميزات مستقلة، ويجب إعادة تصميم مكوناته للاستفادة من قدرات سحابية أصلية. ما استراتيجية 7Rs؟ القرار: Refactor. السبب: Refactor يعيد تصميم المكونات لتحقيق متطلب لا يتيحه النقل البسيط.
تتوفر التقنية، لكن التحول يتعثر بسبب فجوات المهارات والأدوار والثقافة وضعف تبني طرق العمل الجديدة. أي منظور في AWS CAF يعالج الفجوة؟ القرار: People. السبب: People يعالج المهارات والثقافة والقيادة والتصميم المؤسسي وتسريع التغيير.
تحتاج القيادة ربط استثمارات السحابة بالاستراتيجية ونتائج أعمال قابلة للقياس وأولويات المحفظة. أي منظور CAF؟ القرار: منظور Business في AWS CAF. منظور Business يربط الاستثمار بالاستراتيجية والقيمة والنتائج والمحفظة.
تتعارض المبادرات ولا توجد إدارة موحدة للمحفظة والمخاطر والمنافع والمالية السحابية. أي منظور CAF؟ القرار: منظور Governance في AWS CAF. Governance ينسق المبادرات ويوازن المنافع والمخاطر والبرامج والمالية السحابية.
الفجوة هي بناء أساس هجين قابل للتوسع يشمل المعمارية والهندسة والتهيئة وتسليم التطبيقات. أي منظور CAF؟ القرار: منظور Platform في AWS CAF. منظور Platform يبني الأساس السحابي وقدرات التهيئة والتسليم الحديثة.
الفجوة المؤسسية تشمل ضمان الأمن والهوية والثغرات وحماية البنية والبيانات والاستجابة للحوادث. أي منظور CAF؟ القرار: منظور Security في AWS CAF. منظور Security ينظم هذه القدرات الأمنية عبر رحلة التحول.
يجب تقديم الخدمات السحابية بمستوى متفق عليه عبر المراقبة والحوادث والمشكلات والتغيير والأداء والاستمرارية. أي منظور CAF؟ القرار: منظور Operations في AWS CAF. منظور Operations يركز صحة الخدمة وتوافرها وتسليمها وفق مستوى متفق عليه.
عميل قائم ومؤهل لديه مشروع ترحيل جارٍ بدأ قبل إغلاق الخدمة للعملاء الجدد، ويستخدم أدوات متعددة ويحتاج موضعًا مركزيًا لتتبع تقدم التطبيقات. ما الخدمة؟ القرار: AWS Migration Hub.. Migration Hub يوفر موضعًا مركزيًا لربط أدوات الترحيل وتتبع تقدم التطبيقات.
عميل قائم ومؤهل يكمل مشروع ترحيل جارٍ بدأ قبل إغلاق الخدمة للعملاء الجدد، ويحتاج جرد الخوادم وإعداداتها واستخدامها وتبعياتها. ما الخدمة؟ القرار: AWS Application Discovery Service.. Application Discovery Service يجمع دليل الجرد والاستخدام والتبعيات اللازم لتخطيط التطبيقات والموجات.
تحتاج خوادم مدعومة إلى lift-and-shift مع replication مستمر واختبار cutover قبل التحويل. ما الخدمة؟ القرار: AWS Application Migration Service.. Application Migration Service يؤتمت إعادة الاستضافة عبر replication وإنشاء مثيلات اختبار وتحويل.
تريد القيادة تحديد موجات ترحيل فورًا، لكن لم تُقَس فجوات المهارات والحوكمة والمنصة والأمن والتشغيل. ما الخطوة السابقة الصحيحة؟ القرار: إجراء Migration Readiness Assessment عبر منظورات AWS CAF وتسجيل الفجوات وأصحابها. يحدد Migration Readiness Assessment نقاط القوة والفجوات وأصحاب المعالجة عبر منظورات AWS CAF قبل بناء خطة الموجات.
تعتمد واجهة الطلبات على قاعدة بيانات وخدمة هوية مشتركة، لكن الخطة وضعت كل خادم في موجة مستقلة حسب رقمه. كيف تُبنى الموجات؟ القرار: تجميع التطبيقات من التبعيات وأولوية العمل والتعقيد واستراتيجية الترحيل واختبار تسلسلها. تُبنى الموجات حول التطبيقات وتبعياتها وأولوية العمل وتعقيدها واستراتيجية الترحيل، لا حول قوائم خوادم مستقلة.
لدى المؤسسة مستودع .NET Framework مدعوم وتريد نقله إلى .NET حديث متعدد المنصات مع خطة وتحويل وتقارير، على أن يراجع المطورون الناتج ويثبتوه بالبناء والاختبارات. ما الأداة المطابقة؟ القرار: AWS Transform for .NET مع التحقق البشري والبناء والاختبارات. هذه حالة استخدام مدعومة ومحددة لـAWS Transform for .NET، ولا يُعامل الناتج كنجاح حتى يراجعه المطورون وتجتاز عمليات البناء والاختبارات.
أنهت المؤسسة مرحلة assess وحددت فجوات الجاهزية ومحفظة أولية. قبل تنفيذ موجات ترحيل واسعة، ماذا تحقق مرحلة mobilize؟ القرار: معالجة فجوات الجاهزية، وبناء landing zone ونموذج التشغيل والأدوات والمهارات اللازمة للتنفيذ المتكرر. تغلق mobilize فجوات الجاهزية وتؤسس landing zone ونموذج التشغيل والأدوات والمهارات قبل التنفيذ واسع النطاق.
ينتهي دعم نظام التذاكر المرخص، وقد اعتمدت المؤسسة منتج SaaS يلبي سير العمل مع نقل البيانات وتهيئة المستخدمين. أي استراتيجية تنطبق؟ القرار: Repurchase باستبدال المنتج بـSaaS ونقل البيانات وتبني سير عمله. القرار repurchase لأن المؤسسة تستبدل المنتج، ولا تنقل بنيته الافتراضية كما في relocate.
تتضمن المحفظة خدمة منخفضة القيمة قابلة للاستبدال، ونظامًا عالي القيمة يحتاج إطلاقات مستقلة، وحملًا مقيدًا بجهاز مؤقتًا. ما منهج الاستراتيجية الصحيح؟ القرار: تعيين استراتيجية لكل حمل من القيمة والتبعيات وتحمل التغيير والموعد، مع توثيق سبب كل اختيار. السؤال لا يكرر اختيار replatform؛ بل يختبر المنهج الذي يسند قرارًا مختلفًا لكل حمل.
يجب إخلاء المركز خلال ستة أشهر، ويضم النطاق 120 آلة VMware مترابطة. يشترط الفريق إبقاء أدوات vSphere ونموذج التشغيل والتراخيص المتوافقة مؤقتًا، ولا يسمح الجدول بتغيير أنظمة الضيوف. ما الاستراتيجية؟ القيد الحاسم هو نقل مجموعة VMware مع إبقاء طبقة المحاكاة وأدوات التشغيل ونظم الضيوف مؤقتًا؛ هذا هو Relocate لا rehost. يظل القبول مشروطًا بالشبكة والتبعيات والرجوع قبل إغلاق المركز.
تريد المؤسسة ترحيل 80 تطبيقًا، ولكن لا توجد معايير دخول وخروج للموجة أو خطة رجوع. ما الخطوة الصحيحة؟ القرار: تعريف معايير الدخول والخروج والرجوع والمالك، ثم تنفيذ موجة رائدة محدودة وتوسيع النمط بعد نجاحها. هذا قرار تنفيذ الموجة وبواباتها، وليس قرار Retire لتطبيق غير مستخدم.
عميل حالي لـMigration Hub Strategy Recommendations يواصل مشروعًا قائمًا، ولديه جرد وتبعيات وشفرة مصدرية لكن قرارات التحديث لم توضع. ما المورد المناسب ضمن أهليته الحالية؟ الحالة تطلب تعيين استراتيجية تحديث من أدلة الجرد والتبعيات والشفرة، والعميل مؤهل لأنه يواصل مشروعًا قائمًا. Strategy Recommendations يؤدي هذا التحليل؛ الأدوات الأخرى تقدّر الاقتصاد أو تنفذ تحولًا محددًا أو تتبع التقدم.
تشترط خطة قطع موجة تجريبية نجاح تسجيل الدخول بنسبة 99.5% على الأقل عبر 10,000 محاولة، وإلا يبدأ الرجوع. بعد القطع بلغت النسبة 98.8% وما زالت البيئة القديمة قابلة للاستعادة. ما القرار؟ القياس 98.8% دون بوابة 99.5%، ومسار الرجوع ما زال متاحًا؛ لذلك يُطبق الشرط المعتمد الآن. الاستمرار يحول فشلًا محدودًا قابلًا للعكس إلى أثر أوسع.
أظهر assess فجوة خبرة تمنع بناء landing zone ومصنع الترحيل. ما الإجراء؟ الفجوة المحددة تمنع أصلين تأسيسيين للتوسع. يضيف المختص قدرة فورية، لكن المخرجات ومعايير القبول ونقل المعرفة تجعلها قدرة مؤسسية قابلة للتكرار بدل اعتماد دائم غير مضبوط.
اكتمل نقل CRM إلى SaaS، لكن مصالحة السجلات بلغت 99.6% بدل شرط 100%، وفشل اختبار استعادة سجل الاحتفاظ، وما زال النظام القديم صالحًا للرجوع. ما قرار الإيقاف؟ قرار الاستراتيجية تم، لكن الإيقاف أثر مستقل تحكمه بوابات البيانات والاحتفاظ والتكامل. فشل المصالحة والاستعادة يمنع إزالة المسار القابل للرجوع؛ يعاد الاختبار نفسه بعد الإصلاح ثم يُعتمد الإيقاف عند نجاح الدليل.
تتبنى وحدات الأعمال السحابة، لكن كل فريق يعيد بناء الأنماط والضوابط والتدريب منفردًا، فتتكرر الأخطاء ولا تنتقل المعرفة. ما تدخل التبني الأنسب؟ المشكلة قدرة وتنظيم ومعرفة متكررة، لا اختيار 7R. فريق التمكين يجمع الأعمال والمنصة والأمن والعمليات لينتج أنماطًا وحواجز وتدريبًا قابلة لإعادة الاستخدام، ثم يقيس التبني من دون أن يتحول إلى عنق موافقات ينفذ كل شيء.
حددت المؤسسة فرضية قيمة، واكتمل تقييم الجاهزية وأُغلقت فجوات القدرات، لكنها لم تثبت التبني أو النتيجة في الإنتاج بعد. أي طور CAF يناسب؟ فرضية القيمة موجودة والاستعداد الأساسي مكتمل، لكن القيمة في الإنتاج غير مثبتة؛ Launch يحول الفرضية إلى نموذج محدود بمقاييس قبل أن يتحمل Scale أثر التوسع.
تقترح القيادة «استخدام التحليلات المتقدمة»، لكن لا يوجد مالك لنتيجة العمل ولا خط أساس أو هدف أو شرط توقف. ما القرار قبل اختيار التقنية؟ غياب النتيجة والمالك والمقياس يجعل اختيار التقنية غير قابل للتقييم. يبدأ القرار بتعريف منفعة قابلة للقياس ومسؤول عنها وحد توقف، ثم تصبح التقنية وسيلة تُقبل أو تُرفض بدليل.
حقق pilot إنتاجي معايير التبني والكمون وكلفة الوحدة لثلاث شرائح عملاء، وأثبت نموذج التشغيل التكرار. ما مرحلة التحول التالية؟ الدليل المطلوب للإطلاق تحقق عبر شرائح ممثلة، وأصبح النموذج قابلًا للتكرار. Scale يوسع pilots الإنتاجية والقيمة إلى النطاق المطلوب مع التأكد من استمرار المنافع، بدل تكرار MVP أو إيقاف القياس.
لا يملك البرنامج جردًا موثوقًا للتطبيقات أو تبعياتها أو ملاكها، ومع ذلك طُلب منه إعداد حالة عمل وخطة موجات. ما العمل الصحيح أولًا؟ حالة العمل والموجات تعتمدان على معرفة ما سيُنقل وتبعياته واستعداد المؤسسة. مرحلة Assess تنتج الجرد وتقييم الجاهزية والفجوات والأساس الاتجاهي؛ Mobilize يأتي بعد فهم الحالة الحالية.
تستغرق تهيئة كل فريق جديد أربعة أيام بسبب طلبات يدوية متكررة، مع أن الضوابط والحصص نفسها معتمدة لكل الفرق. ما القرار الذي يقلل زمن الوصول إلى القيمة مع حفظ الحوكمة؟ المشكلة تكرار مسار تهيئة ثابت لا غياب ضوابط أو دليل تعافٍ. تحويل المواصفات المعتمدة إلى منتج خدمة ذاتية يزيل الانتظار اليدوي مع إبقاء الحدود قابلة للفحص، ويثبت المنفعة بقياس زمن التهيئة والرفض.
للموجة A اعتمادان خارجيان غير موثقين وموعد عقد بعد ستة أشهر. للموجة B لا اعتماد خارجي، نافذة أعمال بعد أربعة أسابيع، وتوفر runbook ورجوع مختبران. أي ترتيب أولي صحيح؟ B تملك نافذة قريبة وجاهزية تنفيذ مثبتة بلا اعتماد خارجي، لذلك تنتج موجة أولى قابلة للإغلاق. A تحتاج عملًا سابقًا محددًا، لكن موعد العقد يبقى قيدًا على تاريخ بوابتها اللاحقة؛ الترتيب ناتج من بيانات الاعتماد والنافذة والجاهزية.
حددت المؤسسة نتائج التحول وفرصه، لكن وحدات الأعمال والتقنية لم تتفق على فجوات المهارات والحوكمة والتبعيات أو خطة العمل المسؤولة عنها. أي مرحلة AWS CAF تناسب الآن؟ بعد وضوح النتائج، تعالج Align في هذه الحالة فجوات القدرات والتبعيات التي لم يتفق عليها أصحاب المصلحة أو لم يملكها مسؤول محدد. هذه الفجوات غير المحسومة هي بوابة لازمة هنا قبل Launch؛ ولا يعني ذلك وجوب إغلاق كل قدرة في AWS CAF قبل أي pilot محدود.
لم تحدد القيادة بعد لماذا تتحول إلى السحابة: لا فرضية قيمة، ولا نتائج أعمال قابلة للقياس، ولا فرص مرتبة بالأولوية. أي مرحلة من رحلة التحول في AWS CAF تبدأ بها؟ تبدأ Envision بتحديد النتائج والفرص وفرضية القيمة قبل أن يصبح هناك نطاق يمكن مواءمة قدراته أو إطلاقه. Align تأتي بعد وضوح الاتجاه لتحديد الفجوات وخطة العمل، وLaunch وScale تتطلبان أساسًا أكثر نضجًا.
تريد المؤسسة اختبار migration factory. التطبيق الأسهل مستقل ولا يستخدم الهوية المشتركة أو مسار القطع القياسي، بينما تطبيق متوسط المخاطر يمثل 60% من المحفظة ويستخدمهما مع رجوع مختبر. أي pilot؟ هدف pilot إثبات نمط قابل للتكرار، لا إنتاج نجاح سهل لا يختبر المصنع. التطبيق الممثل يختبر التبعيات والبوابات الشائعة مع إبقاء المخاطر والرجوع مضبوطين.
اعتمدت مؤسسة نطاق هجرة واسعًا وراعٍ تنفيذيًا وخطة أولية، وتبحث عن برنامج AWS منظم يساعد هجرة الأحمال على نطاق واسع؛ لا تريد أداة تنقل خادمًا واحدًا. ما المورد الأنسب؟ MAP برنامج يدعم العملاء في الهجرة ويُدار ضمن أهلية واتفاق وتتبع؛ ليس محرك نسخ حمل بعينه. أدوات التنفيذ قد تعمل داخله، لكنها لا تستبدل البرنامج والحوكمة المطلوبة.
تستخدم شركة السحابة لإطلاق اشتراك رقمي جديد لعملاء لم تكن تخدمهم، مع عرض قيمة وتسعير ومصدر إيراد جديد. أي مجال تحول في AWS CAF يصف النتيجة الأساسية؟ يركز تحول المنتج على إعادة تصور نموذج العمل وعروض القيمة والمنتجات أو الخدمات ومصادر الإيراد. وجود تقنية سحابية ممكّنة لا يجعل النتيجة تقنية فقط عندما يكون التغيير الحاسم عرضًا تجاريًا جديدًا.
تعيد مؤسسة تصميم نموذج تشغيلها، وتجمع فرق الأعمال والتقنية الدائمة حول منتجات وتدفقات قيمة مع دورات تحسين رشيقة. لم تطلق عرضًا رقميًا أو مصدر إيراد جديدًا. أي مجال تحول في AWS CAF يصف التغيير الأساسي؟ يركز التحول التنظيمي على إعادة تصور نموذج التشغيل وتنظيم فرق الأعمال والتقنية حول المنتجات وتدفقات القيمة مع أساليب رشيقة. لم تُغيّر الحالة عرض القيمة أو الإيراد، لذلك لا تكون تحول منتج، وهي أوسع من أتمتة خطوة تشغيلية منفردة.
يقارن DMS validation محتوى صفوف المصدر والهدف مع استمرار replication ويبلغ الاختلافات لإعادة تحقق مضبوطة. قد تخفي أعداد متساوية قيم أعمدة مختلفة. يقيس lag التوقيت لا صحة قيم كل صف.
خلاصة الدرس
CAF ينظم التحول عبر الأعمال والأشخاص والحوكمة والمنصة والأمن والعمليات؛ ومسار الترحيل يقرر لكل عبء لا للمحفظة كلها. rehost ليس الأسرع دائمًا، وrefactor ليس الأفضل دائمًا؛ retire وretain وreplatform قرارات صحيحة عند وجود دليل.