روایتی از تصمیم‌گیری برای یک اتفاق نادر داده‌ای

سال 1389 بود که من و همکارانم با بحرانی کابوس‌وار، آن‌هم از جنس از دست‌رفتن اطلاعات حساس پایگاه داده به دلیل نقص پیش‌آمده در سوئیچ بانکی، مواجه شدیم. در آن زمان، چهار سال از تاسیس شرکت فناپ می‌گذشت و ما در واحد راهکارهای بانکی مشغول به فعالیت بودیم. به تدریج مسئولیت‌های محوله به این واحد بیشتر و بیشتر و باعث شکل‌گیری داتین در سال 1390 شد. در ابتدا، در واحد راهکارهای بانکی مسئولیت مدیریت سوئیچ تراکنش‌های بانکی را برعهده داشتیم. توسعه این سوئیچ دو سال طول کشید و پس از استقرار در بانک، عملیات پشتیبانی لازم از آن صورت گرفت. پیش از آن‌که جزئیات مشکل رخ داده را بگویم، کمی از سوئیچ و کارکرد آن توضیح می‌دهم.

سوئیچ چیست و چه کاری را با تراکنش‌های بانکی ما انجام می‌دهد؟

سوئیچ یک نرم‌افزار است که توسط شرکت‌های ارائه‌دهنده راهکارهای بانکی توسعه داده می‌شود و هدفش، برقراری ارتباط با شتاب، شاپرک، سیستم‌های داخلی بانک‌ها مثل کارت، سرویس مدیریت کارت (CMS) و مواردی از این قبیل است. مطابق یک دسته‌بندی مشخص، سوئیچ‌ها از نوع پذیرندگی و یا صادرکنندگی هستند؛ سوئیچ‌های صادرکنندگی مربوط به کارت‌های صادر شده است، یعنی هر تراکنشی که با کارت یک بانک صورت بگیرد، در کل شبکه بانکی، نهایتاً به سوئیچ صادرکنندگی آن بانک می‌رسد و از آنجا به CMS و قسمت‌های مرتبط با ایجاد سند تراکنش ارسال می‌شود. در واقع، سوئیچ صادرکنندگی اطلاعات را از شتاب دریافت و به CMS بانک ارسال می‌کند. در کل، نرم افزار سوئیچ با انجام پردازش‌های مورد نیاز، شرایط اعطای دسترسی و احراز هویت پیام صادره را بررسی می‌کند و تشخیص می‌دهد که به کدام مقصد باید درخواست تراکنش را بفرستد. بعد از اینکه به مقصد مربوطه فرستاد و پاسخش را دریافت کرد، باید بداند که جواب مربوط به کدام تراکنش بوده و باید به کدام مبدا ارسال شود. از سوی دیگر، سوئیچ پذیرندگی مسئول پذیرش تراکنش‌های پذیرندگی یک بانک و یا شرکت‌های ارئه‌دهنده خدمات پرداخت (PSP) است. یعنی اگر با هر کارتی از ابزارهای پذیرندگی مربوط به یک شرکت ارائه‌دهنده خدمات پرداخت و یا درگاه‌های ورودی یک بانک استفاده شود، درخواست مورد نظر به سوئیچ پذیرندگی مذکور ارسال می­‌شود. منظور از ابزارهای پرداخت، دستگاه‌های خودپرداز، کارت‌خوان‌ها، موبایل‌بانک، تلفن‌بانک و مثال‌هایی از این دست است که بخشی از این ابزارها در اختیار بانک‌ها هستند و تعدادی هم در اختیار شرکت‌های psp. بنابراین هم بانک‌ها و هم pspها، سوئیچ پذیرندگی دارند اما صادرکنندگی فقط مختص بانک‌ها است. بنابراین سوئیچ پذیرندگی، مبدا تراکنش را از یک ابزار و یا درگاهی که مربوط به همان بانک یا psp است، دریافت می‌کند، پردازش‌های لازم را انجام و بعد تشخیص می‌دهد که باید به چه مقصدی ارسال کنند که این مقصد می‌تواند شتاب، شاپرک و یا CMS داخلی بانک باشد.

همه چیز خوب است، اما تو باور نکن!

