TestingStage'17 - конференция №1 для тестировщиков. Успей купить билет по цене early bird до 26.04.

Карьера в IT: должность DevOps engineer

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

DevOps (development + operations) — это зародившаяся в 2009 году методология, нацеленная на взаимодействие программистов и системных администраторов для увеличения частоты выпуска релизов. Соответственно, DevOps engineer — специалист, который работает на стыке этих двух должностей и занимается автоматизацией жизненного цикла приложения (включая проектирование, разработку, тестирование, развертывание, поддержку и мониторинг).

По данным ДОУ, среднему украинскому DevOps инженеру 28 лет, он имеет зарплату $1200-2700 и опыт работы 4 года.

Задача и обязанности

Главная задачам DevOps инженера — максимально увеличить предсказуемость, эффективность и безопасность разработки ПО.

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

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

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

В обязанности DevOps engineer входит:
— Развертывание поставленного разработчиками релиза в производстве;
— Интеграция и углубление процессов разработки в поставку;
— Стандартизация окружения разработки;
— Настройка инфраструктуры на особенности разрабатываемого ПО;
— Подготовка продуктивной среды к частым внесениям изменений;
— Обнаружение и исправление проблем;
— Автоматизация процессов.

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

«Автоматизация различных задач, связанных с деплоями софта, который разрабатывается, деплоями системного софта, конфигурированием. Обеспечение мониторинга, реакция на различные внештатные ситуации. Улучшения платформ в плане снижения цены за инфраструктуру, в плане производительности и простоты. Предоставление различных доступов для разработчиков (например, в репозитории, VPN). Дизайн систем, их архитектура».

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

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

«Я постепенно „переехал“ в DevOps из Dev отдела. В работе приходится активно контактировать с Dev, Ops и QA отделами, c другими отделами реже. Если описать должность DevOps одной фразой, я бы сказал так — создавать инструментарий для Dev, Ops, QA etc отделов, чтобы им было легче и удобнее работать».

«Создаем новые виртуальные машины, пишем сервисы для их дополнительного мониторинга и так далее».

«Я вчера поднял teamcity/gradle+gitlab и настроил автоматическую выкладку сайта по коммиту в репу на сервер. Вот чем-то таким девопсы и занимаются».

Преимущества и недостатки

Главное достоинство профессии DevOps engineer — рост интереса компаний к концепции DevOps. По данным EMA, около 30% компаний уже реализовали или планируют реализовать DevOps в ближайшее время. То есть спрос есть — без работы хороший специалист не останется.

Самих DevOps специалистов привлекает то, что в работе они имеют 100% загрузку, в отличие от профессии системного администратора.

«Нравится фактор неожиданности — это делает работу довольно интересной и не превращает в рутину».

Другой плюс — широкая специализация:

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

Некоторых привлекает то, что результат работы можно «потрогать руками»:

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

Недостатки профессии, похоже, не отличаются от таковых у системных администраторов:

«Ночные неожиданности».

Как стать и куда двигаться дальше

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

«В голове нужно иметь библиотеку по всем доступным технологиям, начиная от методов кодирования сигналов до последнего модного продукта Open Stack».

Необходимые качества:
— Аналитический склад ума;
— Стрессоустойчивость;
— Умение не сдаваться даже в безвыходных ситуациях.

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

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

«На самом деле, лучше просто быть хорошим специалистом в _ЛЮБОЙ_ своей области, которая тебе нравится, и жить полной жизнью. И неважно, кто это — DevOp или химик нефти».


P.S. Спасибо за помощь в написании статьи Алексею Асютину и еще 5 украинским DevOps инженерам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.


Остальные статьи цикла:
— Карьера в IT: должность Team Lead
— Карьера в IT: должность Software Architect
— Карьера в IT: должность Project Manager
— Карьера в IT: должность CTO
— Карьера в IT: должность QA engineer
— Карьера в IT: должность QA Automation engineer
— Карьера в IT: должность Бизнес-аналитик
— Карьера в IT: должность системный администратор
— Карьера в IT: должность Data Scientist / Machine Learning Engineer
— Карьера в IT: должность Technical Writer
— Карьера в IT: должность Delivery Manager
— Карьера в IT: должность Software Product Manager

68 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

