Тестовая среда ломает боевой сайт: как развести контуры

Хотели обновить тестовую DNS запись для тестовый контур. Скопировали зону «как в проде», поправили один хост — и случайно отправили checkout боевого сайта на тестовый стенд разработки-сервер. Полчаса пользователи оплачивали в никуда или видели заглушку. Откатили, но осадок и разбор полётов остались на неделю.

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

Типовые аварии на ровном месте

Сценарий неверного копирования DNS. Запись A/CNAME уехала не туда, TTL высокий — откат растягивается на время жизни кэша.

Сценарий общего хостинга без изоляции. Тестовый сайт лежит на том же аккаунте, что и бой; чистка кэша или сертификат затронули оба.

Сценарий «временный hosts у админа». Локально всё зелёное, у клиента — нет. Выкатывают изменение, которое в реальности не проверяли.

Где ошибаются команды

Один и тот же доступ к DNS у всех «кто рядом». Нет разделения ролей и аудита изменений.

Нет списка критичных имён: www, api, pay, mail. Их правят с той же лёгкостью, что и test 123.

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

Дисциплина, которая спасает

Разделяют зоны ответственности: боевая DNS зона и тестовая. Идеально — разные аккаунты/проекты у регистратора или облачного DNS, разные ключи API. Копирование «всё разом» становится невозможным по процессу.

Вводят change для критичных записей: кто меняет, зачем, какой TTL заранее понизили, как проверят, как откатят. Для низкого TTL перед окном работ это не паранойя, а тормоза.

Split-horizon и внутренние имена документируют. Что резолвится внутри офиса и что снаружи — должно быть ясно до инцидента, а не во время него.

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

Опытный подход к доменам и хостингу обычно включает инвентарь записей и автопродление доменов/сертификатов — потому что «тестовый контур broke боевой контур» соседствует с другим классическим ужасом: просроченный домен накануне кампании.

Быстрый чек после любого DNS изменения

• что видит внешний резолвер для pay/api/www;
• куда указывает checkout и платёжный callback;
• не задет ли MX/SPF, если правили «рядом»;
• когда истечёт пониженный TTL и нужно ли вернуть его назад.

Доступы, TTL и человеческий фактор

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

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

Отдельно защищают почтовые и платёжные имена. Ошибка в MX или в callback-домене лечится дольше и дороже, чем ошибка в test-landing. Их вообще не должно быть в одном «быстром» изменении пачкой.

Полезный ритуал — парный контроль на критичных правках: один вносит, другой проверяет внешним резолвером список имён. Две минуты ритуала дешевле часа простоя checkout.

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

Итог

Тестовый контур должен иметь право ошибаться. Prod — нет. Разведение зон, доступов и процедуры изменений делает это различие реальным.

Для бизнеса цена вопроса — прямая выручка на время жизни неверной DNS записи. Поэтому домены и хостинг здесь не «админская мелочь», а часть контура продаж.

Зачем это директору

Ошибка в DNS бьёт сразу по выручке: сайт «как будто открывается», но деньги и заявки уходят не туда. Это один из самых дорогих классов простых ошибок.

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

Заведите список «запрещено менять без второго глазá»: pay, api, www, mail, callback-домены. Даже сильные инженеры ошибаются в усталости; процесс существует именно для таких минут.

Если DNS правите через API/Terraform, всё равно оставьте ритуал внешнего замера после apply. Автоматизация не отменяет проверку реальности резолверами.

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

После инцидента с DNS всегда поднимайте постмортем на одну страницу: что изменили, какой TTL, кто заметил, сколько длилось. Без этого команда наступит на те же грабли.

Добавьте внешнюю проверку критичных имён в мониторинг. Пусть система кричит раньше клиентов.

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

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

Храните историю изменений DNS. Без неё постмортем превращается в гадание.

В панели DNS визуально отделите боевые зоны (нейминг, цвет проекта, отдельный аккаунт). Путаница глаз — частый корень аварии.

Запретите править MX и платёжные CNAME в одном change с тестовыми записями. Разные риски — разные операции.

Тестовая среда имеет право на ошибку только пока она физически не может задеть боевые имена. Всё остальное — лотерея.

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

Один предотвращённый DNS инцидент обычно окупает год аккуратных регламентов вокруг доменов и стендов.