Devops linux или windows

Devops linux или windows

So I’m currently a young Windows System Administrator, and my long term goal is becoming a DevOps Engineer.

I was wondering what the community feels about the differences of Windows vs Linux DevOps? I currently am in a good position to either dive myself into the world of Windows DevOps or Linux Devops.

The way I see it the pros for Windows is that its a new and unique take and something I already have a foothold in. I like what I see with the addition of new tools and the obvious push Microsoft is going towards making the OS more friendly towards it(DSC, and powershell). Though I get concerns with a lot of the other experienced admins, super GUI based only using old school commands, and ignoring powershell in general. It seems hard to push some of my ideas for automation or scripting when a lot of people scuff it away and seem to have a fear of scripting tasks or doing things in the command line.

Linux seems interesting to me, it has an established base in DevOps and automation. A Lot of the tools were based for Linux and has a strong base. I unfortunately only have the basics of Linux down and am still relatively novice with a lot of their mass configuration software.

Luckily, I’m in a position where I can basically practice my skills and try to move to the Linux department then from there move up to a DevOps position. On the other hand I have a firm grasp on the Windows side. My company has opportunitys on both the Linux and Windows side when it comes to DevOps and alot of ability to move to either one.

What do you guys think about the current state of each in respect to DevOps? Do I start learning my skills in the established DevOps movement or try to position myself in the Windows side that’s relatively new and fledgling?

Источник

Современный DevOps и Linux как ключевой элемент

Неизбежные изменения, которые произошли с DevOps с началом пандемии, стали поводом для обсуждений специалистами новых стандартов и требований в этой профессиональной сфере. Естественно, *instinctools в рамках своего проекта «Техпора», не могла пройти мимо этой горячей темы и собрала экспертов из разных компаний, чтобы поговорить о том, как изменилась работа специалистов в DevOps, какие появились новые требования к новичкам и их последующему росту. Прозвучавшие в дискуссии на YouTube высказывания экспертов мы собрали в этом тексте.

В разговоре приняли участие Head of DevOps Advocacy, Developer Advocate, JFrog, ведущий подкаста DevOpsSpeakeas Барух Садогурский, Head of SRE, Flocktory, глава программного комитета Devopsdays Moscow, организатор митапа Devops Moscow Дмитрий Зайцев, Senior Security Architect, Microsoft Виктория Алмазова и лидер сообщества DevOps Minsk, Systems Architect Виктор Ведмич.

Необходимость автоматизации вышла на первый план

Барух Садогурский. Необходимость автоматизации вышла на первый план. Она стала такой болью, что подтолкнула развитие технической части, которая связана с DevOps. По нашим наблюдениям, все изменилось очень сильно, поскольку руками работу стало делать больнее и тяжелее. Как в прямом смысле — это пойти и «пнуть» сервер, так и то, что касается доступа ко всяким средам, которые удаленно менее доступны. Это все привело к тому, что люди стали больше заботиться об автоматизации всего чего только можно.

Виктор Ведмич. У меня был кейс, когда заказчик деплоил в продакшен только из офиса. И ребята, которые работали в локальном офисе, приходили в офис в субботу только для того, чтобы задеплоить в продакшен. Во время пандемии они были вынуждены сделать удаленный доступ к продакшену.

Барух Садогурский. Один вариант — это сделать удаленный доступ к продакшену, второй — перестать деплоить руками. Вот это и есть стимул работать над автоматизацией, pipeline и всем, что является технической частью DevOps.

Автоматизация требует повышения уровня знаний у безопасников

Виктория Алмазова. Очень многие безопасники привыкли работать в «периметре». И конечно же, возник спрос на секьюрити. Но оказалось, что секьюрити нужно делать как-то по-другому. А это, в свою очередь, требует навыков автоматизации и повышения уровня знаний у безопасников, которые по 15-20 лет сидели в «периметре». И этих знаний у них просто нет, поэтому мы видим разные ситуации — либо все открываем, либо ставим VPN и прочие решения, которые не работают. Есть еще подход с перестроением систем безопасности, но чтобы перекроить безопасность, нужно больше людей.

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

