DDoS-атаку на сайт останавливают с провайдером, а в коде защищают рабочие сценарии

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

Медленный экран ещё не доказывает атаку. Cloudflare называет также всплеск запросов и необычные обращения в логах. Сравните их с обычным потоком.

Не ждите диагноза, чтобы открыть обращение. Напишите «подозрение на DDoS» и приложите наблюдения. Провайдеру нужны факты.

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

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

Сетевая защита принимает поток раньше сервера. При переполненном канале ограничитель внутри приложения уже не освободит его.

Уточните покрытие у провайдера. Yandex Cloud различает сетевую защиту L3/L4 и прикладную L7. Наличие одного пакета не подтверждает другой.

Провайдер фильтрует и веб-запросы. Договоритесь, кто меняет каждое правило и проверяет последствия: граница работы зависит от услуги.

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

Добавить мощности можно временно. Без пределов расходов и наблюдений это увеличивает счёт. Инженер проверяет причину исчерпания ресурсов.

Защищайте путь покупки или заявки. Доступная главная ещё не означает работающий бизнес. Назовите сценарий, который нельзя потерять.

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

Лимит на один адрес не заменяет общий предел. Письма отправляют разным получателям, а ресурсы общие. Проверяйте расход всей операции.

Порог берут из обычного поведения и возможностей системы. «Всем по одному запросу» способно сломать работу. Нужны наблюдения до и после.

На vibecoding.ru инженер ведёт машину агентов: задаёт правила и принимает решения. Агенты пишут код. Наш пример касается почтовой формы.

Правка меняет цену повторного действия: новый вызов больше не обязан создавать письмо. Из этой истории нельзя вывести стойкость сайта к DDoS.

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

Урок «Файл правил целиком» касается передачи ограничений. Их записывают в правила для ИИ-агентов и закрепляют проверкой.

«Остановите DDoS» не задаёт места правки. Постановка задачи агенту начинается с конкретного сценария и наблюдаемой проблемы.

Дайте агенту очищенные логи и согласованный предел. Если предел не измерен, сначала нужна задача на наблюдение. Его нельзя выбрать из воздуха.

На инциденте правку делают узкой. Переделка сайта увеличит число неизвестных. Для опасной операции готовят проверку и возврат прежней версии.

Агент готовит код, люди отвечают за выпуск. Порядок проверки и прав описан в статье об ответственности за ошибки ИИ.

Фильтрацию согласуют с провайдером. Менять её одновременно с маршрутом трафика без общей хронологии плохо для диагностики.

Восстановление подтверждает рабочий сценарий. Форма открылась, но заявка ещё может не сохраняться. Одного ответа сервера недостаточно.

Проверяйте правильность вместе с доступностью. Повтор заказа не создаёт новую покупку. После оплаты сверяют запись и статус, а не только экран.

Запишите ошибки, время ответа, очередь и успешные действия до и после. Ведущий инцидент согласует с провайдером окно наблюдения.

После стабилизации нужна нагрузочная проверка. Она выявит предел рабочего пути. Согласуйте среду и условия отдельной профилактической задачи.

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

При недоступности сайта обращаются к провайдеру. Разработка нужна, если после фильтрации отдельные сценарии перегружают приложение или работают неверно.

На /services «Один проект» стоит 250 000 ₽/мес. на 08.10.2026. Это доработка приложения после первичного реагирования.

Anti-DDoS и дежурства 24/7 согласуют отдельно. Подписка на разработку не заменяет эти услуги.

Для фильтрации и аварийного дежурства выбирайте соответствующую службу. Регулярные задачи в коде после стабилизации можно вести подпиской.

Для обсуждения доработок откройте страницу для руководителя. Наблюдения и задачи обсудим на агентной разработке по подписке.

1. Подключите провайдера и передайте наблюдения. Недоступность сайта ещё не устанавливает причину.

2. Разделите фильтрацию и доработку приложения. За каждым изменением закрепите исполнителя и способ возврата.

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

4. После стабилизации сохраните проверки и сигналы. Anti-DDoS, код и дежурство требуют отдельных договорённостей.