DevOps как образ жизни


Содержание

DevOps как образ жизни

Сначала была обычная («каскадная», «водопадная») разработка. Заказчик приносил требования. Требования получали разработчики. Разработчики закрывались на пару месяцев. Заказчику показывали готовое.

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

Дело в изменениях и потребности в оных. «Маленький» продукт можно спроектировать у себя в голове, сделать набросок на салфетке и потом разработать — без лишних наворотов на процессы. Проект минимально будет нуждаться в изменениях. Ок, если что-то и нужно будет допилить — это вполне комфортно и почти не дорого можно будет сделать после релиза.

Но вот проект усложняется. Заказчик не уверен, что нужно делать именно так. Аналитик, хоть и парень с головой, но тоже не экстрасенс. Кто знает, вдруг продукт вообще не воспримется пользователями? Скетчи, мудборды, прототипы и прочая подстраховка — хорошо, но только реальные пользователи расскажут, как продукт должен работать на самом деле.

Процесс меняется в сторону стирания барьера коммуникации между клиентом и разработчиком. Теперь работает другая схема.

Заказчик приносит требования. Их разбивают на задачи и упорядочивают по важности для продукта. Разработчики набирают задач на одну-две недели. Закрываются и работают. Показывают первую версию продукта. Запускают на рынок! Далее по кругу, пока все задачи не будут сделаны, а продукт не обрастет всеми плановыми функциями.

  1. Проект становится более гибким, изменениями становится возможно управлять.
  2. Наконец-то появляется возможность апробации проекта на настоящих пользователях (а не моделирование ситуаций).

В чем, собственно, проблема, которую DevOps решает? Даже если команда работает по Scrum, функции разрабатываются «пачками». Потом «пачками» тестируются. И, наконец, внедряются в работающий продукт тоже «пачкой».

Соответственно, изменения на продукте происходят не ровно, а «скачками».

То есть по факту Agile-разработка с заявленным «ровным» темпом изменений становится тем же каскадом.

Для работающего продукта появляется риск: если пользователи не воспримут какую-то одну фичу из спринта, придется переделывать не только ее, но и уже реализованные связанные с ней функции.

  • Разработчики мотивированы делать больше изменений, за них им платят. ИТ-отдел мотивирован выпускать в свет наиболее стабильный продукт (меньше изменений — меньше рисков, что что-то сломается).
  • Разработчики мыслят «главное — сделать строго по заданию». IT мыслят «главное — сделать оптимально для пользователей».
  • Разработчики делают работу в своей среде, QA зачастую настраивают свою среду для тестирования.
  • Знания разработчиков и ИТ-специалистов неотчуждаемы от них самих, у первых нет знаний вторых и наоборот.
  • Разработчики и отдел эксплуатации мало контактируют друг с другом, у них нет осознания чужих проблем.

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

Что предлагает DevOps? Методология провозглашает три развернутых ключевых тезиса (их еще называют «пути»):

  1. Оценивается производительность системы в целом, а не отделов или конкретных разработчиков, админов, специалистов по качеству. Задача руководителя, внедряющего DevOps — заставить всех участников проекта работать единой командой на достижение глобальной цели: увеличение ценности продукта для пользователей. Обязательное условие — развивать кросс-функциональность, делать сотрудников более универсальными солдатами, заставлять их почувствовать себя в шкуре бойца из «лагеря противника».
  2. Непрерывная обратная связь «справа налево». То есть в продукт постоянно внедряются изменения, отслеживается реакция пользователей, готовится материал для новых задач, они уходят в работу. Такой «конвейер» требует высокого уровня автоматизации процессов тестирования и развертывания, создавать его за счет наращивания персонала не правильно.
  3. Создание внутрикомандной культуры, поощряющей эксперименты. Нельзя понять, как будет оптимально для продукта без тестирования на его конечных потребителях. Соответственно, и каждый член команды, и клиент должны мыслить таким образом: смело внедрять новое, чтобы получать наиболее ценный аналитический материал для будущих этапов разработки.

Из того, что же можно сделать конкретно, информации не так много, как ее хотелось бы.

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

Отличная подборка нужного софта:

Тип инструмента Инструменты
Автоматизация инфраструктуры Bcfg2, CFEngine, Chef, CloudFormation, IBM Tivoli, Puppet
Автоматизации развертывания Capistrano, ControlTier, Func, Glu, RunDeck
Инфраструктура как услуги Amazon Web Services, CloudStack, IBM SmartCloud, OpenStack, Rackspace
Автоматизация сборки Ant, Maven, Rake, Gradle
Автоматизация тестирования JUnit, Selenium, Cucumber, easyb
Управление версиями Subversion, Git, IBM Rational ClearCase
Непрерывная интеграция Jenkins, CruiseControl, IBM Rational BuildForge

Ок, что можно сделать для того, чтобы достичь кросс-функциональности в командах продукта?

  • Самое простое: не разделять команды стенами — так они смогут общаться без помех.
  • Также рекомендуется проводить взаимные обучающие тренинги, чтобы разработчики провели ликбез среди QA и админов, а те посвятили первых в свои боли и печали (мы, например, делаем холивары по технологиям, примерно та же история.).
  • Создавать общую инфраструктуру. Причем всегда поддерживать ее актуальность. Если речь о каких-то программных инструментах — то они общие для всех, строго одинаковых версий. Если это площадка для тестирования продукта — то не нужно вручную настраивать одну среду для разработки, одну для теста и потом трястись над ней. Всё в облако, протестировали, исправили баги, удалили платформу (чтобы ни у кого не было соблазна в следующий раз «случайно» воспроизвести неведомый баг на неактуальной уже платформе).

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

Ответная мера — QA вместе с разработчиками пишут тест-кейсы, по которым потом будут оценивать работоспособность продукта (это делается на этапе планирования).

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

Но, как мы ни крутили методологию, оставался открытым главный вопрос: а есть ли заказчик среди заказной веб-разработки с реальной потребностью в таком крутом и техничном процессе?

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

Допустим, даже если мы как подрядчик готовы допилить свои процессы до такого совершенства… В итоге нет.

Подход адекватен для по-настоящему крупных проектов: вроде Dropbox или Flickr. Когда есть реальная потребность в непрерывном потоке изменений, есть ресурсы для постоянного анализа и, естественно, бюджет для экспериментов.

Или для тех команд, которые пилят собственный продукт, предварительно спланировав все ресурсы.

В общем, если кто-то из IT-компаний вдруг пробовал внедрить DevOps — будем рады послушать ваш опыт.

Что нужно знать чтобы стать начинающим системным инженером (devops)?

DevOps — не профессия. Это название культуры доставки кода от разработчика (dev) через тестировщиков и до сисадмина(ops) и обратная связь по этой цепочке.

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

Профессии, которые отрисуются в процессе построения этой методологии следующие:

  • Build Engineer — инженер, который управляет зависимостями, сборками, конфликтами кода.
  • Release Engineer — инженер, который управляет репозиторием кода (кто куда и по каким правилам мерджится и откуда бренчуется). Пожалуй, это самая сложная задача в больших проектах. Особенно с нестрогим Agile или в Waterfall.
  • Automation Engineer — инженер, который занимается автоматизацией рутинных задач. Обычно деплоймент, автотесты, etc. Все эти buzz-слова типа Docker — его инструментарий.
  • Site Reliability Engineer — инженер, который поддерживает ops (апгрейды, расширение железа)
  • Configuration Manager — непонятная мне специальность. Жуткое порождение HR-специалистов, давящих на громкое название позиции. Можно было бы пойти дальше и назвать специальность ZooKeeper Vice President

В список не вошла самая главная специальность — «психолог». Человек, который должен следить за людьми и вычислять психологически важные аспекты команды, пораждающие боттлнеки производительности.

