Нанять людей в DevOps и другие плохие идеи

Автор оригинала: Stuart Lange
  • Перевод
Как-то стал свидетелем разговора двух приятелей и услышал:
«У вас уже внедряют DevOps? Просто у нас в МегаТелеКо все идет полным ходом! Недавно мы набрали команду DevOps из 35 человек!»

Так почему нанять команду DevOps это плохая идея?


В тот момент я удержался от фейспалма в стиле Капитана Пикара. К несчастью, найм сотрудников на должность, содержащую слово DevOps и радость участника этого разговора по этому поводу не случайное заблуждение. По быстрому обзору источников в интернете следует, что множество компаний ищут инженеров DevOps, которые в числе прочих будут заниматься:
  • автоматизацией изменений в инфраструктуре
  • настройкой JIRA
  • администрированием MySQL
  • поддержкой масштабных Linux проектов
  • ведением всего, что связано с puppet
  • написанием скриптов на ruby, python или bash
  • оперативным подпиранием «костылями» тут и там

Cписок составлен из кусков реальных вакансий, немного изменен, чтобы не намекать на кого-то конкретного.

В целом, я положительно отношусь к тому, что концепция DevOps становится популярной. Однако, как уже было с Agile, DevOps в опасности получить статус очередного модного термина, а впоследствии и утратить всякий смысл. Сдается мне, большая часть компаний, ищущих DevOps, хотят нанять просто сисадмина, но выглядеть при этом современно. Львиная доля требований в стандартной вакансии DevOps полностью покрывается компетенциями инженера поддержки или системным администратором. При этом особенно забавно, что в этих требованиях зачастую отсутсвует пункт «умение создавать простые и работающие решения». Похоже, вместо того, чтобы работать в направлении взаимодействия разработки и поддержки для улучшения качества, ИТ-индустрия пытается «срезать», просто пожаловав админу новое звание — DevOps.

Так что же действительно нужно для развития DevOps?


Вместо создания новой команды DevOps, попробуйте убрать стену между отделами разработки и поддержки. Разработчикам и сисадминам стоит встречаться на регулярной основе, дабы проговаривать все рабочие моменты, включая установку, настройку софта и его проблемы. Обратная связь и обсуждение идей должны работать в обе стороны. Руководителям проектов следует считать сисадминов такими же пользователями ПО, а значит, рассматривать их сценарии работы и учитывать пожелания, как делают это для внешних пользователей. Разработчикам же следует отнестись с пониманием к требованиям поддержки и ответственно подойти к их реализации. Конечно, две команды должны оставаться самостоятельными, ведь у каждой своя специфика, сильные стороны и компетенции, но совместная работа в рамках «суперкоманды» с общей целью — создавать и сопровождать изящный и качественный продукт для решения непростых задач бизнеса.

Вместо повсеместного скриптования инфраструктуры следует делать софт целостным и логичным. Есть мнение, что термина DevOps нет в Windows по причине отсутствия в этой экосистеме эффективных средств автоматизации как в мире Linux (здесь я намекаю на chef и puppet). Трудно не согласиться, такие инструменты крайне полезны, но я не поддерживаю мнение, что краеугольным камнем DevOps является автоматизация. На самом деле, ваш софт не должен полагаться на нетривиальные скрипты для установки и настройки (не важно perl, puppet). Внедрение должно быть простым, в идеале, как обычный xcopy на целевую машину (хорошо бы, если софт при первом запуске сам себя и установит). Настройки следует получать от конфигурационного сервиса, а не устраивать карнавалы XML файлов. Вместо конструирования очередной машины Голдберга, дабы заскриптовать все особенности и сложности настройки вашего софта, взаимодействуйте, наконец, с разработкой (и с менеджментом), чтобы избавиться от таких проблем и от ненужной сложности.

