خب برنامه ساخته شد و در اختیار مشتری یا مخاطب قرار گرفت آیا برای بعدش آماده‌اید؟ بیاید با یک سناریو نرم‌افزاری شروع کنیم.
سناریو واقعی: اختلال نرم‌افزارهای بانکی در اثر حمله سایبری
در جریان جنگ ایران و اسرائیل، حملات سایبری گسترده‌ای به زیرساخت بانک‌ها بخصوص بانک سپه و پاسارگاد انجام شد که باعث از کار افتادن موبایل‌بانک و اینترنت‌بانک گردید. حتی پس از اعلام بازیابی، بسیاری از قابلیت‌های این ابزارهای نرم‌افزاری ناقص یا غیرفعال بودند.
1️⃣ Plan – برنامه‌ریزی ناکامل امنیتی
بانک‌ها از قبل برای توسعه و نگهداری نرم‌افزارهای مالی خود، برنامه‌های تحول دیجیتال و توسعه را تدوین کرده بودند؛ اما متأسفانه برنامه‌ریزی امنیتی بخشی ناقص و محدود به الزامات نظارتی داخلی بود.
🔻 خطا: سناریوهای بحران (مثل حمله سایبری دولتی) در برنامه لحاظ نشده بود یا در حد ضعیف بود.
📌 درس: برنامه‌ریزی نرم‌افزار فقط به نیازهای عملکردی نباید محدود شود؛ امنیت، پایداری، مقاومت در برابر بحران باید جزو اهداف باشد.
2️⃣ Design – طراحی بدون پیش‌بینی لایه‌های تاب‌آوری
طراحی نرم‌افزارهای بانکی، اغلب تک‌لایه و متکی بر اتصال دائمی به سرویس‌های مرکزی (مانند DNS یا پایگاه داده مرکزی) بوده است. به‌همین‌دلیل، با کوچک‌ترین اختلال در سرویس مرکزی، کل سیستم از کار افتاد.
🔻 خطا: طراحی فاقد نسخه‌ی آفلاین یا محدود (Degraded Mode) برای مواقع بحران بود.
📌 درس: طراحی نرم‌افزار باید دارای سناریوهای خطا، ماژول‌های جداشونده و مسیرهای جایگزین باشد.
3️⃣ Build – پیاده‌سازی و تست ناکافی در شرایط بحرانی
نرم‌افزارها پیش از استقرار تنها در شرایط پایدار تست شده بودند. نه زیر بار DDoS، نه در شرایط قطع اینترنت یا اختلال ارتباط با دیتابیس. بنابراین در عمل، هیچ آزمون واقع‌گرایانه‌ای از آن‌ها گرفته نشده بود.
🔻 خطا: فقدان تست‌های امنیتی (Vulnerability Scan، Penetration Test) و تست زیر فشار (Stress Testing).
📌 درس: فاز Build نباید فقط کدنویسی باشد؛ بلکه شامل ساخت زیرساخت تاب‌آور و محیط تست بحران‌محور است.
4️⃣ Deliver – استقرار عجولانه پس از بحران
پس از دو هفته، نرم‌افزارها به شکل محدود بازیابی شدند؛ اما برخی منوها، تنظیمات و عملکردها (مانند انتقال وجه، مشاهده مانده حساب، مدیریت کارت‌ها) غیرفعال بودند. این نشان‌دهنده‌ی استقراری ناقص و بدون کنترل کیفیت نهایی بود.
🔻 خطا: نسخه‌ی استقرار یافته فاقد کنترل پایانی و Regression Testing بود.
📌 درس: در شرایط بحران، استقرار باید مرحله‌ای و کنترل‌شده باشد، نه با فشار رسانه‌ای و بدون اطمینان.
5️⃣ Support – پشتیبانی با ظرفیت پایین در برابر بحران بزرگ
مرکز تماس بانک‌ها پاسخگوی حجم بالای تماس‌ها نبود. اپلیکیشن‌ها نیز فاقد پیام خطاهای دقیق بودند؛ تنها با عبارت‌هایی مانند "مشکلی پیش آمده است" کاربران را رها می‌کردند.
🔻 خطا: نداشتن مستند خطای واضح و پشتیبانی هوشمند (چت‌بات یا پیام داخل اپ).
📌 درس: نرم‌افزار در فاز پشتیبانی، نیاز به شفافیت در خطا، سیستم اطلاع‌رسانی درون‌برنامه‌ای و تیم پشتیبانی توانمند دارد.
6️⃣ Improve – بازنگری دیرهنگام پس از بحران
تحلیل پسارخداد (Post Incident Review) با تأخیر انجام شد. تا مدت‌ها بانک‌ها فقط به بازگرداندن سرویس اکتفا کردند، بدون اینکه مشکلات طراحی، امنیت یا معماری بررسی و اصلاح شود.
🔻 خطا: عدم تعریف فرآیند بهبود مستمر در چرخه حیات نرم‌افزار.
درس: بحران، فرصتی برای نوسازی، مقاوم‌سازی و طراحی مجدد سرویس‌هاست؛ نه فقط برگشت به نقطه قبل از حمله.
فراموش نباید کرد که:
🔹 چرخه‌ی حیات نرم‌افزار نباید فقط حول محور توسعه و استقرار بچرخد، بلکه باید امنیت، تاب‌آوری، تست در بحران و بهبود مستمر را در همه‌ی مراحل در خود بگنجاند.
🔹 ITIL 4 با تمرکز بر ارزش سرویس برای کاربر، مدیریت تجربه، و پاسخ‌گویی در بحران، بهترین الگو برای بازسازی سرویس‌های بانکی در دوران پس از جنگ سایبری است.
