Добавить в корзинуПозвонить
Найти в Дзене
Джаст ИТ

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

Есть проекты, где всё спокойно: планирование, реализация, релиз.
А есть такие, где ты с первого дня понимаешь:
«Если это упадёт — остановится не только система, но и реальный бизнес-процесс.» Это был как раз второй вариант. У клиента была система с примерно 800 терминалами, которые передают данные в центральное приложение. И всё бы ничего… если бы не одна маленькая деталь:
вся эта история держалась на одном сервере. Что это означало: А «всё стоит» — это не про IT. Это про реальные процессы, которые должны идти без пауз. Нам нужно было: Звучит как стандартная задача DevOps.
Но есть нюанс: делать это нужно было без тестового контура и без права на ошибку. Конечно, проект длился уже несколько месяцев, но январь внёс дополнительные «корректировки». А именно январь — это: Поэтому мы сразу отказались от «давайте быстро всё переделаем»
и пошли через аккуратную, поэтапную модернизацию. Мы сделали архитектуру, где: Теперь система могла пережить: И даже не заметить этого. Потому что без этого
Оглавление

Есть проекты, где всё спокойно: планирование, реализация, релиз.
А есть такие, где ты с первого дня понимаешь:
«Если это упадёт — остановится не только система, но и реальный бизнес-процесс.»

Это был как раз второй вариант.

Исходная ситуация: один сервер, 800 терминалов и немного нервов

У клиента была система с примерно 800 терминалами, которые передают данные в центральное приложение.

И всё бы ничего… если бы не одна маленькая деталь:
вся эта история держалась 
на одном сервере.

Что это означало:

  • сервер обновляется → всё стоит;
  • сервер падает → всё стоит;
  • сеть чихнула → всё стоит.

А «всё стоит» — это не про IT. Это про реальные процессы, которые должны идти без пауз.

Задача: сделать так, чтобы не падало. Вообще

Нам нужно было:

  • разнести систему по двум дата-центрам;
  • сделать автоматическое переключение между ними;
  • сохранить безопасность и шифрование;
  • и при этом не сломать текущую работу.

Звучит как стандартная задача DevOps.
Но есть нюанс: 
делать это нужно было без тестового контура и без права на ошибку.

Потом случился январь

Конечно, проект длился уже несколько месяцев, но январь внёс дополнительные «корректировки».

А именно январь — это:

  • часть команды в отпуске;
  • нагрузка скачет (то пусто, то резко много);
  • любые изменения — как игра в сапёра.

Поэтому мы сразу отказались от «давайте быстро всё переделаем»
и пошли через аккуратную, поэтапную модернизацию.

Что построили

Мы сделали архитектуру, где:

  • есть два независимых дата-центра;
  • трафик распределяется через DNS (GSLB);
  • внутри — балансировка через HAProxy;
  • Redis работает как распределённый кластер;
  • всё это связано защищёнными каналами.

Теперь система могла пережить:

  • падение сервера,
  • падение целого ЦОД,
  • проблемы у провайдера.

И даже не заметить этого.

А теперь самое интересное — что пошло не так

Потому что без этого ни один нормальный проект не обходится 🙂

Осложнение №1: Redis, который «почти» отказоустойчивый

На бумаге Redis Sentinel должен автоматически переключать мастер-узел.
На практике — 
вёл себя непредсказуемо при частичных сбоях.

Сценарий:

  • основной узел вроде есть;
  • сеть вроде работает;
  • но приложение продолжает ходить «не туда».

Причина оказалась неожиданной:
подключение к Redis шло через localhost.

Решение:

  • убрали прямое подключение;
  • поставили HAProxy как единую точку входа;
  • теперь приложение всегда ходит к актуальному мастеру.

Redis перестал «думать самостоятельно» — и стал работать стабильно.

Осложнение №2: VPN, который работает… пока не перестаёт

VPN между дата-центрами был настроен с ГОСТ-шифрованием.

И всё выглядело нормально, пока:

  • туннель не начинал «залипать»;
  • трафик переставал проходить, хотя соединение формально есть.

Это один из самых неприятных типов проблем:
когда всё выглядит живым, но по факту — нет.

Что сделали:

  • нашли узкое место в реализации шифрования;
  • сменили тип VPN между площадками;
  • усилили безопасность на других уровнях.

После этого:

  • каналы стали стабильными;
  • Redis перестал «нервничать»;
  • система наконец задышала ровно.

Осложнение №3: нет тестового контура. Вообще

Любые изменения — сразу в прод.

Да, именно так 🙂

Что это значит:

  • нельзя «попробовать»;
  • нельзя «ну давайте откатим, если что»;
  • каждое действие должно быть просчитано.

Как справились:

  • разбили всё на микрошаги;
  • готовили сценарии отката заранее;
  • мониторили систему в режиме «не моргать».

В итоге все изменения прошли:

  • без простоев,
  • без аварий,
  • и практически незаметно для пользователей.

Что получилось в итоге

  • система выдерживает отказ любого компонента;
  • 800 терминалов продолжают работать даже при падении ЦОД;
  • переключение происходит автоматически и незаметно;
  • Redis работает корректно в любых сценариях;
  • инфраструктура стала масштабируемой.

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

Отказоустойчивость — это не про «добавить резервный сервер».

Это про:

  • правильную архитектуру,
  • понимание слабых мест,
  • и готовность к тому, что что-то обязательно сломается.

Особенно:

  • в январе,
  • на проде,
  • и в самый неподходящий момент.

Хорошая новость — если всё сделать правильно,
пользователи об этом даже не узнают.

А это и есть лучший результат!