Серверы, которые держатся сами

1. Google Cloud

   Инстансы Compute Engine, Cloud SQL там, где управляемая база оправдывает свою цену, Cloud Storage для медиа и бэкапов, балансировщик впереди, когда узлов больше одного. Снапшоты по расписанию, размеры инстансов пересматриваются по реальному трафику, а не угадываются на старте.

2. Amazon Web Services

   EC2 с томами EBS и политиками снапшотов, S3 для статики и копий вне площадки, RDS — когда базу лучше не держать самостоятельно, Route 53 и CloudFront для DNS и доставки. Security groups пишутся как список с запретом по умолчанию, а не открываются по ходу дела.

3. Обычный VPS

   Для большинства сайтов это честный ответ. Одна грамотно настроенная машина у европейского провайдера тянет нагруженную установку WordPress или Shop-Script быстрее и намного дешевле, чем облачная архитектура, которую в команде никто не умеет чинить.

4. Собственное железо

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

1. Debian и Ubuntu Server

   LTS-релизы, на пакетах вендора, а не на куче сторонних репозиториев. Автоматические обновления безопасности, SSH по ключу с отключённым входом под root, fail2ban, nftables или ufw закрыты по умолчанию, journald и logrotate настроены так, чтобы о разросшемся логе вы узнавали не по забитому диску.

2. Windows Server 2012 и новее

   Вплоть до актуальных релизов: IIS с отдельным пулом приложений на сайт, MS SQL Server, Active Directory и групповые политики, службы удалённых рабочих столов, файловые шары с квотами и теневыми копиями. Обновления ставятся по графику, а не откладываются, и путь миграции планируется до того, как версия выйдет из поддержки.

3. Контейнеры там, где они помогают

   Docker и Compose — чтобы зафиксировать стек, который должен совпадать между staging и продакшеном, или чтобы держать рядом несколько версий PHP или Node. Не для того, чтобы усложнить сервер с одним сайтом сверх необходимого.

1. nginx, или nginx перед Apache

   Использование nginx только там, где это позволяет приложение; в качестве обратного прокси перед Apache, где должны продолжать работать правила .htaccess. HTTP/2, gzip и Brotli, разумные ограничения для клиентов и статическая обработка файлов без активации PHP.

2. PHP-FPM, по пулу на сайт и в изоляции

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

3. MySQL, MariaDB или PostgreSQL

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

4. Redis или Memcached

   Объектный кэш и сессии — вне базы и вне файловой системы, с осознанно заданной политикой вытеснения и потолком памяти. Слушает localhost или приватную сеть: открытый наружу Redis — одна из самых надёжно эксплуатируемых вещей в интернете.

5. Node.js, когда его требует фронтенд

   Сборка выполняется в пайплайне, а не на боевом сервере. Долгоживущие процессы — под systemd, с политикой перезапуска и сбором логов, а не в сессии screen, которую кто-то однажды открыл.

6. TLS, который продлевается сам

   Let's Encrypt через ACME с автопродлением и хуком, который перезагружает веб-сервер, либо коммерческий сертификат — установленный и поставленный на контроль. Современные наборы шифров, HSTS там, где на него безопасно подписаться, и срок действия под наблюдением снаружи машины.

1. Домен и групповые политики

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

2. Файловый сервер

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

3. Терминальный сервер

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

4. Удалённый доступ

   WireGuard или OpenVPN в офисную сеть, персональные ключи, которые отзываются при уходе сотрудника. Открытый наружу RDP — это то, как заходит шифровальщик, и он до сих пор чаще всего и обнаруживается в доставшейся по наследству сети.

5. Почта, которая доходит

   SPF, DKIM и DMARC настроены корректно под вашего провайдера, плюс обратный DNS там, где почта уходит со своего сервера. За большинством обращений «наши счета уходят в спам» стоит одна недостающая DNS-запись.

1. Закрыто по умолчанию

   Файрвол запрещает всё и открывается порт за портом под названную причину. Базы, кэши и админ-интерфейсы слушают localhost или приватную сеть — и никогда публичный адрес просто потому, что так было проще при настройке.

2. Доступ, который можно отозвать

   Именные учётные записи вместо одного общего логина, SSH-ключи вместо паролей, sudo вместо root, двухфакторка везде, где панель её поддерживает. Когда человек уходит, один отзыв закрывает ему доступ везде — но только если так было построено с самого начала.

3. Сайты изолированы друг от друга

   Один системный пользователь и один пул PHP на сайт. На общем сервере заходят обычно не через защищённый сайт, а через забытый соседний — и изоляция как раз не даёт этому стать общей проблемой.

4. Обновления, которые реально ставятся

   Автоматические обновления безопасности на Linux, запланированное окно обновлений на Windows и отслеживание дат окончания поддержки, чтобы версия тихо не перестала получать исправления, продолжая при этом держать ваш бизнес.

5. Перебор паролей и вредоносный трафик

   fail2ban на SSH и на формах входа, лимиты частоты на веб-сервере, Cloudflare или аналог впереди там, где это оправдано объёмом. Страницы входа атакуют постоянно; вопрос лишь в том, считает ли это кто-нибудь.

6. Секреты вне кода

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

7. План на день, когда это случится

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

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

1. Три копии, два типа носителей, одна вне площадки

   Старое правило, и оно по-прежнему главное. Копия на том же сервере — не бэкап: она сгорит вместе с машиной и будет удалена тем же, что удалило оригинал.

2. Файлы, база данных и конфигурация

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

3. Копии, до которых не доберётся шифровальщик

   Хранилище вне площадки с версионированием или режимом append-only, и доступы, которые не лежат на том же сервере, который бэкапится. Современный шифровальщик первым делом ищет резервные копии — и находит их, если сервер может их удалить.

4. Глубина хранения, которой хватит

   Ежедневные копии хранятся две недели, еженедельные — пару месяцев, ежемесячные — дольше. Повреждение данных и тихую потерю замечают спустя недели, и одна перезаписанная копия к тому моменту уже ничем не поможет.

5. Восстановление на точку во времени

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

6. Восстановления, которые реально проверены

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

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

1. Деплой

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

2. Бэкапы, которые разворачивались

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

3. Мониторинг и оповещения

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

4. Staging, идентичный продакшену

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

5. Миграции без простоя

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

6. Администрирование

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

1. Аудит

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

2. Стабилизация

   Находки, опасные прямо сейчас: торчащие наружу сервисы, отсутствующие или непроверенные бэкапы, истекающие сертификаты, необновлённые версии. Чинятся первыми, до любых улучшений.

3. Автоматизация

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

4. Документация

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

5. Сопровождение

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