Почти всегда все эти роли совмещают один-два человека. Ну это зависит от качества кода.
Назовем эту компанию BRAE/CM для краткости.
Задача BRAE/CM состоит в том, чтобы программный код, который выходит из под пера программистов, оставался на контроле программистов и сисадминов одновременно. Программисты, равно как и сисадмины, благодаря DevOps-подходу, имеют возможность и даже обязаны обслуживать код на протяжении всего жизненного цикла от планирования архитектуры до мусорки.
То есть сисадмины начинают рулить еще до того, как код попадет к ним — на ранних стадиях, а программисты продолжают рулить своими задачами уже после того, как код от них ушел к сисадминам — на поздних стадиях. И все это прозрачно друг для друга и все проблемы и решения ходят туда сюда и не спотыкаются о бюрократия в стиле «ничего не знаю, мы код уже закоммитили, у меня тут свои проблемы, у них сломалось — пусть сами и чинят».

Так вот эта работа — завершающая стадия системного администратора и начинающая стадия разработчика. Поэтому не бывает Junior BRAE/CM.
BRAE/CM бывает всегда только Senior в системном администрировании и всегда Junior в программировании.

Еще один момент. В домашних условиях можно выучить инструменты на базовом уровне. Но не поварившись в одной кастрюле с реальными разработчиками, смысл всей этой кухни не понять. Так что сразу забейте. Но если хотите, могу описать пошаговый длинный путь как стать RE/CM:

Сразу оговорюсь по языкам.
У каждого языка свое предназначение. Java чаще используется в корпоративном секторе. Там много серверов и сложные бизнес-приложения. Поэтому Java-мир очень чувствителен к таким понятиям, как «технинческий долг» и «управление процессом разработки». И именно поэтому именно там все основные вакансии DevOps и именно там будет самый интересный опыт.
Кроме Java, традиционно сильная DevOps-культура у Ruby. Практически все остальные языки не имеют столь развитой и популярной инфраструктуры в в данном контексте и потому вам скорее всего будут неинтересны.
Другими словами, если в среде разработчиков выбор языка — тема для холивара и эмоций с миллионами сравнительных анализов с противоположными результатами, то для специалистов по DevOps выбор очевиден и прозрачен. Java — это одновременно самые интересные задачи, самый богатый toolset, самый большой выбор вакансий и самые высокие зарплаты.

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

Итак, что делать:
1) Почитать книги Head First по Java. Пройти курсы Java на EDX.
2) Освоить SVN. Есть прекрасные тьюториалы. (GIT освоим позже)
3) Поставить VirtualBox (не VMWare. )
4) Написать простенькое приложение. Код коммитить в SVN. Собирать его при помощи maven.
5) Поднять на отдельной виртуалке Jenkins. Он должен брать код приложения на SVN и запускать свой локальный maven для сборки.
6) Написать модульные тесты (unit tests) своего кода. Пусть maven и их прогоняет.
7) Поднять где-нибудь Nexus. Усложнить задачу maven, чтобы он теперь складывал все в Nexus. Если maven’у потребуются внешние библиотеки, он тоже не сам должен ходить в интернет, а через Nexus (Central repo).
8) Настроить на своем десктопе vagrant так, чтобы он с нуля создавал виртуалки VirtualBox.
9) Создать виртуалку DEV через vagrant. При этом ansible должен на ней что-нибудь настроить (например установить JDK)
10) Научиться деплоить jar/war из Nexus на виртуалку DEV чем-нибудь. Чем — не посоветую, так как сам работаю с очень сложным IBM uDeploy, а это точно не для новичка. Посмотрите в сторону Rundeck или чего-то такого. Может самим Jenkins’ом задеплойте.
11) Напишите интеграционные АВТОтесты. На чем хотите (как вариант: Selenium).

Усложняем систему.
12) Донастраиваем Jenkins: собирает maven-проект; выкладывает на Nexus; дергает vagrant/ansible для создания виртуалки SIT (system integration test); деплоит приложение на SIT; прогоняет автотесты на SIT; удаляет виртуалку после успешного завершения автотестов.
13) Прикручиваем SonarQube в Jenkins для статического анализа кода. Исправляем косяки своего кода, согласно полученным от SQ рекомендациям.
14) Прикручиваем мониторинг Sensu.
15) Пишем нагрузочные тесты на чем-нибудь. В идеале потрогать два инструмента: jMeter и Gatling.
16) Как и в 12-м шаге прикручиваем в Jenkins автоматизацию создания виртуалки SLT (Stress/Load test) и прогона на ней тестов. Только уже лоад-тестов(обязательно) и стресс-тестов(опционально) соответственно.
17) Дописываем в свое приложение какой-нибудь функционал, чтобы использовалась база.
18) Придется познакомиться с LiquiBase. Деплой SQL руками делать запрещено.
19) Перейти на Docker (то есть теперь приложение выкладывать не напрямую в ОС, а внутрь докера)

20) Денек на то, чтобы почитать про Agile, Scrum, Waterfall и прочие организационные порядки.

А теперь немного уходим в управление проектом:
21) Поставить Atlassian Jira. Разобраться, чем отличаются Epic, Story, Task, Sub-Task. Создать себе подобной этой структуре фронт работ (делать его не придется, просто нафантазируйте).
22) Поставить Atlassian Stash и связать его с Jira.
23) Переехать со своего SVN на GIT, предоставленный Stash’ем.
24) Пройти Git-тьюториал какой-нибудь. Инструмент очень нетривиальный.
25) Взять любую таску в работу. При этом в начале работы сделать новый Git branch из тикета Jira.
26) По завершению работы запустить всю построенную ранее цепочку, но уже для своего брэнча.
Дайте попробую угадать: вам пришлось скопировать все джобы и переписывать в них ветки?
27) Сделать джобы нормально. Чтобы одни и те же можно было использовать для любых веток — по аналогии с принципом программирования «reuse code». У Вас будет reuse job :)
28) Сделать pull request, самому сделать code review и самому себя же за-approve’ить. После этого сделать merge своей ветки в master.
29) Сделать сборку брэнча автоматической по git-hook (или SCM pool)

30) А теперь высший пилотаж: к чертям Docker, Copistrano и прочую buzz-word-hipsters-галиматью. Теперь вы с этим знакомы и сможете применить, но пришло время выгрызать этот детский сад калёным железом. Теперь вы доставляете код только как .deb-пакеты. Это значит, что вы:
a) разбиваете control-файл на несколько пакетов, возможно с lib*,
b) оверрайдите все

20 dh_ в файле rules так, чтобы все это соответствовало вашим наработкам в предыдущих пунктах.
c) раскидываете файлы по .install
d) самое тяжелое: готовите .preinst, .postinst, .prerm, .postrm файлы СОГЛАСНО ИХ ПРИМЕРАМ .ex, сгенерированным dh_make — то есть с разбиемнием на update/configure/broken-install и что там еще есть. Это означает, что при переустановке, при апгрейде, при даунгрейде, при удалении и при пурдже, у вас будут разные сценарии, каждый из которых должен быть проработан досканально. На этом этапе вы также познакомитесь с понятием «регрессионные тесты».

Ну как бы базовый вариант вот. Но это далеко не весь инструментарий и путь. Это так, для начала.
Кроме этого неплохо бы познакомиться с Puppet (это не очень подходит для DevOps, скорее для рядовых админов с кучей серверов, но это очень популярный инструмент ввиду того, что никто не понимает, что такое DevOps и вас скорее всего заставят управлять сотней серверов, вместо релиз инжиниринга). А так же нужно познакомиться с операционными системами NixOS (обязательно) и CentOS/Debian (опционально, но я бы палкой бил тех, кто не знает эти OS). Кроме того, надо базово ориентирваться в PostgreSQL.

Внимание, важный момент, который должен быть вшит на уровень подсознания у DevOps-ориентированного инженера: вы все время пробуете новые инструменты. Вы всегда будете находить что-то очень отличное. Знаете Nexus как свои пять пальцев и он решает почти все проблемы? Отлично! Теперь выкидываете Nexus и ставите Artifactory. Знаете хорошо CentOS? Круто! Теперь пробуете все это проделать на Windows или Debian. Потому что только когда вы сможете сравнивать инструменты, ваша работа будет ювелирной. А DevOps бывает либо ювелирным, либо он не DevOps. Вы должны быть языко-независимым, платформо-независимым и инструменто-независимым.

