DevOps - "это не автоматизация, так же как астрономия - это не телескопы"

В последние годы DevOps стал модным термином и множество компаний публикуют вакансии Devops-инженеров.

Если посмотреть внимательно на описание этих вакансий, видно, что под термином DevOps почти всегда подразумевается владение неким набором технологий для автоматизации внутренних процессов в IT-компании (в том числе CI/CD).

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

Получил широкое распространение термин "DevOps-инженер", как инженер, владеющий соответствующим набором технологий и инструментов для создания различных pipeline-ов автоматизации (обычно это Ansible, Python, bash, Jenkins/TeamCity, Docker, Kubernetes, облачные технологии). И, собственно, кроме этого от DevOps-инженера больше ничего и не требуется.

Мне вот лично каждый раз, когда вижу такую трактовку DevOps, хочется спросить: а что, до этого не было CI/CD? До этого не было инструментов для автоматизации процессов и людей, ими владеющих?

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

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

А что такое конкурентные преимущества? Это все то, что позволяет:

• ускорить поставку решений на рынок по сравнению с конкурентами
• сделать решение более надежным по сравнению с конкурентами
• улучшить customer experience при взаимодействии с компанией и эксплуатации решения
• удешевить решение по сравнению с конкурентами
• более точно "попасть в рынок", то есть более точно удовлетворить потребности клиентов

Любые новые методологии, новые подходы к организации процессов развиваются тогда, когда они дают эти самые конкурентные преимущества - просто потому, что такова механика рынка.

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

Можно провести аналогию с Agile.

Agile - это не SCRUM или KANBAN, это способ мышления, набор установок, mindset, который нацелен на то, чтобы максимально быстро получать от рынка обратную связь, на основе которой постоянно корректировать развитие продукта. Главные конкурентные преимущества, которые дает Agile-подход - это ускорение поставки решений (решение поставляется небольшими частями, итерационно) и более точное "попадание в рынок", за счет как раз быстрого получения обратной связи и ее учета. SCRUM, KANBAN, экстремальное программирование и прочие методологии - это всего лишь фреймворки, которые в той или иной степени реализуют этот mindset.

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

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

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

А в последнее время DevOps трактуется еще шире - совместная работа не только команд разработки и эксплуатации, но и включая остальные команды, участвующие в потоке создания ценности:

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

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

Для закрепления приведу цитату Кристофера Литла, одного из самых уважаемых авторов по идеологии DevOps: «это не автоматизация, так же как астрономия — это не телескопы». Вот, кстати, ссылка на прекрасную статью этого автора на тему, почему же нет DevOps-манифеста по аналогии с Agile-манифестом (доступна, к сожалению, в России только через VPN): https://devops.com/no-devops-manifesto/.

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

Семантически термин DevOps-инженер аналогичен термину agile-инженер. Вы когда-нибудь слышали о такой позиции, как agile-инженер? )))

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

Здесь даже нельзя привести аналогию отношения SCRUM /agile, т.к. SCRUM - это полноценный фреймворк, который предоставляет полный набор инструментов для реализации agile-подхода к разработке, а то, что обычно называют DevOps-инструментами (Kubernetes, Jenkins, Ansible и прочие) - это всего лишь инструменты, которые к DevOps имеют такое же отношение, как к Agile, к водопадной, V-образной и любой другой модели разработки ПО.

По сути, та позиция, которую сейчас называют "DevOps-инженер" - это просто инженер по автоматизации. До появления позиций DevOps-инженеров работы по автоматизации точно так же выполнялись (сисадминами, разработчиками, инженерами внедрения/эксплуатации), а сейчас тренд на то, что на это направление работ выделяются отдельные позиции. При этом зачастую получается ситуация, когда в разных подразделениях одной цепочки создания ценности имеются свои отдельные "DevOps-команды", которые, по сути, являются просто командами по автоматизации внутренних процессов данного подразделения. Это к девопсу имеет очень слабое отношение.

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

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

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

В частности:

