Книга: Руководство по DevOps

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

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

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

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

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

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

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

В результате мы оказываемся далеко от желаемых целей. Все в организации недовольны уровнем производительности IT-подразделений. Итог — бюджет урезан, все разочарованы, но понимают, что бессильны изменить ход процесса разработки и добиться заметных результатов[7]. Каким же должно быть решение? Необходимо изменить методы работы, и DevOps — это наилучший способ продвижения вперед.

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

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

Точно так же повысились требования к продуктам: то, что было хорошо в предшествующие десятилетия, перестало удовлетворять заказчиков. Следующие 40 лет стоимость и время разработки и внедрения стратегических возможностей для бизнеса снижались все активнее. В 1970–1980-х гг. разработка и внедрение большинства новых технологий требовали от одного до пяти лет и часто обходились в десятки миллионов долларов.

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

Но к 2010 г. в связи с внедрением DevOps и непрекращающейся коммодитизацией[8] компьютерного оборудования, программ, а теперь и облачных технологий новые функции (и даже целые компании-стартапы) могут создаваться за недели и быстро — за часы или даже за минуты — внедряться в производство. Для таких организаций развертывание стало рутинной операцией, практически не содержащей рисков. Появилась возможность проводить эксперименты для проверки бизнес-идей, выясняя, какие из них наиболее ценны для клиентов и самой организации и какие можно быстро превратить в «фичи», а уже их, в свою очередь, быстро и без рисков развернуть на производстве.

Таблица 1. Тенденция к более быстрой, дешевой и имеющей мало рисков поставке программного обеспечения

Источник: Презентация «Быстрота и объем (Скорость выигрывает)» Адриана Кокрофта на конференции FlowCon в Сан-Франциско, ноябрь 2013 г.

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

Сегодня независимо от того, к какой отрасли относится компания, приобретение клиентов и предоставление им создаваемой ценности зависит от технологичности канала поставки этой ценности. Джеффри Иммелт, исполнительный директор компании General Electric, выразил эту мысль сжато и точно: «Каждая отрасль промышленности и каждая компания, не желающие делать программное обеспечение центром бизнес-стратегии, не имеют будущего». Или, как сказал Джеффри Сновер, технический специалист корпорации Microsoft, «в предыдущие экономические эпохи коммерческие предприятия создавали ценности, перемещая атомы. Теперь они делают это, перемещая биты».

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

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

Оглавление книги