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