سؤال طراحیِ قابلاعتماد این نیست که «اگر خراب شود»، این است که «وقتی خراب شد». دیسک میسوزد، سرور میمیرد، دیتاسنتر برق میرود — سیستم خوب برای همه اینها جوابِ از-پیش-طراحیشده دارد.
افزونگی در هر طبقه
- سرور: حداقل ۲ نمونه از هر سرویس پشت LB — خرابی یکی نامرئی است.
- دیتابیس: Replication + Failover خودکار (فصل ۳).
- دیتاسنتر: چند Availability Zone؛ حتی چند Region برای زلزله/قطع کامل.
- وابستگی بیرونی: درگاه پرداخت دوم، ارائهدهنده پیامک دوم — با سوییچ خودکار.
Active-Passive
یدکی آماده ولی بیکار؛ سوییچ هنگام خرابی. ساده، کمی downtime سوییچ.
Active-Active
همه نسخهها همزمان کار میکنند؛ استفاده کامل از ظرفیت، ولی نیازمند Stateless بودن یا همگامسازی جدی.
RTO / RPO
دو عدد فاجعه: چقدر طول میکشد برگردیم (RTO) و چقدر داده از دست میرود (RPO). بکاپِ ۲۴ساعته یعنی RPO تا ۲۴ ساعت!
Graceful Degradation
مغازه نمیبندد: پیشنهادگر خراب؟ پرفروشها را نشان بده. جستجو کند؟ نتایج کششده. هسته زنده بماند، تزئینات بعداً.
دشمن پنهان: خرابیهای همبسته. دو replica روی یک rack، دو LB پشت یک برق، retry storm ای که خودش DDoS داخلی میشود. افزونگیِ واقعی یعنی حذف سرنوشت مشترک — و تمرینِ خرابی (Chaos Engineering: عمداً بکُش، ببین چه میشود).
به زبان ساده
قابلیت اطمینان یعنی از پیش برای خرابیهای عادی برنامه داشته باشیم، نه اینکه بعد از حادثه دنبال راهحل بگردیم.
مثال واقعی
اگر یک دیتاسنتر قطع شد، نسخه دیگر سرویس باید با RTO مشخص بالا بیاید؛ این فقط با تمرین failover قابل اعتماد است.