أساسيات تخطيط السعة

أساسيات تخطيط السعة

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

يتمحور هذا الدرس حول الركائز الثلاث التي تقوم عليها كل استراتيجية قياس تلقائي ستُهيّؤها في الدروس اللاحقة: التنبؤ بالطلب، وسياسة الهامش، ومُهَل التوريد. إذا أخطأت في هذه المحاور، فلن تُنقذك أي كمية من ضبط HPA أو تهيئة Karpenter خلال موجة حركة مرور مفاجئة.

التنبؤ بالطلب

يجيب التنبؤ عن السؤال الجوهري: كم من السعة سأحتاج في الوقت T مستقبلًا؟ ثمة ثلاثة نماذج تستخدمها المنظمات الناضجة معًا:

• التنبؤ القائم على الاتجاه — ملاءمة منحنى (خطي أو أسي) لبيانات الاستخدام التاريخية. مفيد للنمو العضوي لكنه أعمى إزاء الأحداث التجارية.
• التنبؤ المدفوع بالأحداث — تراكب الأحداث التقويمية التجارية المعروفة: إطلاق المنتجات، الحملات التسويقية، الجمعة السوداء، طفرات نهاية الربع المالي في البرمجيات كخدمة للقطاع التجاري. هذه ضرورة لا تنازل فيها: في كل تحليل حوادث كبرى بدأ بـ"نفدت سعتنا" يوجد حدث تم تجاهله.
• التنبؤ بتحليل أعباء العمل — تفكيك الطلب الإجمالي إلى إشاراته المكوّنة (المستخدمون النشطون × الطلبات/مستخدم/ثانية × متوسط حجم الحمل). يتيح لك هذا الاستدلال على أي الخدمات سيصل إلى حد الإشباع أولًا ونمذجة النمو بصورة مستقلة لكل طبقة.

عمليًا، صدّر بيانات وحدة المعالجة المركزية/الذاكرة/معدل الطلبات لمدة 90 يومًا من Prometheus، طبّق انحدارًا خطيًا بسيطًا في Python أو عبر وظيفة التنبؤ في منصة المراقبة لديك، ثم أضف معاملات الأحداث المعروفة. الهدف هو منحنى طلب P95 لا المتوسط — صمّم للذيل لا للمتوسط.

سياسة الهامش

الهامش هو الفجوة التي تتركها عمدًا بين السعة المُوفَّرة وذروة الطلب المتوقعة. يخدم ثلاثة أغراض: استيعاب الطفرات غير المتوقعة قبل استجابة القياس التلقائي، توفير مهلة لتنفيذ القياس التلقائي (إذ يستغرق انضمام عقدة جديدة إلى مجموعة Kubernetes من 2 إلى 4 دقائق)، ومنع تشبّع وحدة المعالجة المركزية/الذاكرة من تدهور زمن الاستجابة قبل أن تتمكن من التوسع.

تعتمد نسبة الهامش الصحيحة على سرعة التوسع وصرامة مستوى الخدمة لديك:

• 20 % هامش — الحد الأدنى المقبول للخدمات ذات التوسع الأفقي السريع (أقل من 90 ثانية لإضافة pod مجدولة مسبقًا على عقدة دافئة). مقبول للخدمات الصغيرة عديمة الحالة المدعومة بـ HPA.
• 30–40 % هامش — مناسب عندما تكون توفير العقدة في المسار الحرج (القياس التلقائي للمجموعة، حوالي 3-5 دقائق). هذا هو الإعداد الافتراضي في Google وNetflix لطبقات الخدمة الأساسية لديهم.
• أكثر من 50 % هامش — مطلوب للخدمات ذات أوقات الإحماء الطويلة (JVM، تحميل نموذج تعلم الآلة)، الأنظمة ذات الحالة (قواعد البيانات، وسطاء Kafka)، أو النشرات أحادية المنطقة حيث يُضاعف فشل منطقة توفر واحدة الحمل فورًا على الناجيات.

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

مُهَل التوريد

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

توجد مُهَل التوريد في كل طبقة من طبقات المجموعة:

• جدولة الـ Pod (عقدة دافئة): 5–30 ثانية. مُجدول Kubernetes + سحب الحاوية إذا لم تكن مخزّنة مؤقتًا. هذا هو نطاق عمل HPA — تفاعلي وسريع.
• توفير العقدة (cluster autoscaler / Karpenter): 2–6 دقائق لأنواع نماذج الحساب القياسية؛ 10–20 دقيقة لنماذج GPU أو العقد الضخمة bare-metal. هذه هي الطبقة التي تنشأ منها قاعدة "30 % هامش" — تحتاج إلى احتياطي كافٍ للصمود ريثما تنضم عقد جديدة.
• شراء الحجوزات: فوري للطلب العاجل، لكن السعة المحجوزة (AWS RIs، الاستخدام الملتزم) تستلزم التزامًا مسبقًا بعقود تتراوح من سنة إلى ثلاث. الخطأ في تقدير الخط الأساسي المحجوز يجعلك إما تدفع زيادة أو تستنفد حصة الطلب العاجل.
• شراء الأجهزة (on-prem / colocation): 8–26 أسبوعًا للخوادم القياسية؛ 6–12 شهرًا للأجهزة المتخصصة (GPU، عقد ذاكرة عالية، شرائح مخصصة). على هذا النطاق، تخطيط السعة هو عملية إنفاق رأسمالي يشمل أصحاب المصلحة في المالية والمشتريات.

تجميع الأمور: دورة تخطيط السعة

تُدير المنظمات الناضجة تخطيط السعة كدورة ربعية، لا كمعالجة طارئة تفاعلية. سير العمل:

1. جمع الإشارات — استخلص اتجاهات الاستخدام لمدة 90 يومًا من Prometheus/Datadog؛ أضف الأحداث التقويمية التجارية للربع القادم.
2. توقع طلب P50 وP95 — لكل خدمة، ولكل نوع من أنواع الموارد (المعالج، الذاكرة، الشبكة، عمليات إدخال/إخراج التخزين).
3. تطبيق سياسة الهامش — اضرب P95 بعامل الهامش الخاص بك (1.3x لمعظم الخدمات، أعلى للطبقات ذات الحالة).
4. مراعاة مُهَل التوريد — إذا كان شراء الأجهزة في المسار الحرج، قدّم الطلبات قبل 12+ أسبوعًا من موعد الحاجة.
5. مراجعة تهيئات القياس التلقائي — تحقق من أن أهداف HPA وتوصيات VPA وحدود Karpenter تتوافق مع التوقع الجديد. عدّل حدود minReplicas قبل موسم الذروة، لا خلاله.
6. توثيق الافتراضات — حتى يفهم مهندس المناوبة التالي سبب توفير 140 % من الحمل الحالي.