Не думайте о DevOps как об очередном модном словечке, лучше примите эту философию и распространите ее. В реальности, DevOps нельзя наладить простым наймом специалистов с этим словом в резюме или внедрением монструозного ПО автоматизации. Чтобы постигнуть дзен DevOps, нужен культурный скачок. Разработчики, которые зациклены на конечных пользователях, должны обратить взор на поддержку и ее потребности. Админы, вместо тихого ворчания, должны сообщать о неудобствах продукта и вносить вклад в улучшение процесса работы. Таким образом, налаживание связей внутри компании это первый и важный шаг. Далее, придется уделить время и ресурсы для улучшения продукта до состояния «простой и удобный». Конфигурация через центральную службу, внедрение простым копированием, отсутствие внешних зависимостей, обдуманные метрики вместо мусора в логах — важные задачи на этом пути.

DevOps должен приниматься не для галочки. Эта философия подразумевает общение и взаимодействие, а главное, стремление создавать качественное программное обеспечение, которое разрабатывается, поддерживается и используется с удовольствием.
Поделиться публикацией

Комментарии 10

    +9
    Извините, но вода водой.
      0
      OFFTOP:… и модное слово DevOps в заголовке… /OFFTOP
        0
        Статья как раз о том, что слово «DevOps» стало слишком модным баззвордом, которое стали употреблять как угодно, только не в правильном значении. Особенно, когда DevOps считают частью названия должности (что примерно так же абсурдно, как называть должность программиста Agile-инженером).
          0
          По честному, надоело обсасывание этой темы, что опсов ни в коем случае нельзя называть девопсами, атата!
          Как поискать best practice в русскоязычном сообществе ИТ по этим самым девопс практикам, так ничего и не найдешь толком, зато 100500 одинаковых копипастов про «перебрасывание через стену», правильную и неправильную философию и прочую муть, имхо.
            0
            я согласен с вами, что толкового материала на эту тему очень мало. но это не в последнюю очередь связано с тем, что область молода. Что касается этой статьи, мне кажется, она не о том, чтобы не называть кого-то девопсами, а о том, что нельзя нанять людей с стороны, которые сделают тебе конфетку и идеальный девопс workflow. Автор призывает компании засучить рукава и строить такие процессы самостоятельно, учитывая бизнес задачи. Лично от себя скажу, что мне как раз надоело, что большинство компаний, а именно их сотрудники, ищут в интернете готовые рецепты: в итоге в индустрии создается иллюзия, что ставишь jira, chef/puppet и у тебя уже девопс. Но ведь это совсем не так.
              0
              Я ни в коем случае не против ни самой статьи, ни перевода. На счет иллюзий в новом течении это да, но рынок и время расставит все и всех по своим местам, как мне кажется. Плюс использовать готовые workflow очень даже хорошо, особенно если это workflow тех кто задает тренд. А внедрение оных все равно пройдет через жестокую реальность твоей инфраструктуры и возможно изменится до совсем другого состояния. Пусть лучше так, чем использование всего подряд, ради того, что бы называться девопсами.
              +1
              > Как поискать best practice в русскоязычном сообществе ИТ по этим самым девопс практикам, так ничего и не найдешь толком, зато 100500 одинаковых копипастов про «перебрасывание через стену»

              Не в последнюю очередь это связано с тем, что компании нанимают людей на должность с тайтлом «DevOps-инженер» и считают, что у них теперь есть модный DevOps и сейчас все станет зашибись. Карго-культ в чистом виде! Нельзя подробно узнать, как в аэропорту организована работа диспетчеров, если диспетчерскую башню имитирует пальма, но а все при этом знают только то, что диспетчеры предотвращают авиакатастрофы.
        0
        всё правильно сделал
          0
          Спустя 3 года после написания статьи, констатирую факт: DevOps полностью как термин умер и теперь так называют простую автоматизацию процессов разработки. А гендиректора Дженкинса называют DevOps-инженером.

          Естественно, в нашем проекте каждая джоба в дженкинсе называется с префиксом CI — это делает наш интегрейшен континиоусным.

          Я плачу сейчас, а вам меня не жалко.
            +1
            я чувствую твою боль, анонимус

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое