فشل عائد الاستثمار في تحديث الحوسبة السحابية

فشل عائد الاستثمار في تحديث الحوسبة السحابية: فجوة المراقبة التي لم يخطط لها أحد

تتجه الشركات العالمية نحو إنفاق أكثر من تريليون دولار على خدمات الحوسبة السحابية العامة بحلول عام 2026. وتستند جدوى هذا الإنفاق إلى توقعات تتراوح بين المقنعة والاستثنائية: إذ تُظهر أبحاث مؤسسة IDC عائدًا على الاستثمار بنسبة 334% خلال ثلاث سنوات، وفترة استرداد رأس المال لا تتجاوز عشرة أشهر للمؤسسات التي تُنفذ عمليات التحديث بفعالية. وتشير معايير AWS إلى نمو الإيرادات بنسبة 43%، وانخفاض الإنفاق على تكنولوجيا المعلومات بنسبة 33% لأحمال العمل المُحدثة بالكامل. هذه الأرقام حقيقية، وتمثل نتائج قابلة للتحقيق. لكن المشكلة تكمن في أن معظم المؤسسات لا تُحققها.

تُظهر بيانات شركة برايس ووترهاوس كوبرز أن 54% من الشركات تُشير إلى قيمة ضئيلة من استثماراتها في الحوسبة السحابية، على الرغم من تزايد الإقبال عليها. وتُشير بيانات شركة فليكسيرا إلى أن 84% من المؤسسات تُصنّف شفافية التكاليف كأولوية قصوى، ومع ذلك، فإن 38% فقط منها تُتابع عائد الاستثمار في الحوسبة السحابية بشكل فعّال عبر وحدات أعمالها. وتُفيد شركة غارتنر بأن ميزانيات الحوسبة السحابية تتجاوز التوقعات بنسبة 17% في المتوسط. إن الفجوة بين ما تعد به تحديثات الحوسبة السحابية وما تُعانيه المؤسسات فعليًا ليست فشلًا تقنيًا، بل هي فشل في الشفافية، ويبدأ هذا الفشل قبل وقت طويل من نقل أول عبء عمل.

اعرف ما الذي تنقله أولاً

SMART TS XL تحديد كل تبعية، ومكون معطل، ومخاطر هيكلية قبل بدء عملية الترحيل.

المزيد من المعلومات

الحقيقة المزعجة حول فشل تحديث الحوسبة السحابية

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

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

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

ما هي فجوة قابلية الملاحظة في الواقع

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

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

لهذه الفجوة السابقة في إمكانية الملاحظة ثلاثة أبعاد:

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

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

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

أين تتشكل الفجوة: قبل الهجرة وأثناءها وبعدها

قبل الهجرة: وهم التقييم

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

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

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

أثناء عملية الترحيل: مشكلة اكتشاف التبعيات

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

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

بعد الترحيل: انهيار شفافية التكاليف

تُشير 84% من المؤسسات إلى أن إدارة الإنفاق على الحوسبة السحابية تُمثل التحدي الأكبر الذي يواجهها، حيث تجاوزت الميزانيات التوقعات بنسبة 17%. في الوقت نفسه، أفاد 69% من قادة تكنولوجيا المعلومات بتجاوزات في ميزانية الإنفاق على الحوسبة السحابية.

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

تشير تقارير شركة فليكسيرا إلى أن 38% فقط من المؤسسات تتابع عائد الاستثمار السحابي بشكل فعّال عبر وحدات أعمالها. لا تستطيع المؤسسات تتبع عائد الاستثمار الذي لا يمكنها قياسه، ولا يمكنها قياس عائد الاستثمار بناءً على أساس لم تحدده بدقة قبل بدء عملية الانتقال.

إمكانية الملاحظة الهيكلية التي تحتاجها برامج الهجرة

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

جرد كامل. كل برنامج، ووظيفة، ووحدة نمطية، ودفتر نسخ، ومخطط، وتدفق عمل، وإجراء، بما في ذلك تلك التي ليست موجودة في الوثائق، والتي غالباً ما تمثل 20-30% من العدد الفعلي في بيئات المؤسسات الكبيرة.

رسم خرائط التبعيات عبر اللغات. كيفية اتصال خدمة جافا ببرنامج كوبول الذي يقرأ من جدول DB2 الذي تقوم مهمة دفعية JCL بتعبئته. التبعيات التي تتجاوز حدود اللغات هي تلك التي لا تستطيع أدوات البنية التحتية رؤيتها، والتي تُسبب أكبر قدر من المفاجآت المكلفة أثناء الترحيل.

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

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

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

لماذا تكون فجوة المراقبة أكبر بالنسبة للأنظمة القديمة وأنظمة الحواسيب المركزية

تتراكم المخاطر في بيئات الحوسبة السحابية التي تنمو من خلال عمليات ترحيل سريعة وغير منظمة، وذلك بسبب الفجوات بين الأدوات والفرق والمسؤوليات. بالنسبة للمؤسسات التي تُرحّل محافظ تطبيقات الويب الحديثة، تُعدّ هذه الفجوة كبيرة. أما بالنسبة للمؤسسات التي تُرحّل أحمال عمل الحواسيب المركزية، ولغات البرمجة COBOL وJCL وPL/I وRPG، فهي غالبًا ما تكون حاسمة.

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

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

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

العلاقة بين العمليات المالية: لا يمكنك إدارة ما لا تراه

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

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

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

كيفية SMART TS XL يسد فجوة إمكانية المراقبة قبل الهجرة

SMART TS XL توفر هذه التقنية طبقة مراقبة هيكلية ضرورية لتقييم ترحيل البيانات إلى الحوسبة السحابية، والتي لا تستطيع أدوات اكتشاف البنية التحتية توفيرها. من خلال تحليل الشفرة المصدرية الفعلية لكل تطبيق في المحفظة، باستخدام لغات البرمجة COBOL وJCL وJava وPython وRPG وPL/I وSQL واللغات الحديثة، تُنشئ هذه التقنية نموذج تبعية موحدًا يكشف التعقيدات غير المرئية قبل بدء عملية الترحيل.

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

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

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

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

سد الفجوة قبل فتح باب الميزانية

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

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