Что делать, если сторонний сервис не может быть обновлен из-за отсутствия сервисного окна
Что проверяют
Умеете ли вы работать с ограничением, которое нельзя снять, и знаете ли способы выкатываться без остановки. Заодно проверяют, отличаете ли вы «нет окна простоя» от «нет прав» и «вендор не выпустил версию»: решения у этих случаев разные.
Как отвечать
Сначала уточните, что именно мешает, и предложите обойти простой, а не ждать его. Обновление без остановки собирается из известных приёмов:
- поднять новую версию рядом и переключать трафик постепенно, с готовностью вернуть старую;
- спрятать новое поведение за флагом, чтобы выкатка кода и включение функции были разными событиями;
- менять схему данных расширением: сначала добавить, потом писать в оба места, потом читать из нового, и только затем убрать старое;
- беречь совместимость контракта: новые поля опциональны, старые не исчезают в том же релизе.
Если обновить нельзя вовсе, задача меняется: снизить ущерб от старой версии. Изолируйте её за своим адаптером, опишите узкий интерфейс и держите вызовы в одном модуле. Закройте обращения таймаутом на подключение и на чтение, добавьте повторы с растущей паузой и разбросом, поставьте предохранитель, который перестаёт дёргать умерший сервис. Кэш с коротким временем жизни и отдачей устаревших данных при сбое сохранит работу интерфейса. Отдельно опишите деградацию: что перестаёт работать и что при этом видит пользователь.
И зафиксируйте всё как риск с владельцем и датой пересмотра, иначе временное решение станет постоянным.
Где спотыкаются
Полагаются на умолчания клиента. В популярной библиотеке запросов таймаута по умолчанию нет вовсе, и один зависший внешний вызов выедает все воркеры приложения.
Второе: повторяют любой неудачный запрос. Повторять можно идемпотентное и по понятным кодам ответа, иначе дубли платежей и писем обеспечены, а просьбу сервера подождать надо уважать.
Третье: закрывают симптом кэшем и забывают. Через полгода никто не помнит, почему версия зафиксирована, а обновление становится вдвое дороже.