Читать книгу "Проект "Феникс". Роман о том, как DevOps меняет бизнес к лучшему - Джордж Спаффорд"

Поэтому когда ты носишься кругами и кричишь: «О, нет! У нас не готова среда для «Феникса»! Помогите! Помогите! О, нет! Мы не можем реализовать запуск, потому что кто-то снова сломал тестовую среду!» – пискляво произносит Эрик, – это означает, что время цикла какой-то критической операции в твоей зоне ответственности больше, чем время такта. Это причина, по которой ты не можешь выполнить требования клиентов.

Как выполнение части Второго пути ты должен создать обратную связь, охватывающую все части проектирования, создания и разработки продукции. Учитывая твои беседы с Диком, можно сказать, что ты способен вклиниться в процесс на более раннем этапе. – Указывая на этаж перед нами, Эрик говорит: – Посмотри на длинную череду оборудования между оранжевыми полосками на полу. Именно на этой линии производятся самые прибыльные единицы продукции, которые у нас есть. Но по стечению обстоятельств именно здесь происходят две самые долгие операции: нанесение цветного порошкового покрытия и термическая обработка в печи».

Скрестив руки, он смотрит вверх. «В прежние дни, когда время цикла данных операций было намного длиннее времени такта, мы никогда не могли выполнить требования заказчика. Как жизнь может быть столь несправедливой? Наиболее прибыльные единицы зависят от обоих наших ограничений: печи для термообработки и красильных камер! Что же делать?

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

То, как такую же проблему решили в Toyota, – это легенда, – продолжает Эрик. – В 1950-е годы процесс штамповки капотов занимал у них около трех дней. Для него требовалось приводить в движение огромные тяжелейшие штампы, весящие по несколько тонн. Подготовительное время операции было настолько длинным, что им приходилось увеличивать объем единовременно выпускаемой партии, что не давало им использовать одну и ту же штамповочную машину для производства нескольких моделей машин одновременно. Нельзя сделать всего одну крышку капота для Prius и затем одну для Camry, если для перенастройки оборудования требуется три дня, верно?

Что они сделали? – спрашивает он риторически. – Они подробно изучили все шаги, требующиеся для переналадки оборудования, а затем провели серию усовершенствований, которые сократили период подготовки до десяти минут. Именно тогда появился легендарный термин «быстрая переналадка» (SMED).

Мы изучили все работы Оно, Спира и Ротера. Мы знали, что должны сократить объем выпускаемых партий, но мы имели дело не с пресс-машинами. Мы имели дело с краской и сушкой. После недель обсуждений, исследований и экспериментов у нас появилась сумасшедшая идея – может быть, мы можем красить и сушить краску в одной машине.

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

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

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

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

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

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

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

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

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

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

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