Дилемма DevOps

Введение

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

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

Перемены такого масштаба не даются многим легко – и это особенно верно, когда они преподносятся чуть ли не как символ веры или наказ свыше, без какого-либо честного объяснения реальных преимуществ и недостатков (как это было раньше . был представлен многим ИТ-специалистам). Вот почему открытое обсуждение планируемого перехода на agile/DevOps-систему до того, как это произойдет, так важно для принятия и окончательного успеха (или провала) усилий.

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

Agile для всех?

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

• Концепция
• Посвящение
• Анализ
• Дизайн
• Строительство
• Тестирование
• Реализация
• Обслуживание

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

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

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

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

По крайней мере, так это работать, но об этом позже.

Какое место в этом занимает DevOps?

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

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

Преимущества гибкой команды DevOps

Новая модель предлагает некоторые очевидные улучшения по сравнению со старым «водопадом» и разрозненным подходом. Большинство крупных технологических компаний приняли его в той или иной степени. Это очевидно в таких корпоративных решениях, как объявленное Microsoft намерение сделать Windows 10 последней четко определенной «версией» своей операционной системы с новыми функциями и функциями (а в некоторых случаях и с прекращением поддержки старых). посредством небольших, добавочных обновлений, а не крупных выпусков ОС, которые проводят четкую границу между одной версией и другой.

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

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

Что возможно могло пойти не так?

Когда хорошая ловкость становится плохой

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

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

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

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

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

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

Сделайте «Agile» более гибким

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

Проще говоря, для некоторых компаний, которые сталкиваются с проблемами при попытке внедрить гибкие принципы, решение состоит в том, чтобы сделать это более гибким способом.