Аварийный обход для Битрикс24: как обойти проблемный IP-адрес в рабочем режиме

Правильный диагноз ещё не решает проблему

Когда стало понятно, что проблема не в коде приложения как таковом, а в том, что часть IP-адресов из пула Битрикс24 фактически «битая» для нашего маршрута, ждать уже было нельзя.

Клиентам не становится легче от того, что ты правильно поставил диагноз. Им нужно, чтобы сервис работал.

Что пришлось строить под утро

Поэтому вместо спокойного разбора мы начали собирать аварийное решение. Логика была простой по смыслу, но сложной в реализации:

• Научить систему определять проблемные адреса.
• Не упираться в них.
• Идти дальше через рабочие.

Фактически нам пришлось на ходу делать свою механику проверки и перебора доступных точек входа. То, чего раньше в таком виде у нас не было, потому что раньше сама постановка задачи казалась избыточной.

До ночи это была история про поиск причины. Под утро это уже была история про отказоустойчивость.

После первого контура стало ясно: это только начало

После того как первый рабочий контур получился, на этом всё не закончилось.

Стало понятно, что пользователю нужно не только восстановить работу, но и показать, что вообще происходит. Поэтому следующим шагом мы пошли в сторону:

• Отображения состояния.
• Более понятного поведения приложения в таких сценариях.

Но тут нас ждала следующая проблема.

Одно дело - сделать обход для одного продукта. И совсем другое - быстро перенести это решение на целую группу приложений, которые развивались в разное время и с разной внутренней логикой.

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