Преодоление пробелов: важность коммуникации DevOps

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

DevOps повсюду. И хотя это интересная тенденция, она должна быть приспособлена к продуктам, а не наоборот.

Но некоторые люди так не видят. Мне часто задают такие вопросы, как «Как вы думаете, стоит ли нам начать использовать Docker или сразу перейти к Kubernetes?» Такие вопросы бессмысленны, даже если вы не знаете, о чем продукт.

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

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

Если вы сказали «отличное общение», вы правы. Инструменты все в порядке. Но они стоят вложенных в них денег только тогда, когда улучшают коммуникацию.

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

Как только этот первый шаг определен, и все знают, что должно произойти, самое время записать его. Где? Ну, я большой сторонник поддержки README.md . Каждый человек в команде всегда может заглянуть внутрь и узнать о состоянии проекта, и это естественно для новичков в проекте.

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

Подождите минутку… автоматизация необязательна, когда речь идет о DevOps? Разве DevOps — это не отдел человека, занимающегося развертыванием?

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

Итак, давайте подробнее рассмотрим сам DevOps.

Объяснение DevOps

Во-первых, позвольте мне показать вам, чем DevOps не является:

1. Это не просто префикс названия должности
2. Это не команда (но есть «Разработчики» и «Операторы»)
3. это не технология
4. Это не значит «системный администратор, умеющий программировать».
5. Это не означает «автоматизация вещей».
6. Это не значит, что «оперативной группы сейчас нет».

Зная это, вы теперь понимаете, что вы не можете просто «нанять инженера DevOps» или «создать команду DevOps» в компании, чтобы убедиться, что вы ориентированы на будущее. DevOps сродни Agile-разработке. Вы бы наняли Agile-разработчика как такового ? Возможно нет. Либо вы разрабатываете продукт по методу Agile, либо нет.

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

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

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

DevOps Automation — это документация

Вы, наверное, никогда не думали об этом таким образом. Но большинство инструментов, обычно связанных с DevOps, — это инструменты документации :

• Сценарии сборки, написанные для удобочитаемости , служат для документирования процесса сборки.
• Конвейеры непрерывной интеграции документируют процесс интеграции, от создания отдельных частей до целого продукта.
• Конвейеры непрерывного развертывания идут дальше, документируя, как развертывать продукт, который может использовать ваш клиент.
• Файлы управления конфигурацией документируют процесс установки и настройки.
• Спецификации «инфраструктура как код» документируют необходимую инфраструктуру (на самом деле вполне формально!)
• Контейнеры поставляются со своими собственными Dockerfile , которые документируют, как создавать и настраивать данный микросервис.

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

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

С письменными инструкциями у вас будет столько интерпретаций, сколько читателей. Если вы пишете двусмысленную или расплывчатую документацию, человек, который ее читает, заполнит пробелы. Дело в том, что вы не можете контролировать, что попадает в щели.

С кодом намного проще. Без конкретных шагов программа перестанет работать. Эти конкретные шаги являются одним из ключевых аспектов коммуникации DevOps.

Коммуникация DevOps: единственный способ преодолеть разрыв между разработкой и эксплуатацией

В книге «Проект Феникс» мы видим проблемы недавно назначенного менеджера, которому поручено развертывание большого проекта. Поскольку никто не знает, что происходит, все тушат пожары без особого прогресса. В подзаголовке книги упоминается, что это рассказ о DevOps. Я согласен с этим.

Но что интересно, на протяжении всей книги не представлено ни одного нового инструмента. Можете ли вы достичь состояния DevOps, только улучшив коммуникацию? Главные герои книги сделали это, так что есть надежда и для вас!

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

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

Структура команды DevOps: кто в команде?

В идеале у каждого продукта должна быть только одна команда: команда продукта.

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

Результат? Отдел разработки и валидации играл в пинг-понг с отчетами о дефектах. Когда проверка обнаружила тест, который не прошел, разработчики были больше заинтересованы в поиске недостатков в самом тестовом коде, чем в попытках сделать свой собственный код свободным от ошибок.

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

Борьба с отходами — совместная работа

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

Но отходы можно увидеть только с высокого уровня. В рамках одной команды некоторые процедуры могут показаться необходимыми. Однако с точки зрения продукта они могут оказаться бесполезными.

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

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

Принципы DevOps: сохраняйте спокойствие

CALMS — это очень точное описание того, как следует практиковать DevOps:

• культура
• Автоматизация
• бережливый
• Измерение
• обмен

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

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

Однако обмен идеями и инструментами требует общения. Как мы должны их разделить? Куда нам их положить? Полезны ли они для каждого человека в команде или только для небольшой группы?

Если вы сосредоточитесь только на более технических аспектах — автоматизации, бережливом производстве и измерении, — вы упустите суть DevOps. Что хорошего в сценарии автоматизированного развертывания, которым никто кроме автора не пользуется? Если сценарий сэкономит ей время, то это может быть оправдано. Но представьте, сколько времени можно было бы сэкономить, если бы все поделились этим сценарием. Это говорит о борьбе с отходами!

DevOps приближает бизнес к разработке

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

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

Инструменты DevOps в первую очередь? Подумайте еще раз

Конечно, для этого нужны все инструменты.

Но никакие инструменты не заменят хороших коммуникаций и эмпатии внутри компании. Однажды я наблюдал продукт, в котором процесс сборки принадлежал одной команде, а предоставленный код — другой.

Проблемы с системой сборки были обычным явлением. Разработчики не знали, как его использовать. Он был основан на стандартных инструментах, но они были настроены до такой степени, что любая документация, доступная в Интернете, оказалась бесполезной.

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

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

Самый быстрый способ внедрить DevOps? Лучшее общение!

Во введении я упомянул вопрос, который часто задают мне клиенты: «Должен ли я использовать Docker или сразу перейти к Kubernetes?» Прочитав эту статью, вы увидите, что на такой вопрос лучше всего отвечать после некоторой подготовительной работы — с мышлением DevOps.

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

После того, как все требования задокументированы, сделать выбор технологии становится намного проще.

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