هندسة موثوقية المواقع (SRE)

مراجعات الموثوقية والجاهزية للإنتاج

18 دقيقة الدرس 7 من 29

مراجعات الموثوقية والجاهزية للإنتاج

لكل انقطاع تاريخٌ سابق. في مكان ما قبل أن ينطلق التنبيه، اتخذ فريق قراراً — أو تجاوز قراراً — جعل الفشل ممكناً. مراجعة الجاهزية للإنتاج (PRR) هي إجابة SRE على هذا النمط: بوابة هيكلية قبل الإطلاق تُجبر فرق الهندسة على الإجابة عن الأسئلة الصعبة قبل انطلاق الخدمة في الإنتاج، لا بعد أن يتأثر المستخدمون. في Google، لا تنتقل أي خدمة إلى تغطية SRE المناوبة دون اجتياز PRR. في Netflix، تُدمج في مسار النشر تحت اسم "LaunchReady". تُشغّل Stripe قائمة "Production Readiness Checklist" ضمن كل إصدار مهم. التفاصيل تختلف؛ والهدف واحد — إظهار ما هو ضمني صراحةً وتوثيقه قبل معالجة طلب إنتاج واحد.

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

ما هي PRR — وما ليست عليه

PRR ليست مراجعة أمنية ولا مراجعة تصميم ولا اختبار أداء — وإن كانت تستند إلى الثلاثة. إنها محادثة موثوقية بين الفريق الذي يبني الخدمة والفريق الذي سيشغّلها (في الغالب SRE). مهمتها الإجابة عن: "إذا فشلت هذه الخدمة الساعة 3 صباحاً يوم الأحد، هل يمكننا رصد الأمر واحتواؤه والتعافي — دون أعمال بطولية؟"

تنتج PRR عادةً منتَجَين: وثيقة PRR (الاستبيان المكتمل مع الأدلة) وقائمة الحواجز الإطلاقية (الثغرات الواجب تصحيحها قبل الإطلاق). العناصر في قائمة الحواجز ليست اقتراحات اختيارية — إنها بوابات صارمة. الخدمة التي لديها حواجز P0 لا تنطلق.

PRR هي قوة دافعة، لا مراسم. القيمة ليست في الوثيقة — بل في المحادثة التي تفرضها الوثيقة. فريق يجب أن يُجيب عن "ما هو RTO في حالة فشل قاعدة البيانات الكامل؟" إما سيكتشف أنه لم يفكر في الأمر (جيد: أصلحه قبل الإطلاق) أو يؤكد أنه فعل (جيد: ثقة). كلا النتيجتين تُحسّن الموثوقية. تجاوز PRR ولن تحصل على أي منهما.

دورة حياة PRR

PRR ليست حدثاً لمرة واحدة. إنها ترافق الخدمة طوال دورة حياتها:

PRR قبل الإطلاق — قبل أول طلب إنتاج. الأهم على الإطلاق. ترصد الثغرات الجوهرية في المراقبة ودفاتر التشغيل والتخطيط للفشل.
PRR التغيير المهم — يُطلَق بسبب تغييرات معمارية كبيرة (قاعدة بيانات جديدة، تبعية جديدة، توقع حركة مرور أكبر بـ 10 أضعاف). ليس مع كل إصدار؛ فقط للتغييرات التي تُغيّر ملف المخاطر جوهرياً.
مراجعة PRR السنوية — تتطور الخدمات. دفتر التشغيل المكتوب قبل 18 شهراً قد لا يعكس الواقع بعد الآن. المراجعات السنوية ترصد الانجراف بين الوثائق والتطبيق.

دورة حياة PRR: التصميم يتدفق إلى مراجعة ما قبل الإطلاق، والحواجز تعود إلى حلقة الإصلاح، والخدمة المعتمدة تعود إلى دورة PRR للتغييرات المهمة والمراجعات السنوية.

قائمة PRR: ما تسأل عنه كبرى شركات التقنية فعلياً

القائمة هي قلب PRR. لكل بند مالك وحالة (مُستوفى / غير مُستوفى / لا ينطبق) وأدلة. فيما يلي المجالات والأسئلة المحددة التي تحجب الإطلاق عند عدم الإجابة عنها.

1. المراقبة والرصد

هل الإشارات الذهبية الأربع (الكمون، الحركة، الأخطاء، التشبع) مُضمَّنة ومعروضة في لوحات مراقبة؟
هل توجد لوحة Tier-0 تعرض معدل استهلاك SLO في الوقت الحقيقي؟
هل يتم إرسال سجلات منظمة وإمكانية الاستعلام عنها في منصة تجميع السجلات؟
هل التتبع الموزع مُفعَّل ومُعيَّن بمعدل أخذ عينات يحفظ تغطية p99؟
هل هناك canary اصطناعي أو نقطة نهاية للتحقق من الصحة يتم الوصول إليها من خارج الكلاستر؟

2. التنبيهات

