Загадка DevOps

Составной термин DevOps всего за несколько лет своего существования обогнал многие, казалось бы, куда более известные неологизмы, например BYOD, что не может не вызвать удивления, ведь это термин из довольно узкой области, ограниченной разработкой и эксплуатацией корпоративных приложений. Кроме того, он имеет скромную родословную и вышел не из Стэнфорда или Беркли — его в 2009 году предложил бельгийский разработчик-фрилансер Патрик Дюбуа для отражения идеи прямой интеграции разработки приложений (Development) с исполнением или операциями (Operation). Но еще больше удивляет тот факт, что при огромном потоке сведений нет ни малейшего согласия в том, что по существу следует понимать под DevOps?

В море сведений, так или иначе связанных с DevOps, обнаруживается множество различных определений и трактовок, как правило содержащих общие размышления о предмете без объяснения причинно-следственной связи (например, в силу каких причин возникает DevOps) или какой-либо детализации [1]. Так, аналитики Gartner считают, что «DevOps — это движение, возникшее из необходимости повысить скорость доставки ИТ-сервисов и в больших компаниях упростить отношения между разработчиками и сотрудниками ИТ-подразделений». Предпосылки к DevOps аналитики обнаруживают в манифесте Agile Manifesto, подчеркивающем значимость взаимодействия всех сторон, участвующих в процессе создания и использования приложений. К тому же считается, что реализация DevOps позволяет эффективнее использовать технологии, сделать инфраструктуру более динамичной и программируемой. А Wikipedia, не мудрствуя лукаво, трактует это слово-гибрид просто как еще один метод разработки ПО. Бывает, что DevOps называют «смесью программистов-разработчиков с персоналом ИТ» или используют образ «моста через зазор между разработчиками и ИТ» [2]. Кроме этого, говорят об интеграции разработчиков и сисадминов, о выработке новой культуры с целью выстраивания единых процессов. В итоге оказывается, что огромное внимание приковано к чему-то, не имеющему четкого определения.

О необходимости объединения программистов и эксплуатационного персонала говорят еще и в контексте цифрового предприятия — например, президент Google Эрик Шмидт, известный своими пророческими высказываниями, заявил: «Предприятия, не имеющие собственных специалистов по программному обеспечению, обречены на отставание». Здесь нет про DevOps, но идейное сходство налицо.

Скорее всего, DevOps следует рассматривать как общую тенденцию к неизбежной автоматизации управления информационными системами, на пути реализации которой, однако, имеется несколько препятствий. Одно из них состоит в том, что процесс автоматизации инспирировали программисты, на своем языке формулирующие понимание проблемы, что привело к отсутствию четкого деления на объект автоматизации с его свойствами и автоматизирующую этот объект систему. Во всех технических приложениях такое деление обязательно, и, соответственно, есть деление на специалистов по объекту и на автоматизаторов, то есть речь идет о двух совершенно разных областях деятельности. Как следствие, можно выделить три категории ИТ-систем: системы, производящие информационные услуги (Information-as-Product, IoP), системы участия(Systems of Engagement, SoE) и системы записей (Systems of Record, SoR), которые заметно различаются как объекты автоматизации.

DevOps и системное администрирование

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