• Совместные митинги с участием представителей всех команд, задействованных в цепочке;
• Совместные чаты;
• Участие смежных подразделений в митингах/чатах "соседних" подразделений;
• Стажировки инженеров в "соседних" подразделениях. Это очень сильная практика, она зачастую корректирует у разработчиков подход к написанию кода (учет удобства его эксплуатации, учет тестабилити);
• Организация процесса передачи знаний между подразделениями, в отличие от обычно принятого процесса вытягивания знаний;
• Прозрачность и визуализация рабочего процесса во всех подразделениях;
• Модерация всех improvement-ов до передачи их на реализацию. Смысл модерации в том, что в производство должны попадать запросы не КАК реализовать что-то, а ЧТО реализовать. Думаю все сталкиваются с тем, что из-за отсутствия такой модерации в производство приходят требования с описанием, как технически реализовать нечто, но без каких-либо объяснений, зачем это вообще потребовалось.
  В итоге часто ресурсы тратятся вхолостую. По моей практике, часто при детальном анализе выясняется, что требование либо излишнее, либо корневая причина его появления должна решаться совсем по-другому, чем описано в тикете.
  Это тоже вполне себе DevOps-подход (для этого нужно быть погруженным как в контекст работы клиента, так и в контекст производства);
• Реализация процесса Continuous Delivery Pipeline (CDP), что важно, с тестированием на каждом этапе этого Pipeline (об этом чуть подробнее ниже);
• Улучшение testability продуктов (стабильные интерфейсы для тестирования вместо проприетарных (логи, telnet));
• Мониторинг работы ПО и анализ ошибок со стороны тестирования и разработки до передачи тикетов на исправление;
• и т.д.

То есть работы по автоматизации Continuous Delivery Pipeline (CDP) и владение инструментами для этой автоматизации (то, что сейчас у нас называют DevOps-ом) - это всего лишь один из элементов этого самого DevOps. Важный, но далеко не единственный.

DevOps-подход на уровне компании - это стандартизация и повсеместное внедрение описанных выше техник.

Сейчас есть модное направление под названием SRE (Site Reliability Engineering). У многих возникает вопрос, а чем SRE отличается от DevOps-а.
SRE - это позиция на стороне разработки, которая отвечает за эксплуатацию продукта (за его отказоустойчивость и надежность).
А DevOps - это подход к организации работ в целом в компании.
Позиция SRE абсолютно органично вписывается в DevOps-подход к разработке ПО. Поэтому я бы рассматривал введение позиции SRE как одну из практик DevOps.

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

Если посмотреть на один из популярных сейчас в мире фреймворков по масштабированию Agile на уровень организации (Scaled Agile Framework), то можно увидеть, что DevOps-подходу в нем уделяется огромное внимание. Остановлюсь чуть подробнее на этом, тем более, что в компании, где я работаю, в свое время были попытки внедрить некоторые практики из этого фреймворка (оттуда у нас появились, например, такие термины, как Release Train, переключатели-рычаги, канарейки).

Сам фреймворк огромен, он описывает все сферы деятельности IT-компании, кому интересно можно ознакомиться по ссылке: https://scaledagileframework.com/

Практики, которые можно отнести к DevOps, пронизывают почти все, что нарисовано на этой картинке.

В SAFe команды каждая команда может внутри себя работать как угодно, главное - все команды должны работать в одном ритме (каденции), с общими точками синхронизации. Несколько таких каденций (это могут быть, например, спринты) объединяются в Program Increment (PI). На выходе PI - артефакт, готовый к установке в прод. В точках синхронизации проводятся System Demo (все промежуточные наработки команд вливаются на один стенд и проводится общее демо), по завершении разработки PI - финальное демо.

Эти демо - инструмент, относящийся в одинаковой степени как к Agile, так и к DevOps подходам.

Показателен этап планирования PI: представители бизнеса, команд разработки/внедрения и т.д. объединяются в одну команду и создают план реализации инкремента продукта. В планировании принимает участие вся проектная команда (аналитики, представители от разработки, тестирования, внедрения/эксплуатации). Процесс планирования обычно длится несколько дней, результат - доска Program Board, на которой указано, какая команда над какой user story в каком спринте работает, плюс визуализируются связи между историями. Эта визуализация, кстати, очень крутая штука - она позволяет на ранних этапах лучше понимать и учитывать эти зависимости.

Обратите внимание: здесь речь идет, по сути, об объединенной команде, которая участвует в планировании релиза. В чистом виде DevOps-подход.

Начинается планирование с того, что до объединенной команды доносят бизнес-контекст предстоящих доработок (руководство либо бизнес). В чистом виде DevOps-подход (помните про "размытие контекста межу подразделениями"?).

Есть общая ответственность за PI - если PI провален, то провален он для всех команд. Тоже DevOps-подход.

