Бот перестал отвечать ночью: чек-лист перед перезапуском

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

В доступном исходном материале недостаточно сведений, чтобы достоверно назвать причину остановки конкретного бота, описать проверенные шаги восстановления или предложить точную настройку автоматического перезапуска. Ниже приведён универсальный порядок анализа, который помогает собрать недостающие данные и не подменять их предположениями.

Что известно, а чего пока нельзя утверждать

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

Из этого следуют важные ограничения:

• нельзя выбирать одну причину остановки как установленный факт;
• нельзя выдавать команду или фрагмент конфигурации за проверенный способ восстановления;
• нельзя утверждать, что автоматический перезапуск уже настроен или гарантированно решит проблему;
• нельзя считать отсутствие ответа равным завершению процесса без проверки самого процесса и среды выполнения.

В рабочем отчёте полезно разделять три уровня уверенности. Факт подтверждается журналом, метрикой или воспроизводимой проверкой. Гипотеза объясняет наблюдаемое поведение, но ещё требует проверки. Предложение описывает дальнейшее действие и не является доказательством причины. Такое разделение позволяет обновить выводы после получения новых журналов, не переписывая весь отчёт.

Какие сведения нужны для диагностики

Сначала следует восстановить временную шкалу. Нужны момент последнего успешного действия, время первого сбоя, момент обнаружения проблемы и время попытки восстановления. Если бот работает по расписанию или реагирует на входящие события, важно указать, какие именно события перестали обрабатываться: все, только один тип запросов или только обращения к отдельной функции.

Затем собираются данные из нескольких независимых источников:

• журнал самого приложения за период до и после остановки;
• сообщения среды запуска и системные события;
• код завершения процесса или причина его принудительного завершения;
• состояние процесса, контейнера, службы или задания;
• изменения в коде, зависимостях, секретах и конфигурации перед инцидентом;
• доступность сети, базы данных, очереди, API и других внешних компонентов;
• показатели памяти, процессора, диска и лимитов;
• результаты проверок готовности и фактической обработки тестового события;
• сведения о повторных запусках, задержках и дублировании задач.

Журналы нужно сохранять до перезапуска, если это возможно. Перезапуск может удалить диагностический контекст, изменить код завершения или скрыть кратковременную ошибку. Время в разных источниках следует привести к одной временной зоне, иначе события могут оказаться в неверном порядке.

Проверить подходящий вариант можно на странице Beget.

Особенно важны точные формулировки ошибок. Сообщение о тайм-ауте внешнего API не доказывает падение бота. Запись о завершении процесса не доказывает неисправность приложения: процесс мог быть остановлен оператором, системой или планировщиком. Отсутствие новых записей также неоднозначно: журнал мог перестать доставляться, а процесс мог продолжать работу без событий.

Безопасный порядок восстановления

Восстановление должно начинаться с оценки масштаба. Нужно определить, затронут ли один экземпляр или все экземпляры, потеряны ли входящие события, изменилось ли состояние данных и продолжается ли обработка хотя бы части запросов. Если бот взаимодействует с пользователями, стоит временно обозначить недоступность функции и не обещать исправление причины, которая ещё не подтверждена.

До ручного запуска следует зафиксировать:

1. текущее состояние процесса или задания;
2. последние доступные журналы;
3. конфигурацию и версию, с которой произошёл сбой;
4. очередь необработанных событий;
5. результат последнего успешного запроса к каждой критичной зависимости;
6. наличие незавершённых или повторно отправленных операций.

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

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

Перед настройкой откройте Beget и сверьте актуальные условия.

Все действия во время восстановления записываются с временем, исполнителем и результатом. Это позволяет отличить действие, которое лишь вернуло доступность, от действия, которое действительно устранило причину. Если после запуска проблема исчезла без объяснения, инцидент всё равно нельзя закрывать как расследованный: это будет временное восстановление с неизвестной причиной.

Как проверять возможные причины остановки

До получения доказательств разумно рассматривать несколько классов причин.

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

Для каждого вывода следует указывать основание. Формулировка «бот остановился из-за нехватки памяти» допустима только при наличии соответствующего события или метрики. Если есть лишь косвенное совпадение времени, корректнее написать: «нехватка памяти рассматривается как гипотеза; подтверждающие данные не собраны». Такой отчёт полезнее категоричного, но недоказанного объяснения.

Автоматический перезапуск: принципиальная схема, а не готовая настройка

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

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

Независимо от конкретной платформы полезны следующие элементы:

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

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

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

Как оформить проверяемый отчёт

Итоговый документ лучше строить так, чтобы другой специалист мог повторить проверку. В начале указываются идентификатор инцидента, затронутая функция, период времени и среда запуска. Далее фиксируются наблюдаемые симптомы без интерпретации: что именно перестало работать, какие события не обработаны и какие пользователи или интеграции затронуты.

Затем приводятся:

• временная шкала с часовым поясом;
• выдержки из журналов с указанием источника;
• версия приложения и конфигурации;
• состояние процесса до и после восстановления;
• проверенные зависимости;
• предпринятые действия и их результат;
• подтверждённая причина, если она установлена;
• оставшиеся гипотезы;
• риски повторения;
• план наблюдения и ответственный за него.

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

Такой формат сохраняет границу между тем, что действительно известно, и тем, что ещё предстоит проверить. Он также позволяет отдельно улучшать наблюдаемость: добавить корреляционные идентификаторы, увеличить срок хранения журналов, настроить уведомления о повторных сбоях и регулярно проверять сценарий восстановления. Эти меры полезны даже тогда, когда конкретная причина остановки ещё не определена.

Что почитать дальше

• VPS — это место запуска, а не единственная копия: как не потерять код и данные
• Какие ресурсы нужны боту и почему их пока нельзя оценить
• Какие данные сохранить после запуска сайта: карточка проекта
• 3 способа обновить бота без потери сообщений и долгого простоя
• Beget.API: что можно утверждать о переносе приложений

Обложка вдохновлена гравюрой Джованни Баттисты Пиранези «Темницы, лист XIV» (1761). Посмотреть оригинал в коллекции Метрополитен-музея.