|
Professor Seleznov
|
Современная розница уже не делится на «магазин» и «онлайн». Покупатель приходит в торговый зал, выбирает товар через мобильное приложение, оплачивает у кассы, забирает заказ из пункта выдачи и возвращает покупку курьером. Все эти сценарии опираются на одну ИТ-инфраструктуру: учётную систему, кассовый софт, сервисы лояльности и склада. Если хотя бы одно звено становится недоступным — останавливается не отдельный канал, а весь бизнес. Поэтому требование «работать 24/7» давно перестало быть лозунгом и превратилось в архитектурную задачу.
1. Сколько стоит минута простоя в рознице
Любая остановка ИТ-сервиса в рознице бьёт сразу по нескольким направлениям одновременно. В торговом зале формируется очередь, кассы перестают пробивать чеки, программы лояльности не начисляют баллы. На сайте срываются заказы, а служба поддержки получает шквал обращений. На складе блокируются комплектация и отгрузка. Все эти эффекты работают на одну и ту же метрику — снижение выручки и снижение доверия к бренду.
Особенность омниканальной модели в том, что у бизнеса нет «безопасных» окон. Магазины работают с раннего утра до позднего вечера, ночью идут служебные обмены, а онлайн-витрина не закрывается никогда. Время на восстановление измеряется не часами, а минутами: каждая минута без касс — это десятки несостоявшихся транзакций по всей сети.
В этой логике ключевой вопрос — не «как быстро мы починим», а «как сделать так, чтобы клиент в принципе не заметил инцидент». Ответ лежит в плоскости архитектуры, а не отдельных серверов или резервных копий.
2. Архитектурная развилка: распределенные базы или единая система
Исторически в торговых сетях прижились две модели работы с учётными данными. Первая — распределенные информационные базы (УРИБ): в центре — головная база на сервере, на периферии — полноценные базы 1С на кассовых компьютерах магазинов. Магазин может торговать автономно даже при потере связи с центром, обмен идёт по расписанию.
Рис. 1 - Распределенная информационная база
Подход выглядит надёжным, пока сеть невелика. С ростом числа точек продаж он начинает давать сбои: остатки и цены отстают от реальности, аналитика бэк-офиса работает с задержкой, обновления платформы превращаются в многодневные операции. Каждая дополнительная точка — это ещё одно место потенциального сбоя обмена и ещё одна задача для команды поддержки.
Вторая модель — централизованная учётная система с тонкими клиентами или веб-кассами в магазинах. Все данные живут в одной базе, размещённой в дата-центре. Касса видит изменения цены или остатка в момент их внесения, бэк-офис получает аналитику в реальном времени, а ИТ-команда поддерживает один контур, а не «созвездие» локальных серверов.
Преимущества централизованной модели в долгосрочной перспективе перевешивают: быстрый старт, единый источник правды по остаткам, упрощённое масштабирование, безопасность данных и предсказуемая стоимость поддержки. Но у неё есть встроенный риск, который нельзя игнорировать: вся сеть зависит от одного центрального контура и каналов связи. Падение этого контура — это уже не локальный инцидент, а остановка всего бизнеса.
Вывод напрашивается сам: централизация даёт максимальный эффект только тогда, когда сам центр спроектирован с учётом отказа любого его компонента — включая отказ целого дата-центра.
3. Кейс: геораспределенный кластер в двух ЦОД
Именно эту задачу моя команда решала для розничной сети из более чем 20 торговых точек с центральным складом и интернет-магазином. Магазины работают с 8:00 до 23:00, онлайн-канал — круглосуточно, ночью идут служебные обмены между сервисами. Учётный контур построен на 1С:Предприятии в клиент-серверном режиме, к нему подключены Клеверенс и система лояльности. Цель проекта была сформулирована жёстко: исключить простои и обеспечить непрерывную работу касс при актуальных остатках по всей сети.
В основу решения легла идея единого кластера, узлы которого физически разнесены по двум независимым дата-центрам — ЦОД‑1 и ЦОД‑2. Это не «локальный кластер плюс резервная копия», а полноценный географический разнос: отказ одного ЦОД целиком — по питанию, охлаждению, магистральному каналу или из-за физического инцидента — не приводит к остановке учётной системы. Нагрузка автоматически продолжается на узлах второго ЦОД
Состав кластера
- Microsoft SQL Server — кластер с единым виртуальным IP и общей базой данных, синхронизированной между ЦОД. При сбое основного узла запросы автоматически переводятся во второй дата-центр.
- 1С:Предприятие — отказоустойчивый кластер серверов 1С с парой узлов в разных ЦОД.
- Веб-сервер IIS — ферма IIS с балансировкой нагрузки между обоими дата-центрами.
- Терминальные сервисы — терминальные серверы в обоих ЦОД, переключение пользовательских сессий через TS Broker.
- Active Directory — два контроллера домена с распределенными ролями — аутентификация и групповые политики выживают при отказе любого узла.
- Сетевая инфраструктура — кластерные пары маршрутизаторов в каждом ЦОД и дублирующие каналы между дата-центрами.
- Магазины — основной интернет-канал плюс резервный LTE-канал с регламентом действий для персонала торговой точки.
Архитектура целиком собрана на стандартном стеке Microsoft (Windows Server Failover Cluster, AD, IIS, TS Broker) — без сторонних балансировщиков и экзотических компонентов. Это даёт администраторам предсказуемое поведение и снимает вопрос редких компетенций на рынке. Дополняют картину разведённые по приоритетам и окнам ночные обмены, мониторинг всех ролей кластера с алертами и ежедневный backup с регулярной проверкой восстановления.
Рис. 2 - Схема геораспределнного розничного контура 24/7 в двух ЦОД
4. Что изменилось для бизнеса
Ценность подобной архитектуры удобнее всего показывать в цифрах и сравнении «до/после». В таблице ниже — целевые показатели, на которые вышла сеть после внедрения проекта.
| Показатель |
До проекта |
После проекта |
| Доступность критичных сервисов |
≈ 98–99% с заметными простоями |
Целевая 99,9%+ (≤ ~8 ч/год) |
| Время восстановления (RTO) |
Часы, ручной разбор инцидента |
Минуты, автоматический failover |
| Потеря данных (RPO) |
До дня (последний backup) |
Секунды/минуты (общее хранилище и журналы) |
| Связь магазин ↔ центр |
Один канал, риск простоя точки |
Основной канал + LTE-резерв |
| Защита от отказа ЦОД |
Отсутствует — одна площадка |
Геокластер ЦОД‑1 ↔ ЦОД‑2, авто-переключение |
| Актуальность остатков |
С запаздыванием по обменам |
Online по всей сети и складу |
| Трудозатраты на поддержку |
Высокие, много ручных операций |
Снижены за счёт типизации и мониторинга |
За сухими цифрами стоят понятные эффекты для бизнеса. Сеть перестаёт зависеть от единичной точки отказа: плановое обслуживание любого узла можно проводить без остановки магазинов и онлайна. Покупатель видит актуальные цены и остатки в любой момент, программа лояльности отрабатывает корректно, а ночные служебные процессы не мешают онлайн-каналу. Команда ИТ переключается с реактивного режима «чиним, когда упало» на проактивный — сопровождение мониторинга и регулярные учения по переключению.
Итог
Распределённый отказоустойчивый контур в двух ЦОД вместе с резервированием каналов связи на стороне магазинов позволил клиенту перейти от модели «чиним, когда упало» к модели «работает всегда». Это снимает зависимость выручки от ИТ-инцидентов и формирует базу для дальнейшего масштабирования сети — открытия новых магазинов, расширения онлайн-канала и подключения новых сервисов без переделки инфраструктуры.
Для розницы, которая работает в режиме 24/7, это уже не «премиальная опция», а обязательное условие конкурентоспособности. Вопрос не в том, нужен ли геораспределенный контур, а в том, насколько быстро бизнес сможет к нему перейти.
Дмитрий Носов
Руководитель проектов в EFSOL-Источник
|
