Кто отвечает за сайт, когда он не работает: бизнес, разработчик или хостинг-провайдер

Представьте: компания запустила рекламную кампанию с бюджетом 100 000 рублей. Трафик пошёл, объявления набирают клики, но вместо каталога или формы заявки пользователи видят ошибку 500.

Рекламный бюджет продолжает расходоваться. Заявки не поступают. Потенциальные клиенты уходят к конкурентам.

Бизнес пишет разработчику. Разработчик отвечает, что проблема на сервере. Техническая поддержка проверяет оборудование и сообщает, что виртуальный выделенный сервер работает исправно. В результате каждая сторона формально права, но сайт по-прежнему недоступен.

Для бизнеса в этот момент не так важно, где именно произошёл сбой. Важнее понять, кто должен его найти, сколько времени займёт восстановление и как остановить прямые финансовые потери.

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

Поэтому вопрос «кто виноват?» редко помогает восстановить сайт. Гораздо полезнее определить, на каком уровне произошёл сбой и кто управляет этим уровнем.

Почему исправный сервер не гарантирует работу сайта

Для клиента сайт выглядит как единый продукт. Человек переходит по ссылке, открывает каталог, оформляет заказ или отправляет заявку.

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

Но между нажатием на объявление и загрузкой страницы работает целая цепочка:

1. Домен должен направить пользователя на правильный сервер.
2. SSL-сертификат должен подтвердить безопасность соединения.
3. Сервер должен принять запрос.
4. Программная часть сайта должна его обработать.
5. База данных должна вернуть нужную информацию.
6. Внешние сервисы должны корректно передать данные.

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

При этом сам сервер действительно может продолжать работать.

Например:

1. закончился срок регистрации домена;
2. были удалены или изменены DNS-записи;
3. истёк SSL-сертификат;
4. сайт сломался после обновления;
5. база данных перестала отвечать;
6. диск заполнился логами или резервными копиями;
7. внешняя CRM, платёжная система или API недоступны;
8. приложение создаёт слишком высокую нагрузку;
9. сайт не выдерживает резко выросший поток посетителей.

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

Фраза «сервер работает» означает только то, что инфраструктура доступна. Она не подтверждает, что весь сайт работает корректно.

Как быстро понять, где возникла проблема

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

Таблица с основными причинами сбоев сайта и ответственными специалистами: разработчиком, администратором, регистратором и хостинг-провайдером.

Эта таблица не заменяет диагностику, но помогает избежать хаотичной переписки между несколькими подрядчиками.

За что отвечает бизнес

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

Бизнес должен знать:

1. на кого зарегистрирован домен;
2. кому принадлежит аккаунт у хостинг-провайдера;
3. где хранятся административные доступы;
4. кто получает уведомления об оплате и сбоях;
5. кто отвечает за обновление сайта;
6. кто создаёт и проверяет резервные копии;
7. к кому обращаться при аварии;
8. какое время реакции закреплено в договоре.

Техническая проблема становится управленческой, когда ни у кого нет полного доступа и полномочий принять решение.

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

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

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

Зоны ответственности бизнеса разработчика администратора и хостинг-провайдера

За что отвечает разработчик

Разработчик отвечает за программную часть сайта:

1. исходный код;
2. CMS;
3. плагины и модули;
4. шаблоны;
5. формы;
6. интеграции;
7. запросы к базе данных;
8. логику работы личного кабинета, корзины и других функций.

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

К его зоне ответственности обычно относятся:

1. ошибки в коде;
2. несовместимость модулей;
3. неудачные обновления;
4. некорректная работа интеграций;
5. слишком тяжёлые запросы к базе данных;
6. отсутствие оптимизации под реальную нагрузку;
7. ошибки в настройках приложения.

Но здесь есть важное ограничение: разработчик отвечает только за те работы, которые закреплены договором.

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

Фраза «он делал сайт, значит, обязан всё исправить» без договора не работает.

За что отвечает хостинг-провайдер

Хостинг-провайдер предоставляет инфраструктуру, на которой размещён проект. Граница его ответственности зависит от типа услуги.

При виртуальном хостинге провайдер обычно обслуживает:

1. физический сервер;
2. сеть;
3. операционную систему;
4. базовое программное окружение;
5. панель управления.

