---

ШАГ 2. Сравнение с требованиями стандартов (ISO/IEC 25010, IEC 61508) и банковскими нормами

· Коэффициент готовности (99.815%):
  · Стандарт/Норма: Для критически важных банковских систем (Core Banking, процессинг) целевой показатель Availability составляет 99.99% («четыре девятки») или 99.999% («пять девяток»).
  · Вывод: Не соответствует. Текущий показатель допускает простой около 1.6 часов в месяц (или ~16 часов в год), что неприемлемо для высоконагруженной транзакционной системы.
· Среднее время восстановления (20 минут):
  · Стандарт/Норма: Для автоматизированных систем с высоким SLA восстановление после критического сбоя должно укладываться в 5-10 минут. 20 минут — это показатель для систем с ручным вмешательством или сложной диагностикой.
  · Вывод: Выше нормы. Требуется оптимизация процедур восстановления.
· Процент успешных транзакций (99.96%):
  · Стандарт/Норма: ISO 25010 (Reliability) и требования платежных систем (PCI DSS) обычно допускают не более 1 ошибки на 10,000-100,000 операций в зависимости от критичности. 480 ошибок на 1.2 млн — это 0.04% ошибок (или 1 ошибка на 2500 транзакций).
  · Вывод: На грани нормы. Для внутренней бухгалтерии допустимо, для клиентского фронта (интернет-банк) — уже критично много. Необходимо выяснить природу этих 480 ошибок.

---

ШАГ 3. Анализ причин несоответствий

1. Почему СВМО (180 часов) ниже целевого значения?
Система падает в среднем каждые 7.5 дней (180 / 24). Это нестабильная система. Возможные причины:

· Утечки памяти (Memory Leaks): Приложение накапливает ошибки в ОЗУ, что приводит к падению примерно раз в неделю.
· Неоптимизированные запросы к БД: Долгие транзакции со временем блокируют пул соединений, вызывая отказ в обслуживании.
· Пиковые нагрузки: Каждые 7 дней могут происходить плановые тяжелые операции (например, формирование еженедельного отчета в фоне), вызывающие деградацию сервиса вплоть до отказа.

2. Почему СВВ (20 минут) превышает норму?

· Отсутствие автоматического перезапуска: Система упала и ждет ручных действий дежурного инженера (пришел, увидел алерт, перезапустил сервис).
· Долгая загрузка кэша: После рестарта приложение долго прогревает кэш данных из базы (1.2 млн транзакций в месяц подразумевают огромный объем справочников).
· Сложная диагностика: 20 минут уходит не на восстановление, а на выяснение причины сбоя в логах.

3. Какие факторы могут влиять на процент успешных транзакций?
480 ошибок из 1.2 млн за 3 месяца (2160 часов) — это 160 ошибок в месяц или ~5 ошибок в день.

· Таймауты сети: СВВО = 1.2 сек. Если база данных отвечает дольше 1.2 сек из-за блокировок, клиент получает отказ (неудачная транзакция).
· Deadlock'и (взаимные блокировки): Классическая проблема СУБД при параллельной записи. Одна из транзакций принудительно откатывается как неудачная.
· Ошибки валидации на бэкенде: Клиент отправляет данные, которые не проходят проверку целостности из-за временного сбоя в справочных сервисах.

---

ШАГ 4. Рекомендации по улучшению надежности системы

№ Рекомендация Улучшаемая метрика Действия Ожидаемый результат
1 Внедрение механизма автоматического перезапуска (Watchdog/Supervisor) СВВ (снижение до 2-3 мин) Настроить мониторинг процесса ОС (systemd, Kubernetes liveness probe). При зависании процесса не ждать человека, а принудительно перезапускать контейнер/сервис. Снижение времени простоя с 20 до 2 минут. Рост КГ до 99.98%.
2 Оптимизация «холодного старта» (прогрев кэша) СВВ (снижение) Настроить lazy loading (отложенную загрузку) данных и персистентное хранение кэша между рестартами (например, Redis с сохранением на диск). Восстановление работоспособности сервиса сразу после запуска JVM/.NET процесса. СВВ < 1 минуты.
3 Анализ и исправление причин 12 отказов за период СВМО (увеличение) Провести Root Cause Analysis (RCA) по каждому из 12 инцидентов. Исправить критические баги, вызывающие падение раз в 7 дней (скорее всего, это утечка соединений к БД). Увеличение СВМО до 500+ часов (1 раз в месяц).
4 Внедрение паттерна Circuit Breaker (Предохранитель) ПУТ (до 99.999%) Настроить таймауты и повторные попытки (Retry) для вызовов к БД. Если БД тормозит (за 1.2 сек не ответила), не падать с ошибкой 500, а повторить запрос один раз через 100 мс. Уменьшение количества неудачных транзакций на 90%.
5 Внедрение средств профилирования SQL-запросов СВМО, СВВО Выявить запросы, которые выполняются дольше 1 секунды (тяжелые JOIN или отсутствие индексов). Оптимизировать индексы БД. Снижение среднего времени обработки транзакции с 1.2 до 0.3 сек, снижение нагрузки на CPU.

---

ШАГ 5. Итоговое заключение

Рассчитанные показатели надежности демонстрируют, что текущая версия информационной системы не соответствует отраслевым банковским стандартам по критерию отказоустойчивости и доступности. Система имеет «хроническое заболевание», приводящее к отказу раз в неделю (СВМО = 180 часов).

Приоритетной задачей является проведение детального расследования (RCA) причин регулярных падений и внедрение автоматического восстановления. Реализация предложенных мероприятий позволит повысить коэффициент готовности с 99.815% до целевых 99.99% и снизить количество ошибок транзакций