×

Советы сеньоров: как прокачать знания junior DevOps

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

Олег Федотов, Engineer Level 2 в CoreValue

18 лет опыта в ІТ, из них 5 — в DevOps

Начнём с того, что изначально DevOps — это культура отношений между группами разработки и эксплуатации, а не профессия. И только со временем, естественным путём, DevOps переместился в разряд профессии — смеси таких навыков, как системное администрирование, программирование, использование облачных технологий и автоматизация инфраструктуры. При этом спектр используемых технологий настолько широк, что начинающему DevOps инженеру нужно быть готовым посвящать достаточно много времени их изучению. Ну а теперь давайте попробуем перечислить, что важно и что лежит в основе:

  • TCP/IP — очень важно понимать, как работает сеть (классический вопрос на собеседовании — Что на самом деле происходит, когда пользователь вбивает в браузер адрес google.com). Вот Cisco CCNA курс, достаточно именно TCP/IP раздела.
  • Linux (дистрибутив не имеет значения, главное — свежий). Лично мне очень помогло в своё время понимание, что происходит под капотом во время загрузки операционной системы. «Linux from Scratch», — наверное, лучшее из бесплатного, но придется с ней повозиться.
  • Python — наверное, самый простой в изучении и одновременно самый востребованный язык в мире DevOps и не только.
  • AWS — облачная инфраструктура, которая очень сильно упрощает жизнь DevOps инженеру, беря на себя огромную часть рутинных задач. При этом так называемый AWS Free Tier даёт возможность новичкам абсолютно бесплатно пощупать львиную долю сервисов. Для меня идеальным в изучении оказался курс AWS Certified Solutions Architect — гайд к нему.

Это далеко не всё, но достаточно для уверенного старта. А впереди Docker, Ansible, Jenkins и пр. — это те технологии, изучать которые будет намного легче, освоив базу. А дальше ITIL, DevOps методологии и еще много-много интересного и важного. И я нарочно не упомянул Windows! Я считаю, что освоив Linux, освоить Windows будет куда легче, но не наоборот.

Дмитрий Замаруев, Technical Director, Cloud Solutions в Grid Dynamics

Более 14 лет опыта в ІТ

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

Наиболее часто компании на позицию «DevOps Engineer» ищут людей, которые будут отвечать за CI/CD инфраструктуру для проекта/компании, заниматься доставкой приложений (deployment engineer) или автоматизировать создание инфраструктуры (infrastructure engineer). Это все самодостаточные отдельные специализации, о каждой из которых можно долго говорить.

Попробуем обобщить знания, которые помогут инженеру начать разбираться в этих областях. DevOps охватывает много определений: это и continuous delivery (CI/CD), и infrastructure automation, и configuration management:

  • Совсем базовые знания — Computer Science. Любая работа в области информационных технологий подразумевает базовые знания в области компьютерных наук. Если в институте этот предмет «не зашел», то можно посмотреть курс CS101 от Stanford University — он находится в свободном доступе и дает хорошее понимание основ.
  • Scripting basics — без написания скриптов в век тотальной автоматизации никак не обойтись, поэтому не нужно бояться командной строки и написания собственных скриптов. Если что-то нужно сделать больше, чем один раз, это нужно автоматизировать.
  • Для тех кому мир Linux Shell совсем не известен: Intro to Bash, Bash scripting tutorial.
  • CI/CD — непрерывная интеграция и доставка приложений сейчас тесно связана с понятием DevOps, поэтому необходимо понимать, что это такое и для чего нужно. Концепция отлично описана в книге Фаулера «Continuous Delivery». Если книгу не достать, то основные концепции описаны у автора на сайте (сайт вообще весь хороший, советую прочитать от и до).
  • Инструментарий для непрерывной интеграции довольно разнообразный, но лидирует с большим отрывом Jenkins, поэтому советую начать изучение именно с него. Вместе с этим крайне желательно ознакомиться с системами сборки тех языков, с которыми планируется работать, так как это одна из точек соприкосновения с разработчиками (Maven/Gradle/sbt/CMake etc.).
  • Clouds — современная инфраструктура уже давно вышла за пределы дата-центров. Поэтому без опыта/знаний облачных провайдеров сейчас мало что можно сделать. Благо крупные провайдеры предоставляют пробные периоды на доступных условиях и попробовать, что такое облако, можно легко. А главное, что бесплатные планы можно использовать для изучения различных инструментов и оттачивания навыков.
  • AWS предоставляет 1 год использования некоторых типов ресурсов совершенно бесплатно (но нужно настроить оповещения на возможную оплату, так как доступны и платные ресурсы, которые по незнанию можно случайно запустить).
  • Google Cloud дает кредит $300 сроком на один год на любые ресурсы — этого вполне достаточно для обучения.
  • Microsoft Azure — $200 на месяц — немного по времени, но достаточно, если нужно просто познакомиться с системой.
  • Infrastructure automation — автоматизация создания инфраструктуры тесно переплетается с понятием infrastructure-as-a-code. Описание инфраструктуры кодом пытается решить проблему повторяемости, тестирования и ревью, то есть применить принципы CI/CD для уровня инфраструктуры (ссылка на Фаулера).
  • Из инструментария наиболее популярными, наверное, являются поделия-на-коленке и Terraform — к нему-то и стоит присмотреться.
  • Configuration management — создание повторяемой и предсказуемой настройки системы/приложений. Также большинство инструментов из этой области могут использоваться для автоматизации доставки приложений (deployment automation). Изучение стоит начать с Ansible, так как у него ниже порог вхождения. Но также следует его сравнить с похожими инструментами, такими как Chef и Puppet.

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

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

