موجز مشروع التخرج
موجز مشروع التخرج
لقد أمضيت الدروس التسعة والأربعين السابقة في تعلم كل طبقة من طبقات منصة الإنتاج الحديثة — من أساسيات Linux وبنية الشبكات، مرورًا بالحاويات وKubernetes وTerraform وGitOps، وصولًا إلى المراقبة الشاملة وممارسات SRE والأمن والامتثال وهندسة التكاليف. كان كل درس مصمَّمًا لتغطية مجال واحد بعمق. أما هذا الدرس الأخير فله هيكل مختلف: إنه مشروع تكاملي شامل، ونطاقه واسع بشكل مقصود.
على مدى الدروس التسعة التالية، ستصمم وتبني منصة إنتاج متكاملة بمعايير كبرى شركات التقنية لشركة متنامية في سيناريو واقعي. كل قرار سيتضمن موازنة بين التكلفة والموثوقية والأمن وسرعة الفرق الهندسية — وهي نفس المقايضات التي يواجهها مهندسو المستوى الرفيع يوميًا. لا أمثلة مبسّطة هنا: الأوامر حقيقية، وملفات YAML جاهزة للإنتاج، وأنماط الفشل هي ذاتها التي تسببت في حوادث فعلية لشركات حقيقية.
السيناريو: شركة Arctiq Commerce
Arctiq Commerce شركة تجارة إلكترونية B2C تشغّل حاليًا تطبيق Laravel متكاملًا (monolith) على خادمين ماديين خلف موازن حمل مادي. وصل عدد مستخدميها المسجلين إلى مليوني مستخدم، مع توقع نمو بمقدار 10 أضعاف خلال 18 شهرًا مدفوعًا بإطلاق تطبيق جوّال جديد. لا تستطيع البنية التحتية الحالية تحمّل هذا الحجم، ودورة الإصدار تستغرق أسبوعين، وكل عملية نشر تتسبب في توقف الموقع أربع دقائق، ولا يوجد أي نظام مراقبة يتجاوز رسوم CPU على مستوى الخادم في أداة قديمة.
وافق مجلس الإدارة على إعادة هيكلة المنصة. أنت قائد هندسة المنصة. مهمتك: بناء منصة سحابية الأصل، آمنة، قابلة للمراقبة، وذاتية الخدمة حتى تتمكن فرق هندسة المنتجات من شحن المميزات يوميًا دون الحاجة لمعرفة تفاصيل البنية التحتية.
المتطلبات والقيود
تبدأ هندسة المنصة الجيدة بتحديد المتطلبات بوضوح وبأرقام ملموسة. التفويضات المبهمة مثل "اجعلها قابلة للتوسع" تفضي إلى منصات مفرطة التعقيد لا يستخدمها أحد. قبل كتابة سطر واحد من Terraform، يكتب المهندس المتمرس المتطلبات مصحوبةً بالأرقام.
المتطلبات الوظيفية
- نشاط نشط في منطقتين: منطقتان AWS (
us-east-1أساسية،احتياطية) مع تبديل تلقائي عند الفشل. هدف زمن الاستجابة: أقل من 80 ms عند النسبة المئوية 99 للمستخدمين الأوروبيين، وأقل من 60 ms للمستخدمين الأمريكيين. - أعباء عمل Kubernetes: 12 فريقًا هندسيًا، كل منها يمتلك 2-8 خدمات مصغّرة. الحد الأقصى لعدد الـ pods: ~4,000. يجب أن يتوسع الكلاستر إلى 8,000 pod دون تغييرات معمارية.
- نشر بدون توقف: يجب أن يستخدم كل نشر استراتيجية rolling أو blue-green. الوقت الأقصى للنشر: 10 دقائق من الدمج (merge) إلى الإنتاج.
- طبقة البيانات: PostgreSQL (RDS Aurora) للبيانات التشغيلية، Redis Cluster للجلسات والتخزين المؤقت، Kafka لتدفق الأحداث غير المتزامن، S3 لتخزين الكائنات مع قواعد دورة الحياة.
- الخدمة الذاتية للمطورين: يجب أن يتمكن أي فريق من توفير مساحة عمل (namespace) جديدة وخط CI وأدوات مراقبة دون رفع طلب للفريق الهندسي للمنصة.
المتطلبات غير الوظيفية (المحددات المعمارية الحقيقية)
- اتفاقية مستوى الخدمة للتوافر: 99.95% وقت تشغيل فصليًا (يتيح 131 دقيقة توقف ربع السنة، أي ما يقارب 22 دقيقة شهريًا). هذا يستبعد نشر المنطقة الواحدة وقواعد البيانات أحادية المنطقة.
- RTO / RPO: هدف وقت الاسترداد 15 دقيقة، هدف نقطة الاسترداد 5 دقائق. هذا يتطلب تكرارًا متزامنًا لـ Aurora، ونقلًا مستمرًا لسجلات WAL، وكلاستر DR محمّلًا مسبقًا — لا standby بارد.
- وضعية الأمان: PCI-DSS المستوى 2 (بيانات البطاقات تمر عبر المنصة). هذا يفرض عزل الشبكة، وتشفير البيانات عند النقل والتخزين في كل مكان، وتسجيل تدقيق لجميع إجراءات المدير، واختبار اختراق ربع سنوي.
- الامتثال: GDPR للعملاء الأوروبيين. يجب توثيق كل معالجة بيانات. يجب أن تكون بيانات PII الخاصة بالعملاء قابلة للحذف خلال 30 يومًا من طلب الحذف، وهو ما يتطلب استراتيجية ضغط أو طوابع تعريف في تدفقات الأحداث التي تحتوي على PII.
- سقف التكاليف: يجب ألا تتجاوز نفقات AWS 85,000$ شهريًا عند ضعف حركة المرور الحالية، مع تنبيه صارم عند 90% من الميزانية. يجب تتبع التكاليف لكل فريق لكل sprint عبر تخصيص قائم على الوسوم (tags).
القيود التشغيلية
- فريق المنصة مؤلف من 4 مهندسين. أي عملية تشغيلية لا يمكن أتمتتها لن تُنفَّذ باتساق — صمِّم لعمليات بدون تدخل يدوي قدر الإمكان.
- التطبيق الحالي هو monolith بـ Laravel. سيكون الترحيل إلى خدمات مصغّرة تدريجيًا على مدى 12 شهرًا باستخدام نمط strangler-fig. يجب أن تدعم المنصة كلًا من الـ monolith والخدمات الجديدة في آنٍ واحد.
- يجب تعريف كل البنية التحتية في Terraform وتخزينها في Git. لا ClickOps. سيُبلّغ أي مورد لم ينشئه حساب خط CI/CD في مراجعة IAM.
معمارية المنصة — نظرة شاملة
قبل الغوص في أي طبقة بعينها، يرسم المهندس المتمرس الصورة الكاملة حتى تتم كل قرار لاحق في سياقه. أدناه معمارية المنصة المستهدفة. إنها ليست نهائية — ستتطور مع كل درس — لكنها تحدد الإطار المرجعي.
كيف تبني الدروس الثمانية التالية هذه المنصة
يقابل كل درس طبقة معمارية واحدة. الترتيب قائم على الاعتماديات — لا يمكنك نشر Kubernetes قبل وجود الشبكة، ولا تطبيق السياسات الأمنية قبل تجهيز طبقة الأمان، ولا ممارسة SRE بدون بنية تحتية للمراقبة. يعكس الترتيب أيضًا كيف تُسلِّم فرق المنصة الحقيقية: البنية التحتية أولًا، ثم الحوسبة، ثم التسليم، ثم المراقبة، ثم الأمان، ثم الموثوقية، وأخيرًا طبقة التجربة التي تتفاعل معها فرق المنتج مباشرةً.
- الأساس — الحسابات والشبكة وIAM: AWS Organizations، معمارية VPC (3 مناطق توافر، transit gateway، private endpoints)، أدوار IAM بأقل صلاحية، SCPs.
- البنية التحتية كأكواد برمجية: هيكل وحدات Terraform، الحالة البعيدة مع S3 + قفل DynamoDB، Atlantis لتطبيق GitOps على التخطيط/التطبيق، ترقية البيئات.
- منصة Kubernetes: تصميم كلاستر EKS، Karpenter، Istio، إضافات الكلاستر، RBAC على مستوى namespace وحصص الموارد.
- CI/CD وتسليم GitOps: خطوط أنابيب GitHub Actions، ArgoCD ApplicationSets، التسليم التدريجي مع Argo Rollouts، بوابات الإصدار.
- مكدس المراقبة: kube-prometheus-stack، OpenTelemetry Collector، التتبع الموزع، التنبيه القائم على SLO، لوحات Grafana ككود.
- الأمان والامتثال: HashiCorp Vault للأسرار، OPA/Gatekeeper للتحكم في القبول، Falco لأمان وقت التشغيل، عزل شبكة PCI.
- الموثوقية — ممارسة SRE والتعافي من الكوارث: تتبع ميزانية SLO، تمارين GameDay، اختبار تبديل Aurora، تجارب الفوضى، كتيبات DR.
- التكاليف وتجربة المنصة: استراتيجية Spot مع Karpenter، تخصيص قائم على الوسوم مع Kubecost، بوابة مطورين داخلية مع Backstage، قوالب المسار الذهبي.
كيفية قراءة الدروس التالية
سيحتوي كل درس من الدروس الثمانية التالية على وحدة Terraform مرجعية أو manifest لـ Kubernetes جاهزة للإنتاج — ليست هيكلًا تعليميًا مبسطًا، بل شيء يمكنك نسخه إلى بيئة حقيقية بتغييرات بسيطة في المتغيرات. ستُعرض الأوامر كما تعمل في خط CI/CD، لا يدويًا من حاسوب محمول. ستتضمن نقاشات المقايضة أرقامًا محددة: ميزانيات زمن الاستجابة، ومعدلات الفشل، والتكاليف بالدولار، وساعات العبء التشغيلي على الفريق.
مقياس النجاح في هذا المشروع ليس قدرتك على إعادة سرد ما يفعله كل مكوّن — فأنت تعرف ذلك بالفعل. المقياس هو قدرتك على الإجابة عن السؤال الأصعب: بالنظر إلى هذه القيود، لماذا اخترنا هذا القرار بدلًا من البدائل، وماذا يجب أن يتغير لجعل خيار مختلف هو الصحيح؟