هل تنبيهات معدل استهلاك SLO مُعرَّفة في كود (لا في الواجهة)؟
هل دوران المناوبة مُهيَّأ ومُختبَر (هل تلقى جميع الأعضاء صفحة اختبارية)؟
هل مستويات خطورة التنبيه مُعرَّفة (P0 يُوقظ شخصاً؛ P1 لليوم التالي)؟
هل تم اختبار إجهاد التنبيهات — هل حسبت حجم التنبيهات المتوقعة أسبوعياً وتأكدت أنها أقل من 5 صفحات قابلة للتنفيذ لكل مناوبة؟

3. دفاتر التشغيل والاستجابة للحوادث

هل يوجد دفتر تشغيل لكل تنبيه P0؟ هل يجتاز "اختبار 3 صباحاً" — هل يستطيع مهندس غير مألوف بالخدمة اتباعه؟
هل عملية إدارة الحوادث موثقة (من تُنبّه، مسار التصعيد، قناة التواصل)؟
هل أُجريت تمرين يوم لعبة على سيناريو فشل واحد على الأقل؟

4. الطاقة الاستيعابية وإدارة الحركة

هل ملف حركة الإطلاق مُعرَّف (RPS المتوقع، هدف كمون p99، حجم البيانات)؟
هل أُجري اختبار التحميل بضعف حركة الإطلاق المتوقعة؟ بعشرة أضعاف؟
هل توجد آليات تخفيف الحمل أو قاطع الدارة؟ ما الذي يحدث عند فشل تبعية upstream؟
هل الضبط التلقائي للحجم مُهيَّأ ومُختبَر ومحدود بزمن (ما الحد الأقصى، وهل نمذجت التكلفة عنده)؟

5. التراجع والاسترداد

هل هناك إجراء تراجع مُختبَر؟ كم يستغرق؟
هل ترحيلات قاعدة البيانات قابلة للعكس؟ إن لم تكن، هل يوجد خطة ترفيع نسخة قراءة؟
هل RTO (هدف وقت الاسترداد) مُعرَّف، وهل يتوافق مع SLA؟
هل أُجري اختبار DR خلال الستة أشهر الماضية؟

6. الأمان والامتثال

هل تُدار الأسرار عبر مدير أسرار (Vault أو AWS Secrets Manager أو GCP Secret Manager) — لا في متغيرات بيئة مضمّنة في الصور؟
هل mTLS مُفعَّل بين الخدمات، أو هل حدود الشبكة مؤمَّنة بطريقة أخرى؟
هل اكتمل نموذج التهديد؟
هل سجلات التدقيق مُفعَّلة لجميع عمليات plane البيانات؟

أتمت جمع الأدلة. الجزء الأكثر إيلاماً في PRR هو جمع الأدلة ("أرِني اللوحة"، "شارك رابط دفتر التشغيل"). اربط قالب PRR بأدواتك: سير عمل GitHub Actions يفتح إشكالية PRR مُعبَّأة مسبقاً بروابط لوحة Grafana وجدول المناوبة في PagerDuty ونتائج اختبار التحميل في Datadog يعني أن الفريق يقضي وقته في إصلاح الثغرات لا في البحث عن روابط.

كتابة قائمة الإطلاق ككود

القائمة تعيش في التحكم بالإصدار جنباً إلى جنب مع الخدمة. صيغة بسيطة ودائمة هي ملف YAML مُلتزم في مستودع الخدمة — تُحللها CI لفرض بوابات الإطلاق:

# .prr/checklist.yaml  — مُلتزم بجانب كود الخدمة
service: payment-processor
version: "1.4.0"
prr_status: approved          # draft | in_review | approved | blocked
approved_by: sreteam@company.com
approved_at: "2025-09-15"

observability:
  golden_signals_dashboard:
    status: met
    evidence: "https://grafana.internal/d/payment-overview"
  slo_burn_alert:
    status: met
    evidence: "https://github.com/org/payment/blob/main/alerts/slo.yaml"
  distributed_tracing:
    status: met
    evidence: "Tempo sampling at 10% base, 100% on error"
  synthetic_canary:
    status: met
    evidence: "Blackbox exporter probing /healthz every 30s from us-east-1, eu-west-1"

alerting:
  oncall_rotation_tested:
    status: met
    evidence: "Test page sent to all 4 rotation members 2025-09-12"
  alert_volume_within_threshold:
    status: met
    evidence: "Projected 2.1 pages/week based on staging burn rate"

capacity:
  load_test_2x:
    status: met
    evidence: "k6 run at 1,200 RPS (2x 600 baseline) — p99 <= 180ms, 0 errors"
  load_test_10x:
    status: not_met          # حاجز
    blocker_severity: P1
    blocker_owner: platform-team
    due: "2025-09-22"
    notes: "10x test shows DB connection pool exhaustion at 6,000 RPS. PgBouncer config update in progress."
  circuit_breaker:
    status: met
    evidence: "Resilience4j configured; fallback returns cached response"

rollback:
  rollback_procedure_tested:
    status: met
    evidence: "Rollback drill completed 2025-09-10, RTO measured at 4 min"
  database_migrations_reversible:
    status: met
    evidence: "All migrations use up/down; tested against prod-clone"

