به گزارش پایگاه خبری بانکداری الکترونیک، محمود گودرزی، مدیر محصول سامانه هور، با تشریح تجربه توسعه این سامانه در شرایط بحران گفت: هور با هدف تداوم خدمات حیاتی بانکی در زمان اختلال یا از دسترس خارج شدن سامانه متمرکز بانکی طراحی شده است؛ سامانه‌ای که قرار نیست جایگزین تمام قابلیت‌های Core Banking باشد، بلکه مأموریت آن حفظ دسترسی مردم به ضروری‌ترین خدمات مالی در شرایط بحرانی است. به گفته او، در جریان توسعه هور، حدود ۵۰ قابلیت در مدت یک ماه به این سامانه افزوده شد و هم‌زمان معماری آن نیز برای پاسخ‌گویی به شرایط جدید و افزایش مقیاس‌پذیری توسعه یافت.
هور؛ راهکاری برای تداوم خدمات حیاتی
گودرزی درباره فلسفه شکل‌گیری هور اظهار کرد: «هور یک سامانه پشتیبان و در واقع راهکاری برای زمانی است که سامانه متمرکز بانکی دچار اختلال می‌شود یا از دسترس خارج می‌شود. در چنین شرایطی، هور می‌تواند وارد مدار شود و خدمات حیاتی مورد نیاز مشتریان را در اختیار آنها قرار دهد.
وی با تأکید بر اینکه هور از ابتدا با هدف جایگزینی کامل Core Banking طراحی نشده است، افزود: یک سامانه تداوم کسب‌وکار در شرایط بحران نمی‌تواند لزوماً جایگزین همه سرویس‌هایی شود، به همین دلیل، از ابتدا خدماتی را انتخاب کردیم که نبود آنها می‌توانست زندگی مالی مردم و فعالیت کسب‌وکارها را با مشکل جدی مواجه کند.
در نسخه اولیه هور، خدماتی مانند برداشت نقدی از شعب، انتقال وجه درون‌بانکی و انتقال پایا پیش‌بینی شده بود. همچنین مجموعه‌ای از سرویس‌های بک‌اند در اختیار بانک قرار گرفت تا برخی عملیات مورد نیاز مشتریان حقوقی، از جمله واریز حقوق و انتقال‌های دستی، امکان‌پذیر باشد.
اولویت‌بندی نیازها در دل بحران
مدیر محصول سامانه هور با اشاره به شرایط خاص و افزایش نیازهای بانک‌ها گفت: در ادامه، دامنه نیازمندی‌های مطرح‌شده به‌طور قابل توجهی افزایش یافت و تیم محصول وارد فرآیندی شد که در آن، نیازها مستقیماً از بانک دریافت و پس از اولویت‌بندی، بلافاصله وارد چرخه توسعه می‌شدند.
وی افزود: در واقع با یک سؤال صرفاً فنی مواجه نبودیم. مسئله این بود که اگر زیرساخت یک بانک به هر دلیلی، از حمله فیزیکی گرفته تا حمله سایبری، از دسترس خارج شود، چگونه می‌توان مستقل از زیرساخت آسیب‌دیده، خدمات ضروری را همچنان در اختیار مشتریان قرار داد راهکارهایی مانند هور در چنین شرایطی اهمیت خود را نشان می‌دهد.
گودرزی درباره نحوه انتخاب قابلیت‌هایی که باید به هور افزوده می‌شدند، گفت: معیار اصلی ما، تأثیر هر نیازمندی بر خدمت‌رسانی به مردم بود. نیازها را در جلسات مشترک با بانک دریافت و اولویت‌بندی می‌کردیم و پس از آن، تیم بلافاصله وارد چرخه تولید می‌شد تا قابلیت مورد نیاز در کوتاه‌ترین زمان ممکن در اختیار بانک و مشتریان قرار گیرد.
گودرزی تأکید کرد که حتی با گسترش قابل توجه هور نیز هدف، تبدیل این سامانه به جایگزین کامل Core Banking نبوده است؛ بلکه هدف ارائه خدماتی بود که از دید بانک، بیشترین تأثیر را بر زندگی روزمره مردم و استمرار فعالیت‌های مالی آنها داشته‌اند.
تداوم خدمت، معیار موفقیت هور
مدیر محصول هور همچنین معتقد است تعداد سرویس‌ها به‌تنهایی معیار مناسبی برای ارزیابی موفقیت یک سامانه تداوم کسب‌وکار نیست.
او در این‌باره توضیح داد: نرخ تداوم خدمات حیاتی یکی از شاخص‌هایی است که می‌توان برای ارزیابی موفقیت هور در نظر گرفت. شاخص دیگر، آمادگی و سرعت بازیابی است؛ یعنی بعد از وقوع اختلال، سامانه با چه سرعتی وارد مدار می‌شود و چه خدماتی را می‌تواند به‌صورت مستمر در اختیار مردم قرار دهد.
به گفته وی، استمرار خدمت‌رسانی علاوه بر پاسخ به نیازهای روزمره مشتریان، در حفظ اعتماد آنها و جلوگیری از آسیب به اعتبار بانک نیز نقش مهمی دارد.
اعتماد به بدنه فنی و توسعه سریع
گودرزی یکی از عوامل تعیین‌کننده در سرعت توسعه هور را اعتماد به تجربه و توانمندی بدنه فنی شرکت خدمات انفورماتیک عنوان کرد.
وی گفت: در لحظه بحران، حجم زیادی از نیازمندی‌ها از سوی بانک مطرح می‌شود و یکی از تصمیم‌های دشوار برای مدیر محصول این است که مشخص کند کدام نیاز را می‌توان در چه زمانی به یک سرویس عملیاتی تبدیل کرد. با شناختی که از تجربه و توان تیم فنی بود و اعتمادی که به این تیم وجود داشت، کمک می‌کرد در جلسات با بانک درباره زمان تحویل قابلیت‌ها با اطمینان بیشتری تصمیم گرفته شود.
به گفته گودرزی، بخش عمده تعهدات در زمان تعیین‌شده محقق شد؛ هرچند در برخی موارد، نیازمندی جدید با معماری اولیه هور تطابق کامل نداشت و حل آن زمان بیشتری نیاز داشت.سرعت توسعه تنها تصمیم مهم این دوره نبود. یکی از اصولی که تیم هور تلاش کرد در این مسیر حفظ کند، جلوگیری از انتقال پیچیدگی تغییرات به سامانه‌های بیرونی بود.
سرعت عرضه خدمات در برابر الزامات فنی
یکی از بخش‌های مهم تجربه توسعه هور، تصمیم‌گیری درباره سرعت عرضه قابلیت‌های جدید در شرایط بحران بود.
گودرزی در این‌باره گفت: بانک و تیم محصول باید یک تصمیم دشوار می‌گرفتند؛ اینکه با چه سرعتی نیازمندی‌ها را در اختیار مردم قرار دهیم تا خدمت‌رسانی مختل نشود، یا فرآیند را مشابه شرایط عادی و با زمان بیشتری پیش ببریم.
در نهایت، اولویت بر تسریع در ارائه خدمات مورد نیاز مردم قرار گرفت، این ریسک را پذیرفتیم تا سرویس‌ها با حداکثر سرعت ممکن در اختیار مردم قرار گیرند؛ به‌گونه‌ای که زندگی روزمره آنها فلج نشود و اعتمادشان به بانک حفظ شود. در مقابل، می‌دانستیم که بعد از فروکش کردن بحران باید زمانی را برای بازبینی و اصلاح موارد فنی اختصاص دهیم.
گودرزی همراهی بانک و پذیرش این تصمیم از سوی طرفین را یکی از عوامل مؤثر در سرعت عمل هور دانست و خاطر نشان ساخت و در خاتمه سه تصمیم مهم را در موفقیت هور موثر دانست. نخستین عامل، اعتماد به بدنه فنی باتجربه شرکت خدمات انفورماتیک بود؛ اعتمادی که به گفته او امکان تصمیم‌گیری و توسعه سریع در شرایطی با سطح بالایی از فشار و عدم قطعیت را فراهم کرد.
دومین تصمیم، حفظ ثبات رابط‌های بیرونی هور بود و تصمیم سوم به معماری هور مربوط می‌شد؛ تصمیمی که با طولانی‌تر شدن شرایط بحران اهمیت بیشتری پیدا کرد.
حرکت به سمت Kubernetes برای مقیاس‌پذیری بیشتر
گودرزی توضیح داد: «هور در ابتدا برای شرایط بحرانی کوتاه‌مدت، در حدود سه تا هفت روز، طراحی شده بود. وقتی شرایط طولانی‌تر شد، تصمیم گرفتیم پیش‌دستانه زیربنای معماری را تغییر دهیم و به سمت Kubernetes حرکت کنیم.
هدف از این تغییر، فراهم کردن امکان توسعه ماژولار، مشارکت هم‌زمان تیم‌های مختلف و افزایش مقیاس‌پذیری سامانه بود.
وی افزود: این تغییر کمک کرد هور از یک سامانه صرفاً تداوم کسب‌وکار به سامانه‌ای تبدیل شود که قابلیت مقیاس‌پذیری بیشتری دارد و می‌تواند در مواجهه با حجم بالاتر تراکنش‌ها نیز پاسخ‌گویی مناسبی داشته باشد.
به‌روز بودن داده‌ها در سامانه پشتیبان
یکی دیگر از موضوعاتی که گودرزی بر آن تأکید دارد، به‌روز بودن اطلاعات در سامانه پشتیبان است.وی با اشاره به الزام بانک‌ها برای برخورداری از راهکارهای پشتیبان گفت: «نقطه قوت ما این بود که توانستیم داده‌ها را به‌روز نگه داریم؛ به‌گونه‌ای که در بحران، حتی آخرین تراکنش‌های بانک و آخرین مانده‌های مشتریان را در اختیار آنها قرار دهیم.