الموثوقية: ممارسة SRE والتعافي من الكوارث

الموثوقية: ممارسة SRE والتعافي من الكوارث

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

تصميم المناوبة على المقياس الكبير

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

البنية التي تُثبت نجاعتها هي المناوبة متعددة الطبقات مع حدود ملكية صارمة:

• الطبقة الأولى — مناوبة المنصة (البنية التحتية): تمتلك مستوى البيانات: صحة عُقد Kubernetes، والشبكات، والتخزين، وتوسّع المجموعة التلقائي، وصلاحية الشهادات. تحمل SLA مدته 15 دقيقة للإقرار بحوادث P1. عادةً دوران أسبوعي من 5-7 أشخاص عبر مناطق زمنية مختلفة. لا تصدر تنبيهات إلا على أعراض ثابتة التأثير على حركة المرور الفعلية.
• الطبقة الثانية — مناوبة الخدمة (لكل فريق): كل فريق منتج يمتلك مناوبة خدماته الخاصة. يتم استدعاؤهم عبر توجيهات Alertmanager المحددة بنطاق namespace الخاص بهم، ولا يُصعّدون إلى الطبقة الأولى إلا عندما يكون الجذر في البنية التحتية للمنصة وليس في كود التطبيق.
• الطبقة الثالثة — تصعيد الإدارة: تصعيد آلي بعد 30 دقيقة من عدم الإقرار بحادث P0 من الطبقتين الأولى والثانية. تتولى سياسات التصعيد في PagerDuty هذا دون تدخل بشري.

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

ميزانية الأخطاء كأداة هندسية

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

الآليات التشغيلية التي تجعل ميزانيات الأخطاء تعمل فعلياً:

1. القياس من جانب العميل، ليس الخادم. المقاييس من جانب الخادم تُغفل أعطال DNS وأخطاء CDN وانقطاع TCP في شبكات الجوال. مصدر الحقيقة الرسمي لقياس SLO هو المراقبة الاصطناعية مقترنة ببيانات Real User Monitoring من الواجهة الأمامية.
2. الميزانية مشتركة عبر جميع أسباب الأعطال. حادثة ناجمة عن تطبيق Terraform خاطئ وحادثة ناجمة عن انقطاع مزود DNS تستنزفان نفس الميزانية. هذا مقصود؛ يمنع الفرق من الجدال حول اللوم ويُركّز الطاقة على تقليل جميع أسباب عدم التوفر.
3. سياسة الميزانية وثيقة مكتوبة تُراجع كل ثلاثة أشهر. يجب أن تُجيب السياسة: عندما تنخفض الميزانية إلى أقل من 10%، ماذا يتغير؟ في Google الجواب: جميع إصدارات الميزات لتلك الخدمة تتطلب موافقة SRE؛ أعمال الموثوقية تأخذ أولوية على أعمال الميزات. بدون سياسة مكتوبة مُطبّقة، تصبح ميزانيات الأخطاء مسرحاً لا أكثر.
4. تتبع استهلاك الميزانية على مستوى السبرينت. لوحة Grafana تُظهر معدل حرق الميزانية على مدى 28 يوماً لكل خدمة، مرئية لكل من SREs ومديري المنتج، هي الأداة الأكثر فعالية للتوافق.

تصميم طبقات التعافي من الكوارث

اختيار طبقة DR هو توازن بين التكلفة والاسترداد، يُعبّر عنه برقمين: RTO (هدف وقت الاسترداد — كم من الوقت حتى تُستعاد الخدمة) وRPO (هدف نقطة الاسترداد — ما مقدار فقدان البيانات المقبول). في شركات التقنية الكبرى، لكل خدمة إجاباتها المختلفة، ويجب أن تدعم المنصة جميعها.

الفكرة الجوهرية هي أن ليس كل خدمة تحتاج Tier 0. خدمة معالجة المدفوعات وخدمة المصادقة تستحق Active-Active متعددة المناطق. لوحة التحليلات الداخلية ولوحة الإدارة لا تحتاج ذلك. تطبيق Tier 0 بشكل موحد يضاعف الإنفاق على البنية التحتية دون أي فائدة للمستخدم في حالة الأعباء منخفضة الأهمية. احتفظ بـسجل أهمية الخدمات — جدول بيانات أو صفحة Confluence تُحدَّث كل ثلاثة أشهر — يربط كل خدمة بطبقة DR ويسجّل المبرر التجاري. بدون هذا السجل، تنجرف قرارات طبقة DR وفق تفضيلات المهندسين لا متطلبات العمل.

التدريبات الميدانية: إثبات أن خطة DR حقيقية

خطة DR لم تُنفَّذ قط تحت الضغط هي مجرد وثيقة خيالية. التدريبات الميدانية هي الانضباط الهندسي المتمثل في تشغيل سيناريوهات أعطال متحكَّم بها في بيئة الإنتاج للتحقق من صحة ادعاءات RTO وRPO.

هيكل برنامج التدريبات الميدانية في شركات التقنية الكبرى:

1. تجاوز DR كامل فصلياً: محاكاة فقدان منطقة كاملة. قطع حركة المرور عن المنطقة الأساسية، وترقية النسخة الاحتياطية لـ Aurora، والتحقق من أن جميع الخدمات تبدأ في منطقة DR ضمن RTO المُحدد، وقياس فقدان البيانات الفعلي مقابل هدف RPO.
2. تجارب الفوضى الشهرية: نطاق أضيق. اقتل pod عشوائياً في namespace حرجة، أو أضف تأخيراً 200 مللي ثانية على اتصالات خدمة المدفوعات الصادرة. استخدم Chaos Mesh أو AWS Fault Injection Simulator. الغلق يجب أن يكون محدوداً — حدّد فرضية الحالة الطبيعية، أدخل الخلل، لاحظ، واسترجع في غضون 30 دقيقة.
3. اختبار أعطال اصطناعية أسبوعياً على Staging: آلي وبدون مراقبة بشرية. اختبار k6 للتحميل مقترن بحقن أعطال مكتوبة. نتيجة نجاح/فشل تُرسل إلى Slack. يمنع الانحدار بين التدريبات الميدانية.

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

دولاب الموثوقية المتسارع

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