DevOps и надёжность: почему сайт «падает» и как этого избежать

Разбор от команды разработки AmSales.

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

Что на самом деле означает «сайт упал»

За фразой «сайт не открывается» скрывается минимум пять разных проблем, и лечатся они по-разному:

• Процесс приложения умер и не поднялся заново — упало Node/PHP, а супервизора нет.
• Кончился ресурс — память, место на диске, лимит открытых файлов. Классика: логи забили диск, база не может писать.
• База данных недоступна — пул соединений исчерпан, долгий запрос заблокировал таблицу.
• Внешняя зависимость отвалилась — платёжка, CRM, почтовый сервис. Без таймаутов один медленный API кладёт весь сайт.
• Нагрузка — рекламная кампания, парсер, DDoS. Инфраструктура рассчитана на «обычный день», а не на пик.

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

Мониторинг: без него вы узнаёте о падении от клиентов

Минимальный набор, который должен быть на любом продакшене:

• Внешний аптайм-чек раз в минуту с уведомлением в Telegram или на телефон. Проверяйте не главную, а реальный health-эндпоинт, который дёргает базу.
• Метрики хоста — CPU, RAM, диск, сеть. Диск на 90 % должен слать алерт заранее, а не когда он забился.
• Логи в одном месте с уровнями. Когда сайт лёг, у вас 5 минут, а не полчаса на поиск, где лежат логи.
• Алерты по симптомам, а не по всему подряд. Если оповещения приходят каждый час, их перестают читать — и пропускают настоящее.

Автовосстановление: сервер должен чиниться сам

Большинство ночных падений закрываются без человека, если заранее настроить самолечение:

• Супервизор процессов (systemd, PM2, Docker с restart: always) — упавшее приложение поднимается за секунды.
• Healthcheck + автоперезапуск контейнера — не просто «процесс жив», а «отвечает 200».
• Ограничение ресурсов на процесс, чтобы одна утечка памяти не утащила весь сервер.
• Ротация логов — банальный logrotate спасает от половины «диск переполнен».

Деплой — источник половины инцидентов

Сайты чаще всего падают не сами по себе, а в момент выкатки новой версии. Что снижает риск:

• CI/CD вместо ручного scp. Сборка, тесты и деплой — по кнопке из одного пайплайна, одинаково каждый раз.
• Быстрый откат. Прошлый работающий образ должен подниматься одной командой. Умение откатиться важнее умения чинить на бою.
• Zero-downtime деплой — новая версия поднимается рядом, трафик переключается, только когда она отвечает 200.
• Миграции БД отдельно и обратимо. Не удаляйте колонки в том же релизе, где меняете код: сначала совместимая схема, потом чистка.

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

Надёжность закладывается в код, а не докупается потом. Базовые приёмы:

• Таймауты на все внешние вызовы. Запрос к чужому API без таймаута — потенциальная остановка всего сайта.
• Graceful degradation. Отвалилась CRM — заявка падает в очередь и отправляется позже, а не теряется с ошибкой 500.
• Идемпотентность и очереди для тяжёлых и внешних операций, чтобы повтор не ломал данные.
• Кэш и CDN для статики и тяжёлых страниц — снимают нагрузку на пиках.

Резервные копии, которые реально восстанавливаются

Бэкап, который ни разу не разворачивали, — это не бэкап, а надежда. Правила простые: автоматические копии базы по расписанию, хранение вне того же сервера, регулярная проверка восстановлением на тестовом стенде. Отдельно держите под контролем срок жизни SSL-сертификата — просроченный сертификат для пользователя выглядит ровно как «сайт упал».

Чек-лист надёжности

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

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