По словам Кристофера Литла, одного из первых летописцев DevOps, «каждая компания — технологическая, независимо от того, к какой области бизнеса она себя причисляет. Банк — это просто IT-организация с банковской лицензией» [В 2013 году в европейском банке HSBC трудилось больше разработчиков ПО, чем в компании Google. Прим. авт.].

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

В деловом и финансовом мире проекты важны, поскольку служат основными двигателями изменений внутри организаций. Проекты должны получить одобрение руководства, для них утверждается бюджет, за расходы нужно отчитываться, поэтому проекты — способ осуществить любые цели и ожидания организации, то есть и роста, и сокращения [Пока не будем устраивать дискуссий, как должна финансироваться разработка ПО, как «проект» или как «продукт». Это мы обсудим ниже. Прим. авт.].

Проекты обычно финансируются за счет вложения капитала (например, заводы: закупка оборудования, главные части проектов и расходы капитализируются и окупятся спустя годы). 50 % в наше время тратится на технические нужды. Это справедливо даже для вертикальных линеек так называемой низкотехнологичной промышленности, то есть тех отраслей, где исторически сложилось так, что вклады в разработку технологий невысоки (энергетика, металлургия, ресурсодобывающие отрасли, автомобилестроение и строительство). Иными словами, это отрасли, в которых руководителям требовалось опираться на эффективное управление IT-отделами ровно настолько, насколько это нужно для достижения их целей [Например, Вернон Ричардсон с коллегами опубликовал следующие поразительные результаты. Они изучили отчеты 184 публичных корпораций по форме 10-K и разделили их на три группы: а) фирмы с нехваткой материальных ресурсов и с нечеткой работой IT-подразделений; б) фирмы с нехваткой материальных ресурсов и с четкой работой IT-подразделений; в) «чистые фирмы» без нехватки материальных ресурсов. В фирмах из группы А текучка кадров среди руководителей высшего звена была в восемь раз выше, чем в фирмах из группы В, а в фирмах из группы Б — только в четыре раза. Ясно, что работа IT-структур оказывается гораздо более важной, чем принято считать. Прим. авт.].

Издержки в человеческих и экономических ресурсах

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

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

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

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

Предлагаем следующие расчеты: по оценкам компании IDC и компании Gartner, примерно 5 % общемировой суммы валового внутреннего продукта (3,1 триллиона долларов) тратятся на IT-отрасли (оборудование, услуги, телекоммуникации). Если считать, что 50 % этой суммы ушли на операционные расходы и поддержание существующих систем, а треть этих 50 % была потрачена на незапланированные работы и переделку, то впустую было потрачено примерно 520 миллиардов долларов.

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

Этическая сторона DevOps: лучший путь

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

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

Разрываем нисходящую спираль, используя DevOps

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

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

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

Всеобъемлющий сбор телеметрии о коде и программной среде обеспечивает своевременное обнаружение проблем и их быстрое исправление. Он подтверждает: все на месте, как предусмотрено, и клиенты получают продукт благодаря предоставленному нами ПО.

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

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

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

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

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

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