DevOps or not DevOps

добавлено: 19 апр 18
понравилось:0
просмотров: 2307
комментов: 4

теги:

Автор: Александр Гладченко

Драгоценные вы мои коллеги! Много в последние дни стали говорить о неких новых вершинах роста развития разработчика и админа. Всё чаще и громче звучит хор разного уровня менеджеров – блогеров (вот последний попавшийся мне на глаза пример: 5 challenges to scaling DevOps at enterprise level) о том, что сферу IT технологий должны наполнить «супер герои», и таким может стать каждый. С чей-то «лёгкой руки» скрестили два (а то и три, если считать управленцев) ортогональных направления IT-проекта, разработку и администрирование. Почему это сделали – понятно. Так проще загонять работы в неверно установленные рамки (тассочки вовремя закрывать, а то премию не дадут). А что бы «старпёры» (такие, как ваш покорный слуга) не «воняли», придумали слоган, что только таким путём можно вовремя реагировать на ставшее почему-то быстрым преобразование бизнеса в эпоху информационных технологий.
И вот перед нами предстаёт он – DevOps, великий и могучий. Давайте рассмотрим его под «лупой». Первое, что бросается в глаза, это то «море» экспертизы, которым пышет это «создание». Основная область – это конечно же разработка. Тут каждый должен знать все последние модные языки и технологии «впаривания» на них кода в продакшен. Причём, чем таких средств больше и чем они новее – тем круче! Вторая область, в которой разработчик всегда чувствовал себя увереннее любого недоразвитого админа – это поддержка и администрирование своего детища. Ведь проще это не хитрое дело делать самому, чем плодить тонны документации и внушать этим «тупым» и «упрямым» айтишникам, как заставить работать столь великолепный в исполнении и гениальный по задумке продукт (который так необъятен, что тестеры ещё долго будут ломать об него свои жалкие копья). Ну и что бы не стало никаких препятствий к заветным бонусам, нужно добавить ещё в этот «винегрет» обязанности продакт-менеджера, который вечно норовит всё перепутать и разрушить стройную модель доведения продукта до пользователя (или хотя бы до тестера). Итого, перед нами предстаёт величественная фигура полубога, который может всё и вся. Это кумир, идол и обитатель не земных высот! У него золотая голова, стальные мышцы и нестираемые метало-керамические колодки вместо подошв (автор не пытается тут напомнить вам сон Навуходоносора, совсем нет).
Теперь давайте кинем в него «камень». Что же случилось, почему эта величественная «скульптура» рассыпалась в прах!? Да всё просто, жизни не хватит, чтобы собрать даже в «золотой» голове всё ту экспертизу, которая будет покупаться и/или аутсортситься бизнесом. Раньше таких горе специалистов принято было называть просто – ламер. Но ламера не продать, поэтому то и нарядили его в «новые одежды». Чистой воды маркетинг. Дерево познаётся по плодам, и когда мы увидим и насладимся плодами девопсов, маркетологи придумают что-нибудь новое.
Второе, что бросается в глаза – это попытка совместить в одном лице две сущности, у которых очень разные цели, хотя задачи и могут иногда пересекаться. Цель разработчика – сдать к сроку работу и получить за это бонус. Цель админа, заставить эту работу работать и за это получить бонус. Цели ортогональны! Что получится в результате – работы будут всегда сданы в срок и работать будут всегда (под неусыпным присмотром девопса, который только один будет знать, как этого добиться). Кажется, где-то мы уже такое видели….
Кто же это придумал? Да уши же торчат прямо из самого названия – уж не от Devil ли сокращение первой части… От чего сокращение второй части, предлагаю обсудить в комментариях к этому посту ;)

