Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему

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

Теперь твоя очередь, – жестко произносит он, тыкая меня пальцем мне в грудь. – Ты должен выяснить, как снизить ваше время переналадки и уменьшить время цикла внедрения кода.

Думаю, твоя цель должна быть… – говорит он и на мгновенье останавливается, – десять выкаток в день. Почему нет?»

У меня отваливается челюсть. «Это невозможно».

«Серьезно? – невозмутимо спрашивает Эрик. – Позволь мне рассказать тебе одну историю. Вернемся в 2009 год, когда я был председателем правления в одной технологической компании. Тогда один из наших инженеров посетил конференцию, посвященную скорости информационных процессов, и вернулся обратно словно буйнопомешанный – полный опасных, невозможных идей. Он увидел презентацию Джона Оллспоу и его коллеги Пола Хаммонда, которая перевернула его мировоззрение. Оллспоу и Хаммонд управляли отделом IT-сопровождения и группой инженеров в компании Flickr. Вместо того чтобы конфликтовать между собой, как кошка с собакой, они рассказывали о том, как вместе работали, и обычно им удавалось реализовывать до десяти запусков в день! И это в мире, где большая часть IT-организаций внедряет по приложению в квартал или даже в год. Представь себе. Они справлялись с внедрением кодов в тысячу раз быстрее.

И позволь мне сказать тебе, – продолжает он, – мы все думали, что наш инженер съехал с катушек. Но я понял, что практики, которые используют Оллспоу и Хаммонд, являются неизбежным следствием применения Трех путей в IT-системе. Таким образом мы совершенно по-другому стали управлять IT-отделом и в итоге спасли нашу компанию».

«Как они это делали?» – спрашиваю я, ошарашенный.

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

Оллспоу научил нас, что разработчики и it-сопровождение должны сотрудничать друг с другом, а также вместе с бизнес-отделом и с группой тестировщиков.

Теперь мы знаем, что Оллспоу и Хаммонд не были безумцами. Джез Хамбл и Дэвид Фарли независимо от них пришли к тем же заключениям и описали все технологии и принципы, которые позволяют осуществлять несколько выкаток в день в книге «Непрерывное развертывание ПО». Эрик Рис затем показал нам, как данные возможности могут помочь бизнесу и привести его к победе в книге «Бизнес с нуля».

Эрик сейчас оживлен больше, чем когда-либо при нашей встрече. Качая головой, он сурово смотрит на меня.

«Твой следующий шаг сейчас уже должен быть очевиден, салага. Чтобы ты мог выполнить требования заказчиков, в том числе твоих приятелей-разработчиков, – говорит он, – ты должен создать то, что Хамбл и Фарли назвали конвейером развертывания. Это автоматизированный процесс, который включает в себя весь цикл – от тестирования кода до его выкатки. Ты должен наладить полный контроль версий. Следить за всем процессом. Не только контролировать сам код, но и все, что требуется для создания среды. Затем тебе нужно автоматизировать весь процесс создания среды. Тебе нужен четкий конвейер развертывания – создаешь ли ты тестовые или рабочие среды, запускаешь ли в них код или что еще. Именно так ты сможешь снизить время, требующееся на настройку и элиминацию ошибок. И так ты сможешь увеличить темп работы».

«Подожди-ка, – не совсем понимаю я. – Что именно мне нужно автоматизировать?»