مشروع التخرج: منصة إنتاج بمستوى الشركات الكبرى

المنصة الكاملة ومسيرتك المهنية

18 دقيقة الدرس 10 من 30

المنصة الكاملة ومسيرتك المهنية

لقد بنيت كل طبقة من طبقات منصة Arctiq Commerce على مدار الدروس التسعة السابقة. حان الوقت الآن لرؤية النظام بأكمله كبنية متماسكة — من بداية طلب HTTPS للمستخدم إلى عملية الكتابة في قاعدة البيانات، مرورًا بخط أنابيب المراقبة، وتطبيق سياسة الأمان، وحماية ممارسة SRE، وحوكمة ضوابط التكاليف. ثم نتناول السؤال الأهم في هذه المرحلة: كيف تحوّل هذا العمق على مستوى المشروع إلى مسيرة مهنية متقدمة في DevOps أو SRE؟

المنصة المجمّعة — تدفق الطلب من البداية إلى النهاية

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

DNS والحافة: يُحوّل Route 53 Latency routing الطلب إلى توزيع CloudFront في eu-west-1. يفحص CloudFront مجموعة قواعد WAF (حد المعدل، أفضل عشر ثغرات OWASP، قائمة سمعة IPs من الدرس 7). المصدر الأصلي لـ CDN هو ALB في eu-west-1 — المنطقة الأوروبية أصبحت الآن نشطة بالكامل، وليست احتياطية، بعد الترقية النشطة-النشطة التي أجريتها في الدرس 8.
الدخول وشبكة الخدمات: يصل الطلب إلى NLB، ثم إلى بوابة دخول Istio. تُنهي Istio اتصال TLS، وتُتحقق من JWT (عبر سياسة RequestAuthentication)، وتُوجّه إلى خدمة orders في نطاق team-commerce. يُحقن sidecar Envoy الخاص بـ Istio رأس traceparent (سياق تتبع W3C) — هذا هو جذر التتبع الذي ينتشر عبر كل استدعاء تالٍ.
حوسبة التطبيق: جدولت Karpenter حجيرة orders على مثيل c6g.2xlarge Spot في منطقة التوافر eu-west-1b. يستخدم حساب الخدمة للحجيرة IRSA — لا بيانات اعتماد ثابتة؛ يقرأ AWS SDK رمزًا مُسقَطًا ويتبادله مع STS للحصول على بيانات اعتماد قصيرة الأجل محددة النطاق بـ orders-service-role.
الأسرار: عند بدء تشغيل الحجيرة، حقّن Vault Agent اسم مصدر بيانات قاعدة البيانات ومفتاح Stripe API في وحدة تخزين tmpfs في الذاكرة على /vault/secrets/. يقرأ التطبيق من الملف — ولم يرَ أي سر ثابت قط.
كتابة البيانات: يُكتب الطلب في قاعدة بيانات Aurora PostgreSQL (النسخة المُرقَّاة إلى writer في eu-west-1 من تمرين DR في الدرس 8). يُنشر حدث order.placed إلى موضوع MSK Kafka orders-v2. يُنسخ MirrorMaker2 ذلك الموضوع إلى كلاستر الولايات المتحدة بشكل غير متزامن.
المراقبة: يُبلّغ Envoy sidecar عن بيانات الامتداد إلى OpenTelemetry Collector DaemonSet. يُجمّع المُجمِّع ويُرسل التتبعات إلى Jaeger، والمقاييس إلى Prometheus (عبر remote_write إلى Thanos)، والسجلات المنظمة إلى Loki. يظهر تدفق الطلب بأكمله — زمن استجابة الدخول، ومدة الكتابة في قاعدة البيانات، وزمن استجابة إنتاج Kafka — كرسم بياني للهب (flame graph) في Grafana خلال 15 ثانية من اكتمال الطلب.
تطبيق السياسات: تراقب Falco حجيرة orders. إذا حاولت العملية تنفيذ fork/exec خارج القائمة المسموح بها (المحددة في قاعدة Falco المخصصة من الدرس 7)، يُطلق تنبيه إلى قناة Slack الأمنية ويحجب OPA أي محاولة لاحقة لإنشاء جلسة exec في تلك الحجيرة.
محاسبة التكاليف: تحمل مثيل EC2 الذي يشغّل الحجيرة وسوم Kubernetes التي نشرها Kubecost: team=commerce, service=orders, env=prod. تُعزى تكلفة هذا الطلب — الحوسبة، ونقل البيانات، وLCUs لـ ALB — تلقائيًا إلى ميزانية فريق التجارة الشهرية في لوحة Kubecost.

