Джин Ким - Руководство по DevOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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