В последнее время подобная реклама заполонила Интернет. Несмотря на приятную зарплату, нельзя не смущаться, что внутри написана дикая ересь.
Сначала предполагается, что «DevOps» и «инженер» можно как-то склеить в одно слово, а дальше идет случайный список требований, часть из которых явно скопирована с вакансии сисадмина.
В этом посте мне бы хотелось немного рассказать о том, как мы дошли до этой точки жизни, что такое DevOps на самом деле и что с этим делать теперь.
Такие вакансии можно всячески осуждать, но факт остается фактом: их много, и так устроен рынок в данный момент. Мы провели devops конференцию и открыто заявляем: « DevOops — не для DevOps-инженеров».
Многим покажется странным и диким: почему люди, которые делают полностью коммерческое мероприятие, идут против рынка.
Сейчас мы все объясним.
О культуре и процессах
Начнем с того, что DevOps не является инженерной дисциплиной.Все началось с того, что исторически сложившееся разделение ролей не работает на качество продукции.
Когда программисты только программируют, но не хотят ничего слышать о тестировании, программное обеспечение завалено ошибками.
Когда администраторов не волнует, как и почему написано программное обеспечение, поддержка превращается в ад. Например, описывая разницу между системным администратором и подходом SRE к управлению услугами.
начинается знаменитая книга Google SRE .
Интересные исследования были проведены в Исследование ДОРА — понятно, что лучшим разработчикам каким-то образом удается внедрять новые изменения в продакшн быстрее, чем раз в час.
Руками тестируют не более 10% (это видно из прошлогодняя ДОРА ).
Как они это делают? «Превосходи или умри», — гласит один из заголовков отчета.
Подробное обсуждение этой статистики в контексте тестирования можно найти в докладе Баруха Садогурского.
«У нас есть DevOps. Давайте уволим всех тестировщиков».
на другой нашей конференции, Heisenbug.
«Когда нет согласия среди товарищей, Дела у них пойдут не очень хорошо, И ничего из этого не выйдет, одни мучения.Как вы думаете, какая часть веб-программистов действительно понимает условия, в которых их приложения используются в производстве? Сколько из них пойдут к админам и попытаются выяснить, что будет, если база данных выйдет из строя? И кто из них пойдет к тестировщикам и попросит научить их правильно писать тесты? А еще есть охранники, продакт-менеджеры и еще куча людей.Жили-были Лебедь, Рак и Щука.
»
Общая идея DevOps — создать сотрудничество между ролями и отделами.
Прежде всего, это достигается не каким-то хитро настроенным программным обеспечением, а практикой общения.
DevOps — это культура, практики, методология и процессы.
Ни одна инженерная специальность не может ответить на эти вопросы.
Порочный круг
Откуда тогда взялась дисциплина «devop-инжиниринг»? У нас есть версия! Идеи DevOps были хороши — настолько хороши, что стали жертвами собственного успеха.Вокруг всей этой темы начали крутиться какие-то теневые вербовщики и торговцы людьми, у которых есть своя атмосфера.
Представьте: вчера вы готовили шаурму в Химках, а сегодня вы уже крупный человек, старший рекрутер.
Идет целый процесс поиска и отбора кандидатов, все непросто, это нужно понимать.
Допустим, начальник отдела говорит: найдите специалиста по Х.
Присвоим Х слово «инженер» и готово.
Нужен линукс? Ну это точно Linux-инженер, если хотите DevOps, то DevOps-инженер.
Вакансия состоит не только из названия, но и внутри необходимо ввести некоторый текст. Самый простой способ — ввести набор ключевых слов от Google, в зависимости от вашей фантазии.
DevOps состоит из двух слов — «Dev» и «Ops», а это значит, что нам нужно склеить ключевые слова, относящиеся к разработчикам и администраторам, все в одну кучу.
Так появляются вакансии со знанием 42 языков программирования и 20 лет использования Kubernetes и Swarm одновременно.
Рабочая схема.
Вот так в сознании людей укоренился бессмысленный и беспощадный образ некоего «девопсовского» супергероя, который настроит всех на развертывание в Дженкинсе, и наступит счастье.
Эх, если бы все было так просто.
«А ещё так можно выследить сисадминов, — думает HR, — слово модное, ключевые слова те же, надо клюнуть».
Спрос рождает предложение, и все эти мусорные вакансии заполнились безумным количеством сисадминов, которые поняли: можно делать все то же самое, что и раньше, но получать в несколько раз больше, называя себя «девопами».
Так же, как вы настраивали серверы по SSH вручную по одному, вы и дальше будете их настраивать, но теперь это якобы devops-практика.
Это какое-то сложное явление, отчасти связанное с недооценкой классических админов и ажиотажем вокруг DevOps, но в целом, что было, то случилось.
Итак, у нас есть спрос и предложение.
Порочный круг, который питает сам себя.
Вот с этим мы и боремся (в том числе создавая конференцию DevOops).
Конечно, кроме системных администраторов, переименовавших себя в «девопсы», есть и другие участники — например, профессиональные SRE или разработчики Infrastructure-as-Code.
Что люди делают в DevOps (на самом деле)
Итак, вы хотите добиться успеха в изучении и применении практик DevOps. Но как это сделать, в какую сторону смотреть? Очевидно, что не следует слепо полагаться на популярные ключевые слова.Если есть работа, кто-то должен ее делать.
Мы уже выяснили, что это не «devop-инженеры», тогда кто? Представляется, правильнее сформулировать это не в терминах должностей, а в терминах конкретных направлений работы.
Во-первых, вы можете обратиться к самому сердцу DevOps — процессам и культуре.
Культура — дело медленное и сложное, и хотя традиционно это обязанность менеджеров, в нем так или иначе участвуют все: от программистов до администраторов.
Пару месяцев назад Тим Листер сказал в интервью :
«Культура определяется основными ценностями организации.Есть, конечно, и техническая часть вопроса.Обычно люди этого не замечают, но, проработав много лет в консалтинге, мы привыкли это замечать.
Вы входите в компанию и буквально через несколько минут начинаете чувствовать, что происходит. Мы называем это «вкусом».
Иногда этот аромат действительно хорош.
Иногда это вызывает тошноту.
(.
) Вы не сможете изменить культуру, пока не будут поняты ценности и убеждения, лежащие в основе конкретных действий.
За поведением легко наблюдать, но искать убеждения сложно.
DevOps — это просто отличный пример того, как все становится все более и более сложным».
Если ваш новый код тестируется через месяц, а выходит только через год, и ускорить его физически невозможно, возможно, вы не соответствуете хорошим практикам.
Передовая практика подкрепляется хорошими инструментами.
Например, имея в виду идею «Инфраструктура как код», вы можете использовать что угодно — от AWS CloudFormation и Terraform до Chef-Ansible-Puppet. Все это нужно знать и уметь, а это уже вполне себе инженерная дисциплина.
Важно не путать причину со следствием: сначала вы работаете по принципам SRE и только потом реализуете эти принципы в виде каких-то конкретных технических решений.
При этом SRE — это очень подробная методология, которая рассказывает не о том, как настроить Jenkins, а о пяти основных принципах:
- Улучшение взаимодействия между ролями и отделами.
- Принятие ошибок как неотъемлемая часть работы
- Вносим изменения постепенно
- Использование инструментов и другой автоматизации
- Измерение всего, что можно измерить
Например, на пути к принятию ошибок вам нужно будет понимать риски, измерять доступность и недоступность сервисов с помощью чего-то вроде SLI ( индикаторы уровня обслуживания ) и СЛО ( цели уровня обслуживания ), научитесь писать постмортемы и сделайте так, чтобы их писать было не страшно.
В дисциплине SRE использование инструментов — это лишь одна часть успеха, хотя и важная.
Нам нужно постоянно развиваться технически, смотреть на то, что происходит в мире и как это можно применить в нашей работе.
В свою очередь, решения Cloud Native сейчас стали очень популярны.
Согласно сегодняшнему определению Cloud Native Computing Foundation, технологии Cloud Native позволяют организациям разрабатывать и запускать масштабируемые приложения в современных динамических средах, таких как общедоступные, частные и гибридные облака.
Примеры включают контейнеры, сервисные сетки, микросервисы, неизменяемую инфраструктуру и декларативные API. Все эти методы позволяют слабосвязанным системам оставаться эластичными, управляемыми и хорошо наблюдаемыми.
Хорошая автоматизация позволяет инженерам часто и с предсказуемыми результатами вносить большие изменения, не превращая это в рутинную работу.
Все это поддерживается стеком известных инструментов, таких как Docker и Kubernetes. Это довольно сложное и широкое определение связано с тем, что данная территория также является достаточно сложной.
С одной стороны, утверждается, что новые изменения в эту систему следует вносить достаточно просто.
С другой стороны, чтобы придумать, как создать некую контейнерную среду, в которой слабосвязанные сервисы живут в программно-определяемой инфраструктуре и доставляются туда с помощью непрерывного CI/CD, и построить вокруг всего этого практики DevOps — все это требует большего.
чем съесть собаку.
Что со всем этим делать?
Каждый решает эти проблемы по-своему: можно, например, публиковать нормальные вакансии, чтобы разорвать порочный круг.Вы можете понять, что означают такие слова, как DevOps и Cloud Native, и использовать их правильно и по делу.
Вы можете развиваться в DevOps и на своем примере демонстрировать правильные подходы.
Мы проводим конференцию DevOops 2020 Москва , что дает возможность глубже вникнуть в то, о чем мы только что говорили.
Для этого существует несколько групп отчетов:
- Процессы и культура;
- Проектирование надежности объекта;
- Облачный родной;
С другой стороны, если вы менеджер по развитию, который пришел на конференцию, чтобы сконцентрироваться на одной конкретной задаче, то вас никто не ограничивает — очевидно, это будет блок о процессах и культуре.
Не забывайте, что после конференции у вас останутся записи (после заполнения формы обратной связи), так что менее важные выступления вы всегда сможете посмотреть позже.
Очевидно, что на самой конференции невозможно пройти сразу по трем трекам, поэтому мы организуем программу таким образом, чтобы в каждом тайм-слоте были темы на любой вкус.
Остаётся только понять, что делать, если ты DevOps-инженер! Во-первых, попытайтесь определить, чем вы на самом деле занимаетесь.
Обычно любят называть этим словом:
- Разработчики, которые работают над инфраструктурой.
Вам больше всего подойдут группы отчетов по SRE и Cloud Native.
- Системные администраторы.
Здесь сложнее.
DevOops — это не системное администрирование.
К счастью, в Интернете есть масса отличных конференций, книг, статей, видео и т. д. по теме системного администрирования.
С другой стороны, если вы заинтересованы в развитии себя в плане понимания культуры и процессов, изучения облачных технологий и подробностей жизни с Cloud Native, то мы будем рады вас видеть! Подумайте вот о чем: вы занимаетесь администрированием, а что потом будете делать? Чтобы внезапно не оказаться в неприятной ситуации, стоит научиться этому уже сейчас.
Тогда вынуждены вас разочаровать: DevOops — это не конференция DevOps-инженеров! 
Слайд из доклад Константина Динера в Мюнхене DevOops 2020 Москва пройдет в Москве, билеты уже в продаже покупка на официальном сайте .
Кроме того, вы можете отправьте свой отчет до 8 февраля.
Обратите внимание, что при заполнении формы необходимо выбрать целевую аудиторию, которая получит наибольшую пользу от вашего отчета ( внутри списка спрятан сюрприз ).
Теги: #программирование #Системное администрирование #Конференции #DevOps #devoops #devoops2019 #devoops2019moscow
-
Изобретение Века: Дешевый Android-Планшет
19 Oct, 24
