Цель любого devopsa – оставить себя без работы
На vc активно обсуждались пара статей про такие размытые понятия как devops и full-stack разработчик. Я вам не скажу за полный стэк, стэк тот очень уж велик. Но и разработчик, и даже тестер, знают за devops’а молодца.
Кто такой девопс (если мы говорим о человеке, а не «наборе практик») можно описать двумя способами. Корректным и еще одним:
Новый вид сисадмина. Только вместо скилла замены картриджа, он научился безболезненно выкатывать на прод бесконечные обновления/дополнения любых продуктов и сервисов
Разработчик, которому быть джуниором не позволяет религия, а сеньором лень/компетенции
Тут не хабр, поэтому буду мыслить в деньгах и бизнес процессах. Смысл любой должности в коммерческой организации — ценный конечный продукт (ЦКП), который прямо или косвенно конвертируется в прибыль.
Примеры
Продаван, ЦКП — деньги в кассе/контракты. Приносит прибыль прямо.
Секретарь, ЦКП — время руководителя. Приносит прибыль косвенно, если руководитель не делает ничего хорошего в освободившееся время, то работа секретаря бессмысленна.
Разработчик какого-нибудь инди-шедевра, ЦКП — оплата внутри приложения или в AppStore. Приносит прибыль прямо.
Разработчик ЯндексТакси, ЦКП — стабильная работа приложения и удовлетворенность пользователей. Приносит прибыль косвенно. Подведут водители или продакты включат в спринт плохую идею и даже идеальная работа разработчика не принесет денег.
ЦКП devops’a?
Если теряешься в догадках нужен ли тебе любой специалист, просто ответь на вопрос нужен ли твоему бизнесу его ЦКП. Значит решение берем/нет devops’a в штат зависит от задач, которые ты хочешь решить. Банальность? Да, но как отправная точка понадобится.
В наиболее частом случае (имхо + опрос devops'ов) основная задача — это поддержание бесперебойной работы и накатка на прод бесконечных обновлений. Обновляется ли сайт, приложение или математическая модель вторично. Главное тут, что работа сводится к двум моментам:
Обеспечь стабильность системы
Итерационно производи одни и те же действия в соответствии с графиком обновлений
Это и есть ЦКП devopsd’a. Если продолжать мыслить в деньгах, то первый пункт сразу хочется отдать на аутсорс, верно? Мое мнение, так рано или поздно случится в 90% компаний. Вспомните время, когда bash еще был торт и там напалмом жег сердца людей zog. Сисадмины были везде и делали все, от картриджа в принтер, до поменять шрифты на сайте. Со временем аппетиты профессионалов росли. Им на смену приходили джуны с ЧСВ до небес, но качественно работать из них могли (или хотели) единицы. Сложность обслуживания наиболее популярных систем снижалась в ответ на запрос рынка, явление «сисадмин на час» стало массовым, появились и активно захватывали рынок аутсорсинговые компании.
Кнопка «сделай хорошо» должна заменить devops’a. Дело не только в экономии
Вторая задача «раскатай на прод обновления» итерационна, зачастую имеет четкое расписание или легко прогнозируема, и главное ОДНОТИПНА.
Расскажу на живом примере.
Дано: Hadoop кластер, который понимает java/scala и хранит много полезных данных разной степени структурированности. Данные храним не красоты ради, а прибыли для. Чтобы получить прибыль необходимо создать какую-либо мат. модель и запустить её на кластере. Тут мы получаем 3 второстепенные задачи:
Выгрузить часть данных для создания/проверки модели
Переписать модель с python на java/scala
Раскатать переписанную модель на прод
В теории все просто, но на практике очень весело:
Devops выгружает данные по принципу «я так вижу». Чаще всего логично, например, убрав тестовые записи. Аналитика, естественно, никто в нюансы не посвящает. Может проскочить что-то реально важное. Есть тут продакты? Списывали из-за «так вышло» 100-1000 человекочасов не самых дешевых специалистов?
У модели есть KPI по точности. На локальной машине аналитика все отлично, но переписанная модель KPI не достигает. Проблема в модели или некорректной пересборке? Выгрузить все данные на локальную машину чтобы проверить оригинальную модель, естественно, невозможно
Критичное увеличение time-to-market. На одно согласование витрины данных может уйти больше суток. А на мемасики в «жизненно необходимом» для парного программирования чатике до 50% рабочего времени (ребята, я вас прикрыл. Мы то знаем что до 95%)
Уверен, похожая ситуация, может быть на другом стеке технологий, у многих. Наши ребята сделали круто. Вместо того, чтобы сохранять необходимость процесса со всеми вытекающими проблемами, они заменили себя кнопкой «сделай хорошо».
Задача итерационна и однотипна? Они потратили время и автоматизировали её. Теперь аналитики сами берут данные в пару кликов и прекрасно понимают, что взяли. Модели не переписываются, на прод они уходят как создавались — на python. Все любимые инструменты, типа Jupiter, доступны в новом интерфейсе.
Далее, конечно, была морально этическая дилемма. Если продолжать мыслить в деньгах, ребят надо бы благодарить и увольнять… Но, если мыслить чуть шире, таких специалистов отпускать ни в коем случае нельзя. Так что они теперь переквалифицировались в продактов и сервис, который должен был оптимизировать внутренние процессы, продается как самостоятельный продукт.
Вопрос к vc. А если честно-честно и не предвзято, Вы знаете devops’ов, которых нельзя заменить? Конечно, в компаниях где их работа не основная услуга или компания не размером с большую "тройку с полтиной" телекома?
Если кто-то знаком с озвученными проблемами при работе с hadoop — по коду "vc_without_dev-ops" может дать бесплатную триалку нашего продукта. Единственное условие, реальное использование и фидбек. Заявку с кодом оставлять тут
ПС. Власть роботам!
На мой взгляд - весь изюм девОпс практик - не в том что появился новый тип системного администратора, а в том что системный администратор больше не нужен.
Сейчас, для разработчика, работать с контейнерами и выстраивать рабочие "пайплайны" с этими контейнерами - это такойже стандарт как работать с системой контроля версий - отдельные специалисты там ни к чему. Вы же не набираете отдельных специалистов для того чтоб работать с гитом?
Вот согласен — чем меньше отдельных специалистов на вспомогательные (пусть и жизненно необходимые) задачи, тем лучше.
Если разраб не хочет научиться выкатывать обновления приложения в магазин, это садельное сооружение стеклянного потолка в своей карьере
Но в приведенном примере, с hadoop'ом и мат. моделями экономика говорит о другом. Ты хочешь найти человека, который может в статистику и python (его готовые библиотеки заменить сложно). Задача сложная, но решаемая. А вот если ты еще навесишь в необходимые скиллы java/scala, то в бюджет вписаться будет оооооочень сложно