Евгений Волченко, DevOps Engineer в Luxoft Ukraine

12 лет в IT, 5 лет опыта в DevOps

3 must-have навыка

Хороший DevOps специалист должен свободно себя чувствовать с людьми, с которыми работает. Развитые soft skills однозначно этому поспособствуют. Общение со специалистами разного профиля в ежедневной деятельности требует развитых коммуникативных навыков. Потому если вам сложно коммуницировать — начинайте развивать этот навык с первых дней работы, научиться этому можно.

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

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

Чего делать не надо

DevOps команда всегда в меньшинстве, а на небольших проектах это и вовсе один человек. Поэтому не стоит ставить себя выше других и считать себя единственным и неповторимым носителем знаний, недоступных другим. Нужно общаться с командой и определять ее приоритеты, понимать, как удобнее для всех взаимодействовать, как оптимизировать работу и быть единым целым. Поэтому не рекомендую опираться лишь на теорию, выловленную из книг и статей, и пытаться ее навязать своим коллегам, а прислушиваться к чужим словам и делать выбор, исходя из потребностей команды. На ранних этапах вашей карьеры — уж точно :)

Тем не менее даже начинающий специалист должен быть достаточно твердым в своих решениях и не идти на поводу всех просьб и предложений коллег по проекту. Нужно находить некий баланс между командным духом и best practices, прочитанными в книгах, хоть это и непросто.

Снова же, из-за того, что DevOps специалистов на проектах зачастую не больше одного, возникает некий вакуум общения с коллегами, интересующимися девопс-направлением и технологиями. Несмотря на противоречивое отношение к профильным мероприятиям, я рекомендую не пренебрегать ими. Митапы, конференции — все это подойдет, особенно, на первых этапах. Как я говорил, DevOps должен сам заниматься своим развитием, иногда даже больше, чем другие специалисты. Программистам разного профиля проще найти более опытных коллег, которые направят и подскажут, даже в рамках одного проекта. По опыту добавлю, что не стоит игнорировать и навыки программирования. Знание архитектуры Web-приложений и умение работать с Rest API точно пригодятся.

Что почитать

С первой книгой начинающим DevOps’ам повезло — она написана в художественном стиле и вряд ли когда устареет. Это «The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win» авторства Gene Kim. Для понимания этапов и процессов в production рекомендую «Site Reliability Engineering: How Google Runs Production Systems» Niall Richard Murphy. И книга по программированию — «Go in Practice: Includes 70 Techniques», автор — Matt Butcher. Чтобы быть успешным DevOps специалистом, нужно уметь программировать хотя бы на базовом уровне.

Антон Чудаев, TeamLead DevOps в V.I.Tech

