Ветеран 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, популярны. Сосредоточьтесь на том, чтобы ваши услуги помогали вашей компании, и не прекращайте процесс обучения. И речь не о копировании инструментов и внедрении их в своей организации. Речь о концентрации на постоянном совершенствовании во всех отношениях.
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:
- Курс по DevOps (12 месяцев)
Ещё курсы
- Профессия Веб-разработчик (8 месяцев)
- Профессия UX-дизайнер с нуля (9 месяцев)
- Профессия Web-дизайнер (7 месяцев)
- Курс по Machine Learning (12 недель)
- Обучение профессии Data Science с нуля (12 месяцев)
- Профессия аналитика с любым стартовым уровнем (9 месяцев)
- Курс «Python для веб-разработки» (9 месяцев)
