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

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

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

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

Даже несмотря на то, что внедрение DevOps сегодня происходит все чаще как на крупных предприятиях, так и в веб–организациях, все еще существует путаница в том, что именно означает этот термин.

Слово «DevOps» было придумано в 2009 году Патриком Дебуа [Patrick Debois], который стал одним из его гуру. Термин был сформирован путем сочетания «разработки» [DEVelopment] и «операций» [OPerationS], что обеспечивает отправную точку для понимания того, что именно люди обычно имеют в виду, когда говорят «DevOps» — это связь разработчиков программного обеспечения и тех, кто тестирует или эксплуатирует то, что разработчики создают.

Примечательно, что DevOps не является ни процессом, ни технологией, ни стандартом.

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

Несмотря на мифический тон некоторых историй о его происхождении, DevOps не был создан из цельной ткани. Скорее семена DevOps были посажены давно и были взращены дальновидными ИТ–экспертами в ряде дисциплин. Два основных предшественника DevOps:

• Управление корпоративными системами (Enterprise systems management, ESM)

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

Эти эксперты по эксплуатации оборудования принесли в DevOps ключевые рекомендации ESM (например, управление конфигурациями, мониторинг систем и т.д.)

• Agile разработка

DevOps можно понимать как продукт Agile культуры — гибкая разработка программного обеспечения требует тесного сотрудничества с клиентами, менеджментом продукта, разработчиками и (иногда) QA, чтобы заполнить пробелы и быстро перейти к лучшему продукту.

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

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

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

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

Не удивительно, что ни один из вариантов не приемлем для руководителей предприятий. И, что более важно, ни один из них не позволяет бизнесу предоставлять лучшие решения для своих клиентов.

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

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

Как эти разрозненные группы интегрируются, как они объединяют свои усилия? Они подписываются на общий набор принципов, которые выходят за рамки традиционных дисциплин и ролей. Например:

• Сформулировать ожидания и приоритеты, и основные убеждения, которые их направляют.

• Сотрудничать как внутри, так и между группами по решению проблем.

• Автоматизировать общие и повторяющиеся процессы, чтобы высвободить время для работы более высокого уровня.

• Интегрировать обратную связь в работу, измеряя все, что было сделано.

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

Компании часто говорят о переходе на DevOps, найме SRE и о том, как стать более Agile, но как эти термины связаны друг с другом?

Agile и Lean — это про то, как команды делают итерации — с короткими циклами разработки и быстрой обратной связью. Agile фокусируется на культуре и не зависит от того, какие инструменты используются.

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

SRE (System Reliability Engineering) — это то, как инженерные организации автоматизируют, доверяя масштабные операции людям с мышлением в области разработки программного обеспечения. SRE начинается с инструментов и движется к культуре.

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

• Совместная работа

• Автоматизация

• Непрерывная интеграция

• Непрерывная поставка ценности

• Непрерывное тестирование

• Непрерывный мониторинг

• Быстрое восстановление

Давайте разберем каждый пункт более детально.

Совместная работа

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

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

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

Автоматизация

DevOps сильно зависит от автоматизации, а это значит, что вам нужны инструменты. Инструменты, которые вы строите. Инструменты, которые вы покупаете. Инструменты с открытым исходным кодом. И эти инструменты должны быть не просто разбросаны повсюду, а использоваться: DevOps опирается на наборы инструментов для автоматизации основных частей end-to-end разработки и поставки программного обеспечения.

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

Непрерывная интеграция (Continuous Integration)

Краеугольным камнем DevOps является непрерывная интеграция, метод, разработанный и названный Грэди Бучем [Grady Booch], который постоянно объединяет обновления исходного кода от всех разработчиков в команде в общую магистраль.

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

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

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

Практики регулярного и открытого общения расцветают в DevOps.

Непрерывное тестирование (Continuous Testing)

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

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

Непрерывное тестирование — это не просто функция QA; на самом деле все начинается в среде разработки. Прошли времена, когда разработчики могли просто перекинуть код через стену в QA и сказать: «Ловите». В среде DevOps качество — это дело каждого. Здесь ведется совместная работа, и каждый вносит свою лепту в то, чтобы все этапы разработки и поставки были реализованы максимально качественно.

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

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

Непрерывная поставка (Continuous Delivery)

Непрерывная поставка — это практика разработки программного обеспечения DevOps», когда изменения кода автоматически тестируются и готовятся к выпуску в продакшн.

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

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

Непрерывный мониторинг (Continuous Monitoring)

Несмотря на непрерывное тестирование огромное количество выпусков вследствие реализации непрерывной поставки может приводить к ошибкам. Нет никакого способа на все 100% снизить все возможные ошибки. Это значит, в среде DevOps сбои должны обнаруживаться и исправляться в режиме реального времени. Именно это и значит «непрерывный мониторинг».

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

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