ЧТО ТАКОЕ ДЕВОПС
1) НЕБОЛЬШИЕ КОМАНДЫ Т-ОБРАЗНЫХ ЛЮДЕЙ
DevOps практикуется в небольших командах, скажем, от пяти до девяти человек. Небольшие команды могут общаться между собой лицом к лицу, что позволяет избежать накладных расходов на передачу и доработку документов. Каждая команда является кросс-функциональной, обладающей навыками разработки программного обеспечения, тестирования, создания инфраструктуры, эксплуатации и безопасности.
Эти функции не обязательно должны быть представлены разными людьми. На самом деле, организации DevOps предпочитают людей, которых они называют Т-образными: сотрудников, обладающих широким набором навыков, но углубленных в одну область. Это универсалы, имеющие специализацию; например, конкретный член команды может уметь разрабатывать программное обеспечение и создавать инфраструктуру, но особенно хорош в оптимизации производительности. Команды с Т-образными сотрудниками очень подвижны, поскольку они могут передавать работу туда-сюда по мере необходимости и при этом использовать глубокие знания, когда это необходимо.
2) АВТОМАТИЗАЦИЯ
Команды DevOps в значительной степени полагаются на автоматизацию. Они автоматизируют тестирование, а также настройку инфраструктуры в облаке. Они автоматизируют контроль за безопасностью и соблюдением нормативных требований. Они автоматизируют процесс слияния кода от разработчиков и разрешения конфликтов.
3) ЧАСТОЕ РАЗВЕРТЫВАНИЕ
Самое примечательное в DevOps – это его акцент на частом развертывании кода для пользователей. Это движение вошло в сознание ИТ-сообщества в 2009 году, когда Flickr, сайт обмена фотографиями, объявил, что он регулярно выполняет десять развертываний каждый день. По сегодняшним меркам это ничто – Amazon.com, вероятно, является текущим лидером с более чем пятьюдесятью миллионами развертываний в год. На самом деле, то, как часто им удается внедрять ценные изменения или новые возможности, стало предметом гордости специалистов по DevOps.
4) БЕРЕЖЛИВОСТЬ
С точки зрения Lean, DevOps является … ну, очень бережливым. Нет необходимости передавать работу внешним группам, поскольку межфункциональная команда обладает всеми необходимыми навыками для выполнения своей работы. Функции завершены и сразу же развернуты, так что работы в процессе мало. Автоматизация сокращает объем работы, которую команда должна проделать для создания каждой функции. Меньше дефектов и меньше переделок, потому что автоматизированные тесты быстро находят проблемы.
5) СНИЖАЕТ РИСК
Может показаться рискованным или хаотичным так часто внедрять изменения для пользователей, но на самом деле все наоборот. В прошлом ИТ-команды проводили крупные, нечастые развертывания, которые неизменно приводили к хаосу для остальной части бизнеса и для них самих. Но в DevOps каждое развертывание является небольшим и, следовательно, маловероятно, что оно будет неудачным; если же это произойдет, проблема может быть быстро найдена. Кроме того, сам процесс развертывания хорошо протестирован, поскольку используется так часто.
НАСТРОЕН НА ЦИФРОВУЮ ЭПОХУ
DevOps, как вы могли заметить, настроен на скорость цифровой эпохи – быстрый процесс для быстрого времени.
В книге Accelerate доктор Николь Форсгрен, Джез Хамбл и Джин Ким пишут:
Наш анализ высоких, средних и низких показателей дает доказательства того, что между повышением производительности и достижением более высоких уровней темпа и стабильности не существует компромиссов: они движутся параллельно. Именно это и предсказывают движения Agile и Lean, но многие догмы в нашей отрасли все еще основываются на ложной предпосылке, что движение быстрее означает компромисс с другими целями производительности, а не их стимулирование и укрепление.
СТАТИСТИЧЕСКИ ПОДТВЕРЖДЕННЫЕ РЕЗУЛЬТАТЫ
В исследовании DORA использовался кластерный анализ для разделения компаний на когорты в зависимости от их ИТ-показателей. Для измерения этого показателя они использовали конструкцию, которую назвали SDO (производительность доставки и эксплуатации программного обеспечения), объединяющую измерения, представляющие пропускную способность, стабильность и доступность системы. В качестве косвенных показателей пропускной способности они использовали частоту развертывания ИТ-функций и время, которое проходит с момента завершения разработчиком кодирования ИТ-функции до момента ее развертывания. Для представления стабильности они измеряли частоту отказов изменений и среднее время устранения проблем (MTTR). На основе SDO они смогли разделить компании на четыре группы: с низким, средним, высоким и элитным уровнем производительности.
Сравнивая элитных исполнителей (которые наиболее широко используют передовые методы DevOps) с низкими исполнителями, они обнаружили, что первые могут развертывать функции в 46 раз чаще, демонстрируют в 2 555 раз более быстрое время от момента завершения кода до его развертывания, в 2 604 раза быстрее восстанавливаются после простоя и лишь на одну седьмую меньше подвержены риску отказа изменений.
СНИЖЕНИЕ РИСКОВ И ЗАТРАТ
Неудивительно, что практика DevOps коррелирует с хорошими бизнес-результатами. Во-первых, эти практики снижают многие виды риска. Риск безопасности снижается как за счет частого тестирования, так и за счет быстрого реагирования на уязвимости при их обнаружении. В то время как водопадный проект рискует практически всем своим бюджетом, не предоставляя результатов до конца, типичный Agile-проект рискует только стоимостью строящегося инкремента. А DevOps, с его быстрыми и частыми поставками, рискует только крошечными приращениями между развертываниями.
Практика DevOps также снижает затраты. Быстро развертывая минимальный продукт, а затем постепенно дополняя его, ваша организация может перестать тратить усилия на ненужные функции или функции, которые на самом деле не нужны клиентам. Затраты также снижаются по мере того, как компания находит способы сделать процесс доставки более экономичным. Поскольку DevOps снижает количество дефектов, он также снижает количество незапланированных работ. И, наконец, похоже, что он позволяет масштабировать размер организаций, занимающихся поставками, без уменьшения отдачи.
ОБЕСПЕЧИВАЕТ ГИБКОСТЬ БИЗНЕСА
Вы можете контролировать инициативу DevOps посредством постоянного участия и обратной связи, а не путем простого утверждения плана в начале работы. Вместо того чтобы проверять проект через периодические обзоры состояния, вы сможете видеть и использовать выполненную работу на протяжении всего проекта – это гораздо лучший способ оценить прогресс. Вы можете постоянно корректировать приоритеты и перераспределять ресурсы, а также оценивать качество работы, видя бизнес-результаты, а не через несколько недель приемочного тестирования в последний момент.
Короче говоря, вы обмениваете мнимый контроль на фактический. Это означает, что ваши ожидания от технологов должны быть выше (и эти ожидания будут удовлетворены, потому что технологам приятно, что их оценивают именно так). Вы должны ожидать, что технологи будут быстро и часто заканчивать работу и предоставлять результаты. Они будут высокого качества. Что технологи будут работать над сокращением сроков выполнения работ, тем самым более чутко реагируя на потребности бизнеса и сокращая потери в процессах. И что они привнесут свою креативность и страсть в решение бизнес-проблем, а не будут ждать, пока требования перебросят им через стену.
УСПЕХ СТАРТАПА ДЛЯ ПРЕДПРИЯТИЯ
В своей книге “Бережливый стартап” Эрик Рис раскрывает некоторые бизнес-последствия способности поставлять продукты упорядоченным, бережливым способом, показывая, как успешные стартапы используют итерационный подход к определению себя. Стартап начинается с идеи и видения продукта, который, по его мнению, будет привлекательным для клиентов. По словам Риса, у компании есть гипотеза ценности о том, какие атрибуты продукта будут ценны для покупателей, и гипотеза роста о том, как эта потребительская ценность будет трансформироваться в растущие доходы компании. Затем она проверяет эти гипотезы с помощью экспериментов на рынке. На основе полученных данных стартап может продолжить работу с двумя гипотезами в их нынешнем виде или “перевернуть” – отказаться от них и сформулировать новые гипотезы. Именно так, по мнению Риса, стартапы добиваются успеха.
Рис кратко описывает процесс бережливого стартапа следующим образом:
Определите убеждения о том, что должно быть правдой, чтобы стартап преуспел. Мы называем эти предположения “прыжком веры”. Создайте эксперимент, чтобы проверить эти предположения как можно быстрее и дешевле. Мы называем эту начальную попытку минимальным жизнеспособным продуктом. Думайте как ученый. Рассматривайте каждый эксперимент как возможность узнать, что работает, а что нет. Мы называем это “единицей прогресса” для стартапов – подтвержденное обучение. Извлеките уроки из каждого эксперимента и начните цикл заново. Этот цикл итераций называется циклом обратной связи “построить – измерить – научиться”. Регулярно принимайте решение о смене стратегии (повороте) или о сохранении курса (упорстве).
МИНИМАЛЬНЫЙ ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ
Итак, цель стартапа – добиться подтвержденного обучения путем экспериментов, максимизировать обучение при минимизации инвестиций. Для этого создается серия минимальных жизнеспособных продуктов, или MVP, – самых маленьких и дешевых версий продукта, которые помогут компании учиться и корректировать курс. MVP могут быть удивительно простыми: возможно, сначала это экранные макеты, которые можно показать пользователям, чтобы получить их отзывы. За этим могут последовать консьерж-продукты – то есть услуги, в которых есть “человек за занавесом”, похожий на волшебника из страны Оз, выполняющий функцию, которая впоследствии будет автоматизирована.
Подход Lean startup также используется предприятиями, разрабатывающими новые цифровые продукты, ориентированные на клиента, или ИТ-системы для использования внутри предприятия. Вместо того чтобы строить на основе требований, команда Agile должна работать на основе гипотез: “Мы считаем, что если мы создадим эту конкретную функцию, то получим этот конкретный бизнес-результат”. Затем они могут проверить свои гипотезы, создав MVP. Тестирование идей приводит к лучшим результатам, чем спрашивать пользователей, что им нужно. Как говорит Рис:
Причина проведения экспериментов – выявление предпочтений клиентов через их поведение. Другими словами, не спрашивайте клиентов, чего они хотят. Разрабатывайте эксперименты, которые позволят вам наблюдать за ними. . . . [Минимально жизнеспособные продукты] – это реальные продукты, независимо от того, насколько они ограничены, которые создают максимальную возможность для нас быть удивленными поведением клиентов.
НОВАЯ МОДЕЛЬ ДЛЯ УСПЕХА БИЗНЕСА
Если соединить все эти части вместе – DevOps, Agile, Lean Startup – мы увидим совершенно другую модель того, как компании используют ИТ. Вместо того чтобы писать документ с требованиями, основываясь на том, что, по их мнению, будет хорошей инвестицией, они начинают с бизнес-цели, генерируют идеи о том, как ее достичь, и проводят небольшие тесты, чтобы увидеть, способствуют ли эти идеи достижению целей… или, если нет, как их можно улучшить. Небольшие тесты возможны потому, что ИТ-команда использует практику DevOps, которая позволяет быстро получить функции в руки пользователей и оценить их эффективность.
ИТ-отдел должен быть согласован с бизнесом. Но именно здесь предприятие может захотеть согласовать свои действия с ИТ. Чтобы получить бизнес-преимущества от практик DevOps и Agile, оно должно упорядочить все свои организационные процессы, частью которых является работа ИТ. Надзор за инвестициями, политика закупок, формулирование требований и управление рисками – это те области, где компании могут значительно сократить потери и время выполнения работ и при этом реально улучшить контроль. Пока они этого не сделают, они будут жертвовать скоростью и быстрой обратной связью, которые приносит DevOps.
Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.