8 лет опыта в Ops + 4 года в DevOps

В DevOps часто приходят либо из программистов (Dev), либо из админов (Ops). Так получается, что это смесь и культура разных направлений, поэтому и изучать новые технологии DevOps инженеру приходится быстрее, чем рядовому айтишнику. Еще накладывается зависимость от конкретных технологий, используемых в проекте. Я советую изучить хотя бы одну тулзу в каждой области, а уже потом расширять и углублять знания по мере необходимости.

Публичные облака. Вычислительные ресурсы — это основа, на которую дальше все накладывается. Если выбор пал на «Амазон» (как в большинстве случаев), то дождитесь скидки и купите курс по AWS за 10$. Он даст общее представление о сервисах и ресурсах. Для автоматизации развертывания и поддержки инфраструктуры (Infrastructure-as-Code) используйте нативный для AWS CloudFormation — будет проще начать и всегда up-to-date. Если не «Амазон» или не желаете вендор-лока, то используйте Terraform.

После того как «сетку раскинули», инстансы подняли, нужно упаковать аппликацию. Тут нам помогает контейнеризация. В этой области правит Docker. Начните с простого создания имиджей и деплоя контейнеров и уже по мере запросов от бизнеса переходите к кластеризации и сервисам в Kubernetes.

Чтобы управление и настройка сервера/сервисами были прозрачными и стандартизированными, используйте тулзы для config-менеджмента. Мой фаворит, особено для начинающих — Ansible. Изучайте примеры на Ansible Galaxy и пробуйте модифицировать их на своих рутинных задачах. Из альтернатив — SaltStack или Chef.

Уже построенный work-flow сборки, тестирования и деплоя нужно упаковать и красиво визуализировать с помощью пайплайнов, например вот пайплайн для Дженкинса. Это поможет масштабировать процессы на разные энвайронменты.

Мониторинг. Следить и поддерживать сервисы поможет, если еще не внедренный, старичок Zabbix. Также посмотрите на более новые: Prometheus или TICK Stack.

Главная задача девопса — ускорение доставки продукта от бизнеса до потребителей. Автоматизация — это только одно из основных средств, а не самоцель. CI/CD, blue-green, Phoenix, Canary Deployments — это тоже средства, которые возникают по мере необходимости. Чтобы это почувствовать, понять философию DevOps культуры, помогут классические книги:

При этом всегда нужно «смотреть в завтрашний день» и следить за новинками, но не перегружать бизнес гонкой за трендами, если он пока еще не дорос до таких потребностей.

Чтобы быть в курсе новостей, читайте дайджесты и статьи на DOU и подписывайтесь на телеграм-каналы:

Hints&tips

Не выдумывайте велосипеды, поищите популярные решения для задач, так будет проще суппортить не только вам.

Не усложняйте — делайте код понятный и простым, чтобы даже новичок смог быстро разобраться. DevOps — это команда, а не единый супермозг.

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

Внедряйте новые технологии только при действительном их эффекте в будущем. Ошибка на уровне архитектуре самая дорогая.

Сергей Марченко, Head of IT Department в Dev-Pro

6 лет опыта в IT

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

Мой план с рекомендациями, как освоить специальность:

Сначала Ops, потом Dev

Заказчики постоянно беспокоятся про uptime, безопасность, в общем, обычный IT Operations никуда не делся. Поэтому сначала понадобятся хорошие знания системного администрирования, troubleshooting и поиск bottlenecks. Infrastructure as a code, CI/CD и прочее стоит рассматривать как продолжение карьеры системного администратора, а не отдельный путь.

Не стоит становиться человеком, который разворачивает инфраструктуру MySQL High Availability на Ansible, не понимая, как работает репликация. Что уж там, иногда даже процесс резервного копирования базы вызывает вопросы. Изучайте основы networking, Linux/Windows, web servers (NGINX, Apache), DBs, monitoring и только потом DevOps практики.

Clouds

DevOps почти равно Clouds. Поэтому стоит разобраться хотя бы с одним Cloud Provider — AWS, Azure, Google Cloud Platform. У AWS можно зарегистрировать Free Tier, которого достаточно, чтобы познакомиться с этой платформой.

Automation