Клиент при этом отвечает за файлы сайта, настройки CMS, базы данных и установленные модули.

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

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

Хостинг-провайдер должен подключаться, если:

1. недоступно оборудование;
2. произошёл сетевой сбой;
3. виртуальный сервер не запускается;
4. не предоставляются заявленные ресурсы;
5. возникла авария в дата-центре;
6. нарушена работа платформы виртуализации.

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

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

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

Кто отвечает за домен и DNS

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

1. на кого зарегистрирован домен;
2. к какой почте привязан аккаунт;
3. кто получает уведомления о продлении;
4. есть ли доступ у представителя бизнеса;
5. включено ли автоматическое продление;
6. где управляются DNS-записи.

DNS-записи могут находиться у регистратора, хостинг-провайдера или внешнего CDN-сервиса. Ошибка в них способна одновременно отключить сайт, корпоративную почту и отдельные сервисы.

Поэтому доступ только к панели сайта не даёт полного контроля над проектом.

Почему подрядчики перекладывают ответственность

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

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

Каждый вывод может быть технически верным, но общей картины ни у кого нет.

Ситуацию усугубляют обращения в формате «сайт не работает». Для диагностики этого недостаточно.

В сообщении специалисту желательно указать:

1. адрес проблемной страницы;
2. примерное время появления ошибки;
3. скриншот или текст сообщения;
4. работает ли сайт с других устройств;
5. какие изменения выполнялись перед сбоем;
6. открывается ли панель управления;
7. работает ли форма, корзина или личный кабинет;
8. поступают ли заявки в CRM.

Чем точнее зафиксирован симптом, тем быстрее определяется уровень проблемы.

Что делать, когда сайт уже упал

Главная задача бизнеса — не найти виноватого, а остановить потери и организовать диагностику.

Пошаговый план действий бизнеса в первые минуты после падения сайта

1. Зафиксировать проблему

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

2. Остановить платный трафик

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

3. Проверить ключевые функции

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

4. Назначить одного координатора

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

5. Не вносить хаотичные изменения

Одновременное обновление плагинов, перенос DNS и перезапуск сервисов могут усложнить диагностику. Все действия во время аварии должны фиксироваться.

6. После восстановления определить причину

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

Чек-лист для владельца бизнеса: готов ли сайт к аварии

Проверьте, можете ли вы ответить «да» на каждый пункт.

1. Домен зарегистрирован на компанию или её владельца, а не на подрядчика.
2. У бизнеса есть доступ к панели регистратора и хостинга.
3. Доступы хранятся в защищённом месте, а не только в личной переписке.
4. Как минимум два ответственных сотрудника могут получить доступ к инфраструктуре.
5. Назначен специалист, который координирует устранение сбоев.
6. В договоре с подрядчиком указано время реакции.
7. Настроены уведомления о продлении домена, SSL и хостинга.
8. Сайт и сервер проверяются системой мониторинга.
9. Резервные копии хранятся отдельно от основной инфраструктуры.
10. Восстановление из резервной копии хотя бы однажды проверялось на практике.
11. Понятно, кто останавливает рекламу при недоступности сайта.
12. Есть список контактов разработчика, администратора и технической поддержки.

Если на несколько вопросов ответить не получается, проблема уже существует. Просто она пока не привела к аварии.

Чек-лист готовности сайта и бизнеса к техническому сбою

Почему одного резервного копирования недостаточно

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

Необходимо понимать:

1. где хранятся копии;
2. как часто они создаются;
3. не находятся ли они на том же сервере;
4. сколько времени занимает восстановление;
5. кто имеет доступ к архивам;
6. проверялась ли целостность данных.

Кроме того, резервное копирование не заменяет мониторинг.

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

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

Кто всё-таки отвечает за работу сайта

За разные участки отвечают разные исполнители:

1. хостинг-провайдер — за инфраструктуру в рамках выбранной услуги;
2. разработчик — за программную часть и функции сайта;
3. регистратор — за обслуживание домена;
4. системный администратор — за настройки серверного окружения;
5. бизнес — за то, чтобы все участки были связаны в управляемый процесс.

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

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

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

Рекомендация AdminVPS

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