Почему отдельно: потому, что DevOps - это в значительной степени о качестве и стабильности продуктов. В Continuous Delivery Pipeline (который является неотъемлемой частью DevOps-подхода) обязательно встроено тестирование.

Вообще, в SAFe встроенному качеству посвящен целый раздел, и есть пять аспектов качества:

Но я здесь остановлюсь на двух моментах:

1. О стоимости тестирования в потоке

При работе в рамках потока (пайплайна), тесты должны выполняться максимально быстро, поэтому:
Во-первых, тесты должны быть автоматизированы
Во-вторых, должна создаваться сбалансированная пирамида тестирования: от большого количества быстрых и дешевых тестов уровня Story до гораздо меньшего количества крупных и дорогих end-to-end тестов:

Это важный момент, который напрямую влияет на стоимость решения. В верхней части пирамиды должны находиться только те тесты, которые невозможно реализовать в более нижних частях. В основании пирамиды - unit-тесты и автономные функциональные тесты компонент продукта, далее - интеграционные тесты внутри продукта (их требуется уже меньшее количество), А end-to-end / системные тесты, проверяющие в том числе и интеграцию между продуктами - самая небольшая по количеству часть тестов.

2. О встраивании автотестов в CDP

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

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

Это важная часть DevOps, но не более того.

Чем занимается команда:

• Разработка слоя кастомизации якорного продукта компании для основного клиента
• Разработка автотестов (python, robot framework): интеграционное тестирование внутри продукта, что важно, на окружении, приближенном к прому клиента
• Ручное комплексное тестирование новых фич перед отгрузкой (часть из них далее автоматизируется)
• Внутренняя автоматизация, нацеленная в конечном итоге на создание и поддержание CDP для продукта (jenkins pipelines, groovy, python, ansible, docker, openstack, etc)

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

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

Мы до сих пор тесно интегрированы с RnD, участвуем в планировании работ над версиями, во внутренних митингах.

Точно так же мы интегрированы и в Отдел по внедрению и эксплуатации.

Какие мы используем DevOps-практики

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

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

Мы так же участвуем во внутренних чатах (корпоративные мессенджеры, телеграм) как команд разработки, так и команды внедрения.

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

Огромное внимание уделяем качеству (напомню, это важная часть DevOps)

Ранее процесс доставки версии включал в себя два этапа тестирования (с оговорками, конечно), условно их можно назвать так:

1. тестирование внутри производства (понятно, что в производстве тестирование тоже не монолитное, но мы здесь рассматриваем процесс в целом)
2. end-to-end / системное / UAT тестирование на, условно, предпроме, этап называется Quality Gate, QG.

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

Это совершенно неэффективно, поэтому мы заполнили этот пробел - организовали отдельный этап тестирования (назвали Internal Quality Gate, InQG).

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

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

Важно: разработка и поддержка автотестов InQG значительно дешевле, чем end-to-end тестов, и этим этапом мы снизили нагрузку на разработку и поддержку той части автотестов, которые идеологически НЕ должны попадать в верхнюю часть пирамиды тестирования, но ранее попадали;

Важно: на этапе InQG используются не дорогие и дефицитные копии прома, а дешевые виртуалки из cloud. Для тестов автоматически разворачивается стенд из двух виртуалок, который можно назвать "мини-копией" прома: в нем есть необходимые нам базы, минимально необходимый набор окружения (rabbit, kafka, zookeeper, nginx, мониторинг и т.п.) и, собственно, разворачивается сам продукт. Этот стенд полностью автоматизированно разворачивается за 15-20 минут (по нажатию одной кнопки);

Очень важно: тесты InQG, в отличие от "большого" QG, прогоняются не перед отгрузкой версии, а ежедневно. Таким образом мы удешевляем поиск и исправление ошибок: гораздо проще найти ошибку не во всем скоупе работ версии, а в дневном инкременте кода;

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

Важно: по окончании прогона результат отправляется в виде отчета в специальный канал корпоративного мессенджера Mattermost, при этом организовано дежурство: каждую неделю есть Robocop - сотрудник, ответственный за анализ результатов прогонов.

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

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

Подход к разработке

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

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

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

Прозрачность работы команды

Еще один важный аспект DevOps - это прозрачность работы команд.

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

Закончить хочется той же фразой, которой начал, т.к. это реально важно: DevOps - "это не автоматизация, так же как астрономия - это не телескопы"