رؤية معمارية جوهرية: المنصة غير مرئية للمهندس الذي يمتلك خدمة orders. يكتب منطق الأعمال، ويدفع إلى GitHub، وفي غضون 7 دقائق يعمل كوده في الإنتاج عبر منطقتين، مُتتبَّعًا ومُنبَّهًا عليه ومحسوب التكاليف — دون فتح تذكرة واحدة لفريق المنصة. هذا الغياب عن المشهد هو مقياس نضج المنصة.

مخطط البنية الكاملة

المنصة الكاملة لـ Arctiq Commerce من البداية إلى النهاية: طلب المستخدم يدخل عبر Route 53 وCloudFront، ويتدفق عبر Istio إلى حجيرات EKS المجدولة بواسطة Karpenter، ويكتب في Aurora وKafka، وتراقبه منظومة OpenTelemetry، ويطبّق عليه Vault وFalco وOPA، وتحسبه Kubecost — نشط في كلتا المنطقتين في آنٍ واحد.

التحقق من صحة المنصة — مجموعة اختبارات الدخان

يجب أن ينتهي كل نشر إنتاجي بتحقق برمجي يؤكد أن المنصة تعمل من البداية إلى النهاية، لا فقط أن الحجيرات في حالة Running. سكريبت k6 التالي هو اختبار الدخان القياسي الذي يُشغَّل عبر خطاف PostSync في ArgoCD بعد اكتمال كل موجة مزامنة GitOps.

// k6 smoke test — runs as ArgoCD PostSync hook, budget: 60s, <1% error rate
import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate, Trend } from 'k6/metrics';

const errorRate = new Rate('errors');
const orderLatency = new Trend('order_latency_ms', true);

export const options = {
  vus: 10,
  duration: '45s',
  thresholds: {
    errors: ['rate<0.01'],
    order_latency_ms: ['p(99)<800'],
    http_req_failed: ['rate<0.01'],
  },
};

const BASE = __ENV.TARGET_URL || 'https://api.arctiq.com';

export default function () {
  const health = http.get(`${BASE}/healthz`);
  check(health, { 'healthz 200': (r) => r.status === 200 });
  errorRate.add(health.status !== 200);

  const headers = { 'Authorization': `Bearer ${__ENV.SMOKE_TOKEN}`,
                    'Content-Type': 'application/json' };
  const start = Date.now();
  const order = http.post(`${BASE}/v1/orders`,
    JSON.stringify({ sku: 'SMOKE-TEST-SKU', qty: 1, idempotency_key: `smoke-${__VU}-${__ITER}` }),
    { headers });
  orderLatency.add(Date.now() - start);
  check(order, {
    'order 201': (r) => r.status === 201,
    'order id present': (r) => JSON.parse(r.body).order_id !== undefined,
  });
  errorRate.add(order.status !== 201);

  sleep(1);
}

الممارسة الإنتاجية على نطاق واسع: في شركات مثل Stripe وShopify، لاختبارات دخان ما بعد النشر ميزانية صارمة مدتها 60 ثانية وتعمل مقابل بيئة الإنتاج الفعلية، لا الاختبار — لأن بيئة الاختبار لا تكون أبدًا ممثِّلة لحجم الحركة الحقيقي. مفاتيح الترابط (idempotency keys) على طلب الاختبار تضمن إمكانية تحديد عمليات الكتابة الاختبارية وتنظيفها بواسطة مهمة ليلية. يُعدّ كتلة thresholds في k6 هي البوابة: إذا تجاوزت p(99) الـ 800ms، تُوضع موجة مزامنة ArgoCD في حالة فشل وتُطلق Argo Rollouts التراجع التلقائي.

مقاييس المنصة الرئيسية — ما يتابعه المهندس الأول أسبوعيًا

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