برویم سراغ اصل داستان. در حالی‌که حدود سه سال از استقرار سوئیچ در بانک سپری می‌شد و ظاهراً همه چیز رو به راه به نظر می‌رسید، بروز یک مشکل پیش‌بینی‌نشده در سوئیچ تراکنش‌ها منجر به از کار افتادن سوئیچ شد و تراکنش‌ها چه از نوع پذیرندگی و چه صادرکنندگی، هیچ کدام پاسخی نمی‌دادند. در نتیجه، تعداد تماس‌ها از مشتریان سوئیچ به‌ویژه شبکه شتاب به دلیل اشکال در تراکنش‌ها، زیاد شده و همه کارتها و ابزارهای پذیرنگی از جمله دستگاه‌های خودپرداز بانک (ATM) و کارتخوان (POS) از کار افتاده بودند. بنابراین، خدمات پردازش تراکنش به مدت 7 ساعت متوقف شد و این مسئله فشار زیادی را از چند جهت به تیم فنی سوئیچ وارد کرد. پس از بررسی دقیق موضوع، مشخص شد که مشکل از پایگاه داده سوئیچ است. آن زمان، اوایل کار ما در پروژه اجرای خدمات بانکی بود و تقریباً واحدهای مشخصی برای انجام وظایف تخصصی شکل نگرفته بودند. در نتیجه، تمامی کارها از جمله مدیریت پایگاه داده‌ها، انتشار نسخه‌ها، تست و عملیات بر عهده تیم فنی گذاشته شده بود. سرانجام توانستیم مشکل پایگاه داده را حل کنیم و از اینکه می‌توانستیم سامانه را به مدار برگردانیم بسیار خوشحال بودیم. اما در لحظات آخر که به‌نظر می‌رسید همه مشکلات حل شده، فاجعه رخ داد! به دلیل یک اشتباه در پیکربندی پایگاه داده‌ها، فایل پشتیبانی قدیمی جایگزین داده‌های پایگاه داده سوئیچ شد. این فایل پشتیبانی مربوط به چند ساعت پیش بود و داده‌های چند ساعت اخیر در آن وجود نداشت و در چند ساعت، داده مرتبط با تراکنش‌های روز از دست رفته بود. پس از فشار زیادی که به تیم فنی آمده بود، حالا مشکل بسیار بزرگ‌تر و بحرانی‌تر شده بود و تعداد زیادی از مشتری‌ها، دغدغه تعیین تکلیف تراکنش‌هایشان را داشتند. اتفاق بدتر این بود که داده‌ای در دسترس نبود و در واقع اطلاعات مربوط به تراکنش‌های چند ساعت اخیر که مربوط به کارت و پذیرنده‌ها می‌شد، در پایگاه داده‌ها وجود نداشت و حوالی نیمه‌شب، فروشندگان منتظر بودند تا حسابشان تسویه شود و پول تراکنش‌ها را دریافت کنند. اگر داده‌ها در زمان تسویه وجود نداشتند، مبالغ تمامی تراکنش‌ها به‌عنوان مغایرت به حساب مشتری‌ها برگشت می‌خورد و در این حالت فروشنده‌ها ضرر می‌کردند. در مورد تراکنش‌های کارت نیز اوضاع به همین منوال بود.

چه باید می‌کردیم؟

سرعت عمل و یافتن راه‌حل درست برای برگشت از فاجعه، مهم‌ترین کار در آن لحظات بود. با تمرکز بر حل مسئله و پرهیز از یافتن مقصر و اتلاف زمان، طی جلسات فشرده، آثار جانبی و شاخص‌های مهم این واقعه را بررسی و بر اساس درجه حساسیت رتبه‌بندی کردیم. در اواخر شب باید دو عمل اساسی انجام می‌شد: یک، تسویه با پذیرنده‌ها و دوم، قرار دادن فایل مغایرت در سامانه شتاب. مشکل اصلی ما در تراکنش‌های پذیرندگی بود؛ بنابراین، تصمیم گرفتیم راه‌حل‌های پیشنهادی تیم فنی را بر اساس اینکه چقدر بار مالی و نارضایتی در مشتریان و بانک ایجاد می‌کرد، اولویت‌بندی کنیم. در نهایت، به این نتیجه رسیدیم که اولویت اصلی ما بازیابی تراکنش‌های ازدست‌رفته باشد، چون هیچ فایل پشتیبانی در دسترس نبود.