Сегодня в больших компаниях управлением информационной системы занимаются администраторы веб-сервера, администраторы баз данных, администраторы сети, системные инженеры, администраторы безопасности сети и администраторы почтовых серверов. Администраторы — специалисты высокой квалификации, имеющие достаточный образовательный ценз и опыт работы, однако они часто заняты рутинной работой, не создают ничего нового и остаются придатками существующих информационных систем. О будущем разделении труда между программистами и администраторами еще в 1947 году писал Алан Тьюринг: «Можно предположить, что по отношению к автоматической счетной машине люди разделятся на специалистов высокой квалификации — мастеров и на обслуживающий персонал — слуг. Мастера будут планировать управляющие таблицы и анализировать методы использования машины, а слугам останется переносить таблицы на карты и вводить их в машину, но со временем счетная машина возьмет на себя функции тех и других». Пророчество Тьюринга во многом оправдалось, за прошедшее с тех пор время история разработчиков (Dev) и операторов (Ops) успела совершить несколько витков развития. На первых порах, еще до появления мэйнфреймов, разделения между разработчиками и операторами не было — тогда были программисты и инженеры, сохранявшие работоспособность крайне ненадежных систем. Мэйнфреймы с их пакетным режимом разделили программистов и операторов — первые отдавали колоды перфокарт со своими программами, а операторы запускали их на счет и возвращали листинги. Возврат на исходную позицию (объединение программиста и оператора в одном лице) случился в семидесятые годы с появлением мини-ЭВМ и диалогового режима — посредники-операторы здесь не требовались, и исчез барьер между разработчиком и компьютером. Но с появлением персональных компьютеров и локальных сетей, клиент-серверных архитектур и баз данных инфраструктура заметно усложнилась и снова возникло деление на Dev и Ops. В последующем появились крупные ЦОД и самостоятельные ИТ-подразделения, целиком состоящие из Ops, — снова возник барьер между двумя сторонами.

К сегодняшнему дню сложилось строгое разделение труда между Dev и Ops. Задачи первых свелись к созданию нового ПО и его периодическим обновлениям, а вторых — к обеспечению пользователям надежного и быстрого доступа к системным ресурсам. Но при том что и Dev, и Ops делают общее дело, их интересы совпадают лишь частично. Естественно, что программисты не хотят делать ПО с ошибками, а люди из ИТ — обрушивать его в процессе эксплуатации, в этом они едины, и пока требования к скорости появления новых релизов ПО были относительно невелики, между ними не было серьезных противоречий.

Если бы потребности пользователей ограничивались только готовым покупным тиражируемым ПО, то разделение, предсказанное Тьюрингом, сохранилось бы еще надолго, но возникли два новых явления: непрерывное обновление ПО (Continuous Delivery, CD) и непрерывная интеграция (Continuous Integration, CI). Потребность в них вызвана тем, что в современных системах запросы пользователей изменяются буквально ежедневно и возникает разрыв с возможностями системы. На одной чаше весов оказываются затраты на поставки кода с новой функциональностью, а на другой — недополученная прибыль из-за задержек с появлением нужной пользователю функции, поздней обратной связи, необходимости поддержки непроверенных решений и прочих факторов. Непрерывную интеграцию как прием программной инженерии используют в проектах с участием большого числа разработчиков, что позволяет снизить трудоемкость интеграции и сделать ее более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

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

Причины появления DevOps

Первая и самая очевидная причина — возрастающее значение концепции PaaS. Непосредственное использование публичных PaaS избавляет разработчиков от необходимости в услугах ИТ, появилось даже выражение «теневые ИТ» — технологии, неизвестные ИТ-подразделениям. Здесь возможен разрыв связей между Dev и Ops, и тогда возникает явление NoOps. Чтобы избавиться от угроз, связанных с теневыми ресурсами, предлагаются технологии частных инфраструктурных сервисов (Private Paas), где отношения между Dev и Ops подняты на новый уровень.

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

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

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

Системы записей и системы соучастия

Системы записей (SoR) — наследники первых бухгалтерских и амбарных книг — хранят все сведения о бизнесе в виде записей, и обработка данных для них есть не что иное как различного рода операции над записями, отсюда и пошло слово «транзакция». Самостоятельную роль «систем записей» выделил и предложил название в 2008 году отец хранилищ данных Билл Инмон в статье «The creeping system of record», где он отмечал, что управление записями как системой фиксации знаний предложили много лет назад банкиры, которых интересовал лишь один параметр — сумма на счету клиента. Но понятие SoR можно рассматривать шире — как основу современной модели ИТ. Типичный представитель SoR — это система ERP, которая поддерживает все стороны бизнеса (финансы, производство, CRM, HR и др.).