معدل النشر وزمن الاستيفاء: الهدف أكثر من 20 عملية نشر يوميًا عبر جميع الفرق الاثنتي عشرة، وزمن استيفاء وسيط أقل من 10 دقائق. ارتفاع زمن الاستيفاء فوق 20 دقيقة يعني عادةً اختبارًا غير مستقر في CI لا مشكلة في Kubernetes. الحالي: 34 عملية نشر يوميًا، وسيط 6.8 دقيقة.
معدل استهلاك ميزانية الخطأ: اتفاقية مستوى الخدمة 99.95% تمنح ميزانية خطأ فصلية مدتها 131 دقيقة. معدل استهلاك 6x (الاستهلاك في سدس الوقت) يُطلق تجميد التغييرات المحفوفة بمخاطر. تتبع هذا كتنبيه Grafana لا تقريرًا شهريًا. الحالي: 1.2x — وضع صحي.
معدل إخلاء الحجيرات: مقاطعات Karpenter Spot تتسبب في إخلاء الحجيرات. معدل إخلاء يتجاوز 3% يوميًا يشير إلى ضرورة تعديل نسبة سعة On-Demand الاحتياطية، أو أن حمل عمل ما يفتقد PodDisruptionBudget. الحالي: 0.8%.
تأخر تدوير الأسرار: تتجدد بيانات الاعتماد الديناميكية لـ Vault كل 15 دقيقة لـ DSN قاعدة البيانات. إذا احتفظ أي حمل عمل بعقد إيجار أقدم من 30 دقيقة، يظهر في سجل مراجعة Vault كانتهاك. تتبعه كمقياس Prometheus مُجمَّع من نقطة نهاية مقاييس Vault. الحالي: 0 انتهاكات.
التكلفة لكل 1,000 طلب: المقياس التجاري الذي يربط كفاءة المنصة بالإيرادات. يحسب Kubecost هذا بضم بيانات تكلفة Kubernetes مع إنتاجية الطلبات من مقاييس التطبيق. الاتجاه: 0.31$/1k طلبات، الهدف أقل من 0.40$. توفّر استخدام Spot حوالي 21k$ شهريًا مقارنة بالأسعار العادية.

ما أثبته مشروع التخرج — وما لم يثبته

الصراحة بشأن حدود هذا المشروع هي بحد ذاتها مهارة مهندس متمرس. ما بنيته هو بنية كاملة بمعايير إنتاجية لشركة في مرحلة 2-20 مليون مستخدم. أما ما لم تبنِه، وما سيأتي لاحقًا في شركة حقيقية، فيشمل:

العزل متعدد المستأجرين: تشغّل Arctiq 12 فريقًا في كلاستر EKS واحد. عند 50+ فريقًا، يبدأ العزل على مستوى الـ namespace بالتصدع (ضوضاء الجار على API server، RBAC واسع للغاية، ضغط etcd). التطور التالي هو كلاسترات مخصصة لكل وحدة أعمال مع طبقة إدارة أسطول (Cluster API أو EKS Blueprints على مستوى الحساب).
التتبع الموزع العالمي على نطاق المليار طلب: يعمل Jaeger مع تخزين في الذاكرة عند حجمنا. عند مليار طلب يوميًا، تحتاج إلى أخذ عينات قائم على الذيل (Tempo أو Honeycomb)، ومخزن تتبع عمودي (ClickHouse أو Parquet على S3)، وسياسات أخذ عينات احتمالية تضمن أخذ عينات 100% من تتبعات الأخطاء و1% من التتبعات الصحية.
نضج FinOps: يمنحك Kubecost رؤية التكلفة لكل فريق. FinOps الحقيقي في شركة كبيرة يضيف اقتصاديات الوحدة (تكلفة لكل استدعاء API، تكلفة لكل مستخدم نشط)، والكشف عن الشذوذات في الإنفاق (قائم على التعلم الآلي لا على العتبات)، وإشارات التكلفة للمهندسين في خط أنابيب PR ("سيزيد هذا التغيير تكلفة البنية التحتية بـ 400$ شهريًا").

تقييم صادق: مهندس أول يمكنه بناء ما بنيته في هذا المشروع. مهندس Staff يمكنه شرح لماذا اتُّخذ كل قرار معماري وما الذي سيجبر على اختيار مختلف. مهندس Principal يمكنه تطوير المنصة مع نمو الشركة من 2 مليون إلى 200 مليون مستخدم دون إعادة كتابة كاملة. الفرق ليس معرفة الأدوات — إنه الحكم المتراكم على أنماط الفشل وديناميكيات المؤسسة وتكلفة التعقيد.

