Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях
Шрифт:
Второй акт начинается, когда кто-то должен компенсировать невыполненные обязательства – это может быть менеджер продукта, обещающий реализовать более впечатляющие возможности, чтобы восхитить заказчиков, или директор, предлагающий более агрессивные цели по доходности. Затем, забыв о реальных возможностях технологии или о том, из-за каких обстоятельств не были выполнены предыдущие обязательства, руководство заставляет технические отделы любой ценой реализовать эти новые обещания.
В результате перед разработчиками ставится задача срочно создать проект, что неизбежно требует решения новых технических проблем и «удаления всего лишнего», чтобы успеть реализовать задачу в срок. Так увеличиваются обязательства по техническому долгу, а параллельно звучат привычные обещания исправить все проблемы, как только появится немного свободного
Такое решение подготавливает сцену для третьего и последнего акта пьесы, когда все необходимые действия становятся более и более трудными: каждый исполнитель все глубже увязает в выполнении задания, коммуникации между сотрудниками и отделами становятся медленными, а очередь из заданий на выполнение понемногу растет. Работа затягивается узлом, небольшие действия вызывают большие сбои, все начинают проявлять опасение и нетерпимость к изменениям. Нужно больше обсуждений, координации и одобрения различными инстанциями. Группы сотрудников чаще вынуждены ждать, когда будет выполнена задача, задерживающая их собственные действия, а качество при этом только ухудшается. Дело движется все медленнее, и, чтобы увеличить скорость, приходится прилагать больше усилий (см. приложение 3 ).
В настоящем разглядеть нисходящую спираль сложно, но ретроспективно она видна отчетливо. Мы начинаем замечать, что развертывание готового кода занимает все больше времени: вместо минут – часы, дни и даже недели. Но хуже всего то, что результаты развертывания оставляют желать лучшего, а это ведет к возрастанию времени простоев у клиентов, что, в свою очередь, требует от отдела IT-эксплуатации героических усилий по «тушению пожаров», отнимающих у него возможность выплатить технический долг.
В результате циклы поставки продукта затягиваются все сильнее, новых начинаний все меньше, а проекты, которые все-таки появляются, оказываются менее амбициозными. Кроме того, обратная связь, доносящая результаты от каждого – особенно поступающая от клиентов, – ослабевает и становится более медленной. Несмотря на все усилия, ситуация только ухудшается: мы уже не в состоянии быстро реагировать на изменяющуюся ситуацию на рынке, предоставляя стабильный и надежный сервис клиентам. В результате мы теряем свою долю рынка.
Снова и снова повторяется одно и то же: если терпит неудачу подразделение IT, то провал ждет всю организацию. Как пишет в своей книге The High-Velocity Edge Стивен Спир, неважно, наступают ли печальные последствия «медленно, как постепенно развивающаяся болезнь», или происходят быстро, «как пожар дома… разрушение в обоих случаях полное».
Более десяти лет авторы этой книги наблюдали нисходящую спираль в огромном количестве организаций всех типов и размеров. И в конце концов поняли, из-за чего она появляется и почему для ее устранения необходимо использование принципов DevOps. Во-первых, как уже говорилось, каждая IT-компания имеет две противоположные цели, а во-вторых, любая такая организация – технологическая, понимает она это или нет.
По словам Кристофера Литла, одного из первых летописцев DevOps, «каждая компания – технологическая, независимо от того, к какой области бизнеса она себя причисляет. Банк – это просто IT-организация с банковской лицензией» [11] .
Чтобы убедиться в верности этих слов, примите во внимание, что большинство крупных проектов связаны со сферой IT. Как говорится, почти невозможно принять какое-либо бизнес-решение, не вызывающее хотя бы одного изменения в работе IT-подразделений.
11
В 2013 году в европейском банке HSBC трудилось больше разработчиков ПО, чем в компании Google. Прим. авт.
В деловом и финансовом мире проекты важны, поскольку служат основными двигателями изменений внутри организаций. Проекты должны получить одобрение руководства, для них утверждается бюджет, за расходы нужно отчитываться, поэтому проекты – способ осуществить любые цели и ожидания организации, то есть и роста, и сокращения [12] .
Проекты
12
Пока не будем устраивать дискуссий, как должна финансироваться разработка ПО, как «проект» или как «продукт». Это мы обсудим ниже. Прим. авт.
13
Например, Вернон Ричардсон с коллегами опубликовал следующие поразительные результаты. Они изучили отчеты 184 публичных корпораций по форме 10-K и разделили их на три группы: а) фирмы с нехваткой материальных ресурсов и с нечеткой работой IT-подразделений; б) фирмы с нехваткой материальных ресурсов и с четкой работой IT-подразделений; в) «чистые фирмы» без нехватки материальных ресурсов. В фирмах из группы А текучка кадров среди руководителей высшего звена была в восемь раз выше, чем в фирмах из группы В, а в фирмах из группы Б – только в четыре раза. Ясно, что работа IT-структур оказывается гораздо более важной, чем принято считать. Прим. авт.
Когда сотрудники, особенно занимающие невысокую должность в отделе разработки, несколько лет находятся в ловушке нисходящей спирали, они зачастую чувствуют себя заложниками системы, запрограммированной на неудачи, и понимают, что не в силах достичь заметных результатов. Ощущение бессилия нередко сменяется эмоциональным выгоранием, ощущением покорности судьбе, цинизмом и даже безнадежностью и отчаянием.
Психологи утверждают: создание системы, порождающей чувство бессилия, – одна из основных опасностей, которым мы подвергаем своих близких. Мы лишаем других возможности управлять собственными достижениями, создавая культурную среду, где подчиненные опасаются поступать правильно из-за страха наказания, неудачи или риска потерять средства к существованию. В результате формируются условия для появления приобретенной беспомощности: инженеры теряют желание или способность поступать так, чтобы избежать подобных проблем в будущем.
Для сотрудников это означает сверхурочные, работу по выходным и ухудшение качества жизни, причем не только их самих, но и всех тех, кто от них зависит, в том числе членов семьи и друзей. Неудивительно, что, когда складывается подобная ситуация, мы теряем лучших (исключая тех, кто обладает гипертрофированным чувством ответственности или связан какими-то обязательствами).
Помимо описанных неудобств, существующие способы действия провоцируют также финансовые потери, а ведь их можно было избежать. Можно оценить такие издержки в 2,6 триллиона долларов в год. На момент написания книги – сумма, равная валовому внутреннему продукту Франции (как считается, шестой экономики в мире).
Предлагаем следующие расчеты: по оценкам компании IDC и компании Gartner, примерно 5 % общемировой суммы валового внутреннего продукта (3,1 триллиона долларов) тратятся на IT-отрасли (оборудование, услуги, телекоммуникации). Если считать, что 50 % этой суммы ушли на операционные расходы и поддержание существующих систем, а треть этих 50 % была потрачена на незапланированные работы и переделку, то впустую было потрачено примерно 520 миллиардов долларов.
Если применение методов DevOps поможет уменьшить потери за счет лучшего управления и повышения качества результата и увеличить потенциал сотрудников в пять раз (и это по самым скромным подсчетам), то можно получить дополнительно 2,6 триллиона долларов в год.