مهندسی هرج و مرج: انعطاف پذیری سیستم

مهندسی هرج و مرج: انعطاف پذیری سیستم

1) چرا مهندسی هرج و مرج

• فرضیه های تست در مورد رفتار سیستم و اعتبار SLO ؛
• شناسایی SPOFs پنهان، زمان بندی نادرست/retrays، اثرات آبشار ؛
• تیم های قطار: روز بازی، کار کردن runbooks، ارتباطات ؛
• برای ایجاد یک فرهنگ «پایداری به طور پیش فرض» به جای «امید به بهترین».

مهم: ≠ مهندسی هرج و مرج "همه چیز را شکستن. "این یک روش علمی است: حالت پایدار → فرضیه → نتیجه گیری → بهبود.

2) چرخه آزمایش پایه

1. حالت پایدار (خط پایه): کدام SLI ها پایدار هستند ؟ (به عنوان مثال، موفقیت ≤500 ms در 99. 95%).
2. فرضیه: با از دست دادن یک AZ، P95 <10٪ افزایش می یابد و ≥99 در دسترس بودن. 9%.
3. آزمایش: خطای برنامه ریزی شده با شعاع انفجار محدود و معیارهای توقف.
4. مشاهده: متریک/دنباله/سیاهههای مربوط، SLO سوختگی نرخ، SLI کسب و کار (به عنوان مثال، سپرده موفق).
5. بهبود: ما پیدا می کنیم، تغییر زمان بندی/محدودیت/مسیریابی، به روز رسانی runbook.
6. اتوماسیون/رگرسیون: تکرار در برنامه، اضافه کردن به CI/CD و تقویم بازی روز.

3) اول ایمنی

شعاع انفجار: با یک باریک شروع کنید - یک غلاف/نمونه/مسیر/فضای نام.
Guardrails: هشدار به SLO سوختگی نرخ (سریع/آهسته)، محدودیت retray، محدودیت QPS، بودجه حادثه.
معیارهای توقف: «اگر نرخ خطا> X٪ یا p99> Y ms N دقیقه - فورا متوقف شود و عقب نشینی کند».
ویندوز: ساعات کاری در تماس، ذینفعان اطلاع داده شده، نسخه های یخ زده.
ارتباطات: IC/Tech lead/Comms، کانال روشن (اتاق جنگ)، قالب پیام.

4) کلاس های شکست و ایده های فرضیه

شبکه: تاخیر/لرزش/از دست دادن، قطره جزئی از پورت ها، «flopping» ارتباط بین خدمات/PSP.
کامپیوتر/گره: کشتن فرآیندها، گرمای بیش از حد CPU، خستگی توصیفگرهای فایل، استخرهای اتصال باریک.
ذخیره سازی و پایگاه داده: رشد دیسک های تاخیر، کپی تاخیر، توقف یک شارد/رهبر، تقسیم مغز.
وابستگی ها: تخریب API های خارجی، محدودیت های ارائه دهنده، انفجار 5xx/429.
مدیریت تغییر: انتشار ناموفق، پرچم ویژگی بد، اجرای جزئی.
محیط: CDN کاهش می یابد، رانش DNS/Anycast، شکست حفاظت WAF/ربات.
منطقه/AZ: از دست دادن کامل یا حادثه «جزئی» (کمی بدتر و غیر قابل پیش بینی).

5) ابزارها و تکنیک ها

Kubernetes: هرج و مرج مش، Litmus، PowerfulSeal، kube-monkey.
ابرها: AWS Fault Injection Simulator (FIS)، دامنه های خطا در نزدیکی ابرها.
شبکه/پروکسی: Toxiproxy (سم TCP)، tc/netem، iptables، خطای فرستاده (تاخیر/سقط جنین)، تزریق گسل Istio.
فرایندها/گره ها: استرس-ng، cgroups/CPU-throttle، پر کردن دیسک.
مسیریابی ترافیک: وزن GSLB/DNS، تعویض قناری/آبی سبز برای چک های جعلی.

6) اسکریپت نمونه (Kubernetes)

6. 1 تاخیر/توقف در مسیر (خدمات مجازی Istio)

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 }

فرضیه: زمانبندی مشتری/بازپرداخت و CB ها p95 <300 ms و نرخ خطا <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"

فرضیه: pools/timeouts/cache تاثیر را کاهش می دهد ؛ پرداخت 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 در مقیاس خودکار گروه، مصنوعی افزایش EBS-latency، غیر فعال کردن NAT-GW در یک AZ.
معیارهای توقف ساخته شده برای معیارهای CloudWatch SLO.

