Нет никаких сомнений в том, что DevOps помог многим ИТ-организациям достичь своей цели по доставке приложений и услуг быстрее и лучше, чем традиционные процессы разработки программного обеспечения. К сожалению, в то время как некоторые ИТ-руководители прекрасно рекламируют преимущества DevOps, их команды движутся в неправильном направлении, используя полусырые или совершенно неправильные инструменты и методы.
ИТ-директора несут ответственность за то, чтобы команды разработчиков намеренно или непреднамеренно не отклонялись от пути DevOps. Вот семь предупреждающих знаков, которые предупредят вас о возможном присутствии отклонения от DevOps в вашей организации.
1. Раздельное размещение DevOps
Первый признак неправильной реализации DevOps можно легко обнаружить, просто просмотрев организационную структуру. «Если вы обнаружите, что DevOps находится в отдельном подразделении, отдельном от разработки и эксплуатации, это первый признак того, что-то пошло не по плану. «Создав отдельную команду DevOps, ИТ-директор, по сути, добавил еще один уровень сложности, еще один отдел и еще одну передачу для управления».
Организационная диаграмма должна отражать структуру, которая позволяет командам комплексно решать проблемы во всех соответствующих областях. Отдавайте предпочтение созданию кросс-функциональных команд от проектирования до эксплуатации. «DevOps — это не конвейеры и CI/CD а методология в целом.
2. Сосредоточение внимания на инструментах, а не на людях
Организация, которая слишком сосредоточена на культуре DevOps, ориентированной на инструменты и технологии, а не на людях и процессах, рассинхронизирована на 180 градусов. «Очень важно оценить текущую деловую практику и потребности, — говорит Мохан Кумар, старший архитектор TEKsystems, фирмы по управлению ИТ-услугами.
Кумар рекомендует отдавать приоритет командам. «Внедрите культуру DevOps в общение, совместную работу, сбор отзывов и анализ», — предлагает он. «Дружественная к экспериментам среда, которая позволяет разработчикам быстро ошибаться, быстро восстанавливаться и быстрее учиться, создает в организации культуру без вины». Кумар также предлагает развивать поток творческих идей, используя коллективный разум команд.
Внедрение DevOps — это итеративный процесс, поэтому ИТ-директор должен начать с оценки текущего состояния команды разработчиков, а затем постепенно выстраивать стратегию постоянного совершенствования с участием людей, процессов и инструментов, которые могут развиваться вместе с будущими потребностями и разработками. «В конечном счете, креативность — это мышца, которую нужно постоянно тренировать, чтобы расти», — отмечает Кумар.
3. Слишком мало автоматизации
Поддельный DevOps может возникать, когда руководителям групп не хватает мышления для автоматизации, в частности, способности инвестировать время и ресурсы, необходимые для создания надежной архитектуры с автоматизированной доставкой кода.
Прежде чем продвигать инициативу по автоматизации, внимательно изучите потребности разработки, существующие контракты и текущие проектные группы. «Посмотрите, находятся ли навыки организации на том уровне, на котором вы можете автоматизировать инфраструктуру, — говорит Ян Фогарти, управляющий директор по технологиям и операциям консалтинговой фирмы Accenture Federal Services.
Однако автоматизация может быть палкой о двух концах. Кумар отмечает, что слишком легко непреднамеренно переключиться с ошибочных ручных процессов на ошибочные автоматизированные процессы. Он советует сопротивляться желанию максимально автоматизировать. Вместо этого автоматизируйте столько, сколько это разумно. Конечной целью, отмечает Кумар, должно стать превращение выпусков программного обеспечения в воспроизводимый и надежный автоматизированный процесс развертывания.
4. Бессистемная автоматизация
Хотя автоматизация очень полезна, многие организации переходят на автоматизацию DevOps без достаточного анализа и планирования. «Мы видели организации, которые отдавали приоритет автоматизации, не принимая во внимание другие аспекты, включая управление, людей, процессы и технологии», — говорит Аарон, управляющий директор DevSecOps в Deloitte Risk & Financial Advisory. Такие организации обычно тратят значительное количество времени на пересмотр и исправление работы по автоматизации.
Прежде чем перейти непосредственно к автоматизации, Аарон предлагает установить надежное управление и стандартизировать требования и процессы. «Сотрудничество между бизнес-подразделениями — неотъемлемая часть DevOps, — отмечает он. Устраните любые организационные барьеры, которые могут существовать. «Руководство руководства будет важно для того, чтобы задать тон», — говорит О. «Кроме того, используйте интеллектуальные инструменты оркестрации, чтобы помочь еще больше устранить разрозненность и обеспечить эффективную связь».
5. Вынашивание нереалистичных ожиданий
Старшие технологические лидеры должны сосредоточиться на обязательствах, выходящих за рамки простого внедрения новых технологических инструментов и методов. «Они должны уделять приоритетное внимание меняющейся культуре и мышлению сотрудников», — говорит Тим Поттер, директор Deloitte Consulting. «Они также должны установить реалистичные сроки, чтобы трансформация укоренилась в организации».
По словам Поттера, организация, которая просто развертывает более автоматизированные инструменты и переименовывает существующие команды приложений в «команды DevOps», стремясь полностью контролировать производственные проблемы, скорее всего, будет разочарована результатами.
Технологические лидеры также должны быть готовы принять тот факт, что после перехода на DevOps производительность может сначала снизиться, прежде чем она улучшится. «Они должны быть готовы обеспечить «прикрытие» для своих прикладных групп, что позволит им протестировать и научиться работать с новой моделью», — советует Поттер. «Завышенные ожидания и отсутствие достаточного времени для трансформации может привести к тому, что организации будут принимать DevOps только номинально».
6. Команды, застрявшие в прошлом
Старые привычки умирают с трудом. В течение десятилетий разработка программного обеспечения следовала традиционной методологии водопада, процессу, который требовал заблаговременного сбора требований, создания функций и, наконец, передачи результатов QA и другим командам для выпуска, говорит Ашиш Какран, директор венчурной ИТ-компании Thomvest. Предприятия. «Раньше требовались месяцы, прежде чем клиенты увидели какие-либо новые функции», — отмечает он.
Когда командам разработчиков не удается полностью выбраться из водопада, они сталкиваются с причудливыми комбинациями процессов, которые можно описать как «agilefall», — говорит Какран. «Это указывает на то, что не произошло полного перехода с использованием последних достижений в области разработки программного обеспечения».
Какран предполагает, что быстрый и простой способ выявить борющуюся команду — это изучить их DevOps «Epics» и «Stories».
«В этих задачах часто отражается полный контекст текущего проекта, — объясняет он. «Если вы чувствуете, что месячный проект уже разбит на задачи с небольшой постоянной обратной связью с клиентами или без нее, это признак того, что команда настраивает себя на неудачу, будь то нарушение сроков проекта или отсутствие полезного пользовательского опыта».
7. Негибкость
DevOps — это не универсальная методология. Для максимальной эффективности потоки и инструменты DevOps должны быть настроены в соответствии с конкретными потребностями организации, которые могут сильно различаться в зависимости от ее размера, типов приложений и опыта разработки.
DevOps никогда не должен быть статичным. Процессы и инструменты должны адаптироваться по мере роста организации и стремления к постоянному совершенствованию. Для достижения этих целей требуются гибкие инструменты, а также способность анализировать ключевые показатели эффективности для выявления возможностей улучшения, говорит Винг То, вице-президент по разработке в компании Digitial.ai, которая продает платформу DevOps на основе ИИ. ИТ-руководители также должны помнить о культурных изменениях, необходимых для объединения групп разработки и эксплуатации. Вместо того, чтобы создавать отдельный отдел DevOps, который только создает больше разрозненности и узких мест в процессах, методологию следует интегрировать в каждую область бизнеса.
DevOps в основном касается людей и процессов. ИТ-руководители должны понимать, что эти ресурсы должны зависеть от контекста. «Оптимальный способ использования инструментов и процессов меняется со временем, он динамичен, а не статичен, а инструменты и процессы нуждаются в тщательном обучении для правильного использования».
Достижение баланса
При запуске успешного преобразования DevOps необходимо достичь баланса. «Если вам повезет, целеустремленные команды активизируются и добровольно станут одними из первых, звеньев», — говорит Поттер. «Важно поддерживать эти команды — вознаграждать их за мужество и отмечать их успехи, сохраняя при этом внимание к более широкой дорожной карте трансформации организации».
Помните, однако, что преимущества будут ограничены и отсрочены, если вся организация не примет трансформацию. «Неизбежно возникнут взаимозависимости, которые затормозят команду разработчиков, если более широкая организация не изменит ситуацию», — говорит Поттер.