Кейс: развитие инфраструктуры сети корпоративных и дилерских сайтов

О клиенте

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

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

Исходная ситуация

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

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

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

Какие проблемы мы обнаружили

Резервное копирование зависело от прежнего подрядчика

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

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

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

Серверы были неоднородными и частично устаревшими

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

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

Работа сайтов зависела от незафиксированных фоновых заданий

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

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

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

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

Конфигурация новых серверов отличалась от старой инфраструктуры

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

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

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

Доступы выдавались шире, чем требовалось

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

Доступ к отдельным административным интерфейсам был открыт из внешней сети. Ограничение по IP или через VPN отсутствовало либо зависело от возможностей внешнего провайдера.

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

Диагностика аварий зависела от внешней инфраструктуры

Часть инцидентов была связана не с самими сайтами, а с сетью или платформой виртуализации. В таких случаях одновременно пропадали HTTP-доступ, SSH и связь с несколькими серверами.

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

Что было сделано

1. Приняли инфраструктуру и зафиксировали исходное состояние

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

Для переноса подготовили отдельные виртуальные машины. Ресурсы распределяли постепенно, поскольку клиент не мог заменить всю инфраструктуру одновременно.

По каждому проекту определили:

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

Это позволило перейти от набора разрозненных серверов к управляемому плану миграции.

2. Перенесли резервное копирование под контроль клиента

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

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

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

В результате резервные копии перестали зависеть от инфраструктуры прежнего подрядчика.

3. Развернули и стандартизировали новые серверы

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

На серверах настроили:

веб-серверы и обработку PHP;
базы данных и отдельные учётные записи;
структуру каталогов и права;
системные службы;
сертификаты; журналы;
планировщик заданий;
мониторинг;
резервное копирование.

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

4. Провели поэтапную миграцию сайтов

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

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

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

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

5. Настроили многоуровневый мониторинг

На контроль поставили доступность сайтов, серверов и системных служб. Мониторинг проверял HTTP-ответы, сетевую доступность, SSH, состояние веб-сервера, работу агентов, заполнение дисков, нагрузку и выполнение резервного копирования.

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

Оповещения по автоматическим проверкам переводили в инженерные задачи. Это позволяло не только восстановить сервис, но и сохранить историю повторяющихся сбоев.

6. Пересмотрели модель доступа

Провели аудит локальных пользователей, SSH-настроек и прав повышения привилегий. Удалили или заблокировали доступы подрядчиков, которые больше не участвовали в сопровождении.

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

После инцидента безопасности пароли обновляли последовательно: сначала готовили изменения в коде и конфигурации, затем меняли секрет на сервере и сразу проверяли работу проекта.

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

7. Организовали постоянную эксплуатацию

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

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

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

Результат

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

В результате:

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

Вывод

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

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