У нас немає стреотипів в компанії і ми готові взяти активного DevOps, який буде хотіти розвиватися і нам він також потрібен для налаштування середовища під проекти!) Чому програмісти це не зроблять? Тому, що в них є більш нагальні задачі і ми б все таки хотіли, щоб цим займалася окрема людина!) Всі, хто хоче долучитися до нашої дружньої команди, пишіть (skype id — hihiha4ka). Опис вакансії за посиланням — jobs.dou.ua/…​demotion/vacancies/39730

дописывать костыли по необходимости
не отнимайте хлеб

Конь в вакууме — это сильно!)))

Приятель подкинул ссылку. Достаточно доходчиво. :)
www.linkedin.com/...-feed-article-title-share

Ищем DevOps Engineer, который сможет провести и отладить инфраструктуру нашего проекта. Наладить деплой на Production. Обеспечить стабильность работы всех элементов продукта. Больше инфы здесь career.netpeak.ua/...evops-engineer-ringostat.

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

А зачем? Ваши разработчики же как-то смотрят логи (при траблшитинге), если они сами не прикрутили агригатор логов, то им, наверное, вполне удобно и так.

Формируем DevOps команду: jobs.dou.ua/...es/skein/vacancies/27483 — присылайте резюме на devops@skeingroup.com

Плохо что не вспомнили что после DevOps’ов дальше идёт SRE (Site Reliability Engineering).

Имхо, у нас DevOps только в моду входит, а в миру уже успел морально устареть :p медленно обволакивается дисциплинами пообъёмней и поконструктивней.

Да гугль книгу в апреле выпустил landing.google.com/sre/book.html если кто не в курсе.
Уже успел купить и прочитать в бумаге. Не то что бы много нового узнал, но как список литературы катит.

после DevOps’ов дальше идёт SRE (Site Reliability Engineering
всегда считал что это просто ещё одно название DevOps

DevOps не включает в себя обеспечение и контроль качества обслуживания.

Нужно понимать что есть методы мониторинга и масштабирования которые не удовлетворят требования к целевому продукту, и есть довольно много специфических моментов, которые влияют на доступность (availability) и перситентность (partition tolerance), но всего нужно выбрать что-то одно.

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

DevOps — это основа для SRE.

DevOps не включает в себя обеспечение и контроль качества обслуживания.
Включает.
Просто, что и демонстрирует статья и комменты, сейчас под вывеской DevOps настойчиво хотят продать (админ+конфигурейшн менеджмент+настройка сборки).
Фишка в том что термин DevOps появился позже чем первые проявления этого движения. Site Reliability Engineering — это то проявление, которое сложилось в Гугле.

В DevOps’e нет инструментов для QoS/QoE и соответствующих метрики для аудита масштабирования решений — вы не можете определить не масштабируете ли вы часом простой процессора на очередном ruby / python / node приложении и принять соответствующее решение. Так же в DevOps’e нет понятия метрик реального времени и систем принятия решения согласно этим метрикам, частенько в SRE фигурирует ML — бустяные деревья принятия решений и т.п.

В рамках DevOps’a не обсуждаются различные задачи синхронизации в распределённых системах, связанные с этим накладные расходы, и особенности реализации в рамках существующих требований проектов. Где-то нужен решать задачу принятия консенсуса на paxos/raft’e, а где-то CRDT структурами жонглировать, особенно если используются БД типа Riak, и у каждого решения есть свои метрики и свои особенности аудита в рамках конкретных задач.

По этому басни про Graphite/Ganglia меня просто умиляют — это посредственные поделки не имеющие никакого отношения к обеспечению надёжности целевых проектов.

Задача DevOps’a — связать разработчиков, QA и операционные задачи воедино, а не обеспечивать надёжность целевых решений.

В DevOps’e нет инструментов для
Доброе утро. От так магия, девопс находится в изолированном мире, в том в котором нет инструментов для ...
Давайте представим, что девопс — это нечто большее чем написание скриптов на чифе/папете :)

Есть разница между автоматизированными и автоматическими процессами.
Вот в случае с DevOps’ом речь идёт именно об автоматизированных.

