Демо работает, прод ломается: три поломки, которых не видно на показе

Демо длится пятнадцать минут. Вы задаете боту три вопроса - он отвечает за секунду. Показываете рассылку отчетов - она уходит вовремя. Все довольны, работу принимают. А через неделю эксплуатации прилетает сообщение: «бот молчит». Не «упал с ошибкой» и не «врет», а именно молчит.

Я собирала Telegram-бота для отельной автоматизации: он отвечает сотрудникам по внутренней базе знаний и рассылает отчеты по расписанию. На демо он работал. В проде сломался тремя разными способами - и ни один из них на демо не воспроизводится в принципе. Не потому, что я плохо показывала, а потому что демо устроено так, что эти поломки внутри него почти невозможны.

Дальше - три класса поломок, механика каждой и то, что стоило написать в коде заранее.

Демо - это лучший случай, прод - это все остальные

У демо обычно совпадают три условия:

• один пользователь (вы) и вопросы по очереди
• свежий процесс (программу запустили минуту назад, еще нечему «накапливаться»)
• удачный день у провайдера (внешний сервис отвечает быстро).

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

Поэтому демо проверяет ровно один сценарий - happy path. А ломается система на всех остальных.

flowchart TB
  U["Запрос пользователя"] --> C["Вызов модели"]
  C --> P{"Провайдер отвечает?"}
  P -->|"да"| OK["Ответ пользователю"]
  P -->|"ошибка"| E["Ошибка видна,<br/>обработана"]
  P -->|"молчит"| W1["Без таймаута:<br/>ожидание не кончается,<br/>бот не отвечает никому"]
  P -->|"молчит"| W2["С таймаутом 60 с:<br/>сдаемся сами,<br/>отвечаем пользователю"]

Поломка №1: вызов без таймаута висит вечно

Таймаут - это ограничение времени ожидания: «жду ответа не дольше N секунд, потом сдаюсь сам». Если его не задать явно, во многих библиотеках ожидание не ограничено ничем.

Именно так у меня и было: запрос к языковой модели уходил без таймаута. На демо это невидимо - ответ приходит за секунды. В проде провайдер иногда не отвечал вовсе, и запрос висел бесконечно.

Деталь, которую новички обычно пропускают: плохо не то, что пользователь не получил ответ. Плохо то, что никто ничего не узнал. Нет ошибки - значит, нет записи в логе, нет сообщения «попробуйте еще раз», нет повторной попытки. Задача просто стоит и держит ресурсы процесса. Снаружи это выглядит как «бот молчит», и по такому описанию причину не выковыряешь.

Лечение простое: явный таймаут на каждый сетевой вызов. У нас - 60 секунд. Число не магическое: это примерно столько, сколько человек готов ждать ответа в чате (у вас может быть другое). Важно, что оно вообще есть: тогда «висит» превращается в «упало с понятной ошибкой», а с ошибкой уже можно работать - логировать, показывать пользователю, ретраить.

Тот же дефект - в скрипте выкладки

Забавно (и неприятно), но он всплыл там, где его не ждешь. Скрипт деплоя после старта сервиса опрашивал его: «ты поднялся?» - и ждал ответа без ограничения. Если сервис не отвечал, висел сам скрипт: выкладка не заканчивалась ни успехом, ни провалом. Добавили лимит: 5 секунд на попытку.

Правило одинаковое и для бота, и для деплоя: сетевой вызов - это не вызов функции. Он может не вернуться никогда.

Поломка №2: тяжелый прогрев блокирует запуск

Прогрев - это подготовка тяжелых частей системы при старте, чтобы потом не платить за нее на каждом запросе. Мой бот при старте поднимал поисковый конвейер: по вопросу сотрудника находил подходящие куски базы знаний и отдавал их модели. Для этого нужно загрузить модель и открыть базу - операция небыстрая, поэтому ее делают один раз.

Ошибка была не в самом прогреве, а в том, где он стоял. Он выполнялся до запуска планировщика (у нас это рассылка отчетов) и до начала обработки сообщений. То есть пока прогрев не закончился, бот не был живым ни в каком смысле: ни ответы, ни расписание.

Пока все хорошо, разницы не видно: прогрев занял полминуты - никто не заметил. Но если прогрев подвисал (а он зависит от диска, памяти и внешних сервисов), бот не отвечал вообще и расписание не работало. Одна медленная операция на старте выключала обе функции сразу.

Лечение: прогрев вынесли в фоновую задачу после старта. Бот принимает сообщения сразу, планировщик стартует сразу, тяжелая часть догружается параллельно.

Да, это добавляет вопрос, на который придется ответить осознанно: что делать с запросом, который пришел до того, как прогрев закончился. Но это честный вопрос с понятным ответом - в отличие от «сервис не запустился, причина неизвестна».

flowchart TB
  subgraph WAS["Прогрев до старта"]
    W1["Старт"] --> W2["Прогрев: модель и база"] --> W3["Завис - расписание<br/>не работает,<br/>бот не отвечает"]
  end
  subgraph NOW["Прогрев в фоне"]
    N1["Старт"] --> N2["Расписание и прием<br/>сообщений"]
    N1 --> N3["Прогрев параллельно"]
    N3 --> N4["Вопрос: что делать<br/>с ранним запросом - <br/>честный и с ответом"]
  end
  WAS ==> NOW

Поломка №3: health check, который сам все роняет

Проверка здоровья - это простой запрос, на который сервис отвечает «я жив». Его регулярно дергает внешняя система (мониторинг, оркестратор, systemd - неважно), и по ответу решает, считать ли сервис работающим.

Мой health check запрашивал статистику базы знаний. Логика казалась здравой: проверить не «процесс существует», а «данные на месте, я действительно готов работать».

Проблема в том, что health check должен отвечать за миллисекунды и не зависеть ни от чего тяжелого. Как только база начинала подвисать, вместе с ней подвисала и проверка. И тут связь становится опасной: инструмент, который должен сообщать о состоянии системы, сам оказывается частью системы и разделяет ее проблемы. Внешняя система видит молчание и делает выводы - а выводы у нее обычно радикальные.

Лечение: проверку свели к дешевому вопросу «файл базы на месте». Никаких обращений внутрь базы, никакой статистики.

Разделение, которое стоит запомнить: health check отвечает на вопрос «меня можно спрашивать?», а не «все ли хорошо с данными». Второй вопрос тоже важен, но это работа мониторинга и метрик, а не ручки, от которой зависит жизнь сервиса.