Техническая поддержка сайтов

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

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

Поддержка как управляемый процесс

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

Кому подходит техническое сопровождение

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

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

Перед началом поддержки

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

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

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

Мониторинг доступности и критичных функций

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

Диагностика и устранение ошибок

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

Безопасные обновления

Обновления CMS, модулей и окружения оцениваются по риску. Для значимых изменений используется тестовая копия, резервная точка и перечень сценариев повторной проверки. Автоматическое обновление без контроля не заменяет сопровождение.

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

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

Релизы и контроль изменений

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

Производительность и инфраструктура

Разбираем причины медленной работы на уровне приложения, базы данных, кеширования, фоновых задач и сервера. Если инфраструктура находится у другого подрядчика, готовим технические данные и участвуем в совместной диагностике в рамках согласованной зоны ответственности.

Технические задачи SEO

Исправляем проблемы индексации, шаблонов метаданных, canonical, sitemap, редиректов, микроразметки и внутренней перелинковки по согласованным требованиям. Семантика, контент и стратегия относятся к отдельной работе по SEO-продвижению.

Плановые доработки

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

Как устроен SLA

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

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

Зона ответственности

У сайта обычно несколько владельцев технических зон: разработчик, хостинг, администратор домена, интегратор 1С, CRM, платёжный сервис и сотрудники заказчика. Без разграничения любой инцидент превращается в передачу проблемы между подрядчиками.

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

Как обрабатываются задачи

1. Регистрация. Обращение попадает в согласованный канал и получает описание, автора и приоритет.
2. Уточнение. Проверяем воспроизведение, влияние, окружение и необходимые доступы.
3. Оценка. Для плановой задачи согласуем состав результата и трудоёмкость; критичный инцидент сразу идёт в диагностику по регламенту.
4. Реализация. Изменение выполняется с учётом риска, резервной точки и необходимости тестового окружения.
5. Проверка. Контролируем исправленный сценарий и связанные функции.
6. Релиз. Фиксируем, что изменилось, когда и кем выпущено.
7. Закрытие. Сохраняем результат, комментарии и последующие профилактические задачи.

Отчётность и план развития

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

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

Безопасность сопровождения

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

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

Поддерживаемые проекты

Основные направления — WordPress и 1С-Битрикс, PHP-проекты, корпоративные сайты и интернет-магазины с внешними интеграциями. Возможность принять конкретный сайт зависит не только от названия CMS, но и от версии платформы, качества кода, доступности документации и состояния инфраструктуры.

Для сложных задач на 1С-Битрикс также смотрите направление разработки модулей и доработок.

Частые вопросы

Можно ли принять сайт, который разработала другая команда?

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

Вы работаете круглосуточно?

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

Гарантирует ли SLA срок полного исправления?

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

Входят ли новые функции в поддержку?

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

Можно ли начать с аварийного восстановления?

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

Кто оплачивает хостинг, лицензии и сторонние сервисы?

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

Как рассчитывается стоимость?

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