الخلاصة

  • اتفاق مستوى الإتاحة ليس بوليصة تعويض عن توقف العمل من طرف إلى طرف. إنه آلية محدودة توزع جزءاً من خطر عدم مطابقة خدمة محددة، وغالباً في صورة رصيد على رسوم تلك الخدمة لا في صورة تعويض عن الأثر الاقتصادي الكامل.
  • النسبة الاسمية لا يمكن تقييمها منفردة. يجب قراءة وحدة القياس، ومتطلبات النشر، والمقام النقدي، ومهلة المطالبة، والأدلة، والاستثناءات، والسقف، وقواعد منع الجمع باعتبارها أجزاء من المنتج نفسه.
  • كلما ارتفعت الإتاحة المطلوبة من حمل العمل، زادت أهمية ما يظل خارج SLA: التعدد بين المناطق أو النطاقات، الموازنة، التعافي، المراقبة المستقلة، التأمين، شروط الموردين المكملين، وخطة الخروج.
  • الأمثلة التالية ليست ترتيباً لـCloudflare أو AWS أو Google أو Oracle أو IBM من حيث الاعتمادية. إنها نماذج مختلفة لتصميم القياس والعلاج، ولا تكشف الشروط المنشورة وحدها ما يطبَّق على عميل بعينه أو ما قد يتضمنه أمر شراء أو تفاوض خاص.

النسبة الاسمية ليست الأصل الاقتصادي

من السهل التعامل مع 99.99% أو 100% كأنهما سلعتان يمكن مقارنتهما مباشرة. لكن الرقم لا يخبر المشتري ما الذي يجب أن يتعطل حتى تُعد الدقيقة «دقيقة توقف»، ولا يخبره كم من فاتورته يدخل الحساب، ولا ما إذا كان النشر أحادي المنطقة مؤهلاً، ولا ما إذا كان انقطاع قصير متقطع يدخل القياس أصلاً.

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

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

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

وحدة القياس هي العقد

AWS تجعل هذا الفصل واضحاً في EC2. الالتزام الإقليمي البالغ 99.99% يفترض أن تكون جميع النسخ العاملة موزعة بالتزامن على منطقتي إتاحة على الأقل داخل المنطقة المعنية؛ وفي المقابل يوجد التزام على مستوى النسخة المنفردة يبلغ 99.5%. فإذا فشل الالتزام، تنتقل النتيجة إلى شرائح رصيد 10% أو 30% أو 100%، لكن المقام المالي هو فاتورة EC2 الشهرية في المنطقة المتأثرة أو فاتورة النسخة المنفردة بحسب نوع المطالبة، مع استبعاد الدفعات المسبقة لمرة واحدة مثل الدفعات المقدمة لـReserved Instances. (Amazon Web Services, Inc.)

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

Google Compute Engine يرسم حدوداً مختلفة. تُحدد النسبة والرصيد على أساس الشهر التقويمي لكل مشروع ولكل منطقة، أو لكل نسخة في حالة النسخة المنفردة. كما تختلف مستويات الالتزام بحسب ما إذا كان النشر متعدد النطاقات أو أحادي النسخة وبحسب مستوى الشبكة. وفترة التوقف يجب أن تمتد دقيقة متصلة أو أكثر؛ الدقائق الجزئية أو التوقف المتقطع لأقل من دقيقة لا تدخل فترة التوقف. شرائح الرصيد الرئيسية في التصميم المنشور هي 10% و25% و100%، لكن العتبات التي تفعّلها تختلف بحسب نوع الخدمة والتكوين. (Google Cloud)

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

العمارة جزء من ثمن الإتاحة

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

وثائق IBM تميز صراحة بين SLO، بوصفه هدفاً لا أداة تعاقدية، وبين SLA الذي قد ينشئ استحقاقاً لرصيد إذا خولفت الشروط. وفي مثال VPC ذي هدف 99.999%، تقول إرشادات المرونة إن الاستفادة الكاملة من ذلك الهدف لحمل العمل تتطلب، في الحد الأدنى، ثلاثة خوادم افتراضية موزعة على المناطق الثلاث في منطقة متعددة النطاقات وموازن حمل. وهي تضع المسؤولية العامة عن مرونة السحابة وتعافيها على IBM، بينما تبقى مرونة حمل العميل وتعافيه مسؤولية العميل. (IBM Cloud)

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

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

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

المقام النقدي يحدد مقدار الخطر المنقول

إذا كانت الدقيقة هي البسط التقني، فإن الفاتورة المؤهلة هي المقام الاقتصادي.

