هندسة الفوضى: مرونة النظام

هندسة الفوضى: مرونة النظام

1) لماذا هندسة الفوضى

• فرضيات الاختبار حول سلوك النظام والتحقق من صحة SLO ؛
• الكشف عن SPOFs المخفية، المهلات/عمليات إعادة التدوير غير الصحيحة، الآثار المتتالية ؛
• أفرقة التدريب: أيام اللعب، دفاتر التشغيل، الاتصالات ؛
• لتشكيل ثقافة «الاستدامة افتراضيًا» بدلاً من «الأمل في الأفضل».

مهم: ≠ فوضى الهندسة "كسر كل شيء. "هذه طريقة علمية: فرضية → الحالة الثابتة → تجربة → استنتاجات → تحسين.

2) دورة التجربة الأساسية

1. الحالة الثابتة (خط الأساس): ما هي المؤشرات القصوى المستقرة ؟ (على سبيل المثال، النجاح ≤500 ms at 99. 95%).
2. الفرضية: مع فقدان واحد AZ، سيزيد p95 أقل من 10٪، ≥99 التوافر. 9%.
3. التجربة: خطأ مخطط له مع نصف قطر انفجار محدود ومعايير إيقاف.
4. الملاحظة: المقاييس/المسارات/جذوع الأشجار، ومعدل الحرق SLO، و SLI للأعمال التجارية (على سبيل المثال، الودائع الناجحة).
5. التحسينات: نسجل الاكتشافات، ونغير المهلة/الحدود/التوجيه، ونحدث دفتر التشغيل.
6. التشغيل الآلي/الانحدار: كرر في الجدول الزمني، أضف إلى CI/CD وتقويمات أيام اللعبة.

3) السلامة أولا

نصف قطر الانفجار: ابدأ بنصف ضيق - جراب واحد/مثيل/مسار/مساحة اسم.
حواجز الحماية: تنبيهات إلى معدل حرق SLO (سريع/بطيء)، حدود إعادة الدفع، حد QPS، ميزانية الحوادث.
معايير التوقف: «إذا كان معدل الخطأ> X٪ أو p99> Y ms N minutes - توقف وتراجع على الفور».
النوافذ: ساعات العمل عند الطلب، وإخطار أصحاب المصلحة، والإصدارات المجمدة.
الاتصال: IC/Tech Lead/Comms، قناة واضحة (غرفة الحرب)، نموذج الرسالة.

4) فصول الفشل وأفكار الفرضية

الشبكة: تأخير/نفث/فقدان، إسقاط جزئي للموانئ، «فشل» الاتصال بين الخدمات/PSP.
الكمبيوتر/العقد: عمليات القتل، ارتفاع درجة حرارة وحدة المعالجة المركزية، استنفاد واصفات الملفات، أحواض الاتصال الضيقة.
التخزين وقاعدة البيانات: نمو أقراص الكمون، النسخ المتماثلة المتأخرة، إيقاف قطعة/قائد واحد، تقسيم الدماغ.
التبعيات: تدهور واجهات برمجة التطبيقات الخارجية، حدود مقدمي الخدمات، رشقات نارية 5xx/429.
إدارة التغيير: الإفراج غير الناجح، علم الميزة السيئ، الطرح الجزئي.
المحيط: يتحلل CDN، DNS/Anycast drift، WAF/فشل حماية الروبوت.
المنطقة/المنطقة المنخفضة: خسارة كاملة أو حادثة «جزئية» (أسوأ قليلاً ولا يمكن التنبؤ بها).

5) الأدوات والتقنيات

Kubernetes: Chaos Mesh و Litmus و PowerfulSeal و kube-monkey.
السحب: محاكي حقن الصدع AWS (FIS)، مجالات الصدع بالقرب من السحب.
الشبكة/الوكيل: السموم (سم TCP)، tc/netem، iptables، خطأ المبعوث (التأخير/الإجهاض)، حقن خطأ Istio.
العمليات/العقد: «الإجهاد - نغ»، الخناق/وحدة المعالجة المركزية، ملء القرص.
توجيه حركة المرور: أوزان GSLB/DNS، تبديل الكناري/الأزرق والأخضر للفحوصات المزيفة.

6) نماذج نصية (Kubernetes)

6. 1 تأخير/إجهاض على الطريق (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

الفرضية: ستحتفظ المهلات/عمليات إعادة تشغيل العملاء و CBs بـ p95 <300 مللي ثانية ومعدل الخطأ <0. 5%.

6. 2 بود كيل (فوضى شبكية)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

الفرضية: يعوض التوازن و HPA عن فقدان حالة واحدة دون نمو p99> 20٪.

6. 3 فوضى الشبكة (التأخير في قاعدة البيانات)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

الفرضية: البرك/المهلات/المخبأ ستقلل من التأثير ؛ p95 المدفوعات ستبقى ≤ SLO.

6. 4 ملء القرص

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

الفرضية: سيعمل تناوب السجلات/الحصص/التنبيهات قبل تدهور الطرق.

7) تجارب خارج K8s

7. 1 توكسيبروكسي (محلي/متكامل)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. خطأ المبعوث 2 HTTP (محيط/شبكة)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (فكرة مثال)

التجربة «تقتل» N٪ EC2 في مجموعة Auto Scaling Group، ترفع بشكل مصطنع كمون EBS، تعطل NAT-GW في جهاز AZ واحد.
معايير التوقف المدمجة لمقاييس CloudWatch SLO.

8) مقاييس إمكانية الرصد أثناء الفوضى