Есть разница между автоматизированными и автоматическими процессами.
Угу разница в том что автоматический не требует наличия человека. Вы отрицаете наличие людей с тайтлом сайт site reliability engineer?
Фишка в том что сами гуглеры объясняли эту позицию «ну ты знаешь что такое девопс? ну это вот оно и есть»
Так же в DevOps’e нет понятия метрик реального времени и систем принятия решения согласно этим метрикам, частенько в SRE фигурирует ML — бустяные деревья принятия решений и т.п.
ээм, как же нет? если одним из самых продающих примеров культуры DevOps после «легко выкатываем 100500 релизов в день!» идёт как раз автомаштабирование инфраструктуры, базирующиеся на метриках реального времени?
В рамках DevOps’a не обсуждаются различные задачи синхронизации в распределённых системах, связанные с этим накладные расходы,
где-то есть DevOps-манифест, где сказано, мол если вы полезли в raft — вы больше не девопс?
Задача DevOps’a — связать разработчиков, QA и операционные задачи воедино, а не обеспечивать надёжность целевых решений.
Пока что остаюсь при мнении, что SRE == DevOps

Ищу работу, позволяющую развиваться в данном направлении.
ua.linkedin.com/in/shapovalenkoserhii

без английского шансов немного

среднему украинскому DevOps инженеру 28 лет, он имеет зарплату $1200-2700 и опыт работы 4 года.

Приятно ощущать себя более выдающимся по всем этим показателям :) А если серьезно, то 4 года общего стажа работы в целом недостаточно для такой позиции как DevOps, учитывая, что в Украине эта позиция продвигается лишь последние года 2-2.5 Подавляющее часть работы DevOps связана с R&D (что по сложности стоит после таких активностей как Operations и Implementation) и освоением новых и очень новых технологий — а для этого нужен опыт в первую очередь, второе, часто нужно понимание архитектуры — и здесь снова нужен опыт + хорошая теоретическая подготовка. Третье, просто развернуть и запустить достаточно лишь на короткий промежуток времени — очень скоро встает вопрос оптимизации кода, снижении затрат, повышении скорости деплойментов, повышении отказоустойчивости и т.д. (аппетит у Product Owner’ов на этот счет обычно приходит быстро) — хорошо, если есть архитект, который поможет с решениями, а если его нет? Снова надежда лишь на опыт. Но отчаиваться не ст0ит — опыт приходит вместе с желанием двигаться вперед и пробовать все новое. Немаловажную роль играет team — один DevOps в поле обычно не воин...

4 года общего стажа работы в целом недостаточно для такой позиции как DevOps, учитывая, что в Украине эта позиция продвигается лишь последние года 2-2.5
Возможно, в опросе участники указывали свой общий стаж в ИТ, а не непосредственно DevOps

4 года общего стажа в ИТ недостаточно. Я как бы это и написал :)

DevOps (development + operations) — это зародившаяся в 2009 году методология, нацеленная на взаимодействие программистов и системных администраторов для увеличения частоты выпуска релизов.
Не читайте русскую википедию.

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

Соответственно, DevOps engineer — специалист,
Соответственно, DevOps engineer — это первый признак того что в организации нет культуры ДевОпс.
для увеличения частоты выпуска релизов
От это совсем-совсем не правда.
«Частота резизов» — это побочных продукт культуры ДевОпс. И тут самая адская проблема: большинство «манагеров» как раз уверенны в правильности вашего утверждения и рассматривают ДевОпс как средство достижения «релизов когда хочет менеджмент» (например, ночью с сб на вс, шоб КуА успели потестить :) ).
большинство «манагеров» как раз уверенны в правильности вашего утверждения и рассматривают ДевОпс как средство достижения «релизов когда хочет менеджмент» (например, ночью с сб на вс, шоб КуА успели потестить :)

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

Согласна, но тут статья рассчитана на новичков, кто только разбирается, какие вообще должности есть в ИТ, кто чем занимается, выбирают, кем сами хотят быть. Поэтому текст задумывался как «пояснительная записка» к вакансиям jobs.dou.ua/...acancies/?category=DevOps, причем в украинских реалиях, а не про саму методологию DevOps, и некоторые вещи упрощены

Ответственность DevOps инженера состоит в:
— автоматизации процесса по подержанию целого программного стека в up-to-date статусе в соотвествии в внутренними процедурами и политиками компании в течение всего жизненного цикла.
— noninterruptable внесение измений в конфигурацию этого стека ( evolutionary design )
Достигается это через использование например
Automating provisioning and configuration через использование infrastructure-as-software или иными словами «кодирование» provisioning процесса, с целью получить что-то
типа «один запуск — один готовый environment» или
«один запуск — один апгрейднутый environment» вместо классической ситуации типа:
— «ну у нас еще диски не подвезли, поэтому файловая система еще не расширена до нужного размера» — ждем-с пока storage инженер, а потом сисадмин «раздуплятся»
— «VPN не сконфигурирован и порты пока закрыты» — ждем сетевых инженеров.
— «хост еще пока не зарегистрирован в DNS» — ждем сисадмина
— «бэкап сервер пока не готов, но вы же можете без него пока» — ждем сисадмина
— «ОС пока еще не пропатчена, но вам же это не мешает» — ждем сисадмина
— «СУБД пока еще не той версии..» — ждем DBA
— «Схема в СУБД не той версии» — ждем DBA
— приложение требует библиотеку версии 1.2, а у вас 1.1.
и т.д.
Суть действа: После отработки configuration management tool — у вас должет быть готовый к использованию environment не требующих внесения дальнейших дополнительных телодвижений, тем более мануальных.
Если это не так, то кто-то «накосячил» или у вас просто неправильно работает целый процесс.
Это может быть кто угодно, начиная от Dev-a и кончая DevOps-ом.

DevOps — может быть, как самостоятельной единицей, так и «приданным» к Dev-у, QA и т.д.
В любом случае лезть в код приложения, а тем более что-то там менять — это не отвтетственность DevOps-а. :)

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

Я где-то упомянул, что речь идет о сисадмине? :)
Например, в самом примитивном случае программный стэк состоит из:
— сервер приложений
— сервер БД
— собственно целевое приложение которое использует все выше перечисленное.

Отсюда имеет, скажем при использовании Chef-a соответствующий набор cookbook-ов которые отвечают за установку СУБД, сервера приложений и сообственно нашего целевого приложения. Кроме этого имеем набор cookbook общего назначения для предварительной конфигурации ОС ( файловые системы, DNS, ntpd сервис, конфигурация сетевого окружения и т.д. и т.п. )

Так вот отдельные cookbooks могут быть написаны разными людьми из разных подразделений.
Я сильно сомневаюсь что рядовой сисадмин «потянет» автоматизацию скажем Weblogic-a, хотя проблем с автоматизацией скажем Apache распространенных конфигураций у него недолжно возникнуть и не возникает.
Точно так же сисадмин скорей всего справится с автоматизайией MySQL, а вот с СУБД Oracle ему точно не совладать.

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

Вопрос: Вы много встречали сисадминов которые умеют писать тесты? :)

Как узнать что все это работает вместе?

Запустить integration test, а лучше два.
1. Setup нового environment-a
2. Upgrade c предыдущей версии.

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

Я про это:

Ответственность DevOps инженера
с последующим перечислением ответственностей operations. Поддержка инфраструктуры — это задача operations, независимо от того, автоматизировано оно или нет.

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

Цель DevOps — минимизация Operations cost в том числе.

Прежде чем что-то попадет в Operations он должно пройти цепочку Dev-Qa-Test-Uat и только потом Prod ( сферу ответственности Operations )
Это ж справедливо и для DevOps-ов.
Если по какой-либо причине изменение берет свое начло в Prod-е, то такое изменение обрушивает вышеозначенную цепочку, делая работу остальных в этой цепочке непредсказуемой.
Потому что у вас появляеются изменение о которых никто ничего не знает, с которыми никто не работал.

Continuous delivery процесс приказывает долго жить, автоматизация теряет смысл и превращается в обузу. Зачем что-то автоматизировать, если ваш софт «налетит» на изменения о которых никто не знал?
Отсюда вывод: «Никакое изменение не может брать свое начало в Prod-е.»

Я уже имел честь воотчию наблюдать в нескольким местах подобные обрушения, когда у руководства «падает планка», например в следствие непрохождения аудита с одной стороны, и отсутствия контроллированого процесса внесения изменений с другой,
и в результате оно отдает приказ внести изменение в Prod без тестирования.
Удручающее зрелище. Сисадмины ликуют. :)

Вы привели отличный пример, почему некоторые компании стали использовать public cloud.
Порой заставить Storage/Unix/Network/DBA team настолько сложно и затратно или невозможно, что проще перебраться в облако, где такие проблемы отсутствуют как класс или сведены к минимуму.

Я к тому, что в случае DevOps-культуры задача operations и automation сводится к поддержке работоспособности cloud on-premises. Но сама культура DevOps не предполагает появления новых должностей. Она лишь по-другому распределяет ответственности между существующими должностями.

