انرژی و زیرساخت‌های حیاتی

زیرساختی که قرار نیست با اولین خرابی متوقف شود

در مجموعه‌های انرژی و زیرساخت‌های حیاتی، مسئله فقط دسترس‌پذیری یک سامانه نیست. گاهی توقف یک سرویس می‌تواند روی عملیات، هماهنگی تیم‌ها و تصمیم‌گیری در چند نقطه اثر بگذارد. برای همین طراحی باید از همان ابتدا فرض کند بخشی از مسیر ممکن است از دسترس خارج شود و سرویس همچنان باید قابل کنترل بماند.

درخواست جلسه فنی مشاهده همه صنایع

قبل از طراحی، این سؤال‌ها باید جواب داشته باشند

اگر یکی از مسیرها یا سایت‌ها از دسترس خارج شد، چه چیزی ادامه پیدا می‌کند؟

کدام سرویس‌ها واقعاً حیاتی‌اند؟
مسیر جایگزین ارتباط کجاست؟
Backup و DR چقدر از محیط اصلی مستقل‌اند؟
چه بخشی از زیرساخت Single Point of Failure است؟
در زمان بحران، چه چیزی باید اول برگردد؟

پایداری فقط با افزونگی به‌دست نمی‌آید

داشتن تجهیزات اضافه خوب است؛ اما معماری باید بداند در زمان خرابی چه کند

High Availability وقتی ارزش دارد که Failover، مسیر شبکه، دسترسی به داده و ترتیب بازیابی سرویس‌ها از قبل مشخص باشد. اگر هر لایه جداگانه مقاوم باشد ولی وابستگی بین آن‌ها دیده نشده باشد، همان نقطه اتصال می‌تواند کل سرویس را متوقف کند.

مسئله‌هایی که معمولاً باید کنار هم دیده شوند

پایداری، بازیابی و امنیت از هم جدا نیستند

High Availability واقعی

افزونگی باید در Compute، Storage، Network و برق دیده شود؛ اما مهم‌تر از آن، وابستگی بین این لایه‌هاست.

سایت‌های توزیع‌شده

وقتی سرویس‌ها در چند نقطه اجرا می‌شوند، ارتباط بین سایت‌ها، Latency، مسیر جایگزین و نحوه ادامه عملیات اهمیت بیشتری پیدا می‌کند.

Data Protection

نسخه پشتیبان باید خارج از محدوده حادثه باشد و Recovery آن هم در شرایط واقعی تست شده باشد؛ نه فقط روی کاغذ.

Disaster Recovery

در بحران باید روشن باشد کدام سرویس اول منتقل می‌شود، چه داده‌ای در دسترس است و بازگشت به سایت اصلی چطور انجام می‌شود.

امنیت و تفکیک

شبکه‌های مدیریتی، سرویس‌های زیرساختی و دسترسی کاربران باید مرزبندی مشخصی داشته باشند تا یک رخداد به همه بخش‌ها سرایت نکند.

ظرفیت و پشتیبانی

زیرساخت باید برای رشد بعدی جا داشته باشد و تیم پشتیبانی هم معماری را بشناسد، نه اینکه فقط در زمان خرابی وارد شود.

طراحی بر اساس Failure Domain

به‌جای اینکه بپرسیم «چه چیزی خراب می‌شود؟» می‌پرسیم «خرابی تا کجا اثر می‌گذارد؟»

ممکن است یک Host، یک Storage، یک Rack، یک لینک یا حتی یک سایت کامل از دسترس خارج شود. معماری باید از قبل مشخص کند اثر هرکدام تا کجا می‌رسد و چه بخشی از سرویس همچنان در دسترس می‌ماند.

در بررسی Failure Domain معمولاً این موارد را کنار هم می‌گذاریم

محل اجرای سرویس‌های حیاتی
وابستگی به Storage و Network
مسیرهای ارتباطی اصلی و جایگزین
محل نگهداری Backup و Replica
سناریوی Failover و Recovery
اولویت بازگشت سرویس‌ها

لایه‌های راهکار

برای زیرساخت حیاتی، هیچ لایه‌ای را نمی‌شود جدا دید

پایداری واقعی از کنار هم قرار گرفتن چند تصمیم درست به‌دست می‌آید؛ از مجازی‌سازی و شبکه تا Storage، Backup، DR و پشتیبانی.

Private Cloud و VCF

برای استانداردسازی، Lifecycle Management و مدیریت یکپارچه زیرساخت مجازی، بدون اینکه وابستگی‌های شبکه و Storage نادیده گرفته شوند.

خدمات VCF

Network و Security

طراحی مسیرهای جایگزین، Segmentation، Firewall و کنترل دسترسی برای اینکه اختلال یا رخداد امنیتی محدود بماند.

امنیت شبکه

Backup و Cyber Resilience

نسخه‌های مستقل، Immutable Backup و تست Recovery برای اینکه Backup خودش در همان حادثه از بین نرود.

راهکارهای Backup

DR و Business Continuity

تعریف RPO و RTO واقعی، ترتیب Failover و برنامه بازگشت برای سرویس‌هایی که توقف آن‌ها قابل پذیرش نیست.

Storage و Capacity

Performance، Fault Domain و ظرفیت قابل استفاده باید بر اساس بار واقعی سرویس و رشد آینده سنجیده شود.

پشتیبانی زیرساخت

پشتیبانی مؤثر فقط رفع خرابی نیست؛ باید تغییرات، ظرفیت، Incident و توسعه بعدی را هم در همان معماری دنبال کند.

پشتیبانی زیرساخت

نحوه شروع پروژه

اول باید بدانیم چه چیزی حیاتی است و خرابی آن چه اثری دارد

به‌جای اینکه جلسه را با لیست تجهیزات شروع کنیم، سرویس‌های مهم، وابستگی‌ها، مسیرهای ارتباطی، Backup، ظرفیت و سناریوهای خرابی را کنار هم می‌گذاریم. بعد از آن تازه می‌شود درباره طراحی درست تصمیم گرفت.

۰۱

سرویس‌های حیاتی

مشخص می‌کنیم چه چیزی باید همیشه در دسترس بماند و چه وابستگی‌هایی دارد.

۰۲

سناریوی خرابی

از خرابی یک جزء تا از دسترس خارج شدن یک سایت، اثر هر سناریو بررسی می‌شود.

۰۳

طراحی و Sizing

معماری، ظرفیت و مسیرهای جایگزین بر اساس نیاز واقعی طراحی می‌شوند.

۰۴

اجرا و تست

پس از اجرا، Failover، Recovery و مستندات باید در عمل قابل استفاده باشند.

اگر زیرساختی دارید که توقفش ساده نیست، از همان‌جا شروع کنیم

می‌توانید سرویس‌های حیاتی، محدودیت‌های فعلی و سناریویی که بیشترین نگرانی را ایجاد می‌کند با تیم فنی راگا مطرح کنید. هدف جلسه اول این است که مسئله و مسیر بررسی بعدی روشن‌تر شود.

درخواست جلسه فنی