Первоначально клиент обратился из-за нехватки дискового пространства, периодических простоев и тяжелого резервного копирования. Сервер уже не справлялся с накопившимся объемом данных: только файлы CRM занимали около 1,9 ТБ, из которых примерно 1,8 ТБ приходилось на пользовательские загрузки. База данных занимала еще более 200 ГБ.

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

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

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

Поврежденная файловая система

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

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

Во время проекта этот риск реализовался: файловая система старого сервера повторно дала сбой, после чего была повреждена база данных и CRM перестала работать на исходной площадке.

Переполнение дискового пространства

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

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

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

Резервные копии не защищали от отказа физического сервера

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

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

Инфраструктура не была готова к воспроизводимому переносу

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

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

Почтовая доставка зависела от нескольких систем

После стабилизации основной инфраструктуры периодически возникали проблемы с доставкой писем из CRM. Часть сообщений попадала в спам или блокировалась внешними почтовыми системами.

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

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

Подготовили новую серверную площадку

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

На новой площадке:

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

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

Перенесли файлы и базу данных

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

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

Во время копирования контролировали заполнение файловых систем и при необходимости перераспределяли свободное место.

Восстановили CRM после аварии старого сервера

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

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

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

Проверили работу приложения после переноса

После восстановления проверили не только открытие сайта, но и прикладные функции CRM.

В ходе проверки:

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

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

Перестроили резервное копирование

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

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

Для тестовой площадки отключили избыточные копии, не имевшие самостоятельной эксплуатационной ценности.

Подключили постоянный эксплуатационный контроль

После миграции проект перешел на регулярную поддержку.

В мониторинг включили:

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

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

Исследовали проблемы почтовой репутации

Для диагностики почтовой доставки проверили настройки DNS и механизмы подтверждения отправителя: SPF, DKIM, DMARC и PTR.

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

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

Результат

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

CRM продолжила работу после аварии исходного сервера

устранена зависимость от поврежденной файловой системы

создан запас дискового пространства

рабочая и тестовая площадки разделены

резервное копирование приведено к управляемой схеме

восстановлена работа уведомлений и фоновых функций CRM

инфраструктура включена в централизованный мониторинг

конфигурация серверов стала воспроизводимой

обновления безопасности вошли в регулярный эксплуатационный процесс

диагностика почтовых проблем стала опираться на данные о репутации и источниках отправки

Вывод

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

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

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

Смотрите другие
кейсы по Bitrix

Error get alias

Хотите передать
свою инфраструктуру в надежные руки?

Будем рады проконсультировать вас и обсудить проект.

Миграция и стабилизация инфраструктуры корпоративной CRM на «1С-Битрикс24»

О клиенте

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