Комментарии


  • Александр,

    компании, которые заражены DevOps, Agile и прочими квадратно-гнездовыми, кукурузными догмами, проще обходить благодаря провозглашению ими этих мантр.
    Это же лакмусовые термины, знаки - не входить туда, вляпаешься, потеряешь время.

  • 22 мая 2018, 14:36 рубист

    Александр, Вы не поняли статьи, на которую ссылаетесь, и что такое DevOps тоже.
    DevOps это не какой-то "специалист на все руки", что почти невозможно, как Вы правильно заметили.
    DevOps это прежде всего методология, как SCRUM или KANBAN.
    Использовать что-то из какой-то методологии или нет, зависит много от чего.
    У каждой методологии есть цель, ради которой она существует. Цели SCRUM и KANBAN понятны,
    повысить управляемость и предсказуемость процесса разработки.
    Главные цели DevOps:
    - уменьшить разобщенность между разработчиками, тестерами и админами.
    - максимально сократить время прохождения продукта между стадиями, от разработчика до заказчика.
    - сделать процесс прохождения всех стадий до заказчика максимально прозрачным для команды, а иногда и для заказчика.
    ВСЁ, больше ничего от DevOps не требуется.
    Можно реализовывать все эти цели, можно только часть, зависит от потребностей.
    Обязанности по реализации этих целей может совмещать какой-то из членов команды, а может и отдельно выделенный для этого человек.
    Если подумать об этих целях, то вырисовывается и набор экспертиз которым должен владеть специалист реализующий DevOps.
    И среди этих экспертиз нет обязанностей продакт-менеджера и всего остального, что Вы написали.
    Да, нужно быть программистом и от части админом, так как для реализации второго и третьего пункта
    нужно писать автоматизацию, в том числе для развертывания STAGE и PROD инфраструктур проекта,
    писать самому или интегрировать существующие средства мониторинга, сбора статистики и оповещения по работе
    системы контроля версий, прохождения тестов, STAGE прогонов и т.п. Если в этом процессе что-то программируется,
    то, как можно догадаться, используются совсем не те языки или инструменты, на которых пишется сам проект.
    Так что для хорошего программиста или админа это не новая вершина роста, это просто другая вершина,
    т.е. скорее шаг в сторону, чем вверх. Хотя, можно воспринимать такой переход по разному.
    Маркетологи и HR ходящие с плакатами "DevOps в массы" сами ничего в этом не понимают и других запутывают.
    Теперь придя на вакансию DevOps к HR можно обнаружить, что нужен просто обычный админ с навыками автоматизации. :)
    Это так же, как c "Cloud в массы" произошло. Теперь всё что ни попадя называют "облаками". :)))

  • 25 мая 2018, 11:49 Александр Гладченко

    "рубист" - увы, не согласен :) Все эти DevOps, SCRUM и/или KANBAN приводят к "размыванию" ответственности и, как Вы правильно заметили, шаг в сторону от Цели. Все эти "рысканья" помогают только уложиться в сроки - что выгодно и нужно менеджерам. Пользователь же получит очередную версию (извините) дерьма. Популяризируют же эти технологии те, кому выгодно продавать для них инструментарий. Уж они то точно не витают в "облаках".
    СУТЬ: DevOps - послушный админ.

  • поделюсь своим видением этого явления:
    - хотят убрать напряженность между деволоперами и админами. Как правильно было сказано, одни хотят, чтобы быстро, другие, чтобы качественно и на долго.
    В больших проектах продакт-менеджер должен утрясать/избегать подобные трения. В малых два чувака сами должны суметь договориться.

    - боссам Дев и Айти команд удобно переложить ответственность на какого-то ДевОпса за срывы.

    - таким способом хотят тряхануть заскорузлых/старых спецов (см. Reinforced change-resistant culture из этой статья), там об этом неявно.

    Выводы: в нормальных конторах толку от него будет ноль (или скорее с минусом). А в конторах с проблемами возможны положительные результаты, но это будет зависить от деталей реализации.
    Как технология/методология притянута за уши.



Необходимо войти на сайт, чтобы оставлять комментарии