Что будет дальше? Дальше вы начнете работать с микросервисами (сотни одинаковых контейнеров в облаке, которые должны как-то работать друг с другом без ручной конфигурации). Тогда познакомитесь со всякими Consul, ZooKepper и кучей инструментов AWS/OpenStack.


Статьи консультантов Cleverics

Можно утверждать, что появлению DevOps в наибольшей степени способствовали два фактора: развитие гибких методов разработки программного обеспечения и управление ИТ-инфраструктурой как программным кодом. Рассмотрим каждый из них.

Развитие гибких методов разработки программного обеспечения

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

Рис. Пример водопадной модели разработки программного обеспечения

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

Однако в конце 90-х годов XX века, с бурным развитием Интернет-технологий и web-программирования, недостатки водопадной модели стали достаточно негативно влиять на взаимодействие и взаимопонимание заказчиков (бизнес-подразделений компании, либо внешних организаций) и исполнителей (программистов компании, либо внешних разработчиков программного обеспечения). Действительно, появляющиеся рыночные возможности для основного бизнеса требовали быстрого, за считанные месяцы, вывода на рынок новых продуктов. В то время как типичный цикл разработки от начала проекта до получения первого работающего результата занимал от 6 до 18 месяцев, в крупных организациях – до 2-3 лет. Кроме того, в условиях появления ранее неизвестных, но потенциально перспективных рыночных возможностей требования заказчиков могли меняться по ходу проекта разработки, что было крайне сложно учесть при создании ИТ-системы без увеличения сроков, либо снижения качества выходных результатов.

Рис. Классическая пирамида взаимосвязанных ограничений проектного управления

Таким образом, накапливалось напряжение между заказчиками и исполнителями, между основным бизнесом и разработчиками ПО. Ответом на такой вызов стали инновационные подходы к программированию. Кен Швейбер (Ken Schwaber) выпустил несколько публикаций о Scrum. Кент Бек (Kent Beck) опубликовал книгу об экстремальном программировании, XP. Однако применение новых идей давало весьма скромные результаты, в основном потому, что такое применение фокусировалось лишь на одном из этапов цикла разработки ПО – на собственно программировании, при том что задача ставилась намного более широкая. Требовалось что-то, что позволит упростить и ускорить всю цепочку разработку программного обеспечения.

В 2001 году Кен, Кент, а также ещё пятнадцать товарищей отправили друг другу приглашения, а затем собрались обсудить имевшиеся проблемы и выработать решение. Итогом стал так называемый манифест Agile, призванный устранить разрыв понимания между бизнесом и разработчиками ПО. Один из авторов манифеста, Роберт Мартин (Robert C. Martin), поясняет:

«Используя правильные дисциплины и правильный минимальный процесс, может возникнуть и развиться доверие между разработчиками и бизнесом. Бизнес начнёт доверять разработчикам, вместо того, чтобы думать, что они ленивые, продажные, противные существа, а разработчики начнут обращать внимание на бизнес и осознают, что те являются разумными, рациональными существами, а не с какой-то другой планеты.»

Последовавшее развитие и принятие идей гибкой разработки сообществом программистов и менеджеров проектов сильно ускорили и перестроили разработку ПО.

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

Группа разработки ПО, применяющая гибкие подходы, выдаёт готовый к эксплуатации новый код каждые две-четыре недели. Конечные потребители плотнее вовлечены в создание продукта, а значит быстрая обратная связь значительно влияет на дальнейшее развитие продукта, что дополнительно добавляет вкуса к быстрым изменениям.

Однако во многих компаниях отказ от водопадной модели в пользу гибкой разработки даёт куда меньший эффект, чем ожидается. Такие наблюдаемые в работе многих компаний результаты связаны не столько с какими-то преимуществами водопадной модели или недостатками Agile. Зачастую полезный эффект нивелируется тем, что разработка кода – лишь одно из звеньев в цепочке создания ценности.

Цукерберг рекомендует:  Сниппеты гамбургер-меню

Действительно, до начала собственно разработки есть значительный блок работ, направленный на выявление бизнес-потребностей, их проработку, анализ, приоритизацию и так далее.

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

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

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

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

Управление ИТ-инфраструктурой как программным кодом

Возникновению управления ИТ-инфраструктурой как программным кодом предшествовало появление и развитие двух технологий: виртуализации и облачных вычислений.

История виртуализации программных и аппаратных сред началась довольно давно, в 1964 году, с началом разработки операционной системы IBM CP-40. За годы последовательного развития этого направления был достигнут весьма значительный прогресс. Коммерчески доступные системы появились для мейнфреймов (70-80-е годы прошлого века) и для более распространённых в последующем машин на архитектуре Intel x86 (80-90-е годы).

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

Вторая технология развивалась ещё более быстро. До середины 90-х годов прошлого века телекоммуникационные компании предлагали своим клиентам организацию частных глобальных вычислительных сетей (WAN, Wide Area Network) путём прокладывания соответствующих соединительных кабелей для каждой точки, каждого заказчика, от пункта А до пункта Б. Но с появлением технологии частных виртуальных сетей (VPN, Virtual Private Network) возникла возможность по одним и тем же каналам передачи данных отправлять пакеты разных клиентов, обеспечивая должный уровень безопасности, приватности и качества сервиса. Для наглядного отображения разграничения ответственности – где идёт «кабель от клиента», а где трафик попадает в общую разделяемую сеть, провайдеры стали использовать символ облака.

Клиенты, получившие возможность передачи данных на большие расстояния, стали использовать данные технологии не только для собственно обмена информацией между территориально удалёнными друг от друга системами, но и для распределения вычислительной нагрузки между разными узлами своих сетей. Напрашивалось появление технологии, упрощающей и удешевляющей такое взаимодействие. Небольшие провайдеры сделали первые шаги, а действительно масштабные изменения случились в 2006 году, когда компания Amazon представила своё решение ECC (Elastic Compute Cloud). Вскоре, в 2008 году, компания Microsoft запустила свой сервис, Azure, а компания Google – сервис Google App Engine, впоследствии развившийся в Google Cloud Platform. Это, разумеется, не единственные, но самые крупные примеры предоставления вычислительных мощностей в аренду.

Виртуализация и облачные технологии сильно изменили вычислительный ландшафт. Предлагаемые коммерческими провайдерами ресурсы стали доступными по стоимости, надёжными и обеспечивающими необходимый уровень безопасности. Отношение клиентов к облакам и их использование изменились от «кто-то другой где-то управляет моим железом» до «у меня есть инфраструктура, которой я управляю на расстоянии».

Что же это означает – управлять инфраструктурой на расстоянии? Вспомним одну из ключевых парадигм Unix-систем: все необходимые действия с системой можно произвести из командной строки (а значит – и с помощью скрипта). Графические оболочки являются красивым, но опциональным инструментом.

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

  • обосновать и согласовать бюджет (недели и месяцы)
  • дождаться очередного цикла закупки (месяцы)
  • заказать оборудование у поставщика и оплатить его (дни)
  • дождаться поставки (недели и месяцы)
  • получить, установить, настроить, подготовить к использованию (дни и недели)

Теперь аналогичную по характеристикам ИТ-инфраструктуру можно создать так:

  • запустить скрипт, дождаться окончания его выполнения (минуты, редко – часы)
  • оплатить счёт облачного провайдера в конце месяца

То есть необходимая инфраструктура создаётся с помощью программного кода. И не только создаётся, но и может управляться как программный код – с хранением версий, отслеживанием изменений, отладкой, повторным использованием прошлых наработок и так далее.

