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

التخطيط للطاقة وتوقع الطلب

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

التخطيط للطاقة وتوقع الطلب

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

لماذا تختلف أعطال الطاقة عن غيرها

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

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

الركيزة الأولى: نمذجة النمو العضوي

النمو العضوي هو الزيادة البطيئة المتوقعة في حركة المرور المدفوعة باكتساب المستخدمين والأنماط الموسمية وتوسع المنتج. يُنمذج بعمل استخراج تاريخي لمعدلات الطلبات وتناسبها مع اتجاه — خطي أو أسي عادةً اعتماداً على مرحلة دورة حياة المنتج.

يعتمد سير عمل SRE القياسي على تصدير إشارة طاقة رئيسية (RPS أو QPS أو الاتصالات النشطة) من Prometheus وإسقاطها للأمام. نهج بسيط يستخدم دالة predict_linear() في PromQL التي تناسب خطاً بأقل المربعات عبر آخر N دقيقة من البيانات وتستقرئ للأمام:

# إسقاط معدل الطلبات الحالي للأمام 30 يوماً
# باستخدام آخر 7 أيام من البيانات كاتجاه أساسي
predict_linear(
  http_requests_total{job="api-server"}[7d],
  30 * 24 * 3600
)

يُعيد هذا الاستعلام تقديراً يوضح موضع RPS خلال 30 يوماً إن استمر الاتجاه الحالي. شغّل هذا على إشارات الطاقة الرئيسية — RPS واشباع وحدة المعالجة المركزية واستخدام الذاكرة ومعدل امتلاء التخزين — وقارن القيم المتوقعة بحدود مواردك.

اختيار الإشارة مهم. معدل الطلبات مؤشر متقدم؛ وحدة المعالجة المركزية والذاكرة مؤشران متأخران. ابنِ نموذج النمو على المقياس الذي يؤثر بشكل مباشر في استهلاك الموارد لعبء عملك — بالنسبة لواجهة API عديمة الحالة هو RPS؛ لقاعدة البيانات هو معدل الكتابة والاتصالات النشطة؛ لمخزن البيانات الثنائية هو البايتات المخزنة.

للتنبؤ في بيئة الإنتاج، قم بتصدير التجميعات اليومية إلى مخزن بيانات سلاسل زمنية (BigQuery أو ClickHouse) واستخدم مكتبة إحصائية مناسبة. تستخدم Google وMeta كلتاهما تمهيد أُسي هولت-وينترز لالتقاط الموسمية — الإيقاع الأسبوعي حيث تنخفض حركة المرور في عطلات نهاية الأسبوع حقيقي ولا ينبغي إخفاؤه بتناسب خطي ساذج.

الركيزة الثانية: التخطيط لارتفاع حركة الإطلاق

عمليات الإطلاق تُخفق الخدمات. إطلاق منتج رئيسي أو حملة فيروسية أو ميزة App Store يمكن أن تُسبب ارتفاعاً حاداً في حركة المرور بمقدار 5 إلى 20 ضعفاً في دقائق. نموذج النمو العضوي عديم الفائدة هنا — تحتاج إلى عملية منفصلة لحركة مرور الإطلاق.

تتضمن بوابة مراجعة جاهزية الإنتاج (PRR) في SRE قسم طاقة الإطلاق الإلزامي بثلاثة مدخلات:

ذروة QPS المتوقعة: تُقدمها الإدارة أو التسويق بناءً على توقعات اكتساب المستخدمين. طبّق معامل أمان (1.5× إلى 2×) لأن هذه التقديرات تكون دائماً أقل من الواقع.
تكلفة الموارد لكل طلب: يُقاس عبر اختبار الحمل — ثواني CPU لكل طلب، تخصيص الذاكرة، استدعاءات العمليات المتشعبة. لا تقدّر؛ قِس تحت حمل واقعي.
وقت التوسع: كم يستغرق أداة التوسع التلقائي لإضافة الطاقة؟ لـ Kubernetes HPA مع صور حاويات باردة واحترار JVM، وقت التوسع الواقعي هو 3 إلى 5 دقائق. خلال تلك الفترة يجب أن تمتص الاندفاع من الهامش الاحتياطي الموجود.

قم بتشغيل محاكاة حركة المرور قبل كل إطلاق رئيسي. كحد أدنى، استخدم اختبار حمل يرتفع تدريجياً من خط الأساس إلى ضعفَي الذروة المتوقعة ويقيس النسب المئوية للكمون ومعدل الخطأ وإشباع الموارد. أدوات مثل k6 وvegeta وlocust هي المعيار لهذا الغرض:

