blog

Как мы строили систему, которая переживёт вообще всё

Как мы строили систему, которая переживёт 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 работает корректно в любых сценариях;
  • инфраструктура стала масштабируемой.

Главный вывод

Отказоустойчивость — это не про «добавить резервный сервер».
Это про:
  • правильную архитектуру,
  • понимание слабых мест,
  • и готовность к тому, что что-то обязательно сломается.
Особенно:
  • в январе,
  • на проде,
  • и в самый неподходящий момент.
Хорошая новость — если всё сделать правильно,
пользователи об этом даже не узнают.
А это и есть лучший результат!
2026-04-15 09:17 Инфраструктура