در یکی از روزهای ابتدایی نوروز ۱۴۰۲، در حال جست‌وجو در یوتیوب بودم. مطلبی از دونالد کنوت، دانشمند برجسته رایانه و یکی از تأثیرگذارترین چهره‌ها در دنیای نرم‌افزار و برنامه‌نویسی نظرم را جلب کرد که طی دو سال گذشته من و هم‌تیمی‌هایم در داتین آن را با پوست و گوشت خود حس کردیم و همین چند ماه پیش یعنی در یکی از روزهای سال ۱۴۰۱، توانستیم از آن چالش به سلامت عبور کنیم. دونالد کنوت در مجموعه کتاب‌هایش به نام «هنر برنامه‌نویسی رایانه‌ای» که به‌طور گسترده تکنیک‌ها و الگوریتم‌های بهینه‌سازی را پوشش می‌دهد، می‌گوید: «بهینه‌سازی در طراحی الگوریتم و عملکرد سامانه بسیار کمک‌کننده است و حتی اگر راه‌حل فعلی بهینه در نظر گرفته شود، همیشه امکان یافتن راه‌حل بهتر وجود دارد». با تمرکز بر بهینه‌سازی که جنبه کلیدی کار و فلسفه دونالد کنوت است، می‌توان به هر سطحی از پیشرفت دست یافت. او توسعه‌دهندگان نرم‌افزار را تشویق می‌کند تا برای راه‌حل‌های کارآمد تلاش کنند و از جست‌وجو برای بهبود غافل نشوند، حتی اگر راه‌حل فعلی رضایت‌بخش به نظر برسد! توصیه‌ای که دقیقاً ما آن را در یک پروژه بزرگ‌مقیاس بانکی از نوع مهاجرت راهکار بانکی با گستره وسیعی از مشتریان، تراکنش‌ها، سپرده‌ها و مبادلات تجربه کردیم و با گوشت و پوست و استخوان خود آن را درک کردیم. درحالی که همه چیز در محیط تستی، به‌ظاهر کارکرد مناسبی داشت، اما به‌تدریج بروز نشانه‌هایی ما را به این سمت‌وسو سوق داد که بهتر است به فکر راه‌حل‌های جدیدی باشیم.
تست کارایی نرم‌افزار؛ چرا و چگونه؟
در سال ۱۴۰۰، ما در داتین مشغول انجام پروژه استقرار سامانه بانکداری متمرکز در یکی از بانک‌ها و ادغام تعداد مشخصی بانک زیرمجموعه آن در بستر سامانه بانک هدف بودیم. سیستم بانکداری متمرکز، سیستمی است که در آن تمامی اطلاعات در شبکه بانکی هدف در یک واحد مرکزی و به اصطلاح Core نگهداری می‌شود که مزایای زیادی دارد اما در این میان یکی از دلایل مهاجرت بانک‌ها از رویه‌ی سنتی غیرمتمرکز به متمرکز، ایجاد سهولت برای مشتریان در تعامل با سامانه‌های مرتبط است. در دنیای رقابتی امروز، گزینه‌های فراوانی پیش‌روی مشتریان قرار دارد و آنها تمایل به استفاده از خدمات مجموعه‌هایی را دارند که در کوتاه‌ترین زمان ممکن نیازشان را برطرف سازد. از این‌رو، گام برداشتن در مسیر تحقق سامانه بانکداری متمرکز برای رونق بخشیدن به کسب‌‌وکار بانک‌ها از طریق تحلیل درست نیازمندی‌ها، توسعه نیازها در قالب سامانه‌های یکپارچه و در نهایت استقرار (به‌معنای اجرا و راه‌اندازی سامانه در مجموعه مورد نظر)، ضرورتی انکارناپذیر است. در اجرای این پروژه، اول باید قابلیت اتصال و تعامل با بانک‌های زیرمجموعه در نرم‌افزارمان پیاده‌سازی می‌شد و کارفرما از ما گواهینامه تست کارایی نرم‌افزار متناسب با ابعاد فعالیت بانک هدف را می‌خواست. در واقع، «تست کارایی» یکی از انواع تست‌های نرم‌افزار است که هدف آن ارزیابی عملکرد و سرعت سامانه در شرایط مختلف است و می‌تواند برای بررسی میزان تحمل بار، پاسخگویی، استقرار، امنیت و مقیاس‌پذیری سامانه مورد استفاده قرار گیرد. این تست به ما کمک می‌کرد تا بفهمیم که سامانه چگونه در مقابل درخواست‌های همزمان و زیاد کاربران عمل می‌کند و آیا مشکلاتی در زمینه منابع، پایگاه داده، شبکه و غیره وجود دارد یا خیر! برای انجام تست کارایی نیاز بود تا استراتژی مورد نظر براساس حجم داده‌ها و فرایندهای موجود در بانک تعیین شود. این استراتژی مجموعه‌ای از تست‌ها و سناریوها متناسب با هریک از ابعاد فعالیت و خدمات بانک بود که برای بررسی دقیق و کامل عملکرد سامانه طراحی و پیاده‌سازی شد. درصورتی که اختلال یا نقصی در عملکرد شناسایی می‌شد، من و هم‌تیمی‌هایم در توسعه راهکار پرداخت داتین، کارهایی که لازم بود را برای اعمال تغییر و بهبود در دستور کارمان قرار می‌دادیم. در نهایت، پس از اتمام تست‌های کارایی و اطمینان از کارکرد درست سامانه در ابعاد مختلف، گزارشی از نتایج تست‌ها و میزان پاسخگویی متناسب با مقیاس پروژه تهیه شد و گواهینامه موردنظر را توانستیم به‌دست بیاوریم. این گواهینامه، نشان‌دهنده این بود که سامانه توسعه داده‌شده، کارایی و عملکرد مناسب را در انجام پروژه‌های بانکی مبتنی بر نیازمندی‌های از پیش تعریف‌شده دارد.
در طول این فرایند، هسته اصلی که وظیفه پردازش تراکنش‌ها را داشت، به‌صورت جداگانه تست کردیم. همچنین، نرم‌افزار سوئیچ که وظیفه ورود تمام تراکنش‌ها را به شبکه بانکی بر عهده داشت، توسط یک آزمایشگاه تست نرم‌افزار معتبر در یکی از دانشگاه‌های معتبر کشور آزمایش شد. در ابتدا با تغییرات در پیکربندی نرم‌افزار، تلاش کردیم با افزایش تعداد تراکنش‌ها در ثانیه بتوانیم معیارهای تست در این بخش را با موفقیت پاس کنیم. در ادامه، تلاش کردیم با اعمال تغییرات دیگری در بخش تحقیق و توسعه و معماری، کارکرد مطلوب‌تری را در سامانه به‌دست بیاوریم. پس از اقدامات انجام شده، تست کارایی گفته شده برای فرایندهای کاری بانک با در نظر گرفتن ادغام چند بانک در آن، انجام شد. نتیجه حاصله توام بود با پاسخگویی به تراکنش‌ها با کمترین اختلال ممکن! بر این اساس موفق شدیم گواهینامه تست کارایی را به‌دست بیاوریم.
مشکل پشت مشکل علی‌رغم موفقیت در دریافت گواهینامه!
با اینکه ما موفق شدیم گواهینامه تست کارایی را به‌دست بیاوریم، اما در عمل مشکلاتی به‌وجود آمد که نتایج مطلوب را خدشه‌دار کرد و نگرانی‌هایی را درباره صحت عملکرد سامانه به‌وجود آورد. یکی از این مشکلات، پس از مهاجرت ۵ بانک و ادغام آنها در بانک، مشخص شد. با ادغام صورت‌گرفته، تعداد تراکنش‌ها روزبه‌روز افزایش می‌یافت و به‌طور خاص در دو هفته آخر سال ۱۴۰۰، پاسخگویی به حجم بالای تراکنش‌ها به‌کندی پیش رفت. این اتفاق، در واقع نشانه‌ای بود که در سامانه عیبی وجود دارد؛ مسئله‌ای که چشم‌پوشی از آن و تأکید بر موفقیت در کسب گواهینامه استانداردهای لازم، زیانی قابل توجه را به تیم پروژه تحمیل می‌کرد. البته، این تنها هشداری برای وجود نقص در سامانه در شرایط واقعی نبود.
در ادامه به‌شکل اتفاقی و در قالب یک رویداد عمومی توسط نهاد نظارتی، برنامه‌ای برای برگزاری یک مانور از ورودی اصلی سامانه سوئیچ یعنی سامانه رگولاتوری شتاب برای تمامی بانک‌ها در نظر گرفته شد. طبعاً، بانک گفته شده هم باید در این مانور شرکت می‌کرد. بر اثر تغییر مرکز داده و استفاده از سایت دوم برای ارسال تراکنش‌ها، زمان پاسخ سامانه برای انجام فرایندهای کاری بالا رفت. به‌طوری که عملیات مورد نظر در سناریوی از پیش تعیین شده مانور، دچار اختلال شد و به این نتیجه رسیدیم که احتمالاً تراکنش‌ها به‌درستی به سامانه ارسال نمی‌شوند. درنهایت، مشکل سوم زمانی رخ داد که رسیدیم به روزهای پایانی سال 1401. در پایان سال 1401، مثل دوره پیش، تعداد تراکنش‌ها به دلیل نزدیک شدن به پایان سال حدود 20 درصد نسبت به زمان مشابه سال قبل افزایش یافت که این موضوع باعث ایجاد تاخیر در زمان پاسخ‌دهی در سامانه شد.
جدی گرفتن نشانه‌ها و تلاش برای حل مشکل!
اگرچه برای هریک از این نشانه‌ها، دلایل فنی خاص خود را داشتیم، اما تواتر اتفاقات ما را واداشت تا به‌شکل ریشه‌ای علت را جست‌وجو کنیم. به تدریج پردازش تراکنش‌ها کاهش داده شد تا بتوانیم سرعت عملکرد سامانه را بهبود دهیم. این اقدام، از طریق بهینه‌سازی عملکرد کدها، بهبود سرورها و شبکه‌ها، بهبود مدیریت حافظه و استفاده بهینه از منابع سخت‌افزاری انجام شد. همچنین، بررسی ارتباط بین سوئیچ و سایت دوم رگولاتور بسیار مهم بود و ضرورت داشت که از نحوه ارتباط و انتقال داده‌ها بین مرکز داده جدید و سامانه، اطمینان پیدا کنیم. ممکن بود در این ارتباط، خطاهایی مثل از دست دادن داده‌ها یا عدم هماهنگی در پروتکل‌ها رخ دهد که باید شناسایی و رفع می‌شدند. همچنین، بررسی و بهینه‌سازی عملکرد سامانه در موقعیت مواجهه با بار شدید نیز اهمیت داشت. تحلیلی دقیق از میزان بار مورد انتظار در زمان مانور رگولاتور می‌توانست نیازمندی‌های سخت‌افزاری و نرم‌افزاری لازم را به‌دست دهد تا سامانه قادر به پردازش تراکنش‌ها در زمان اوج فشار کاری باشد. بنابراین، برای ردیابی مشکل تصمیم گرفتیم با تقلیل تعداد تراکنش‌هایی که از طریق پذیرنده‌هایی همچون خودپرداز و موبایل‌بانک به سامانه وارد می‌شوند، بار درخواست‌ها را کاهش دهیم و سعی بر شناسایی مشکل کنیم. بعد از این تغییر، میزان تحمل سامانه برای بار ورودی از سمت رگولاتور بیش از پیش شد. اما با افزایش مجدد ورودی در روزهای پایانی سال، کاهش بار پذیرندگی هم آنچنان کمکی در زمان پردازش تراکنش‌ها نکرد. پس از انجام تست‌ها و تغییرات مختلف در پیکربندی سیستم، دیدیم که با توجه به نتایج، وضعیت پایدارتری در تمامی درگاه‌های ورودی سامانه برقرار است و در نهایت مشکل برطرف شد. برای رفع این مشکل، از روش‌های مختلفی مثل تست‌های یکپارچه تراکنش‌ها، بهبود پیکربندی سامانه بر اساس تحلیل‌های انجام‌شده، بهینه‌سازی الگوریتم‌های مورد استفاده و افزایش ظرفیت سامانه استفاده کردیم. همین‌طور، راهکارهای پیشگیرانه مثل مشخص کردن نقاط ضعف سامانه و انجام به‌روزرسانی‌های منظم و به‌موقع را در دستور کار قرار دادیم. با اجرای این اقدام‌ها، مشکلات مربوط به افزایش تعداد تراکنش‌ها در پایان سال و در پی آن، عملکرد سامانه بهبود پیدا کرد.
اینجا همان نقطه‌ای است که پس از دو سال کار مداوم و تجربه شکست و پیروزی‌های کوچک و بزرگ، برای من دو تجربه ارزشمند داشت. اول اینکه، همواره راه‌حل بهتری برای رفع مشکل وجود دارد؛ حتی اگر تصور شود که راه‌حل فعلی بهینه است، نباید از جست‌وجو برای راه‌حل‌های جدید، باوجود بی‌استفاده بودن در لحظه فعلی غافل شد. همچنین، از تجربه‌های این‌چنینی می‌توان دریافت که محیط تست، توانایی شبیه‌سازی تمامی چالش‌های محیط عملیاتی را ندارد. در حقیقت در محیط تست، تعداد مشکلات و چالش‌ها کمتر از محیط عملیات است و عدم شناسایی آنها ممکن است باعث گمراهی ما درباره صحت عملکرد سامانه شود.
داتین
راهکارها
سرمایه‌های انسانی
ارتباطات