# اختبار تدرجي k6 يحاكي ارتفاع الإطلاق
# احفظ باسم launch-test.js وشغّل: k6 run launch-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // الإحماء إلى خط الأساس
    { duration: '5m', target: 100 },   // الثبات عند خط الأساس
    { duration: '2m', target: 2000 },  // التدرج إلى 20x ارتفاع حاد
    { duration: '5m', target: 2000 },  // الثبات عند الذروة
    { duration: '2m', target: 0 },     // التراجع التدريجي
  ],
  thresholds: {
    http_req_duration: ['p(99)<500'],  // النسبة المئوية 99 < 500ms
    http_req_failed:   ['rate<0.01'],   // معدل الخطأ < 1%
  },
};

export default function () {
  const res = http.get('https://staging.api.example.com/v1/feed');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

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

الركيزة الثالثة: سياسة الهامش الاحتياطي

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

تتباين أهداف الهامش الاحتياطي القياسية في شركات التقنية الكبرى حسب الطبقة:

الحوسبة عديمة الحالة (حاويات Kubernetes، Lambda): أبقِ ذروة CPU والذاكرة أقل من 70 % من طاقة الكتلة. الـ 30 % المتبقية تمتص الارتفاعات العضوية وأعطال العقد المفردة (N+1) وتأخر أداة التوسع التلقائي.
قواعد البيانات (العقد الرئيسية): أبقِ ذروة CPU أقل من 50 % وIOPS أقل من 60 %. تتدهور قواعد البيانات بشكل غير خطي قرب الإشباع — عقدة رئيسية عند 80 % CPU في الحالة العادية ستنهار خلال نافذة النسخ الاحتياطي أو حادثة استعلام بطيء.
التخزين: تنبيه عند 70 % امتلاء؛ إيقاف صارم لتوفير بيانات جديدة عند 80 %. يمتلئ التخزين أسرع مما يمكن لأي أداة توسع تلقائي التفاعل معه لأنه عادةً لا يُوسَّع تلقائياً.

فعّل الهامش الاحتياطي بكتابة قواعد تنبيه Prometheus تُطلق قبل بلوغ الحد وليس بعده:

# prometheus/rules/capacity.yaml
groups:
  - name: capacity.headroom
    rules:
      - alert: ComputeHeadroomLow
        expr: |
          (
            sum by (cluster) (rate(container_cpu_usage_seconds_total{container!=""}[5m]))
            /
            sum by (cluster) (kube_node_status_allocatable{resource="cpu"})
          ) > 0.70
        for: 15m
        labels:
          severity: warning
          team: sre
        annotations:
          summary: "Cluster {{ $labels.cluster }} CPU headroom below 30%"
          description: "CPU utilization is {{ $value | humanizePercentage }}. Provision additional nodes before headroom is exhausted."

      - alert: DatabasePrimaryHighCPU
        expr: |
          avg by (instance) (
            rate(mysql_global_status_cpu_time[5m])
          ) > 0.50
        for: 10m
        labels:
          severity: warning
          team: sre-dba
        annotations:
          summary: "DB primary {{ $labels.instance }} CPU exceeds 50% headroom threshold"

الجمع بين العناصر: دورية مراجعة الطاقة

التخطيط للطاقة ليس تمريناً لمرة واحدة. تُجري فرق SRE الناضجة مراجعة طاقة ربع سنوية تُفرز تذاكر التوفير قبل أن تصبح الحاجة ملحّة:

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

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

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

أنماط أعطال الإنتاج الشائعة

الامتلاء الصامت: التخزين أو مجمعات الاتصال التي تمتلئ ببطء على مدى شهور دون أي تنبيه حتى تنهار الخدمة عند 100 %.
أداة التوسع التلقائي لا تواكب: HPA يتوسع على CPU لكن عنق الزجاجة هو اتصالات قاعدة البيانات. الحاويات تتوسع؛ قاعدة البيانات تنهار لأن عدد الاتصالات يزيد مع عدد الحاويات.
حركة الإطلاق أُقلّت تقديرها بمقدار 10 أضعاف: أرسلت التسويق رسالة بريد إلكتروني جماعية لـ 10 ملايين مستخدم عند الساعة 09:00 يوم الاثنين. حتى مع التوسع التلقائي، يتسبب تأخر بدء التشغيل في تراكم طابور انتظار يتصاعد إلى مهلات انتهاء.
انتهاء صلاحية الطاقة المحجوزة: نماذج الحجز السحابية المشتراة لتوفير التكاليف تنتهي صلاحيتها؛ الاحتياطي حسب الطلب غير متاح في المنطقة المستهدفة بسبب حدث طاقة. تحقق دائماً من تواريخ انتهاء صلاحية الحجز في مراجعتك الربع سنوية.

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