SLO/SLI: جزء بسيط من الطلبات الجيدة، p95/p99، معدل الحرق.
نموذج RED للطرق الحرجة (المعدل، الأخطاء، المدة).
البرك: في انتظار الاتصال p95، الاستخدام.
DB: النسخ المتماثلة المتأخرة، الأقفال، طلبات الانجراف p95.
الشبكة: retransmitts، RTT، سلوك dscp/ecn.
SLI الأعمال: نجاح المعاملات (الودائع/الشيكات)،% العوائد/الأخطاء.
التتبع: مسارات انتقائية (نماذج)، ارتباط شروح الإصدار.

9) التكامل مع SLO/ميزانية الخطأ

تجارب الخطة ضمن ميزانية الأخطاء: يجب ألا «تعطل» الفوضى الأهداف الفصلية.
تنبيهات معدل الحرق كتبديل قتل تلقائي.
تقرير: «كم احترقت الميزانية»، «ما الذي ينحرف عن الحالة الثابتة».

10) أيام اللعبة (تمرين)

السيناريو: أسطورة موجزة (على سبيل المثال «المنطقة الشرقية المفقودة»)، خطوات الحقن، أهداف SLO، الأدوار، الوقت.
التصنيف: RTO/RPO الفعلي، جودة الاتصالات، صحة الدليل.
الرجعية: قائمة التحسينات مع المالكين والمواعيد النهائية، تحديث الوثائق/لوحات القيادة.

11) التشغيل الآلي و CI/CD

فوضى الدخان: اختبارات مرحلية قصيرة في كل إصدار (على سبيل المثال 1 جراب قتل + 200 م تأخير لكل طريق).
ليلية/أسبوعية: سيناريوهات أثقل (5-15 دقيقة) مع تقرير.
بوابات الترويج: إذا كانت p95/أخطاء> عتبة الكناري - التراجع التلقائي.
مستودعات مع كتالوج من التجارب (YAML + runbook + SLO-العتبات).

12) الأنماط المضادة

«كسر الطعام بدون درابزين»: لا معايير توقف، لا تحت الطلب → خطر وقوع حادث حقيقي.
عمل لمرة واحدة بدلاً من العملية.
الفوضى بدون حالة ثابتة: ليس من الواضح ما الذي يعتبر نجاحًا/فشلًا.
إعادة التدوير المفرطة → DDoS الذاتي عند حقن التأخير.
تجاهل SLI للأعمال: نجاح «تقني» عندما تفشل المدفوعات/الطلبات.
عدم وجود مالكي التحليل والتحسين.

13) قائمة التنفيذ المرجعية (0-45 يومًا)

0-10 أيام

حدد SLI الحالة الثابتة (المستخدم + الأعمال).
اختر أداة (Chaos Mesh/Litmus/Toxiproxy/FIS).
وصف الدرابزين: نصف قطر الانفجار، معايير التوقف، النوافذ، الأدوار.

11-25 يومًا

قم بإجراء التجارب الأولى: قتل الكبسولة، تأخير 100-200 مللي ثانية لكل منبع حرج، قم بإسقاط 1٪ من الحزم.
قم بتهيئة تنبيهات معدل الحرق، وربط مفتاح القتل بمعايير التوقف.
اقض أول يوم للعبة، واجمع الرجعية والإصلاحات.

26-45 يومًا

أضف مستوى AZ/نصوص التبعية (خارجي PSP، DB-lag).
أتمتة الفوضى الليلية عند الانطلاق ؛ إعداد السيناريوهات «الموسمية» (القمم).
فهرس التجارب والتقارير المنتظمة للإدارة/SRE.

14) مقاييس النضج

≥80٪ من الطرق الحرجة لديها التجارب الموصوفة ومقاييس الحالة الثابتة.
يتم تشغيل مفتاح القتل التلقائي عند تجاوز عتبات معدل الخطأ p99/الخطأ.
فصلية - مستوى يوم اللعبة AZ/المنطقة ؛ ≥1 مرات/شهر - السيناريو المستهدف للتبعيات.
ينخفض MTTR بعد دورة من التحسينات، وينخفض ارتباط «إطلاق ↔ الحادث».
تنخفض نسبة «غير المتوقعة» في الإخفاقات الحقيقية → تميل إلى الصفر.
تُظهر لوحات القيادة «المرونة» كمؤشرات أداء رئيسية (معدل الحرق، ووقت الاسترداد، ونسبة إجراءات DR الناجحة).

15) أمثلة على حواجز الحماية ومحفزات التوقف

توقف عند: «http _ req _ failed> 1٪» 3 دقائق، «p99> 1000 ms' 3 نوافذ»، الإيداع _ النجاح <99. 5%`.
تقليل نصف قطر الانفجار: التراجع التلقائي للبيان، وإعادة أوزان GSLB، وتعطيل حقن الصدع.
أمر التوقف: زر/نص واحد مع تسجيل الأسباب.

16) الثقافة والعمليات

الفوضى جزء من إيقاع SRE، وليست «متطرفة».
الإبلاغ الشفاف، التعرف على الضعف، الإجراءات التصحيحية.
التدريب عند الطلب، ومحاكاة الاتصالات مع العملاء/الشركاء.
الربط مع SLA/SLO والميزانيات: يجب أن تعزز الفوضى الموثوقية ولا تقوضها.

17)

تحول شركة Chaos Engineering «الأمل في التسعات» إلى استدامة يمكن إثباتها. صياغة حالة ثابتة، ووضع درابزين، وتحطيم صغير ومضبوط، ومراقبة SLO و SLI التجارية، وتسجيل التحسينات وأتمتة. ثم ستصبح الإخفاقات الحقيقية أحداثًا خاضعة للرقابة: RTO يمكن التنبؤ بها، وميزانية الأخطاء المحمية واستعداد الفريق للعمل دون ذعر.