От переводчика.
В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:
- что такое DevOps
- каковы его ценности
- как он внедряется
- кому он приносит пользу
Надеюсь этот текст вам понравится.
От переводчика.
1. Что такое DevOps и откуда оно взялось?
Термином «DevOps» обычно называют возникшее профессиональное движение, которое выступает за совместные рабочие отношения между разработчиками и ИТ-подразделением, в результате получая более быстрое выполнение планируемых работ (например, высокие темпы развертывания), одновременно увеличивая надежность, стабильность, устойчивость и безопасность production-среды. Почему разработчики и ИТ-подразделения (далее для краткости админы)? Потому что, как правило, поток ценностей (value stream) находится между бизнесом (где определяются требования) и заказчиком (куда поставляется результат).
Считается, что движение DevOps зародилось в 2009 году, как объединение многочисленных смежных и взаимодополняющих сообществ: Velocity Conference, на которой особенно яркими было выступление «10 Deploys A Day» John Allspaw и Paul Hammond, подход «инфраструктура как код»(Mark Burgess и Luke Kanies)," Agile infrastructure "(Andrew Shafer) и системное администрирование в Agile (Patrick DeBois), подход Lean Startup Эрика Райса с его непрерывной интеграции, а так же широкая доступность облачных и PaaS технологий.
Один из соавторов DevOps Cookbook, Джон Уиллис, написал фантастический пост об этом событии.
2. Чем DevOps отличаются от Agile?
Одним из принципов Agile является предоставление рабочего программного обеспечения меньшими и более частыми релизами, в отличие от подхода «большого взрыва», который присущ водопадной методологии. Так что Agile стремятся иметь потенциально готовый продукт в конце каждого спринта (как правило, раз в две недели).
Высокие темпы развертывания приводят к тому, что перед админами накапливается большая гора задач. Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом ».
DevOps особенно хорошо дополняет Agile, так как он расширяет и дополняет процессы непрерывной интеграции и выпуска продукта, давая уверенность в том, что код готов к выпуску и несет ценность для клиента.
DevOps позволяет сформировать гораздо более непрерывный поток работы в ИТ-подраздедение. Если код не поставляется в прод, в том виде как он был разработан (например, разработчики поставляют код каждые две недели, но развертывается он только один раз в два месяца), операции по установке будут накапливаться перед админами, клиенты не получат важный функционал для себя и сам процесс установки в таком случае приводит к хаосу и дезорганизации.
DevOps, в том числе, изменяет культуру, так же как изменяет процессы и метрике разработчиков и админов. Джон Уиллис и Дэймон Эдвардс (соавторы Cookbook DevOps) подробно написали об этом здесь.
3. Чем DevOps отличается от ITIL и ITSM?
Хотя многие люди считают, что DevOps это реакция на ITIL (IT Infrastructure Library) и ITSM (IT Service Management), у меня другая точка зрения. ITIL и ITSM по-прежнему являются лучшей кодификацией бизнес-процессов, лежащих в основе ИТ подразделения, так как на самом деле описыват многие вещи, необходимые для того, чтобы ИТ команда могда работать в формате DevOps.
Непрерывная интеграция и релизы являются результатом работы разработчиков, что в свою очередь является материалом для работы админов. Для того чтобы уложится в более быстрый ритм релизов, существующий в DevOps, многие процессы ITIL требуют автоматизации, в частности, связанные с изменением конфигурации и релизов в целом.
Цель DevOps не столько увеличение скорости выдачи нового функционала, сколько развертывания этого функционала в производстве, без хаоса и нарушения работы уже запущенного приложение, а так же быстрое обнаружение и исправление проблем, если они все же происходят. Это добавляет в ITIL такие пункты как настройка сервисов, управление инцидентами и проблемами.
4. Чем DevOps похоже на VisibleOps?
В соавторстве с Kevin Behr и George Spafford я написал „Visible Ops Handbook“ в 2004 году. Visible Ops является руководством по достижению трансформации к высокопроизводительным ИТ подразделениями по пути „от хорошего к великому“, и одним из ключевых понятий является понятие по ограничению и сокращению незапланированных работ.
DevOps в свою очередь ориентируется, в первую очередь на том, как создать быстрый и стабильный поток плановых работ по разработке и администрированию. Тем не менее, DevOps также имеет более целостный подход к систематическому искоренению незапланированной работы, обращаясь к принципам ответственного управления и сокращения технического долга.
5. Каковы принципы DevOps?
В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, мы описываем лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути». Они описывают ценности и философию, которые являются основой процессов, процедур, практик, а также обязательных шагов.
Первый Путь подчеркивает производительность всей системы в целом, в отличие от производительности отдельного звена или отдела — это может быть как большое подразделение (например, разработка или ИТ отдел) так и отдельные люди (например, разработчик, системный администратор).
В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT. Другими словами, он начинается тогда, когда определяются основные требования (например, для бизнес или ИТ), они закончены в разработке, а затем перешли в ИТ-отдел, в которых ценность сервиса затем и доставляется заказчику в виде сервиса.
Результаты следования Первому Пути на практике состоят в том, что известные баги никогда не передаются на следующий этап работ, никогда не развивается локальная оптимизация, приводящая к созданию глобальной деградации, происходит непрерывное улучшение и стремление достичь глубокого понимания системы (в соответствии с Демингом).
Второй Путь заключается в создании петли обратной связи идущей справа налево. Целью практически любой инициативы по совершенствования процесса является сокращение и усиление обратной связь, чтобы необходимые поправки могли внедряться постоянно.
Итоги Второго Пути: понимание и реакция на всех клиентов, как внутренних так и внешних, сокращение и усиление всех петель обратной связи, и углубление знаний о среде там, где это нужно.
Третий путь заключается в создании культуры, которая влияет на две вещи: постоянное экспериментирование, которое требует принятия рисков и извлечение уроков из успехов и неудач, а также понимание того, что повторения и практики являются предпосылкой к мастерству.
Нам нужны оба этих принципа в равной мере. Эксперименты и принятие рисков, является тем, что гарантирует, что мы продолжим улучшения, даже если это означает, что мы можем зайти в слишком опасные дебри. И мы должны учиться навыками, которые могут помочь нам выйти из опасной зоны, когда мы зашли слишком далеко.
Итоги Третьего Пути включают выделение времени для улучшения повседневной работы, создание ритуалов, которые поощряют команду в принятии рисков и возможному созданию неисправностей в системе с целью повышения устойчивости в перспективе.
6. Области внедрения DevOps
В книге „DevOps Cookbook“, мы выделили 4 моделей внедрения DevOps:
Модель 1: Углубление процессов разработки в поставку: это включает расширение непрерывной интеграции и выпуска в на боевые сервера, интеграция тестирования и информзащиты в рабочие процессы, что дает готовый к поставке код, настроенные среды, и так далее.
Модель 2: Создание обратной связи от прода до разработки: включает создание полной хронологии событий в разработке и администрировании, с целью помощи в разрешении проблем, а так же предоставление доступа команде разработки к анализу проблем на проде, одновременно с созданием разработчиками сервисов самообслуживания, везде где это возможно, и создание информационных радиаторов, показывающих изменение в поведении системы при вносе изменений.
Модель 3: Объединение разработки и администрирования: состоит во включении команды разработки в цепочку разрешения проблем, назначение разработчиков на разрешение проблем на проде, а так же взаимные тренинги между разработчиками и администраторами, чтобы уменьшить количество эскалаций.
Модель 4: Включение ИТ команды в разработку: состоит во включении или тесной связью между IT и разработкой, создание многоэтапных пользовательских историй (включая развертывание, управление кодом в производстве и т.д.), и определение нефункциональных требования, которые могут быть использованы во всех проектах.
7. В чем ценность DevOps?
Я полагаю, что есть три бизнес преимущества, которые организации получают от перехода на DevOps: быстрый выход на рынок (например, сокращение времени цикла и более высокие темпы развертывания), повышение качества (например, повышение доступности, меньше сбоев и т.д.), и увеличение организационной эффективности (например, больше времени тратится на деятельность связанную с увеличением ценности продукта по сравнению с потерями, увеличение количества функционала, переданного заказчику).
Быстрое время выхода на рынок
В 2007 году в IT Process Institute, мы тестировали более 1500 ИТ организаций и пришли к выводу, что высокопроизводительные ИТ организации были в среднем на 5-7x порядков более производительными, чем их невысокопроизводительные сверстники. Они делали в 14 раз больше изменений, получая проблемы только половине случаев, при этом имея скорость исправления проблем с первого раза в 4 раза выше, а также имели в 10 раз более короткие периоды простоя. У них было в 4 раза меньше результатов повторного аудита, они в 5 раз чаще находили нарушения за счет автоматизированной системы внутреннего контроля, и в 8 раз лучше укладывались в сроки проекта.
Одной из характеристик высокопроизводительных команд состоит в том, что они уходят далеко вперед от толпы. Другими словами, лучшее становится еще лучше. Это происходит в области темпов развертывания приложения. Accenture недавно провели исследование о том, что делают интернет-компании, и Amazon пошла на рекорд, заявив, что они делают более 1000 развертываний в день, поддерживая скорость успешных изменения 99,999%!
Возможность поддержания высоких темпов развертывания (например, быстрое время цикла) трансформируется в бизнес-ценность двумя основными способами: как быстро может организация перейти от идеи к чему-то, что может быть передано заказчику и сколько экспериментов организация может проводить одновременно.
Без сомнения, если я работаю в организации, где я могу сделать только одно развертывание каждые девять месяцев, и мой конкурент может сделать 10 установок в день, у меня есть значительные, структурные конкурентные недостатки.
Высокие темпы развертывания позволяют проводить эксперимент быстро и практически непрерывно. Скотт Кук, основатель Intuit, был одним из самых ярых сторонников „безудержной инновационной культуры“ на всех уровнях организации. Один из моих любимых примеров приводится ниже:
»Каждый сотрудник [должен быть в состоянии] проводить быстрые, высоко-скоростные эксперименты… Дэн Маурер руководит нашим потребительским подразделением, в том числе запуск веб-сайта TurboTax. Когда он начинал работу над этим проектом, мы сделали около семи экспериментов за год. За счет внедрения инновационной культуры, они сейчас делают 165 экспериментов в течение трех месяцев налогового сезона. Бизнес результат? Коэффициент конверсии веб-сайта составляет до 50 процентов. Результат для сотрудников? Люди просто любят его, потому что теперь их идеи могут попасть рынок ".
Для меня самой шокирующей частью истории Скотта Кука является то, что они делали все эти эксперименты в пик сезона подачи налоговых деклараций! Большинство организаций делают остановку изменений во время пикового сезона. Но если вы можете увеличить коэффициент конверсии, и, следовательно, продаж, в пик сезона, когда ваш конкурент не может, то это подлинное конкурентное преимущество.
Предпосылки для этого включают возможность находится в состоянии сделать много мелких изменений быстро, без перерыва в обслуживании клиентов.
Уменьшение количества потерь IT отдела
Mike Orzen и я как-то говорили об огромных потерях в IT стриме, вызванными длительными сроками простоя, медлительной передачей работ, незапланированными работами и переделками. Для статью Michael Krigsman мы оценили, сколько полезной деятельности мы могли бы вернуть путем применения принципов DevOps.
Мы подсчитали, что если бы мы могли просто сократить вдвое количество IT потерь, а также перераспределять эти деньни таким образом, что сможем вернуться в пять раз больше чем было вложено, мы бы производили $ 3 триллионов долларов полезной деятельности в год. Это ошеломляющее количество денег и возможностей, которым мы позволяем ускользнуть из наших рук. Это 4,7 процента от ежегодного мирового ВВП, или больше, чем весь объем производства Германии.
Я думаю, это важно, особенно когда я думаю о мире, в котором будут жить трое моих детей. Потенциальное экономическое влияния на производительность труда, уровень жизни и процветание ставит это на первое место.
Однако, существует еще другой тип потерь. Люди в большинстве ИТ-организаций часто чувствуют себя обойденными вниманием и полными разочарования. Люди чувствуют, как будто они в ловушке вечно повторяющегося фильма ужасов и беспомощны, чтобы изменить финал. Менеджмент отрекается от своей ответственности за IT, что часто приводит к бесконечным войнам между разработкой, ИТ и отделами информационной безопасности. И все становится только хуже, когда аудиторы вскрывают все это. Жизнь ИТ-специалистов часто деморализована и полна разочарований, что, как правило, приводит к чувству бессилия и наполняет стрессами, которые проникают в каждый аспект жизни.
Как люди, мы стремимся творить и ощущать, что мы является частью чего-то большого. Тем не менее, слишком часто, когда ИТ-специалисты просят у их организации поддержки, они слышат «Вы не понимаете», или еще хуже, едва прикрытое, «Вы никто».
Автор: mythmaker
