الفرق الصغيرة لا تخسر أمام الكبار بسبب نقص الأدوات بقدر ما تخسر بسبب تشتت القرار. القضية ليست إضافة تقنية أخرى، بل إزالة احتكاك واضح من العمل من دون خلق كلفة أو مخاطرة أكبر في مكان آخر.

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

ابدأ بفصل ما تريده عن ما تحتاجه. سؤال بسيط لكنه مؤلم: ما الذي ندفع مقابله ولا نستخدمه؟ اجمع بيانات استخدام فعلية للشهرين الماضيين واطرح الأسئلة التالية على فرق التطوير والعمليات: ما التطبيقات التي تتعرض لأحمال متقلبة؟ أي منها حساس للكمون؟ ما قواعد الامتثال التي تمنع نقل بيانات بعينها؟

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

قرّر على ثلاثة قوائم: يبقى (keep)، ينتقل كما هو (lift-and-shift)، ويعاد تصميمه (refactor). هذه القوائم ليست نظرية؛ هي قواعد تنفيذية تحدد ميزانية، خطة تعلم، ومخاطر.

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

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

قائمة تحقق سريعة قبل التوقيع على العقد: - هل تحتاج سعة متغيرة بسرعة (فترات حمل قصيرة ومتقلبة) أم سعة متواصلة ومستقرة؟ - ما تكلفة نقل البيانات (egress) لكل سيناريو استخدام؟ - هل هناك قيود امتثال أو سياسات بيانات تمنع نقل بعض الملفات خارج الموقع؟ - هل أنت مستعد للاستثمار في تحكم داخلي (tagging، FinOps، CI/CD) أم ترغب في حل مُدار كاملًا؟

الاختيار بين Public Cloud وHybrid وColocation أو On-premise ليس تقنية فقط، بل قرار تنظيمي. مثلاً، شركات تتعامل مع قواعد بيانات كبيرة ومستقرة تميل للـ colocation أو On-premise لأن كلفة تخزين ونقل البيانات في السحابة قد تفوق فوائد الإدارة المُدارة. على الجانب الآخر، فرق تطويرات منتجات تتطلب بيئات اختبار متكررة وشدات حمل مفاجئة تستفيد من Public Cloud.

قواعد عملية: للحمولات غير المتوقعة أو التي تتأثر بالموسمية اختر نماذج مع Autoscaling لكن ضع حدودًا واضحة للحد الأدنى والحد الأقصى. للحمولات الثابتة، اتفاقيات التسعير طويلة الأجل (reserved instances / savings plans) تصبح مبررة.

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

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

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

أدوات FinOps وحدود الميزانية ليست كافية وحدها إذا لم تُترجم إلى قواعد شراء: لا تُصدر VM أو قاعدة بيانات دون تذكرة أو موافقة تكلفة. لا تُعطِ فرقًا صلاحية إنشاء حسابات سحابية بدون نظام Tagging وإغلاق تلقائي للموارد التجريبية.

قوائم تحقق لضبط التكلفة: - اعتمد سياسة lifecycle للموارد التجريبية (إغلاق تلقائي بعد X أيام). - طبّق Tagging إلزامي لكل مصدر: خدمة، مالك، بيئة، مشروع. - راجع الاستخدام شهريًا وخفض العتبة قبل نهاية الربع. - نفّذ Reserved Instances للمحركات الثابتة، وSpot أو Preemptible للعمليات التي تحتمل الانقطاع.

القرار العملي هنا هو بسيط ومؤلم: وجود فائض سعوي دائم يعني أن بعض الأحمال يجب أن تعاد إلى بيئة ثابتة أو تُعاد هندستها لتكون أكثر كفاءة.

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

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

نقاط يجب فحصها فورًا: - تشفير البيانات في الراحة وأثناء النقل: من المسؤول عن المفاتيح؟ - من هي الجهة المالكة للمفاتيح الأساسية؟ managed KMS أم BYOK؟ - هل استرداد البيانات يتطلب نقل بيانات كبير (تكلفة egress)؟

مقارنة عملية: إن أنشأت نظامًا يعتمد على managed services مكررة في منطقة واحدة فقط، فقد تكون أكثر عرضة لتأثيرات إقليمية. إن حافظت على نسخ احتياطية منتظمة خارج السحابة، فتأكد أن تكلفة واستغراق نقل البيانات لإعادة البناء مقبولان.

تحذير: لا تفترض أن مورد السحابة يحمي بياناتك تلقائيًا. الحوكمة والهوية وإدارة المفاتيح مسؤوليتك.

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

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

إجراء عملي سريع: عيّن مالكًا لكل فئة تكلفة (compute, storage, network) بمسؤولية تقرير شهري وأوامر تنفيذية قابلة للقياس.

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

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

#الحوسبة_السحابية #البنية_التحتية #الأمان