الزام هر بانک به ایجاد مرکز داده اصلی، پشتیبان و بحران، سالها یکی از پایههای تداوم کسبوکار در شبکه بانکی بوده است. بهزاد صفری، مشاور مدیرعامل بانک سپه، معتقد است افزایش هزینه تجهیزات، دشواری تأمین برق، تحریم و تهدیدهای فیزیکی نشان دادهاند که اتکا به این مدل، بهتنهایی تابآوری بانکها را تضمین نمیکند. از نگاه او، مسئله امروز فقط تعداد مراکز داده نیست؛ معماری نگهداری و بازیابی داده باید تغییر کند.
صفری در گفتوگو با رضا قربانی، بنیانگذار راه پرداخت، به اظهارنظری در سال ۱۴۰۳ اشاره میکند که در آن، ایجاد زیرساختی مشترک برای استفاده بانکها را بهعنوان یکی از راهکارهای احتمالی مطرح کرده بود. او توضیح میدهد که هدفش تجویز یک مرکز داده متمرکز نبوده و آن پیشنهاد صرفاً مثالی برای بازاندیشی در هزینه سنگین ساخت سه مرکز داده مستقل برای هر بانک بوده است.
.h_iframe-aparat_embed_frame{position:relative;}.h_iframe-aparat_embed_frame .ratio{display:block;width:100%;height:auto;}.h_iframe-aparat_embed_frame iframe{position:absolute;top:0;left:0;width:100%;height:100%;}
به گفته او، در دو سال گذشته اجرای پروژههای مرکز داده نهتنها سادهتر نشده، بلکه افزایش نرخ ارز، محدودیت تأمین تجهیزات، هزینه نگهداری، سرمایش و دسترسی به برق، کار را پیچیدهتر کرده است. در عین حال، تجربه اختلالها و حملات اخیر نیز نشان داده که داشتن چند سایت با معماری مشابه، الزاماً مانع از توقف خدمت نمیشود؛ بهویژه اگر سایت اصلی و پشتیبان بهصورت همزمان هدف قرار گیرند.
راهکار کوتاهمدت از نگاه صفری، نگهداری نسخههای پشتیبان بهصورت توزیعشده است. این نسخهها میتوانند براساس نیاز بانک بهشکل سرد، آفلاین یا آنلاین نگهداری شوند تا یک رویداد واحد نتواند همه مسیرهای بازیابی را از دسترس خارج کند. چنین مدلی قرار نیست مشکل معماری قدیمی را یکباره حل کند، اما میتواند فاصله بانک تا رسیدن به زیرساختی منعطفتر را پوشش دهد.
مسیر بلندمدت، حرکت به سمت سامانههای کربنکینگ مبتنی بر معماری Cloud-Native و استانداردهای جدید زیرساخت است. صفری میگوید سامانههای اصلی بانکداری موجود در کشور، دستکم براساس بررسیهای مورد اشاره او، هنوز بهصورت واقعی برای استقرار بومی روی ابر طراحی نشدهاند. انتقال یک نرمافزار قدیمی به زیرساخت ابری نیز لزوماً آن را به محصول Cloud-Native تبدیل نمیکند؛ زیرا معماری نرمافزار باید از ابتدا برای توزیعپذیری، مقیاسپذیری و بازیابی انعطافپذیر طراحی شده باشد.
او مانع مهاجرت بانکی به ابر را صرفاً رگولاتوری یا نگرانی امنیتی نمیداند. مسئله اصلی این است که بخش بزرگی از توان فنی و مالی بانکها صرف حفظ زیرساختهای موجود میشود و فرصتی برای بازطراحی بنیادی باقی نمیماند. وقتی سازمان برای تأمین تجهیزات، برق و نگهداری روزمره با مشکل روبهروست، توسعه معماری نسل بعد به اولویتی عقبافتاده تبدیل میشود.
بخش دیگری از معماری بحران، «ایرگپسایت» است؛ محیطی جداشده که بتواند هنگام ازکارافتادن زیرساخت اصلی، حداقل خدمات ضروری بانک را حفظ کند. صفری توضیح میدهد که سازمان پدافند غیرعامل پیشتر بانکها را به ایجاد چنین سامانهای ملزم کرده بود و رخدادهای اخیر ضرورت عملیاتی آن را بیشتر نشان دادهاند.
به گفته او، برخی بانکها این راهکار را در قالب یک هسته مستقل یا زیرساختی شبیه مینیکور دنبال میکنند و بعضی دیگر از ظرفیت نئوبانک خود برای ایجاد مسیر دوم خدمت استفاده میکنند. هدف این نیست که همه خدمات بانک در زمان بحران بدون تغییر ادامه پیدا کند؛ هدف، حفظ حداقل عملیات ضروری تا زمان بازیابی زیرساخت اصلی است.
این گفتوگو نشان میدهد تابآوری بانکی دیگر با شمارش مراکز داده سنجیده نمیشود. بانک میتواند سه سایت داشته باشد، اما اگر معماری، مسیرهای ارتباطی و نسخههای پشتیبان آن نقاط شکست مشترک داشته باشند، تعدد فیزیکی بهتنهایی کافی نیست. مسیر آینده ترکیبی از دادههای توزیعشده، ایرگپسایت، هستههای مستقل بحران و حرکت تدریجی به سمت معماری Cloud-Native است؛ تغییری که پیش از خرید تجهیزات بیشتر، به بازطراحی معماری نیاز دارد.