МОДЕЛЮВАННЯ ВІДМОВОСТІЙКОЇ КОНФІГУРАЦІЇ ІНФОРМАЦІЙНОГО СЕРЕДОВИЩА БАНКУ

Анотація

Нормативні вимоги до операційної стійкості фінансового сектору визначають кількісні показники готовності критичних банківських сервісів, однак традиційна перевірка планів відновлення за принципом «успішно/неуспішно» не дає статистично обґрунтованої відповіді на питання, чи справді розгорнута конфігурація ці показники забезпечує. Коефіцієнт покриття відмов, тобто ймовірність того, що відмову буде виявлено й автоматично оброблено без переривання сервісу, у розрахунках готовності постулюється, але не вимірюється. У статті запропоновано метод експериментальної перевірки відмовостійкої конфігурації інформаційного середовища банку, що ґрунтується на контрольованому внесенні відмов у робоче середовище та інтервальному оцінюванні результатів. Показано, що програму випробувань доцільно формувати як проєкцію моделей аналізу ризиків – ранжування видів відмов за пріоритетним числом ризику та переліку захисних бар’єрів дерев відмов і подій, – завдяки чому кожна серія перевіряє окрему кількісну гіпотезу про конкретний механізм захисту, а її результат уточнює відповідний параметр моделі готовності. Формалізовано схему контрольованого експерименту, придатну для промислового банківського середовища: метрику усталеного стану, операційні означення моментів виявлення, локалізації та завершення перемикання, обмеження радіуса впливу пілотним контуром і критерій автоматичної дострокової зупинки. Методику статистичного опрацювання побудовано на довірчих інтервалах Вілсона та зведених оцінках для однотипних механізмів. Кількісно визначено потрібні обсяги випробувань і показано, що підтвердження покриття на рівні 0,99 потребує щонайменше 381 бездефектного прогону, що обґрунтовує автоматизацію внесення відмов. Метод апробовано на пілотному георозподіленому середовищі діючого банку: вісім серій загальним обсягом 261 прогін дали інтервальні оцінки покриття всіх ключових бар’єрів, виявили два приховані дефекти конфігурації, які не виводяться з аналітичних моделей, і показали, що ручне перемикання на резервний майданчик з медіаною 42 хв не відповідає нормативу часу відновлення найкритичнішого класу сервісів.