8) معیارهای قابل مشاهده در طول هرج و مرج

SLO/SLI: کسری از درخواست های خوب، p95/p99، نرخ سوختن.
مدل RED برای مسیرهای بحرانی (نرخ، خطا، مدت زمان).
استخر: انتظار برای اتصال P95، استفاده.
DB: کپی تاخیر، قفل، درخواست رانندگی p95.
شبکه: انتقال مجدد، RTT، رفتار dscp/ecn.
SLI کسب و کار: موفقیت معاملات (سپرده/چک)،٪ بازده/خطاها.
ردیابی: مسیرهای انتخابی (نمونه)، همبستگی حاشیه نویسی انتشار.

9) ادغام با SLO/خطا بودجه

آزمایشات را در بودجه اشتباهات برنامه ریزی کنید: هرج و مرج نباید «اهداف سه ماهه» را مختل کند.
هشدار نرخ سوختگی به عنوان خودکار کشتن سوئیچ.
گزارش: «چقدر بودجه سوخته»، «چه انحراف حالت پایدار».

10) بازی روز (ورزش)

سناریو: افسانه کوتاه (به عنوان مثال «منطقه شرق از دست رفته»), مراحل تزریق, اهداف SLO, نقش, زمان.
Rating: RTO/RPO واقعی، کیفیت ارتباطات، صحت runbook.
Retro: لیست پیشرفت ها با صاحبان و مهلت ها، به روز رسانی اسناد/داشبورد.

11) اتوماسیون و CI/CD

Smoke-chaos: تست های مرحله بندی کوتاه در هر نسخه (به عنوان مثال 1 غلاف کشتن + 200ms تاخیر در هر مسیر).
شبانه/هفتگی: سناریوهای سنگین تر (5-15 دقیقه) با گزارش.
دروازه های تبلیغاتی: اگر p95/خطاها> آستانه در قناری - بازگشت خودکار.
مخازن با کاتالوگ آزمایش (YAML + runbook + SLO-آستانه).

12) ضد الگوهای

«شکستن غذا بدون نرده»: هیچ معیار توقف، بدون تماس → خطر یک حادثه واقعی است.
یک بار اقدام به جای روند.
هرج و مرج بدون حالت پایدار: مشخص نیست که چه چیزی به عنوان موفقیت/شکست محسوب می شود.
Retrays بیش از حد → خود DDoS هنگام تزریق تاخیر.
نادیده گرفتن SLI کسب و کار: موفقیت «Technarian» زمانی که پرداخت/سفارشات شکست خورده است.
عدم وجود صاحبان پس از تجزیه و تحلیل و بهبود.

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 پس از یک دوره بهبود کاهش می یابد، همبستگی «حادثه ↔ انتشار» کاهش می یابد.
نسبت افت «غیرمنتظره» در شکستهای واقعی به صفر میل میکند.
داشبورد ها «انعطاف پذیری» را به عنوان KPI ها (میزان سوختن، زمان بهبودی، نسبت اقدامات موفق DR) نشان می دهند.

15) نمونه هایی از گارد محافظ و متوقف کردن محرک

توقف در: 'http _ req _ failed> 1٪' 3 دقیقه، 'p99> 1000 ms' 3 پنجره، 'deposit _ success <99. 5%`.
کاهش شعاع انفجار: بازگشت خودکار آشکار، بازگشت وزن GSLB، غیرفعال کردن تزریق گسل.
فرمان توقف: تک دکمه/اسکریپت با ورود به سیستم از علل.

16) فرهنگ و فرآیندها

هرج و مرج بخشی از ریتم SRE است، نه «شدید».
گزارش شفاف، تشخیص آسیب پذیری، اقدام اصلاحی.
آموزش در تماس، شبیه سازی ارتباطات با مشتریان/شرکا.
پیوند با SLA/SLO و بودجه: هرج و مرج باید قابلیت اطمینان را افزایش دهد، نه تضعیف کند.

17) نتیجه گیری

مهندسی هرج و مرج «امید به نه» را به پایداری قابل اثبات تبدیل می کند. تدوین و فرموله حالت ثابت، نرده محل، شکستن کوچک و کنترل، مشاهده SLO و SLI کسب و کار، رکورد و بهبود خودکار. سپس شکست های واقعی به رویدادهای کنترل شده تبدیل می شوند: RTO قابل پیش بینی، بودجه خطای محافظت شده و تمایل تیم به عمل بدون وحشت.