Во время изучения Cloud Platforms стоит обратить внимание на Configuration Management and Provisioning Tools. Я бы рекомендовал Ansible и Terraform. Вместе с изучением Terraform советую смотреть на контейнеры, Docker, Kubernetes — это позволит лучше понять сильные стороны Provisioning Tools.

Копайте вглубь

Важно, чтобы после лабораторной, тестового задания, PoC, работы на проекте не осталось открытых вопросов. Подходите системно: выписывайте вопросы, потом обсуждайте с коллегами, читайте литературу. Главная цель — полное понимание происходящего. Почему выбрали тот или иной инструмент, почему именно так написали код — у вас должны быть ответы на эти вопросы.

Пишите код

Кроме кода, который необходимо писать для разворачивания новой инфраструктуры, стоит подумать про написание своего приложения. Тут поможет какой-нибудь Pet Project. Это может быть веб-сайт, чат-бот или IoT-приложение, которое доливает воду в кофеварку (в IТ-компаниях и не такое встретишь). Главное — глубже понять работу и проблемы разработчиков. Для написания такого приложения я бы предложил воспользоваться языком, который потом пригодится DevOps инженеру: Python или Golang в самый раз. В случае Go забудьте про книги, A Tour of Go — то, что вы ищите.

Читайте чужой код

Изучая Terraform, я подсмотрел tips and tricks, хорошие практики из Terraform Module Registry. Чтение чужого кода позволяет посмотреть другие практики и, если они окажутся лучше ваших, перенять их. Кстати, говоря о Terraform, я бы рекомендовал начать с Terraform: Up and Running.

Security

DevOps подходы ускоряют разворачивания инфраструктур и добавляют еще больше проблем для Security Engineers. Так что стоит сразу избавляться от простых ошибок, например, не класть ключи и секреты в открытом виде в version control, немного углубиться в тему security. Тут вам помогут ключевые слова DevSecOps, OWASP, Key Vault.

Сообщество

Когда вы определитесь со списком software, с которым вы работаете, стоит принимать активное участие в жизни продукта. Читать форумы (Stack Overflow), следить за обновлениями на GitHub, возможно, даже контрибьютить свой код.

Не решайте проблем, которых нет

AI, Big Data... в мире столько новых течений. Как тут удержаться и не внедрить что-то новенькое в свой проект. Мой совет — внедряйте только то, в чем вы действительно нуждаетесь, вы должны знать, какую проблему решаете. Большинство модных технологий вам не нужны или не подходят. You are not Google.

Максим Зинькевич, Lead Systems Engineer в EPAM Kharkiv

5 лет опыта в DevOps

DevOps нельзя выучить по книгам и курсам, а потом выйти на проект и сделать все классно. Практика и только практика может сформировать инженера в этом направлении. Нужно быть готовым, что придется прилагать много усилий и постоянно преодолевать себя, особенно в самом начале. Чем тяжелее в начале освоения профессии, тем легче на проектах.

Еще будучи студентом, я работал системным администратором в различных бизнесах. Начинал с Windows и Linux. Постепенно перешел к поддержке серверов и автоматизации. Когда я впервые использовал такие инструменты как Puppet, Jenkins, системы контроля версий (Subversion, Git), ко мне пришло осознание, что за гранью сисадминистрирования есть огромный мир DevOps. Чтобы двигаться дальше, я присоединился к EPAM. Именно тогда, 5 лет назад, в компании запускалось пилотное направление DevOps. Сейчас мы активно развиваем эту компетенцию внутри компании.

Опираясь на свой опыт, мои рекомендации начинающим специалистам будут выглядеть так:

  • Выбирайте работодателя и проекты, которые будут вас профессионально формировать. Все мои смены работы были продиктованы исключительно желанием развиваться. Как только чувствуете, что начинаете деградировать — меняйте работу.
  • Не бойтесь браться за новые или сложные проекты, которые выше вашего уровня. А лучше всего сразу подключаться к нескольким проектам. Такой активный режим очень поможет в прокачке практических знаний и навыков. Но не забывайте о балансе, чтобы быстро не перегореть.
  • Задавайте вопросы вашему ментору / лиду проекта / тимлиду. Если в течение двух дней вы не задали вопрос по тому, что вам непонятно — вы потеряли два дня в познании профессии, и кому-то придется переделывать вашу работу. Отбросьте стеснение, абсолютно все начинали так же, как и вы. Будьте инициативны и любознательны.
  • Учитесь на своих ошибках. Завершили проект — проанализируйте, что было сделано хорошо, а что можно и нужно улучшить. Подход continuous improvement должен стать неотъемлемой частью проектной работы.
  • Выучите или доучите такие несложные языки программирования, как Ruby и Python. Python и так давно уже используется в системном администрировании. Почему Ruby? Системы автоматизации Puppet и Сhef используют DSL, основанный на Ruby, поэтому некоторые тонкие вещи придется писать на этом языке. Хоть программирование в основном и функциональное, но без основ объектно-ориентированного программирования развиваться в DevOps будет сложно.
  • Следите за авторами и читайте профильные материалы на Habr и DZone. Там же есть подкасты и видео.
  • Пройдите обучающие курсы на Coursera и Codecademy.com.

На самом деле сейчас есть огромное количество ресурсов по теме DevOps, сложно посоветовать что-то конкретное. Главное — не останавливать процесс изучения новых технологий и закрепления актуальных.

За весь свой опыт работы я прочитал только одну книгу «Непрерывная интеграция» Jez Humble, David Farley. Она очень легко читается и будет понятна начинающим специалистам. Там еще используются примеры старого ПО, но все принципы будут актуальны и сегодня. Она мне помогла структурировать уже имеющиеся знания. Остальное же — практика, актуальные статьи по теме, документация и, конечно же, коллеги.

Олег Миколайченко, DevOps Team Lead в Ring Ukraine

8 лет опыта в DevOps

От специалиста уровня Junior ждут, что он будет хоть как-то полезен, и не будет особо мешать. Как результат, в первую очередь джуну нужно понять, где он может быть полезен и как не мешать остальным работать. В DevOps-related инфраструктурах и экосистемах в большинстве случаев есть какие-то узкие мануальные движения, которые можно автоматизировать. Или задачи, которые никто делать не хочет, но их нужно сделать.

Мне в свое время помогали вопросы:

  • Где я могу помочь?
  • Чем я могу помочь?
  • У меня есть капасити, что полезного я могу сделать?

Если не получается, то задавать вопросы нужно вот так: «Я работал над задачей Х, столкнулся с проблемами 1,2,3 и решал их вот-так и еще вот так. Читал тут, но не получилось. Актуальная ошибка — вот такая. Можете помочь, плиз, советом?» или «Уважаемый Senior ДевОпс ДевОпсович, не изволите ли вы помочь своей экспертизой и взглянуть одним глазком на безобразие, которое я тут наделал?».

Советовать все любят, поэтому советов будет море. Если правильно запустить маховик советов, то вся команда будет спорить, кто посоветовал лучше, а вы, как Junior DevOps Engineer — будете купаться в изобилии архитектурных решений, технологий и best practices.

Добавляем к умению полгода/год/два (кому как) работать самостоятельно, задавать правильные вопросы и еще неплохой английский — и получаем отличного Middle, резюме которого я уже жду.

Знания будут полезны любые. Все. Все, что может учить Junior, будет полезно.
Если вектор сформировать правильно, можно быть максимально эффективным в обучении. Например:

  • AWS, Docker, Kubernetes, Jenkins, Github, EFK, Terraform, Prometheus, Grafana, Golang
  • вместо AWS можно GCP/Azure
  • вместо Jenkins можно CircleCI/TeamCity
  • вместо Github можно работать в Gitlab
  • вместо Golang можно Python
  • приправить чем-то из HashiCorp и CNCF

Валидировать правильность вектора можно в разделе вакансий на DOU. Если в строке поиска ввести технологию, то можно увидеть количество вакансий, в которой она обязательна.

Отдельно добавляем конференции, и их записи на YouTube. Почти все есть в свободном доступе:

  • KubeCon
  • AWS re:Invent
  • DevOps Days
  • Monitorama

Актуальные и свежие новости можно читать в ежемесячных DevOps-дайджестах на DOU или в Telegram-канале ДевОпс инженер.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn

Схожі статті




37 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

можно, пожалуйста, следующую статью на тему «Галерные 40-летние дяди с 20 годами опыта гребли рассказывают, что нужно учить, чтобы проходить интервью в Google/Netflix/Facebook или хотя бы как к 40 перестать быть синиор инженером»? Заранее благодарен!

Советы сеньоров: как прокачать

идешь в ближайшую качалку и качаешься...

Я уже раньше писал что я (и многие другие) думаю про DevOps.

Это не профессия, это культура в команде или в компании. Это когда команда разработки и эксплуатации — это одна и та же команда. Очень емкое описание от Амазона: «You build it, you run it» — речь о коде конечно же. Заключается культура DevOps в том, что программист сам знает как задеплоить свой код на сервер, как собрать логи, метрики, что делать когда код упадет на продакшене, как настроить безопасность, сеть и так далее по списку. В эпоху докер контейнеров, клауда и PaaS/SaaS достаточно просто делать все самому. Если как программист вы можете написать код, значит вы можете написать и скрипт чтобы задеплоить/сконфигурировать свое приложение. Так что мой совет джуниорам — учитесь быть инженером. Software Engineer с широким кругозором я имею ввиду.

Так что мой совет джуниорам — учитесь быть инженером. Software Engineer с широким кругозором я имею ввиду.

С этим полностью согласен.

Но, Антон, если отказываемся от профессии/должности devops, должны ли все dev-синьёры (хотя бы на таком уровне и выше) знать в обязательном порядке kubernets, ansible, swarm, тонкости тюнинга баз данных, репликации, особенностей cloud провайдеров (сервисы, инстансы, price policy), мониторинга, ответственность за стабильность продакшена и т.д.

Если должны, то нужно добавлять это всё в требования ко всем вакансиям и devops’ы не нужны. Если нет, а только желательно понимать и по возможности уметь, но не нести ответственность. То появляются отдельные фигуры, обладающие особыми уникальными знаниями в рамках dev-команды, которые таки это умеют, настроили и отвечают за стабильность.

И встаёт вопрос, кого легче сейчас найти — отдельно хорошего senior java, но без k8s и прочего + devops’а. Или же одного человека обладающего всеми этими компетенциями?

И вот пока в dev-ваканчиях не будет этих требований, будет специальная профессия — devops, без философии.

Хороший вопрос, и я думаю ответ на него «да». Ведь если девелопер называет себя Senior Software Engineer, то он как раз должен разбираться в основах (сети, безопасность, базы) и в современных технологиях (k8s, docker, aws, etc.). Но здесь как всегда срач о том кто есть сеньор и кто не сеньор. В украинских реалиях часто человек с лычкой сеньор таковым не является. Справедливости ради в швеции я также кучу людей с лычкой сеньор видел, которые не знают про докер или основы про сети.

Если должны, то нужно добавлять это всё в требования ко всем вакансиям и devops’ы не нужны.

Ну скажем так, всегда будут фронтенд или там iOs девелоперы которым все это знать не обязательно. Но справедливости ради я бы предложил вместо лычки DevOps что-то типа Security Engineer, или Network Engineer, или Site Reliability Engineer — несомненно в больших компаниях есть место для таких ролей/тайтлов

он как раз должен разбираться в основах (сети, безопасность, базы) и в современных технологиях (k8s, docker, aws, etc.)

разбираться — не нести ответственность в случае проблем. Разбираться в основах — не знаит иметь четкие познания и низкоуровневое понимание как и что работает. В итоге возвращаемся к тому, что сейчас идет попытка опрограммить админов, или обадминить программеров и назвать это devops.

Разбираться в основах — не знаит иметь четкие познания и низкоуровневое понимание как и что работает.

Согласен, но я просто непонятно написал. Я имел ввиду что сети, безопасность и базы — это основы Computer Science. Их надо знать обязательно. Например у нас в ВУЗе далеко не первой величины все это входило в программу обучения, причем на весьма детальном уровне. Я по этой причине считаю что хороший программист (или инженер в IT) должен иметь профильное образование.

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

все равно это сведется к тому, что если проект более менее крупнее чем разработка сайтов на WP, Joomla etc, в команде будет организм который будет выполнять функции связующего звена между разрабами, тестерами, в какой то мере менеджментом и раньше для меня это и был админ, а сейчас это devops :) Слышал про конторы в которых разрабы сами отвечают за работу своего кода, но не приходилось с такими сталкиваться и все равно интересно как у них настраиватеся и кем тот же nginx например, или если касается микросервисной архитектуры, кто настраивает тот же скейлинг, или реплики, кластеры и прочее, неужели есть конторы в которых все эти функции делаются разрабами и «все поддерживают все»...

Хорошо сказано. Но пожалуй учитывая все это все равно должность DevOps’а необходима в современных больших компаниях, т.к. есть умение что-то сделать (это похвально, если программист сам может задеплоить и скрипт написать), а есть ответственность и тонкое понимание общей картины. Необходимо иметь одного специалиста с узкой специализацией по DevOps’у который отвечает за деплой, интеграцию, администрирование, масштабирование и т.д всех приложений компании, чем три сеньйора которые невпопад делают как им удобно. Мне кажется в современной разработке важно иметь узкоспециализированных работников, а не «специалистов широкого профиля».

Good or not Intro =)
www.youtube.com/...​D2u-gmis8h9K66qoj&index=1
As far as I understand DevOps is about implementing CALMS principle in organization:
1) Culture
2) Automation
3) Lean
4) Measurement
5) Sharing
And to do so — you need to use a combination of soft and hard skills. There are a lot of tools to consider but what is important is to not create a zoo of different techs and tools, — also use best practices & patterns. “People over processes over tools”

Мне вот интересно было бы почитать методологии о которых тут писали, а то как то все говорят про них, а я вот не нахожу никаких методологий, есть только одно эфемерное понятие и куча трактований, у каждого свое. Так же есть «DevOps практики», которые можна перевести «а вот как у нас», а люди зачастую не пользуются здравым смыслом и считают это руководством к деййствию, методологией, библией для devopsов... Самое смешное то, что в одной статье один человек пришет опрвержение что понятие «DevOps Engeneer» — это ерунда, а следом публикуют чувака у которого должность такая....

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

опять же — это все личное мнение конкретного человека. Кто то придумал понятие, написал какую то книжку, в которой какое то эфемерное, размытое, невнятное, непонятное понятие devops. В итоге «да будет срач».

так то в каждой конторе еть свои особенности и обязанности для каждого тайтла , поэтому это все желательно уточнять на интервью, чтобы не было размытости

и от этого грустно. Хотя сейчас мне уже как то проще мирится с этим зоопарком, так как все сводится во всех конторах к одному — деплой, поддержка девов, поддеркжа тестеров, поддержка инфраструктуры (личной или в облаках), педаленье какой нить автоматики. В итоге тот же админ как и 10 лет назад, только обозвали по новому :)

хз хз, мне и другим знакомым админам это название вызывает приступ тошноты.

А моим колегам всем нравится :) и где правда ?:)

а я и не ищу правдку, она у каждого своя. Только если ты разраб на С. то ты разраб на С, а если ты devops — то х..й знает кто ты вообще такой... А когда тебя называют эфемерным названием, которое интерпретируют как методилогию, специализацию, технологию взаимодествия и прочая срань, это раздражает. Но каждому свое. Лично я не зависимо от тасков и проектов считаю себя админом и прошу меня так звать и величать в документах.

и прошу меня так звать и величать в документах.

А какая разница ?

Как минимум Админ, он же Администратор системы, есть в калссификации специальностей, а что такое devops, его ни в какой классификации нет... Называть себя специальностью которой не существует и радоваться, ну блин для меня это непонятно как то.

ага прям как бугФут, никто не видел, но все его знают и хотят поймать)))
мое личное мнение , неважно какой у тебя тайтл в компании, а главное это то на сколько ты там полезен, влиятелен/авторитетен и уровень заработной платы)
а девопс ты или сисадмин в свитере с оленями — дело десятое))))

ну вот смешно но замеченный факт — админам платят меньше чем опсам. Так что название похрже играет роль :)

