Поддержка и техподдержка
сайта в Новосибирске

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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