#РазборСбояBitrix24 #Битрикс24 #IT — 13 апреля 2026 г. в 13:33:17.799
#РазборСбояBitrix24 #Битрикс24 #IT Часть №5. Найти решение - это ещё не решить проблему К утру у нас уже было главное: Мы поняли, где именно ломается связка и нашли рабочую логику обхода. Но это была только половина победы. Проблема затронула не один продукт. И очень быстро стало ясно, что переносить это решение придётся на целую группу сервисов. А они разрабатывались: - Не в один год. - Не под одну и ту же задачу. - Не в одной и той же архитектурной логике. Эталонное решение ≠ быстрое тиражирование На бумаге всё выглядело просто: есть проверенное решение, бери и повторяй. На практике это означало много часов ручной адаптации, проверок и переделок, потому что одно и то же техническое поведение в разных продуктах вшито по-разному. И вот это, наверное, один из самых неприятных моментов любого инцидента. Ты уже понял, в чём проблема. Ты даже уже понял, как её обходить. Но до реального восстановления у всех клиентов ещё огромное расстояние, потому что решение надо не придумать, а довести до всей системы. Попытка ускорить. Смена IP-адреса как потенциальный выход. Параллельно мы продолжали работать с поддержкой и максимально подробно передавали диагностику: - Маршруты. - Тесты. - Сравнение рабочих и нерабочих IP-адресов. - Поведение на разных слоях. В какой-то момент со стороны Дата центра тоже начали склоняться к версии, что проблема похожа на внешнюю фильтрацию или ограничения, на которые они напрямую повлиять не могут. Как вариант нам предложили смену IP-адреса сервера. На этом этапе это выглядело как возможный путь ускорить восстановление. Но дальше ситуация повернулась ещё жёстче. В следующем посте расскажу, как в процессе смены IP-адреса мы на ровном месте получили уже не один, а два проблемных сервера ... Расширенная версия поста: https://dozmi.ru/blog/bitrix24-incident-rollout/ Канал Второй Мозг: Веб-Блог / Телеграм / MAX