Ответ.

В истории развития распределённых IT-систем вопросы обработки ошибок и сценариев отказа долгое время оставались на второстепенных ролях, уступая место бизнес-логике. Однако рост масштабов и усложнение инфраструктуры со временем продемонстрировали, что недоработанные сценарии обработки ошибок приводят к масштабным сбоям и потерям данных.

Проблема заключается в том, что сложные системы испытывают множество типов сбоев: от недоступности отдельных сервисов до неконсистентности данных или частичных отказов каналов связи. Часто заказчики под «отказами» понимают лишь очевидные сбои (например, сервер недоступен), игнорируя цепочки межсервисных ошибок или деградацию пользовательского опыта.

Эффективное решение строится на системном подходе:

Обнаружение всех возможных точек отказа.
Разработка исчерпывающих сценариев их возникновения совместно с архитекторами, QA, проектировщиками и инженерами по эксплуатации.
Согласование поведения системы с бизнесом (например, можно ли откладывать заказы или требуется кэшировать операции).
Чёткая документация всех видов сообщений об ошибках и маршрутов обработки.

Ключевые особенности:

Обработка не только фатальных, но и мягких/плавающих сбоев (например, временная недоступность внешнего сервиса).
Включение сценариев деградации UI и функциональности.
Разграничение бизнес-ошибок и технических сбоев на всех этапах проработки требований.

Вопросы с подвохом.

В чем разница между исключением на уровне приложения и на уровне инфраструктуры?

Очень часто кандидаты путают бизнес-ошибки (например, "пользователь не найден") с реальными сбоями (например, "база данных недоступна"). Приложение всегда должно чётко различать два типа исключений и обеспечивать разные стратегии обработки (откат, уведомления, алертинг).

Какие сценарии отказа нужно моделировать для внутреннего API, если оно не публично?

Сценарии отказа актуальны для любых API: даже если API внутреннее, сбои возможны всегда (даже внутри одного контура автоматизации), и их нужно явно моделировать, чтобы исправно работать с недостоверными/отсутствующими данными.

Должна ли система скрывать все ошибки от пользователя ради максимального UX?

Нет, абсолютное скрытие ошибок приводит к дезинформации пользователя. Важно находить баланс между информативностью (чтобы пользователь понимал, что делать дальше) и безопасностью (не раскрывая детали реализации).

Типовые ошибки и анти-паттерны

Неформализованная обработка отказов (оставленные на "по умолчанию" catch-ы).
Отсутствие сценариев деградации при частичных сбоях (на примере микросервисов — неработающая корзина полностью блокирует оформление заказа).
Игнорирование накопления "молчаливых" сбоев (нет алертинга/мониторинга по исключительным ситуациям).

Пример из жизни

Негативный кейс: В крупном e-commerce проекте системный аналитик оставил обработку всех сетевых ошибок на откуп архитектуре. При аварийных обновлениях и сбое почтового сервиса система не отправляла оповещения о заказах, а пользователи не понимали, созданы ли их заказы.

Плюсы:

Упрощение описания требований.

Минусы:

Потеря данных (невозможно доказать создание заказа).
Расходы на поддержку выросли после запуска продукта.

Положительный кейс: Системный аналитик вместе с архитектором смоделировал отдельные сценарии для каждого критического сервиса: недоступности очереди писем, отвалов платёжных шлюзов, деградации поискового сервиса. Были прописаны user-friendly сообщения для клиентов.