Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

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

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

Коренной, хронический конфликт

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

Термин «технический долг» был впервые предложен Уордом Каннингемом. Подобно финансовому, технический долг — решения, необходимые для ликвидации проблем, с течением времени становящихся все более трудно разрешимыми при постоянном уменьшении будущих возможностей для маневра. Даже действуя благоразумно, мы все равно вынуждены выплачивать проценты.

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

• реагировать на быстро меняющийся конкурентный ландшафт;

• обеспечить стабильный, надежный и безопасный сервис для клиента.

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

Доктор Элияху Голдратт, один из создателей методологии управления производством («теории ограничений»), называл конфигурации такого типа «корневым, хроническим конфликтом». Он заключается в том, что корпоративное нормирование и стимулы в разных подразделениях препятствовали достижению глобальных целей организации[10].

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

Нисходящая спираль: драма в трех актах

У этой драмы три акта, вероятно, знакомые всем, кто имеет отношение к сфере IT.

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

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