Модуль 5 · Урок 13 · ~10 минут

Всё ломается: режимы отказа

Одна идея этого урока: сеньор проектирует не «чтобы работало», а «что будет, когда сломается».

Знакомая ситуация

Твой телеграм-бот школы отвечает студентам через LLM. Ночью у провайдера модели сбой – API перестал отвечать. Бот не упал, он «работает»: принимает сообщения и молчит. Утром – десятки жалоб «бот сломался», а ты даже не знал, что что-то не так.

Приложение никто не «ломал». Просто наступил один из его режимов отказа – а сценария на этот случай не было.

Отказ – не исключение, а норма жизни системы. Вопрос не «сломается ли», а «когда сломается – что увидит пользователь?». Сеньор задаёт этот вопрос на этапе проектирования, а не после инцидента.

Четыре типовых режима отказа

Режим отказа (failure mode) – это конкретный способ, которым часть системы перестаёт работать. Для твоих приложений почти все инциденты сводятся к четырём:

1
Сеть оборвалась network failureЗапрос ушёл и не вернулся. Причём неизвестно, выполнился он или нет: деньги могли списаться, хотя ответ не пришёл.
2
Внешний сервис молчит или тормозит dependency failureПлатёжка, LLM, почтовый сервис – не ответил вовсе или ответил через минуту вместо секунды. Медленный ответ часто хуже отказа: всё «висит», очередь копится.
3
Ресурс закончился resource exhaustionДиск забился логами, память кончилась, лимит запросов исчерпан. Система деградирует постепенно и падает «внезапно».
4
Ключ или доступ протух expired credentialsAPI-ключ отозван, токен истёк, сертификат кончился. Всё работало месяцами – и перестало без единой правки кода.

Вопрос сеньора к каждой интеграции в проекте: «что увидит пользователь, когда ЭТО упадёт?». Если ответа нет – ответ уже есть: пользователь увидит молчание или непонятную ошибку.

Три инструмента против отказов

Деградация с достоинством (graceful degradation). Система теряет часть возможностей, но не всё сразу. Бот без LLM отвечает заглушкой: «Я временно туплю, попробуй через 10 минут или напиши в поддержку» – это в сто раз лучше молчания. Лендинг без сервиса аналитики всё равно принимает заявки.

Радиус поражения (blast radius). Насколько далеко разлетаются осколки одного отказа. Если падение рассылки роняет и приём оплат – радиус слишком большой. Части системы с разной важностью нужно изолировать: сбой второстепенного не должен трогать критичное.

Бэкапы, которые восстанавливались. Вопрос сеньора не «есть ли бэкап», а «когда последний раз из него реально восстанавливались?». Непроверенный бэкап – это не бэкап, а надежда. Раз в квартал – тестовое восстановление на копии.

Как думают три уровня

Джун · счастливый путьПроектирует только happy path: «запрос ушёл – ответ пришёл – всё хорошо». Отказы для него – досадные случайности, о которых думают потом. ИИ-агент без указаний пишет так же.
Мидл · ошибки пойманы, сценарии нетОборачивает вызовы обработкой ошибок, «чтобы не падало». Но что именно увидит пользователь и что делать системе дальше – не продумано. Ошибка поймана и... всё.
Сеньор · отказы в постановке задачиЕщё до кода перечисляет режимы отказа каждой интеграции и требует от агента план деградации: что показать пользователю, что записать в лог, что изолировать. Отказ – часть дизайна, а не сюрприз.

Проверь себя

1. Агент показал план новой фичи: «бот отправляет вопрос студента в LLM и возвращает ответ». Что в первую очередь уточнит сеньор?

2. В твоём приложении школы сломался модуль рассылки – и вместе с ним перестала работать оплата курсов. О чём это говорит?

3. Агент отчитался: «Бэкапы базы данных настроены, делаются каждую ночь». Что скажет сеньор?

Что говорить агенту уже сегодня

Источники