Простой коммерческого сайта в течение 1 часа обходится среднему e-commerce проекту в потерю от 0,5% до 2% месячной выручки, при этом 40% всех критических сбоев вызваны не атаками, а ошибками конфигурации DNS и прав доступа. Разбираю три реальных инцидента, где неправильный один символ в конфиге или лишний флаг chmod привели к полной недоступности ресурса.
Кейс 1: Конфликт записей A и CNAME
Проблема возникла при переносе сайта на новый IP-адрес: администратор оставил старую A-запись и добавил CNAME для поддомена www. В итоге 30% пользователей получали ошибку DNS_PROBE_FINISHED_NXDOMAIN из-за неконсистентности ответов рекурсивных DNS-серверов. Время восстановления составило 4 часа, так как TTL (Time To Live) был установлен на уровне 86400 секунд (24 часа), что замедлило обновление кеша у провайдеров.
Микро-вывод: Всегда снижайте TTL до 300-600 секунд за 24 часа до плановых работ. Это сокращает время простоя при ошибках с суток до 10 минут.
Кейс 2: Критическая ошибка прав 777
В попытке быстро исправить ошибку записи в лог-файл, разработчик установил права 777 на корневую директорию сайта. Результат — сервер Apache/Nginx выдал 500 Internal Server Error, так как многие современные конфигурации безопасности (например, suPHP или mod_ruid2) блокируют выполнение скриптов в папках с избыточными правами записи для всех. Сайт стал полностью недоступен для 100% трафика.
Правильный стандарт: Директории — 755, файлы — 644. Любое отклонение в сторону 777 на продакшене — это не только риск взлома, но и прямой путь к падению сервера из-за политик безопасности хостинга.
Кейс 3: Ошибки владельца и Group ID
После миграции сайта с одного VPS на другой через архив tar, владельцем файлов стал пользователь root вместо www-data. Сайт выдавал 403 Forbidden, так как веб-сервер не имел прав на чтение индексного файла. Исправление через команду chown -R www-data:www-data заняло 5 минут, но простой составил 40 минут из-за того, что команда была запущена на массиве в 15 ГБ данных без предварительного анализа структуры.
Микро-вывод: Проверка соответствия UID/GID пользователя веб-сервера должна быть первым пунктом чек-листа после любой миграции, чтобы понять, почему страница недоступна.
Сравнение методов восстановления доступа
При возникновении ошибок конфигурации выбор метода восстановления напрямую влияет на время простоя (Downtime). Сравнение двух подходов:
- Ручной правка конфигов через SSH: Время восстановления 5-15 мин, риск человеческой ошибки 20%, стоимость 0 руб.
- Откат к бэкапу через панель управления: Время восстановления 30-120 мин (зависит от объема данных), риск ошибки 2%, стоимость ресурсов хостинга.
Мой опыт показывает: если ошибка в DNS или правах — ручная правка в 10 раз быстрее. Откат к бэкапу оправдан только при повреждении структуры БД или удалении файлов.
Вывод
Для предотвращения подобных инцидентов необходимо внедрить два правила: жесткий стандарт прав доступа (755/644) и обязательное снижение TTL до 600 секунд перед любыми изменениями DNS. Избегайте использования прав 777 даже в режиме отладки — это плохая практика, которая ведет к конфликтам с серверным ПО. Начинайте с аудита текущих владельцев файлов (chown) и проверки DNS-записей через dig или nslookup, чтобы исключить конфликт A и CNAME.