Как бы ни были многочисленны и совершенны современные системы SoR, они могут реализовать потенциал ИТ лишь частично — недоиспользованными остаются коммуникационные способности и возможность работы с контентом. SoR повторяют традиционные системы управления, они служат для совершенствования и автоматизации ранее принятых и получивших распространение методов управления. Примером самого неполноценного использования компьютеров являются системы документооборота, в которых лишь зафиксирован канцелярский подход к документам многовековой давности и вообще не предполагается какой-либо работы с контентом. В полной мере преимущества компьютеров могут раскрыться только сегодня в условиях BYOE (Bring Your Own Everything), облаков, технологий Больших Данных и всего остального, составляющего кооперативные ИТ (Cooperative IT, CoIT). В CoIT материализуются такие новые подходы, как частичная передача функций управления ИТ бизнесу, использование работниками предпочтительных для них устройств и приложений и динамическое изменение инфраструктуры.

Термин «система вовлечения или участия» (Systems of Engagement, SoE) предложил Джефри Мур, директор консалтинговой компании TCG и автор книги о приложении дарвиновской теории к эволюции компаний, для обозначения нового поколения информационных систем. На рис. 1 показано качественное отличие систем XXI века, а в таблице собраны отличительные черты SoR и SoE.

Рис. 1. Предприятия XXI века и кооперативные ИТ

Таблица. Сравнение SoR и SoE

Качественная новизна SoE состоит в том, что такие системы являются платформой для перехода к предприятию нового типа Enterprise 2.0, и их задача заключается в обеспечении коллегиальной работы, поэтому они снабжаются средствами поддержки онлайн-сообществ, краудсорсинга, социальных CRM, открытыми интерфейсами и т. п. Переход от SoR к SoE имеет много общего с тем, что происходило в прошлом в других областях, когда на первых порах новые технологии применяются к старым формам и только по прошествии времени возникает качественно новая форма — например, автомобили были похожи на кареты, а пароходы — на парусники. Со времен мэйнфеймов компьютеры лишь улучшали многовековую систему записей, и только в условиях SoE от них можно получить полную отдачу.

DevOps как технология

Системы класса «информация как продукт» (Information-as-Product, IoP) создаются с чистого листа, поэтому их можно изначально делать как программно-конфигурируемую среду (Software-Defined Environment, SDE), объединяющую вычислительные, сетевые и ресурсы хранения, адаптируемую к требуемым видам работ. Проповедники DevOps интерпретируют SDE как «программируемую инфраструктуру» (Infrastructure as Code). Очевидно, что такая инфраструктура прекрасно адаптирована к автоматизации, в ней для этого есть все исполнительные органы и нужно только научиться подавать на них необходимые управляющие воздействия. Теоретически возможны два подхода к автоматизации.

• На уровне приложений и связующего ПО (application или middleware-centric tools). Возможности таких средств ограничены управлением кодами серверов приложений и самими приложениями, они не связаны с операционными системами, с виртуализированными или физическими узлами. Простота управления приложениями, работающими на серверах, является их главным достоинством.
• На уровне универсальных многофункциональных средств (generic tools). Такие средства имеют доступ ко всем составляющим информационных систем, от конфигурирования ОС до защитных экранов, но они сложнее и дороже. Такие средства позволяют описывать желаемое состояние инфраструктуры с использованием того или иного предметно-ориентированного языка (Domain Specific Language, DSL). В результате удается автоматизировать всю систему на протяжении ее жизненного цикла.

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

