Цель любого devopsa – оставить себя без работы

На vc активно обсуждались пара статей про такие размытые понятия как devops и full-stack разработчик. Я вам не скажу за полный стэк, стэк тот очень уж велик. Но и разработчик, и даже тестер, знают за devops’а молодца.

Кто такой девопс (если мы говорим о человеке, а не «наборе практик») можно описать двумя способами. Корректным и еще одним:

  • Новый вид сисадмина. Только вместо скилла замены картриджа, он научился безболезненно выкатывать на прод бесконечные обновления/дополнения любых продуктов и сервисов

  • Разработчик, которому быть джуниором не позволяет религия, а сеньором лень/компетенции

Тут не хабр, поэтому буду мыслить в деньгах и бизнес процессах. Смысл любой должности в коммерческой организации — ценный конечный продукт (ЦКП), который прямо или косвенно конвертируется в прибыль.

Примеры

Продаван, ЦКП — деньги в кассе/контракты. Приносит прибыль прямо.

Секретарь, ЦКП — время руководителя. Приносит прибыль косвенно, если руководитель не делает ничего хорошего в освободившееся время, то работа секретаря бессмысленна.

Разработчик какого-нибудь инди-шедевра, ЦКП — оплата внутри приложения или в AppStore. Приносит прибыль прямо.

Разработчик ЯндексТакси, ЦКП — стабильная работа приложения и удовлетворенность пользователей. Приносит прибыль косвенно. Подведут водители или продакты включат в спринт плохую идею и даже идеальная работа разработчика не принесет денег.

ЦКП devops’a?

Если теряешься в догадках нужен ли тебе любой специалист, просто ответь на вопрос нужен ли твоему бизнесу его ЦКП. Значит решение берем/нет devops’a в штат зависит от задач, которые ты хочешь решить. Банальность? Да, но как отправная точка понадобится.

В наиболее частом случае (имхо + опрос devops'ов) основная задача — это поддержание бесперебойной работы и накатка на прод бесконечных обновлений. Обновляется ли сайт, приложение или математическая модель вторично. Главное тут, что работа сводится к двум моментам:

  1. Обеспечь стабильность системы

  2. Итерационно производи одни и те же действия в соответствии с графиком обновлений

Это и есть ЦКП devopsd’a. Если продолжать мыслить в деньгах, то первый пункт сразу хочется отдать на аутсорс, верно? Мое мнение, так рано или поздно случится в 90% компаний. Вспомните время, когда bash еще был торт и там напалмом жег сердца людей zog. Сисадмины были везде и делали все, от картриджа в принтер, до поменять шрифты на сайте. Со временем аппетиты профессионалов росли. Им на смену приходили джуны с ЧСВ до небес, но качественно работать из них могли (или хотели) единицы. Сложность обслуживания наиболее популярных систем снижалась в ответ на запрос рынка, явление «сисадмин на час» стало массовым, появились и активно захватывали рынок аутсорсинговые компании.

Кнопка «сделай хорошо» должна заменить devops’a. Дело не только в экономии

Вторая задача «раскатай на прод обновления» итерационна, зачастую имеет четкое расписание или легко прогнозируема, и главное ОДНОТИПНА.

Расскажу на живом примере.

Дано: Hadoop кластер, который понимает java/scala и хранит много полезных данных разной степени структурированности. Данные храним не красоты ради, а прибыли для. Чтобы получить прибыль необходимо создать какую-либо мат. модель и запустить её на кластере. Тут мы получаем 3 второстепенные задачи:

  1. Выгрузить часть данных для создания/проверки модели

  2. Переписать модель с python на java/scala

  3. Раскатать переписанную модель на прод

В теории все просто, но на практике очень весело:

  • Devops выгружает данные по принципу «я так вижу». Чаще всего логично, например, убрав тестовые записи. Аналитика, естественно, никто в нюансы не посвящает. Может проскочить что-то реально важное. Есть тут продакты? Списывали из-за «так вышло» 100-1000 человекочасов не самых дешевых специалистов?

  • У модели есть KPI по точности. На локальной машине аналитика все отлично, но переписанная модель KPI не достигает. Проблема в модели или некорректной пересборке? Выгрузить все данные на локальную машину чтобы проверить оригинальную модель, естественно, невозможно

  • Критичное увеличение time-to-market. На одно согласование витрины данных может уйти больше суток. А на мемасики в «жизненно необходимом» для парного программирования чатике до 50% рабочего времени (ребята, я вас прикрыл. Мы то знаем что до 95%)

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

Задача итерационна и однотипна? Они потратили время и автоматизировали её. Теперь аналитики сами берут данные в пару кликов и прекрасно понимают, что взяли. Модели не переписываются, на прод они уходят как создавались — на python. Все любимые инструменты, типа Jupiter, доступны в новом интерфейсе.

Далее, конечно, была морально этическая дилемма. Если продолжать мыслить в деньгах, ребят надо бы благодарить и увольнять… Но, если мыслить чуть шире, таких специалистов отпускать ни в коем случае нельзя. Так что они теперь переквалифицировались в продактов и сервис, который должен был оптимизировать внутренние процессы, продается как самостоятельный продукт.

Вопрос к vc. А если честно-честно и не предвзято, Вы знаете devops’ов, которых нельзя заменить? Конечно, в компаниях где их работа не основная услуга или компания не размером с большую "тройку с полтиной" телекома?

Если кто-то знаком с озвученными проблемами при работе с hadoop — по коду "vc_without_dev-ops" может дать бесплатную триалку нашего продукта. Единственное условие, реальное использование и фидбек. Заявку с кодом оставлять тут

ПС. Власть роботам!

0
2 комментария
Dima Kotobotov

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

Ответить
Развернуть ветку
Руслан Зиганшин
Автор

Вот согласен — чем меньше отдельных специалистов на вспомогательные (пусть и жизненно необходимые) задачи, тем лучше.

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

Но в приведенном примере, с hadoop'ом и мат. моделями экономика говорит о другом. Ты хочешь найти человека, который может в статистику и python (его готовые библиотеки заменить сложно). Задача сложная, но решаемая. А вот если ты еще навесишь в необходимые скиллы java/scala, то в бюджет вписаться будет оооооочень сложно

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда