Трудовыебудни консультанта
"Девопс хорош там, где хорош" говаривал мой приятель. И действительно, все так и есть! И я с ним не спорю даже :) хотяяяя...
Полная свобода в работе и максимальное регламентирование ?
Полная свобода - это хорошо. Это полет мысли. Это возможности. Это идти на острие технологий! НО! Только если в компании не больше одной команды на все продукты. Если, вдруг, у нас становится команд больше чем одна, то это становится конгломератом стартапов. И вместо "быть в тренде", мы становимся рыбой, раком и щукой. Какие минусы? Если быть точнее, то никаких плюсов. Взаимозаменяемость? Нет. Глубокая экспертиза? Нет. Взаимовыручка, поддержка, брейншторминг? Нет, нет и нет. Уже ни раз я наблюдал результат этого пложения стартапов. Ничего хорошего так и не нашел.
Тогда идем в тотальную стандартизацию всего и вся? Я бы сказал - да, но вот какими методами? В принципе есть два варианта: насадить и как-нибудь само. И вот тут сразу откликается мотивация сотрудника. Пытаемся "спустить решение" сверху вниз - хорошо, если в ответ получим только "итальянскую забастовку". А ведь может и текучка прилететь. Девопсеры конечно циники, каких поискать, но души от тонких материй ранимые (да и я - такой же). А текучка - это жопа. То есть совсем вот так, мы же пытаемся бардак причесать...
Остается как-нибудь само, но это само должно быть под чутким руководством. С организацией ныне модных ЦК (центров компетенций), организацией процесса стандартизации самими девопсерами, показывая их важность и давая простор для доказывания, самореализации и "спортивного интереса". И как следствие:
Мотивация каждого вовлеченного в процесс.
Вот где истинное творчество. Это уже работа с людьми, с их ожиданиями, с их "детищами", с их (даже иногда) амбициями, с их притензиями. Да много с чем еще.
Если бы все можно было решить деньгами, то все бы так и делали, но как уже доказано - это очень краткосрочное решение проблемы. Да и вовсе не решение, можно сделать еще хуже. Но вот что важно, какой бы рецепт не выбрать - результатом должна стать стандартизация.
На своем опыте могу сказать, как этого я добивался в определенной ситуации и у определенного заказчика.
Первое - это доверие. Вообще доверие это одна их основных ценностей коллектива, которая проходит по всем модным "текникам" (типа того же аджайла), да и не только им. Вообще доверие в коллективе - это важно.
Второе - это уважение этого коллектива. Нужно просто заслужить уважение :) И, да, не обязательно техническими терминами.
Третье - показать, что в сотруднике и его идеях реально заинтересованы, ну и давать время для опытов и игрищ ;)
Четвертое - заставить всех специалистов общаться друг с другом. Учить их слышать сторону оппонента и даже ее принимать. Продавать свою идею и доказывать ее состоятельность. Ну и проявить самому смекалку и корректировать в нужную сторону затеянную утряску. Создать основное - костяк и дружный коллектив.
В общем на эти нехитрые пункты я потратил полгода, но результатом остался доволен. Это и вечные споры инженеров-девопсеров, составление техрадара и новые команды уже адаптировались под него. Мощное коммьюнити и экспертиза в организации, взаимозаменяемость, и просто замечательный коллектив.
ну и причем тут облака?
А действительно, причем? Раз уж я говорю о философии девопса, то эта философия должна быть во всем, поэтому немного технической составляющей:
К сожалению реальные облачные провайдеры, с которыми работал - это Amazon и Azure. Остальные пока подходят только для создания виртуалок. Ну а какие это "облака", так, биллинговые виртуализаторы. Почему? Потому что первый постулат работы с облаками и девопсом это Infrastructure As a Code.
Это нам автоматически дает преймущества immutable всего. Инфраструктуры, приложений, релизов. Почему? Потому что мы должны гарантировать работоспособность кода. А это только удалить и пересоздать. Одним словом - immutable.
Созданные пайплайны могучими руками девопсеров должны контролировать и регламентировать работу разработчиков. Но нужно помнить, что тут работает и обратная зависимость.
Как сказал мой Коллега "что опять эти плаксивые разрабы хнычут, хоть раз бы сами свое говно на прод затолкали".
Пользоваться только достаточным стеком технологий, не нужно перегружать и так перегруженное, но помнить, что есть extended DevOps. DevSecOps, DevSecMonOps и т.д.