В последнее время такие объявления заполонили интернет. Несмотря на приятную зарплату, не может не смущать, что внутри написана дикая ересь. Вначале предполагается, что «DevOps» и «инженер» можно каким-то образом склеить вместе в одно слово, а далее идет рандомный список требований, часть которых явно скопирована из вакансии сисадмина.
В этом посте хочется немного поговорить, как мы дошли до жизни такой, что такое DevOps на самом деле и что теперь с этим делать.
Такие вакансии можно всячески порицать, но факт остается фактом: их много, и так устроен рынок на данный момент. Мы сделали девопс-конференцию и открыто заявляем: «DevOops — не для DevOps-инженеров». Тут многим покажется странным и диким: почему люди, делающие совершенно коммерческое мероприятие, идут против рынка. Сейчас всё объясним.
Про культуру и процессы
Начнем с того, что DevOps — это не инженерная дисциплина. Началось всё с того, что исторически сложившееся разделение по ролям не работает на качество продуктов. Когда программисты только программируют, но ничего не хотят слышать о тестировании — софт завален багами. Когда админам наплевать, как и почему написан софт — поддержка превращается в ад.
Например, описанием разницы между сисадминским и SRE-шным подходом к service management начинается знаменитая Google SRE Book. Интересные исследования проведены в рамках опроса DORA — видно, что самые лучшие разработчики каким-то образом умудряются деплоить новые изменения на продакшн быстрее, чем раз в час. Они же тестируют руками не больше 10% (это видно по прошлогоднему DORA). Каким образом у них это получается? «Excel or die» – говорит один из заголовков отчета. За подробным обсуждением этой статистики в разрезе тестирования можно обратиться к кейноуту Баруха Садогурского «У нас DevOps. Давайте уволим всех тестировщиков» на другой нашей конференции, Heisenbug.
«Когда в товарищах согласья нет,
На лад их дело не пойдет,
И выйдет из него не дело, только мука.
Однажды Лебедь, Рак да Щука…»
Как думаете, какая часть веб-программистов действительно понимает, в каких условиях эксплуатируются их приложения на проде? Сколько из них пойдет к админам и попытается разобраться, что произойдет при падении базы? А кто из них отправится к тестировщикам и попросит научить, как правильно писать тесты? А там еще есть безопасники, менеджеры продуктов, еще куча людей.
Общая идея DevOps в том, чтобы наладить взаимодействие между ролями и отделами. В первую очередь это достигается не каким-то хитро настроенным софтом, а практикой общения. DevOps — это про культуру, практику, методологию и процессы. Не существует такой инженерной специальности, которая бы отвечала на эти вопросы.
Замкнутый круг
Откуда же взялась тогда дисциплина «девопс-инженерии»? У нас есть версия! Идеи DevOps оказались хороши — настолько хороши, что стали жертвами своего успеха. Вокруг всей этой темы стали клубиться какие-то мутные рекрутеры и торговцы людьми, у которых очень своя атмосфера.
Представьте: вчера вы в Химках лудили шаурму, а сегодня — вы уже большой человек, сениор рекрутер. Тут целый процесс поиска и отбора кандидатов, всё непросто, понимать надо. Допустим, начальник отдела говорит: найди специалиста по X. Приписываем к X слово «инженер», и дело в шляпе. Нужен Linux? Ну это точно Linux-инженер, хочешь DevOps — DevOps-инженер. Вакансия состоит не только из заголовка, но внутри нужно вписать какой-то текст. Проще всего — вписать набор кейвордов из Гугла, кому сколько хватит фантазии. DevOps состоит из двух слов — «Dev» и «Ops», значит, надо склеивать кейворды, относящиеся к разработчикам и администраторам, все в одну кучу. Так появляются вакансии про владение 42 языками программирования и 20 лет использования Kubernetes и Swarm одновременно. Рабочая схема.
Таким в сознании людей укоренился бессмысленный и беспощадный образ некого супергероя-«девопса», который настроит всем деплой на Jenkins, и наступит счастье. Ах, если бы все было так просто. «А еще так можно хантить сисадминов, — думает эйчар, — слово модное, кейворды те же самые, должны клюнуть».
Спрос рождает предложение, и на все эти треш-вакансии налетело безумное количество сисадминов, которые смекнули: можно делать все то же самое, что и раньше, но получать в несколько раз больше, назвавшись «девопсами». Как ты настраивал сервера через SSH руками по одному, так и продолжишь настраивать, но теперь это якобы девопс-практика. Это какое-то сложное явление, частично связанное и с недооцененностью классических админов, и с хайпом вокруг DevOps, но в общем — что получилось, то получилось.
Итак, у нас есть спрос и предложение. Замкнутый круг, который подпитывает сам себя. Вот с этим мы и боремся (в том числе, создавая конференцию DevOops).
Безусловно, кроме сисадминов, переименовавшихся в «девопсы», есть и другие участники — например, профессиональные SRE или разработчики Infrastructure-as-Code.
Чем люди занимаются в DevOps (на самом деле)
Итак, вы хотите продвинуться в изучении и применении практик DevOps. Но как это сделать, в какую сторону смотреть? Очевидно, слепо руководствоваться популярными ключевыми словами не стоит.
Если работа есть, кто-то ей должен заниматься. Мы уже выяснили, что это не «девопс-инженеры», тогда кто? Кажется, правильней сформулировать это не в терминах должностей, а в терминах конкретных направлений работы.
Во-первых, можно заниматься самым сердцем DevOps — процессами и культурой. Культура — дело небыстрое и нелегкое, и хотя это традиционно сфера ответственности руководителей, так или иначе в этом участвуют все, от программистов до админов. Пару месяцев назад Тим Листер в интервью сказал:
«Культура задаётся основными ценностями организации. Обычно люди этого не замечают, но мы, работая в консалтинге на протяжении многих лет, привыкли это подмечать. Ты заходишь в компанию и буквально через несколько минут начинаешь чувствовать, что происходит. Мы называем это «ароматом». Иногда этот аромат действительно хорош. Иногда он вызывает тошноту. (…) Ты не можешь изменить культуру до того, как были осознаны ценности и убеждения, которые стоят за конкретными действиями. Поведение наблюдать легко, а искать убеждения — сложно. DevOps — это как раз отличный пример того, как всё становится сложнее и сложнее».
Есть и техническая часть вопроса, конечно. Если у тебя новый код на тестирование попадает через месяц, а в релизе оказывается только через год, и ускорить всё это физически невозможно — до хороших практик можно не дожить. Хорошие практики поддерживаются хорошими инструментами. Например, держа в голове идею Infrastructure-as-Code, можно использовать что угодно, от AWS CloudFormation и Terraform до Chef-Ansible-Puppet. Всё это надо знать и уметь, и вот это уже вполне инженерная дисциплина. Важно не путать причину со следствиями: вначале вы работаете по принципам SRE и только потом уже воплощаете эти принципы в виде каких-то конкретных технических решений. При этом SRE — это очень комплексная методология, которая рассказывает не про то, как настроить Jenkins, а про пять основных принципов:
- Улучшение взаимодействия между ролями и отделами
- Принятие ошибок как неотъемлемой части работы
- Постепенное осуществление изменений
- Использование тулинга и прочей автоматики
- Измерение всего, что можно измерить
Это не просто какой-то набор утверждений, а конкретное руководство к действию. Например, на пути принятия ошибок нужно будет разобраться с рисками, измерить доступность и недоступность сервисов с помощью чего-то вроде SLI (service level indicators) и SLO (service level objectives), научиться писать постмортемы и сделать так, чтобы писать их было не страшно.
В дисциплине SRE использование инструментов — только одна из частей успеха, впрочем, немаловажная. Нам нужно постоянно развиваться в техническом плане, смотреть, что происходит в мире и как это можно применить в своей работе.
В свою очередь, сейчас стали очень популярными решения Cloud Native. Согласно современному пониманию Cloud Native Computing Foundation, технологии Cloud Native позволяют организациям разрабатывать и запускать масштабируемые приложения в современных динамичных средах, таких как публичные, приватные и гибридные облака. В качестве примера можно привести контейнеры, сервис-меши, микросервисы, неизменяемую инфраструктуру и декларативные API. Все эти техники позволяют слабосвязанным системам оставаться эластичными, управляемыми и хорошо наблюдаемыми. Хорошая автоматика позволяет инженерам делать большие изменения часто и с предсказуемыми результатами, не превращая это в адский труд. Все это поддерживается стеком из всем известных инструментов, таких как Docker и Kubernetes.
Это довольно непростое и развесистое определение связано с тем, что и область довольно непростая. С одной стороны утверждается, что новые изменения в эту систему должны добавляться достаточно просто. С другой стороны, чтобы разобраться в том, как сделать некую контейнеризованную среду, в которой слабосвязанные сервисы живут на software-defined инфраструктуре и поставляются туда с помощью непрерывного CI/CD, и выстроить вокруг всего этого DevOps-практики — на всем этом надо не одну собаку съесть.
Что со всем этим делать
Каждый решает эти проблемы по-своему: например, можно публиковать нормальные вакансии, чтобы разорвать замкнутый круг. Можно разобраться, что значат слова вроде DevOps и Cloud Native и употреблять их правильно и по делу. Можно развиваться в DevOps и своим примером демонстрировать правильные подходы.
Мы же делаем конференцию DevOops 2020 Moscow, которая предоставляет возможность глубже разобраться в вещах, о которых мы только что поговорили. Для этого есть несколько групп докладов:
- Процессы и культура;
- Site Reliability Engineering;
- Cloud Native;
Как выбрать, куда идти? Тут есть тонкий момент. С одной стороны, DevOps — это про взаимодействие, и нам очень хочется, чтобы вы сходили на доклады из разных блоков. С другой стороны, если вы — руководитель разработки, пришедший на конференцию, чтобы сконцентрироваться на одной конкретной задаче, то никто вас не ограничивает — очевидно, это будет блок про процессы и культуру. Не забывайте, что после конференции у вас останутся записи (после заполнения формы обратной связи), поэтому вы всегда сможете посмотреть менее важные доклады позже.
Очевидно, что на самой конференции вы не можете пойти сразу на три трека одновременно, поэтому мы так формируем программу, чтобы в каждом временном слоте были темы на любой вкус.
Осталось только понять, что делать, если вы DevOps-инженер! Во-первых, попробуйте определить, чем на самом деле вы занимаетесь. Обычно этим словом любят называть:
- Разработчиков, которые занимаются инфраструктурой. Для вас больше всего подойдут группы докладов про SRE и Cloud Native.
- Системных администраторов. Тут сложнее. DevOops — не про системное администрирование. К счастью, на тему системного администрирования есть масса прекрасных конференций, книг, статей, видео в интернете и т.п. С другой стороны, если вам интересно развиваться в плане понимания культуры и процессов, изучения облачных технологий и подробностей жизни с Cloud Native, то мы будем рады вас видеть! Подумайте вот о чем: вот вы занимаетесь админством, а дальше что вы будете делать? Чтобы внезапно не оказаться в неприятной ситуации, стоит учиться уже сейчас.
Есть ещё один вариант: вы упорствуете и продолжаете утверждать, что являетесь именно DevOps-инженером и никак иначе, что бы это ни значило. Тогда вынуждены огорчить, DevOops — это конференция не для DevOps-инженеров!
Слайд из доклада Konstantin Diener в Мюнхене
DevOops 2020 Moscow пройдет 29-30 апреля в Москве, билеты уже можно приобрести на официальном сайте.
Кроме того, вы можете подать свой доклад до 8 февраля. Обратите внимание, что при заполнении формы вы должны выбрать целевую аудиторию, которой ваш доклад принесет больше пользы (внутри списка зарыт сюрприз).
Автор: Олег Чирухин
