Разделите исправления, эксплуатацию и развитие
После запуска возникают разные задачи. Одна связана с ошибкой согласованной функции, другая — с обновлением окружения, третья — с новым пожеланием бизнеса. Если все они называются поддержкой, трудно сравнивать предложения и планировать работу.
В договорённостях стоит отдельно перечислить исправления ошибок, регулярные технические работы и развитие. Новая интеграция или переработка каталога обычно требует отдельной оценки, даже если команда уже обслуживает сайт.
Также обозначьте границы ответственности: кто отвечает за домен, сервер, почту, внешние сервисы, содержание и аналитику. Контакт подрядчика не заменяет владельца процесса со стороны компании.
Следите за пользовательскими сценариями
Ответ сервера подтверждает доступность приложения, но не доказывает, что клиент может отправить заявку. Формы, вход в кабинет, оформление заказа и получение уведомлений требуют отдельных проверок.
Выберите несколько важных сценариев и договоритесь, как часто их проверять. Для сайта услуг это может быть отправка тестового обращения и его получение менеджером. Для магазина — прохождение согласованного тестового заказа без реального списания.
Для каждого сигнала нужен получатель. Если уведомления о сбое уходят в ящик, который никто не читает, мониторинг не помогает восстановить работу. Проверьте контакты, резервный канал связи и порядок эскалации.
Проверяйте восстановление из резервной копии
Резервирование должно охватывать данные, без которых проект нельзя восстановить: базу, загруженные файлы и необходимые настройки. Конкретный способ зависит от устройства системы. Например, документация PostgreSQL описывает несколько подходов к резервному копированию базы; копия каталога сайта не является их универсальной заменой.
Сам факт появления архива ещё не показывает, что данные можно вернуть. Для проверки полезно восстановить копию в отдельной среде и пройти основные сценарии. При этом рабочая база не должна использоваться как место для учебного восстановления.
Обсудите допустимую потерю последних изменений и ожидаемое время восстановления. Это разные ограничения. От них зависят частота копирования, срок хранения и подготовка резервного окружения.
Планируйте обновления и возможность возврата
Обновление приложения, библиотеки или сервера может влиять на формы, изображения и внешние подключения. Поэтому в поддержку стоит включить проверку до публикации и короткую проверку после неё.
До изменения важно понимать, как вернуться к рабочей версии. Для кода это может быть предыдущий образ приложения, для данных — отдельный план совместимости и восстановления. Возврат старого кода не всегда отменяет изменения базы.
Периодичность работ и срочность определяются состоянием проекта. Не все обновления одинаково критичны; приоритет стоит обсуждать по влиянию на безопасность, доступность и пользовательские сценарии.
Зафиксируйте порядок реакции на обращение
Время ответа и время исправления — не одно и то же. Первое означает, когда команда начнёт разбирать проблему, второе зависит от причины и доступности внешних систем.
Уточните часы поддержки, канал регистрации задач и критерии срочности. Неработающая оплата и просьба заменить изображение требуют разной реакции. Для серьёзного сбоя полезно заранее определить, кто согласует временное отключение функции.
Регулярный отчёт может быть коротким: выполненные работы, результаты проверок, обнаруженные проблемы и следующие действия. Его задача — показать состояние проекта и решения, которые нужны от владельца.
Что передать команде поддержки
Перед началом работы подготовьте:
- список доменов, окружений и внешних сервисов;
- ответственных за содержание и технические вопросы;
- перечень основных пользовательских сценариев;
- описание текущего резервирования и последнего восстановления;
- порядок выпуска обновлений и возврата версии;
- согласованные часы связи и приоритеты обращений.
Условия обслуживания зависят от системы и состава работ. Их можно обсудить в разделе поддержки сайтов или описать задачу команде DDRW.