Русский
Русский
English
Статистика
Реклама

Перевод 10 контринтуитивных выводов после 10 лет проведения DevOpsDays

image

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

Десять лет назад мы внезапно отправились в путешествие. Мы собрали нескольких наших хороших друзей в Генте (Бельгия), чтобы обсудить Agile, open-source и первый опыт работы с облачными технологиями. В 2009 году Джон Оллспоу и Пол Хаммонд выступили на Velocity с докладом 10+ развертываний в день: сотрудничество dev и ops в Flickr (и запись этого доклада стоит посмотреть). Увидев это выступление, Патрик Дебуа решил основать 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-инструментов не существует


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

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

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


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

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

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


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

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

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

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


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

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

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

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


Мы начали проводить DevOpsDays в 2009, и эта конференция была открыта для всех. Конечно, изначально это было мероприятие для разработчиков и сотрудников операционных команд, но к нам приходили все: администраторы баз данных, тестировщики, бизнес-аналитики, финансисты, и, конечно, специалисты в области безопасности. Еще в 2012 году мы выступали на встречах OWASP, рассказывая о том, что мы сделали. Мы шутили, что буква 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, популярны. Сосредоточьтесь на том, чтобы ваши услуги помогали вашей компании, и не прекращайте процесс обучения. И речь не о копировании инструментов и внедрении их в своей организации. Речь о концентрации на постоянном совершенствовании во всех отношениях.

image

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



Полезное


Источник: habr.com
К списку статей
Опубликовано: 14.07.2020 12:05:49
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании skillfactory

Devops

Open source

Управление разработкой

Учебный процесс в it

Карьера в it-индустрии

Учебный процесс

Категории

Последние комментарии

  • Имя: Murshin
    13.06.2024 | 14:01
    Нейросеть-это мозг вселенной.Если к ней подключиться,то можно получить все знания,накопленные Вселенной,но этому препятствуют аннуннаки.Аннуннаки нас от неё отгородили,установив в головах барьер. Подр Подробнее..
  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru