В прошлой статье я рассказывал, как устроено ядро нашего поиска: триграммы, crc32, словарь болей и два сита. В конце был короткий раздел «А где же нейросеть?», и он заслуживает отдельного разговора. Сегодня про то, как модель встроена сверху и почему мы с самого начала исходили из того, что она когда-нибудь подведёт.
Рубрика «fallback»
Языковая модель в поиске магазина: как подключить её так, чтобы её падение никто не заметил
2026-10-07 в 7:08, admin, рубрики: claude, deepseek, fallback, json, llm, python, reasoning, отказоустойчивость, умный поиск, языковые модели10 Принципов отказоустойчивости (с примерами на Javascript)
2025-06-15 в 18:16, admin, рубрики: error handling, fallback, UX, архитектура, надежность, отказоустойчивость, ошибки, стабильность, устойчивость
Отказоустойчивость (англ. resilience, fault tolerance) — это способность системы продолжать работу, несмотря на внутренние ошибки, сбои в зависимостях или непредвиденные ситуации.
Программист-защитник сильнее энтропии
2019-10-28 в 8:12, admin, рубрики: best practices, fallback, post mortem, безопасность, Блог компании FunCorp, валидация, высокая производительность, кеширование, надежность, оптимизация, прагматизм, практики, практики программирования, Программирование, Проектирование и рефакторинг, процесс разработки, процессы, Разделение привилегий, разделяй и властвуй, разработка, Совершенный код, стабильность
© Dragon Ball. Goku.
Программист-защитник в любой момент и в любом месте кода ожидает появления потенциальных проблем и пишет код таким образом, чтобы заранее от них защититься. А если от проблемы нельзя защититься, то хотя бы сделать так, чтобы её последствия и влияние на пользователей были минимальными.
Вспоминается эффект FlashForward из голливудских блокбастеров, когда главный герой видит грядущую катастрофу и остаётся предельно спокойным, потому что заранее знает, что она произойдёт, и имеет от неё защиту. Идея защитного программирования в том, чтобы защититься от проблем, которые сложно или вовсе невозможно предвидеть. Программист-защитник ожидает появления ошибок в любом месте системы и в любой момент времени, чтобы предотвратить их до того, как они нанесут ущерб. При этом цель не в том, чтобы создать систему, которая никогда не падает, это всё равно невозможно. Цель в том, чтобы создать систему, которая падает изящно в случае любой непредвиденной проблемы.
Давайте разберёмся подробнее, что входит в понятие «падать изящно».
- Падать быстро. В случае непредвиденной ошибки все операции должны завершаться сразу же, особенно если последующие вычисления тяжёлые или могут привести к порче данных.
- Падать аккуратно. Если возникла ошибка, программа должна освободить все ресурсы, снять локи, удалить временные и наполовину записанные файлы, закрыть соединения. Дождаться завершения критических операций, прерывание которых может привести к непредсказуемым результатам. Либо безопасным способом аварийно завершить эти операции.
- Падать явно и красиво. Если что-то сломалось, сообщение об ошибке должно быть простым, лаконичным и содержать важные детали из того контекста системы, где возникла ошибка. Это поможет команде, которая отвечает за систему, максимально быстро разобраться в проблеме и исправить её.
Безболезненный Fallback Cache на Scala
2019-09-05 в 10:30, admin, рубрики: fallback, highload, scala, Блог компании Конференции Олега Бунина (Онтико), высокая производительность, функциональное программированиеВ крупных или микросервисных архитектурах самый важный сервис не всегда самый производительный и бывает не предназначен для хайлоада. Мы говорим о бэкенде. Он работает медленно — теряет время на обработке данных и ожидании ответа между ним и СУБД, и не масштабируется. Даже если само приложение масштабируется легко, это узкое место не масштабируется совсем. Как эту проблему решить и обеспечить высокую производительность? Как обеспечить ответ системы, когда важные источники информации молчат?
Если ваша архитектура полностью соответствует Reactive-манифесту, составные части приложения неограниченно масштабируются с возрастанием нагрузки независимо друг от друга, и выдерживают падение любого узла, — вы знаете ответ. Но если нет, то Олег Нижников (Odomontois) расскажет, как проблему масштабируемости решили в Тинькофф, построив свой безболезненный Fallback Cache на Scala, не переписывая приложение.
Примечание. В статье будет минимум кода на Scala и максимум общих принципов и идей.
Читать полностью »
Graceful degradation. Доклад Яндекс.Такси
2019-02-03 в 8:00, admin, рубрики: fallback, usability, Анализ и проектирование систем, Блог компании Яндекс, Геоинформационные сервисы, деградация, сервисы такси, тыкваСервисы необходимо писать так, чтобы минимальная функциональность сохранялась всегда — даже если откажут критически важные компоненты. Илья Сидоров, руководитель одной из команд продуктовой разработки бэкенда Яндекс.Такси, объяснил в своем докладе, как мы даем пользователю заказать машину, когда отдельные части системы не работают, и по какой логике мы активируем упрощенные версии сервиса.
Важно писать не только сервисы, которые хорошо работают, но и сервисы, которые хорошо ломаются.