В завершении отметим также вторую жизнь, которую получили давно придуманные технологии, не получившие ранее широкого применения. К примеру, виртуализация на уровне операционной системы была доступна во многих UNIX-системах ещё в 80-е годы прошлого столетия. Однако серьёзный коммерческий успех этой технологии, которую чаще стали называть контейнеризацией, пришёл только во второй половине 2000-х, что совпадает по времени с событиями, описанными ранее. И если изначальный механизм chroot был довольно ограничен в функциональности и возможностях, то сейчас для контейнеров можно изолировать файловую систему, выделять дисковые квоты, ограничивать предоставляемые оперативную память, время процессора, ширину каналов ввода-вывода и так далее.

Неизбежность появления

Таким образом, рассмотренные истоки возникновения DevOps позволяют сделать следующие выводы.

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

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

Что за зверь — DevOps или Среда обитания диковинных профессий

Кто такой девопс? Какие функции выполняет devops-инженер в компании? Кому и зачем стоит присмотреться к этой профессии?

IT-сфера – одна из самых молодых и быстроразвивающихся сфер в мировой экономике. Технологии и бизнес-процессы усложняются, а объем задач растет. Поэтому в сфере информационных технологий появляются все новые специальности, требующие особых навыков и компетенций. К новым специальностям относится и DevOps-инженер. Эти специалисты участвуют в разработке, внедрении и сопровождении IT-продукта или сервиса, они вовлечены во все этапы работы над продуктом.

DevOps – это акроним от английского development и operations. То есть методология, при которой объединяются два разных направления работы над конечным программным продуктом или сервисом — разработка и администрирование. Разработчик (программист) отвечает за развитие IT-продукта – создание нового, а системный администратор следит за бесперебойной работой уже созданной системы. Разрыв между этими ролями может быть настолько велик, что при наихудшем сценарии разработчик может создать такой продукт, который не будет качественно работать из-за постоянно возникающих критических ситуаций. Для формирования отказоустойчивой программной структуры и предугадывания всех возможных ошибок еще на этапе разработки идеи требуется DevOps-инженер.

Он устанавливает связь между всеми этапами работы над продуктом, отлаживает и автоматизирует цикличный процесс разработки, тестирования, администрирования и новой разработки. Наличие должности девопса в IT-компании позволяет избежать авралов, глобальных поломок и развивать продукт эволюционно – от версии к версии.

✔ Развертывание и сопровождение проектов и приложений
✔ Обеспечение бесперебойной работы информационных систем компании
✔ Участие в разработке документации к внедряемым системам и решениям, поддержание документации в актуальном состоянии
✔ Поиск путей автоматизация процессов тестирования и сопровождения информационных систем
✔ Поиск путей оптимизации временных, программных и человеческих ресурсов
✔ Постоянный мониторинг инфраструктуры

Девопс смотрит на ошибки программного кода как на неотъемлемую часть проекта, его задача – минимизировать их количество и последствия для пользователя и ускорить их исправление для следующего релиза. Поэтому правило DevOps-методологии – частые релизы продукта, в которых быстро исправляются текущие ошибки.

DevOps – редкая птица на сайтах вакансий, хотя под именем DevOps-инженера может подразумеваться просто системный администратор. Как и многие другие IT-специальности, должность девопса хорошо оплачивается:
60 000 – 240 000 рублей в месяц

Какие универсальные компетенции нужны девопсу в работе

✎ Аналитический склад ума
✎ Умение видеть и решать проблему
✎ Умение быстро осваивать сложные архитектуры и решения, в том числе сложные многослойные системы, состоящие из 3-4 ландшафтных архитектур
✎ Терпеливость
✎ Стрессоустойчивость
✎ Методичность
✎ Любознательность
✎ Постоянное саморазвитие
✎ Обучаемость
✎ Умение работать в команде
✎ Умение принимать решения
✎ Умение делегировать полномочия
✎ Внимательность к деталям

Как стать DevOps-инженером

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

Выбор профессии девопс-инженера трудно сделать в подростковом возрасте, потому что эта профессия отличается преобладанием практики над теорией. Девопсами становятся опытные айтишники, у которых появился интерес к методологии повышения эффективности в результате работы над реальными проектами. IT-специалиста этого направления отличает творческий подход к работе, энтузиазм и желание довести продукт до конечного пользователя. Если вам интересна IT-сфера, программирование, создание высокотехнологичных и качественно работающих продуктов, то в дальнейшем вы сможете стать DevOps-инженером.
Что можно сделать, чтобы им стать:

    ✔ При обучении в школе важно не ограничиваться только уроками информатики, но глубже интересовать сферой информационных технологий.
    ✔ Посещать кружки по программированию, робототехнике.
    ✔ Посетить iСмену и TechСмену в лагере «Профессионалы будущего», где занятия проводят настоящие айтишники, и в том числе специалисты DevOps.
    ✔ Проходить стажировки в IT-компаниях, как небольших стартапах, так и корпорациях (вроде, Microsoft или Яндекс). Только в реальных полевых условиях вы сможете понять, как строится цикл создания IT-продукта: от зарождения идеи до ее реализации. На стажировках вы сможете познакомиться и пообщаться с настоящими девопс-профессионалами.

Чтобы понять, подходит ли вам профессия девопса и работа в IT-сфере, пройдите наш бесплатный тест «Информационно-технологический профиль».

Автор: Ольга Биккулова, ЦТР «Гуманитарные технологии»

Если вы хотите получать свежие статьи о профессиях, подпишитесь на нашу рассылку.

Что такое DevOps?

Узнайте, как DevOps объединяет людей, процессы и технологии, помогая вам совершенствовать свои продукты и быстрее предоставлять их клиентам.


Определение DevOps

DevOps — это сочетание разработки (Dev) и эксплуатации (Ops). Это объединение людей, процессов и технологий, позволяющее постоянно предоставлять преимущества клиентам.

Что DevOps означает для сотрудников? DevOps позволяет представителям ранее разрозненных подразделений — разработки, ИТ-операций, обеспечения качества и безопасности — координировать свои действия и совместно создавать более качественные и надежные продукты. Внедрив культуру DevOps вместе с соответствующими методиками и инструментами, команды получают возможность лучше реагировать на потребности клиентов, повышать доверие к создаваемым приложениям и быстрее достигать бизнес-целей.

Преимущества DevOps

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

Быстрый выход на рынок

Адаптация к условиям рынка и конкурентной среде

Поддержание стабильности и надежности системы

Сокращение среднего времени восстановления

DevOps и жизненный цикл приложений

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

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

Разработка

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

Доставка

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

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

Использование

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

Культура DevOps

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

Совместная работа, прозрачность и согласованность

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

Изменения в сфере участия и ответственности

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

Сокращение циклов выпуска

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

Непрерывное обучение

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

Узнайте, как команды в Майкрософт внедрили культуру DevOps

Методики DevOps

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

Непрерывные интеграция и поставка (CI/CD)

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

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

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

Управление версиями

Управление версиями — это методика работы с кодом в версиях, то есть отслеживание исправлений и истории изменений для упрощения анализа и восстановления кода. Эта методика обычно реализуется с помощью систем управления версиями, таких как Git, которые позволяют нескольким разработчикам совместно работать над созданием кода. Эти системы обеспечивают четкий процесс объединения изменений кода в одних и тех же файлах, разрешения конфликтов и отката изменений до более ранних состояний.

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

Управление версиями также является необходимым элементом в других методиках, таких как непрерывная интеграция и инфраструктура как код.

Гибкая разработка программного обеспечения

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

С гибкой методикой связаны две популярные концепции — канбан и Scrum.

Инфраструктура как код

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

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

Управление конфигурацией

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

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

Непрерывный мониторинг

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

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

Инструменты DevOps

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

DevOps и облако

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

Облачная гибкость

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

Цукерберг рекомендует:  Design - Вопрос к студентам дизайн направления

Kubernetes