security:
  secrets_in_vault:
    status: met
    evidence: "All env vars read from Vault dynamic secrets; no secrets in image"
  threat_model_complete:
    status: met
    evidence: "STRIDE model in Confluence: https://wiki.internal/payment-threat-model"

تفشل مهمة CI في الدمج إذا كان أي بند يحمل status: not_met وblocker_severity: P0. تُطلق الحواجز P1 تعليقاً تحذيرياً على طلب السحب لكن لا تحجبه — يجب تسويتها قبل مراجعة ما بعد الإطلاق.

#!/usr/bin/env python3
# scripts/prr_gate.py  — يُشغَّل في CI عند كل دفع لفرع الإصدار
import sys, yaml, pathlib

checklist = yaml.safe_load(pathlib.Path(".prr/checklist.yaml").read_text())
p0_blockers = []

for domain, items in checklist.items():
    if not isinstance(items, dict):
        continue
    for item_name, item in items.items():
        if not isinstance(item, dict):
            continue
        if item.get("status") == "not_met" and item.get("blocker_severity") == "P0":
            p0_blockers.append(f"  - {domain}.{item_name}: {item.get('notes','no notes')}")

if p0_blockers:
    print("PRR GATE FAILED — P0 blockers present:")
    print("\n".join(p0_blockers))
    sys.exit(1)

print("PRR gate passed. No P0 blockers.")

نقل خدمة إلى الإنتاج: تسلسل يوم الإطلاق

الموافقة على PRR لا تعني "انشر فوراً". إطلاقات كبرى شركات التقنية تتبع تسلسل طرح تدريجي يُحدد نطاق الأضرار ويؤكد الموثوقية عند كل خطوة قبل توسيع التعرض.

Canary داخلي (0.1% من حركة الإنتاج) — نشر على حارزة واحدة، تأكيد أن الإشارات الذهبية طبيعية لمدة 24 ساعة. أي استهلاك SLO فوق 10x يُطلق تراجعاً تلقائياً.
Canary موسّع (1-5%) — نقع 48 ساعة. تنخفض عتبة تنبيه استهلاك SLO من 10x إلى 2x. تأكيد أن هدف كمون p99 مُحقَّق تحت حمل المستخدم الحقيقي لا الاصطناعي.
طرح منطقة تلو منطقة (10% ← 25% ← 50% ← 100%) — كل مرحلة مُقيَّدة بخطوة موافقة يدوية في مسار النشر. يُوقّع المهندس المناوب؛ يُسجّل المسار من وافق ومتى.
مراجعة ما بعد الإطلاق (48-72 ساعة بعد الطرح الكامل) — تأكيد أن SLO محقَّق، ومعدل الاستهلاك طبيعي، ولا توجد أخطاء طويلة الذيل غير متوقعة.

الوقت الأخطر هو مباشرة بعد إطلاق ناجح. تسترخي الفرق — الخدمة "تعمل" — وتبقى بنود PRR المؤجلة مؤجلة. حواجز P1 من PRR يجب أن يكون لها مالك وتاريخ استحقاق مُفرض بنظام إدارة المشاريع. الخدمة التي تنطلق مع حواجز P1 غير محلولة وبدون تذكير دوري في التقويم ستحمل تلك المخاطر إلى ما لا نهاية. أغلق الحلقة خلال سبرينتين.

أنماط الفشل الإنتاجي التي ترصدها PRR

دفاتر تشغيل مفقودة لأنماط فشل معروفة: الفريق يعرف أن قاعدة البيانات يمكن أن تفشل لكنه لم يكتب قط ما يجب فعله. سؤال قائمة PRR "هل يوجد دفتر تشغيل لكل تنبيه P0؟" يجعل ذلك مرئياً.
تراجع غير مُختبَر: تراجع لم يُتدرّب عليه قط يستغرق 45 دقيقة تحت ضغط الحادث. نفس الإجراء المُتدرَّب عليه ثلاث مرات يستغرق 4 دقائق. تطلب PRR أدلة لا مجرد توثيق.
إعداد خاطئ لمجموعة الاتصالات عند الحجم: الخدمة تعمل بشكل جيد على 100 RPS في staging لكنها تُنهك مجموعة اتصالات قاعدة البيانات عند 800 RPS في الإنتاج. متطلب اختبار التحميل 10x يكشف هذا قبل الإطلاق.
اعتماد صامت على منطقة توافر واحدة: الخدمة "متعددة المناطق" في مخطط المعمارية لكن جميع التخزين المؤقت في AZ واحدة. بند "اختبار DR" في PRR يرصد هذا الانجراف.
فجوات تنبيه-لا دفتر تشغيل: ينطلق تنبيه لكن المهندس المناوب لا يعرف ما يعنيه أو ما يفعله. كل تنبيه P0 يجب أن يرتبط 1:1 بقسم في دفتر التشغيل يشرح الإشارة وأسبابها وخطوات الإصلاح.

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