Что входит в техническую поддержку сайта после запуска

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

Техническая поддержка объединяет такие работы в согласованный процесс. У компании появляется команда, которая знает устройство проекта, принимает обращения и выполняет регулярное обслуживание.

Состав услуги зависит от функций сайта и его роли в бизнесе. Небольшому информационному ресурсу и интернет-магазину с оплатой, личными кабинетами и обменом с 1С потребуется разный объём внимания.

Какие задачи входят в регулярное обслуживание

Мониторинг доступности и важных действий

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

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

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

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

Резервное копирование и восстановление

Для восстановления могут понадобиться файлы сайта, база данных и настройки его окружения. Состав копии нужно определять по конкретному проекту.

Например, в документации WordPress по резервному копированию отдельно рассматриваются файлы и база данных. Там же рекомендуется создавать копию перед обновлением.

Для обслуживания важно договориться:

• Что именно сохраняется.
• Как часто создаются копии.
• Где они хранятся и кому доступны.
• Как долго сохраняются предыдущие версии.
• Кто и как проверяет возможность восстановления.

Частота копирования должна учитывать изменения на сайте. Если за день появляются новые заказы, восстановление старой базы может потребовать отдельной работы с данными, поступившими после создания копии.

Наличие архива следует дополнять проверкой восстановления в отдельном окружении. Так команда сможет заранее обнаружить неполную копию или недостающие настройки.

Обновления и проверка совместимости

Система управления, модули и серверные компоненты меняются. Обновления могут исправлять ошибки, закрывать уязвимости и поддерживать совместимость.

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

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

В порядок работ также стоит включить подготовку резервной копии и действия на случай неудачного обновления.

Как организовать работу при сбое

Приоритет зависит от последствий

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

Категории обращений лучше определить заранее. Тогда сотрудник заказчика сможет правильно сообщить о проблеме, а команда поддержки поймёт её срочность.

При описании сбоя полезны ссылка на страницу, последовательность действий, время возникновения и снимок экрана. Если проблема связана с заказом, номер или другие сведения передают по согласованному каналу.

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

Время реакции и время восстановления

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

Реакцией может считаться подтверждение получения заявки и начало диагностики. Что именно входит в этот этап, нужно согласовать с исполнителем.

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

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

Кто отвечает за сайт и связанные сервисы

В работе проекта могут участвовать разработчик, хостинг, специалист по 1С, сервис оплаты и другие поставщики. Их зоны ответственности нужно связать между собой.

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

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

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

Чем обслуживание отличается от новых функций

Регулярное обслуживание помогает поддерживать согласованную работу сайта. Добавление программы лояльности, нового кабинета или дополнительной интеграции меняет возможности проекта и требует отдельной оценки.

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

В составе услуги следует определить, включены ли:

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

В Sibcode новые задачи и дополнительные работы оцениваются отдельно от технической поддержки. Это позволяет обсуждать их состав и стоимость до начала выполнения.

Гарантийные исправления тоже нужно учитывать отдельно. Их условия связаны с ранее выполненной разработкой и договорённостями по проекту. Подробнее о возникновении и проверке ошибок рассказано в статье Sibcode «Баги — проблемы IT-компании или необходимость?».

Как выбрать формат поддержки

Для сайта с редкими изменениями может подойти обслуживание с определённым набором регулярных проверок и отдельной оплатой дополнительных задач.

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

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

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

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

Что должно быть видно в отчёте команды

Отчёт помогает понять, какие задачи выполнены и в каком состоянии находится сайт. Для этого недостаточно общего перечня действий без результата.

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

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

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

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