Надо знать смежные области

Виктория Алмазова. На моем опыте, одни из самых лучших безопасников в современном DevOps — это люди с бэкграундом и паранойей разработчика. Знания смежных областей помогают понять суть задач и проблем. Например, если сотрудник сидел раньше на «бумажной» безопасности и вдруг ему потребуется помочь разработчику, то он не сможет взглянуть на задачу с его точки зрения.

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

Использовать AI для автоматизации в DevOps можно не всегда

Барух Садогурский. Хорошие разработчики и инженеры упрощают бизнес-задачи до технологических задач. И вот этот процесс редакшена — это самая сложная когнитивная задача. Если бы это было просто, все бы это делали. Вот до этого AI дико далеко. С остальными задачами, как, например, понять контекст и принять правильное решение, — он справляется намного проще. Именно поэтому мне кажется, что туда AI идет и он уже в этом все лучше и лучше. А вот в вопросе сведения бизнес-задач к технической абстракции нужен человек.

Виктория Алмазова. В моем понимании бизнес — это немного творчество. А как мы знаем, AI очень плох в творчестве. Все говорят, что AI нацелен на автоматизацию задач, которые не интересны человеку и не требуют много абстракции и творчества.

Барух Садогурский. Автоматизация бизнеса — это не вопрос DevOps, пусть с ним разбираются стартаперы и прочие предприниматели. Мы занимаемся сведением бизнес-задач к техническим задачам.

Крутых senior-инженеров в DevOps все меньше и меньше

Виктор Ведимич. У нас появляются AI-решения для разработки, например Copilot, и мы начинаем пользоваться всей этой магией. Но при этом нет фундаментальных знаний. Я вижу, что все меньше и меньше становится крутых senior-инженеров, которые не просто разбираются в инструментах, а имеют фундаментальные знания.

Виктория Алмазова. Меня начинает пугать тот факт, что люди знают инструменты, но не знают, какие концепты, стоят за ними. Давайте посмотрим на вопрос с точки зрения истории. Если мы глянем на те же контейнеры, отмотаем на пару десятков лет назад и вспомним Linux и FreeBSD, там же были джейлы, там же был chroot. Современному человеку скажи, что такое джейлы, что такое chroot — и он задумается. Все знают, что такое контейнер. Я работала с Amazon Cloud и сейчас работаю с Azure и могу сказать, что знание концепта помогает очень быстро выучить новые инструменты. Это точно как с языками: ты выучишь первые три языка и четвертый у тебя пойдет очень легко, ведь ты знаешь конструкции и концепт. А мы идем к тому, что начинаем все аутсорсить. Не делает ли это нас очень слабыми людьми?

Барух Садогурский. Нет, не делает. У нас есть глубокая специализация в сложных вещах. И у нас есть понимание. В США во время пандемии 10% жителей пошли оформлять пособие по безработице, и старые системы, написанные на Cobol, попадали. И проявился тренд поиска специалиста программирования на Cobol за любые деньги. Ведь нужно было чинить системы. Но этот тренд продлился два месяца, и сейчас все системы переписаны, например на Java. Да, мы почитали в новостях, что ищут программистов на Cobol, посмеялись, но это не значит, что Cobol будет использоваться и дальше. Достаточно одного инцидента с падением систем и поиском специалиста, чтобы в будущем переписать систему на другом языке.

Учиться легче, когда тебе 17 лет, а не когда уже есть семья и кот

Дмитрий Зайцев. Если ты планируешь вырасти, то хорошо бы инвестировать в базу. Кажется, что инвестировать в знания легче, когда тебе 17 лет, а не когда уже есть семья и кот.

Виктория Алмазова. Я не призываю изучать всю историю IT и знать, откуда появился Linux. Я за знание концепта, базиса. Я в 17 лет инвестировала пару ночей, чтобы разобраться в концепте. И сейчас эти инвестиции окупаются, я очень быстро учу тулзы. Выходит новый продукт, но это все то же «яйцо», только в другом цвете. Да, с новыми фишками, с автоматизацией, но изучение этого функционала дается значительно быстрее. Например, что касается инструментов для обеспечения безопасности, то сегодня специалисты очень часто имеют представление о них только в части, где кликнуть мышкой и какую команду написать. Это если сравнивать с теми, кто приходит и с нуля начинает учить какой-то инструмент. У людей просто нет понимания, как инструмент работает, у них паническая атака сразу, когда инструмент не ведет себя так, как описано в документации. Исходя из моего опыта, я скажу, что понимание базиса позволяет сэкономить время на обучении. Если бы сейчас я начинала с нуля и пошла работать DevOps инженером, то у меня был резонный вопрос — с чего начать, куда смотреть? Очень много инструментов и направлений. Даже Amazon или Azure — это 600+ сервисов. Это не дает повода для энтузиазма, разбегаются глаза и непонятно, где начать работать DevOps, чтобы научиться и быть в тренде.

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

У новичков должны быть знания по Linux

Барух Садогурский. У нас есть много хороших ресурсов для начинающих DevOps. Облачные провайдеры заинтересованы в том, чтобы в DevOps приходили новички, и у них есть хорошие ресурсы для старта. Их решения очень дружелюбны к пользователю, их приятно использовать и с них начинать. Да, какие-то Linux решения понадобятся, но достаточно немного знаний — и ими можно будет пользоваться. Но начинать нужно с облачных решений.

Дмитрий Зайцев. Мы часто ищем себе системных инженеров и собеседуем много людей. И я вижу, что у новичков должны быть знания по Linux, знания хотя бы с минимального курса «Яндекс Кит» по сетям и умением писать на Bash, Python и Go. Облака, конечно, это хороший вариант. Провайдеры вас научат, как делать системы лучше. Но для того, чтобы запустить сервер, нужно ему отдать user-data, а это bash-скрипт. А его кому-то нужно написать и знать, что ты пишешь. Ну и Linux — это ключевой элемент. Все остальное легко учится, а понимание того, что взять в облаке для решения какой-то задачи, — вторичное. Можно обратиться в техническую поддержку провайдера, и там объяснят, как решить вашу задачу, пусть и с избыточными знаниями.

Любой безопасности нужен периодический аудит

Виктория Алмазова. Если бы меня спросили про лучшие инструменты в рамках базового подхода в безопасности для DevOps, то я бы посоветовала фокусироваться на sisd pipeline с имплементацией туда тулзов как package management scanning. Далее я бы рекомендовала использовать Sast (static security analysis) и Dust (dynamic security analysis). В обязательном порядке фокусироваться на то, какие пакеты и библиотеки мы используем в коде. Это все first party и open source, и лучше использовать security-инструменты, которые сканируют их. Причем не только на безопасность, но и на лицензию. Мы очень часто забываем, что некоторые open-source-библиотеки имеют привычку менять лицензии. И, соответственно, еще SaS-инструменты помогут отследить эти изменения и просканируют код на предмет безопасности и уязвимостей. Dust-инструменты это лайт версия пентеста. CI/CD pipeline — это сердце безопасности и качества. Надо не только думать, что положить в pipeline, но и над тем, какие права сам pipeline имеет и куда, а также кто имеет право редактировать и запускать наш pipeline.

Барух Садогурский. Любой безопасности нужен периодический аудит. В моем понимании, кроме необходимых новых проверок, которые добавляются в pipeline, должны еще быть люди, которые генерируют дополнительные проверки. Напрашивается аналогия с QA, где у нас, несмотря на то что мы автоматизировали все тесты, все равно есть exploratory testing. Люди находят, где может сломаться и что нужно тестировать. Мне кажется, что pen testers — это примерно то же самое в парадигме security.

Источник