Скорей всего это верно при условии, что такая культура производства уже распространена в компании, иначе роль DevOps инженера скорей следует понимать как роль евангилиста. :)
С другой стороны я встречал термин DevOps DBA, что как-бы предполагает, что вакансия предусматривает знакомство в культурой DevOps.
В таком контексте DevOps без доп. слов скорей всего предполагает сисадмина знакомого с DevOps.

Кстати,
Недавно мне попадалось на глаза содержимое вопросов по экзамену Linux RHCSA ( за точность не ручаюсь ). Так вот среди вопросов была тема менежмента СУБД MySQL.
Так, что все относительно. :)

www.redhat.com/...tified-engineer-rhce-exam

Database services
Install and configure MariaDB
Backup and restore a database
Create a simple database schema
Perform simple SQL queries against a database

Точно так же сисадмин скорей всего справится с автоматизайией MySQL, а вот с СУБД Oracle ему точно не совладать.
Жуть какие стереотипы... говорю как сисадмин/devops/системный инженер, это всё ± одни и те же понятия/должности, разница лишь в том какую роль/обязанности вам вверяют и как та или иная позиция называется в вашей компании.

Существуют клише о сисдаминах, их часто принимают за эникэев, которые таскают принтеры и разблокируют AD-учетки. Но, многие могут не знать, что современный системный администратор должен владеть и понимать ± всем вышеперечисленным,а самое важное уметь быстро разбираться в новых технологиях и деплоить их. К примеру, я сейчас занимаюсь всем на OS-уровне (траблшутинг, тюнинг, перформанс,сервисы), всеми видами монтироринга, виртуалзацией (включая, хосты, сторедж, ит.п.), физическими серверами, автоматизацией всего что может понадобиться, деплойментом приложений, конфигурейшн менеджмент, патчинг, базы (в прошлом проекте крутили jboss’ы, tomcat’ы и oracl’ы) — и моя позиция в компании системный администратор (в соседней мог бы элементарно называться DevOps).

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

1. Сисадмин в классическом нашем представлении «заточен» на решение сиюминутных проблем, отчего формируется определенный стиль работы, типа «пока не упало не лезь». Другой поганой привычкой является делать upgrade системы без качественного тестированя влияния upgrad-a на остальные компоненты программного стека.
Ему просто неоткуда взять подобные навыки, используемые программистами в процессе производства кода, если только он не работает с ними плечом к плечу. Максимум, что можно ожидать от него это положить последнюю версию конфигов в систему контроля версий, но для DevOps-а этого недостаточно. Необходимо писать код, необходимо работать с кодом, необходимо тестировать кода, как это делают программисты и qa, и соответственно реагировать на баги в стиле программистов, необходимо в конце-концов писать тесты, а это предполагает определенный уровень культуры производства программного обеспечения.
Все это повышает качество вносимых в конфигурацию изменений. Но самое поганое, что по-моему, серьезно ранит «душу сисадмина» это code review. Потому что, теперь каждый «несисадмин» может глянуть в его код, оценить его уровень и качество, и при случае указать на недостатки и попросить придерживаться практик кодирования и тестирования принятых в компании. :)
Отсюда имеем. Низкий общий уровень культуры производства ПО в компании не позволяет ей адекватно реагировать на необходимость вносить изменения и никакие приставки DevOps здесь не помогут, именно потому что DevOps — это культура сотрудничества отдельных подразделений компании, результатом которой является работающий код, а следовательно общий уровень кодирования определяется наислабейшим звеном.
Следует отметить, что это не только проблема сисадминов, как может показаться.
Сюда же следует отнести подход DBA-ев и сетевых администраторова. Просто у DBA это может встречаться реже, только потому что они ближе к программистам и потому чаще с ними пересекаются, но и только.

2. Как делают сисадмины траблшутинг в среде Oracle DB мне отлично известно. Обычно все заканчивается фразой «это не проблемы в системе, это у вас плохо написанный запрос, который ставит систему на рога», хотя на самом деле один из LUN-ов просто хандрит, от чего подвисает ранее нормально отрабатываваший запрос, использующий Full Table Scan. :)
Или «я тут успешно провел upgrade, но только надо, чтобы DBA посмотрел почему база не стартует» :) В данном контексте это все не про DevOps, если что.

