НОВОСТИ [Перевод] 10 контринтуитивных выводов после 10 лет проведения DevOpsDays

[Alvaros]

Ветеран DevOps Крис Байтаерт, стоявший у истоков DevOpsDays, делится своим опытом, и его выводы вас удивят.

Десять лет назад мы внезапно отправились в путешествие. Мы собрали нескольких наших хороших друзей в Генте (Бельгия), чтобы обсудить Agile, open-source и первый опыт работы с облачными технологиями. В 2009 году

You must be registered for see links

и

You must be registered for see links

выступили на Velocity с докладом «10+ развертываний в день: сотрудничество dev и ops в Flickr» (и

You must be registered for see links

стоит посмотреть). Увидев это выступление,

You must be registered for see links

решил основать DevOpsDays.

Верно ли, что мир DevOps очень сильно изменился за эти 10 лет? Я посещаю мероприятия DevOpsDays с самого основания конференции, и за это время я накопил значительный опыт. В этом посте я расскажу о 10 уроках, которые могут также быть полезны для вас.

1. Нет такого понятия, как DevOps-инженер


Во многих командах есть человек с должностью «DevOps-инженер», и далеко не всем специалистам нравится такое звание. Такое название профессии создает ложное впечатление, что DevOps – это работа, которую может выполнить один человек. Чаще всего, инженер DevOps – это Linux-инженер, который, если повезет, может решать задачи автоматизации. Когда рекрутеры начинают искать DevOps-инженера, соискатели должны задать себе правильные вопросы: «Что на самом деле нужно компании от соискателя? Они ищут инженера для сборке? Сеньора, который понимает нефункциональные требования? Специалиста в отдел операций, способного заниматься автоматизаций или кого-то еще?» Чаще всего компании ищут специалиста, который отвлечет остальных сотрудников от невыполнения практических принципов и требований Agile.

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

2. DevOps-команд не существует


Раньше мы часто говорили, что цель DevOps – устранение неразберихи между разными командами. В частности, между разработчиками и сотрудниками оперативных отделов. Тем не менее, недавно мы столкнулись с новым феноменом – появлением множества DevOps-команд.

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

Мой опыт показывает, что наличие слова «DevOps» в названии команды, скорее всего, будет препятствовать достижению желаемых результатов.

3. DevOps-проектов не бывает


Все проекты конечны. Вы занимаетесь разработкой, разворачиваете свое решение и двигаетесь дальше. Также последние 10 лет идут разговоры о том, что DevOps – это постоянное совершенствование, а постоянное совершенствование бесконечно. В свою очередь, результатом ваших проектов являются долгоиграющие сервисы, а сервис подразумевает последовательность “Разработка -> Развертывание -> Поддержка работоспособности”

Лишь после того, как мы посмотрим на сервисы вне рамок проектов, мы сможем увидеть аспекты, которые легко забываются: нефункциональные требования. Нефункциональные требования включают в себя функциональность, которая не вписывается в специфическое поведение. Также эти требования определяют нашу оценку работы системы. Зачастую в эти требования включают аспекты, которые относят к области DevOps: надежность, юзабилити, поддерживаемость и масштабируемость. Все эти характеристики важны для достижения результатов в бизнесе.

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

4. DevOps-инструментов не существует


Несмотря на то, что многие поставщики будут стараться

You must be registered for see links

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

Культура, основанная на инструментах может скорее изолировать людей вместо того, чтобы помочь им взаимодействовать. Дело в том, что люди становятся одержимы своим тулчейном и отдаляются от тех, кто им не пользуется. Несмотря на то, что те или иные инструменты могут быть очень полезны с технической точки зрения, ряд новых инструментов (условно относимых к DevOps) увеличил раскол между различными группами. Например, я часто слышу фразу «это работает в моем контейнере”. Разработчики используют эту фразу, чтобы обозначить, что „их“ работа выполнена. Контейнеры сами по себе не решают проблем взаимодействия, связанных с эффективным запуском приложений. Мы не можем позволить инструментам отдалить нас друг от друга.

5. В DevOps не бывает сертификации


Никакой тест с выбором вариантов ответа не может подтвердить, что вы способны эффективно взаимодействовать с коллегами. Организации, предлагающие сертификацию, могут иметь невероятную квалификацию в технической области (и даже вопросах эффективного взаимодействия), но сертификат не может показать, что кто-то хорош в DevOps.

К сожалению, команды менеджеров требуют сертификаты в области, в которой трудно что-то сертифицировать. Будьте образованы в области своего любимого программного и аппаратного обеспечения, изучите облачные технологии. Выучитесь в местном университете, читайте книги, из которых вы многое почерпнете, в частности, книги

You must be registered for see links

,

You must be registered for see links

,

You must be registered for see links

и

You must be registered for see links

. Но не надейтесь, что станете лучшим в DevOps после получения сертификата. Взаимодействовать с коллегами намного важнее.

6. DevOps-конвейера не существует


»DevOps уже отработал?" «DevOps-конвейер работает.» «DevOps-конвейер сломан.» Всякий раз, когда я слышу эти заявления, я удивляюсь, что мы пришли к подобной терминологии. Мы сделали ребрендинг конвейера развертывания, или дело в том, что в некоторых компаниях DevOps-команды занимаются этой инфраструктурой? А может дело в том, что разработчики звонят операционной команде, если конвейер сломан?

Несмотря на огромную важность технологий CI/CD, я скептически отношусь к использованию термина «DevOps-конвейер». Если конвейер разработки ломается, то в этом виновата операционная команда. Разработчики не задумываются о работе конвейера, покуда они пишут тесты. Также в заблуждение вводит сама концепция. Конвейеры создаются для каждого сервиса или приложения отдельно, а не в рамках всей области DevOps. Создавая обобщенные конвейеры мы рискуем увеличить разрыв между командами, а это совсем не та целью, которую преследует DevOps.

Я рекомендую пользоваться методикой, которую я видел в сотнях организаций по всему миру: называть каждый отдельный конвейер конвейером для приложения X. С такой терминологией будет проще узнать, с каким приложением возникают проблемы при тестировании, развертывании или обновлении. Также мы будем знать какая команда будет работать над исправлениями в приложении X (возможно, с помощью друзей из операционной команды).

7. В DevOps нет стандартов


Самая непростая из тысяч историй, связанных с DevOps – это стандартизация. Точно так же, как мы не можем сертифицировать людей, в DevOps не существует универсального стандарта. У каждой организации свой путь, и эти пути могут иметь очень большие отличия. Не существует волшебного рецепта, в котором будут перечислены инструменты и описаны методы создания потоков автоматизации, которые внезапно наладят в вашей организации DevOps.

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

DevOps стоит понимать как совокупность практик, подобную методологии

You must be registered for see links

. Помните, что буква L в ITIL означает Library (Библиотека). И эту библиотеку нужно воспринимать не как руководство к действию, а как перечень лучших практик, из которого нужно выбрать самые применимые для вас. ITIL возненавидели именно из-за неудачных реализаций, в которых библиотеку использовали именно как пошаговую инструкцию. Стандартизация в DevOps приведет к таким же результатам.

8. Нет такого понятия, как DevSecOps


Мы начали проводить DevOpsDays в 2009, и эта конференция была открыта для всех. Конечно, изначально это было мероприятие для разработчиков и сотрудников операционных команд, но к нам приходили все: администраторы баз данных, тестировщики, бизнес-аналитики, финансисты, и, конечно, специалисты в области безопасности. Еще в 2012 году мы выступали на встречах

You must be registered for see links

, рассказывая о том, что мы сделали. Мы шутили, что буква «S» в DevOps означает безопасность, как и буква «S» в HTTPS.

DevOps подразумевает безопасность по самой своей сути. Я заметил, что лучше всего принципы CD приживаются в командах, занимающихся безопасностью. CD – это требование безопасности: вы должны иметь возможность развертывать в любое время, это даст вам возможность произвести развертывание и внедрить обновления, требуемые бизнесом или вопросами безопасности.

С одной стороны, печально, что нам приходится придумывать слова, чтобы включить людей, отвечающих за безопасность. С другой стороны, хорошо, что мы снова обсудили это. По сути, нет никакой разницы между DevSecOps и DevOps. Безопасность всегда была частью разработки и операций. Я могу использовать для этого термин DevSecOps, но лучше просто пользоваться термином DevOps.

9. Нельзя взять и перейти на DevOps


Вы когда-нибудь встречали компанию, делавшую заявление в духе «Мы реализуем DevOps-проект в четвертом квартале этого года, а в следующем году мы перейдем на DevOps полностью», у которой все это действительно получилось? Вот и я не встречал.

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

10. Есть такая штука, как «Дев-уупс»


К сожалению, многие люди не понимают всей важности сотрудничества. Они строят стены между командами, считают, что инструменты важнее практик, требуют сертификации всего и вся. Также они считают, что все 9 предыдущих утверждений неверны. И эти люди будут вечно мучиться, чтобы преуспеть в том, что я называю «Дев-уупс».

«Дев-уупс» – это считать, что инструменты и разделение команд важнее настоящих принципов DevOps, которые могут улучшить вашу работу. Давайте будет стремиться к тому, чтобы заниматься DevOps, а не «Дев-уупс».

Главная цель


Мы проводим DevOpsDays уже 10 лет, и за это время тысячи людей узнали друг от друга много интересного в легкой и открытой обстановке. Некоторые концепции, которые я нахожу противоречащими целям DevOps и agile, популярны. Сосредоточьтесь на том, чтобы ваши услуги помогали вашей компании, и не прекращайте процесс обучения. И речь не о копировании инструментов и внедрении их в своей организации. Речь о концентрации на постоянном совершенствовании во всех отношениях.

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:

• You must be registered for see links
  (12 месяцев)

Ещё курсы

• You must be registered for see links
  (8 месяцев)
• You must be registered for see links
  (9 месяцев)
• You must be registered for see links
  (7 месяцев)
• You must be registered for see links
  (12 недель)
• You must be registered for see links
  (12 месяцев)
• You must be registered for see links
  (9 месяцев)
• You must be registered for see links
  (9 месяцев)

Полезное

• You must be registered for see links
• You must be registered for see links
• You must be registered for see links
• You must be registered for see links
• You must be registered for see links