Говорить о рынке технологий для DevOps пока сложно — имеется несколько небольших стартапов, работающих в сегменте управления конфигурациями (Configuration Management, CM) и включающих в свои продукты элементы DevOps. Среди них лидирует компания Puppet Labs, выпустившая в 2011 году коммерческую версию Puppet Enterprise своего продукта с открытым кодом, относящегося к классу CM. Puppet служит для автоматизации ИТ с помощью декларативного языка Ruby DSL и обеспечивает управление операционными системами и приложениями, включая развертывание и обновление как в облаках, так и в локальных ЦОД. Компания Chef (в прошлом Opscode) выпускает одноименный продукт, позволяющий автоматизировать процесс развертывания серверов и приложений. Норвежскую компанию CFEngine справедливо назвать ветераном — она занимается автоматизацией ИТ на академическом уровне с 1993 года, а ее первые коммерческие продукты появились в 2009 году. Эта компания занимается телеметрией ИТ, обеспечивая сбор и аналитику по устройствам, процессам и данным. Только компания MaestroDev декларирует свою привязанность непосредственно к DevOps — ее продукт Maestro назван DevOps Orchestration и поддерживает процесс разработки в стиле Agile и DevOps.

DevOps как культура

SoE нельзя рассматривать как альтернативу SoR — поскольку традиция ведения записей существует уже много столетий, то, скорее всего, системам этого типа ничто не угрожает и в корпорациях они будут сосуществовать с SoE. Однако ИТ-системы приобретают в результате большую динамику, и если прежде обновления были вызваны новыми релизами ПО, то теперь усовершенствование становится перманентным, разработка и тестирование органично сочетаются на протяжении всего жизненного цикла решения (рис. 2). Ведущую роль в этом процессе играет DevOps, и если представить жизненный цикл так, как изображено на рис. 3, то это будет сдвиг влево, что открывает большие возможности разработчикам и специалистам по контролю качества (Quality Assurance, QA) при анализе поведения систем до их внедрения. В таких условиях новое приложение еще на уровне макета должно погружаться в среду, близкую к реальной, что, во-первых, повышает качество тестирования и, во-вторых, позволяет заранее оценить сложности на этапе внедрения. Этот принцип важен не только для разработчиков, но и для операционного персонала, который будет пользоваться приложением, — открывается возможность для более ранней оценки свойств приложения и доведения его до нужного качества совместно с разработчиками. Таким образом, реализуются непрерывное обновление программного обеспечения (CD) и непрерывная интеграция (CI). При объединении SoR и SoE в больших корпоративных ИТ-системах решающую роль начинают играть уже не технологии, а изменения производственной культуры, происходящие под влиянием ПО (software-driven innovation).

Рис. 2. Жизненный цикл DevOps

Рис. 3. Сдвиг влево в операционной архитектуре

***

Наиболее общее определение DevOps включает в себя четыре качества — культура, автоматизация, измерение и обмен знаниями (CAMS — Culture, Automation, Measurement, Sharing). Вполне правомерно трактовать его с прагматической программистской позиции, но можно взглянуть шире и увидеть в феномене DevOps отражение серьезных изменений, происходящих в корпоративных информационных системах. Проблема в том, что до сих пор такие системы создавались исходя из интуитивных представлений и накопленного опыта и не было специальной науки, чего-то вроде аналога кибернетики, поэтому проектирование и разработка оказались не готовы к новым условиям, сопровождаемым ростом сложности и переходом от SoR к SoE. Не исключено, что массовый интерес к DevOps сможет изменить создавшееся положение.

Литература

1. Наталья Дубова. DevOps: новый подход к интеграции // Открытые системы.СУБД. — 2013. — № 05. — С. 20–23. URL: http://www.osp.ru/os/2013/05/13035991 (дата обращения: 18.04.2014).
2. Дмитрий Андреев. DevOps на практике // Открытые системы.СУБД. — 2013. — № 05. — С. 30–31. URL: http://www.osp.ru/os/2013/05/13035994 (дата обращения: 18.04.2014).

Леонид Черняк (osmag@osp.ru) — научный редактор, «Открытые системы.СУБД» (Москва).