Так как контейнерные технологии все чаще используются в приложениях, Kubernetes становится отраслевым решением для оркестрации контейнеров в нужном масштабе. В эпоху Kubernetes автоматизация процессов сборки и развертывания контейнеров с помощью конвейеров CI/CD и их мониторинг в производственной среде становятся основополагающими методиками.


Бессерверные вычисления

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

Кто такой DevOps-инженер, и чем он занимается

Ранее я рассказал о том, что такое методология DevOps и кому она нужна. Сегодня — фокус на DevOps-специалистах: их задачах, зарплатах и навыках.

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

Кто такой DevOps-инженер

DevOps-инженер занимается внедрением методологии DevOps. Он синхронизирует все этапы создания программного продукта: от написания кода до тестирования и выпуска приложения. Такой специалист контролирует отделы разработки и администрирования плюс автоматизирует выполнение их задач, внедряя различные программные инструменты.

Фишка DevOps-инженера в том, что он совмещает множество профессий: админа, разработчика, тестировщика и менеджера.

Джо Санчес, DevOps-евангелист из VMware, компании-разработчика программного обеспечения для виртуализации, выделил ряд навыков, которыми обязан обладать DevOps-инженер. Помимо очевидного знания методологии DevOps, этот человек должен иметь опыт администрирования ОС Windows и Linux и опыт работы с инструментами автоматизации вроде Chef, Puppet, Ansible. Еще он должен уметь писать скрипты и код на паре-тройке языков и разбираться в сетевых технологиях.

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

Кто нанимает

DevOps-инженеры могут принести пользу любой организации, чья деятельность связана с разработкой приложений или управлением большим количеством серверов. DevOps-инженеров нанимают ИТ-гиганты вроде Amazon, Adobe и Facebook. Еще они работают на Netflix, Walmart и Etsy.

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

Сколько платят

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

В США они получают 90 тыс. долларов в год (500 тыс. рублей в месяц). В Канаде им платят 122 тыс. долларов в год (670 тыс. рублей в месяц), а в UK — 67,5 тыс. фунтов стерлингов в год (490 тыс. рублей в месяц).

Что касается России, то московские компании готовы платить DevOps-специалистам от 100 до 200 тыс. рублей в месяц. В Санкт-Петербурге работодатели чуть щедрее — предлагают 160–360 тыс. рублей в месяц. В регионах указывают зарплату 100–120 тыс. рублей в месяц.

Как стать специалистом по DevOps

DevOps — это относительно новое направление в IT, поэтому устоявшегося перечня требований к DevOps-инженерам нет. В вакансиях среди требований на эту должность можно встретить как навыки администрирования Debian и CentOS, так и умение работать с дисковыми RAID-массивами.

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

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

Чтобы понять, где знаний пока не хватает, можно воспользоваться мини-википедией на GitHub или ментальной картой. Резиденты Hacker News также рекомендуют почитать книги «Проект «Феникс», «Руководство по DevOps» от авторов методологии и «Философия DevOps. Искусство управления IT» под грифом O’Reilly Media. В списке рекомендаций есть и другая литература, заточенная под развитие отдельных навыков, например «Современное администрирование Linux» от того же издательства O’Reilly.

Еще можно подписаться на рассылку Devops Weekly, почитать статьи тематического портала DZone и начать общаться с DevOps-инженерами в Slack-чате. Еще стоит изучить бесплатные курсы на Udacity или edX.

Что еще почитать в выходные:

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Когда «веб-дизайнер» перестало быть круто, их стали называть «UX специалисты». Когда сисадмины захотели больше денег, они стали называть себя «DevOps-инженеры».

Когда разрабы поняли что они разрабы, стало грустно им. Они стали писать software engineer.

И это тоже, собственно появление «архитекторов» тоже из этой серии.

девопс это сисадмин который освоил немного кодинга.

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

не просто понимание, но и не меньше, чем волшебно взявшееся 1-3 года опыта такой работы. Chef, Puppet, Ansible, Jenkins

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

типичная работа мартышки на нижнем уровне it иерархии.

постройте архитектуру

типичная работа мартышки

Хочу узнать, чем в вашем мире занимаются высшие уровни IT-иерархии.

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

работа девопса это такой tech ради tech. некоторых прет, ну и ок :)

Слишком жирно, попробуйте потоньше.
DevOps как минимум обязан уметь в развертывание. Разработчики обычно не умеют в это. Я встречал сеньоров, не имеющих представления, как для продакшна настраивать тот же nginx и как работает reverse proxy.

DеvOps начался намного раньше получения красивого названия в 2009

И когда же, интересно узнать?

Внезапно с момента появления компьютеров.

DevOps — это относительно новое направление в IT

Относительно новое это DevSecOps, а DevOps уже минимум 15 лет существует.

Боюсь, что с 15 годами вы перегнули. Считается, что термин DevOps был впервые использован на конференции O’Reilly в 2009 году (презентация сотрудника Flickr «10+ Deploys per Day: Dev and Ops Cooperation»). Альтернативная версия по вики — конференция devopsdays (тоже 2009 год).

Не думаю, что вакансии именно с такой формулировкой появились раньше, что уж говорить про должностные инструкции и понимание каких-то относительно единых требований к DevOps-инженерам. DevSecOps — это просто специализация, не меняющая сути. Про это есть тред на кворе с диаграммами Венна https://www.quora.com/What-is-the-difference-between-DevOps-and-DevSecOps

Первая версия Puppet вышла в 2005 году

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

Комментарий удален по просьбе пользователя

да не, смотря какие кодеры)
если партия скажет — надо, комсомольцы ответят — есть!

Бред. Девопс это сисадмин для программистов.
Кто такой продакт?

Ну DevOps, по сути, связующее звено в организации работы разработчиков непосредственно и практиков, если я всё правильно понимаю

Бредятина. Стартап возьмёт девопса, а не трёх технарей с выделенными ролями. Девопс, это development operations. Он занимается автоматизацией процесса разработки. Он не менеджер и не тестировщик.

Задача ИдеальногоDevOps (ТМ) — лишить эту позицию смысла. Автоматизировать все и тихо уйти=)

В статье (как и предыдущей, автору респект за качество) в основном рассматривается пример приложений. Тут все сильно зависит от нативности/кроссплатформенности разработки, расскажу про пример связанный с большими данными.

Есть кластер hadoop, отличное решение, к тому же open source. Есть python, под который уже есть терабайты удобных и полезных библиотек. Есть дата аналитик, который может в питон и математику.

Но все данные, необходимые аналитику хранятся на кластере, который питон не принимает. Зато отлично понимает java/scala. Поэтому чтобы создать самую простую модель на имеющихся данных devops будет нужен минимум дважды — выгрузить на локальную машину данные для создания модели и её проверки, а потом выкатить готовую модель на прод.

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

Если есть постоянная необходимость в человеке за $100 000 для автоматизации, нужно найти способ реально автоматизировать процесс, а не через белковую прокладку. В работе с hadoop мы так и сделали, теперь экономим и продаем как коробочное решение.

PS. Переживающим за судьбу наших devops — автоматизировав и упаковав, они преквалифицировались в продакт овнеров


Как стать DevOps-инженером за полгода или раньше? Часть 1

Примечание: это первая часть из цикла статей, посвященных DevOps.

Целевая аудитория

Вы разработчик и хотите направить свою карьеру в DevOps русло?

Или вы IT-специалист и хотите получить представление о том, что же такое DevOps?

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

Если ответ на все вышеперечисленные вопросы — да, то наш цикл статей призван помочь вам во всем этом разобраться!

Кстати, даже если вы много лет занимаетесь DevOps, то данная статья все равно может стать полезной для вас.

Что же такое DevOps?

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

Что же, для вас я очистил определение от лишнего мусора и вот что получилось:

DevOps- это способ доставки программного обеспечения до конечного потребителя через коллективные боль и ответственность.

Хорошо, но что же это значит на самом деле?

Это значит, что, испокон веков, разработчики (люди, создающие программное обеспечение) имеют совершенно другие мотивы, нежели IT-специалисты (люди, которые запускают программное обеспечение).

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

Однако, как IT-специалист, мне нужно внедрить в продукт как можно меньше функций, так как каждая новая функция — это перемены, а перемены рискованны.

В результате этого разительного контраста и зародился DevOps.

DevOps пытается объединить разработку и обслуживание ПО в один рабочий процесс. Идея заключается в том, что коллектив будет делить между собой как боль, так и ответственность (и, предположительно, вознаграждение) за создание, внедрение и получение дохода от программного обеспечения, ориентированного на клиента.

Пуристы скажут вам, что не существует такого понятия как «DevOps-инженер». «DevOps — это культура, а не должность» — будут они вам говорить.

Да, да мы поняли. Технически они правы, но, как часто бывает, термин в конце концов вышел за рамки своего первоначального смысла.

Теперь, DevOps-инженер — это что-то вроде «Программного инженера версии 2.0»

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

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

Обратите внимание, что если вы выберете в качестве карьеры DevOps сферу, вы легко сможете найти себе рабочее место, так как сейчас почти все компании поддерживают DevOps. Ну либо утверждают, что поддерживают.

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

ПРИМЕЧАНИЕ: Будьте осторожны с объявлениями, наподобие: «Требуется DevOps-команда» или «DevOps-отдел». Грубо говоря, такие объявления не должны существовать, так как DevOps — это культура и «способ доставки» программного обеспечения, а не специальный отдел или команда.

Дисклеймер

Теперь, отставим стакан газировки в сторону и рассмотрим следующее.

Слышали ли вы когда-нибудь изречение о том, что «в DevOps нет junior-инженеров»?

Если не слышали, то знайте, что это очень популярный троп на таких платформах как Reddit и Stack Overflow. Но что он означает?

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

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

Однако! Существует примерно согласованный (трендовый, если вам так удобнее) список инструментов и концепций, которые используют большинство компаний. О них и пойдет речь в этой статье.

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

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

Достаточно болтовни, с чего мне начать?

Ниже дан план, который приведет вас к желаемой должности.

Если вы пройдете его от начала до конца, то сможете смело называть себя DevOps-инженером! Или Cloud-инженером, если вам не нравится предыдущее название.

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

ПРИМЕЧАНИЕ: Вы должны преодолеть этот путь шаг за шагом. Начните с фундамента, не пропускайте его! Сначала изучите технологии, помеченные синим цветом (Linux|Python|AWS), затем, если позволяет время или этого требует нынешний рынок труда, изучите технологии, помеченные фиолетовым (Golang|Google Cloud).

Повторюсь, синий цвет обязателен, а фиолетовый нужен для углубления уже имеющихся знаний.

После того, как вы усвоите весь «фундамент», переходите к изучению навыков, использующихся в реальных «боевых» условиях:

ПРИМЕЧАНИЕ: В схеме выше намеренно отсутствуют навыки, необходимые для тестирования ПО. Написание блоков кода, интеграция, приемочное тестирование традиционно ложатся на плечи разработчиков. Упущение фазы «тестирования» является преднамеренным действием, так как цель данной статьи — быстрое освоение новых навыков и инструментов. По мнению автора статьи, отсутствие опыта в тестировании — крайне незначительная помеха для трудоустройства.

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

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

Хорошо, копнем немного глубже!

Фундаментальные знания

Вверху статьи есть план под названием «Фундамент» с навыками, которыми должен овладеть любой DevOps-инженер.

В нашей отрасли, прежде всего, вы должны знать 3 столпа: операционную систему, язык программирования и открытый облачный сервис. У вас не получится быстренько пройти их, вычеркнуть из списка дел и двигаться дальше. Эти навыки вам придется постоянно повторять, постоянно быть в курсе всех изменений происходящих с ними и, по надобности, доучивать какие-то аспекты.

Давайте разберем эти три столпа шаг за шагом.

Linux

Linux: там, где происходит вся магия. Можно ли быть DevOps-инженером, оставаясь при этом в экосистеме Microsoft? Конечно вы можете! Не существует закона, который бы предписывал работать исключительно в системе Linux.

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

Как проще всего выучить Linux? Установите на домашний компьютер дистрибутивы Fedora или Ubuntu и используйте их как можно чаще! В процессе использования вам не раз придется ломать и чинить систему, сталкиваться с различными проблемами, благодаря которым, в конце концов, вы познаете Linux.

Для справки, в Северной Америке очень распространен дистрибутив Linux от компании Red Hat. Поэтому имеет смысл начать с Fedora или CentOS. Кстати, если не можете выбрать графическое окружение — KDE или Gnome, ставьте KDE. Его использует Линус Торвальдс.

Python

Python: самый распространенный язык для back-end’а в наши дни. С него легко начать, и он повсеместно используется во многих сферах. Бонус: Python широко распространен в сфере искусственного интеллекта и машинного обучения, поэтому, если решите этим заняться в будущем — вам практически ничего не придется учить.

Amazon Web Services: Без понимания того, как работает открытый облачный сервис невозможно стать DevOps-инженером. Amazon Web Services, пожалуй, лучшее место для изучения всей отрасли, так как он предлагает наиболее богатый набор инструментов для работы.

Вы спросите, можно ли начать с Google Cloud или Azure? Безусловно! Но после серьезного падения доллара, самым безопасным вариантом, по крайней мере, в 2020 году остается AWS.

При регистрации на AWS, вы получаете бесплатный уровень пользования сервисом на 1 месяц.


Когда вы залогинитесь в AWS, вас поприветствует простое и понятное меню выбора их продуктов.

Шучу, это был сарказм. Хорошая новость в том, что вам не нужно знать каждую функцию AWS.

Начните со следующего: VPC, EC2, IAM, S3, CloudWatch, ELB и всех продуктов из меню «Безопасность, идентификация и соответствие требованиям». Этого достаточно для начала работы с облачными сервисами.

У AWS есть собственный веб-сайт предназначенный для изучения их функций и это отличное место для начала обучения.

Я рекомендую вам уделять хотя бы по 30 минут в день на практику Python, Linux и AWS.

ПРИМЕЧАНИЕ: В целом, я считаю, что тратить ежедневно по часу, пять раз в неделю, достаточно для того, чтобы за 6 месяцев или меньше сложилось четкое представление о том, что происходит в DevOps сфере.

Но это касается только фундаментальных знаний!

В следующих статьях нашего цикла мы рассмотрим этапы: Конфигурирования, Версии, Пакеты, Внедрение, Запуск и Мониторинг программного обеспечения полностью автоматизированным способом.

ИТ База знаний

ShareIT — поделись знаниями!

Полезно

Узнать IP — адрес компьютера в интернете

Онлайн генератор устойчивых паролей

Онлайн калькулятор подсетей

Калькулятор инсталляции IP — АТС Asterisk

Руководство администратора FreePBX на русском языке

Руководство администратора Cisco UCM/CME на русском языке

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Похожее и популярное

Пошаговый ввод в домен Windows 10

Apache или IIS – сравнение и преимущества

Погружение в Iptables – теория и настройка

Как восстановить пароль от root в CentOS 7

DevOps – это философия будущего: кто, что и как?

В контексте Azure DevOps

Софт DevOps (англ. development и operations) имеет очень большое значение для огромного количества людей, которые занимаются разработкой программного обеспечения. Для того, чтобы разобраться, что такое программа/путь DevOps и как правильно ее использовать на практике, стоит подробнее поговорить о происхождении этого набора техник.

Что такое практика DevOps?

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

  1. Непосредственное создание программного обеспечения, направленного на решение тех или иных производственных задач.
  2. Тестирование промежуточных версий или уже готовых продуктов программного обеспечения.
  3. Эксплуатация и тестирование готовой продукции на практике.

Коротко: DevOps специалист должен знать сети (маршрутизацию, коммутацию) хотя бы на уровне CCNA, знать и уметь пользоваться Linux (знать CLI, основные принципы) и уметь программировать. Желательно фуллстэк – то есть фронтенд часть и бэкенд. Идеально уметь программировать на Python :) Вот что такое DevOps.

