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