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