Именно из этих фаз и состоит DevOps. В результате разработки, тестирования и эксплуатации и создаются все условия, которые так необходимы для качественного использования того или иного софта. Чаще всего используются следующие инструменты:

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

Графический интерфейс Azure DevOps имеет следующий внешний вид:

Для чего нужны циклы DevOps?

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

Цукерберг рекомендует:  Обучение - Помогите с задачей
В чём суть DevOps?

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

Какие инструменты имеются в наборе DevOps?

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

  • Code — набор полезных инструментов, используемых в качестве основных способов анализа кода в программе;
  • Build — набор инструментов, благодаря которым можно получать огромное количество информация касательно интеграции одного элемента программы в другой, а также получать статус сборки;
  • Тест — пакет программ для всестороннего изучения промежуточных версий или готового продукта. При этом, данные инструменты включают в себя различные возможности, направленные на тестирование программы под разными нагрузками.
  • Для создания промежуточных версий подойдёт инструмент под названием Пакет. При этом, в пакет входит набор артефактов и автоматическая установка приложения. С помощью данного набора программ можно создать всевозможные условия, под которыми основной продукт будет распространяться на персональные компьютеры или мобильные телефоны конечного потребителя.
  • Релиз — ещё один пакет программ, позволяющий управлять изменениями в готовом продукте. Самое интересное, что сюда входят пакеты программ, предназначенных для налаживания выпуска и утверждения определённых партий.
  • Для управления конфигурациями нужно налаживать инфраструктуру. Одноимённой пакет программ нужен для того, чтобы положить определенную коммуникацию между элементами производства. Всё, что с этим связано, может быть использовано в качестве основных инструментов для реализации ряда идей, связанных с прокладывания инфраструктуры.
  • И, наконец, сюда входит так называемый мониторинг, целиком и полностью предназначенной для отладки ошибок, использования готового продукта, а также создания различных условий для его эксплуатации. Сюда можно отнести различные тесты и прочие синтетические инструменты определения эффективности работы программы.
Главные участники DevOps

Практика включает в себя следующих участников:

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

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

Для чего нужно использовать DevOps?

DevOps решает следующие цели:

  1. Перво-наперво, это максимальное сокращение затраченного на разработку времени. При этом, сокращение ведёт не только к удешевлению конечного продукта, но ещё и отсутствию срывов дедлайна. Таким образом, конечные продукты смогут выходить гораздо чаще и стабильнее. При этом, это касается как полноценных программ, так и всевозможных патчей вместе с исправлениями.
  2. Те компании, которые практиковали DevOps, теперь реже отказываются от новых разработок и релизов.
  3. Само собой, с первым пунктом также уменьшилось количество исправлений, связанных с критическими ошибками. Теперь выпускать патчи стало гораздо удобнее для разработчика и издателя.
  4. В том случае, если во время создания того или иного продукта произошёл сбой, восстановиться гораздо проще, нежели это было раньше. Это неудивительно, ведь автоматизированное производство позволяет заменить недостающие элементы на другие, при этом не подставив весь штат.
В чём заключаются основные преимущества DevOps?

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

Полезна ли Вам эта статья?


Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

Введение в культуру DevOps: о практиках и роли DevOps инженера

Любая компания, связанная с разработкой или внедрением программного обеспечения, стремится двигаться быстрее и быть как можно гибче. Для этого требуется максимальная вовлеченность разработчиков во все стадии жизненного цикла процесса разработки ПО. Давайте задумаемся, с чего начинается и чем заканчивается этот цикл программного обеспечения. Начинается с планирования — это знают практически все. Но чем он заканчивается? Деплойментом? А куда и как мы деплоимся? Когда заканчивается вовлеченность разработчика в процесс? Стоит ли ему вовлекаться в принципе? И вообще, важно ли то, на какой платформе будет размещаться написанное тобою ПО. Важны ли ресурсы, которые вы под него отведете? Как быстро вы будете обновлять его? Давайте проследим эволюцию процесса.

Как было раньше

Когда только начиналась промышленная разработка программного обеспечения, каждый разработчик был сам себе бизнес-аналитик, архитектор, верстальщик, девелопер, тестировщик, девопс и поддержка 24/7 в одном флаконе. Какие это таило в себе недостатки? Иногда получались достаточно корявые и не понятные для стороннего пользователя продукты. Трудно было представить, что творилось в голове того или иного индивида. И еще один минус — сосредоточение всех сакральных знаний в одной светлой голове, которая могла заболеть, уйти к конкурентам, да и просто уехать отдыхать на Гоа. Однако в этом были и плюсы. Инженер сразу задумывался о полном цикле жизни своего продукта. Тут не было надежды на всемогущего админа, который придет и все порешает за тебя. За любой косяк приходилось выгребать самому и расплата не заставляла себя долго ждать.

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

Почему появилась культура DevOps

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

Если первый фактор еще может показаться достаточно спорным, то второй — более однозначный. Это широкое развитие облачных сервисов, отказ от хостинга на своих серверах и поддержки своей инфраструктуры как таковой. Выбранная инфраструктура начала определять архитектуру приложения. AWS, Azure, Heroku, DigitalOcean начали делать за вас вашу работу. Теперь не надо без особой потребности придумывать 1001 вариант написания балансера или шардинга — это все доступно из коробки. Это снизило количество велосипедов на квадратный метр, но этот подход, в свою очередь, требует знания инфраструктуры сервисов и адаптации своих продуктов под них.

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

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

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

Практики DevOps

Теперь давайте поговорим о практиках DevOps. Они достаточно неплохо описаны в книге «DevSecOps The Road to Faster, Better and Stronger Software». Давайте рассмотрим главные из них.

«Automate everything» — автоматизируй все, что можно. Уменьшай количество «ручной» операционной работы. Делаешь, что-то два раза — придумай, как это автоматизировать. Это ускорит все процессы и сведет количество ошибок к минимуму. Работать должен робот, человек должен отдыхать и заниматься мыслительным процессом!

«Configuration management». Docker приходит к нам на помощь в конфигурации, сохранении и менеджменте всего, что нам нужно для успешной работы приложения. Оркестрация контейнеров может осуществляться при помощи таких тулов, как Kubernetes или Docker Swarm.

«Infrastructure as Code». Подразумевается, что подход к конфигурированию приложений должен быть таким же, как и к коду. Если раньше в конфигурации системы через консоль не было ничего зазорного, то сегодня стало уже плохим тоном не использовать для этих целей инструменты автоматизации, такие как Terraform, Chef, Puppet и т. д. Эта практика позволяет оптимизировать ресурсы, а также значительно ускорить время поставки.

«Continuous Deployment». Автоматическое выкатывание готовых фич на рабочее окружение. И если раньше CD системы были игрушкой только для разрабов, то теперь они активно используются для автоматизации накатки изменений в конфигурациях. Эта практика позволяет оптимизировать ресурсы, а также сводит участие человека в процессе поставки к минимуму.

«Application monitoring». Если раньше системы мониторинга представляли из себя различные способы «скирдования» логов, то теперь это мощный инструмент для мониторинга состояния вашего приложения. На анализ логов не надо тратить дни и недели, вы можете настроиться на ту или иную метрику и смотреть за изменениями в режиме реального времени. Мало того, кроме сугубо технических моментов, например количества запросов, перформанса, загрузки CPU, вы с помощью таких систем, как Prometheus, можете собирать и внутренние характеристики приложения, значимые для вашего бизнеса.

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

Выводы

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

Эта статья — нулевая в цикле материалов по DevOps практикам. В течение месяца я буду писать по одной статье, которая будет давать введение в культуру DevOps. Цикл будет включать такие темы:

Как перейти из системного администрирования в DevOps

Содержание:

DevOps-инженеров не выпускают вузы и не готовят с нуля специализированные курсы – на новую для IT позицию большинство специалистов приходят из системного администрирования. Такой карьерный маневр позволяет сисадмину повысить профессиональную квалификацию, не переходя в разработку. Если вас заинтересовала эта возможность, то статья поможет вам сформировать представление о концепции DevOps и работе DevOps-инженера .

DevOps как концепция

Как DevOps меняет разработку ПО

Когда-то Agile существенно изменил процесс разработки в IT, а сегодня на индустрию так же сильно влияет DevOps. Первыми применять новую концепцию начали крупные корпорации, вроде Amazon и Facebook, которые стремились внедрять новые сервисы в свои продукты как можно быстрее. Сегодня DevOps практикуют компании по всему миру, что помогает им адаптироваться к современным IT-тенденциям: усложнению IT-инфраструктуры, переходу от физических платформ к виртуализации, необходимости частых обновлений приложений в ответ на запросы пользователей.

Несмотря на популярность DevOps, все еще не существует единой трактовки самого понятия. Чаще всего DevOps описывают как современную IT-методологию, когда фазы разработки и эксплуатации объединяются в один процесс для ускорения доставки ПО.

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

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

Практики DevOps

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

Непрерывная интеграция (Continuous Integration) – процесс, при котором разработчики ежедневно синхронизируют новую часть кода с основной веткой в системе контроля версий. Как правило, после сборки проекта запускаются автоматизированные тесты. Если будет обнаружена ошибка, то разработчик сразу получит оповещение и сможет приступить к исправлению дефекта.

Непрерывная доставка (Continuous Delivery) – практика, при которой проект после сборки попадает в тестовую среду, где проходит финальное тестирование перед установкой на серверах заказчика. В результате команда получает готовый к развертыванию релиз.

Непрерывное развертывание (Continuous Deployment) – процесс работы с релизом идет так же, как при непрерывной доставке. Но в данном случае изменения в исходном коде, как только проходят через этап QA, автоматически (без участия разработчиков) развертываются на рабочих серверах. В результате заказчик и пользователи получают обновления программы сразу после того, как они будут подготовлены.

DevOps как профессия

Когда менеджмент решает перейти к DevOps, команде IT-проекта нужно освоить конкретные практики и новые инструменты. В таком случае придется нагружать дополнительными задачами либо программистов, либо системных администраторов. Лучше нанять профессионала, который уже понимает суть DevOps и может помочь настроить все необходимые процессы. Так IT-сектору понадобился специалист с новым сочетанием навыков на стыке системного администрирования и программирования – DevOps-инженер. В Беларуси, по данным портала dev.by, DevOps-инженеры зарабатывают в среднем в два раза больше, чем системные администраторы. Такая разница обусловлена тем, что компетентный DevOps-инженер может повысить эффективность всего процесса разработки и зона его ответственности шире, чем у системного администратора.

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

Если спросить DevOps-инженера, чем он занимается, то, скорее всего, он ответит «автоматизацией». Под таким определением скрывается целый спектр задач, которые можно условно разделить на три блока:

  • Автоматизация процессов доставки релизов из производственной среды в эксплуатацию.
  • Управление физическими и виртуальными серверами и их конфигурацией.
  • Мониторинг состояния инфраструктуры и поведения приложений.

Одна из основных задач DevOps-инженера – настроить платформы и инструменты для непрерывной интеграции, доставки или развертывания кода. Для автоматической сборки проекта и развертывания на серверах могут использоваться программы Jenkins, TeamCity, GoCD или Bamboo. DevOps-инженер пишет скрипт с последовательностью команд, которые один из этих инструментов автоматически выполняет на серверах.

Раньше системные администраторы настраивали каждый сервер вручную. Сегодня DevOps-инженер следует подходу «инфраструктура как код» (IaC), когда все скрипты для настройки серверов, как и код разработчиков, сохраняются в системе контроля версий. Удаленно координировать работу всех физических или виртуальных серверов можно через системы Chef, Puppet, Ansible или Kubernetes.

Для мониторинга состояния инфраструктуры DevOps-инженер может использовать системы Zabbix, Nagios или Prometheus. Например, Zabbix позволяет контролировать работу серверов, сетевого оборудования, баз данных и веб-приложений.

Что нужно знать системному администратору, чтобы стать DevOps-инженером

Опыт системного администратора – хорошая отправная точка для карьеры DevOps-инженера. Осталось дополнить этот бэкграунд специфическими для DevOps навыками.

Опыт администрирования ОС

Чтобы практиковаться в работе с операционной системой Linux, можно установить дистрибутивы Fedora или Ubuntu на своем компьютере. Если хотите в целом подтянуть свои знания в администрировании, то можно записаться на курсы. Например, в Минске в образовательном центре ПВТ программа по Linux длится месяц, а на образовательном портале Microsoft есть бесплатный курс по администрированию Windows Server.

Знание программирования

DevOps-инженеру нужно знать скриптовые языки программирования (Bash, Perl), на которых пишутся сценарии для настройки автоматизации. Чтобы повысить квалификацию, можно выучить один из языков общего назначения, например, Java или Python. Это поможет лучше понимать код разработчиков.

Понимание работы с облачными сервисами

Сегодня наиболее востребованы облачные платформы от Amazon и Microsoft. Основные сервисы AWS, с которыми работает DevOps-инженер, – EC2, VPC, S3, RDS, ELB, EBS. Дополнительно можно изучить ECS, CloudFormation, OpsWorks, CloudWatch. Если вы еще не работали с AWS, то можете зарегистрироваться на официальном сайте – и получите годовой бесплатный доступ ко многим продуктам компании. Узнать больше об инструментах платформы поможет специализированный портал. Microsoft в конце 2020 года расширила список сервисов для платформы Azure DevOps. Для знакомства с ними можно выбрать бесплатные курсы на образовательном портале Microsoft.

Навыки работы с контейнерами

Контейнеры – это изолированные структуры, в которых можно развертывать приложения независимо от основной операционной системы. По сравнению с виртуальными машинами, контейнеры меньше весят и быстрее запускаются. Самый популярный инструмент для работы с контейнерами – Docker. И разработчик, и DevOps-инженер могут одновременно работать в Docker-контейнере. Пока разработчик пишет код самого приложения, DevOps-специалист создает конфигурационные файлы. Для запуска и управления контейнерами используются системы оркестрации, самая популярная из которых – Kubernetes. Разобраться в основах программы можно с помощью онлайн-курса от Linux Foundation.

Знание английского языка

В IT знание английского языка уже давно стало аксиомой. Но для DevOps-инженера это особенно актуально, ведь этот подход востребован в основном на проектах для зарубежных заказчиков, преимущественно из США. Английский пригодится и для самообразования, чтобы вы могли изучать новые технологии, не дожидаясь пока появится соответствующий курс на русском языке. Если в будущем захотите получить профессиональный сертификат (например, AWS Certified DevOps Engineer), экзамен, скорее всего, тоже нужно будет сдавать на английском.

Когда приступать к поиску работы DevOps-инженером

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

Просматривая вакансии, обращайте внимание на другие названия, за которыми может скрываться эта роль: системный инженер, релиз-менеджер, инженер по автоматизации, D evOps-специалист. Чтобы лучше понять ожидания работодателей, сходите на несколько собеседований. После технического интервью обязательно просите фидбэк: каких знаний вам не хватает и какие еще технологии нужно освоить.

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

  • Система контроля версий (GitHub, SVN и др.).
  • Программа для непрерывной интеграции (Jenkins, TeamCity, Bamboo и др.).
  • Платформа для автоматизации развертывания ПО (например, Chef, Puppet, GoCD, Ansible).
  • Инструмент для мониторинга (Zabbix, Nagios, Prometheus и др.).
  • Облачная инфраструктура (например, AWS, Microsoft Azure).
  • Инструменты для работы с контейнерами (например, Docker, Kubernetes, Helm).

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

Карьерные перспективы в DevOps

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

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих