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

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

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

У симфонистов одна общая цель — совершенная гармония (совершенство — вещь относительная, конечно) и наиболее точное воплощение замысла композитора (например, Людвик ван Бетховен, любимый фанатичными реципиентами), и все это с долей (более или менее) ) определенной манеры исполнения, характерной для данного музыкального периода. Но какое это имеет отношение к DevOps?

Представьте себе такую ​​ситуацию. У нас есть симфонический оркестр, в состав которого входят только именитые инструментальные музыканты. Они получают музыкальное произведение в виде записи, например, как показано ниже (для музыкантов схемы ИТ-систем выглядят «более или менее одинаково»). И если предположить, что у них аналогичные музыкальные знания в области нотной грамоты и невероятные технические навыки, они начинают исполнять произведение.

Яннис Ксенакис, Metastaseis, 1954

Возникает вопрос: будет ли художественный успех? Если кто-то руководил оркестром или ансамблями, кажется, что ответ очевиден — нет, не будет. Очевидно, это будет вызвано различиями в понимании намерения, в интерпретации обозначений (музыкального или ИТ-проекта) и т. д.

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

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

Существуют группы людей (специалистов) разной компетенции, которые, однако, преследуют одни и те же цели или, по крайней мере, настойчиво их преследуют. Между тем, как все мы знаем, во многих методах управления реализация общей цели, такой как эффективный процесс продаж (на основе ИТ-системы), существенно фрагментирована.

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

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

Ключ к пониманию DevOps

Чтобы хорошо понять концепцию DevOps, не только с точки зрения «современных» ИТ-инструментов и новых названий должностей специалистов в вашей компании, вам необходимо внимательно изучить три аспекта работы над ИТ-решением. Во-первых, качество, во-вторых, своевременность (фактор «времени выхода на рынок») и, в-третьих, стоимость производства данной ИТ-системы. Итак, давайте позаботимся о «крыше» «бережливой мануфактуры» — трех важнейших факторах успеха ИТ-проекта (и не только).

Бережливое производство

Напоминаем, что официальное определение термина «качество» из PN-EN 9000: 2001: «Качество — это степень, в которой набор присущих свойств соответствует требованиям».

Как мы знаем, каноническому ИТ-проекту предшествует этап технико-экономического обоснования и анализа. Конечно, в эту «сумку» входит бизнес-анализ, в том числе оценка рентабельности проекта, общей стоимости его реализации и т. Д. Как известно, в классическом подходе этот этап выполняется узкой группой. специалистов в области бизнес-анализа и технологического анализа, при активном участии т.н. «Бизнес», то есть заинтересованные ведомства. Чаще всего разработанные технические концепции начинают фазу проектирования системы — на этом этапе ИТ-составляющая уже является явной доминантой.

Проектирование системы с использованием классического каскадного подхода — это техническая реализация видения, определенного в продуктах аналитического этапа (читайте: в документации). Здесь не так много возможностей для «улучшения» и «предложения» других, возможно, лучших решений. Интересно, что во многих случаях системные проектировщики (или «технические архитекторы»), реализующие этап проектирования, как правило, являются специалистами со знаниями, выходящими далеко за рамки технологий, то есть знаниями, охватывающими технологический материал, в котором они должны реализовывать ИТ-проекты. Уже на этом этапе мы видим «удушение» потенциала знаний.

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

DevOps

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

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

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

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

DevOps на практике

На практике DevOps сводится к активной поддержке руководством описанных ниже инициатив во всех сферах создания ИТ-решений (от идеи до реализации).

Организация и свободный обмен знаниями

Реализация данной инициативы в первую очередь связана с организацией концептуальной работы всех участников разработки программного обеспечения (а шире ИТ-решений) путем создания единой платформы для обмена знаниями (не только информацией) о создаваемых и разрабатываемых проектах. Это может быть решение в виде «Wiki» страниц, содержащих четко задокументированные описания случаев и «происшествий» в проводимом проекте, его участниках, его стратегических и тактических целях и т. Д.

Сама по себе документация не является здесь достаточно (sic!).

знание  = (новая) информация + информация об опыте = данные + контекст опыт = знания (уже приобретено)

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

Во многих случаях достаточно использовать готовые функции, доступные в интегрированных системах поддержки разработки программного обеспечения, таких как GitLab. Системы этого типа обычно содержат все функции, используемые в процессе разработки программного обеспечения: от страниц с энциклопедическими знаниями о проектах, используемых на этапах концептуальной разработки и разработки программного обеспечения, до функций обработки отчетов (например, ошибок), управления кодом и версиями программного обеспечения. , код автоматической сборки, для тестирования и развертывания.

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

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

В случае отделов разработки программного обеспечения важно предоставить инструменты, позволяющие автоматизировать тестирование кода, его пробную реализацию и тестирование качества кода (и воссозданных систем). Кроме того, с помощью расширенных систем управления конфигурацией, таких как Ansible или Puppet Enterprise, вы можете исключить большую часть повторяющейся работы, связанной с созданием тестовых сред, необходимой для обеспечения адекватной поддержки процессов непрерывной интеграции и непрерывной доставки.

Кроме того, использование соответствующей среды выполнения, такой как современные методы виртуализации системных ресурсов, например, «контейнеризация» или «технология виртуальных машин», позволяет полностью автоматизировать выделение ИТ-ресурсов для отдельных проектов или тестирования. среды данного ИТ-проекта. Доступные и проверенные решения — это, например, OpenShift и Docker.

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

Постоянный контроль качества

«Доверие и контроль» — это может показаться зловещим, но, конечно, в практике управления понятия доверия и контроля никоим образом не исключают друг друга. Контроль качества созданного решения (нечто большее, чем контроль качества кода) ни в коем случае не должен ассоциироваться ИТ-сотрудниками с попыткой оказания давления, иначе это будет эффективный процесс (источник: опыт автора).

Контроль качества создаваемых решений распространяется на несколько технологических областей:

функциональный анализ — соответствие программного обеспечения ожиданиям — программные артефакты, адаптация кода среды выполнения — конфигурация компонентов, настройки, ограничения и т. Д.

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

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

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

Что касается конфигурации программного обеспечения. Для среды выполнения и выполнения программного обеспечения лучшим источником знаний будет анализ системных журналов операционных систем, сред выполнения (например, JBoss или Oracle Weblogic server) и непрерывные проверки работоспособности системы путем считывания показателей использования определенных ресурсов.

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

Могут помочь такие решения, как системы управления событиями. Одним из таких решений, предлагающим огромный набор доступных функций и готовых аналитических приложений, является решение Splunk Enterprise. Благодаря богатой экосистеме готовых конфигураций (в терминологии Splunk — «приложения») система позволяет быстро получить максимум информации из существующих разнородных источников данных, необходимой для достоверной интерпретации качественных характеристик создаваемых ИТ-решений.

Резюме

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

DevOps подход не может быть реализован частично, например, путем внедрения только процесса CI/CD (непрерывная интеграция и доставка). Потому что использование отдельных элементов подхода DevOps на «неподготовленной земле» обычно вызывает больше проблем, чем пользы, и вместо DevOps мы можем выйти из этого «DevOoops». Отсутствие организационной согласованности обычно приводит к реваншу по прошествии длительного периода времени, например, замешательством, усталостью и разочарованием сотрудников (особенно узкоспециализированных).