Не секрет, что ИТ-принцип «agile» стал мантрой цифровой эпохи. На фоне большой шумихи организации открывают для себя, что идея имеет смысл и увеличивает доходы. Одним из направлений, вызывающих большой интерес, является методология DevOps, предлагающая более коллективный и итеративный подход к управлению задачами на пересечении ИТ- и операционной деятельности. Примерно шесть из каждых десяти организаций сегодня в той или иной форме используют DevOps. Тем не менее для многих предприятий эта идея все еще сложна в реализации. Предлагаем вашему вниманию шесть главных уроков.
DevOps — это философия. Одной из обычных ошибок, которые совершают руководители ИТ-подразделений и бизнеса, по словам Камерона Хейта, вице-президента по исследованиям Gartner, является отношение к DevOps как к комплексу знаний или как к библиотеке ИТ-инфраструктуры. Он говорит: «Здесь нет предписанного набора действий или заранее составленной дорожной карты. Это не продукт деятельности некой комиссии. Это образ мышления, вращающийся вокруг новаторства и экспериментирования. Основными точками приложения является управление релизами и изменениями. И во всем этом главное — быстрота и гибкость». А Дэмон Эдвардс, сооснователь консалтинговой фирмы DTO Solutions, специализирующейся на DevOps, добавляет: «Это не так уж сильно отличается от того, как движение за рационализацию бизнеса превратило способность некоторых промышленных компаний решать поставленные задачи в стратегическое оружие. Движение DevOps следует по тому же пути, только в чисто цифровом контексте».
DevOps быстро растет. Но достижение успехов далеко не гарантировано. Гибкий подход требует особого мышления и приемов.
Первичный драйвер — не CIO. В большинстве случаев DevOps начинается с рядовых сотрудников ИТ-отделов. «Им надоедают звонки в два часа ночи, и у них возникает желание найти иной, лучший способ работы», — поясняет Хейт. Поэтому базисная структура инициативы должна исходить от реальных разработчиков и ИТ-персонала. Однако на определенном уровне должен быть задействован и CIO. «Требуется довольно значительный сдвиг в культуре, и под манифестом гибкой разработки необходимо расставить приоритеты и ранги. Надо определить также метрики, показатели КПД и модели управления». CIO может сыграть ключевую роль в оркестровке инициативы и надзоре за ее реализацией.
DevOps — больше, чем инструмент ИТ-отдела. В подавляющем большинстве компаний DevOps почти всецело рассматривается как нечто для использования в стенах ИТ-группы, отмечает Эдвардс: «Куда меньше внимания уделяется эффектам DevOps в масштабе всей компании, и почти никакого — эффектам DevOps за её стенами ». Однако уроки и принципы этой концепции применимы за границами ИТ-департамента. «DevOps может превратить ИТ-операции в устойчивое конкурентное преимущество», — говорит Эдвардс. Тем не менее он предупреждает, что стандартизированный подход здесь не имеет эффекта. «Не пытайтесь слепо копировать чужие средства или искать образцы для подражания в других подразделениях своей организации. Это не работает, — предупреждает он. — Есть долгая история методов, которые не работали в мире эффективной организации производства, как и масса ранних примеров неудачной стратегии в движении DevOps». Вместо этого Эдвардс предлагает изучать культуру высокой эффективности и разбираться в причинах, лежащих глубже, чем инструменты и процессы.
Важен принцип совместного владения. Одна из проблем традиционных разработок состоит в том, что разные отделы, группы и коллективы устанавливают разные метрики и цели. Однако метрики одной группы могут не иметь ничего общего с метриками другой. Еще хуже, если они друг другу противоречат. Неудачи возникают и тогда, когда что-то передается из одних рук в другие. Нередко задачи или этапы проектов выполняются не на совесть, а чтобы удовлетворить минимальным требованиям. «К сожалению, — указывает Хейт, — смена метрик зачастую не решает проблему. На самом деле надо создавать систему с адекватными стимулами, поощряющими кооперацию и сотрудничество». Эдвардс отмечает, что это большее, чем только противодействие самоизоляции разных подразделений. «Если не работать над организационными и политическими вопросами, с которыми связана разрозненность, вы будете бегать за собственным хвостом, пытаясь исправить симптомы болезни».
Развертывание и расширение инициативы DevOps требует постоянного планирования. Что делает инициативу DevOps одновременно интригующей и пугающей, так это задача наладить комфортную работу людей вне заранее установленных границ. Следовательно, важно подобрать таких членов команды, чьё мышление и личные качества отвечают DevOps. Более того, важно их использовать как миссионеров, продвигающих концепцию в остальные части компании. Возможно, потребуется установить категории и приоритеты для портфеля приложений, учитывая изменяемость проекта, организацию управления и потенциальный эффект.
Коммуникации могут развивать или убивать инициативу. Поскольку коммуникации и сотрудничество находятся в сердце успеха DevOps, критически важно выстроить инфраструктуру, поддерживающую свободный обмен идеями. Фокус внимания, говорит Хейт, должен быть направлен на устранение разрозненности и конфликтов на почве владения. Необходимо, чтобы группы или технические лидеры, связанные с операционной стороной дела, посещали ежедневные короткие совещания, на которых они смогут узнавать, что происходит в конвейере. Не менее важно, чтобы больше людей Dev-профиля участвовало в Ops-совещаниях, включая разборы неудач без поиска козлов отпущения. Концентрироваться нужно на решении проблем и создании таких условий, при которых инцидент или проблема больше не повторятся. Фокус должен быть на проблеме, а не на людях.
