Ночная диагностика сбоя Битрикс24: частичная деградация IP-адресов пула

Начали с очевидного

Вечером пятницы мы начали разбирать проблему не на уровне ощущений, а на уровне конкретных технических слоёв.

Сначала проверили самое очевидное:

• Авторизация жива.
• Обновление токенов работает.
• Служба выдачи доступа отвечает нормально.

Значит, проблема не в токенах, не в базе и не в том, что приложение «разавторизовалось».

Потом пошли глубже.

Пул из 13 IP-адресов

Мы начали смотреть, как именно идут запросы до облачных порталов Битрикс24, и обнаружили вещь, с которой раньше не сталкивались.

Один и тот же домен вёл на пул из 13 IP-адресов. При этом часть адресов работала штатно, а часть стабильно ломалась.

Это был самый важный поворот всей истории.

На проблемных адресах была доступность по сетевому протоколу. Проходило соединение на 443 порт. Но дальше соединение зависало на уровне установки защищённой связи.

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

Почему сбой был «плавающим»

Именно поэтому ошибка была плавающей:

• Если запрос попадал на рабочий IP-адрес, всё шло нормально.
• Если на проблемный — приложение зависало по таймауту.

Именно ночью нам стало окончательно понятно, что мы ищем не баг в приложении и не обычный сбой платформы. Мы столкнулись с частичной сетевой деградацией, которая маскировалась под случайную нестабильность.

В этот момент стало ясно и другое: просто ждать восстановления бессмысленно. Нужно не только найти причину, но и прямо сейчас придумать, как обойти эту проблему в рабочем режиме.

В следующем посте расскажем, какое аварийное решение нам пришлось собирать уже под утро, чтобы клиенты вообще могли продолжать работать.