تست پایداری

1) مفاهیم و اهداف اساسی

قابلیت اطمینان - احتمال عملکرد ؛ انعطاف پذیری - رفتار در طول و پس از یک شکست.
SLO/بودجه اشتباه: معیارهای «پذیرش» تخریب.
فرضیه حالت پایدار: انتظار رسمی از معیارهای پایدار (به عنوان مثال p95 <200 ms، نرخ خطا <0. 5%). آزمایش موفقیت آمیز در نظر گرفته می شود اگر فرضیه پایدار باشد.
انواع خرابی: شبکه (تاخیر، از دست دادن/تکراری، شکست)، محاسباتی (CPU، حافظه)، ذخیره سازی (I/O، خستگی دیسک)، وابستگی (5xx، timeouts، rate-limit)، منطقی (حوادث جزئی، «تخریب آهسته»)، عملیاتی (انتشار، پیکربندی)، «تاریک» (تقسیم مغز، شیفت ساعت).

2) هرم پایداری

1. تست واحد شکست منطق (retrays، idempotency، timeouts).
2. آداپتورهای کامپوننت با تزریق خطا (Testcontainers/tc-netem).
3. ادغام/سیستم با شبکه/پایگاه داده/کش ها و پروفایل های دنیای واقعی.
4. آزمایش های هرج و مرج در pre-prod (و سپس در prod محدود) در runbooks.
5. روز بازی - تمرینات سناریو تیم (مردم + ابزار).

3) قابلیت مشاهده به عنوان پایه

SLI: p50/p95/p99 تاخیر، میزان خطا، اشباع (CPU/heap/FD/IOPS)، افت/زمان، عمق صف.
ردیابی: برای پیدا کردن تنگناها تحت شکست.
معیارهای انعطاف پذیری معنایی: میزان موفقیت برازنده-تنزل، میزان درخواست ریختن، میزان خود بهبودی (MTTR).
آزمایش برچسب زدن: "هرج و مرج. experiment_id'، 'phase = inject/recover' در رویدادها/سیاهههای مربوط.

4) کاتالوگ تزریق گسل

شبکه: تاخیر/لرزش، از دست دادن/تکراری/مرتب سازی مجدد، محدودیت پهنای باند، طوفان پشت سر هم، TLS شکسته.
میزبان: حد CPU، نشت/محدودیت حافظه، مکث GC، خستگی توصیف کننده، «انحراف ساعت».
ذخیره سازی: افزایش تاخیر، EROFS، ENOSPC، تخریب ماکت، از دست دادن رهبر.
وابستگی: 5xx/429، کاهش سرعت، DNS flapping، گواهینامه های قدیمی، محدودیت نرخ، «پاسخ های جزئی».
داده ها: نوشتن فساد، «سوراخ» در جریان، تکراری رویداد، درگیری های نسخه.
عملیات: انتشار ناموفق، پرچم ویژگی، رانش پیکربندی، خطای دستی (به عنوان بخشی از شبیه سازی).

5) الگوهای پایداری (چه چیزی را بررسی کنید)

Jitter retraces و وقفه در هر RPC.
قطع کننده مدار (باز/نیمه باز، بازیابی نمایی).
Bulkheads (جداسازی استخرها/صف به حوزه های بحرانی).
کاهش بار (تنظیم مجدد درخواست های کم اولویت هنگام اشباع).
فشار برگشتی (به زنجیره سیگنال میدهد، محدودیتهای همروندی).
Idempotency (کلید idempotency در «عوارض جانبی»).
ذخیره سازی و پشته در صورت تخریب منبع.
تخریب برازنده (پاسخ های سبک وزن، داده های قدیمی، ویژگی های غیرفعال).

اتمام وقت - بودجه

اتمیسیتی/جبران خسارت (جعبه ورودی Saga/Outbox/Transactional).
Quorums و تکرار (quorums R/W، تخریب سازگاری برای در دسترس بودن).
ضد آنتروپی/پخش (بازیابی از سوراخ رویداد).

6) نسخه برای تزریق و انتظارات (pseudocode)

Retray با لرزش و شکن

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

سایه و Backprescher

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

عدم توانایی

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) آزمایش: سناریوها و فرضیه ها

7. 1 «وابستگی آهسته»

تزریق: + 400 ms p95 به API خارجی.
انتظار: رشد زمان ≤ X٪، باز کردن شکن، پاسخ های fallback، صرفه جویی در خدمات p99 <SLA، بدون آبشار در طول بازپرداخت.

7. 2 «از دست دادن حافظه پنهان جزئی»

تزریق: شکست 50٪ از گره های Redis/Cache shard.
انتظار: افزایش خانم، اما بدون بهمن به منبع (درخواست TTL coalescing/غیر قابل تغییر)، خودکار گرم کردن و بازیابی.

7. 3 «تقسیم مغز در پایگاه داده»

تزریق: از دست دادن رهبر، تغییر به ماکت.
انتظار: انکار کوتاه مدت سوابق، خواندن از حد نصاب، بدون از دست دادن داده ها، Outbox پیام ها را از دست نمی دهد.

7. 4 «ENOSPC/دیسک کامل»

تزریق: 95-100٪ دیسک.
انتظار: چرخش اضطراری سیاهههای مربوط، شکست از ویژگی های غیر مسدود کردن، ایمنی سیاهههای مربوط به بحرانی (WAL)، هشدار و autoliquids.

7. 5 «انفجار ترافیک»

تزریق: × 3 RPS به نقطه پایانی داغ 10 دقیقه.
انتظار: سایه کم اولویت، p95 پایدار برای مسیرهای «هسته ای»، رشد صف در محدوده، بدون طوفان DLQ.

7. 6 «ساعت چوله»

تزریق: تغییر زمان گره توسط +/ − 2 دقیقه.
انتظار: TTL/signatures (leeway) صحیح، تایمر یکنواخت در بازپرداخت، نشانه های معتبر با رانش قابل قبول.

8) محیط و ایمنی آزمایش

با پیش تولید، داده های مصنوعی، پیکربندی/توپولوژی تا حد ممکن نزدیک به محصول شروع کنید.
در فروش - فقط پنجره های کنترل شده، پرچم های ویژگی، دامنه گام به گام، بازگشت خودکار، «دکمه قرمز».
Guardrails: محدودیت RPS/اشکال، نگهبانان SLO، جلوگیری از انتشار در حوادث بحرانی.
یک کتاب اجرا مورد نیاز است: چگونه به عقب بر گردیم، چه کسی تماس بگیرد، کجا نگاه کند.

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

کاتالوگ آزمایشات به عنوان کد (YAML/DSL): اهداف، تزریق، معیارها، آستانه ها، دکمه های «برگشت».
هرج و مرج دود در هر نسخه: تزریق کوتاه (به عنوان مثال 2 دقیقه + 200 میلی ثانیه به اعتیاد) در مرحله.

شب ماتریس اجرا می شود - خدمات × حالت های شکست

Release gate: ممنوعیت استقرار در صورتی که ثبات زیر آستانه باشد (به عنوان مثال، «پوشش fallback <95٪» تحت «وابستگی آهسته»).

10) اطلاعات و سازگاری

Check compensation (Saga): بخشی از عملیات انجام شده باید به حالت توافق شده آورده شود.
تکرار تست/تکرار رویداد، تحویل خارج از سفارش، سوراخ و تکرار.
بررسی متغیرهای دامنه پس از شکست: تعادل منفی نیست، معاملات گیر نمی کنند، محدودیت ها نقض نمی شوند.

11) ضد الگوهای

تست تنها مسیر شاد و بار بدون شکست.
Retray بدون لرزش → طوفان تحت تخریب.
بدون بودجه اتمام وقت جهانی → زمانهای آبشاری.
یک استخر واحد برای تمام وظایف → بدون انزوا (bulkheads).
«بی نهایت» صف → افزایش در تاخیر/PDE.
تله متری صفر آزمایش → شیوه های هرج و مرج «کور».
هرج و مرج در فروش بدون بازگشت/محدودیت/مالک مسئول.

12) چک لیست معمار

1. فرضیه حالت پایدار و SLO تعریف شده است ؟

2. هر RPC دارای وقفه، عقب نشینی jitter، breakers ؟

3. پیاده سازی bulkheads، limiters، backpressure، تخلیه بار ؟

4. کش ثابت: coalescing، حفاظت از کش طوفان، گرم کردن ؟

5. Outbox/Saga برای عوارض جانبی، کلیدهای بی نظیر ؟

6. Quorums/replication/feilover تست شده است ؟

7. آیا فهرستی از آزمایشات، هرج و مرج شبانه و دروازه ها در CI/CD وجود دارد ؟

8. معیارها/ردیابی آزمایشات علامت، داشبورد وجود دارد ؟

9. «کتاب اجرا» و «دکمه قرمز» آماده، مسئولیت اختصاص داده شده ؟

10. روزهای بازی به طور منظم شامل Dev/SRE/پشتیبانی ؟

13) ابزارهای کوچک و سناریوهای نمونه (طرح های YAML)

شبکه (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

پردازنده/پشته

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

وابستگی

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

نتیجه گیری

تست انعطاف پذیری یک «ترفند هرج و مرج» نیست، بلکه یک رشته ای است که باعث می شود سیستم قابل پیش بینی باشد. فرضیه های روشن، تله متری، کاتالوگ آزمایش های کنترل شده و الگوهای تعبیه شده در معماری (وقفه ها، قطع کننده ها، انزوا، idempotence) حوادث بالقوه را به سناریوهای کنترل شده تبدیل می کنند. تیم اعتماد به نفس در نسخه ها، و کاربران دریافت خدمات پایدار حتی در شرایط شکست.