دليل عملي للمؤسسات للانتقال إلى السحابة، من التقييم حتى الانتقال الفعلي

نادرًا ما تُجري المؤسسات الترحيل مرة واحدة. فهي ترحّل نظامًا أول، وتتعلم منه، ثم ترحّل الأنظمة العشرة التالية. ويوثّق الدليل العملي ما تعلّمته لتكون الموجة الثانية أسرع وأكثر أمانًا من الأولى: كيف تُقيَّم الأنظمة، وكيف تبدو منطقة الهبوط (landing zone)، وكيف يُدار التحويل، وما معنى «الإنجاز». هذا الدليل هو الذي نعتمده نقطة انطلاق مع العملاء، وينبغي تكييفه مع مؤسستك لا اتباعه حرفيًا.

يسري فيه مبدآن. الأول: رحّل وظيفة العمل لا الخادم؛ فالسؤال هو كيف يستمر التطبيق وبياناته في خدمة المستخدمين، لا كيف تُنسخ آلة افتراضية. والثاني: أبقِ كل خطوة قابلة للتراجع حتى اللحظة التي تُجعل فيها دائمة عن قصد.

يأتي اختيار المنطقة أولًا. فالمنطقة الموجودة داخل البلد، حيثما وُجدت، توفّر مناطق توافر (Availability Zones) متعددة للمرونة وزمن استجابة منخفضًا للمستخدمين المحليين. ومن الأمثلة منطقة AWS Asia Pacific (Bangkok) (ap-southeast-7): فهي تمنح المؤسسات التي لديها مستخدمون في تايلاند خيارًا لم يكن متاحًا طوال معظم حقبة السحابة، بدلًا من خدمة البلد من سنغافورة. وللأنظمة الحساسة لزمن الاستجابة وللمؤسسات التي تفضّل سياساتها أو جهاتها التنظيمية بقاء البيانات داخل البلد، تكون المنطقة المحلية نقطة الانطلاق الافتراضية.

ثمة تحذيران. الأول أن المناطق الأحدث لا تُطلق بجميع الخدمات؛ لذا راجع قائمة الخدمات الإقليمية لكل خدمة مُدارة في التصميم قبل الالتزام، وأعدّ بديلًا (خدمة مختلفة، أو منطقة مختلفة لذلك المكوّن). والثاني أن الإقامة قرار سياسي قبل أن تكون قرارًا تقنيًا: فقوانين حماية البيانات الشخصية مثل PDPA تجيز النقل عبر الحدود بشروط، وقد تكون للجهات التنظيمية القطاعية، في الخدمات المالية مثلًا، توقعاتها الخاصة. دوّن فئات البيانات التي يجب أن تبقى داخل البلد وتلك التي يجوز نسخها إلى الخارج للتعافي من الكوارث، واطلب من الفرق القانونية وفرق الامتثال تأكيد ذلك. ثم حوّل ذلك إلى قيود على المناطق ضمن سياسات المؤسسة، بحيث يُمنع إنشاء أي مورد في غير موضعه بدلًا من اكتشافه لاحقًا.

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

كل ما يمكن تعريفه بالشيفرة في منطقة الهبوط ينبغي تعريفه بها: الحسابات والسياسات المؤسسية، والشبكات والتوجيه، والهوية والأدوار، والتسجيل ومسارات التدقيق، ومفاتيح التشفير، وسياسات النسخ الاحتياطي، والميزانيات والتنبيهات. Terraform هي أداتنا المفضلة لأنها تصريحية ومستقلة عن المزوّد وقابلة للمراجعة ضمن مسار طلبات الدمج (pull request) نفسه المتبع مع شيفرة التطبيقات.

بعض الممارسات تُبقيها قابلة للإدارة. خزّن الحالة (state) عن بُعد مع القفل، بحالة واحدة لكل بيئة ولكل مكوّن منطقي، حتى لا يُفسد خطأ في موضع موضعًا آخر. ابنِ وحدات صغيرة واضحة الأسماء للعناصر التي تُنشأ مرارًا (خدمة مع تعريف حاويتها، وقاعدة موازن التحميل، ودور IAM، ومجموعة السجلات) وأدِر إصداراتها. ضع وسومًا على كل مورد بالمالك والبيئة والتطبيق ومركز التكلفة من وحدة وسوم واحدة، لأن ضبط التكاليف لاحقًا يعتمد على ذلك. شغّل plan مع كل تغيير، واشترط المراجعة، وطبّق التغييرات من مسار نشر لا من حاسوب محمول. اكتشف الانحراف وفق جدول زمني، وتعامل مع التغييرات اليدوية في وحدة التحكم على أنها حوادث يجب تسويتها لا وضعًا طبيعيًا جديدًا.

والنتيجة أن بيئة الموجة الثانية تصبح طلب دمج لا مشروعًا.

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

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