كيف ينقل الإنترنت المعلومات، ولماذا قد تتعطّل الخدمات

تناول المقالان السابقان من سلسلة «أساسيات»، «كيف تعمل أجهزة الكمبيوتر: فاينمان وموظف الأرشفة فائق السرعة» و«كيف تحوّل أجهزة الكمبيوتر الرقمين 0 و1 إلى كلمات وصور»، كيفية اتباع الكمبيوتر للتعليمات وتمثيل المعلومات بقيم محفوظة. لكن نقل هذه المعلومات إلى كمبيوتر آخر يطرح مشكلة مختلفة: فالجهازان لا يشتركان في الذاكرة، وقد لا توجد بينهما وصلة مباشرة أصلاً. يستطيع موظف الأرشفة في نموذج فاينمان أن يفتح درجاً مرقّماً ليعثر على شيء محفوظ بالقرب منه. أمّا للحصول على معلومات موجودة في كمبيوتر بعيد، فعليه إرسال طلب وانتظار الرد، كما لو أنه يكاتب مكتباً آخر بدلاً من فتح درج ثانٍ. وقد يكون الجهاز مستعداً لمتابعة العمل قبل وصول الإجابة بوقت طويل.

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

من الجهاز إلى الشبكة الأوسع

يبدأ الهاتف أو الكمبيوتر المحمول أو أي جهاز آخر باتصال محلي، غالباً عبر شبكة Wi-Fi أو شبكة الهاتف المحمول أو كابل. ومن هناك تمرّر معدات الشبكة القريبة حركة البيانات نحو شبكة أوسع. وفي المنازل والمكاتب، يتولى مزوّد خدمة الإنترنت (ISP) عادةً توفير الاتصال بالإنترنت الأوسع، وتؤدي شبكة مشغّل الهاتف المحمول دوراً مماثلاً. ويستطيع كل مزوّد تبادل البيانات مع شبكات أخرى، مما يسمح للاتصالات بعبور مؤسسات ومسافات بعيدة من دون الحاجة إلى وصلة مادية مخصّصة بين الجهازين الطرفيين.

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

كيف يتحوّل اسم الخدمة إلى عنوان

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

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

كيف تمرّر الشبكات المعلومات

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

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

من أين تأتي الإجابات ولماذا تستغرق وقتاً

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

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

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

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

لماذا قد تتعطّل الخدمات معاً

قد تكون لموقع تسوّق وتطبيق مصرفي وخدمة فيديو جهات مالكة وأغراض مختلفة، لكنها جميعاً تعتمد على جزء واحد من البنية الأساسية. يوفّر مزوّدون مثل Amazon Web Services وMicrosoft Azure وGoogle Cloud موارد للحوسبة والتخزين، بينما تقدّم Cloudflare وAkamai وAmazon CloudFront أشكالاً من توصيل المحتوى وخدمات الشبكات الأخرى. وقد تتداخل هذه الفئات، ويشغّل المزوّد الواحد مكونات كثيرة ومتميزة. ولذلك لا يكفي ذكر اسم المزوّد لإثبات وجود اعتماد تقني مشترك أو تحديد سبب عطل بعينه. والسؤال الحاسم هو المكونات التي تتطلبها كل خدمة فعلاً لإتمام عملية محددة.

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

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

في 20 أكتوبر 2026، عطّل حدث متعلق بالطاقة خدمات Google Cloud في منطقة لندن، بينما أبلغ عملاء Revolut وLloyds وHSBC عن مشكلات في الوصول إلى خدمات مصرفية. وشرح التقرير الأولي للحادث الصادر عن Google أن فقدان إحدى مناطق التوافر في مركز بيانات أثّر أيضاً في خدمات أخرى ضمن المنطقة الإقليمية، إذ انتقل العمل إلى البنية المتبقية وظلت بعض الأنظمة الإقليمية تعتمد على مكوّنات في المنطقة غير المتاحة. وربط تقرير لوكالة Reuters بين تعطّل Revolut وحادث Google Cloud، لكن المسارات التقنية الدقيقة التي أثّرت في كل مؤسسة لم تُثبت علناً.

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

كيف تحصل تطبيقات الأخبار على المقالات

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

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

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

الخلاصة

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

مصطلحات أساسية ينبغي معرفتها

المراجع

1. Google Cloud Service Health (22 أكتوبر 2026). التقرير الأولي لحادث تعطّل خدمات منطقة europe-west2 في 20 أكتوبر. ↗
2. Reuters (21 أكتوبر 2026). «Europe's financial regulators query Google over cloud outage that hit banks». ↗
3. Synergy Research Group (30 يوليو 2026). «Q2 Cloud Market Passes $143 Billion; Highest Growth Rate in Eight Years». حصص إيرادات خدمات البنية الأساسية السحابية عالمياً في الربع الثاني من 2026: Amazon ‏28%، وMicrosoft ‏20%، وGoogle ‏15%. ↗
4. W3Techs (اطّلاع 22 أكتوبر 2026). «Usage statistics and market shares of reverse proxy services for websites». يقيس الاستخدام الملحوظ على المواقع لخدمات تشمل Cloudflare وAmazon CloudFront وFastly وAkamai، ولا يقيس إيرادات شبكات توصيل المحتوى أو حصص حركة البيانات. ↗