Если говорить про оборудование крупных вендоров, то для линеек продукции массового производства в большинстве случаев есть несколько релизов софта (старые и новые) и патчи, которые позволяют пофиксить проблему. В нашем случае мы имеем нишевый продукт, для которого альтернативного софта на момент тестирования не существовало. Поэтому замена оборудования была единственным быстрым вариантом решения проблемы. А вендор в свою очередь получил важную информацию о работе своего продукта и начал устранять ошибки.
В данном случае стояла блокировка на уровне софта, что было выявлено в ходе анализа трейсов и сообщений между телефоном и сетью, а также на основе спецификации производителя телефона
Само отношение к 1С у многих осталось во временах 7.7 и 8.0. Многие до сих пор боятся Linux и Postgres. Цели статьи как раз совпадают с вашим мессаджем.
Гипервизоры я не рассматривал в этой статье. А так да, про OpenStack тоже на написал) Сравнение Linux и Windows по производительности, надежности и прочим — это тема для холиваров
Самой 1С VDI не нужен конечно. После 20 года многие компании выбрали именно это решение для удаленного доступа сотрудников и количество инсталляций растет. А вот в VDI конечно можно работать и веб-клиентом, и тонким, и толстым (для гурманов). Акцент сделан на отказ от иностранного ПО. Гибридные варианты можно рассматривать только как промежуточные варианты на этапе миграции.
Правильное уточнение, технически это возможно. И даже для 1С можно применить, если серверы предприятия будут на Windows. Только в разрезе перехода на Linux это не имеет смысла, от операционных систем Microsoft уйти не получится все равно.
На самом деле, у krbtgt есть политика протухания пароля, но она применима только к активным учетным записям, которые умеют логиниться. krbtgt дезактивирована и никуда не логинится, поэтому эта политика на неё не распространяется
В наших расследованиях мы очень часто сталкиваемся с уязвимостями в различных CMS, которые либо не обновлены, либо "слабо" сконфигурированы. Версия джумлы действительно не самая актуальная - использовалась версия 3.4.6, в которой была уязвимость, приводящая к RCE. В самом сценарии злоумышленник эксплуатирует данную уязвимость, затем повышает свои привилегии и в конечном итоге производит дефейс сайта.
SecretID и roleID - это в какой-то степени аналоги логина и пароля. Они оба должны оказаться в приложении, чтобы приложение получило токен, по которому уже получит секреты. При этом они достаточно равноценны в своем написании - оба представляют собой длинный и почти случайный набор знаков. Поэтому выбирать, какой участник процесса положит в приложение SecretID, а кто положит roleID, нужно на основании того, как выполняется процесс: какие права в приложении есть у devops-инженера, какие полномочия в CI/CD есть у владельца приложения и т.д.
Привет! Мы проверили наличие самого протокола, без погружения. И прошивки не обновляли. Думаю, тут только попробовать с ними связаться marketing@ttyinfo.com. Может смогут переадресовать на суппорт.
Давайте свернем это обсуждение, так как я не вижу в нем смысла. Я не знаю ни одного аналитика, который применяет в своей рутинной работе преобразование Фурье или фильтр Калмана. У меня есть большой опыт использования этих инструментов, но в совершенно других, инженерных задачах. Допускаю, что есть проекты, в которых это действительно необходимо (возможно, у вас как раз такой случай), но если говорить об общей массе — сомневаюсь.
Своё мнение по этому вопросу я высказала, ваше также услышала, но я с ним не согласна.
В конце концов, эта статья посвящена моему видению вопроса, основана на моем практическом опыте, никто не мешает написать вам свою :)
Так речь не о студенте. По тому, что я вижу, в основном от аналитиков просят выгружать данные простыми запросами (без требований в супер продвинутом уровне в SQL), анализировать на наличие выбросов, пропущенных значений и пр., трансформировать (объединять, группировать и т.д.) и анализировать в привязке к бизнес-задаче. Поэтому так или иначе работать все равно нужно с сырыми данными, никто их не приготовит за тебя. По результатам этого анализа нужно делать выводы и демонстрировать результаты команде/заказчику. Также часто аналитики общаются с коллегами/заказчиком для лучшего понимания данных. В некоторых случаях дополнительно просят умение строить классические ML-модели
В разных компаниях совершенно разные требования :) Да, знание математики очень важно, тем не менее на практике во многих вакансиях требования гораздо ниже того, что вы описали (по крайней мере на начальные позиции). Часто просто дают данные и просят подготовить отчет (например, в формате jupyter-notebook), где нужно проанализировать все с точки зрения бизнеса, например. На всякий случай оговорюсь, что в этой статье я не говорю о том, какие знания должны быть у аналитика (как и у дата-сайнтиста), я скорее говорю о том минимуме, который нужно пройти, чтобы иметь возможность начать проходить собеседования. И, разумеется, это не означает, что после получения оффера обучение заканчивается
Прежде всего, если у человека нет совсем никакого опыта (ни математики, ни программирования), лучше идти сначала на дата-аналитика, это будет куда проще и быстрее.
Но даже в этой ситуации, если человек сильно замотивирован, и хочет именно в data science и будет заниматься, то имхо полгода — это адекватное количество времени.
Мой кейс: мехмат + опыт программирования на С++ (сугубо с внутренними библиотеками работодателя) и некоторый опыт программирования на python (без ООП). У меня ушло на обучение где-то 2-3 месяца, но это с небольшими перерывами и при офисной работе с 8 до 17 с высокой загруженностью. У меня была мотивация, поэтому я ботала в метро, по вечерам и выделяла время на выходных. Потом я начала искать работу, проходить интервью и по их результатам что-то еще параллельно добивала. Всего на поиск работы у меня ушло около 2-х месяцев, но это был очень интенсивный процесс, в среднем где-то по 2 технических интервью в неделю.
На мой взгляд, куда хуже растягивать обучение на год или даже на годы, т.к. это очень длинная дистанция, можно легко потерять нить происходящего, выгореть и все забросить.
Питон — это настолько обширный язык программирования, что изучать его можно всю жизнь :) Все зависит от того, для чего вы его изучаете. Мне кажется, очень важно помнить, что Питон — это лишь инструмент, который используется для различных задач. По сути он представляет собой основы (что такое интерпретатор, какие есть типы и структуры данных, что такое стек вызовов, пространства имен и области видимости, элементы ООП) и большое количество библиотек и фреймворков. Например, для того, чтобы заниматься разработкой высоконагруженных сервисов, необходимо уметь работать с одним набором инструментов (многопоточность, работа с REST API запросами и пр.), для data science или для аналитики данных будут совершенно другие библиотеки (анализ данных, рисование графиков, обучение моделей). Например, если взять ту же биоинформатику — там настолько специфические инструменты, что смысла их изучать без особой необходимости совершенно нет. Поэтому при изучении Питона важно разобраться с основами и сконцентрироваться на том наборе библиотек и фреймворков, который нужен для достижения желаемой цели. Еще я бы здесь обратила внимание на то, что ты никогда не выучишь все и сразу, часто обучение происходит итерационно — сначала появляется первое понимание происходящего, потом оно уточняется с появлением нового опыта, и это может происходить на протяжении многих лет. Поэтому очень важно сдерживать себя и не пытаться выучить сразу все досконально, это не получится и всегда будут какие-то белые пятна, в которые можно углубляться.
Насчет оценки времени, полутора месяцев для изучения основ в первом приближении, на мой взгляд, вполне достаточно (хотя, разумеется, копать глубже можно очень долго). Конечно, это индивидуально, кто-то справится и за неделю (лично знаю такие истории), кому-то потребуется больше времени. Но здесь я бы обратила внимание на то, что очень важно отслеживать прогресс. Если есть понимание, что ты топчешься на месте, то имеет смысл обратиться за помощью. Можно написать в тематические чаты, можно поискать ментора (например, на https://getmentor.dev/ есть менторы, которые дают бесплатные консультации).
Что касается Git и Docker, опять же, всё зависит от целей. В посте я рассматриваю изучение этих инструментов для дата-сайнтистов, не для разработчиков и не для дата-инженеров/MLOps-ов. Чтобы понять концепцию систем контроля версий, принцип работы Git, основные понятия (что такое репозиторий, как делать коммиты, работа с ветвлением, слияние веток) и команды, уйдет максимум неделя (это еще и с практикой). То же самое с докером. Чтобы понять, что такое докер-файл, докер-образ, как создается контейнер, базовые команды для запуска контейнера — на это уйдет неделя. Разумеется, если погружаться глубже, начать писать самостоятельно докер-файлы и погружаться в оркестрацию контейнеров, то тут потребуется гораздо больше времени, но для джуновской DS-позиции это не нужно.
Разумеется, это не полные университетские курсы мат. анализа и линейной алгебры, даже не близко к этому :) но за пару недель действительно можно в первом приближении разобраться с самыми базовыми понятиями — с дифференцированием, векторно-матричными операциями, функциями многих переменных, понятиями градиента и матрицы Гессе, с постановкой задачи оптимизации и пр. В дальнейшем, конечно, было бы неплохо посмотреть уже полные курсы, которые есть в свободном доступе в большом количестве, просто это займет значительное время и не является необходимым условием для понимания ML-алгоритмов . Что касается SQL, изучить синтаксис и разобраться, как делать выгрузки из БД, как объединять таблицы, что такое primary/secondary key, чем отличаются разные join-ы — это дело пары дней, особенно если есть опыт работы с библиотеками типа pandas. Ну неделю можно еще порешать задачки, просто чтобы руку набить. Все равно на реальной работе будет своя специфика, к которой надо будет адаптироваться и что-то дополнительно гуглить, поэтому, на мой взгляд, тратить очень много времени на SQL не стоит. Хотя что касается сроков обучения — тут все сугубо индивидуально, все люди разные, я оцениваю ситуацию для эдакого сильно замотивированного человека в вакууме, обобщая мой личный опыт и опыт моих знакомых :)
Так как на прошлом месте работы я была помощником HR и выполняла многие его функции, мне казалось, что у меня может получится попасть в ИТ на должность младшего HR или помощника HR. Но поговорив с сотрудниками, занимающимися подбором персонала в ИТ-сфере, я поняла, что это намного сложнее, что есть определенная специфика и требуется больше опыта, чем у меня было на тот момент.
Если говорить про оборудование крупных вендоров, то для линеек продукции массового производства в большинстве случаев есть несколько релизов софта (старые и новые) и патчи, которые позволяют пофиксить проблему. В нашем случае мы имеем нишевый продукт, для которого альтернативного софта на момент тестирования не существовало. Поэтому замена оборудования была единственным быстрым вариантом решения проблемы. А вендор в свою очередь получил важную информацию о работе своего продукта и начал устранять ошибки.
Добрый день,
Это российский вендор Trialink, оборудование которого входит в ТОРП.
Это зависит от договоренностей с операторами сотовой связи, так как на их частотах строится сеть для потенциальных заказчиков.
В данном случае стояла блокировка на уровне софта, что было выявлено в ходе анализа трейсов и сообщений между телефоном и сетью, а также на основе спецификации производителя телефона
Само отношение к 1С у многих осталось во временах 7.7 и 8.0. Многие до сих пор боятся Linux и Postgres. Цели статьи как раз совпадают с вашим мессаджем.
Гипервизоры я не рассматривал в этой статье. А так да, про OpenStack тоже на написал)
Сравнение Linux и Windows по производительности, надежности и прочим — это тема для холиваров
Самой 1С VDI не нужен конечно. После 20 года многие компании выбрали именно это решение для удаленного доступа сотрудников и количество инсталляций растет. А вот в VDI конечно можно работать и веб-клиентом, и тонким, и толстым (для гурманов).
Акцент сделан на отказ от иностранного ПО. Гибридные варианты можно рассматривать только как промежуточные варианты на этапе миграции.
Правильное уточнение, технически это возможно. И даже для 1С можно применить, если серверы предприятия будут на Windows. Только в разрезе перехода на Linux это не имеет смысла, от операционных систем Microsoft уйти не получится все равно.
На самом деле, у krbtgt есть политика протухания пароля, но она применима только к активным учетным записям, которые умеют логиниться. krbtgt дезактивирована и никуда не логинится, поэтому эта политика на неё не распространяется
В наших расследованиях мы очень часто сталкиваемся с уязвимостями в различных CMS, которые либо не обновлены, либо "слабо" сконфигурированы. Версия джумлы действительно не самая актуальная - использовалась версия 3.4.6, в которой была уязвимость, приводящая к RCE. В самом сценарии злоумышленник эксплуатирует данную уязвимость, затем повышает свои привилегии и в конечном итоге производит дефейс сайта.
SecretID и roleID - это в какой-то степени аналоги логина и пароля. Они оба должны оказаться в приложении, чтобы приложение получило токен, по которому уже получит секреты. При этом они достаточно равноценны в своем написании - оба представляют собой длинный и почти случайный набор знаков. Поэтому выбирать, какой участник процесса положит в приложение SecretID, а кто положит roleID, нужно на основании того, как выполняется процесс: какие права в приложении есть у devops-инженера, какие полномочия в CI/CD есть у владельца приложения и т.д.
Привет! Мы проверили наличие самого протокола, без погружения. И прошивки не обновляли. Думаю, тут только попробовать с ними связаться marketing@ttyinfo.com. Может смогут переадресовать на суппорт.
Давайте свернем это обсуждение, так как я не вижу в нем смысла. Я не знаю ни одного аналитика, который применяет в своей рутинной работе преобразование Фурье или фильтр Калмана. У меня есть большой опыт использования этих инструментов, но в совершенно других, инженерных задачах. Допускаю, что есть проекты, в которых это действительно необходимо (возможно, у вас как раз такой случай), но если говорить об общей массе — сомневаюсь.
Своё мнение по этому вопросу я высказала, ваше также услышала, но я с ним не согласна.
В конце концов, эта статья посвящена моему видению вопроса, основана на моем практическом опыте, никто не мешает написать вам свою :)
Так речь не о студенте. По тому, что я вижу, в основном от аналитиков просят выгружать данные простыми запросами (без требований в супер продвинутом уровне в SQL), анализировать на наличие выбросов, пропущенных значений и пр., трансформировать (объединять, группировать и т.д.) и анализировать в привязке к бизнес-задаче. Поэтому так или иначе работать все равно нужно с сырыми данными, никто их не приготовит за тебя. По результатам этого анализа нужно делать выводы и демонстрировать результаты команде/заказчику. Также часто аналитики общаются с коллегами/заказчиком для лучшего понимания данных. В некоторых случаях дополнительно просят умение строить классические ML-модели
В разных компаниях совершенно разные требования :) Да, знание математики очень важно, тем не менее на практике во многих вакансиях требования гораздо ниже того, что вы описали (по крайней мере на начальные позиции). Часто просто дают данные и просят подготовить отчет (например, в формате jupyter-notebook), где нужно проанализировать все с точки зрения бизнеса, например. На всякий случай оговорюсь, что в этой статье я не говорю о том, какие знания должны быть у аналитика (как и у дата-сайнтиста), я скорее говорю о том минимуме, который нужно пройти, чтобы иметь возможность начать проходить собеседования. И, разумеется, это не означает, что после получения оффера обучение заканчивается
Прежде всего, если у человека нет совсем никакого опыта (ни математики, ни программирования), лучше идти сначала на дата-аналитика, это будет куда проще и быстрее.
Но даже в этой ситуации, если человек сильно замотивирован, и хочет именно в data science и будет заниматься, то имхо полгода — это адекватное количество времени.
Мой кейс: мехмат + опыт программирования на С++ (сугубо с внутренними библиотеками работодателя) и некоторый опыт программирования на python (без ООП). У меня ушло на обучение где-то 2-3 месяца, но это с небольшими перерывами и при офисной работе с 8 до 17 с высокой загруженностью. У меня была мотивация, поэтому я ботала в метро, по вечерам и выделяла время на выходных. Потом я начала искать работу, проходить интервью и по их результатам что-то еще параллельно добивала. Всего на поиск работы у меня ушло около 2-х месяцев, но это был очень интенсивный процесс, в среднем где-то по 2 технических интервью в неделю.
На мой взгляд, куда хуже растягивать обучение на год или даже на годы, т.к. это очень длинная дистанция, можно легко потерять нить происходящего, выгореть и все забросить.
Питон — это настолько обширный язык программирования, что изучать его можно всю жизнь :) Все зависит от того, для чего вы его изучаете. Мне кажется, очень важно помнить, что Питон — это лишь инструмент, который используется для различных задач. По сути он представляет собой основы (что такое интерпретатор, какие есть типы и структуры данных, что такое стек вызовов, пространства имен и области видимости, элементы ООП) и большое количество библиотек и фреймворков. Например, для того, чтобы заниматься разработкой высоконагруженных сервисов, необходимо уметь работать с одним набором инструментов (многопоточность, работа с REST API запросами и пр.), для data science или для аналитики данных будут совершенно другие библиотеки (анализ данных, рисование графиков, обучение моделей). Например, если взять ту же биоинформатику — там настолько специфические инструменты, что смысла их изучать без особой необходимости совершенно нет. Поэтому при изучении Питона важно разобраться с основами и сконцентрироваться на том наборе библиотек и фреймворков, который нужен для достижения желаемой цели. Еще я бы здесь обратила внимание на то, что ты никогда не выучишь все и сразу, часто обучение происходит итерационно — сначала появляется первое понимание происходящего, потом оно уточняется с появлением нового опыта, и это может происходить на протяжении многих лет. Поэтому очень важно сдерживать себя и не пытаться выучить сразу все досконально, это не получится и всегда будут какие-то белые пятна, в которые можно углубляться.
Насчет оценки времени, полутора месяцев для изучения основ в первом приближении, на мой взгляд, вполне достаточно (хотя, разумеется, копать глубже можно очень долго). Конечно, это индивидуально, кто-то справится и за неделю (лично знаю такие истории), кому-то потребуется больше времени. Но здесь я бы обратила внимание на то, что очень важно отслеживать прогресс. Если есть понимание, что ты топчешься на месте, то имеет смысл обратиться за помощью. Можно написать в тематические чаты, можно поискать ментора (например, на https://getmentor.dev/ есть менторы, которые дают бесплатные консультации).
Что касается Git и Docker, опять же, всё зависит от целей. В посте я рассматриваю изучение этих инструментов для дата-сайнтистов, не для разработчиков и не для дата-инженеров/MLOps-ов. Чтобы понять концепцию систем контроля версий, принцип работы Git, основные понятия (что такое репозиторий, как делать коммиты, работа с ветвлением, слияние веток) и команды, уйдет максимум неделя (это еще и с практикой). То же самое с докером. Чтобы понять, что такое докер-файл, докер-образ, как создается контейнер, базовые команды для запуска контейнера — на это уйдет неделя. Разумеется, если погружаться глубже, начать писать самостоятельно докер-файлы и погружаться в оркестрацию контейнеров, то тут потребуется гораздо больше времени, но для джуновской DS-позиции это не нужно.
Разумеется, это не полные университетские курсы мат. анализа и линейной алгебры, даже не близко к этому :) но за пару недель действительно можно в первом приближении разобраться с самыми базовыми понятиями — с дифференцированием, векторно-матричными операциями, функциями многих переменных, понятиями градиента и матрицы Гессе, с постановкой задачи оптимизации и пр. В дальнейшем, конечно, было бы неплохо посмотреть уже полные курсы, которые есть в свободном доступе в большом количестве, просто это займет значительное время и не является необходимым условием для понимания ML-алгоритмов . Что касается SQL, изучить синтаксис и разобраться, как делать выгрузки из БД, как объединять таблицы, что такое primary/secondary key, чем отличаются разные join-ы — это дело пары дней, особенно если есть опыт работы с библиотеками типа pandas. Ну неделю можно еще порешать задачки, просто чтобы руку набить. Все равно на реальной работе будет своя специфика, к которой надо будет адаптироваться и что-то дополнительно гуглить, поэтому, на мой взгляд, тратить очень много времени на SQL не стоит. Хотя что касается сроков обучения — тут все сугубо индивидуально, все люди разные, я оцениваю ситуацию для эдакого сильно замотивированного человека в вакууме, обобщая мой личный опыт и опыт моих знакомых :)
Как по мне, для первого погружения в тему курс неплохой. Если посоветуете альтернативные и качественные курсы по Python — будет здорово.
Так как на прошлом месте работы я была помощником HR и выполняла многие его функции, мне казалось, что у меня может получится попасть в ИТ на должность младшего HR или помощника HR. Но поговорив с сотрудниками, занимающимися подбором персонала в ИТ-сфере, я поняла, что это намного сложнее, что есть определенная специфика и требуется больше опыта, чем у меня было на тот момент.
Перезалили скрины