В идеале, как и любой другой код он должен быть покрыт набором тестов.
Давайте устроим перекличку, у кого CM cookbooks покрыты тестами, мне просто интересно :D
После отработки configuration management tool — у вас должет быть готовый к использованию environment не требующих внесения дальнейших дополнительных телодвижений, тем более мануальных.
«диски» configuration management tool тоже сам купит и подвезет? :-)

Увы, тут без Амазона никак. :)

private cloud ограничивает рамками единственной вычислительной платформы
да и ошибка где-нибудь в цикле скрипта деплоя может буквально разорить компанию :-)

Если брать Амазон (хоть он сам по себе и дорогой), то там можно очень гибко все настроииь и защитить себя, те же autoscaling groups с максимальным количеством машин и оповещения, когда ты превысил бюджет в текущем месяце.

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

Проблема с private cloud только одна.
Если за него отвечают те же люди, которые дo этого занимались инфраструктурой компании и потребитель инфраструктуры был недоволен их работой, то переход в private cloud ничего не изменит, потому что люди останутся те же самые, менежмент будет тот же самый.
1. У меня есть примеры, когда народ специально переписывал код своего приложения таким образом, чтобы он был нечувствителен к установленной локали, только потому что сисадмины не могли гарантировать установку правильной локали во время инсталяции БД.
2. Как-то наш системный архитектор озвучил одну мысль:
«Чем воевать с нашими сетевиками нам дешевле будет переехать в public cloud, где потребность в них отпадет совсем» — вот почему public cloud.

сначала не понял при чем тут private cloud к амазону, а потом заметил что сам очепятался :-) (имел ввиду конечно же — public, если облако свое — как раз с одновременным использованием разных вычислительных платформ проще)
переходят на private cloud не потому что кто-то ни руководить ни

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

Спасибо за статью!

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

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

С тем что DevOps это культура, как и Agile( по сути DevOps — это «Agile для админов») для того чтобы получить более предсказуемый результат в результате процесса, через написание кода автоматизации я в целом согласен.
Кодироване инфраструктуры позволяет достичь:
а) контроля над тем тем, что делают sysop-ы, dba и т.д. и как они это делают.
б) работу по автоматизации выполняет тот, кто лучше всего знает конкретный софт + смежные области.
с) кодирование изменений вместо мануального внесения изменений позволяет автоматизировать процесс внесения изменений и пустить его стандартизированной и предсказуемой цепочке Dev-Qa-Uat-Prod.
d) работа sysop-ов, dba, cетевых инженеров перестает носить характер внесения хаотических изменений, когда «все упало», а вместо этого преобретает определенность и предсказуемость.

Основная часть работы DevOps инженера приходится на этап выпуска релиза — поставки продукта заказчику.
Не соглашусь. Заказчик — роль, просто во время разработки эту роль выполняют и Product Owner и DEV и QA, фаза UAT тоже очень важна как вариант «боевого тестирования»
Классические программеры понятия не имеют о том, как их приложение будет развертываться в продакшене
Не обобщайте галеры на весь домен.
до последнего модного продукта Open Stack
Пытаются захватить мир с 2010 и конкуренты пока ещё не повержены. Врядли такое случится — очень сложная прикладная область, которая к тому же не сбавляет обороты развития.

...
И как вариант bottom line
i.imgur.com/euj7F1F.jpg

«На самом деле, лучше просто быть хорошим специалистом в _ЛЮБОЙ_ своей области, которая тебе нравится, и жить полной жизнью. И неважно, кто это — DevOp или химик нефти».

Самое ценное в этой статье.

Похоже на описание релиз менеджера или automation инженера. DevOps инженеров не существует.

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

А если несколько человек? Наивно полагать, что если человек называется релиз-менеджером, то он не справится, а если назвать его DevOps, то он автомагически получает всесилие.

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

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

чем по-твоему занимается релиз-менеджер?

Я к тому, что сисадминов начали называть модным словом, не поменяв сути. habrahabr.ru/sandbox/96363

Суть поменяли, раньше ручками, а теперь требуют не только доку писать, но еще и одним нажатием кнопки это делать.

То есть прикрутил puppet/chef/ansible/etc — уже не сисадмин, а DevOps инженер? По-моему, этого недостаточно.

Конечно недостаточно, но уже лучше чем «надо на новый сервачек переахать, ааа, эээ, а что нам надо туда поставить и настроить?»

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

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

у нас существует

...ага, и РМы, как известно, тоже не нужны))

Акексею же

почему в профиле Акексей, я не знаю, опечатка наверное. Но Алексей же

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