Как масштабировать аварийное решение на 50 продуктов Битрикс24

Найти решение — это ещё не решить проблему

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

Но это была только половина победы.

Проблема затронула не один продукт. И очень быстро стало ясно, что переносить это решение придётся на целую группу сервисов. А они разрабатывались:

• Не в один день.
• Не под одну и ту же задачу.
• Не в одной и той же архитектурной логике.

Эталонное решение ≠ быстрое тиражирование

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

И вот это, наверное, один из самых неприятных моментов любого инцидента.

Ты уже понял, в чём проблема. Ты даже уже понял, как её обходить. Но до реального восстановления у всех клиентов ещё огромное расстояние, потому что решение надо не придумать, а довести до всей системы.

Смена IP-адреса как потенциальный выход

Параллельно мы продолжали работать с поддержкой и максимально подробно передавали диагностику:

• Маршруты.
• Тесты.
• Сравнение рабочих и нерабочих IP-адресов.
• Поведение на разных слоях.

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

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

Но дальше ситуация повернулась ещё жёстче.

В следующем посте расскажу, как в процессе смены IP-адреса мы на ровном месте получили уже не один, а два проблемных сервера.