في Cloudflare، يقتصر الحساب المنشور على الرسوم الشهرية المتكررة المرتبطة بالخدمة، ويصف SLA الرصيد بأنه العلاج الحصري لمخالفة الاتفاق. كما يضع سقفاً سنوياً لا يتجاوز ستة أشهر من إجمالي الرسوم الشهرية التراكمية للعميل وفق النص المنشور. (Cloudflare)

في AWS EC2، قد تصل الشريحة إلى 100%، لكن عبارة «100%» لا تعني 100% من خسارة العمل. إنها نسبة من فاتورة EC2 المؤهلة في المنطقة أو النسخة التي أخفقت وفق مستوى المطالبة. وتطبق الأرصدة عادة على دفعات EC2 المستقبلية، مع بعض السلطة التقديرية في طريقة الإيداع. (Amazon Web Services, Inc.)

وفي Google، السقف الإجمالي في شهر فوترة لا يتجاوز المبلغ المستحق للخدمات المشمولة في المناطق التي لم تحقق SLO، ويأتي الرصيد للاستخدام المستقبلي. (Google Cloud)

أما وثيقة Oracle PaaS/IaaS المرجعية، فالنسخة التي يعرضها الرابط حالياً تحمل تاريخ يوليو/تموز 2026. وهي تسمح بتصاميم SLA تشمل الإتاحة والإدارة والأداء بحسب الخدمة، وتحسب الرصيد كنسبة من صافي الرسوم المدفوعة للكمية المستخدمة فعلاً من الخدمة غير المطابقة خلال فترة القياس. كما لا يمكن أن يتجاوز إجمالي الرصيد الرسوم المدفوعة للكمية المعنية من الخدمة غير المطابقة في الفترة ذات الصلة. (Oracle)

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

ومن هنا يمكن تعريف «فجوة SLA» ببساطة: الفرق بين التعرض الاقتصادي الفعلي للحمل وبين العلاج المالي الذي تنقله شروط الخدمة إلى المزود.

المطالبة ليست عملاً إدارياً لاحقاً

العلاج الذي لا يمكن إثباته في وقته ليس علاجاً ذا قيمة كاملة.

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

AWS تمنح مهلة أطول من الأيام الخمسة، لكنها تجعل ملف الإثبات محدداً أيضاً: يجب أن تصل المطالبة قبل نهاية دورة الفوترة الثانية بعد الحادث، وتتضمن التواريخ والأوقات، والمنطقة أو منطقة الإتاحة بحسب نوع المطالبة، ومعرّفات الموارد، وسجلات الطلبات أو البيانات اللازمة للتحقق. عدم تقديم المعلومات المطلوبة قد يسقط الاستحقاق. (Amazon Web Services, Inc.)

Google تطلب الإخطار خلال 60 يوماً من نشوء الأهلية للرصيد، مع سجلات تبين فترات التوقف وتواريخها وأوقاتها. (Google Cloud)

Oracle تطلب، ضمن وثيقتها العامة، معلومات مثل اسم الخدمة، ووصف الظروف، ووقت التوقف ومدته، والمنطقة، وOCIDs ذات الصلة، ومحاولات الحل، والوثائق أو السجلات المؤيدة، ويجب أن تستلم المطالبة خلال 60 يوماً تقويمياً من وقوع المشكلة. (Oracle)

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

منع الجمع يحدد سقف الحادث

هناك فرق آخر يختفي وراء النسب: هل يمكن لحادث واحد أن يولد علاجات متعددة؟

AWS لا تسمح بجمع المطالبة الإقليمية ومطالبة النسخة للنسخة نفسها. يجب اختيار أحد المسارين. (Amazon Web Services, Inc.)

Google، حيث ينطبق الأمر، لا تمنح للآلة الافتراضية نفسها رصيداً باعتبارها نسخة منفردة وباعتبارها جزءاً من نشر متعدد المناطق عن التوقف نفسه. (Google Cloud)

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

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

من رصيد الخدمة إلى إتاحة العمل

إذا تعطل مورد حوسبة، فذلك لا يعني بالضرورة أن رحلة المستخدم توقفت. وإذا بقي المورد «متاحاً» وفق تعريف SLA، فذلك لا يعني بالضرورة أن رحلة المستخدم نجحت.

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

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

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

في معظم الحالات، تبقى بين السؤالين فجوة. تلك الفجوة يجب ألا تختفي داخل شعار «أربع تسعات». يجب تسعيرها.

الخطر الذي لا ينتقل يجب أن يذهب إلى مكان ما

ما لا ينتقل إلى المزود عبر SLA لا يختفي. يبقى في ميزانية المخاطر الخاصة بالمشتري.

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

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

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

المصادر