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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Скорее всего отдаётся страница из кеша. Это самая частая причина ложного вывода «правка не доехала». После каждого выката кеш сбрасывается, и только потом проверяется результат. Отдельная тонкость: у части страниц кеша может не быть вовсе, и тогда правка видна сразу — это не доказывает, что кеша нет на остальных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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