تخطيط السعة والتوسع التلقائي

مراجعات السعة وممارسة التنبؤ

18 دقيقة الدرس 9 من 27

مراجعات السعة وممارسة التنبؤ

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

مراجعات الإطلاق: بوابة سعة الإنتاج

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

تغطي مراجعة الإطلاق المنظمة جيداً أربعة مجالات:

شكل حركة المرور وتقديرات الذروة. ما معدل الطلبات المتوقع عند p50 وp99 لحظة الإطلاق؟ هل حركة المرور متقطعة (تخفيض مفاجئ، أو مشغّل cron يطلق بداية كل ساعة) أم سلسة؟ كيف تتدهور حركة المرور بأمان — هل يوجد طبقة CDN أو قائمة انتظار، أم ينزل الحمل مباشرة على الأصل؟
التحقق من تحجيم الموارد. أجرِ اختبارات الحمل عند 150% من أعلى توقع للذروة، وتأكد من وجود هامش في استهلاك CPU والذاكرة على الخدمة وتبعياتها (قواعد البيانات، وذاكرات التخزين المؤقت، وسماسرة الرسائل). تحقق من أن HPA سيعمل وأن الحاويات الجديدة ستصل قبل انتهاك الـ SLO.
عقود سعة التبعيات. يجب أن تؤكد كل خدمة مصدر أو وجهة أن لديها هامشاً يستوعب الإطلاق. خدمة واحدة في المصب بلا هامش ستتسبب في تدهور متتالي تجاه الخدمة الجديدة بغض النظر عن حجمها.
خطة التراجع وتخفيف الحمل. وثّق الأوامر الدقيقة التي تعكس الطرح، وتوقف علامة الميزة، أو تنشط تخفيف الحمل عند تعثر الإطلاق. يجب تدريب هذه الخطة مسبقاً، لا كتابتها للمرة الأولى خلال حادثة.

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

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

// launch-ramp.js  --  k6 load test for launch review
// Run: k6 run --out influxdb=http://influx:8086/k6 launch-ramp.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '5m',  target: 200  },   // warm-up
    { duration: '10m', target: 500  },   // normal launch traffic
    { duration: '5m',  target: 1000 },   // peak burst (150% of forecast)
    { duration: '5m',  target: 1000 },   // sustain peak
    { duration: '5m',  target: 0    },   // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<250', 'p(99)<500'],  // SLO gates
    http_req_failed:   ['rate<0.01'],
  },
};

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

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

نمذجة النمو: ترجمة خطط الأعمال إلى أرقام موارد

تحوّل نمذجة النمو خارطة طريق المنتج والتوقعات التجارية إلى توقعات موارد قابلة للتنفيذ. المخرج ليس رقماً واحداً — بل نطاق بفترات ثقة، يُحدَّث بانتظام (عادةً شهرياً).

يعتمد أبسط نموذج فعّال على ثلاثة مدخلات:

الخط الأساسي الحالي. استهلاك الموارد المقاس لكل وحدة نشاط تجاري (الطلبات لكل مستخدم نشط يومياً، كتابات صفوف قاعدة البيانات لكل طلب، GB صادر لكل مشاهدة فيديو). استخرج هذه البيانات من منظومة الرصد — مقاييس Prometheus مقترنة بأحداث تحليلات الأعمال.
معدل النمو. نمو المستخدمين، أو حجم المعاملات، أو حجم البيانات — أيهما يُحرك عامل التكلفة الرئيسي. استخدم توقعات فريق المنتج الملتزمة للتخطيط، وسيناريو P90 للإمكانات الصاعدة للهامش.
تحسين الكفاءة. كل ربع سنة، تخفّض تحسينات التخزين المؤقت وتحسينات الاستعلام وترقيات البروتوكول تكلفة الموارد لكل وحدة. نمّذج تحسيناً محافظاً بنسبة 10–15% سنوياً حتى لا تُبالغ في التوفير مقابل تكلفة لكل وحدة ستتقلص.

يسحب النص التالي بيانات Prometheus للـ 90 يوماً الماضية ويلائم خطاً اتجاهياً للمساعدة في تثبيت النموذج:

#!/usr/bin/env python3
# capacity_forecast.py — fit a trend line to Prometheus CPU usage and project forward
# pip install requests numpy pandas matplotlib

import requests, numpy as np, pandas as pd
import matplotlib.pyplot as plt
from datetime import datetime, timedelta

PROM = "http://prometheus.monitoring.svc:9090"
QUERY = 'sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m]))'

end   = datetime.utcnow()
start = end - timedelta(days=90)

resp = requests.get(f"{PROM}/api/v1/query_range", params={
    "query": QUERY,
    "start": start.isoformat() + "Z",
    "end":   end.isoformat()   + "Z",
    "step":  "1h",
}).json()

ts  = [float(v[0]) for v in resp["data"]["result"][0]["values"]]
cpu = [float(v[1]) for v in resp["data"]["result"][0]["values"]]

df   = pd.DataFrame({"ts": ts, "cpu": cpu})
df["day"] = (df["ts"] - df["ts"].min()) / 86400

# Linear fit
coeffs = np.polyfit(df["day"], df["cpu"], 1)
slope, intercept = coeffs
print(f"Daily CPU growth rate: {slope:.3f} cores/day")

# Project 90 days out (P50 and P90 with 20% upside buffer)
for days_out in [30, 60, 90]:
    p50 = intercept + slope * (df["day"].max() + days_out)
    p90 = p50 * 1.20
    print(f"  +{days_out}d  P50={p50:.1f} cores   P90={p90:.1f} cores")

نمّذج الذيل لا الوسط. يجب أن تستوعب سعة الإنتاج سيناريو حركة مرورك عند P90 أو P95 — لا المتوسط. إذا بُني نموذج النمو على متوسط المستخدمين النشطين يومياً، فأضف مضاعفاً لنسبة الذروة إلى المتوسط (عادةً 3–5 أضعاف للمنتجات الاستهلاكية ذات ذروات الصباح والمساء) قبل ترجمة ذلك إلى متطلبات vCPU وذاكرة.

تخطيط السعة الإقليمية

التوسع إلى منطقة جديدة — أو الحفاظ على التكرار الإقليمي N+1 — يتطلب تمريناً منفصلاً للسعة لأن حركة المرور الإقليمية ليست أبداً جزءاً بسيطاً من حركة المرور العالمية. يأخذ تخطيط السعة الإقليمي بعين الاعتبار ثلاثة عوامل يفوتها النموذج العالمي:

تقارب الزمن الحساس للكمون. لا يتوزع المستخدمون بالتساوي بين المناطق. قد تجذب منطقة APAC الجديدة 25% من التسجيلات العالمية لكنها تولّد 40% من استدعاءات API لأن انخفاض الكمون يرفع معدل التفاعل. قس نطاقات الكمون الحالية جغرافياً لبناء مضاعفات معدل الطلبات الخاصة بالمنطقة.
متطلبات إقامة البيانات. تُلزم اللوائح مثل GDPR وقوانين السيادة على البيانات وعقود عملاء المؤسسات في أحيان كثيرة ببقاء بيانات محددة داخل منطقة بعينها. هذا يفرض وجود قواعد بيانات محلية رئيسية وتخزين كائنات محلي، وهما أعلى تكلفة ثابتة من نشر قائم على النسخ المتماثلة للقراءة فحسب.
ميزانية عزل فشل المنطقة. إذا كنت تستهدف التكرار N+1، يجب تحجيم كل منطقة لاستيعاب 100% من حركة مرور المنطقة الفاشلة خلال التحويل التلقائي. كثير من الفرق تُخصص موارد منقوصة للمنطقة الاحتياطية مع "سنوسعها إن احتجنا" — وهي خطة تفشل عملياً عندما يتزامن التحويل التلقائي مع ارتفاع حركة المرور.

نموذج N+1 الإقليمي: يجب تحجيم كل منطقة لاستيعاب 100% من حركة المرور؛ تعمل المنطقة النشطة عند ~70% لإبقاء هامش للتحويل التلقائي.

قاعدة التحجيم الحرجة للتكرار N+1: شغّل كل منطقة بما لا يتجاوز 60–70% من الاستهلاك خلال التشغيل الطبيعي. هذا يحفظ هامشاً كافياً لاستيعاب تحويل تلقائي كامل مضافاً إليه تأخر التوسع التلقائي بينما يتزامن ارتفاع حركة المرور وفشل إقليمي — وهو أسوأ سيناريو يجب أن يصمد أمامه تخطيط سعتك.

إجراء اجتماع المراجعة الربعية للسعة

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

الحالة الراهنة (10 دقائق). اعرض اتجاه استهلاك 90 يوماً لكل طبقة: CPU والذاكرة وإدخال/إخراج القرص وصادرات الشبكة واتصالات قاعدة البيانات. نبّه على أي مقياس تجاوز 70% من السعة خلال الربع الماضي.
التوقعات مقابل الواقع (10 دقائق). قارن التوقعات من المراجعة الربعية السابقة بالواقع. النموذج الذي يتنبأ باستمرار بزيادة يهدر المال؛ والذي يتنبأ بنقص يسبب حوادث. اضبط مضاعفات نمو النموذج بناءً على التباين.
توقعات الربع القادم (15 دقيقة). استعرض نموذج النمو للـ 90 يوماً القادمة، شاملاً الإطلاقات القادمة والحملات التسويقية والموسمية. حدد المورد الذي سيبلغ 80% من الاستهلاك أولاً — هذا هو المسار الحرج للربع.
بنود العمل (5 دقائق). كل مورد في خطر يحتاج مالكاً وتاريخ حل مستهدفاً: توسع رأسي، أو اعتماد توسع أفقي، أو تحسين كود، أو طلب رفع حصة لدى مزود السحابة.

تجنب نمط "مسرح الهامش": تقدم الفرق أحياناً مخططات تُظهر 40% متوسط استهلاك وتُعلن صحة النظام — متجاهلةً أن استهلاك الذروة يبلغ 85% بانتظام وأن تأخر التوسع التلقائي خلال الارتفاع المفاجئ قد يدفع النظام نحو التشبع لعدة دقائق. اعرض دائماً استهلاك الذروة وP99 إلى جانب المتوسط في مراجعات السعة.

يجعل دليل تشغيل يلتقط دورة المراجعة الربعية كوكود العملية قابلة للتكرار. يصدّر مقتطف الشل التالي مقاييس Prometheus الرئيسية إلى CSV يُشكّل نقطة البداية لعرض المراجعة:

#!/bin/bash
# export_capacity_snapshot.sh
# Exports 90-day P95 utilization per service namespace into capacity_snapshot.csv
# Requires: curl, jq, promtool (or direct Prometheus access)

PROM="http://prometheus.monitoring.svc:9090"
NAMESPACES=("production" "staging" "infra")
OUT="capacity_snapshot_$(date +%Y-%m-%d).csv"
echo "namespace,metric,p95_90d,unit" > "$OUT"

for NS in "${NAMESPACES[@]}"; do
  # CPU p95 over last 90 days (vCPU cores)
  CPU=$(curl -sG "$PROM/api/v1/query" \
    --data-urlencode "query=quantile_over_time(0.95, sum(rate(container_cpu_usage_seconds_total{namespace=\"$NS\"}[5m]))[90d:1h])" \
    | jq -r '.data.result[0].value[1] // "0"')

  # Memory p95 over last 90 days (GiB)
  MEM=$(curl -sG "$PROM/api/v1/query" \
    --data-urlencode "query=quantile_over_time(0.95, sum(container_memory_working_set_bytes{namespace=\"$NS\"})[90d:1h]) / 1073741824" \
    | jq -r '.data.result[0].value[1] // "0"')

  echo "$NS,cpu,$CPU,cores"  >> "$OUT"
  echo "$NS,mem,$MEM,GiB"   >> "$OUT"
done

echo "Snapshot written to $OUT"

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

يُغلق تخطيط السعة الحلقة بين المرونة التفاعلية للتوسع التلقائي وحوكمة الموارد الاستباقية التي تُبقي المنصات مستقرة مع نمو الأعمال. المهندسون الذين يتقنونه هم من يمنعون حوادث منتصف الليل — لا من يستجيبون لها.