Devops, что это такое?

Частенько путешествуя по просторам русскоязычного Интеренета, я постоянно натыкаюсь на обсуждения вида «Что-же такое Devops», а ещё и регулярно получаю предложения на разнообразные вакантные (а иногда и не очень) позиции «Devops». И с увереностью могу сказать, что подавляющее большинство IT специалистов и рекрутеров не до конца осознают что же стоит за этим, модным нынче, словом. И ладно бы это слово использовалось просто так, для солидности и красоты, но ведь зачастую оно и бывает темой разговора! Соответственно, в силу различий в интерпретации, диалог заходит в тупик непонимания и заканчивается разочарованием всех причастных. Ниже я бы хотел поделится с Вами своими размышлениями на данную тему.

Что думают в Интернете

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

Кого ищут работодатели

Если поискать вакансии «Devops», то обычно имеются следующие требования для соискателя:
— опыт в администрировании Windows/Linux;
— знать python/ruby/bash/java/…;
— приветствуется опыт работы с aws/docker/kubernetes/elasticsearch/GitLab/прочие модные слова ассоциирующиеся у кого-то с Devops и облачными технологиями.
Идём далее, должностные обязанности выглядят так:
— администрирование Windows/Linux/Zabbix/Jenkins/Git/остальное ПО компании;
— автоматизировать всё вокруг и выбрать инструменты «Devops» (интересно, что тут подразумевается?);
— что-то помогать разработчикам.
И как правило, по таким вакансиям пытаются найти системного администратора со знанием определённого языка. Зачем же здесь это магическое слово спросите Вы? Да очень просто, оно солидно звучит и подчёркивает требования к профессионализму сосискателя. То есть мы ищем не просто там сисадмина, а очень высококфалифицированного Системного Администратора с богатым опытом/кругозором/аналитическими способностями/знакомого с финансами/… и конечно определённым языком программирования. Поэтому часто на собеседованиях можно услышать что-то вроде — «У нас все программисты пишут на Basic, используют Couchbase и пишут для OS/2, а у Вас нет пятилетнего опыта использования такого стека, поэтому на devops Вы нам не подходите». Так неужели настоящий Devops нуждается в знании и опыте с Basic, Couchbase и OS/2?..

Как и для чего появился Devops

Чтоб понять что скрывается за этим словом, нам понадобиться хотя-бы краткий экскурс в историю зарождения этого термина.
Когда-то давно, компьютеров было совсем мало и использовались они в основном для неких узких задач. В те времена языки программирования были сравнительно сложны в использовании, инструментов облегчающих проектирование ещё не было и для написания качественного ПО уходило достаточно много времени. Многие програмы писались только один раз, т.е. без обновлений, распространялись на физических носителях и раз установленные, использовались годами. В те времена, была признана самой эффективной и применялась следущая схема разработки — собирались все требования, затем создавалось техническое задание, по нему писали программное обеспечение, тестировали его и в итоге выпускали новую программу. То есть, весь этот процесс занимал месяцы, а то и годы.
Но время шло, мир познавал новое, а быстрее всех развивались информационные технологии. Вот на дворе уже новый миллениум, у каждого есть по смартфону и планшету, в кошельке лежат банковские карты, нас окружает глобальная сеть в которой друг с другом связаны холодильники и стиральные машины, а ещё в ней каждый может скачать всё что угодно. Людям очень нравится Интернет и новые программы, они хотят вызывать такси обедая в ресторане, оформлять загранпаспорт сидя в своём офисе, покупать билеты на поезд летя в самолёте. Языки программирования стали гораздо удобнее, появилось множество готовых библиотек, фреймворков и разнообразных инструментов для разработки. Теперь программы пишутся за считаные дни, а потенциальная аудитория для нового ПО охватывает весь мир! Конечно, за такой кусок пирога, разгорелась нешуточная драка, программы теперь пишут все кому не лень и если ты хочешь отхватить кусок рынка побольше, а не выбыть из гонки, то надо всегда быть на шаг впереди конкурентов. Надо выпускать и распространять свои программы быстрее всех, дорабатывать их в максимально короткие сроки и конечно же не терять в качестве, ибо выбор аналогов велик и их создатели не дремлют. Для захвата максимальной аудитории пользователей появляется понятие минимально жизнеспособного продукта и гибкие методологии разработки. Между производителями програм начинается соревнование — кто быстрее всех может создавать, дорабатывать и продавать всем вокруг новые продукты. И вот тут-то на сцене и появляется новое ранее неведомое понятие — Devops.

Притча про Корпорацию и Программиста

Давным давно, в тридевятом царстве, на заре расцвета доткомов, решила одна могучая Корпорация создать новую, жутко полезную, программу калькулятор. Засели множество умных мужей за проектирование и разработку сего чуда, кропели они днями и ночами создавая небывалую ранее тулзу, аж со 105 кнопками! А многим людям обычным, была та тулза позарез нужна, и ждали её с нетерпением.
А в это время один программист решил не ждать, а сделать свой калькулятор, простенький, так для себя. И вот написал он его за пару дней, да и выложил в интернете на всеобщее обозрение. А народ как увидел, что появился калькулятор то, так и стал его качать и пользоваться. Ну и что, что всего две кнопки, иного-то пока и нету. Стали программисту отзывы поступать на программулинку его, делать нечего пришлось уступить просьбам добрым и добавить ещё пару кнопок. Обрадовались обыватели и стали пуще прежнего калькулятор себе устанавливать и большего просить. Делать нечего, день за днём идёт, а кнопки у программиста всё прибавляются, а кошелёк тяжелеет.
Но вот настал день, и Корпорация выпустила свой калькулятор, весь украшенный бисером и материалами богатыми, глазу приятный и с 95 кнопками! Глядь, ан никто и не идет за сим чудом дивным, все калькулятор Программиста используют и уходить с него не хотят. Мечут молнии старшие Корпорации, велят исправить сиё недоразумение, но лишь разводят руками мужи умные, никак не могут народ заставить. Так и разогнал царь старших всех, да назначил своего воеводу на их место.
Но идёт время, понемногу и на товар Корпорации находятся купцы заморские, да и люд местный. Вот уже и Корпорация наравне с Программистом свое произведение улучшает, по нарокам от купцов полученным. И уж не спит и не ест Программист, а всё никак за Корпорацией не поспевает, ну быстрее и лучше они калькулятор то свой дорабатывает.
Так, мало помалу, и ушли от Программиста все его последователи. Но не остался он один, ибо и по сей день сидят рядом с ним, на завалинке, старшие из Корпорации. Поминают они с Программистом старое, и обсуждают как правильно делать калькуляторы, чтоб и народ повеселить, да и богатства сколотить несметные.

Что же такое DevOps на самом деле

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

В качестве пояснения, хотел бы вкратце привести пару примеров, показывающих ценности Devops на каждой стадии жизненного цикла программы. Допустим, если наш «конвейер» выглядит так,
конвейер devops процессовто:
1) Вы думаете в разработке не место Devops? Как бы не так, ведь опытный специалист знает, что от созданного кода, как минимум, будет зависит выкладка, конфигурирование и обратная связь при использовании программы. Мы должны держать руку на пульсе разработки и заранее подсказать программистам как надо/не надо делать, ведь они сами не задумываются (и не должны) о таких вещах. Это позволит нам избежать узких мест на этапах эксплуатации;
2) Система контроля версий — тут важно убедиться, что мы сможем успешно взаимодействовать с нашей системой сборки и об удобстве для разработчиков, не надо отвлекать их на битву с системой контроля версий. Правильно выбранная и настроенная СКВ не должна «тормозить» компоненты нашего конвейера.
3) При сборке продукта мы должны быть уверены — формат результатов сборки позволяет автоматизацию дальнейших шагов, учёт релизов или версий, связь с ревизией в СКВ.
4) О чем же полезном мы может задуматься при взгляде на хранилище артефактов? Конечно же на совместимость с системой сборки или например автоматизацией для отката. Ведь мы же помним что бывают ситуации когда релиз может оказаться не совсем удачным и тут наш конвейер тоже не должен сплоховать.
5) Доставка. Тут наверно и говорить не о чем, это важная часть она более чем полностью находится в наших руках и должна быть качественно автоматизирована.
6) От конечных пользователей, нам нужна обратная связь и конечно это тот самый этап когда необходимо собирать важные для бизнеса метрики. Именно на основе этих данных и будет планироваться дальнейшие направления разработки.
7) А если смотреть на конвейер в целом, то нам будет интересен мониторинг прохождения по нему изменений, для оценки эффективности и поиска «бутылочных горлышек».
Это конечно совсем не полный набор как можно использовать Devops, на самом деле список гораздо больше и может быть индивидуален для каждой ситуации, да и в предложенной схеме мы не касались тестирования, «облаков» или высокой доступности. Но даже из этого примера видно, что итоговая скорость «движения», будет не больше скорости самой медленной части и максимальную пользу от применения Devops можно получить только применяя его на всех этапах конвейера.
Но не стоит думать, что это однократный процесс — один раз настроил и забыл. Вовсе нет, вместе с ростом зрелости компании, улучшения её продуктов и внедрения новых технологий, должны развиваться и преобразовываться все составляющие Вашего Devops.

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

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

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

Оставить ответ