Что такое девопс простыми словами
Кто такой DevOps-инженер, что он делает, сколько зарабатывает и как им стать
DevOps-инженеры — это многопрофильные специалисты, которые умеют автоматизировать процессы и знают, как работают разработчики, QA и менеджеры. Они умеют программировать, быстро осваивают сложные инструменты и не теряются перед незнакомой задачей. DevOps-инженеров мало — им готовы платить по 200–300 тысяч рублей, но вакансий всё равно много.
В статье рассказываем, чем конкретно занимается DevOps и что нужно изучить, чтобы претендовать на такую должность. Бонусом — важные ссылки на книги, видео, каналы и профессиональное сообщество.
Разобрался, чем занимаются и сколько зарабатывают DevOps-инженеры
Чем занимается DevOps-инженер
В ситуации с DevOps важно не путать термины. Дело в том, что DevOps — это не какое-то конкретное направление деятельности, а профессиональная философия. Это методология, которая помогает разработчикам, тестировщикам и системным администраторам работать быстрее и эффективнее за счёт автоматизации и бесшовности.
Соответственно, DevOps-инженер — это специалист, который внедряет эту методологию в процесс работы:
Всё, что написано выше, происходит в близких к идеальным проектах. В реальном же мире приходится стартовать в проекте, где планирование пропустили, с архитектурой ошиблись, а об автоматизации задумались, когда все проекты встали. И разобраться во всех этих проблемах, решить их и сделать так, чтобы всё работало — ключевой навык DevOps-специалиста.
На рынке кадров есть путаница. Иногда бизнес ищет DevOps-инженеров на позицию системного инженера, билд-инженера или кого-то ещё. Обязанности в зависимости от размера компании и направления тоже меняются — где-то ищут человека на консалтинг, где-то просят всё автоматизировать, а где-то требуют выполнять расширенные функции системного администратора, умеющего программировать.
Что нужно для старта в профессии
Вход в профессию требует предварительной подготовки. Просто прийти на курсы с нуля, ничего не понимая в IT, и выучиться до уровня junior не получится. Нужен технический бэкграунд:
Не обязательно знать всё перечисленное досконально, для старта обучения DevOps достаточно минимального уровня подготовки. Если такой технический бэкграунд есть, попробуйте записаться на курсы.
Говорим о DevOps на понятном языке
Трудно уловить главное, говоря о DevOps? Мы собрали для вас яркие аналогии, ударные формулировки и советы от экспертов, которые помогут дойти до сути даже неспециалистам. В конце бонус – собственный DevOps сотрудников Red Hat.
Термин DevOps возник 10 лет назад и прошел путь от хэштега в Твиттере до мощного культурного движения в мире ИТ, настоящей философии, поощряющей разработчиков быстрее добиваться результатов, экспериментировать и двигаться вперед методом итераций. DevOps стал неразрывно связан с понятием цифровой трансформации. Но как это часто бывает с ИТ-терминологией, за десяток лет DevOps успел обрасти множеством определений, трактовок и заблуждений на свой счет.
Поэтому про DevOps нередко можно услышать вопросы вроде, это то же самое, что agile? Или это какая-то особая методология? Или это просто еще один синоним слова «сотрудничество»?
DevOps включает в себя много разных концепций (непрерывная доставка, непрерывная интеграция, автоматизация и т. п.), поэтому вычленить главное может быть непросто, особенно когда вы неравнодушны к предмету. Однако это умение очень полезно, неважно, пытаетесь ли вы донести свои идеи до начальства или же просто рассказываете о своей работе кому-то из родных или знакомых. Поэтому пока отложим в сторону терминологические нюансы DevOps и сосредоточимся на общей картине.
Что такое DevOps: 6 определений и аналогий
Мы попросили специалистов объяснить суть DevOps максимально просто и коротко, чтобы ее ценность стала понятна читателю с любым уровнем технической подготовки. По итогам этих бесед мы отобрали самые яркие аналогии и ударные формулировки, которые помогут вам выстроить свой рассказ о DevOps.
1. DevOps – это культурное движение
«DevOps – это культурное движение, в рамках которого обе стороны (разработчики ПО и специалисты по эксплуатации ИТ-систем) признают, что софт не приносит реальной пользы до тех пор, пока им не начинает кто-то пользоваться: заказчики, клиенты, сотрудники, не суть, – считает Эвелина Эрлих (Eveline Oehrlich) старший аналитик-исследователь Института DevOps. – Поэтому обе эти стороны совместно обеспечивают быструю и качественную доставку софта».
2. DevOps – это то, что наделяет властью разработчиков
«DevOps наделяет разработчиков полномочиями на владение приложениями, их запуск и управление доставкой от начала и до конца»
«Обычно о DevOps говорят, как о способе ускорить доставку приложений в продакшн за счет выстраивания и применения автоматизированных процессов, – говорит Джей Шнайп (Jai Schniepp), директор по платформам DevOps страховой компании Liberty Mutual. – Но для меня это гораздо более фундаментальная вещь. DevOps наделяет разработчиков полномочиями на владение приложениями или определенными частями ПО, на их запуск и управление доставкой от начала и до конца. DevOps устраняет неразбериху с ответственностью и ведет всех участников процесса к созданию автоматизированной и управляемой разработчиком инфраструктуры».
3. DevOps – это сотрудничество при создании и доставке приложений
«Проще говоря, DevOps – это такой подход к производству и доставке ПО, когда все работают вместе», – отмечает Гур Стаф, президент и руководитель направления автоматизации цифрового бизнеса компании BMC.
4. DevOps – это конвейер
«Конвейерная сборка возможна, только если все детали подходят друг к другу».
«Я бы сравнил DevOps с конвейером по сборке автомобилей, – продолжает Гур Стаф. – Идея в том, чтобы заранее спроектировать и сделать все детали так, чтобы потом их можно было собрать без индивидуальной подгонки. Конвейерная сборка возможна, только если все детали подходят друг к другу. Те, кто проектирует и делает двигатель, должны подумать о том, как крепить его к кузову или раме. Те, кто делает тормоза, должны подумать о колесах, и так далее. Точно так же должно быть и с софтом.
Разработчик, создающий бизнес-логику или пользовательский интерфейс, должен подумать о базе данных, хранящей сведения о заказчиках, о средствах безопасности для защиты пользовательских данных, а также о том, как все это будет работать, когда сервис начнет обслуживать большую, возможно, даже многомиллионную аудиторию пользователей».
«Сделать так, чтобы люди сотрудничали и думали о тех частях работы, которые выполняются другими, а не концентрировались исключительно на своих собственных задачах – вот величайшее препятствие, которое надо преодолеть. Если это удается, у вас появляются отличные шансы на цифровую трансформацию», – добавляет Гур Стаф.
5. DevOps – это правильная комбинация людей, процессов и автоматизация
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps, предложила отличную аналогию для объяснения DevOps. По ее словам, «DevOps – это как кулинарный рецепт, в котором есть три основные категории ингредиентов: люди, процессы и автоматизация. Большинство этих ингредиентов можно взять из других областей и источников: Lean, Agile, SRE, CI/CD, ITIL, лидерство, культура, инструменты. Секрет DevOps, как и любого хорошего рецепта, в том, как правильно подобрать пропорции и смешать эти ингредиенты, чтобы повысить скорость и результативность работы при создании и выпуске приложений».
6. DevOps – это когда программисты работают, как команда Формулы-1
«Гонка планируется не от старта к финишу, а наоборот, от финиша к старту».
«Говоря о том, чего ждать от инициативы DevOps, я привожу в пример гоночную команду NASCAR или Формулы-1, – говорит Крис Шорт (Chris Short), главный менеджер по маркетингу облачных платформ Red Hat и издатель рассылки DevOps’ish. – У руководителя такой команды одна цель: занять по итогам гонки максимально возможное место с учетом имевшихся у команды ресурсов и выпавших на ее долю испытаний. При этом гонка планируется не от старта к финишу, а наоборот, от финиша к старту. Вначале ставится амбициозная цель, а затем определяются пути ее достижения. После чего они разбиваются на подзадачи и делегируются членам команды».
«Всю неделю перед гонкой команда оттачивает пит-стоп. Занимается силовыми и кардиотренировками, чтобы быть в форме в изнурительный день гонок. Отрабатывает совместные действия при решении любых проблем, которые могут возникнуть на гонке. Аналогично команда разработчиков должна тренировать навыки частого выпуска новых версий. При наличии таких навыков и отлаженной системы безопасности запуск новых версий в продакшн тоже происходит чаще. В рамках этого мировоззрения рост скорости означает рост безопасности», – говорит Шорт.
«Дело не в том, чтобы делать «правильные вещи», – добавляет Шорт, – а в том, чтобы устранять как можно больше вещей, которые стоят на пути к желаемому результату. Сотрудничайте и адаптируйтесь с учетом обратной связи, которую вы получаете в реальном времени. Будьте готовы к аномалиям и работайте над повышением качества, чтобы свести к минимуму их влияние на движение к цели. Именно это ожидает нас в мире DevOps».
Как масштабировать DevOps: 10 советов от экспертов
Просто DevOps и массовый DevOps – это абсолютно разные вещи. Мы расскажем, как преодолеть барьеры на пути от первого ко второму.
Для многих организаций путь к DevOps начинается легко и приятно. Создаются небольшие пассионарные команды, старые процессы заменяются на новые и первые успехи не заставляют себя ждать.
Увы, это лишь фальшивый блеск, иллюзия прогресса, как говорит Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland. Ранние победы конечно обнадеживают, но не помогают достичь конечной цели, а именно, массового использования DevOps в организации.
Легко видеть, что в результате формируется культура разделения на «мы» и «они».
«Зачастую организации запускают такие проекты-первопроходцы, считая, что они проложат путь к массовому DevOps, не задумываясь, смогут и захотят ли пойти этим путем остальные, – объясняет Бен Гриннел. – Команды для реализации таких проектов обычно набирают из самоуверенных “варягов”, которые уже делали нечто подобное в других местах, но являются новичками в вашей организации. При этом их поощряют ломать и разрушать правила, которые остаются обязательными для всех остальных. Легко видеть, что в результате формируется культура разделения на «мы» и «они», которая препятствует передаче знаний и навыков».
«И эта культурная проблема – лишь одна из причин того, что DevOps сложно масштабировать. Команды DevOps сталкиваются с ростом сугубо технических сложностей, характерным для быстроразвивающихся компаний, сделавших ставку на ИТ-технологии», – говорит Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr.
«В современном мире услуги меняются сразу, как только появляется такая необходимость. Постоянно реализовывать и внедрять новые функции, конечно, здорово, но вот координировать этот процесс и устранять возникающие проблемы – настоящая головная боль, – добавляет Стив Ньюман. – В очень быстро растущих организациях инженеры в составе кросс-функциональных команд борются за то, чтобы сохранить за собой возможность отслеживать изменения и порождаемые ими каскадные эффекты на уровне зависимостей. Более того, инженеров отнюдь не радует, когда их лишают такой возможности и в результате им становится труднее понимать суть возникающих проблем».
Как же преодолеть эти описанные выше трудности и перейти к массовому использованию DevOps в крупной организации? Эксперты призывают запастись терпением, даже если ваша конечная цель состоит в том, чтобы ускорить цикл разработки ПО и бизнес-процессы.
1. Помните, что для изменений в культуре нужно время
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps: «На мой взгляд, расширение DevOps должно быть таким же постепенным и итеративным, как и agile-разработка (и в равной мере затрагивать культуру). В Agile и DevOps упор делается на небольшие команды. Но по мере роста числа и интеграции таких команд мы получаем все больше людей, применяющих новые методы работы, и, как следствие, возникает масштабная культурная трансформация».
2. Уделите достаточно времени планированию и выбору платформы
Эран Кинсбрюнер (Eran Kinsbruner), ведущий технический евангелист компании Perfecto: «Чтобы масштабирование сработало, командам DevOps в начале надо научиться сочетать традиционные процессы, инструменты и навыки, а затем медленно взращивать каждую отдельную фазу DevOps и стабилизировать ее. Все начинается с тщательного планирования пользовательских историй (userstory) и потоков создания ценности (valuestream), после чего наступает этап написания ПО и контроля версий с использованием trunk-based development или других подходов, наиболее подходящих для ветвления и слияние кода».
«Затем следует этап интеграции и тестирования, где уже требуется масштабируемая платформа для автоматизации. И здесь командам DevOps важно выбрать правильную платформу, которая отвечала бы их уровню навыков и конечным целям проекта.
Следующая фаза – развертывание в производственной среде, и оно должно быть полностью автоматизировано с использованием инструментов оркестрации и контейнеров. При этом важно иметь виртуализированные среды на всех этапах DevOps (симулятор производственной среды, среда контроля качества и, собственно, производственная среда) и всегда использовать для тестов только самые последние данные, чтобы получать актуальные выводы. Аналитика должны быть умной и способной обрабатывать большие данные с быстрой и действенной обратной связью».
3. Избавьте ответственности от привкуса вины
Гордон Хафф (Gordon Haff), евангелист RedHat: «Создание системы и атмосферы, разрешающей и поощряющей эксперименты, позволяет реализовать так называемые успешные сбои в agile-разработке ПО. Это не значит, что за сбои больше никто не отвечает. На самом деле установить ответственного становится даже проще, поскольку «быть ответственным» больше не означает «стать виновником аварии». То есть суть ответственности качественно меняется. При этом крайне важными становятся четыре фактора: масштабы сбоя, подходы, производственные процессы и стимулы». (Подробнее об этих факторах можно прочитать в статье Гордона Хаффа «DevOps lessons: 4 aspects of healthy experiments».)
4. Расчищайте путь вперед
Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland: «Чтобы добиться масштабирования, я рекомендую вместе с проектами-первопроходцами запускать программу «расчистки пути». Цель этой программы – убирать мусор, который остается за первопроходцами DevOps, вроде потерявших актуальность правил и прочих подобных вещей, чтобы путь вперед оставался свободен».
«Дайте людям организационную поддержку и придайте импульс через коммуникацию, которая выходит далеко за рамки группы первопроходцев, широко празднуя успехи новых методов работы. Тренируйте людей, которые задействованы в следующей волне проектов DevOps и нервничают из-за того, что используют DevOps впервые. И помните, что эти люди сильно отличаются от первопроходцев».
5. Сделайте инструменты более демократичными
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Инструменты не надо прятать от людей, и они должны быть относительно просты в освоении для любого, кто готов потратить на это время. Если возможность запрашивать логи предоставлена только трем людям, «сертифицированным» для работы с каким-то инструментом, у вас всегда будет максимум три человека, способных разобраться с соответствующей проблемой, даже если у вас очень большая вычислительная среда. Иначе говоря, здесь возникает узкое место, которое может привести к серьезным (для бизнеса) последствиям».
6. Создайте идеальные условия для работы команды
Том Кларк (Tom Clark), руководитель направления Common Platform в телекомпании ITV: «Вы можете сделать что угодно, но не все сразу. Поэтому ставьте большие цели, начинайте с малого и двигайтесь вперед быстрыми итерациями. Со временем вы заработаете репутацию команды, у которой все получается, поэтому другие тоже захотят использовать ваши методы. И не гонитесь за выстраиванием высокоэффективной команды. Вместо этого обеспечьте людям идеальные условия для работы и эффективность придет сама собой».
7. Не забывайте о законе Конвея и канбан-досках
Логан Дейгл (Logan Daigle), директор по доставке ПО и стратегии DevOps компании CollabNetVersionOne: «Важно осознавать последствия закона Конвея. В моем вольном пересказе этот закон гласит, что продукты, которые мы создаем, и процессы, которые мы при этом используем, включая DevOps, оказываются устроены так же, как и наша организация».
«Если в организация высока разобщенность, а при планировании, создании и выпуске ПО управление много раз переходит из рук в руки, эффект от масштабирования будет нулевым или недолговечным. Если же организация формирует кросс-функциональные команды вокруг продуктов, которые финансируются с ориентацией на рынок, то шансы на успех резко возрастают».
«Еще один важный аспект масштабирования заключается в том, чтобы отображать на канбан-досках все работы, находящиеся в процессе выполнения (WIP, workinprogress). Когда в организации появляется место, где люди могут видеть такие вещи, это сильно стимулирует сотрудничество, что положительно сказывается на масштабировании».
8. Ищите старые шрамы
Манюэль Паис (Manuel Pais), консультант по DevOps и соавтор книги «Team Topologies»: «Вывод практик DevOps за пределы собственно Devи Opsи попытку применить их к другим функциям вряд ли можно назвать оптимальным подходом. Это, несомненно, даст определенный эффект (например, за счет автоматизации ручного управления), но можно добиться гораздо большего, если начать с понимания процессов доставки и обратной связи».
«Если в ИТ-системе организации есть старые шрамы – процедуры и механизмы управления, которые были внедрены по итогам прошлых инцидентов, но утратили актуальность (из-за смены продуктов, технологий или процессов), – то их, безусловно, надо удалять или разглаживать, а не автоматизировать неэффективные или ненужные процессы».
9. Не плодите варианты DevOps
Энтони Эдвардс (Antony Edwards), директор по производству компании Eggplant: «DevOps – очень расплывчатый термин, поэтому у каждой команды получается свой вариантDevOps. И нет ничего хуже, когда в организации появляются сразу 20 разновидностейDevOps, которые не очень хорошо уживаются вместе. Нельзя, чтобы у каждой из трех команды разработчиков был свой, особый интерфейсом между разработкой и управлением продуктом. Как и нельзя, чтобы продукты имели свои, уникальные ожидания в части обработки обратной связи при переносе в симулятор производственной среды. Иначе у вас никогда не получиться масштабироватьDevOps».
10. Проповедуйте ценность DevOps для бизнеса
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Поработайте над признанием ценности DevOps. Научитесь и не стесняйтесь рассказывать о пользе того, что вы делаете. DevOps невероятно экономит время и деньги (просто подумайте: меньше простоев, короче среднее время восстановления), и команды DevOps должны неустанно подчеркивать (и проповедовать) важность этих инициатив для успеха бизнеса. Так вы сможете расширить круг адептов и усилить влияние DevOps в организации».
БОНУС
На Red Hat Forum Russia 13 сентября прилетит наш собственный DevOps – да, у Red Hat, как у производителя программного обеспечения, есть собственные DevOps команды и практики.
Наш инженер Марк Биргер, который занимается разработкой служб внутренней автоматизации для других групп по всей организации, на чистом русском языке расскажет собственную историю – как DevOps команда Red Hat мигрировала приложения из виртуальных сред Hat Virtualization, управляемых Ansible в полноценный контейнерный формат на платформе OpenShift.
Но и это еще не все:
После того как организации перенесли рабочие нагрузки в контейнеры, традиционные методы мониторинга приложений могут не сработать. Во втором докладе мы объясним нашу мотивацию к изменению способа регистрации и покажем продолжение пути, который привел нас к современным методам ведения журналов и мониторинга.
Кто такой DevOps-инженер?
Эксперт в DevOps и Linux.
DevOps-инженер — связующее звено между всеми этапами создания продукта: от написания кода до релиза. Спрос на его труд растет из года в год, и даже младший специалист может рассчитывать на зарплату от 100 тыс. рублей. Мы попросили DevOps-инженера из Ростелекома, а также автора одноименного курса в SkillFactory Вячеслава Светлова разложить для нас его профессию по полочкам.
Что такое DevOps?
DevOps — это набор практик на стыке системного администрирования (Ops — Operations) и разработки (Dev — Development).
До внедрения DevOps при создании приложения целью группы разработки было написание кода, а группы инфраструктуры — поддержка всех серверов в работоспособном состоянии.
Если возникала проблема, инженер инфраструктуры мог сказать: «С сервером все в порядке, проблема с кодом, дальше разбираться я не буду, проблема не моя», — а разработчик говорил: «На моем компьютере этот код работает, проблема с сервером, дальше разбираться я не буду, это не моя зона ответственности».
С приходом DevOps-инженера вся команда фокусируется на единой цели — создании качественного продукта.
Без DevOps-культуры в компании может практиковаться ручное тестирование, ручное управление инфраструктурой, могут возникать конфликты в частях кода, написанных разными разработчиками. В итоге бизнес получит низкое качество продукта, низкую скорость вывода продукта на рынок, демотивированных сотрудников, вынужденных большую часть времени тратить на рутинные задачи и сложности при масштабировании.
Что делает DevOps-инженер?
DevOps-инженер синхронизирует все этапы создания программного продукта: от написания кода до тестирования и релиза.
Это профессионал, имеющий широкие знания в IT и понимающий, как прийти к конечному продукту. Он хорошо разбирается в инфраструктуре, понимает принципы разработки приложений и построения их архитектуры. Еще он — менеджер-практик, знающий жизненный цикл приложения и современные методологии разработки.
А можно на простом примере?
Есть два друга, которые хотят пожарить мясо на природе. Итоговый продукт их деятельности — шашлык. Друзья распределяют между собой задачи: один нанизывает мясо на шампур (сравним его с разработчиком), другой собирает мангал и разводит огонь (сравним его с инженером инфраструктуры).
Угли готовы, мясо на шампурах, положили шампуры на мангал — ждут. Но пошел дождь, надо перенести мангал под тент, чтобы угли не потухли. Одному это сделать трудно, дождь усиливается.
Без DevOps-культуры разработчик (отвечающий за нанизывание мяса на шампуры) может сказать: «Мясо на шампурах — моя работа сделана. Дальше разбираться я не буду», — и в итоге шашлыка никто не поест.
DevOps-инженер — это третий друг, который заранее посмотрел прогноз погоды, понял, что будет дождь, взял с собой тент, развернул его и, когда погода испортилась, помог перенести мангал с мясом под тент. В итоге все насладились вкусным мясом (выпустили качественный продукт).
Где нужен DevOps?
DevOps-инженеры нужны в компаниях, которые разрабатывают ПО для себя или на заказ. При этом сферы могут быть самые разные: медицина, транспорт, спорт, автомобили и пр.
Что ему нужно знать?
DevOps-инженер — многопрофильный специалист, и для успешной работы ему необходимо разбираться в нескольких IT-направлениях. Требования к нему в разных компаниях отличаются, но база для всех примерно такая:
Какие нужны софт-скилы?
Помимо хорошего технического кругозора и навыков автоматизации DevOps-инженеру крайне необходимо развивать софт-скилы, которые помогут синхронизировать работу всех участников и подразделений.
Особенно требуется умение работать в команде, поскольку DevOps-культура в целом подразумевает довольно плотное общение между командой разработки и командой инфраструктуры. Часто для получения конечного результата надо уметь находить компромиссы.
Насколько это востребовано и сколько получает DevOps-инженер?
IDC прогнозирует, что количество специалистов DevOps с 2019 по 2024 год возрастет в два раза. Ожидается, что к 2024 году минимум 30% компаний внедрят полноценный цикл DevOps.
По данным Research and Markets сфера DevOps переходит из нишевого инструмента в глобальный рынок, который имеет просто колоссальный потенциал для роста. За период карантина в 2020 году рынок вырос на 29,3%.
В марте 2021 года на сайте hh.ru было более 4,3 тыс. вакансий DevOps-инженера.
Можно заметить рост популярности запроса «devops» и других запросов по теме на графиках от сервиса Google Trends.
Зарплата зависит от компании и навыков. Младший специалист DevOps в Москве получает от 70 до 150 тыс. рублей в месяц, а зарплата ведущего составляет примерно 250 тыс. рублей. По данным Хабр Карьеры, во втором полугодии 2020 года средняя медианная зарплата специалиста DevOps составила 155 тыс. рублей.
На сайте hh.ru можно найти вакансии с зарплатой более 400 тыс. руб. в месяц. Больше всего вакансий предполагают доход от 105 тыс. до 265 тыс. рублей.
Плюсы и минусы профессии
Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.
Чем DevOps отличается от Agile?
Agile — обобщающий термин для целого набора принципов, подходов и практик, основанных на ценностях гибкой разработки. Такую методологию применяют для организации труда небольших групп. Она нацелена на минимизацию рисков при работе с помощью разделения разработки на короткие циклы, каждый из которых выглядит как отдельный конечный проект. Каждый из этапов обычно включает в себя спектр задач: планирование, анализ требований, проектирование, программирование, тестирование и документирование.
В отличие от Agile, DevOps предполагает разработку методологии, позволяющей оптимизировать выполнение повторяющихся задач. Этот подход лучше применять для разработок, в которых необходимо найти способ быстро и с высокой повторяемостью переносить программное обеспечение в производственную среду.
DevOps-инженерами становятся:
Я пришел в специальность из системного администрирования около трех лет назад. До этого работал в центре обработки данных (ЦОД), занимался системами мониторинга — приходилось заниматься как администрированием, так и немного разработкой. После решил попробовать себя в DevOps, там и остался.
Как начать?
DevOps вряд ли будет вашей стартовой профессией в IT, нужно уже иметь опыт в сфере и общее понимание разработки. Для DevOps-инженера также важно знать фундаментальные основы системного администрирования и сетей.
Узнать больше о сетях можно в книгах «Компьютерные сети» Виктора и Натальи Олифер и «Руководство по подготовке к экзамену CCNA» Уэнделла Одома. А ознакомиться с Linux и операционными системами в целом помогут «Настольная книга Unix & Linux системного администратора» Эви Немет и «Современные операционные системы» Эндрю Таненбаума.
Присоединяйтесь к профсообществам на форумах и в соцсетях, чтобы лучше понимать тенденции рынка и обращаться за советами:
Теоретические знания можно отрабатывать на онлайн-курсах (на Udacity есть бесплатный курс), с их помощью удобно систематизировать знания.
На курсе «DevOps-инженер» от Skillfactory вы за 6 месяцев освоите ключевые инструменты и востребованные рынком технологии. Под управлением экспертов вы создадите портфолио архитектурных решений и подходов, научитесь уверенно рассказывать о них на собеседовании и осознанно внедрять в своих проектах.
После этого вы присоединитесь к сообществу специалистов-практиков, получите рекомендации экспертов по внедрению изменений, решению реальных проблем и удержанию фокуса на постоянных улучшениях.
Освойте перспективную IT-профессию на стыке разработки, системного администрирования и бизнеса. Дополнительная скидка 5% по промокоду BLOG.