بهترین روش برای حل مشکل، استفاده از داده‌های کارتخوان‌ها در مکان فروشنده‌ها بود. کارتخوان‌ها چیزی به نام روزنامه دارند که اطلاعات تراکنش‌های روز را در خود ذخیره می‌کنند. این کار مطمئن‌ترین راه بود، اما مشکل آنجا بود که کارتخوان‌ها در سراسر کشور پخش بودند و کارگزارها باید به محل فروشندگان منتقل می‌شدند تا در آنجا اطلاعات را به شرکت می‌دادند. استفاده از این روش چند مشکل داشت: 1. زمانبر بودن کار، 2. هزینه برای انتقال کارگزارها به محل، یا نبود پذیرنده‌ها، 3. ایجاد حس ناپایداری برای پذیرنده‌ها و 4. مشکل رایزنی با بانک و گرفتن مهلت. بنابراین، ما باید روی راه‌حل‌های شدنی و سریع تمرکز می‌کردیم.

ایده‌ای برای نجات!

پس از بررسی همه راه‌حل‌ها، ایده‌ای به ذهنمان رسید: استفاده از فایل‌های ثبت وقایع (logs) در سامانه سوئیچ! واقعیت آن بود که تراکنش‌های ورودی و خروجی از سوئیچ در فایل وقایع ثبت می‌شدند و ما می‌توانستیم اطلاعات مربوط به تراکنش‌ها را از رکوردهای ثبت وقایع استخراج و در پایگاه داده تراکنش‌ها وارد کنیم. البته راه‌حل به آن آسانی هم نبود. این رکوردهای ثبت وقایع چندان قابل اعتماد نبودند و داده‌های کاملی نداشتند. در نهایت با اکتفا به این روش، برنامه‌ای نوشتیم که داده‌ها را از روی رکوردهای ثبت وقایع بخواند و وارد پایگاه داده‌های سویئچ کند. یعنی به‌جای داده‌هایی که در وقایع ثبت‌شده وجود نداشتند، داده‌های ساختگی (fake) وارد کردیم. این راه‌حل فقط برای تراکنش‌های موفق انجام شد، زیرا تراکنش‌هایی موفق بودند که انتقال پول در آنها انجام شده و باید در اواخر شب این مبالغ با پذیرنده‌ها تسویه می‌شدند. تراکنش‌های ناموفق به دلیل عدم انتقال پول، اولویتی برای استخراج اطلاعات مفید نداشتند.

چه چیزی یاد گرفتیم؟

در مطلب پیش‌رو، به شرح رویدادهای یک موقعیت واقعی پرداختیم که در آن نرم‌افزاری که سال‌ها بدون مشکل کار می‌کرد، ناگهان به‌علت وجود نقصی در عملکردش، پاسخی ارائه نداد و موجب از دست‌رفتن داده‌های حیاتی پایگاه داده شد. اگرچه، اتفاقاتی از این قبیل ممکن است نادر تلقی شود، اما پیامدهای جدی دارد و باید از آنها درس گرفت. این اتفاق برای ما هم درس‌آموخته‌های زیادی داشت که نحوه‌ تصمیم‌گیری در زمان بحران و به‌کارگیری راهکارهایی برای جلوگیری از بحران دو نکته کلیدی از دل این رخداد بود. در ادامه دقیق‌تر از این یادگیری‌های می‌گویم:

1. تصمیم‌گیری در لحظه مواجهه با بحران

از زمانی که آن اتفاق رخ داد، تمرکز تیم بر یافتن مقصر نبود، بلکه کل اعضای تیم روی یافتن راه‌حل متمرکز شدند و همه راه‌حل‌های ممکن از جنبه‌های گوناگون بررسی و اولویت‌بندی شدند؛ همچنین، برای حل مشکل با توجه به تنگی وقت، پیچیده فکر نشد، بلکه تمامی راه‌حل‌های ممکن و تا حد امکان اثربخش، روی میز مورد بررسی قرار گرفت.

2. تأمل درباره چرایی رخداد سانحه

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

خلاصه آنکه در لحظات بحرانی، «تمرکز بر راه‌حل‌های کارا» نه تنها چراغی است که راه را در تاریکی نشان می‌دهد، بلکه افکار ما را به سوی آینده‌ای بهتر هدایت می‌کند.