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

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

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

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

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

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

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

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

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

Дежурство означает, что на сигнал наблюдения кто-то отвечает, а не что команда сидит за столом всю ночь. Уведомление уходит дежурному, тот подтверждает приём и начинает разбор; если он не ответил за оговорённое время, сигнал повышается и уходит следующему. Объём ночных работ ограничен: восстановление работоспособности, откат последнего изменения, переключение на резерв. Всё, что можно отложить до утра, до утра и откладывается — ночные правки чаще ломают, чем чинят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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