Что делать если сторонний сервис работает нормально, но у нас падают запросы
Что проверяют
Умеете ли доказывать, на чьей стороне проблема, вместо спора по переписке. И знаете ли, что при исправном партнёре ломается чаще всего наша собственная обвязка вызова.
Как отвечать
Начать с фактов: какая именно ошибка и на каком этапе. Таймаут соединения, таймаут чтения, разрыв соединения, 429, пятисотка от партнёра, ошибка рукопожатия TLS и сбой разбора ответа лечатся совершенно по-разному, и смешивать их в одну «падают запросы» нельзя.
Что смотреть у себя:
- пул HTTP-клиента исчерпан: запросы стоят в очереди за свободным соединением, а выглядит это как медленный партнёр. Нужны метрики пула;
- таймауты: на подключение, на чтение и общий должны быть заданы явно. Клиент без таймаута удерживает поток до бесконечности и выедает пул потоков приложения;
- протухшие keep-alive соединения: партнёр или промежуточный прокси закрывает их раньше нас, отсюда редкие разрывы на первом запросе;
- DNS и балансировка: часть адресов отвечает, часть нет, ошибки идут процентами от общего числа;
- сертификаты: срок действия и цепочка доверия в хранилище приложения;
- собственные повторы: на всплеске они умножают нагрузку и получают ограничение уже заслуженно.
Лечение: повторы только для идемпотентных вызовов, с экспоненциальной задержкой и джиттером; предохранитель, чтобы не добивать шатающегося партнёра; отдельный пул потоков под интеграцию, чтобы она не съела весь сервис; сквозной идентификатор запроса в логах, чтобы сверяться с партнёром по конкретным вызовам.
Где спотыкаются
Принимают ответ «у нас всё зелено» как закрытие вопроса. Дашборд партнёра усреднён по всем клиентам, нужен разбор конкретных запросов по времени и идентификатору.
Включают агрессивные повторы первым лекарством. Повтор без ограничения числа попыток превращает частичный сбой в лавину и роняет партнёра окончательно.
Предлагают кэширование как решение. Оно снижает число обращений, но не объясняет, почему падают оставшиеся, и к записи не применимо вовсе.