المراقبة واتفاقيات مستوى الخدمة

كل نمط في هذا الموضوع يفترض أنك تكتشف

تكرار Multi-AZ، وفحوصات سلامة Auto Scaling، وخطة تعافٍ من كوارث مُختبَرة: كل نمط غطّاه هذا الموضوع حتى الآن يفترض بصمت شيئاً واحداً. يفترض أنك تكتشف وقوع عطل، ويُفضَّل قبل أن يكتشفه المستخدم، ويفترض أن يستطيع أحد لاحقاً أن يقول بأرقام دقيقة كم كان النظام موثوقاً فعلياً. يغطي هذا الدرس النصفين معاً: المراقبة، وهي كيف تكتشف، واتفاقيات مستوى الخدمة، وهي الوعد الموثَّق بعدد المرات التي كان يجب ألا تحتاج فيها للاكتشاف أصلاً.

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

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

Amazon CloudWatch هو تطبيق AWS للّبنات الثلاث جميعاً: يجمع مقاييس تلقائياً من معظم خدمات AWS، ويخزّن السجلات ويتيح الاستعلام عنها، ويتيح تعريف تنبيهات فوق أي منهما. مثال ملموس: يراقب تنبيه متوسط استخدام المعالج على فترات مدتها 5 دقائق، وإن بقي فوق 80% لـ3 فترات متتالية، يُطلَق التنبيه، وقد يستدعي مهندس مناوبة، أو يتصل مباشرة بربط الدرس السابق، بسياسة تتبع هدف في Auto Scaling تطلق طاقة إضافية. تؤدي Azure Monitor وGoogle Cloud Operations الدور نفسه على منصتيهما؛ تتغيّر المفردات قليلاً، لكن المقاييس والسجلات والتنبيهات القطع الثلاث نفسها في كل مكان.

SLI وSLO وSLA: القياس، والاستهداف، والوعد

تُستخدم هذه المصطلحات الثلاثة بالتبادل تقريباً في الحديث العادي، والحد الفاصل بينها في الامتحان يستحق تعلّماً دقيقاً.

مؤشر مستوى الخدمة (SLI) قياس كمّي لأداء خدمة فعلياً، كنسبة الطلبات الناجحة. هدف مستوى الخدمة (SLO) هو الهدف الداخلي الذي يضعه فريق لذلك المؤشر، كـ"نستهدف 99.95% طلبات ناجحة". اتفاقية مستوى الخدمة (SLA) هي النسخة الخارجية التعاقدية: وعد للعملاء، إن أُخفِق فيه، يحمل تبعات مالية، عادة رصيد خدمة.

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

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

التسع(ات): ماذا تكلّف نسبة وقت التشغيل من توقف فعلي

تُقارَن أرقام الإتاحة بشكل عابر، "نحن عند 4 تسعات"، دون أن يستحضر ذلك دائماً معناها الفعلي بالساعات. كل تسعة إضافية تقسّم التوقف المسموح تقريباً على 10، وهذا سبب كون القفزة من 99.9% إلى 99.99% التزاماً هندسياً أكبر بكثير مما توحي به الأرقام وحدها.

تستهدف أغلب منتجات SaaS وواجهات البرمجة 3 تسعات. تُحفَظ 5 تسعات للأنظمة التي حتى دقائق قليلة من توقف سنوي فيها تحمل تبعات مالية أو سلامة حقيقية، وتكلّف هندستها أكثر بما يتناسب مع ذلك.

مثال محلول: قراءة اتفاقية مستوى خدمة حقيقية

اتفاقية مستوى خدمة Amazon EC2 مثال ملموس ومفيد. تلتزم بنسبة تشغيل شهرية على مستوى Region لا تقل عن 99.99%، وبنسبة منفصلة على مستوى النسخة الفردية لا تقل عن 99.5%. إن قصرت نسبة تشغيل Region الفعلية في شهر معين، فمستويات التعويض 10% لنطاق 99.0% حتى أقل من 99.99%، و30% لنطاق 95.0% حتى أقل من 99.0%، و100% لما دون 95.0%.

بالتحديد: إن هبطت نسبة تشغيل EC2 على مستوى Region إلى 96.2% في شهر ما، تقع هذه النسبة في نطاق 95.0% إلى أقل من 99.0%، ويستحق العميل تعويضاً بنسبة 30% على فاتورة تلك الخدمة لذلك الشهر، يُطبَّق تلقائياً أو بناء على طلب حسب المزوّد، لا استرداداً نقدياً ولا تعويضاً عن أي إيرادات فقدها عمل العميل نفسه.

ما تعِد به اتفاقية مستوى الخدمة، وما لا تعِد به

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

الحد الفاصل: ترابط الخدمات يزيد الرقم سوءاً لا تحسيناً

نادراً ما يعتمد حمل عمل على خدمة واحدة فقط. اربط 3 خدمات بنسب إتاحة فردية 99.99% و99.95% و99.9%، ومن المغري افتراض أن أقواها يساعد على رفع المعدل. لا يفعل: تضرب الإتاحة المركّبة الاحتمالات الفردية بدل حساب متوسطها، فينزل حاصل ضرب 99.99% في 99.95% في 99.9% إلى نحو 99.84%، أسوأ من أي مكوّن منفرد في السلسلة. كل تبعية مضافة ضريبة على الموثوقية الإجمالية، ولهذا يحسب المهندسون كم خدمة يلمسها فعلياً مسار طلب حرج، لا فقط مدى موثوقية كل خدمة بمفردها.

إشارات الامتحان: مطابقة سيناريو بالمصطلح الصحيح

إلى أين يقودك هذا

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