Ответственность за «положивший» сайт парсер

Дисклеймер: материал носит информационный характер и не является юридической консультацией. Ответственность и ее объем зависят от фактов (намерение, режим доступа, масштаб, ущерб, доказательства). Для конкретного кейса подключайте юриста и специалистов по ИБ/инфраструктуре.

«Положить сайт» парсером — это создать DoS-эффект (отказ в обслуживании) за счет запросов: резкий рост RPS, исчерпание CPU/RAM/DB-пула, лавина 5xx/timeout, падение конверсии и/или простой продаж. Такое случается не только из-за “злого умысла”, но и из-за банальной ошибки конфигурации: слишком много потоков, бесконечные ретраи, парсинг “дорогих” эндпоинтов (поиск/фильтры), отсутствие лимитов и стоп-условий.

Что значит «положить сайт» и почему парсер становится причиной

Типовые “механики” падения:

• Резкий рост запросов к веб-серверу и приложению → очередь запросов → timeouts
• Перегруз БД (особенно от поиска/фильтров) → блокировки/медленные запросы
• Истощение лимитов (пул соединений, лимит воркеров, лимит CPU)
• Лавина ретраев: 5xx/timeout → бот повторяет запросы → еще больше 5xx
• Медиа/файлы: скачивание изображений/архивов на высокой скорости → трафик/CDN-счет растут

Чем «нагрузочный парсинг» отличается от DDoS

• DoS-эффект: сайт “не отвечает”, но причина может быть и “неумышленной” (ошибка в скрипте, неверные настройки).
• DDoS: как правило, распределенная атака (много источников) и явная цель — отказ в обслуживании.

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

Типовые сценарии, когда парсер «кладет» сайт

1. Слишком высокий параллелизм (много потоков/процессов)
2. Агрессивные ретраи без backoff при 5xx/timeout
3. Парсинг поиска/фильтров с комбинаторикой параметров (“взрыв URL”)
4. Полный обход сайта “с нуля” вместо инкрементального обновления
5. Запуск в пик посещаемости (когда сайт и так на пределе)
6. Несколько парсеров одновременно (разные подрядчики/задачи)
7. Баг пагинации/редиректов → бесконечный цикл обхода
8. Скачивание больших медиа/фидов без ограничений
9. Игнорирование 429/503 (сайт просит “остановиться”, а бот давит сильнее)
10. Парсинг “тяжелых” страниц без кэша на стороне ресурса

Что считается ущербом и как его фиксируют

В гражданско-правовом смысле речь обычно про убытки (реальный ущерб + упущенная выгода). В ГК РФ убытки определены как расходы/утрата имущества (реальный ущерб) и неполученные доходы (упущенная выгода).

Также применяется общий принцип: вред имуществу юрлица подлежит возмещению лицом, причинившим вред (при наличии условий ответственности).

Что обычно фиксируют (чек-лист доказательств)

• Access logs: IP/подсети/ASN, user-agent, пути (paths), timestamp, коды ответов, RPS по минутам
• Метрики инфраструктуры: CPU/RAM, DB latency, очередь запросов, saturation по воркерам/пулу соединений
• Финансовые следы: рост расходов на CDN/трафик/серверы (счета/акты)
• Бизнес-метрики: падение заказов, конверсии, выручки в период инцидента (аналитика/BI)
• Хронология: когда началось, когда остановилось, какие меры приняты

Практически важно: без логов и временной корреляции “кто положил” доказать тяжело.

Ответственность

1) Гражданско-правовая

Чаще всего спор идет в плоскости возмещения убытков/вреда: нужно показать факт вреда/убытков, причинно-следственную связь и другие условия ответственности. Опора — нормы об убытках (ст. 15 ГК) и общие основания деликтной ответственности (ст. 1064 ГК).

Если между сторонами есть договор (например, подряд на парсинг/интеграцию) — добавляется договорная ответственность и распределение рисков в условиях договора.

2) Уголовно-правовая (концептуально)

В “красной зоне” оказываются ситуации, где усматривается неправомерный доступ или иное деяние, повлекшее блокирование/копирование/модификацию информации.

