Проекты обычно финансируются за счет вложения капитала (например, заводы: закупка оборудования, главные части проектов и расходы капитализируются и окупятся спустя годы). 50 % в наше время тратится на технические нужды. Это справедливо даже для вертикальных линеек так называемой низкотехнологичной промышленности, то есть тех отраслей, где исторически сложилось так, что вклады в разработку технологий невысоки (энергетика, металлургия, ресурсодобывающие отрасли, автомобилестроение и строительство). Иными словами, это отрасли, в которых руководителям требовалось опираться на эффективное управление IT-отделами ровно настолько, насколько это нужно для достижения их целей[13].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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