بانکداری و خدمات مالی

زیرساخت بانکی باید وقتی اوضاع عادی نیست هم جواب بدهد

در یک محیط بانکی، مسئله فقط سرعت سرور یا ظرفیت Storage نیست. سرویس باید در زمان افزایش بار، تغییرات زیرساخت، خرابی یک جزء و حتی بحران قابل اتکا بماند. برای همین طراحی را از پایداری، مسیر بازیابی و ریسک عملیاتی شروع می‌کنیم؛ بعد سراغ محصول می‌رویم.

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

سؤال‌هایی که در طراحی بانکی جدی‌اند

اگر یکی از اجزای اصلی از دسترس خارج شد، بعدش چه؟

سرویس از کجا ادامه پیدا می‌کند؟
Backup تا چه حد قابل اعتماد و قابل بازیابی است؟
برای Upgrade چقدر پنجره توقف داریم؟
شبکه و دسترسی‌ها چطور از هم تفکیک شده‌اند؟
ظرفیت فعلی تا چه زمانی جواب می‌دهد؟

چالش اصلی، فقط قطعی نیست

چند دقیقه اختلال می‌تواند از مرز تیم فنی عبور کند

وقتی یک سرویس بانکی متوقف می‌شود، موضوع خیلی زود به تجربه مشتری، عملیات شعب، تعهدات سازمان و فشار روی تیم فناوری می‌رسد. به همین دلیل زیرساخت باید فقط برای «کار کردن» طراحی نشده باشد؛ باید برای خرابی، تغییر، رشد و بازگشت کنترل‌شده هم آماده باشد.

مسئله‌هایی که معمولاً روی میز هستند

معماری خوب، قبل از بحران خودش را نشان می‌دهد

دسترس‌پذیری سرویس

خرابی یک Host، Storage، لینک یا سایت نباید بدون برنامه روشن، سرویس‌های حیاتی را متوقف کند.

تغییر و ارتقا

Upgrade و Migration باید با شناخت وابستگی‌ها، پنجره توقف و مسیر Rollback انجام شود؛ نه با امید به اینکه همه‌چیز طبق برنامه جلو برود.

بازیابی داده

وجود Backup به‌تنهایی کافی نیست. نسخه پشتیبان باید سالم، محافظت‌شده و در زمان موردنیاز واقعاً قابل بازیابی باشد.

رشد و ظرفیت

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

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

راهکار بانکی معمولاً یک محصول نیست؛ چند لایه باید با هم کار کنند

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

Private Cloud و VCF

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

خدمات VCF

Business Continuity و DR

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

Backup و Cyber Resilience

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

راهکارهای Backup

Network و Security

Segmentation، کنترل دسترسی و معماری ارتباطات باید با مدل سرویس و حساسیت داده هماهنگ باشد؛ نه اینکه بعداً به معماری اضافه شود.

امنیت شبکه

Storage و Capacity

Performance، رشد داده، Fault Domain و ظرفیت قابل استفاده باید با بار واقعی سرویس‌ها سنجیده شود، نه صرفاً عدد خام تجهیزات.

پشتیبانی و عملیات

بعد از تحویل، مسئله تمام نمی‌شود. Incident، تغییرات، ظرفیت و توسعه‌های بعدی نیاز به تیمی دارد که معماری را بشناسد و بتواند در زمان لازم وارد شود.

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

مدل ورود به پروژه

قبل از تغییر زیرساخت، باید بدانیم چه چیزی را نباید به خطر انداخت

به همین دلیل پروژه را با Assessment شروع می‌کنیم؛ سرویس‌های حیاتی، وابستگی‌ها، ظرفیت، سناریوهای خرابی و محدودیت‌های تغییر را کنار هم می‌گذاریم. بعد معماری و برنامه اجرا شکل می‌گیرد.

۰۱

Assessment

وضعیت موجود، ریسک‌ها و نقاط وابستگی را مشخص می‌کنیم.

۰۲

Design

معماری، Sizing، سناریوهای خرابی و مسیر تغییر را طراحی می‌کنیم.

۰۳

Implement

اجرا، Migration و تست را مرحله‌ای و با کنترل ریسک پیش می‌بریم.

۰۴

Operate

برای Incident، بهبود و تغییرات بعدی کنار تیم سازمان می‌مانیم.

در جلسه فنی چه چیزی بررسی می‌شود؟

جلسه باید به تصمیم بعدی کمک کند، نه فقط به معرفی محصول

اگر مسئله Upgrade، DR، Backup، ظرفیت یا امنیت باشد، سعی می‌کنیم در همان گفت‌وگوی اول محدوده مسئله روشن شود و مشخص کنیم برای تصمیم دقیق‌تر چه داده یا بررسی دیگری لازم است.

معمولاً این موارد روی میز می‌آید

سرویس‌های حیاتی و وابستگی آن‌ها
RPO و RTO مورد انتظار
وضعیت Backup و تست Recovery
ظرفیت Compute، Storage و Network
سناریوی Upgrade یا Migration
ریسک‌ها و محدودیت پنجره تغییر

اگر مسئله زیرساخت بانکی دارید، از همان مسئله شروع کنیم

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

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