Попробуйте еще разок сейчас. Там были небольшие проблемы, но теперь все должно быть ок — как раз в том числе и подобные вещи тестирование помогает исправить на будущее
Большое спасибо, за высокую оценку! Мы рады, что добавили свою копеечку в общее дело! Насчёт Jenkins. В 2014 году мы не стали рисковать пересаживаться на опен-сорс решения в виде Jenkins – в то время, нам показалось, что может быть множество проблем с обновлениями самого Jenkins, его поддержкой и многочисленных плагинов, которые нам были нужны. Также, в то время были не очень хорошие отзывы о нём со стороны инженеров. Которые работали с ним более плотно, а TeamCity очень хорошо себя показал на пилотных испытаниях проектов, продемонстрированных тем, кто принимал тогда решение о его использовании.
Насчёт легаси. Как и у всех достаточно крупных компаний, есть оно и у нас, но, что касается CI/CD инфраструктуры – его у нас минимально: из «старья» на поддержке остался только 1 сборочный сервер, со своей самописной CI-системой. Всё остальное было переведено на новые рельсы, описанные в статье. Сборочные сервера у нас имеются различных типов с различными ОС, это зависит от требований разработчиков, собирающих тот или иной модуль. На каждом из них стоит сборочный агент, поэтому проблем с их дружбой с текущей CI-системой не возникает.
К сожалению, сейчас прокомментировать что-то по сценариям использования Kubernetes для DevOps-задач я не могу, т.к. активно он в нашей команде не применяется. Возможно, в статье нужно было уточнить, что Kubernetes используется в разработке (dev+test) некоторых наших продуктов, которым мы помогаем, но не непосредственно нами. Подробнее про эти продукты я пока рассказать не могу.
Спасибо за вопрос. Возможно я повторюсь, но мне кажется, в статье я уже подробно ответил на него:
«На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, и лишь затем его провели полностью. Основная причина — необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог.»
К этому могу добавить только то, что это был 2014 год (когда мы искали замену CI на базе TFS), а что-то вменяемое для CI на базе GitLab начинает появляться только сейчас. Мы тоже сейчас экспериментируем с GitLab-CI и переводом «простых» сборок на него, но TeamCity, всё-таки, сейчас гораздо приятнее внешне и мы хорошо отладили в нём масштабирование наших сборочных проектов. Можно долго спорить по этому поводу, но для больших многокомпонентных продуктов сейчас GitLab-CI ещё не очень удобен в эксплуатации. Но мы не теряем надежды на переезд в GitLab-CI и, кроме того, с помощью инструмента CrossBuilder мы надеемся сохранить и перенести все наши скриптовые наработки для TeamCity-метараннеров (которых у нас уже несколько сотен) в GitLab-CI.
Я удивился, увидев такой ваш комментарий. Возможно, возникло какое-то недопонимание сути статьи. Более того, когда-то я с удовольствием прочитал вашу статью про девопс. Ещё раз перечитав её, я не нашёл противоречия с нашей: у нас нет ни «отдела девопс из 35 человек», мы не «нанимаем сисадминов с кучей доп.компетенций», и в то же время мы и пытаемся в нашей большой компании создать и внедрять «простые работающие решения». Кроме того, мы уже 4й год, также как и описывали вы в своей статье, работаем в направлении взаимодействия между разработчиками, тестировщиками и ИТ-службами. За что отвечает наша служба автоматизации и какие на неё возложены роли, мы честно и подробно написали в 3-4-5 абзацах статьи.
Что касается названия «Open DevOps Community» и всего прочего – да, частично согласен, возможно мы немного поспешили с его анонсом. Но с другой стороны – где нашим парням выкладывать свой код? Кроме того, опять же, почему «Tools, best practices and examples for the open community of automation engineers» — это перебор? Если мы именно это и хотим сделать в итоге, то зачем писать что то другое? А как бы вы предложили назвать? Кроме того, как я и написал в статье, проект фактически только стартовал и не претендует на мега-систему девопса и истину в последней инстанции. Будем развиваться потихоньку.
Спасибо! Постараемся довести их до ума в следующем году. PS/ Надо же, я удивился увидев, что когда то читал и использовал вашу статью про гугл-апи – она была полезной.
Не совсем так, ME встроен в PCH и на большинстве платформ. Но начинает функционировать до старта основного процессора в момент появления дежурного напряжения.
2. В книге Platform Embedded Security Technology Revealed, которая описывает внутренне устройство Intel ME заявляется, что доступ к коду модулей не должен компрометировать систему и не считается угрозой безопасности.
Поскольку первым начал использовать такие суффиксы великий русский писатель Николай Семенович Лесков («смолевые непромокабли» в рассказе «Левша» 1881 года), мы решили, что нам тоже можно.
И кстати, это именно суффикс, а не приставка, если вы так щепетильны к языку. Приставка располагается перед корнем, а не после него.
Большинство наших исследований связаны как раз с аудитом безопасности клиентов, включая и финансовые учреждения. В данной статье приведен общий пример анализа, но как правило мы показываем такие вещи именно конкретным организациям.
Защитники железной дороги (IBM) опубликовали свой обзор — взломать их не смогли, но атаки были (включая физические):
https://habrahabr.ru/company/ibm/blog/331672/
>вероятно, больше является вайпером, а не шифровальщиком
Когда вы пишете столь уверенные наезды на экспертов, лучше избегать красивых, но неточных терминов.
Вирус подменяет MBR и затирает следующие за ним 18 секторов, заменяя их на собственный загрузчик.
Предположительно, в этих секторах не должно быть ничего важного для пользователя.
Файлы пользователя шифруются обратимо при условии наличия приватного ключа RSA. Поэтому термин «шифровальщик» вполне корректен.
Короткий ответ — «чтобы начальнику было удобно смотреть из кабинета» :)
На самом деле, в конкурсе моделировались реальные ситуации, с которыми наши эксперты регулярно сталкиваются. Доступность АСУ ТП через Интернет — не такая уж редкость. Вот статистика нашего последнего исследования: более 160 тыс. систем доступны, четверть из них — системы автоматизации зданий и управления электроэнергией. Подробнее исследование тут:
https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/ICS-Security-rus.pdf
Насчёт легаси. Как и у всех достаточно крупных компаний, есть оно и у нас, но, что касается CI/CD инфраструктуры – его у нас минимально: из «старья» на поддержке остался только 1 сборочный сервер, со своей самописной CI-системой. Всё остальное было переведено на новые рельсы, описанные в статье. Сборочные сервера у нас имеются различных типов с различными ОС, это зависит от требований разработчиков, собирающих тот или иной модуль. На каждом из них стоит сборочный агент, поэтому проблем с их дружбой с текущей CI-системой не возникает.
К этому могу добавить только то, что это был 2014 год (когда мы искали замену CI на базе TFS), а что-то вменяемое для CI на базе GitLab начинает появляться только сейчас. Мы тоже сейчас экспериментируем с GitLab-CI и переводом «простых» сборок на него, но TeamCity, всё-таки, сейчас гораздо приятнее внешне и мы хорошо отладили в нём масштабирование наших сборочных проектов. Можно долго спорить по этому поводу, но для больших многокомпонентных продуктов сейчас GitLab-CI ещё не очень удобен в эксплуатации. Но мы не теряем надежды на переезд в GitLab-CI и, кроме того, с помощью инструмента CrossBuilder мы надеемся сохранить и перенести все наши скриптовые наработки для TeamCity-метараннеров (которых у нас уже несколько сотен) в GitLab-CI.
Что касается названия «Open DevOps Community» и всего прочего – да, частично согласен, возможно мы немного поспешили с его анонсом. Но с другой стороны – где нашим парням выкладывать свой код? Кроме того, опять же, почему «Tools, best practices and examples for the open community of automation engineers» — это перебор? Если мы именно это и хотим сделать в итоге, то зачем писать что то другое? А как бы вы предложили назвать? Кроме того, как я и написал в статье, проект фактически только стартовал и не претендует на мега-систему девопса и истину в последней инстанции. Будем развиваться потихоньку.
2. В книге Platform Embedded Security Technology Revealed, которая описывает внутренне устройство Intel ME заявляется, что доступ к коду модулей не должен компрометировать систему и не считается угрозой безопасности.
И кстати, это именно суффикс, а не приставка, если вы так щепетильны к языку. Приставка располагается перед корнем, а не после него.
https://habrahabr.ru/company/ibm/blog/331672/
https://habrahabr.ru/company/pt/blog/331962/
Проверили на одной из железок. Он затер GPT, но диск с Windows (загрузились с него) позволил восстановить его из резервной копии.
Когда вы пишете столь уверенные наезды на экспертов, лучше избегать красивых, но неточных терминов.
Вирус подменяет MBR и затирает следующие за ним 18 секторов, заменяя их на собственный загрузчик.
Предположительно, в этих секторах не должно быть ничего важного для пользователя.
Файлы пользователя шифруются обратимо при условии наличия приватного ключа RSA. Поэтому термин «шифровальщик» вполне корректен.
Если эта библиотека носит название perfc.dat, то должен присутствовать файл C:\Windows\perfc
https://github.com/ptresearch/Pentest-Detections/tree/master/WannaCry_Petya_FastDetect
На самом деле, в конкурсе моделировались реальные ситуации, с которыми наши эксперты регулярно сталкиваются. Доступность АСУ ТП через Интернет — не такая уж редкость. Вот статистика нашего последнего исследования: более 160 тыс. систем доступны, четверть из них — системы автоматизации зданий и управления электроэнергией. Подробнее исследование тут:
https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/ICS-Security-rus.pdf