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

Миф 5: DevOps означает отсутствие необходимости управления IT-эксплуатацией, то есть NoOps (дословно – «нет эксплуатации»). Многие неправильно трактуют DevOps как полное исключение необходимости IT-эксплуатации. Однако такое утверждение редко бывает справедливо. Хотя характер оперирования может измениться, само управление остается важным как никогда. Просто оно на гораздо более ранних этапах жизненного цикла ПО взаимодействует с разработкой, продолжающей действовать параллельно с IT-эксплуатацией еще долго после того, как разработанный код развернут в производственной среде.

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

Миф 6: DevOps – это просто реализация подхода «инфраструктура как код». Хотя многие из практик и подходов DevOps, приведенных в этой книге, требуют автоматизации, для реализации DevOps также необходимо изменение архитектуры системы и культуры производства, дающее возможность достичь общих целей в ходе работы по повышению создаваемой ценности IT. Это выходит далеко за рамки простой автоматизации. Как написал Кристофер Литл, один из самых первых летописцев DevOps, «это не автоматизация, так же как астрономия – это не телескопы».

Миф 7: DevOps применим только к программам с открытым исходным кодом. Хотя многие случаи успешного внедрения DevOps действительно имели место в организациях, использовавших ПО, входившее в группу LAMP (Linux, Apache, MySQL, PHP), имелись истории успеха, и не зависевшие от использованных технологий. Например, в приложениях, написанных на Microsoft.NET, коболе, языке ассемблера мейнфреймов, а также в системах SAP и даже в коде встроенных систем (например, микропрограммное обеспечение принтеров HP LaserJet).

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

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

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

Вот, например, конструирование современного автомобиля. Где кончается область компетентности инженера-механика и начинается зона ответственности инженера-электрика? Где (и как, и когда) специалист по аэродинамике (безусловно, имеющий четкое представление о форме, размере и местах размещения окон) должен взаимодействовать с экспертом в области эргономики пассажиров? Что можно сказать о химическом влиянии топливной смеси и масел на материалы, из которых изготовлены двигатель и трансмиссия, в течение всего времени эксплуатации машины? Во время конструирования автомобиля можно задать много других вопросов, но конечный результат одинаков: для успеха современных технических проектов абсолютно необходимы две вещи – умение рассмотреть проблему с разных точек зрения и опыт совместной деятельности.

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

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

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

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

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

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