Клиент: производственная компания.
Проблема: Полная остановка работы сайта из-за аварии на внутреннем сервере.
Решение: Разделение зон ответственности и миграция на специализированный хостинг.
Предыстория: иллюзия полного контроля
Один из наших клиентов долгое время придерживался политики «всё своё ношу с собой». Сайт компании был размещен не в дата-центре, а на внутреннем сервере в офисе, в одной стойке с почтовым сервисом и базами 1С.
На первый взгляд, логика была железной:
- Экономия: не нужно платить за хостинг.
- Безопасность: данные физически находятся в офисе.
- Удобство: системный администратор всегда рядом, «за стенкой».
Однако такая архитектура имела критическую уязвимость, которая сработала в самый неподходящий момент.
Инцидент: когда «упало» всё
В один из дней на внутреннем сервере произошел серьезный технический сбой. Из-за физической поломки оборудования вышла из строя вся ИТ-инфраструктура компании. Последствия были катастрофическими:
- Сайт перестал открываться. Клиенты не могли оставить заявки, зайти в личный кабинет, а запущенная рекламная кампания начала сливать бюджет в пустоту.
- Резервные копии оказались недоступны. Бэкапы хранились на том же сервере, что и сам сайт. Когда «полетело» железо, восстанавливать данные стало не из чего.
- Паралич ИТ-отдела. Системный администратор был занят восстановлением почты и рабочих баз, и сайт в списке приоритетов оказался далеко не на первом месте.
То, что казалось «полным контролем», на деле обернулось отсутствием плана аварийного восстановления (Disaster Recovery).
Анализ ошибок: почему внутренний сервер — это риск?
Разбирая ситуацию, мы выделили несколько причины, по которым сайт на внутреннем сервере компании — это плохая идея для бизнеса:
- Конфликт задач. Внутренний сервер заточен под работу сотрудников (почта, файлы, 1С). Сайту же нужна другая среда, оптимизированная под внешние запросы и высокую скорость отдачи контента.
- Единая точка отказа. Если веб-сервер «падает», компания теряет и внутренние сервисы, и внешнее представительство в сети.
- Единое хранилище данных и копий. Резервные копии хранились на том же сервере, что и основной сайт, — при сбое пострадали все данные.
- Недостаточная квалификация персонала. Штатные IT‑специалисты больше фокусировались на поддержке внутренних систем, а не на веб‑инфраструктуре.
- Отсутствие чёткого графика резервного копирования. Бэкапы делались нерегулярно, без проверки их целостности.
Решение: разделяй и властвуй
После того как нам удалось восстановить сайт в рамках работ по технической поддержке сайта из фрагментарных копий, мы предложили клиенту изменить подход и разделили зоны ответственности:
- Сайт переехал на специализированную хостинг-площадку. Теперь за его доступность отвечает дата-центр с уровнем надежности 99.9%, независимым питанием и скоростными каналами связи.
- Настройка автоматических бэкапов. Копии сайта теперь создаются ежедневно и хранятся в облаке, полностью изолированном от офисного сервера.
- Внутренние ресурсы остались внутри. Почта и локальные сервисы по-прежнему администрируются внутренним специалистом, но больше не влияют на работу сайта.
Результат
Сайт перестал зависеть от того, есть ли в офисе свет и исправен ли сервер в серверной. Даже если в офисе компании произойдет полное отключение оборудования, сайт продолжит выполнятьсвои функции.
Чек-лист: В зоне риска ли ваш сайт?
Проверьте себя. Если хотя бы на два пункта вы ответили «Да», ваш бизнес под угрозой:
- Сайт физически находится на сервере в вашем офисе.
- Вы не знаете, когда последний раз проверялась целостность резервных копий.
- У вас нет пошагового плана: «Что делать, если сервер сгорит прямо сейчас».
- За сайт и за офисню it-инфраструктуру отвечает один и тот же человек.
