IT истории: антипарсинг

Не так давно был один интересный случай. Сайт клиентов парсили конкуренты, унося к себе довольно важные сведения. Кто именно - по айпи понять не получалось. Был вариант закрыть важную информацию от незарегистрированных пользователей, благо регистрация делалась только для юрлиц. Но от него отчаянно отбивался отдел маркетинга и продаж, вполне логично аргументируя это тем, что люди, изначально приходящие на сайт именно за этой информацией, часто конвертируются в постоянных клиентов. Каковы другие варианты?

Директор по развитию - очень умный и грамотный человек с крепким инженерным мышлением, долгое время напрямую руководивший техническим отделом - пришёл к айтишникам и поставил вопрос прямо: нас парсят, что мы можем этому противопоставить?

Айтишники закономерно перешли от формулировки бизнес-задачи к её технической формализации. Что значит парсят? Как именно парсят? Вариантов противодействия много - на уровне программных интерфейсов обмена данными, на уровне веб-сервера, на сетевом уровне, на уровне веб-клиента. Чтобы понять, какой подход применить - надо понимать, что именно происходит.

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

Итак - обнаружили, пришли к директору, отрапортовали.

“Отлично” - ответил директор. Можем ли мы от этого закрыться?

“Само собой” - ответили айтишники. В данном случае можно либо написать модуль антипарсинга в коде веб-сервиса. Займёт какое-то время и потребует дальнейшей поддержки разработчиков, но зато будет гибко настраиваемо и там можно прописывать сложную логику.

Либо просто добавить отсечки в конфигурацию веб-сервера: при большом числе запросов подряд с одного адреса сначала замедлять, а потом полностью отключать выдачу. С быстрым парсингом будет покончено. А медленный можно просто отсечь по айпи адресу. Сделать можно быстро, поддерживать сможет системный администратор.

“Значит, более простое решение позволит решить обе проблемы парсинга? Точно-точно?” - уточнил директор.

“Да, само собой. Обе проблемы будут решены. Точно-точно.” - уверенно ответили айтишники. Как говорится - запомните этот твит. Мы к нему ещё вернёмся.

“Вот молодцы. Тогда всё очевидно - внедряйте простое решение!” - приказал директор.

“Сэр, есть, сэр!” - взяли под козырёк айтишники.

Прошёл месяц.

“Ребята, нас снова парсят!” - прибежал возмущённый директор.

“Что значит парсят? Как именно парсят?” - снова стали уточнять айтишники.

“Ну снова так же - медленно, маскируясь под действия пользователя” - ответил директор, смотря на айтишников с плохо скрываемым возмущением и некоторым подозрением.

“А в чём сложность?” - удивились айтишники - “Забанить его снова по айпи, и всех делов. Ну, логи придётся покурить, конечно.”

Директор посмотрел на них уже с откровенным удивлением. Долгим таким взглядом посмотрел. Тяжёлым.

“В смысле - снова забанить по айпи? В смысле - снова курить логи?? У нас разве нет механизма автоматического определения медленного парсинга с автоматической блокировкой?”

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

“У нас нет, никогда не было и не предполагалось механизма автоматического определения такого парсинга. Более того, с выбранным нами подходом решить эту проблему в общем виде попросту невозможно.”

“Как так невозможно?? Вы же говорили, что он решает обе проблемы?? Вот же твит!” - ударил козырем по столу директор.

“Кхм…” - в некотором недоумении ответили айтишники - “а вот твит, где мы прямым текстом говорим, что распознавание поведения парсера, маскирующегося под пользователя, путём простой конфигурации конфигов невозможно. Твит был прочитан, принят к сведению, возражений не поступило. Решение о выборе простого подхода было принято уже после этого обсуждения.”

“Но… вот же, я прямым текстом спросил, будет ли решена проблема” - недоумённо повторил директор.

“Ну да. И проблема была решена.” - так же недоумённо ответили айтишники.

После чего обе стороны долго и молча смотрели друг на друга.

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

В чём же проблема?

Проблема - в проблеме. Точнее, в том смысле, который обе стороны вкладывали в термин “проблема” в том самом твите. Айтишники говорили о “проблеме медленного парсинга”, имея в виду проблему отсечки конкретного парсинга с конкретного адреса, который был найден в логах. Директор же имел в виду решение проблемы в общем виде. Чтобы вообще никто и никогда не смог парсить данные, маскируясь под пользователя.

Какие же выводы можно сделать из этой простой житейской истории? Неужто нужно уточнять каждое слово, договариваться об определениях каждого используемого термина? С таким оверхедом никакое общение попросту не будет возможно. Общение при помощи речи - что устной, что письменной - изначально предполагает некоторую неточность и расхождения в понимании. Именно поэтому учёные предпочитают общаться формулами - языком математики, в котором возможность неверной трактовки резко снижается. Хотя и не устраняется полностью. Но переводить повседневное общение на математический язык обречено на неудачу, как бы инженерам ни хотелось добиваться строгости терминов и определений.

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

Применительно к конкретике описанного случая - уточнить: “Будет ли решена проблема медленного парсинга, маскирующегося под действия пользователя - так, чтобы в дальнейшем нам не приходилось обнаруживать такой парсинг руками. Чтобы это обнаруживалось и блокировалось автоматически?”

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

Но это - долго, муторно и сложно. Поэтому обе стороны неосознанно сократили своё понимание до простого слова “проблема” - и получили то, что получили.

Такие дела.