البنية التحتية لتقنية المعلومات حتى 2030: ما الذي ينبغي للشركات الاستعداد له

ما الموثق وما الذي يبقى سيناريو؟

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

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

تصبح الطاقة مسألة معمارية

تقدر وكالة الطاقة الدولية استهلاك مراكز البيانات للكهرباء عالمياً في 2024 بنحو 415 TWh. وفي الحالة الأساسية لتقرير Energy and AI لعام 2025، يرتفع إلى نحو 945 TWh بحلول 2030. هذا تطور قائم على نمذجة مع عدم يقين، وليس قياساً مرصوداً بالفعل لعام 2030. ويصف التقرير، ضمن أمور أخرى، افتراضات مختلفة لاستخدام الذكاء الاصطناعي والكفاءة. وكالة الطاقة الدولية: ملخص Energy and AI لعام 2025 ↗

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

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

يغير الذكاء الاصطناعي سؤال الذاكرة، لكن ليس كل تطبيق بحاجة إلى GPU

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

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

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

راقب معماريات الذاكرة الجديدة دون الاعتماد عليها

يصف CXL Consortium في CXL 2.0 توسعة الذاكرة والتخصيص المُدار لموارد ذاكرة مجمعة. تتعاون المنصة وأجهزة الذاكرة والبرامج وربما المحولات. إنها بنية تقنية موثقة، لا وعد بإمكان ترقية كل لوحة أم موجودة. CXL Consortium: تجميع الذاكرة في CXL 2.0 ↗

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

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

تأتي قابلية النقل من اعتماديات مُختبرة

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

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

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

ثلاثة سيناريوهات لجولة الاستثمار المقبلة

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

استعداد عملي خلال التسعين يوماً المقبلة

1. الأيام 1–30: جرد التطبيقات والمسؤوليات ومدد الدعم. تسجيل اتجاهات المعالج وRAM والتخزين والتكلفة خلال دورة عمل ذات معنى.
2. الأيام 31–60: اختبار استعادة حقيقية وتصدير بيانات. توثيق أكبر الاعتماديات اليدوية واختيار تجربة تحسين محدودة واحدة.
3. الأيام 61–90: تقييم التجربة وفق معايير محددة مسبقاً. النظر إلى التكلفة والجودة والتشغيل معاً وعدم التوسع إلا بعد إثبات المنفعة.

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

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