ProDevOps

Статья служит цели дать понимание того, что такое  DevOps, как это культурное движение появилось и из чего оно состоит.

Начнем.

Шел 2009-й год. Постепенно осознание в необходимости избавиться от «бункеров», ставших причиной обособленности между разработчиками и админами, стало настолько очевидным и четким, что мысли переросли в нечто осязаемое, получившее в последствии название «Культурное движение DevOps».

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

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

  • Исчерпывающая инструкция по установке и настройке, что помогало только отчасти: нередко в боевой среде приложение ведет себя иначе даже с корректными настройками, а способов быстро идентифицировать проблему практически нисколько. К этому стоит добавить, что мы все равно сопровождали сам выход в прод, сидя на телеконе. Однажды даже в ночь с 31-го декабря на 1-е января.
  • Дебаг по фотографии. Если админы и разработчики не общаются, то админ часто не знает, какая информация нужна, чтобы разобраться в проблеме, а разработчик не знает, что на систему может повлиять. Выглядит это так: «Вот скриншот с ошибкой System is not available», после чего череда «Пришлите пожалуйста логи фронтенда», «Пришлите пожалуйста логи сервиса», «Пришлите, пожалуйста, SQL запрос с таким-то идентификатором», «Выполните пожалуйста следующий запрос против prod-базы», «А теперь этот», «И еще вот этот..». Это реальный, повторяющийся много раз кейс 🙂

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

Помимо культурной составляющей DevOps включает в себя ряд подходов к построению процессов и поддерживающий технологический-инструментальный ландшафт. Часть процессов не новы, но жизненно необходимы, если вы хотите приблизиться к показателям, подобным на приведенном ниже изображении.
Сссылка на отчет: https://puppet.com/resources/white-paper/2015-state-devops-report.

2015 State of DevOps Report @ High-performing IT organizations
2015 State of DevOps Report

Перечислим процессы, затем перейдем к технологиям:

  • Планирование релиза
  • Непрерывная интеграция
  • Непрерывная поставка
  • Непрерывное тестирование
  • Непрерывный мониторинг
  • Непрерывное улучшение

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

continuous deployment pipeline
Сontinuous Deployment Pipeline

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

  • Автоматизация
  • Версионный контроль
  • Непрерывная интеграция
  • Мониторинг
  • Контейнеризация
  • Безопасность
  • ….

XebiaLabs поддерживает просто отличную «Периодическую таблицу DevOps-инструментов»:

Periodic Table of DevOps Tools
Periodic Table of DevOps Tools

Автоматизация позволяет сделать процесс более быстрым, предсказуемым и повторяемым, уберечь от человеческого фактора. Что касается тестирования, то автоматизация позволяет выполнять тесты параллельно, что еще сильнее сокращает время проверки и дает возможность запускать «тяжелые» тесты в ночное время. Кроме того, это и автоматическая генерация отчетов и, при правильном приготовлении, меньшие затраты на поддержку.

Контейнеры дают вам возможность быстро и дешево поднимать и гасить неограниченное количество идентичных окружений для различных целей: UAT, тестирование производительности, тестирование безопасности, «боевое» выполнение. Это полностью избавляет от употребления фразы «У меня на машине всё работает», ведь теперь «моя машина» ничем не отличается от прода или UAT’а. Описание окружения в виде текстового файла хранится под версионным контролем, что позволяет проследить изменения окружения во времени и быть точно уверенным в том, какое ПО установлено на сервере.

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

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

Wastes

Кто-то частично узнает свой текущий проект, кто-то полностью 🙁

Теперь представьте, что вы выпустили новую крутую фичу. Потом вторую, третью. И вдруг ваш сайт поймал хабраэффект, или перед новым годом пришло в 1000 раз больше посетителей, чем ваши сервисы могут обслужить. Среди вариантов могут быть:

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

Подводя итог, культура DevOps — это:

  • Совместное и динамичное движение в сторону единых целей, целей бизнеса
  • Существенное сокращение времени вывода новых версий продукта с одновременным повышением качества
  • Снижение стоимости реализации фич
  • Предсказуемость и снижение риска поставок
  • Сокращение времени реакции на изменения на рынке
  • Открытость и способность к инновациям

И напоследок, пример того, как процесс поставки может выглядеть, если вы избавитесь от ручной работы и совместными усилиями выстроите эффективный Deployment Pipeline. Процесс поставки может и должен занимать минуты, максимум — часы.

Screen Shot 2016-07-19 at 03.07.37

Пролезные ссылки

Patrick Debois
Etsy
RackSpace
UrbanCode
http://devops.com
ITRevolution
State of DevOps Report 2015
Тренинг компании ScrumTrek «Основы DevOps»

Share

Leave a Reply