Поддержка и сопровождение
сайта в Краснодаре

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

Цена зависит от объема задач, срочности и типа сайта. Мы предлагаем гибкие тарифы: от разовой до ежемесячной поддержки. Можно подобрать оптимальный формат сопровождения под ваш бюджет.

Работаем с корпоративными сайтами, интернет-магазинами, лендингами, Bitrix, WordPress, OpenCart и другими CMS. Также берем в поддержку custom-разработку.

Да. Даже если сайт стабилен, его нужно регулярно проверять, обновлять и защищать от сбоев. Техническая поддержка — это как техосмотр: лучше заранее, чем после поломки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, объём часов меняется по месяцам. В пик берём больше и добавляем дежурство, в межсезонье возвращаемся к базовому режиму.

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