Как мы строили систему, которая переживёт 10ю мировую
Как мы строили систему, которая переживёт вообще всё
Есть проекты, где всё спокойно: планирование, реализация, релиз.
А есть такие, где ты с первого дня понимаешь:
«Если это упадёт — остановится не только система, но и реальный бизнес-процесс.»
Это был как раз второй вариант.
Исходная ситуация: один сервер, 800 терминалов и немного нервов
У клиента была система с примерно 800 терминалами, которые передают данные в центральное приложение.
И всё бы ничего… если бы не одна маленькая деталь:
вся эта история держалась на одном сервере.
Что это означало:
- сервер обновляется → всё стоит;
- сервер падает → всё стоит;
- сеть чихнула → всё стоит.
А «всё стоит» — это не про IT. Это про реальные процессы, которые должны идти без пауз.
Задача: сделать так, чтобы не падало. Вообще
Нам нужно было:
- разнести систему по двум дата-центрам;
- сделать автоматическое переключение между ними;
- сохранить безопасность и шифрование;
- и при этом не сломать текущую работу.
Звучит как стандартная задача DevOps.
Но есть нюанс: делать это нужно было без тестового контура и без права на ошибку.
Потом случился январь
Конечно, проект длился уже несколько месяцев, но январь внёс дополнительные «корректировки».
А именно январь — это:
- часть команды в отпуске;
- нагрузка скачет (то пусто, то резко много);
- любые изменения — как игра в сапёра.
Поэтому мы сразу отказались от «давайте быстро всё переделаем»
и пошли через аккуратную, поэтапную модернизацию.
Что построили
Мы сделали архитектуру, где:
- есть два независимых дата-центра;
- трафик распределяется через DNS (GSLB);
- внутри — балансировка через HAProxy;
- Redis работает как распределённый кластер;
- всё это связано защищёнными каналами.
Теперь система могла пережить:
- падение сервера,
- падение целого ЦОД,
- проблемы у провайдера.
И даже не заметить этого.
А теперь самое интересное — что пошло не так
Потому что без этого ни один нормальный проект не обходится
Осложнение №1: Redis, который «почти» отказоустойчивый
На бумаге Redis Sentinel должен автоматически переключать мастер-узел.
На практике — вёл себя непредсказуемо при частичных сбоях.
Сценарий:
- основной узел вроде есть;
- сеть вроде работает;
- но приложение продолжает ходить «не туда».
Причина оказалась неожиданной:
подключение к Redis шло через localhost.
Решение:
- убрали прямое подключение;
- поставили HAProxy как единую точку входа;
- теперь приложение всегда ходит к актуальному мастеру.
Redis перестал «думать самостоятельно» — и стал работать стабильно.
Осложнение №2: VPN, который работает… пока не перестаёт
VPN между дата-центрами был настроен с ГОСТ-шифрованием.
И всё выглядело нормально, пока:
- туннель не начинал «залипать»;
- трафик переставал проходить, хотя соединение формально есть.
Это один из самых неприятных типов проблем:
когда всё выглядит живым, но по факту — нет.
Что сделали:
- нашли узкое место в реализации шифрования;
- сменили тип VPN между площадками;
- усилили безопасность на других уровнях.
После этого:
- каналы стали стабильными;
- Redis перестал «нервничать»;
- система наконец задышала ровно.
Осложнение №3: нет тестового контура. Вообще
Любые изменения — сразу в прод.
Да, именно так
Что это значит:
- нельзя «попробовать»;
- нельзя «ну давайте откатим, если что»;
- каждое действие должно быть просчитано.
Как справились:
- разбили всё на микрошаги;
- готовили сценарии отката заранее;
- мониторили систему в режиме «не моргать».
В итоге все изменения прошли:
- без простоев,
- без аварий,
- и практически незаметно для пользователей.
Что получилось в итоге
- система выдерживает отказ любого компонента;
- 800 терминалов продолжают работать даже при падении ЦОД;
- переключение происходит автоматически и незаметно;
- Redis работает корректно в любых сценариях;
- инфраструктура стала масштабируемой.
Главный вывод
Отказоустойчивость — это не про «добавить резервный сервер».
Это про:
- правильную архитектуру,
- понимание слабых мест,
- и готовность к тому, что что-то обязательно сломается.
Особенно:
- в январе,
- на проде,
- и в самый неподходящий момент.
Хорошая новость — если всё сделать правильно,
пользователи об этом даже не узнают.
А это и есть лучший результат!