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

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

يحمل هذا المجال 22% من درجات اختبار SOA-C03، ويبني مباشرة على المجال الأول. سياسة التوسيع ليست إلا تنبيه CloudWatch أُضيف إليه إجراء، وقرار التبديل عند الفشل فحص صحة يقرأ مقياساً. هنا تحوّل تلك القياسات إلى أحمال تمتص الضغط وتصمد أمام الأعطال.

ما الذي يغطيه هذا المجال

• Elastic Load Balancing بأنواعه ALB وNLB وGateway Load Balancer، وفحوصات صحة مجموعات الأهداف، وتشخيص الأهداف العالقة في حالة unhealthy
• فحوصات صحة Route 53 والتبديل عند الفشل عبر DNS، وzonal shift مع Application Recovery Controller
• مجموعات EC2 Auto Scaling، وأنواع السياسات target tracking وstep وscheduled وpredictive، وlifecycle hooks وinstance refresh
• توسيع الحاويات وأحمال serverless: التوسيع التلقائي لخدمات ECS، وEKS، وحدود التزامن في Lambda
• التخزين المؤقت عبر CloudFront وElastiCache، وتوسيع قواعد البيانات العلائقية بنسخ القراءة وAurora Serverless v2
• أوضاع السعة في DynamoDB، والتوسيع التلقائي للجداول، وDAX
• تحمّل الأعطال بالنشر متعدد مناطق التوفر، وAWS Backup واللقطات، والاستعادة إلى نقطة زمنية، وversioning وreplication في S3
• استراتيجيات التعافي من الكوارث الأربع، وقيمتا RTO وRPO اللتان تحسمان الاختيار بينها

لماذا هذا مهم

أسئلة هذا المجال نادراً ما تطلب منك تعريف Multi-AZ. تعطيك قيداً: هدف RPO لا يتجاوز خمس دقائق، أو ميزانية لا تحتمل تشغيل أسطول ثانٍ، أو تطبيق يحفظ الجلسات محلياً فينكسر عند إنهاء النسخ، ثم تسألك أي آلية تحقق هذا القيد. الإجابة تتطلب معرفة ما يكلفه كل خيار من مال ووقت استرجاع وعمل تشغيلي، لا معرفة ما يفعله فقط.

نفس التفكير يتكرر في كل مناوبة on-call. حين تفرّق بين فحص صحة فاشل وسياسة توسيع فاشلة، وبين استعادة تبلغ هدف RPO وأخرى تفقد ساعة من الكتابات بصمت، تقضي وقت الحادث في إصلاح المشكلة بدل اكتشاف التصميم أثناءه.