Поддержка веб-приложений и SaaS
Живые пользователи, растущая база, очереди и миграции. Держим приложение в строю и выкатываем обновления без даунтайма.
Что входит
- Мониторинг ошибок и метрик
- Контроль фоновых задач и очередей
- Миграции схемы без потери данных
- Обновление зависимостей и патчи
- Логи и разбор инцидентов
- Выкладка без даунтайма
- Оптимизация медленных запросов
У сайта посетители, у приложения — пользователи с аккаунтами и данными. Разница принципиальная: сайт при сбое не открывается, приложение при сбое может продолжать работать и при этом молча портить данные. Поэтому поддержка приложения — это не только «доступен ли сервис», но и «правильно ли он себя ведёт».
Приложение к тому же меняется во времени само по себе, без правок кода. База растёт, и запрос, который на тысяче записей отрабатывал мгновенно, на миллионе кладёт сервер. Очередь фоновых задач копится, пока не переполнится. Партнёрский API объявляет старую версию устаревшей. Всё это не аварии, а предсказуемая деградация, которую видно заранее — если за ней смотреть.
Как мы работаем
- Наблюдаемость. Первым делом настраиваем сбор ошибок, метрик и логов. Без этого разбор любого инцидента превращается в гадание по жалобам пользователей.
- Контроль фона. Ставим на мониторинг очереди и планировщик: задача, которая перестала выполняться, обычно не вызывает ошибок — она просто не происходит, и это самое коварное.
- Обновления зависимостей. Регулярно обновляем библиотеки и следим за уязвимостями. В приложении зависимостей на порядок больше, чем в сайте, и половина рисков живёт именно там.
- Миграции схемы. Изменения базы делаем обратимо и на копии сначала. Потерянные данные не восстанавливаются извинениями.
- Выкладка без даунтайма. Настраиваем деплой так, чтобы обновление не выбивало работающих пользователей из сессии посреди действия.
- Работа с производительностью. Отслеживаем медленные запросы и рост времени ответа, чиним до того, как это станет заметно пользователям.
Что вы получаете
Приложение, о проблемах которого известно раньше, чем о них напишут в поддержку. Инциденты разбираются по логам и метрикам, а не по пересказу пользователя. Деградация видна на графике за недели до того, как превратится в аварию.
Если у приложения есть мобильный клиент, у него свой цикл проблем — сторы, сертификаты, версии ОС. Это поддержка мобильных приложений, и её обычно берут вместе с серверной частью. Если нужен только мониторинг без полного сопровождения, посмотрите настройку серверного мониторинга.
Сроки
Подключение — от недели: нужно разобраться в архитектуре, поднять наблюдаемость и понять, где узкие места. Дальше помесячно. Для приложений с платящими пользователями мы обычно рекомендуем круглосуточный тариф: ночная авария в SaaS означает утро с очередью обращений в поддержку и оттоком.
Пример из практики
Допустим, у сервиса есть фоновая задача, которая раз в час рассылает уведомления. Однажды она перестаёт выполняться из-за исчерпания места на диске под логи. Приложение при этом полностью работоспособно: интерфейс открывается, данные сохраняются, ошибок нет. Пользователи просто перестают получать письма и постепенно решают, что сервис их игнорирует. Мониторинг фоновых задач ловит такую тишину в первый же час, потому что следит не за наличием ошибок, а за фактом успешного выполнения.