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

Конечно, теория не всегда реализуется на практике. Мы говорили с людьми, которые помогли развернуть DevOps в реальном мире, чтобы узнать темную сторону философии - как присущие ей проблемы, так и пути, которые ведут разработчиков в сторону провала. Мы надеемся, что эти предостерегающие рассказы помогут вам посмотреть реальности в глаза.

DevOps - это не просто набор инструментов

Эрнест Мюллер, на сайте Agile Admin, определяет то, что он описывает как «инструменты DevOps»:

Инструменты, которые вы использовали бы при совершении этих принципов. В мире DevOps появился взрыв инструментов (jenkins, travis, teamcity), управление конфигурацией (puppet, chef, ansible, cfengine), оркестровка (zookeeper, noah, mesos), мониторинг, виртуализация и контейнеризация (AWS, OpenStack , vagrant, docker) и многие другие. Хотя, как и в случае с Agile, некорректно сказать, что инструментом является «инструмент DevOps» в том смысле, что он волшебным образом принесет вам DevOps, есть определенные инструменты, разрабатываемые с четкой целью облегчения вышеуказанных принципов, методов и практик, и целостное понимание DevOps должно включать этот слой.

К сожалению, рассмотрение этих инструментов или других в качестве тотема, который «волшебным образом принесет вам DevOps», - это то, что делает множество магазинов, не прилагая усилий для изменения процессов или менталитетов. «Майк», который работал в офисе технического директора средней технической компании во время его попытки перехода на DevOps, описывает такое вид «культового» видения DevOps. «Я буду обвинять в этом инженерную узость взглядов, - говорит он, - потому что разработчики программного обеспечения рассматривают лишь проблемы с программными решениями. Мы рассматривали DevOps как набор технологий, которые будут установлены во многих приложениях. Это настолько неправильно, что трудно понять, с чего начать. Мы купили копии проекта Phoenix для всех, кто этого хотел. У нас были обеденные семинары на Ruby and Chef. Мы запустили hackathons и фактически заняли высшие чины в инфраструктурных проектах».

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

Не все будут на борту

И это подводит нас к нашей следующей темной стороне DevOps. Мечта заключается в том, что ваш технический персонал с готовностью получит на борту новую философию и способ делать то, что влечет за собой DevOps. Реальность заключается в том, что изменения сложны, и многие люди не видят ничего плохого в работе, которую они уже выполняют, и в том, как они это делают. Коди Сванн (Cody Swann) является генеральным директором Gunner Technology, фирмы по разработке программного обеспечения, которая помогает частным и государственным организациям переходить на DevOps - и он видел все это: когда дело доходит до сопротивления, а некоторые сотрудники принимают активные меры, чтобы сделать переход настолько сложным, насколько это возможно. Например, в одном задании сотрудники задавали вопрос о жизнеспособности новой инфраструктуры, которую они предлагали. «Команда Ops попыталась доказать, что микросервисы - это причуда, - сказал он, - и не являются устойчивыми для крупных проектов, потому что их слишком сложно поддерживать и что JavaScript не может масштабироваться».

Процессы не всегда улучшались, когда они переходили к реализации. «Мы разбили огромное монолитное приложение .NET / инфраструктуру в микропроцессоры JavaScript на базе AWS Lambda», - говорит он. «Частично это включало перенос данных из Oracle в решение DynamoDB/Elasticsearch». Уловка?«Команда on-premise ops заняла позицию о том, что невозможно было предоставить нам доступ к базе данных Oracle для переноса данных. Разумные оправдания были очевидными: к примеру, они утверждали, что база данных была доступна только для внутренних IP-адресов. В конце концов мы настроили VPN-пиринговое соединение из AWS, чтобы перенести данные, но было получено много сопротивления при переносе данных».

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

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

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

Безопасность, как обычно, является проблемой

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

«Благодаря непрерывной интеграции и непрерывному развертыванию / доставке (CI / CD) в качестве основного драйвера в DevOps большая часть хороших методов безопасности часто автоматизируется или вообще исключается из процесса просто из-за воздействия, которое оно оказывает на скорость релиза программного обеспечения», объясняет Дэви Хуа, глава DevOps для ShiftLeft. «В результате увеличение скорости выпуска часто приводит к получению неправильно проверенного кода, что может привести к непреднамеренной чувствительной утечке данных для протоколирования конечных точек или наложению уязвимостей из сторонних программных библиотек, как это было в случае нарушения Equifax».

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

Игорь Лившиц, директор по управлению продуктами в GuardiCore, видит, что безопасность становится особой проблемой в DevOps, когда она «интегрирована в разные точки шлюза процесса DevOps вместо того, чтобы быть побочным продуктом после развертывания».

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

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

Двигайтесь быстро, но не слишком

Весь смысл перехода на DevOps заключается в том, что вы в конечном итоге получаете полезные обновления программного обеспечения гораздо быстрее. Но слишком часто команды думают, что их переход к DevOps сам по себе должен идти так же быстро - с катастрофическими результатами, особенно если культурные перемены рабочей силы не дают возможности идти в темпе. Результатом может стать некий магазин “Франкенштейн”, с половиной DevOps. Эд Прайс, директор по соблюдению в Devbridge Group, приводит пример некоторых предупреждающих знаков: «Если компании все еще видят ручную миграцию кода и вводят код вручную, если они все еще полагаются на команду среды. Если они не видят автоматическую единицу, регрессии или тестирования производительности, встроенных в их CI-конвейер, чтобы не допустить выхода кода на рынок, значит они еще не готовы».

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

Стройте для роста

Если есть один урок, который нужно извлечь из всего этого, это то, что люди наиболее важны для определения того, идет ли ваш проект DevOps к темной стороне или к свету. «Привлечение людей, которые имеют « установившееся» мышление, вместо понимания того, что означает создание DevOps с нуля», - говорит Райан Дугид, главный евангелист из Nintex. «Когда это случается, работа команды сводится к чрезмерному проектированию, чрезмерным расходам или слишком большой изощренностью, с которой сложно справиться. У вас должны быть люди, которые могут прийти и сказать «Хорошо, что здесь нужно»? вместо «Это то, что я сделал на своей последней работе». Если вы являетесь стабильной компанией, имеет смысл нанимать стабильных людей. Но если вы начинаете путешествие к DevOps, вам нужен талант, который понимает, как создать DevOps с нуля и знает, как вернуться к основам. " Урок для новичков DevOps: убедитесь, что вы строите правильную культуру с нуля и научитесь ходить, прежде чем пытаться летать.

No Comments