مسيرتك المهنية — المسارات الثلاثة

إتمام مشروع كهذا يضعك على مستوى المهندس الأول. الخطوات التالية الطبيعية تتفرع إلى ثلاثة مسارات، واختيارك الواعي بينها يهم أكثر مما يدرك معظم المهندسين:

مهندس منصة Staff / Principal: تمتلك منصة يستخدمها مئات المهندسين. مخرجاتك مضاعَفة من خلال الآخرين — تكتب قوالب المسار الذهبي، والأنماط المعمارية، والمعايير الداخلية. المهارات التي تتراكم: الكتابة التقنية، وتصميم الأنظمة على نطاق واسع، والتأثير التنظيمي بدون سلطة رسمية، والانضباط في رفض الطلبات التي تزيد العبء التشغيلي دون مكاسب موثوقية مقابلها.
SRE / هندسة الإنتاج: تمتلك موثوقية الأنظمة الكبيرة النطاق — عادةً أكثر من مليون طلب في الثانية، ومجالات فشل معقدة، واتفاقيات مستوى خدمة يشعر بها العملاء الحقيقيون. المهارات التي تتراكم: التحليل الإحصائي لبيانات الموثوقية، المعرفة العميقة بأداء النواة (eBPF، مخططات شعلة perf، رسوم بيانية زمن الاستجابة)، قيادة الحوادث، والقدرة على ترجمة مخاطر الموثوقية إلى مخاطر أعمال يمكن للمسؤول التنفيذي التصرف بناءً عليها.
مدير هندسة / مدير منصة: تمتلك الفريق الذي يبني المنصة. مخرجاتك هي مخرجات 8-20 مهندسًا. المهارات التي تتراكم: التوظيف وفق الحكم لا الشهادات، بناء ثقافة فريق تتعامل مع العبء التشغيلي كمشكلة هندسية من الدرجة الأولى، التواصل مع أصحاب المصلحة غير التقنيين، وتحديد خارطة طريق للمنصة متعددة السنوات تبقى ذات صلة مع تطور المنتج.

# خطة عمل 90 يومًا بعد مشروع التخرج

# الأسبوع 1-2: نشر المشروع
# ادفع وحدات Terraform ومانيفستات k8s إلى مستودع GitHub عام.
# اكتب وثيقة قرار معماري (ADR) بـ 2,000 كلمة تشرح أهم ثلاث مقايضات اتخذتها.
# هذا يصبح قطعة محفظة أعمالك المهنية.
git init arctiq-platform && cd arctiq-platform
git checkout -b main

# الأسبوع 3-4: احصل على بيئة AWS حقيقية
eksctl create cluster \
  --name arctiq-demo \
  --region us-east-1 \
  --nodegroup-name default \
  --node-type t3.medium \
  --nodes 3 \
  --managed

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set grafana.adminPassword=demo1234 \
  --set prometheus.prometheusSpec.retention=7d

# الأسبوع 5-8: الشهادات التي تهم على المستوى المتقدم
# CKA (Certified Kubernetes Administrator)
# AWS Solutions Architect Professional
# HashiCorp Vault Associate

# الأسبوع 9-12: ساهم في النظام البيئي
# افتح PR لمشروع CNCF (Karpenter, OpenTelemetry, Argo)
# حتى توثيق. PR مقبول في مشروع رئيسي أفضل من أي شهادة في السيرة الذاتية.

مقابلات DevOps المتقدمة — ما يُختبر فعلًا

تغيّرت المقابلات التقنية لأدوار DevOps و SRE الأولى في الشركات الكبرى بشكل كبير. الأسئلة الاعتيادية ("ما هو الـ pod؟"، "اشرح عمليات النشر blue-green") تُحذف في فلتر الفرز الأولي. المقابلات التي تهم تختبر أربعة أشياء:

تصميم الأنظمة في ظل الغموض: ستُعطى تحديدًا مبهمًا مثل "صمم نظام النشر لشركة تمتلك 500 خدمة مصغّرة". يختبر المحاور ما إذا كنت تطرح أسئلة توضيحية (تكرار النشر؟ هيكل الفريق؟ تحمّل التعقيد؟) قبل رسم المربعات. علّمك المشروع البدء بالمتطلبات لا الحلول.
تحليل الحوادث: ستُعطى رسمًا بيانيًا أو مقتطف سجل وتُسأل عن تشخيص حادث إنتاجي. السيناريو النموذجي: ارتفعت زمن الاستجابة p99 إلى 4 ثوانٍ عند 14:23 لكن p50 لم يتغير — ماذا تفحص أولًا؟ (الجواب: زمن الاستجابة الذيلي مع ثبات الوسيط يشير إلى تدفق أسفل بطيء واحد لا مشكلة على مستوى الكلاستر — افحص التتبعات الموزعة لأبطأ 1% من الطلبات، وانظر في مقاييس توقف جمع المهملات وتشبع تجمع الاتصالات.)
الاستدلال على المقايضات: "هل يجب استخدام Istio أم Linkerd لشبكة خدماتنا؟" لا توجد إجابة صحيحة — هناك مقايضات. نطاق ميزات Istio الأوسع يكلف المزيد من CPU/ذاكرة وتعقيد تشغيلي. مستوى بيانات Rust في Linkerd أسرع وأبسط لكن له نظام بيئي أدوات أقل. يختبر المحاور ما إذا كنت تستطيع توضيح المقايضات بوضوح، لا ما إذا كنت حفظت فائزًا.
أنماط فشل الإنتاج: "ما أول شيء ينكسر عند توسع كلاستر EKS من 500 إلى 5,000 عقدة؟" الجواب يتضمن إنتاجية كتابة etcd، وحدود معدل طلبات API server، وفيضان NXDomain في CoreDNS من الإعداد الخاطئ ndots:5، وسقف QPS الافتراضي لجدولة Kubernetes. هذه ليست أشياء تتعلمها من الدروس — تأتي من تشغيل أنظمة إنتاجية على نطاق واسع، أو من دراسة تقارير ما بعد الحوادث من شركات مرّت بها.

أعلى إعداد للمقابلات من حيث الإشارة: اقرأ 20 تقرير ما بعد حادث عام من شركات تعمل على النطاق الذي تريد العمل فيه. Cloudflare وStripe وShopify وGitHub وSlack كلها تنشر تقارير حوادث مفصّلة. لكل منها، تتبع الفشل وصولًا إلى طبقة المنصة التي كان بإمكانها منعه (تنبيه أفضل، تجربة فوضى كانت ستكشف عن نمط الفشل، قاطع دائرة مفقود). هذا التمرين يبني قدرة على المقابلة أكثر من أي دورة يمكنها.

الخاتمة: ما علّمتك إياه هذه الدورة فعلًا

لم تكن هذه الدورة يومًا عن صيغة Terraform أو YAML لـ Kubernetes. تلك تفاصيل تنفيذية تتغير مع كل إصدار رئيسي. ما بنته الدورة، عبر 50 درسًا وهذا المشروع، هو نموذج ذهني لكيفية فشل أنظمة الإنتاج وكيف تُصمَّم المنصات المرنة لتفشل بأمان. النماذج الذهنية الأربعة التي ستخدمك للعقد القادم:

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

المنصة التي بنيتها في هذا المشروع تتعامل مع متطلبات Arctiq Commerce. الحكم الذي طورته في بنائها يتعامل مع متطلبات لم تشهدها بعد. هذا ما تُبنى عليه مسيرة مهندس DevOps المتمرس — ليس الأدوات، بل الحكم لاختيار الأدوات الصحيحة للقيود التي أمامك.

أكثر الأخطاء المهنية شيوعًا في هذا المستوى: البقاء قريبًا جدًا من التكنولوجيا وعدم الاستثمار في مهارات التواصل. أفضل مهندسي المنصات في الشركات الكبيرة يقضون 30-40% من وقتهم في الكتابة — وثائق القرارات المعمارية، وتقارير ما بعد الحوادث، والمقترحات، والمدونات الهندسية. المهندسون الذين يصلون إلى مستوى Staff وPrincipal ليسوا بالضرورة الأعمق تقنيًا — إنهم من يستطيعون شرح الأنظمة المعقدة ببساطة كافية لاتخاذ نائب رئيس الهندسة قرارًا مستنيرًا. إذا اتخذت إجراءً واحدًا من هذا الدرس، ابدأ الكتابة علنًا عما تبنيه.