• УК РФ ст. 272 описывает неправомерный доступ к охраняемой законом компьютерной информации, если он повлек, среди прочего, блокирование или копирование.
• УК РФ ст. 274 касается нарушения правил эксплуатации средств хранения/обработки/передачи компьютерной информации и сетей, повлекшего уничтожение/блокирование/модификацию/копирование и крупный ущерб.

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

3) Административная и “прочие” риски

Даже когда до уголовной/крупной гражданской истории не доходит, возможны:

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

Кто отвечает: заказчик, исполнитель, инфраструктура

С точки зрения фактов обычно смотрят: кто контролировал запуск и кто извлекал выгоду.

• Заказчик сам запустил парсер → риски на заказчике (он субъект действий).
• Подрядчик делает парсинг “под ключ” → у подрядчика выше зона контроля (лимиты, мониторинг, stop-условия), но возможны нюансы договора и ТЗ.
• “Прокси/облака/третьи лица” → усложняет доказывание, но не отменяет вопроса: кто организовал и управлял процессом.

Как снизить риск «положить» сайт

Без “серых схем” — только то, что снижает вероятность инцидента:

• Rate limiting и лимит параллелизма (глобальный и по эндпоинтам)
• Backoff и стоп-условия при 429/5xx/timeout (не “долбить сильнее”)
• Инкрементальные обновления вместо полного обхода
• Кеширование результатов и “не ходить дважды” по одному и тому же
• Запрет/строгие лимиты на “дорогие” зоны: поиск, фильтры, сложные параметры
• Окна запуска (не в пики)
• Мониторинг + kill switch (авто-останов при росте ошибок/latency)
• Тестовый прогон на малой частоте перед масштабированием
• Если возможно — официальные выгрузки/API вместо веб-скрейпинга

Таблица: сценарий → риск → профилактика → кто контролирует

Сценарий	Риск	Профилактика	Кто контролирует
Много потоков/параллелизма	DoS-эффект	лимит concurrency + RPS	Исполнитель/заказчик
Ретраи без backoff	“лавина” 5xx	экспоненциальный backoff + стоп-условия	Исполнитель
Парсинг поиска/фильтров	перегруз БД	исключить/строго лимитировать	Исполнитель
Полный обход ежедневно	лишняя нагрузка	инкремент + дифф-обновления	Исполнитель/заказчик
Скачивание медиа	трафик/CDN-счет	лимиты по байтам/типам	Исполнитель
Запуск в пик	падение под реальным трафиком	расписание вне пиков	Заказчик/исполнитель
Бесконечная пагинация	бесконечный цикл	max depth + stop rules	Исполнитель
Несколько парсеров сразу	суммарная нагрузка	координация графиков	Заказчик
Игнорирование 429/503	эскалация блокировок/ошибок	уважать коды, снижать темп	Исполнитель
Нет мониторинга	позднее обнаружение	алерты + kill switch	Исполнитель

Что делать прямо сейчас

Если вы владелец сайта и вас «кладут»

1. Включить/усилить WAF / rate limits (особенно на поиск/фильтры)
2. Временно ограничить “дорогие” запросы, добавить кеширование
3. Сохранить логи и метрики (временные интервалы — критично)
4. Быстро определить источник(и) трафика (IP/ASN/UA/paths)
5. Попробовать связаться с источником трафика/провайдером (если это добросовестный сбор — часто помогает)
6. Зафиксировать ущерб: расходы, простой, падение выручки/конверсии

Если вы заказчик/исполнитель парсинга и произошел инцидент

1. Немедленно остановить парсер (kill switch)
2. Зафиксировать конфигурацию, логи, время запуска/остановки
3. Уведомить пострадавшую сторону и предложить разбор причин (это часто снижает эскалацию)
4. Сделать RCA (root cause analysis): что именно перегрузило сайт
5. Внедрить лимиты/stop-условия/инкремент и повторить только через тестовый прогон

Мини-кейсы

Кейс 1: “положили сайт ретраями”
Парсер получал 5xx и мгновенно повторял запросы, усугубляя перегруз. После инцидента добавили backoff, лимиты на параллелизм и стоп-условия при росте ошибок — повторов “лавиной” не стало.

Кейс 2: “поиск оказался самым дорогим”
Сбор шел через поиск с множеством фильтров → перегруз БД. Решение: исключили поиск из обхода, перешли на инкремент по листингам/карточкам и снизили частоту обновлений — сайт перестал падать.