Ну во-первых, я ее не выдумал, это реальный кейс из нашей работы, я его еще и упростил прилично.
Во-вторых, я не прошу написать код, я просто предлагаю порассуждать вслух, как подойти к решению этой задачи, причем предлагаю задавать любые уточняющие вопросы. Меня прежде всего интересует, как кандидат анализирует задачу, прежде чем "бросаться в бой".
В-третьих, я конечно могу ошибаться, но у меня есть убеждение, что человек с реальным опытом разработки и сопровождения проектов, должен понимать, что внешний сервис может вернуть не только код 200, но и коды ошибок, в том числе отличные от 50х и 404, и кандидату предлагается обсудить вопрос их обработки (там уже конкретные детали и требования озвучиваются, это не имеет отношение к данному посту).
Ну и в-четвертых, кандидаты отбираются по резюме в котором указан опыт разработки и интеграций с разными внешними API. Плюс, его повторно спрашивают предварительно, был ли такой опыт у него.
В реале так и сделано, там же не одно такое api, там целый зоопарк, и разные форматы и протоколы и разные условия/ограничения, именно это условие не самое страшное, есть и похуже... И все это надо обойти, собрать данные, обработать применяя правила, и отправить дальше внутри системы. И уложиться в некое общее время отведенное на это. И вот за последние года 3, все чаще и чаще всплывают проблемы связанные с сетевой доступностью. Отсюда собственно говоря и родилась такая задача.
Руками скорей всего. Инструмент держать в руках умею "вроде бы как", а насколько это соответствует реальности, только "продакшен" покажет. Но трудности и особенности работы "в поле", а не в кресле - представляю хорошо.
Допустим поставщик данных требует соблюдения интервала в 5 секунд. Если вы сделаете 50 запросов в течении этих 5 секунд, на 1 запрос вы получите код 200 и данные, а на 49 запросов - получите код 429. Понимаете о чем речь?
Я не очень понял, что именно предлагается "распараллелить"? Сами запросы? Но если не выжидать требуемое той стороной время, она будет отвечать 429. Обработку данных? Зачем, в чем мы выиграем?
Но если разработчик писал http запросы для "сервер-сервер", он же должен знать, что можно (надо) выставить значение таймаутов, иначе по дефолту будет использоваться 45 секунд (или что еще хуже, где-то в проекте оно в system property выставлено руками), а в этой задаче это приведет к тому, что при плохой связи (таймаут соединения) - будет впустую тратиться время. Там же простой подсчет на калькуляторе нужен. Если конечно имелся реальный опыт работы с такими вещами.
Тоже сейчас участвую в собеседованиях на позицию бэкендера (мидл и выше), не спрашиваю ничего, спрашиваю "с rest api работали?" если да, то прошу озвучить мысли вслух "как бы Вы решали такую задачу?" и даю ее короткое описание.
В задаче описано, что нам надо использовать чье-то внешнее rest api, это апи отдает данные порциями, то есть надо сделать больше одного запроса (больше 100..200) , в том апи есть ограничение на интервал между запросами (они знают кто к ним пришел, так как есть долгоживущий токен и его надо указывать в запросе), и есть требование уже нашего бизнеса "надо уложиться в отведенное время, данные записать куда-то (принять, что время обработки и записи данных практически мгновенное на фоне общих требований) или в случае "ошибок/не успеваем получить все данные" в отведенное время, кинуть алерт (не важно каким образом) и ничего не записывать совсем"
Из порядка 12 кандидатов на текущий момент, только один стал думать в сторону "а будет ли возможность выставить ограничение на таймаут соединения/чтения ответа или нет?" И то, только после того как я стал подталкивать его посчитать, блин, время, которое уйдет на все эти запросы. Многие начинают фантазировать в сторону распараллеливания запросов. То есть, либо не понимают условие задачи, либо пользуются ИИ, так как ИИ (я проверял на паре общедоступных моделей) начинает свое решение именно с этого, и только на 2..3-й странице указывает, что придется использовать синхронные вызовы, кандидат не успевает прочитать это.
Если ты имеешь реальный опыт работы, ты должен уже был наступать на такие грабли же? Или нет? Я начинаю уже думать, что я спрашиваю у людей какую-то ересь.
От всей этой ситуации остается неприятный осадок - "туристов сделали крайними". Дело даже не столько в утекших данных, сколько в ситуации, когда может сломаться процесс возвращения туристов, решения оперативных проблем с теми же отелями например. Кароче, неприятный осадок и от действий хакеров и от дырки у ТезТура. Какая то беспросветная жопа, простите мне мой албанский.
Скорей всего файл залили через какой-то служебный внутренний сервис "для турагенств" и тп, получили доступ к локальной сетке, там нашли следы/возможность запуска веб-панельки tomcat, которая если и была защищена от коннектов снаружи, то пропускала коннекты из локальной сети, ну а дальше получив доступ к деплою, уже дело техники. Как то так, грубо на пальцах, это видится.
Автор призывает к действиям с тщательным планированием. По его мнению, правительствам и регуляторам нужно финансировать инженеров по безопасности через гибкие гранты, создать стимулы для улучшения безопасности, особенно для частого пентестинга, поощрять использование передовых моделей с человеческим контролем для пентестинга, препятствовать OTA‑обновлениям и штрафовать за нерегулярные проверки безопасности. В первую очередь он призывает обратить внимание на больницы и местные органы власти. ... (и далее по тексту)
В принципе это можно считать дорожной картой, но это не один год и не два года... А каких то реальных предложений у автора нет. По итогу все сводится к постулату "давайте усилим службы безопасности и будем делать все хорошо, а плохо делать не будем"...
А правило drop более выгодно или это какие-то секурные стандарты? Просто если ставить по дефолту reject, то и диагностика проблемы была бы моментальной.
Ну во-первых, я ее не выдумал, это реальный кейс из нашей работы, я его еще и упростил прилично.
Во-вторых, я не прошу написать код, я просто предлагаю порассуждать вслух, как подойти к решению этой задачи, причем предлагаю задавать любые уточняющие вопросы. Меня прежде всего интересует, как кандидат анализирует задачу, прежде чем "бросаться в бой".
В-третьих, я конечно могу ошибаться, но у меня есть убеждение, что человек с реальным опытом разработки и сопровождения проектов, должен понимать, что внешний сервис может вернуть не только код 200, но и коды ошибок, в том числе отличные от 50х и 404, и кандидату предлагается обсудить вопрос их обработки (там уже конкретные детали и требования озвучиваются, это не имеет отношение к данному посту).
Ну и в-четвертых, кандидаты отбираются по резюме в котором указан опыт разработки и интеграций с разными внешними API. Плюс, его повторно спрашивают предварительно, был ли такой опыт у него.
"кровавый энтерпрайз"
В реале так и сделано, там же не одно такое api, там целый зоопарк, и разные форматы и протоколы и разные условия/ограничения, именно это условие не самое страшное, есть и похуже... И все это надо обойти, собрать данные, обработать применяя правила, и отправить дальше внутри системы. И уложиться в некое общее время отведенное на это. И вот за последние года 3, все чаще и чаще всплывают проблемы связанные с сетевой доступностью. Отсюда собственно говоря и родилась такая задача.
Руками скорей всего. Инструмент держать в руках умею "вроде бы как", а насколько это соответствует реальности, только "продакшен" покажет. Но трудности и особенности работы "в поле", а не в кресле - представляю хорошо.
Допустим поставщик данных требует соблюдения интервала в 5 секунд. Если вы сделаете 50 запросов в течении этих 5 секунд, на 1 запрос вы получите код 200 и данные, а на 49 запросов - получите код 429. Понимаете о чем речь?
Я не очень понял, что именно предлагается "распараллелить"?
Сами запросы? Но если не выжидать требуемое той стороной время, она будет отвечать 429.
Обработку данных? Зачем, в чем мы выиграем?
Наверное Вы правы. Но пока никакой другой, небольшой по объему требований задачи, чтобы проверить реальность написанного в резюме, в голову не пришло.
>в том апи есть ограничение на интервал между запросами
Потому, что 429 прилетит в ответ. А из реальных кейсов, иногда и блокировка на сутки после 10 таких попыток.
Но если разработчик писал http запросы для "сервер-сервер", он же должен знать, что можно (надо) выставить значение таймаутов, иначе по дефолту будет использоваться 45 секунд (или что еще хуже, где-то в проекте оно в system property выставлено руками), а в этой задаче это приведет к тому, что при плохой связи (таймаут соединения) - будет впустую тратиться время. Там же простой подсчет на калькуляторе нужен. Если конечно имелся реальный опыт работы с такими вещами.
забыли "в том, что ее легко 'написать и запустить' и гори оно потом там синим пламенем все" )))
Я не пройду. Это точно. Это 146% Поэтому, периодически проигрываю комбинации, куда, в какую сферу я пойду потом работать.
Тоже сейчас участвую в собеседованиях на позицию бэкендера (мидл и выше), не спрашиваю ничего, спрашиваю "с rest api работали?" если да, то прошу озвучить мысли вслух "как бы Вы решали такую задачу?" и даю ее короткое описание.
В задаче описано, что нам надо использовать чье-то внешнее rest api, это апи отдает данные порциями, то есть надо сделать больше одного запроса (больше 100..200) , в том апи есть ограничение на интервал между запросами (они знают кто к ним пришел, так как есть долгоживущий токен и его надо указывать в запросе), и есть требование уже нашего бизнеса "надо уложиться в отведенное время, данные записать куда-то (принять, что время обработки и записи данных практически мгновенное на фоне общих требований) или в случае "ошибок/не успеваем получить все данные" в отведенное время, кинуть алерт (не важно каким образом) и ничего не записывать совсем"
Из порядка 12 кандидатов на текущий момент, только один стал думать в сторону "а будет ли возможность выставить ограничение на таймаут соединения/чтения ответа или нет?" И то, только после того как я стал подталкивать его посчитать, блин, время, которое уйдет на все эти запросы. Многие начинают фантазировать в сторону распараллеливания запросов. То есть, либо не понимают условие задачи, либо пользуются ИИ, так как ИИ (я проверял на паре общедоступных моделей) начинает свое решение именно с этого, и только на 2..3-й странице указывает, что придется использовать синхронные вызовы, кандидат не успевает прочитать это.
Если ты имеешь реальный опыт работы, ты должен уже был наступать на такие грабли же? Или нет? Я начинаю уже думать, что я спрашиваю у людей какую-то ересь.
Чорт, а я ведь знал когда-то про "пары чисел", просто потому что это красиво, но ведь забыл напрочь когда прочитал этот вопрос..
"Без бумажки ты какашка, а с бумажкой - Человек"
ничего не поменялось за последние 50 лет
От всей этой ситуации остается неприятный осадок - "туристов сделали крайними". Дело даже не столько в утекших данных, сколько в ситуации, когда может сломаться процесс возвращения туристов, решения оперативных проблем с теми же отелями например. Кароче, неприятный осадок и от действий хакеров и от дырки у ТезТура. Какая то беспросветная жопа, простите мне мой албанский.
Скорей всего файл залили через какой-то служебный внутренний сервис "для турагенств" и тп, получили доступ к локальной сетке, там нашли следы/возможность запуска веб-панельки tomcat, которая если и была защищена от коннектов снаружи, то пропускала коннекты из локальной сети, ну а дальше получив доступ к деплою, уже дело техники. Как то так, грубо на пальцах, это видится.
В принципе это можно считать дорожной картой, но это не один год и не два года... А каких то реальных предложений у автора нет. По итогу все сводится к постулату "давайте усилим службы безопасности и будем делать все хорошо, а плохо делать не будем"...
Вы на дату моего сообщения посмотрите)))
А правило drop более выгодно или это какие-то секурные стандарты? Просто если ставить по дефолту reject, то и диагностика проблемы была бы моментальной.
Так по идее "новые правила сетевого фильтра в новом облаке " должны скорей приводить к
connection refused,а не к таймауту соединения, или нет?