Трудно уловить главное, говоря о DevOps? Мы собрали для вас яркие аналогии, ударные формулировки и советы от экспертов, которые помогут дойти до сути даже неспециалистам. В конце бонус – собственный DevOps сотрудников Red Hat.
Термин DevOps возник 10 лет назад и прошел путь от хэштега в Твиттере до мощного культурного движения в мире ИТ, настоящей философии, поощряющей разработчиков быстрее добиваться результатов, экспериментировать и двигаться вперед методом итераций. DevOps стал неразрывно связан с понятием цифровой трансформации. Но как это часто бывает с ИТ-терминологией, за десяток лет DevOps успел обрасти множеством определений, трактовок и заблуждений на свой счет.
Поэтому про DevOps нередко можно услышать вопросы вроде, это то же самое, что agile? Или это какая-то особая методология? Или это просто еще один синоним слова «сотрудничество»?
DevOps включает в себя много разных концепций (непрерывная доставка, непрерывная интеграция, автоматизация и т. п.), поэтому вычленить главное может быть непросто, особенно когда вы неравнодушны к предмету. Однако это умение очень полезно, неважно, пытаетесь ли вы донести свои идеи до начальства или же просто рассказываете о своей работе кому-то из родных или знакомых. Поэтому пока отложим в сторону терминологические нюансы DevOps и сосредоточимся на общей картине.
Мы попросили специалистов объяснить суть DevOps максимально просто и коротко, чтобы ее ценность стала понятна читателю с любым уровнем технической подготовки. По итогам этих бесед мы отобрали самые яркие аналогии и ударные формулировки, которые помогут вам выстроить свой рассказ о DevOps.
«DevOps – это культурное движение, в рамках которого обе стороны (разработчики ПО и специалисты по эксплуатации ИТ-систем) признают, что софт не приносит реальной пользы до тех пор, пока им не начинает кто-то пользоваться: заказчики, клиенты, сотрудники, не суть, – считает Эвелина Эрлих (Eveline Oehrlich) старший аналитик-исследователь Института DevOps. – Поэтому обе эти стороны совместно обеспечивают быструю и качественную доставку софта».
«DevOps наделяет разработчиков полномочиями на владение приложениями, их запуск и управление доставкой от начала и до конца»
«Обычно о DevOps говорят, как о способе ускорить доставку приложений в продакшн за счет выстраивания и применения автоматизированных процессов, – говорит Джей Шнайп (Jai Schniepp), директор по платформам DevOps страховой компании Liberty Mutual. – Но для меня это гораздо более фундаментальная вещь. DevOps наделяет разработчиков полномочиями на владение приложениями или определенными частями ПО, на их запуск и управление доставкой от начала и до конца. DevOps устраняет неразбериху с ответственностью и ведет всех участников процесса к созданию автоматизированной и управляемой разработчиком инфраструктуры».
«Проще говоря, DevOps – это такой подход к производству и доставке ПО, когда все работают вместе», – отмечает Гур Стаф, президент и руководитель направления автоматизации цифрового бизнеса компании BMC.
«Конвейерная сборка возможна, только если все детали подходят друг к другу».
«Я бы сравнил DevOps с конвейером по сборке автомобилей, – продолжает Гур Стаф. – Идея в том, чтобы заранее спроектировать и сделать все детали так, чтобы потом их можно было собрать без индивидуальной подгонки. Конвейерная сборка возможна, только если все детали подходят друг к другу. Те, кто проектирует и делает двигатель, должны подумать о том, как крепить его к кузову или раме. Те, кто делает тормоза, должны подумать о колесах, и так далее. Точно так же должно быть и с софтом.
Разработчик, создающий бизнес-логику или пользовательский интерфейс, должен подумать о базе данных, хранящей сведения о заказчиках, о средствах безопасности для защиты пользовательских данных, а также о том, как все это будет работать, когда сервис начнет обслуживать большую, возможно, даже многомиллионную аудиторию пользователей».
«Сделать так, чтобы люди сотрудничали и думали о тех частях работы, которые выполняются другими, а не концентрировались исключительно на своих собственных задачах – вот величайшее препятствие, которое надо преодолеть. Если это удается, у вас появляются отличные шансы на цифровую трансформацию», – добавляет Гур Стаф.
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps, предложила отличную аналогию для объяснения DevOps. По ее словам, «DevOps – это как кулинарный рецепт, в котором есть три основные категории ингредиентов: люди, процессы и автоматизация. Большинство этих ингредиентов можно взять из других областей и источников: Lean, Agile, SRE, CI/CD, ITIL, лидерство, культура, инструменты. Секрет DevOps, как и любого хорошего рецепта, в том, как правильно подобрать пропорции и смешать эти ингредиенты, чтобы повысить скорость и результативность работы при создании и выпуске приложений».
«Гонка планируется не от старта к финишу, а наоборот, от финиша к старту».
«Говоря о том, чего ждать от инициативы DevOps, я привожу в пример гоночную команду NASCAR или Формулы-1, – говорит Крис Шорт (Chris Short), главный менеджер по маркетингу облачных платформ Red Hat и издатель рассылки DevOps’ish. – У руководителя такой команды одна цель: занять по итогам гонки максимально возможное место с учетом имевшихся у команды ресурсов и выпавших на ее долю испытаний. При этом гонка планируется не от старта к финишу, а наоборот, от финиша к старту. Вначале ставится амбициозная цель, а затем определяются пути ее достижения. После чего они разбиваются на подзадачи и делегируются членам команды».
«Всю неделю перед гонкой команда оттачивает пит-стоп. Занимается силовыми и кардиотренировками, чтобы быть в форме в изнурительный день гонок. Отрабатывает совместные действия при решении любых проблем, которые могут возникнуть на гонке. Аналогично команда разработчиков должна тренировать навыки частого выпуска новых версий. При наличии таких навыков и отлаженной системы безопасности запуск новых версий в продакшн тоже происходит чаще. В рамках этого мировоззрения рост скорости означает рост безопасности», – говорит Шорт.
«Дело не в том, чтобы делать «правильные вещи», – добавляет Шорт, – а в том, чтобы устранять как можно больше вещей, которые стоят на пути к желаемому результату. Сотрудничайте и адаптируйтесь с учетом обратной связи, которую вы получаете в реальном времени. Будьте готовы к аномалиям и работайте над повышением качества, чтобы свести к минимуму их влияние на движение к цели. Именно это ожидает нас в мире DevOps».
Просто DevOps и массовый DevOps – это абсолютно разные вещи. Мы расскажем, как преодолеть барьеры на пути от первого ко второму.
Для многих организаций путь к DevOps начинается легко и приятно. Создаются небольшие пассионарные команды, старые процессы заменяются на новые и первые успехи не заставляют себя ждать.
Увы, это лишь фальшивый блеск, иллюзия прогресса, как говорит Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland. Ранние победы конечно обнадеживают, но не помогают достичь конечной цели, а именно, массового использования DevOps в организации.
Легко видеть, что в результате формируется культура разделения на «мы» и «они».
«Зачастую организации запускают такие проекты-первопроходцы, считая, что они проложат путь к массовому DevOps, не задумываясь, смогут и захотят ли пойти этим путем остальные, – объясняет Бен Гриннел. – Команды для реализации таких проектов обычно набирают из самоуверенных “варягов”, которые уже делали нечто подобное в других местах, но являются новичками в вашей организации. При этом их поощряют ломать и разрушать правила, которые остаются обязательными для всех остальных. Легко видеть, что в результате формируется культура разделения на «мы» и «они», которая препятствует передаче знаний и навыков».
«И эта культурная проблема – лишь одна из причин того, что DevOps сложно масштабировать. Команды DevOps сталкиваются с ростом сугубо технических сложностей, характерным для быстроразвивающихся компаний, сделавших ставку на ИТ-технологии», – говорит Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr.
«В современном мире услуги меняются сразу, как только появляется такая необходимость. Постоянно реализовывать и внедрять новые функции, конечно, здорово, но вот координировать этот процесс и устранять возникающие проблемы – настоящая головная боль, – добавляет Стив Ньюман. – В очень быстро растущих организациях инженеры в составе кросс-функциональных команд борются за то, чтобы сохранить за собой возможность отслеживать изменения и порождаемые ими каскадные эффекты на уровне зависимостей. Более того, инженеров отнюдь не радует, когда их лишают такой возможности и в результате им становится труднее понимать суть возникающих проблем».
Как же преодолеть эти описанные выше трудности и перейти к массовому использованию DevOps в крупной организации? Эксперты призывают запастись терпением, даже если ваша конечная цель состоит в том, чтобы ускорить цикл разработки ПО и бизнес-процессы.
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps: «На мой взгляд, расширение DevOps должно быть таким же постепенным и итеративным, как и agile-разработка (и в равной мере затрагивать культуру). В Agile и DevOps упор делается на небольшие команды. Но по мере роста числа и интеграции таких команд мы получаем все больше людей, применяющих новые методы работы, и, как следствие, возникает масштабная культурная трансформация».
Эран Кинсбрюнер (Eran Kinsbruner), ведущий технический евангелист компании Perfecto: «Чтобы масштабирование сработало, командам DevOps в начале надо научиться сочетать традиционные процессы, инструменты и навыки, а затем медленно взращивать каждую отдельную фазу DevOps и стабилизировать ее. Все начинается с тщательного планирования пользовательских историй (userstory) и потоков создания ценности (valuestream), после чего наступает этап написания ПО и контроля версий с использованием trunk-based development или других подходов, наиболее подходящих для ветвления и слияние кода».
«Затем следует этап интеграции и тестирования, где уже требуется масштабируемая платформа для автоматизации. И здесь командам DevOps важно выбрать правильную платформу, которая отвечала бы их уровню навыков и конечным целям проекта.
Следующая фаза – развертывание в производственной среде, и оно должно быть полностью автоматизировано с использованием инструментов оркестрации и контейнеров. При этом важно иметь виртуализированные среды на всех этапах DevOps (симулятор производственной среды, среда контроля качества и, собственно, производственная среда) и всегда использовать для тестов только самые последние данные, чтобы получать актуальные выводы. Аналитика должны быть умной и способной обрабатывать большие данные с быстрой и действенной обратной связью».
Гордон Хафф (Gordon Haff), евангелист RedHat: «Создание системы и атмосферы, разрешающей и поощряющей эксперименты, позволяет реализовать так называемые успешные сбои в agile-разработке ПО. Это не значит, что за сбои больше никто не отвечает. На самом деле установить ответственного становится даже проще, поскольку «быть ответственным» больше не означает «стать виновником аварии». То есть суть ответственности качественно меняется. При этом крайне важными становятся четыре фактора: масштабы сбоя, подходы, производственные процессы и стимулы». (Подробнее об этих факторах можно прочитать в статье Гордона Хаффа «DevOps lessons: 4 aspects of healthy experiments».)
Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland: «Чтобы добиться масштабирования, я рекомендую вместе с проектами-первопроходцами запускать программу «расчистки пути». Цель этой программы – убирать мусор, который остается за первопроходцами DevOps, вроде потерявших актуальность правил и прочих подобных вещей, чтобы путь вперед оставался свободен».
«Дайте людям организационную поддержку и придайте импульс через коммуникацию, которая выходит далеко за рамки группы первопроходцев, широко празднуя успехи новых методов работы. Тренируйте людей, которые задействованы в следующей волне проектов DevOps и нервничают из-за того, что используют DevOps впервые. И помните, что эти люди сильно отличаются от первопроходцев».
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Инструменты не надо прятать от людей, и они должны быть относительно просты в освоении для любого, кто готов потратить на это время. Если возможность запрашивать логи предоставлена только трем людям, «сертифицированным» для работы с каким-то инструментом, у вас всегда будет максимум три человека, способных разобраться с соответствующей проблемой, даже если у вас очень большая вычислительная среда. Иначе говоря, здесь возникает узкое место, которое может привести к серьезным (для бизнеса) последствиям».
Том Кларк (Tom Clark), руководитель направления Common Platform в телекомпании ITV: «Вы можете сделать что угодно, но не все сразу. Поэтому ставьте большие цели, начинайте с малого и двигайтесь вперед быстрыми итерациями. Со временем вы заработаете репутацию команды, у которой все получается, поэтому другие тоже захотят использовать ваши методы. И не гонитесь за выстраиванием высокоэффективной команды. Вместо этого обеспечьте людям идеальные условия для работы и эффективность придет сама собой».
Логан Дейгл (Logan Daigle), директор по доставке ПО и стратегии DevOps компании CollabNetVersionOne: «Важно осознавать последствия закона Конвея. В моем вольном пересказе этот закон гласит, что продукты, которые мы создаем, и процессы, которые мы при этом используем, включая DevOps, оказываются устроены так же, как и наша организация».
«Если в организация высока разобщенность, а при планировании, создании и выпуске ПО управление много раз переходит из рук в руки, эффект от масштабирования будет нулевым или недолговечным. Если же организация формирует кросс-функциональные команды вокруг продуктов, которые финансируются с ориентацией на рынок, то шансы на успех резко возрастают».
«Еще один важный аспект масштабирования заключается в том, чтобы отображать на канбан-досках все работы, находящиеся в процессе выполнения (WIP, workinprogress). Когда в организации появляется место, где люди могут видеть такие вещи, это сильно стимулирует сотрудничество, что положительно сказывается на масштабировании».
Манюэль Паис (Manuel Pais), консультант по DevOps и соавтор книги «Team Topologies»: «Вывод практик DevOps за пределы собственно Devи Opsи попытку применить их к другим функциям вряд ли можно назвать оптимальным подходом. Это, несомненно, даст определенный эффект (например, за счет автоматизации ручного управления), но можно добиться гораздо большего, если начать с понимания процессов доставки и обратной связи».
«Если в ИТ-системе организации есть старые шрамы – процедуры и механизмы управления, которые были внедрены по итогам прошлых инцидентов, но утратили актуальность (из-за смены продуктов, технологий или процессов), – то их, безусловно, надо удалять или разглаживать, а не автоматизировать неэффективные или ненужные процессы».
Энтони Эдвардс (Antony Edwards), директор по производству компании Eggplant: «DevOps – очень расплывчатый термин, поэтому у каждой команды получается свой вариантDevOps. И нет ничего хуже, когда в организации появляются сразу 20 разновидностейDevOps, которые не очень хорошо уживаются вместе. Нельзя, чтобы у каждой из трех команды разработчиков был свой, особый интерфейсом между разработкой и управлением продуктом. Как и нельзя, чтобы продукты имели свои, уникальные ожидания в части обработки обратной связи при переносе в симулятор производственной среды. Иначе у вас никогда не получиться масштабироватьDevOps».
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Поработайте над признанием ценности DevOps. Научитесь и не стесняйтесь рассказывать о пользе того, что вы делаете. DevOps невероятно экономит время и деньги (просто подумайте: меньше простоев, короче среднее время восстановления), и команды DevOps должны неустанно подчеркивать (и проповедовать) важность этих инициатив для успеха бизнеса. Так вы сможете расширить круг адептов и усилить влияние DevOps в организации».
На Red Hat Forum Russia 13 сентября прилетит наш собственный DevOps – да, у Red Hat, как у производителя программного обеспечения, есть собственные DevOps команды и практики.
Наш инженер Марк Биргер, который занимается разработкой служб внутренней автоматизации для других групп по всей организации, на чистом русском языке расскажет собственную историю – как DevOps команда Red Hat мигрировала приложения из виртуальных сред Hat Virtualization, управляемых Ansible в полноценный контейнерный формат на платформе OpenShift.
Но и это еще не все:
После того как организации перенесли рабочие нагрузки в контейнеры, традиционные методы мониторинга приложений могут не сработать. Во втором докладе мы объясним нашу мотивацию к изменению способа регистрации и покажем продолжение пути, который привел нас к современным методам ведения журналов и мониторинга.
Термин DevOps возник 10 лет назад и прошел путь от хэштега в Твиттере до мощного культурного движения в мире ИТ, настоящей философии, поощряющей разработчиков быстрее добиваться результатов, экспериментировать и двигаться вперед методом итераций. DevOps стал неразрывно связан с понятием цифровой трансформации. Но как это часто бывает с ИТ-терминологией, за десяток лет DevOps успел обрасти множеством определений, трактовок и заблуждений на свой счет.
Поэтому про DevOps нередко можно услышать вопросы вроде, это то же самое, что agile? Или это какая-то особая методология? Или это просто еще один синоним слова «сотрудничество»?
DevOps включает в себя много разных концепций (непрерывная доставка, непрерывная интеграция, автоматизация и т. п.), поэтому вычленить главное может быть непросто, особенно когда вы неравнодушны к предмету. Однако это умение очень полезно, неважно, пытаетесь ли вы донести свои идеи до начальства или же просто рассказываете о своей работе кому-то из родных или знакомых. Поэтому пока отложим в сторону терминологические нюансы DevOps и сосредоточимся на общей картине.
Что такое DevOps: 6 определений и аналогий
Мы попросили специалистов объяснить суть DevOps максимально просто и коротко, чтобы ее ценность стала понятна читателю с любым уровнем технической подготовки. По итогам этих бесед мы отобрали самые яркие аналогии и ударные формулировки, которые помогут вам выстроить свой рассказ о DevOps.
1. DevOps – это культурное движение
«DevOps – это культурное движение, в рамках которого обе стороны (разработчики ПО и специалисты по эксплуатации ИТ-систем) признают, что софт не приносит реальной пользы до тех пор, пока им не начинает кто-то пользоваться: заказчики, клиенты, сотрудники, не суть, – считает Эвелина Эрлих (Eveline Oehrlich) старший аналитик-исследователь Института DevOps. – Поэтому обе эти стороны совместно обеспечивают быструю и качественную доставку софта».
2. DevOps – это то, что наделяет властью разработчиков
«DevOps наделяет разработчиков полномочиями на владение приложениями, их запуск и управление доставкой от начала и до конца»
«Обычно о DevOps говорят, как о способе ускорить доставку приложений в продакшн за счет выстраивания и применения автоматизированных процессов, – говорит Джей Шнайп (Jai Schniepp), директор по платформам DevOps страховой компании Liberty Mutual. – Но для меня это гораздо более фундаментальная вещь. DevOps наделяет разработчиков полномочиями на владение приложениями или определенными частями ПО, на их запуск и управление доставкой от начала и до конца. DevOps устраняет неразбериху с ответственностью и ведет всех участников процесса к созданию автоматизированной и управляемой разработчиком инфраструктуры».
3. DevOps – это сотрудничество при создании и доставке приложений
«Проще говоря, DevOps – это такой подход к производству и доставке ПО, когда все работают вместе», – отмечает Гур Стаф, президент и руководитель направления автоматизации цифрового бизнеса компании BMC.
4. DevOps – это конвейер
«Конвейерная сборка возможна, только если все детали подходят друг к другу».
«Я бы сравнил DevOps с конвейером по сборке автомобилей, – продолжает Гур Стаф. – Идея в том, чтобы заранее спроектировать и сделать все детали так, чтобы потом их можно было собрать без индивидуальной подгонки. Конвейерная сборка возможна, только если все детали подходят друг к другу. Те, кто проектирует и делает двигатель, должны подумать о том, как крепить его к кузову или раме. Те, кто делает тормоза, должны подумать о колесах, и так далее. Точно так же должно быть и с софтом.
Разработчик, создающий бизнес-логику или пользовательский интерфейс, должен подумать о базе данных, хранящей сведения о заказчиках, о средствах безопасности для защиты пользовательских данных, а также о том, как все это будет работать, когда сервис начнет обслуживать большую, возможно, даже многомиллионную аудиторию пользователей».
«Сделать так, чтобы люди сотрудничали и думали о тех частях работы, которые выполняются другими, а не концентрировались исключительно на своих собственных задачах – вот величайшее препятствие, которое надо преодолеть. Если это удается, у вас появляются отличные шансы на цифровую трансформацию», – добавляет Гур Стаф.
5. DevOps – это правильная комбинация людей, процессов и автоматизация
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps, предложила отличную аналогию для объяснения DevOps. По ее словам, «DevOps – это как кулинарный рецепт, в котором есть три основные категории ингредиентов: люди, процессы и автоматизация. Большинство этих ингредиентов можно взять из других областей и источников: Lean, Agile, SRE, CI/CD, ITIL, лидерство, культура, инструменты. Секрет DevOps, как и любого хорошего рецепта, в том, как правильно подобрать пропорции и смешать эти ингредиенты, чтобы повысить скорость и результативность работы при создании и выпуске приложений».
6. DevOps – это когда программисты работают, как команда Формулы-1
«Гонка планируется не от старта к финишу, а наоборот, от финиша к старту».
«Говоря о том, чего ждать от инициативы DevOps, я привожу в пример гоночную команду NASCAR или Формулы-1, – говорит Крис Шорт (Chris Short), главный менеджер по маркетингу облачных платформ Red Hat и издатель рассылки DevOps’ish. – У руководителя такой команды одна цель: занять по итогам гонки максимально возможное место с учетом имевшихся у команды ресурсов и выпавших на ее долю испытаний. При этом гонка планируется не от старта к финишу, а наоборот, от финиша к старту. Вначале ставится амбициозная цель, а затем определяются пути ее достижения. После чего они разбиваются на подзадачи и делегируются членам команды».
«Всю неделю перед гонкой команда оттачивает пит-стоп. Занимается силовыми и кардиотренировками, чтобы быть в форме в изнурительный день гонок. Отрабатывает совместные действия при решении любых проблем, которые могут возникнуть на гонке. Аналогично команда разработчиков должна тренировать навыки частого выпуска новых версий. При наличии таких навыков и отлаженной системы безопасности запуск новых версий в продакшн тоже происходит чаще. В рамках этого мировоззрения рост скорости означает рост безопасности», – говорит Шорт.
«Дело не в том, чтобы делать «правильные вещи», – добавляет Шорт, – а в том, чтобы устранять как можно больше вещей, которые стоят на пути к желаемому результату. Сотрудничайте и адаптируйтесь с учетом обратной связи, которую вы получаете в реальном времени. Будьте готовы к аномалиям и работайте над повышением качества, чтобы свести к минимуму их влияние на движение к цели. Именно это ожидает нас в мире DevOps».
Как масштабировать DevOps: 10 советов от экспертов
Просто DevOps и массовый DevOps – это абсолютно разные вещи. Мы расскажем, как преодолеть барьеры на пути от первого ко второму.
Для многих организаций путь к DevOps начинается легко и приятно. Создаются небольшие пассионарные команды, старые процессы заменяются на новые и первые успехи не заставляют себя ждать.
Увы, это лишь фальшивый блеск, иллюзия прогресса, как говорит Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland. Ранние победы конечно обнадеживают, но не помогают достичь конечной цели, а именно, массового использования DevOps в организации.
Легко видеть, что в результате формируется культура разделения на «мы» и «они».
«Зачастую организации запускают такие проекты-первопроходцы, считая, что они проложат путь к массовому DevOps, не задумываясь, смогут и захотят ли пойти этим путем остальные, – объясняет Бен Гриннел. – Команды для реализации таких проектов обычно набирают из самоуверенных “варягов”, которые уже делали нечто подобное в других местах, но являются новичками в вашей организации. При этом их поощряют ломать и разрушать правила, которые остаются обязательными для всех остальных. Легко видеть, что в результате формируется культура разделения на «мы» и «они», которая препятствует передаче знаний и навыков».
«И эта культурная проблема – лишь одна из причин того, что DevOps сложно масштабировать. Команды DevOps сталкиваются с ростом сугубо технических сложностей, характерным для быстроразвивающихся компаний, сделавших ставку на ИТ-технологии», – говорит Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr.
«В современном мире услуги меняются сразу, как только появляется такая необходимость. Постоянно реализовывать и внедрять новые функции, конечно, здорово, но вот координировать этот процесс и устранять возникающие проблемы – настоящая головная боль, – добавляет Стив Ньюман. – В очень быстро растущих организациях инженеры в составе кросс-функциональных команд борются за то, чтобы сохранить за собой возможность отслеживать изменения и порождаемые ими каскадные эффекты на уровне зависимостей. Более того, инженеров отнюдь не радует, когда их лишают такой возможности и в результате им становится труднее понимать суть возникающих проблем».
Как же преодолеть эти описанные выше трудности и перейти к массовому использованию DevOps в крупной организации? Эксперты призывают запастись терпением, даже если ваша конечная цель состоит в том, чтобы ускорить цикл разработки ПО и бизнес-процессы.
1. Помните, что для изменений в культуре нужно время
Джейн Гролл (Jayne Groll), исполнительный директор Института DevOps: «На мой взгляд, расширение DevOps должно быть таким же постепенным и итеративным, как и agile-разработка (и в равной мере затрагивать культуру). В Agile и DevOps упор делается на небольшие команды. Но по мере роста числа и интеграции таких команд мы получаем все больше людей, применяющих новые методы работы, и, как следствие, возникает масштабная культурная трансформация».
2. Уделите достаточно времени планированию и выбору платформы
Эран Кинсбрюнер (Eran Kinsbruner), ведущий технический евангелист компании Perfecto: «Чтобы масштабирование сработало, командам DevOps в начале надо научиться сочетать традиционные процессы, инструменты и навыки, а затем медленно взращивать каждую отдельную фазу DevOps и стабилизировать ее. Все начинается с тщательного планирования пользовательских историй (userstory) и потоков создания ценности (valuestream), после чего наступает этап написания ПО и контроля версий с использованием trunk-based development или других подходов, наиболее подходящих для ветвления и слияние кода».
«Затем следует этап интеграции и тестирования, где уже требуется масштабируемая платформа для автоматизации. И здесь командам DevOps важно выбрать правильную платформу, которая отвечала бы их уровню навыков и конечным целям проекта.
Следующая фаза – развертывание в производственной среде, и оно должно быть полностью автоматизировано с использованием инструментов оркестрации и контейнеров. При этом важно иметь виртуализированные среды на всех этапах DevOps (симулятор производственной среды, среда контроля качества и, собственно, производственная среда) и всегда использовать для тестов только самые последние данные, чтобы получать актуальные выводы. Аналитика должны быть умной и способной обрабатывать большие данные с быстрой и действенной обратной связью».
3. Избавьте ответственности от привкуса вины
Гордон Хафф (Gordon Haff), евангелист RedHat: «Создание системы и атмосферы, разрешающей и поощряющей эксперименты, позволяет реализовать так называемые успешные сбои в agile-разработке ПО. Это не значит, что за сбои больше никто не отвечает. На самом деле установить ответственного становится даже проще, поскольку «быть ответственным» больше не означает «стать виновником аварии». То есть суть ответственности качественно меняется. При этом крайне важными становятся четыре фактора: масштабы сбоя, подходы, производственные процессы и стимулы». (Подробнее об этих факторах можно прочитать в статье Гордона Хаффа «DevOps lessons: 4 aspects of healthy experiments».)
4. Расчищайте путь вперед
Бен Гриннел (Ben Grinnell), управляющий директор и руководитель направления цифровых технологий консалтинговой фирмы North Highland: «Чтобы добиться масштабирования, я рекомендую вместе с проектами-первопроходцами запускать программу «расчистки пути». Цель этой программы – убирать мусор, который остается за первопроходцами DevOps, вроде потерявших актуальность правил и прочих подобных вещей, чтобы путь вперед оставался свободен».
«Дайте людям организационную поддержку и придайте импульс через коммуникацию, которая выходит далеко за рамки группы первопроходцев, широко празднуя успехи новых методов работы. Тренируйте людей, которые задействованы в следующей волне проектов DevOps и нервничают из-за того, что используют DevOps впервые. И помните, что эти люди сильно отличаются от первопроходцев».
5. Сделайте инструменты более демократичными
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Инструменты не надо прятать от людей, и они должны быть относительно просты в освоении для любого, кто готов потратить на это время. Если возможность запрашивать логи предоставлена только трем людям, «сертифицированным» для работы с каким-то инструментом, у вас всегда будет максимум три человека, способных разобраться с соответствующей проблемой, даже если у вас очень большая вычислительная среда. Иначе говоря, здесь возникает узкое место, которое может привести к серьезным (для бизнеса) последствиям».
6. Создайте идеальные условия для работы команды
Том Кларк (Tom Clark), руководитель направления Common Platform в телекомпании ITV: «Вы можете сделать что угодно, но не все сразу. Поэтому ставьте большие цели, начинайте с малого и двигайтесь вперед быстрыми итерациями. Со временем вы заработаете репутацию команды, у которой все получается, поэтому другие тоже захотят использовать ваши методы. И не гонитесь за выстраиванием высокоэффективной команды. Вместо этого обеспечьте людям идеальные условия для работы и эффективность придет сама собой».
7. Не забывайте о законе Конвея и канбан-досках
Логан Дейгл (Logan Daigle), директор по доставке ПО и стратегии DevOps компании CollabNetVersionOne: «Важно осознавать последствия закона Конвея. В моем вольном пересказе этот закон гласит, что продукты, которые мы создаем, и процессы, которые мы при этом используем, включая DevOps, оказываются устроены так же, как и наша организация».
«Если в организация высока разобщенность, а при планировании, создании и выпуске ПО управление много раз переходит из рук в руки, эффект от масштабирования будет нулевым или недолговечным. Если же организация формирует кросс-функциональные команды вокруг продуктов, которые финансируются с ориентацией на рынок, то шансы на успех резко возрастают».
«Еще один важный аспект масштабирования заключается в том, чтобы отображать на канбан-досках все работы, находящиеся в процессе выполнения (WIP, workinprogress). Когда в организации появляется место, где люди могут видеть такие вещи, это сильно стимулирует сотрудничество, что положительно сказывается на масштабировании».
8. Ищите старые шрамы
Манюэль Паис (Manuel Pais), консультант по DevOps и соавтор книги «Team Topologies»: «Вывод практик DevOps за пределы собственно Devи Opsи попытку применить их к другим функциям вряд ли можно назвать оптимальным подходом. Это, несомненно, даст определенный эффект (например, за счет автоматизации ручного управления), но можно добиться гораздо большего, если начать с понимания процессов доставки и обратной связи».
«Если в ИТ-системе организации есть старые шрамы – процедуры и механизмы управления, которые были внедрены по итогам прошлых инцидентов, но утратили актуальность (из-за смены продуктов, технологий или процессов), – то их, безусловно, надо удалять или разглаживать, а не автоматизировать неэффективные или ненужные процессы».
9. Не плодите варианты DevOps
Энтони Эдвардс (Antony Edwards), директор по производству компании Eggplant: «DevOps – очень расплывчатый термин, поэтому у каждой команды получается свой вариантDevOps. И нет ничего хуже, когда в организации появляются сразу 20 разновидностейDevOps, которые не очень хорошо уживаются вместе. Нельзя, чтобы у каждой из трех команды разработчиков был свой, особый интерфейсом между разработкой и управлением продуктом. Как и нельзя, чтобы продукты имели свои, уникальные ожидания в части обработки обратной связи при переносе в симулятор производственной среды. Иначе у вас никогда не получиться масштабироватьDevOps».
10. Проповедуйте ценность DevOps для бизнеса
Стив Ньюман (Steve Newman), основатель и председатель правления компании Scalyr: «Поработайте над признанием ценности DevOps. Научитесь и не стесняйтесь рассказывать о пользе того, что вы делаете. DevOps невероятно экономит время и деньги (просто подумайте: меньше простоев, короче среднее время восстановления), и команды DevOps должны неустанно подчеркивать (и проповедовать) важность этих инициатив для успеха бизнеса. Так вы сможете расширить круг адептов и усилить влияние DevOps в организации».
БОНУС
На Red Hat Forum Russia 13 сентября прилетит наш собственный DevOps – да, у Red Hat, как у производителя программного обеспечения, есть собственные DevOps команды и практики.
Наш инженер Марк Биргер, который занимается разработкой служб внутренней автоматизации для других групп по всей организации, на чистом русском языке расскажет собственную историю – как DevOps команда Red Hat мигрировала приложения из виртуальных сред Hat Virtualization, управляемых Ansible в полноценный контейнерный формат на платформе OpenShift.
Но и это еще не все:
После того как организации перенесли рабочие нагрузки в контейнеры, традиционные методы мониторинга приложений могут не сработать. Во втором докладе мы объясним нашу мотивацию к изменению способа регистрации и покажем продолжение пути, который привел нас к современным методам ведения журналов и мониторинга.
