Ваш банк или компания растет, клиентов становится в 2-3 раза больше, а ИТ-инфраструктура начинает трещать по швам. Знакомо?
Чтобы этого избежать при ее подготовке необходимо проанализировать несколько аспектов.
1) Текущая нагрузка и ее паттерны
- Не средние значения, а пиковые нагрузки по часам, дням, сезонам;
- География запросов: откуда приходят клиенты сейчас и откуда придут завтра;
- Самые «тяжелые» операции: открытие счета, переводы, кредитные решения;
2) Архитектурные ограничения
- Где находятся узкие места: базы данных, сетевые каналы, внешние API?
- Какие системы нельзя останавливать даже на минуту?
- Как устроена связность между модулями — можно ли масштабировать частично?
3) Человеческий капитал
- Сколько времени нужно на обучение новых специалистов?
- Есть ли документация, которая реально работает в чрезвычайных ситуациях?
4) Внешние зависимости
- Лимиты партнеров (платежные системы, скоринг, регуляторы);
- SLA поставщиков облачных услуг;
- Время восстановления при сбоях у провайдеров.
Некоторые элементы стратегии на основе анализа.
Гибридный подход к архитектуре
Не нужно ломать работающую систему.
Критические модули, такие как платежный шлюз и авторизация, переводим на небольшие независимые части (микросервисы) с возможностью автоскейлинга, позволяя им работать автономно. По остальному функционалу задаем четкие границы API для будущего разделения.
Геораспределение с умом
Для сокращения задержек к доступу данных не нужно строить 10 дата-центров по всему миру. Но 2-3 в ключевых регионах (ЦФО, Урал, Сибирь для России) в режиме active-active решат 80% проблем с доступностью.
Меры по подготовке ИТ-инфраструктуры:
1) Поэтапное шардирование баз данных (начинаем не со всей БД, а с самых нагруженных таблиц. Например, таблица транзакций шардируется по датам, таблица клиентов — по регионам).
2) Автоматизация развертывания и отката (если новый релиз вызывает проблемы — откат должен занимать минуты, а не часы).
3) Бизнес-мониторинг вместо технического (вместо мониторинга загрузки CPU, анализируем сколько клиентов не смогли войти в мобильный банк, долю платежей, которые проходят с первой попытки, время открытия нового счета).
4) Регулярные нагрузочные тесты не раз в год, а каждый квартал (сценарии должны имитировать реальный рост: «Что если завтра к нам придёт 100 000 клиентов из новой рекламной кампании?»)
Как считаете, лучше обнаружить слабые места сейчас или в момент, когда новые клиенты уже стучатся в дверь?
ГК Финрул
Чтобы этого избежать при ее подготовке необходимо проанализировать несколько аспектов.
1) Текущая нагрузка и ее паттерны
- Не средние значения, а пиковые нагрузки по часам, дням, сезонам;
- География запросов: откуда приходят клиенты сейчас и откуда придут завтра;
- Самые «тяжелые» операции: открытие счета, переводы, кредитные решения;
2) Архитектурные ограничения
- Где находятся узкие места: базы данных, сетевые каналы, внешние API?
- Какие системы нельзя останавливать даже на минуту?
- Как устроена связность между модулями — можно ли масштабировать частично?
3) Человеческий капитал
- Сколько времени нужно на обучение новых специалистов?
- Есть ли документация, которая реально работает в чрезвычайных ситуациях?
4) Внешние зависимости
- Лимиты партнеров (платежные системы, скоринг, регуляторы);
- SLA поставщиков облачных услуг;
- Время восстановления при сбоях у провайдеров.
Некоторые элементы стратегии на основе анализа.
Гибридный подход к архитектуре
Не нужно ломать работающую систему.
Критические модули, такие как платежный шлюз и авторизация, переводим на небольшие независимые части (микросервисы) с возможностью автоскейлинга, позволяя им работать автономно. По остальному функционалу задаем четкие границы API для будущего разделения.
Геораспределение с умом
Для сокращения задержек к доступу данных не нужно строить 10 дата-центров по всему миру. Но 2-3 в ключевых регионах (ЦФО, Урал, Сибирь для России) в режиме active-active решат 80% проблем с доступностью.
Меры по подготовке ИТ-инфраструктуры:
1) Поэтапное шардирование баз данных (начинаем не со всей БД, а с самых нагруженных таблиц. Например, таблица транзакций шардируется по датам, таблица клиентов — по регионам).
2) Автоматизация развертывания и отката (если новый релиз вызывает проблемы — откат должен занимать минуты, а не часы).
3) Бизнес-мониторинг вместо технического (вместо мониторинга загрузки CPU, анализируем сколько клиентов не смогли войти в мобильный банк, долю платежей, которые проходят с первой попытки, время открытия нового счета).
4) Регулярные нагрузочные тесты не раз в год, а каждый квартал (сценарии должны имитировать реальный рост: «Что если завтра к нам придёт 100 000 клиентов из новой рекламной кампании?»)
Как считаете, лучше обнаружить слабые места сейчас или в момент, когда новые клиенты уже стучатся в дверь?
ГК Финрул