علت اختلال در خدمات بانکی؛ نقص در به‌روزرسانی هسته بانکی مشترک و چالش‌های زیرساختی

رفتم بانک پولام رو برداشت کنم. گفتن پول میخوای چکار؟ از همون کارت استفاده کن!!!
مردک، پولم میخوام دست خودم باشه خب. و حالام میبینیم که حتی همون کارت هم تعطیل شده!!!

این گزاره از نظر فنی دقیق نیست و چند سوءبرداشت مهم در آن دیده می‌شود. نخست اینکه Java به‌عنوان یک «نرم‌افزار متن‌باز» تعریف نشده است، بلکه یک اکوسیستم برنامه‌نویسی است که شامل نسخه‌های مختلف و پیاده‌سازی‌های گوناگون می‌شود. بخشی از این اکوسیستم مانند OpenJDK متن‌باز است، اما در بسیاری از سازمان‌های حساس و به‌خصوص بانک‌ها، معمولاً از توزیع‌های تجاری یا سازمانی مانند Oracle JDK استفاده می‌شود. بنابراین نسبت دادن Java به‌عنوان یک نمونه ساده از «نرم‌افزار متن‌باز وابسته به اینترنت» دقیق نیست و تصویر اشتباهی از معماری واقعی سیستم‌ها ارائه می‌دهد.
نکته مهم‌تر این است که در زیرساخت‌های بانکی و سازمان‌های سطح Enterprise، اصولاً وابستگی مستقیم به اینترنت برای دریافت آپدیت‌ها یا کتابخانه‌ها در لحظه وقوع حادثه وجود ندارد. در چنین محیط‌هایی، معماری استاندارد به‌گونه‌ای طراحی می‌شود که تمامی مخازن نرم‌افزاری (Repositoryها)، بسته‌های امنیتی و Patchها از قبل به داخل شبکه سازمانی منتقل شده و در Mirrorهای داخلی نگهداری شوند. حتی در بسیاری از موارد، محیط‌های عملیاتی (Production) به‌طور کامل از اینترنت ایزوله هستند. بنابراین این تصور که در زمان بحران، سیستم بانکی برای رفع مشکل نیازمند اتصال به منابع جهانی و دانلود نسخه‌های جدید باشد، نشان‌دهنده یک ضعف معماری است، نه یک محدودیت ذاتی فناوری.
از طرف دیگر باید بین «رفع حادثه (Incident Response)» و «به‌روزرسانی نرم‌افزار» تفاوت جدی قائل شد. زمانی که یک اختلال در سامانه بانکی رخ می‌دهد، فرآیند حل مشکل معمولاً شامل تحلیل لاگ‌ها، بررسی وضعیت شبکه، دیتابیس، ذخیره‌سازی، سرویس‌ها، مکانیزم‌های Failover و بازیابی سرویس است. در چنین شرایطی، نصب یا دریافت نسخه جدید Java یا هر کتابخانه متن‌باز دیگر، جزء اقدامات اصلی و فوری محسوب نمی‌شود. این نوع اقدامات بیشتر در چرخه‌های برنامه‌ریزی‌شده نگهداری و Patch Management انجام می‌شود، نه در لحظه بحران.
همچنین باید توجه داشت که استفاده از فناوری‌های متن‌باز به‌خودی‌خود نه تنها مشکل‌ساز نیست، بلکه بخش جدایی‌ناپذیر از زیرساخت‌های بانکی مدرن در سراسر جهان است. سیستم‌های بانکی بزرگ نیز از Linux، Kubernetes، PostgreSQL، Kafka و بسیاری ابزارهای متن‌باز دیگر استفاده می‌کنند. تفاوت در اینجاست که سازمان‌های بالغ، این ابزارها را در قالب معماری کنترل‌شده، نسخه‌بندی‌شده و ایزوله‌شده به کار می‌گیرند، نه به‌صورت وابسته به اینترنت عمومی.
اگر در یک سناریو واقعی، قطع اینترنت بین‌الملل باعث کندی در رفع یک مشکل بانکی شده باشد، احتمالاً مسئله در جای دیگری است؛ مانند عدم دسترسی به Vendor Support خارجی، نبود Repository داخلی کامل، ضعف در فرآیند مدیریت Patch، یا وابستگی بیش از حد به سرویس‌های بیرونی برای مانیتورینگ، لایسنس یا مستندات. این‌ها نشانه‌های ضعف در طراحی عملیات (Operations) و تاب‌آوری سیستم (Resilience) هستند، نه ایراد ذاتی در Java یا متن‌باز بودن نرم‌افزارها.
در نتیجه، این گزاره با ساده‌سازی بیش از حد، علت یک مسئله پیچیده زیرساختی را به یک عامل سطحی تقلیل داده است. در حالی‌که در سیستم‌های بانکی واقعی، ریشه مشکلات معمولاً در معماری، فرآیندهای عملیاتی و مدیریت وابستگی‌هاست، نه در ماهیت فناوری‌های استفاده‌شده.