Справа в тому, що «девопс», як явище — це характерний симптом agile.Порівняно з адміном від девопса вимагається значно ширша необхідна компетенція. З одночасним зменшенням глибини цієї компетенції. Тобто, і швець, і жнець, і на дуді ігрець, і дба, і сапорт, і тестер, і ще бозна що в одному флаконі. Це, можливо, й виправдано для дрібних проектів, де накладно тримати окремих адміна, ДБА етц, але як наслідок, цей підхід породив інший симптом — хайлоад. Що в усіх випадках означає концептуальні проблеми в архітектурі та реалізації проекту. Ну, не в усіх, звичайно, я брав участь в двох проектах, де хайлоад таки дійсно був неуникний в силу природи задач. Великий обсяг обчислень + велике значення транзакцій в секунду. Але якщо в системі транзакцій менше, ніж 1к/с, а транзакція зводиться до десятка простеньких запитів в базу, то хайлоад — це лише ознака неправильної точки монтування /dev/hands.

вроде как это и есть админ в большинстве контор:

Тобто, і швець, і жнець, і на дуді ігрець, і дба, і сапорт, і тестер, і ще бозна що в одному флаконі.

ну и

Справа в тому, що «девопс», як явище — це характерний симптом agile.

Интересно кто все функции девопса выполнял в дев конторах, отделах, департаментах до появления термина девопс ?

А хто його зна. Я в масі проектів зтикався з нерозумінням потреби в грамотному ДБА та повній інкапсуляції БД від шаловливих ручок кодерів, які вважають за припустиме струячить DDL в продакшн. Та ж кожен похапіст вміє селект написать! А потім зчиняється алярма — хайлоад, хайлоад, випускайте кракєна! Що казати про «адмінів», які не бачать різниці між конфігуруванням свого десктопу та бойової ноди.

))))) ну таких спецов сейчас навалом, особенно с наступлением времен «вайтишников».

ИМХО — админ — может быть девопсом, сисопом, и моними другими буквами и аббревиатурами, а вот наоборот — нет. Из админов в девопсы — да, хоть это и в некотором роде даунгрейд, но платят больше, по себе заметил и не раз. А вот из девопсов стать админом — неа и это факт, надо учиться и практиковаться много.

Ну так в іншій темі вже говорилося, що функобов’язки девопса — це підмножина функобов’язків адміна. Власне, вся ідея в тому, щоб неповний пакет функціоналу покласти на вже присутнього дева, а не тримати окремо адміна. Це все виправдане лише для малих колективів в малих проектах, а в мінімально серйозних проектах має бути спеціалізація. «Беда, коль пироги начнет печи сапожник, а сапоги тачать пирожник». Але декому неодмінно необхідно власними ратицями відтоптатися на двохсотрічних граблях.

намешано из менифеста и какие то сумбурные понятия, что в итоге подтверждает факт — devops эфемерное понятие, не имеющее чего то четкого или внятного.

Прочитал сначала «Советы сыроедов: как прокачать знания junior...»

Мониторинг. Следить и поддерживать сервисы поможет, если еще не внедренный, старичок Zabbix.

так себе, для мониторинга сервисов — особенно, решительно не понимаю его популярности

А що можете порекомендувати?

у меня другой стек технологий (RISC-серверы и СХД в собственных ЦОДах, а не публичные х86-облака)
так что то, что я могу порекомендовать — будет невостребованно для всяких aws-ов
но знаю, что еще многих не устраивают ни Munin (если серверов сильно больше нескольких штук), ни Zabbix, ни Ganglia ни Nagios, ни производные от последнего в виде — Icinga, Shinken, ...
и используются составные конструкции в виде
Graphite + Grafana
Prometheus + Grafana
и т.д.
с разными вариациями агентов сбора метрик и баз хранения данных
но в качестве конечного дашбоарда — Grafana тут явно победила

На жаль, сучасні «девопси» навіть гадки не мають, що в більшості систем штатно сидить утиліта `logger`, за допомогою якої можна організувати розподілений збір будь-яких метрик, якщо, звісно, знати, що має значення та як ці метрики вичитать. Але в сучасному продакшні девопси можуть не більше, ніж закладено в готові моніторингові агрегати, а все, что виходить за межі цього — «неможливо».

Только практика, только хардкор

Підписатись на коментарі