Неизбежные изменения, произошедшие с DevOps с начала пандемии, породили дискуссии среди специалистов о новых стандартах и требованиях в этой профессиональной сфере.
Естественно, *инстинктивные инструменты как часть вашего проекта "Техпора" , не смог обойти эту горячую тему и собрал экспертов из разных компаний, чтобы рассказать о том, как изменилась работа специалистов DevOps, какие новые требования появились к новичкам и их последующий рост. Звучало в обсуждении на YouTube В этом тексте мы собрали экспертные высказывания.
В беседе приняли участие руководитель отдела DevOps Advocacy, Developer Advocate, JFrog, ведущий подкаста DevOpsSpeakeas. Барух Садогурский , руководитель SRE Flocktory, руководитель программного комитета Devopsdays Москва, организатор Devops Moscow митапа Дмитрий Зайцев , старший архитектор безопасности, Microsoft Виктория Алмазова и лидер сообщества DevOps Минск, системный архитектор Виктор Ведмич .
Фото с сайта Pixabay.
Потребность в автоматизации вышла на первый план
Барух Садогурский.На первый план вышла потребность в автоматизации.
Это стало такой болью, что подтолкнуло развитие технической части, связанной с DevOps. По нашим наблюдениям, все очень сильно изменилось, так как работать руками стало больнее и труднее.
Как в прямом смысле — это значит пойти и «пинать» сервер, так и то, что касается доступа ко всяким средам, менее доступным удаленно.
Все это привело к тому, что люди стали больше беспокоиться об автоматизации всего, что можно.
Виктор Ведмич.
У меня был случай, когда заказчик развернул производство только из офиса.
А ребята, которые работали в местном офисе, пришли в офис в субботу только для того, чтобы внедрить в производство.
Во время пандемии они были вынуждены сделать удаленный доступ к производству.
Барух Садогурский.
Один вариант — сделать удаленный доступ к продакшену, второй — прекратить развертывание вручную.
Это стимул работать над автоматизацией, пайплайном и всем, что является технической частью DevOps. 
Фото Google.com
Автоматизация требует повышения уровня знаний специалистов по безопасности
Виктория Алмазова.Многие специалисты по безопасности привыкли работать в «периметре».
И, конечно же, был спрос на безопасность.
Но оказалось, что безопасность нужно делать по-другому.
А это, в свою очередь, требует навыков автоматизации и повышения уровня знаний охранников, сидящих в «периметре» по 15-20 лет. А этих знаний у них просто нет, поэтому мы видим разные ситуации — либо открываем всё, либо устанавливаем VPN и другие решения, которые не работают. Есть также подход к восстановлению систем безопасности, но для восстановления безопасности нужно больше людей.
Появился, увеличился и будет продолжать расти спрос на новые решения в области безопасности.
Сейчас мы работаем удаленно, и это другой тип доступа и устойчивости.
А если мы начнем открывать доступ, то это вызовет больший интерес со стороны инициаторов хакерских атак.
И еще один момент. Чтобы содержать политику безопасности и настраивать межсетевые экраны, для обеспечения защиты требуется меньше ресурсов, чем потребовалось бы при автоматизации процессов.
Фото Google.com
Необходимо знать смежные области
Виктория Алмазова.По моему опыту, некоторые из лучших специалистов по безопасности в современном DevOps — это люди с опытом разработки и паранойей.
Знание смежных областей помогает понять суть задач и проблем.
Например, если сотрудник ранее работал над «бумажной» безопасностью и ему вдруг понадобится помочь разработчику, он не сможет посмотреть на задачу со своей точки зрения.
Барух Садогурский.
Проблема не в том, что он начнет помогать, а в том, что он не сможет помочь.
Специалисты по безопасности, имеющие юридическое образование, а не технологическое образование, имеют совершенно другое мышление.
У них все очень сложно в плане каких-либо изменений в сторону DevOps. 
Фото с сайта Pixabay.
Использование ИИ для автоматизации в DevOps не всегда возможно.
Барух Садогурский.
Хорошие разработчики и инженеры упрощают бизнес-проблемы до технологических проблем.
И этот процесс редактирования представляет собой сложнейшую познавательную задачу.
Если бы это было легко, каждый бы это сделал.
ИИ далек от этого.
С другими задачами, такими как понимание контекста и принятие правильного решения, он справляется гораздо легче.
Именно поэтому мне кажется, что ИИ идет туда и у него это получается все лучше и лучше.
Но в деле сведения бизнес-задач к технической абстракции нужен человек.
Виктория Алмазова.
В моем понимании бизнес – это немного творчества.
А как мы знаем, ИИ очень плох в творчестве.
Все говорят, что ИИ нацелен на автоматизацию задач, которые не интересны человеку и не требуют особой абстракции и творчества.
Барух Садогурский.
Автоматизация бизнеса — это не проблема DevOps, пусть ею занимаются стартаперы и другие предприниматели.
Мы стремимся свести бизнес-проблемы к техническим проблемам.
В DevOps всё меньше крутых старших инженеров
Виктор Ведимич.Мы получаем решения для разработки искусственного интеллекта, такие как Copilot, и начинаем использовать всю эту магию.
Но фундаментальных знаний нет. Я вижу, что крутых старших инженеров, которые не просто разбираются в инструментах, но и обладают фундаментальными знаниями, становится всё меньше.
Виктория Алмазова.
Меня начинает пугать то, что люди знают инструменты, но не знают лежащих в их основе концепций.
Давайте посмотрим на проблему с исторической точки зрения.
Если мы посмотрим на те же контейнеры, отмотаем на пару десятилетий назад и вспомним Linux и FreeBSD, там были тюрьмы, были chroot .
Расскажите современному человеку, что такое джейлы, что такое chroot — и он задумается.
Все знают, что такое контейнер.
Я работал с Amazon Cloud, а сейчас работаю с Azure и могу сказать, что знание этой концепции помогает очень быстро освоить новые инструменты.
Это как с языками: вы выучите первые три языка, а четвертый вам будет очень легко, потому что вы знаете конструкции и концепцию.
И мы приближаемся к тому, что начинаем все отдавать на аутсорсинг.
Не делает ли это нас очень слабыми людьми? Барух Садогурский.
Нет, он этого не делает. У нас глубокая специализация на сложных вещах.
И у нас есть взаимопонимание.
В США во время пандемии 10% жителей пошли подавать заявки на пособие по безработице, и старые системы, написанные на Коболе, оказались под ударом.
И возникла тенденция искать специалиста по программированию на Коболе любой ценой.
Ведь нужно было чинить системы.
Но эта тенденция продержалась два месяца, и теперь все системы переписаны, например на Java. Да, мы прочитали в новостях, что ищут программистов на Кобол, мы посмеялись, но это не значит, что Кобол будут использовать и дальше.
Одного инцидента с крахом системы и поиска специалиста достаточно, чтобы в будущем переписать систему на другой язык.
Учиться легче, когда тебе 17 лет, а не когда у тебя уже есть семья и кот.
Фото https://overclockers.ru/ Дмитрий Зайцев.
Если вы планируете расти, было бы хорошо вложить деньги в базу.
Кажется, в знания легче вкладываться, когда тебе 17 лет, а не когда у тебя уже есть семья и кот. Виктория Алмазова.
Я не призываю изучить всю историю информационных технологий и узнать, откуда взялся Linux. Я за знание понятия, основы.
Когда мне было 17, я потратил пару ночей, чтобы понять концепцию.
И теперь эти вложения окупаются, я очень быстро осваиваю инструменты.
Выходит новый продукт, но это всё то же «яйцо», только в другом цвете.
Да, с новыми возможностями, с автоматизацией, но освоить этот функционал гораздо быстрее.
Например, что касается средств безопасности, то сегодня специалисты очень часто имеют о них представление только с точки зрения того, куда нажать мышкой и какую команду написать.
Это по сравнению с теми, кто приходит и начинает изучать инструмент с нуля.
Люди просто не понимают, как работает инструмент, у них сразу возникает паническая атака, когда инструмент ведет себя не так, как описано в документации.
По своему опыту скажу, что понимание основ экономит время на обучение.
Если бы сейчас я начал с нуля и пошел работать DevOps-инженером, то у меня возник бы резонный вопрос — с чего начать, куда смотреть? Инструментов и направлений очень много.
Даже у Amazon или Azure есть более 600 сервисов.
Это не дает повода для энтузиазма, глаза разбегаются и непонятно, с чего начать работать в DevOps, чтобы учиться и быть в тренде.
Дмитрий Зайцев.
Новичкам я бы посоветовал обращаться в компании, которые предлагают стажировки.
Как правило, это крупные аутсорсинговые компании или банки.
Но после стажировки нужно не забыть «пойти» в технологическую компанию, которая умеет делать проекты хорошо и быстро.
Новички должны иметь знания Linux
Барух Садогурский.У нас есть много хороших ресурсов для новичков в DevOps. Поставщики облачных услуг заинтересованы в новичках в DevOps, и у них есть хорошие ресурсы для начала работы.
Их решения очень удобны для пользователя, ими приятно пользоваться и начинать работу.
Да, вам понадобятся некоторые решения для Linux, но достаточно немного знаний, и вы сможете их использовать.
Но начинать нужно с облачных решений.
Дмитрий Зайцев.
Мы часто ищем системных инженеров и проводим собеседования со многими людьми.
И я вижу, что у новичков должно быть знание Linux, знание хотя бы минимального курса Яндекс Кит по сетям и умение писать на Bash, Python и Go. Облака, конечно, хороший вариант. Провайдеры научат вас, как сделать системы лучше.
Но чтобы запустить сервер, вам нужно передать ему пользовательские данные, а это bash-скрипт. И кто-то должен это написать и знать, что вы пишете.
Ну, Linux — ключевой элемент. Всему остальному научиться легко, но понимание того, что взять из облака для решения проблемы, вторично.
Вы можете обратиться в техподдержку провайдера, и вам объяснят, как решить вашу проблему, пусть и с излишними знаниями.
Фото https://itsfoss.com/
Любая безопасность требует периодического аудита
Виктория Алмазова.Если бы вы спросили меня о лучших инструментах в рамках базового подхода к безопасности DevOps, я бы посоветовал сосредоточиться на SISD-конвейер с внедрением там таких инструментов, как сканирование управления пакетами.
Далее я бы рекомендовал использовать Sast (статический анализ безопасности) и Dust (динамический анализ безопасности).
Крайне важно сосредоточиться на том, какие пакеты и библиотеки мы используем в коде.
Это все собственные разработки и открытый исходный код, и лучше использовать инструменты безопасности, которые их сканируют. И не только ради безопасности, но и ради лицензии.
Мы часто забываем, что некоторые библиотеки с открытым исходным кодом имеют привычку менять лицензии.
И, соответственно, инструменты SaS также помогут отслеживать эти изменения и сканировать код на предмет безопасности и уязвимостей.
Dust Tools — это облегченная версия пентеста.
Конвейер CI/CD — это основа безопасности и качества.
Мы должны думать не только о том, что поставить в пайплайн, но и какие права имеет сам пайплайн и где, а также кто имеет право редактировать и запускать наш пайплайн.
Барух Садогурский.
Любая безопасность требует периодического аудита.
В моем понимании помимо необходимых новых проверок, которые добавляются в конвейер, должны быть еще люди, которые генерируют дополнительные проверки.
Напрашивается аналогия с QA, где, несмотря на то, что мы автоматизировали все тесты, у нас всё равно есть исследовательское тестирование.
Люди находят, где оно может сломаться и что нужно проверить.
Мне кажется, пентестеры примерно одинаковы в парадигме безопасности.
Теги: #информационная безопасность #DevOps #ci/cd #ИТ-индустрия #инстинктивные инструменты #технологии
-
Ноутбуки Делл
19 Oct, 24 -
Телевизоры Lg Electronics И Протокол Dlna
19 Oct, 24 -
Trove4J: Высокопроизводительные Коллекции
19 Oct, 24 -
Friendfeed Приближается К Web 3.0
19 Oct, 24 -
Просто Google Или Google У Вас На Ладони
19 Oct, 24
