Сервис имеет зависимость от стороннего SaaS-провайдера, у которого за последний год было три крупных отказа по несколько часов, вне контроля компании. Как спроектировать устойчивость к этому риску на уровне архитектуры и процессов?

Короткий ответ

Единственного правильного решения нет: варианты — graceful degradation без полного fallback-провайдера (принять ограниченную функциональность при отказе), многопровайдерная архитектура с переключением (дороже и сложнее, не всегда технически возможна для конкретного типа SaaS), или принятие риска с чётким SLA-договором и компенсациями — выбор зависит от критичности функции для бизнеса, технической возможности абстрагировать провайдера и стоимости резервирования.

Как это работает подробнее

зависимость от внешнего SaaS вне контроля компании нельзя устранить "починкой кода" — провайдер не даёт SLA с нужной надёжностью, либо даёт SLA, но компенсация (кредит на следующий счёт) не покрывает реальные бизнес-потери от простоя; поэтому решение всегда компромиссное между стоимостью резервирования (дублирующий провайдер, сложная абстракция) и принятием остаточного риска.

Компромисс: нужно явно оценить (а) частоту и длительность исторических отказов провайдера и их бизнес-влияние (сколько денег/репутации стоил каждый отказ), (б) стоимость и сложность внедрения резервного провайдера или глубокого graceful degradation, (в) альтернативные договорные механизмы (более строгий SLA, штрафы, выделенная поддержка) — и обсудить с бизнесом, какой уровень инвестиций оправдан для снижения риска, который полностью не устраним.

Пример / кейс

Ожидаемое поведение: команда должна представить оба варианта с оценкой стоимости, остаточного риска (включая риски безопасности варианта B) и обсудить с бизнесом и security-командой, какой уровень компромисса между доступностью и безопасностью приемлем, а не выбирать один вариант без этого обсуждения.

Пример кода

example.txtКопировать

Провайдер: сервис отправки SMS для двухфакторной аутентификации.
История: 3 отказа по 2-4 часа за год, блокирующих логин части пользователей.
Вариант А: добавить второго SMS-провайдера с автоматическим переключением при ошибках
(доп. интеграция + доп. ежемесячная стоимость за поддержание двух контрактов).
Вариант B: graceful degradation — при отказе SMS-провайдера временно разрешить вход
по резервному коду/email без второго фактора, с усиленным логированием для аудита рисков безопасности.

Что использовать на практике

• Практический подход. Для некритичной функциональности (например, виджет чата поддержки) разумно просто добавить graceful degradation — скрыть виджет при недоступности, не блокируя основной сценарий. Для критичной функциональности (например, обработка платежей через единственного провайдера) стоит оценить техническую возможность добавить второго провайдера с абстракцией на уровне своего кода (адаптер/интерфейс), переключаясь между ними при отказе — но это требует поддержки интеграции с двумя API, двойного тестирования и может быть экономически неоправданно, если провайдер предоставляет уникальную функциональность без аналогов.

Подводные камни

• Частые ошибки. Считать, что раз зависимость "внешняя", то и ответственность за риск полностью на провайдере, не предпринимая никаких архитектурных мер со своей стороны; пытаться добавить резервного провайдера без учёта различий в API/поведении/данных между провайдерами, что создаёт собственные баги при переключении; не включать сторонние SaaS-зависимости в общую карту SPOF и DR-планирование компании, рассматривая их как "не наша проблема".