Зачем изолировать домены, базы и конфигурацию
Изоляция уменьшает радиус аварии. Если узел сломался, остальная сеть должна продолжать отдавать страницы.
4 мин чтения · 17 августа 2026 г.
Изоляция звучит как инфраструктурный жаргон, но смысл простой: ошибка одного сайта не должна становиться ошибкой всех. Домен, база и конфигурация — три слоя, которые легко случайно склеить «для удобства» и потом расхлёбывать общим инцидентом.
Спросите: если этот узел удалить завтра, что ещё умрёт вместе с ним? Чем короче список, тем здоровее сеть.
Домен
Имя сайта — граница доверия для читателя и для сертификата. Общий домен с подпапками удобен для одного проекта. Для сети независимых витрин свой hostname нужен, чтобы cookie, поиск, почта и репутация не жили в одной куче. Переезд узла тогда сводится к смене имени и сертификата, а не к хирургии всего контура.
База
Общая база на все сайты кажется экономной, пока не понадобится выгрузить один узел, ограничить доступ подрядчику или откатиться после кривой публикации. Отдельная логическая граница — хотя бы tenant id и жёсткие запросы «только этот siteId» — обязательна. Физическое разделение баз — следующий шаг, когда объём и риски выросли.
- Каждый материал принадлежит одному сайту.
- Категории и страницы не пересекаются между доменами.
- Бэкап узла должен восстанавливаться без соседей.
Конфигурация
Тема, язык, регион, контакты, расписание — это настройки узла, не глобальные константы репозитория. Глобальным остаётся только то, что действительно общее: версия шаблона, правила прокси, секреты контура. Если ниша зашита в код, вы больше не управляете сетью, вы клонируете проект.
Что не нужно изолировать любой ценой
Шаблон, дизайн-токены и пайплайн деплоя как раз выгодно держать общими. Изоляция ради изоляции плодит ручную работу. Правило: изолируйте состояние и смысл, объединяйте механизм.
Если сайты на одном сервере, изоляции уже нет?
Сервер — общий ресурс. Изоляция начинается с данных и конфигурации. Один хост не отменяет tenant-границы, он только повышает цену ошибки в ОС и в прокси.