Войти в систему
Войти с помощью соц. сетей:
Двигайся быстро и сокрушай.
Двигайся быстро со стабильной инфраструктурой.
Знаменитый слоган Марка Цукерберга «Двигайся быстро и сокрушай» был блестящим, но в конечном счете неискренним. Поэтому неудивительно, что в конце концов он сменил его в 2014 г. на гораздо менее запоминающийся «Двигайся быстро со стабильной инфраструктурой». Эта глава повествует о противоречиях между этими двумя утверждениями.
В большинстве компаний руководители хотят, чтобы их команды внедряли инновации, чтобы продукты отгружались вчера и чтобы их команды мыслили нестандартно. Прекрасно! Отлично! Инновации — всюду!
Но они также хотят безошибочной рабочей среды. Если есть ошибки, сбои или недочеты в системе безопасности, проводятся разбирательства, чтобы выяснить, кто виноват. Если СМИ или клиенты негативно реагируют на новый продукт, его, скорее всего, законсервируют, а у команды разработчиков будут неприятности карьерного плана.
Эти две идеи прямо противоположны друг другу. Руководители утверждают, что хотят инноваций, но затем неосознанно наказывают за их естественные последствия. А поскольку люди хорошо умеют избегать неприятностей, стремление уйти от наказания довольно быстро побеждает установку на инновации. В результате мы получаем медленно двигающуюся организацию, где не хотят идти на риск и нести ответственность.
В этом и заключается гениальность оригинального девиза Цукерберга: «Двигайся быстро и сокрушай». Он признает, что быстрое движение связано с издержками — результаты не будут идеальными, — и он согласен с этим. Если вы что-то разрушаете, он готов прикрывать вас до тех пор, пока вы выходите за рамки привычного, изобретая что-то для клиентов. Он гарантирует установку на инновационность.
Но вот в чем беда: на самом деле Цукерберг не был искренним. Если вы разработчик, который ломает машину, приносящую миллиарды долларов, никто в действительности не будет вас поздравлять. Но, к счастью, компромисс между скоростью и качеством — это ложная дилемма, и определение альтернативы таким образом неразумно, что, очевидно, понял позже Цукерберг.
В Facebook, как и во многих других компаниях, принято тратить на инфраструктуру и платформы более 30%, а иногда и более 50% от общего бюджета развития. Учитывая, что клиенты на самом деле не видят результата этих дорогостоящих инвестиций, руководители часто ставят их под сомнение. Эта глава посвящена пониманию важности ваших платформенных команд и тому, как они превращают другие команды в лучшие и более эффективные. В компании Facebook все началось с парня по имени Чак Росси.
Чак пришел в Facebook в 2008 г. в качестве первого «релиз-инженера». Его работа состояла в управлении внедрением ПО в производственную среду и заботе о том, чтобы ничего из внедряемого не обрушило сайт. Он управлял очень жестким процессом, который включал еженедельные обновления с крупными изменениями, причем в течение рабочего дня, когда инженеры могли прийти на помощь при возникновении проблем, а также ежедневные обновления для устранения мелких проблем. На нем лежал учет того, какие разработчики пишут беспроблемный код, и ведение репутационного рейтинга разработчиков в компании. Обрушивший Facebook получал предупреждение. Три предупреждения — и вам на какое-то время запрещали поставлять код. (Заметьте, не навсегда — ошибки допускались, предполагая, что вы учитесь на них, хотя и ходите в штрафниках.) Выступая в роли сторожевой собаки, Росси внедрял лучшие практики тестирования, проверки кода и многое другое.
Короче говоря, Росси убедился, если предоставлять платформы и процессы, помогающие разработчикам создавать продукт быстрее, и внедрять барьеры, гарантирующие защиту клиентов и компании от действительно плохих результатов, то даже при высоком темпе работы мало что ломается. Оказывается, отличная инфраструктура — это основа инноваций.
Такой подход не так уж сильно отличается от того, что делают эффективные компании с высоким уровнем инноваций, которые дают сотрудникам свободу для творчества, сохраняя определенную преемственность.
Если вы нанимаете команду специалистов по продажам, то, надо думать, обеспечиваете ее работоспособность. У вас есть группа, которая готовит материалы для обучения торговых представителей работе с вашими продуктами, что делает их более продуктивными. Вы покупаете ПО для автоматизации продаж, помогающее им отслеживать торговые сделки и статус заказов.
Точно так же вы создаете условия для работы финансовой команды. У вас есть ERP-система, которая помогает вести учет, отслеживать расходы и информировать инвесторов о вашем финансовом положении. Трудно представить себе, что продажи, финансы или другие функции существуют и могут успешно работать без этой важнейшей инфраструктуры.
Команды разработчиков ничем не отличаются от других команд. Чтобы сделать их успешными, необходимо вкладывать деньги в инфраструктуру. Делать это заранее необязательно. Как правило, эти системы эволюционируют естественным образом по мере того, как команда становится больше и сложнее, но при этом вы должны активно поддерживать их. Существуют способы создания инфраструктуры, которые позволяют разработчикам чувствовать себя услышанными и помогают им поверить, что компания заботится о них как о творческих профессионалах.
Нередко крупные софтверные компании направляют более 50% средств, выделяемых на исследования и разработки, на развитие инфраструктуры. Однако всегда есть соблазн поставить эти инвестиции под вопрос. Вы видите крупные расходы на инфраструктурные команды в каждом бюджетном цикле, и их необходимость начинает вызывать вопросы. Зачем мы нанимаем инженеров для поддержания внутренней инфраструктуры вместо того, чтобы увеличить штат команд, создающих продукты для клиентов? Да затем, что софтверная инфраструктура делает всех других разработчиков более продуктивными и успешными. Откажитесь от этого, и вы быстро поймете, какой выигрыш дают инфраструктурные команды. Большинство компаний обнаруживают, что рост производительности оказывается намного больше, чем 20–30%-ные инвестиции в инфраструктуру.
Вы никогда не задумывались, почему инженеры стекаются в такие компании, как Google? Конечно, платят там хорошо. Но инфраструктура поддержки у них мирового уровня. Одно дело — баловать разработчиков бесплатным обедом и трехколесными велосипедами, однако Google балует их также отличной инфраструктурой, позволяющей создавать продукт. Когда рабочие инструменты направляют почти всю вашу энергию на выполнение поставленной задачи — обслуживание клиентов и творчество, это чудесно. Верно и обратное: когда приходится бороться с рабочими инструментами, это наносит удар по моральному духу.
Я знаю это по собственному опыту. Можно подумать, что понимание этой истины пришло к нам естественным образом, поскольку компания Twilio была основана тремя разработчиками. Но на заре существования нашей компании был момент, когда мы недостаточно инвестировали в софтверную инфраструктуру, и это едва не прикончило нас.
В 2013 г. Twilio находилась на этапе быстрого роста. Годовой доход компании вырос с $1 млн в 2010 г. до более чем $30 млн в 2012 г. Мы осуществили четыре раунда венчурного финансирования на общую сумму $103 млн, а наш штат увеличился с трех основателей до 100 с лишним человек, более половины из которых были разработчиками, создающими наши продукты.
Но у нас была проблема. Наша «система сборки» — софтверная инфраструктура, которую полсотни разработчиков использовали для отправки своего кода в наше хранилище данных, тестирования, подготовки к развертыванию и собственно развертывания на основных рабочих серверах, — устарела. Я создал эту систему в 2008 г., когда мы основали компанию, и она не была рассчитана на поддержку 50 инженеров, которые весь день отправляли код, а затем развертывали его на сотнях серверов. Когда система создавалась, я мог зафиксировать свой код и запустить его на сервере за пять минут. К 2013 г. из-за роста кодовой базы и сложности тестов и сборок этот процесс иногда занимал 12 часов! Кроме того, текущую сборку обычно не удается запустить сразу — в худшем случае она не работает до 50% времени, и разработчику приходится начинать все сначала. Мы регулярно теряли дни на доведение кода до ума. Это никак не вязалось с быстрым движением.
Само написание кода не было трудным. Трудной была борьба разработчиков с нашими устаревшими системами. В результате лучшие инженеры начали увольняться, разочарованные невозможностью нормально работать. Сперва их было немного, но не успели мы опомниться, как уволилась почти половина наших инженеров. Половина! Это была абсолютная катастрофа, и она едва не погубила компанию.
Поэтому мы приступили к срочной и болезненной перестройке наших платформ разработчиков, чтобы поддержать рост компании. Первое, что мы сделали, это пригласили парня по имени Джейсон Худак, который должен был возглавить платформенную команду. Джейсон более 10 лет работал над созданием инфраструктуры для поддержки тысяч инженеров в компании Yahoo. Джейсон совсем не тот человек, которого вы себе представляете, когда думаете о программисте. Он — краснолицый техасец и бывший морской пехотинец, который окончил Техасский технологический университет, где изучал бизнес, а не информатику. Он в какой-то мере самоучка, научившийся писать код после поступления на работу в технологическую компанию в 1990-х гг. Джейсон в свободное время занимается подводным плаванием, ездой на велосипеде и охотой на диких кабанов в Техасе. Он также отличный художник-абстракционист. У меня в кабинете висят две его картины. Джейсон ходит на работу в футболке, шлепанцах и бейсболке. Но за его непринужденностью скрываются целеустремленность и дисциплина, которым он научился еще в учебном центре морской пехоты.
Сочетание этих качеств имело решающее значение, когда мы начали использовать методологию под названием DevOps (интеграция разработки и эксплуатации ПО) при создании нашей платформы для разработчиков. Возможно, вы слышали об этой методологии, даже если не работаете в технологической индустрии.
Циник может сказать, что методология DevOps стала своего рода «хитом сезона» в разработке ПО, точно так же, как и аджайл с бережливым стартапом ранее. На сайте Amazon выставлено более тысячи книг на тему DevOps. На изучение всего опубликованного о DevOps могут потребоваться годы, но для наших целей я дам предельно упрощенное объяснение этой методологии, которое выглядит следующим образом:
— Организации, занимающиеся разработкой ПО, выделили в процессе создания кода ряд рабочих ролей. Такие задачи, как кодирование, построение, тестирование, упаковка, выпуск, конфигурирование и отслеживание, выполняются разными специалистами. Разработчики пишут код и передают его инженерам по качеству, которые ищут ошибки. Инженеры по выпуску готовят код к выпуску. Как только пользователи начинают использовать программу, инженеры по надежности сайтов поддерживают ее работу. Инженеры по надежности сайтов «живут с пейджером» — они должны быть готовы ответить на вызов даже ночью или в выходные дни. Предполагается, что они бросят все и исправят код в случае падения программы.
Разделение работы на специализированные роли давало определенные преимущества, однако замедляло процесс разработки. Разработчики передавали код инженерам по качеству, которые интенсивно работали с ним и отправляли назад для исправления. Так происходило многократно. Затем код отправлялся инженерам по выпуску, которые могут отправить его обратно, а затем инженерам по надежности сайта, которые также могут завернуть его. (Вы, наверное, уже поняли, что я не любитель подобной организации работы.) На каждом этапе могут возникать задержки, поскольку разработчик ждет, пока инженер по качеству или инженер по выпуску закончит другие проекты, а затем займется его продуктом. Умножьте эти потенциальные задержки на количество итераций, и вы увидите, что процесс может вообще остановиться.
Методология DevOps, впервые предложенная около десяти лет назад, представляет собой попытку ускорить процесс, поручив выполнение всех этапов одному разработчику. Концепция отражена в самом названии: вместо того, чтобы иметь «разработчиков», пишущих код, и «операторов», делающих все остальное, вы объединяете все обязанности в одном лице. В среде DevOps один и тот же разработчик пишет код, тестирует его, упаковывает, контролирует и отвечает за него после коммерческого запуска продукта.
Это последнее предложение представляет один из самых важных элементов современной разработки программного обеспечения и то, что мы в Twilio считаем почти священным: человек, который пишет код, также «живет с пейджером» после его коммерческого запуска.
Это твой код. Если он дает сбой, ты его исправляешь. Нам нравится этот подход, поскольку он подталкивает разработчиков к созданию более качественного кода. Страх перед ночными телефонными звонками служит дополнительным стимулом лишний раз проверить работу продукта перед отправкой.
Это не значит, что мы позволяем командам отправлять код, который постоянно рушится, даже если они просыпаются, чтобы исправить его. Клиенты пострадают в любом случае. Поэтому Джейсон и его команда создали контрольный список лучших практик, который называется «Модель операционной зрелости». В нем шесть категорий совершенства: документация, безопасность, поддержка, отказоустойчивость, тестируемость и конфиденциальность. Идея вот в чем: чтобы команды считали свой продукт общедоступным, т.е. готовым для представления клиентам, они должны демонстрировать превосходный результат в каждой категории. Достижение идеального результата по всем направлениям — наивысший уровень достижений. Мы называем этот уровень «Железный человек».
В традиционной модели разработчики реализуют лишь некоторые из этих практик. Они могут писать кое-какие тесты, но не полные сквозные тесты. Возможно, они документируют свой код, но не выполняют функции команды поддержки. Возможно, у них есть хорошие методы обеспечения безопасности, но не практики конфиденциальности. Нельзя сказать, что им все равно — просто они не слишком хорошо понимают, как выглядит совершенство. Лучший способ добиться успеха в подобной работе заключается, естественно, в автоматизации. Вместе с тем, если каждой команде придется стать экспертом и самостоятельно автоматизировать процесс в каждой из категорий, это займет целую вечность. Вот тут-то и появляется команда Джейсона.
Джейсон определяет свою работу и работу платформенной группы, состоящей примерно из сотни инженеров и 13 небольших команд, как «предоставление ПО, которое позволит традиционному разработчику успешно использовать методологию DevOps, не имея серьезного опыта во всех этих специальных дисциплинах». Они не разрабатывают ПО, поставляемое клиентам. Они создают ПО, которое разработчики используют для написания, тестирования, развертывания и мониторинга собственных программ. Если что-то в нашем рабочем процессе напоминает сборочную линию, то это, вероятно, самый близкий аналог. Платформенные инженеры — это специалисты, которые проектируют и оптимизируют «сборочную линию», ускоряющую инновации.
Мы хотели, чтобы разработчикам было проще писать код, который достигает операционной зрелости с минимальными затратами труда. Наше решение состояло в создании платформы, имеющей все необходимые функции. Джейсон сравнивает ее с большим витражным окном — одной панелью со множеством элементов. Разработчики могут получить доступ ко всем необходимым инструментам через это окно. У них высокие стандарты. «Инженеры-разработчики — самая циничная, критически настроенная и придирчивая публика на земле, — говорит Джейсон. — У меня есть право утверждать это, поскольку я — один из них. Они интеллектуально честны, но вы получаете от них самые жесткие отзывы. Причина, по которой я создаю платформы, заключается в том, что тот, кто может создавать ПО, делающее других инженеров-разработчиков счастливыми, способен создавать программы для чего угодно».
Когда Джейсон Худак пришел в Twilio, он составил список принципов и ценностей, чтобы показать всем, как он строит платформу и управляет ей. Ему пришлось искать баланс между предоставлением разработчикам свободы и автономии и принуждением их придерживаться набора стандартных процедур. Стандарты помогают нам обеспечить связанность почти во всех частях кодовой базы (как я уже говорил в главе 6, правильно разработанные ограничения могут освобождать людей). Но нам не нужна жесткость, которая подавляет инновации. Мы стараемся поддерживать этот баланс должным образом.
Вот его принципы.
Проторенный путь
Платформа Admiral включает в себя все необходимые разработчику инструменты. Но разработчики не обязаны их использовать. Если вам нравится конкретный инструмент тестирования, но его нет в платформе, вы можете пользоваться им. Джейсон называет это «бездорожьем» по сравнению с «проторенным путем», имея в виду, что у тех, кто использует инструменты, выбранные нами, жизнь будет легкой, как езда по проторенной дороге. Тем не менее вы вольны ездить по бездорожью. Вы все равно доберетесь в пункт назначения, но это может занять больше времени. Одно из любимых выражений Джейсона: «У нас нет правил — у нас есть ограничения». Но тем, кто едет по бездорожью, все равно нужна безопасность и устойчивость, а с этой точки зрения проторенный путь лучше.
Выберите свой язык
Другой пример: мы не заставляем разработчиков использовать только один язык программирования. Мы поддерживаем четыре языка — Python, Java, Scala и Go. Разработчик может использовать любой из них и при этом получать полностью поддерживаемую платформу. Но, как и в случае с инструментами, разработчики имеют право выбирать и другие языки. Вопрос опять о том, где ехать — по проторенной дороге или по бездорожью. «Если вы хотите писать что-то на языке C или на другом языке, это ваше право — мы здесь не для того, чтобы говорить, что можно, а что нельзя делать, — объясняет Джейсон. — Просто знайте, что вам придется попотеть больше, поскольку вы не сможете использовать инструменты платформы разработчика».
Самообслуживание
Цель состоит в том, чтобы предоставить разработчикам меню и позволить им выбирать тот инструмент, который они хотят и когда они хотят, без необходимости обращаться к какому-нибудь «диспетчеру». Им также не нужно знать, как работают все эти процессы. Они просто выбирают то, что хотят. Это сродни набору номера на торговом автомате и получению диетической колы. Вам все равно, как это делает машина. «Разработчики просто говорят нам, что им нужно сделать, и мы не хотим, чтобы они тревожились о том, как это делается. Просто скажи нам, чего ты хочешь, и мы позаботимся об этом».
Выбор в пользу сложности
Платформа Admiral настроена так, что каждый инструмент работает определенным образом — Джейсон называет это «оптимальным рабочим процессом», подразумевая под этим, что платформенные инженеры знают, как лучше всего использовать данный инструмент. Но, опять же, разработчики не обязаны следовать этим правилам. «Мы позволяем разработчикам настраивать ПО для выполнения более сложных действий или даже использовать его для выполнения функций, которые не предусматривались. Наш принцип: “Общее должно быть легким, а сложное — возможным”».
Сочувствуйте, но жестко расставляйте приоритеты
«Нам не нравится говорить “нет”, — утверждает Джейсон. — Но если у одной команды есть запрос на нечто, что было бы круто сделать, а у другой команды есть проект, который принесет компании $90 млн постоянного дохода, мы сначала решим второй вопрос, а первый внесем как запрос в наш бэклог».
Многокомпонентное, а не монолитное
Наше ПО построено на архитектуре, состоящей из сотен микросервисов. Каждый микросервис предоставляет одну функцию или возможность. Преимущество микросервисов в том, что мы можем обойти или выдержать сбой. Например, отказ одного микросервиса не выведет из строя всю голосовую систему Twilio. Все микросервисы связаны слабо. Они построены разными командами, которые могут работать независимо. Один микросервис может быть первой или второй версией, а другой — пятой. Но пока они все «разговаривают» с соединяющим их API, все нормально.
В фильме «Ford против Ferrari», рассказывающем о попытке компании Ford выиграть гонку 24 Hours of Le Mans, есть замечательная сцена, где Ford наконец-то побеждает, выставив потрясающий гоночный автомобиль GT40. «Это чертовски хорошая машина», — говорит пилот Кен Майлз конструктору Кэрроллу Шелби. Но потом, вместо того чтобы купаться в лучах славы, Майлз и Шелби сразу же начинают размышлять о том, как сделать GT40 еще быстрее.
Таков дух и софтверной индустрии. Каждый чувствует неослабевающее стремление двигаться быстрее, делать больше за меньшее время и меньшими силами — и все для того, чтобы не отстать. «Выживают только параноики» — такой была мантра генерального директора компании Intel Энди Гроува. Мы все в какой-то мере параноики.
В Twilio мы потратили не один год на создание «машины», которая производит наше ПО, т.е. платформы Admiral. Мы экономим немного времени здесь, немного там, стараясь удержаться впереди. Я, не залезая в дебри, хочу рассказать, как работает этот процесс, поскольку он очень важен для любой современной софтверной организации. Хорошая платформа радикально сокращает время, необходимое разработчикам для коммерческого запуска нового кода, позволяя меньшему числу разработчиков создавать больше за меньшее время.
Платформа Admiral основана на концепции «конвейера» — процесса, который начинается, когда разработчик берет на себя создание нового кода. Каждая команда имеет возможность настраивать конвейер на основе не только уникальных свойств продукта, но и своего стиля работы, обеспечивая таким образом автономию. Но есть несколько стандартных, предварительно настроенных конвейеров, с которых команды могут начать свою работу. Они представляют собой самые «проторенные пути» для стандартных рабочих процессов, таких как создание сайтов, микросервисов или кластеров баз данных. Типичный конвейер начинается с запуска модульных тестов — самого простого вида тестов, которые создают разработчики. Затем конвейер запускает более сложные тесты, например интеграционные тесты, позволяющие проверить, как программа взаимодействует с другими сервисами, от которых она зависит. Далее код проходит через тест, в котором имитируются реальные сценарии выхода компьютеров из строя, например перебои в работе компьютерной сети или сбои жесткого диска. Затем идут нагрузочные тесты для выяснения, что происходит, когда объем запросов резко возрастает, а также тестирование на долговечность, имитирующее устойчивые высокие нагрузки, ради обнаружения утечек памяти или иных проблем, возникающих после длительного периода перегрузок. Пройдя все эти тесты, код переходит в «подготовительную» среду для другого набора тестов — это полная копия нашей реальной рабочей среды, но используемая только для внутреннего тестирования. Наконец, если все идет хорошо, код перемещается в «производственный» кластер — в системы, которыми пользуются клиенты. Однако коммерческий запуск не происходит мгновенно. Как правило, код поэтапно вводится через «испытательное развертывание» (оно же «канареечное развертывание») — вспомните канарейку в угольной шахте. Небольшая доля запросов отправляется в новое ПО, и, если не возникает никаких проблем, эта доля медленно увеличивается с течением времени, пока новый код не начнет обрабатывать 100% производственных запросов. Если в какой-то момент обнаруживаются проблемы, старый код возвращается обратно, а инженеры получают уведомление о необходимости разобраться с возникшей проблемой.
Этот процесс для большинства команд теперь автоматизирован. Как нетрудно представить, выполнение подобной работы вручную было бы мучительно медленным и утомительным и сопровождалось бы ошибками. На самом деле, когда процесс не автоматизирован, большинство команд пропускают многие этапы, что сопряжено с риском. «Проторенный путь» — действенная идея. Поскольку большая часть инфраструктуры всегда наготове, выполнить работу правильно также относительно легко, что позволяет командам работать быстро и уверенно.
Однако, как бы я ни нахваливал платформу Admiral, команды не обязаны пользоваться ею. Автономия небольших команд означает, что они не обязаны использовать какой-то определенный инструмент, если не хотят. Они вправе выбирать. Таким образом, Джейсон, как и любой, кто «продает» продукт, должен завоевывать клиентов, т.е. разработчиков Twilio. Вот где его принципы реально действуют.
С помощью предварительно сконфигурированных «конвейеров» Admiral упрощает создание и развертывание стандартных типов услуг. Однако для того, чтобы команды приняли этот инструмент, они должны иметь возможность вмешаться в него и внести изменения, если необходимо. В противном случае им придется создавать собственные инструменты вне платформы Admiral. Вот тут-то и вступает в игру один из принципов Джейсона — выбор в пользу сложности. Хотя команды могут взять настройки по умолчанию, у них есть возможность влезть в недра Admiral и подстроить платформу под конкретный проект. Не нравится инфраструктура модульного тестирования, установленная по умолчанию? Разработчики могут подключить свою собственную, сохранив все преимущества Admiral и остальной части «конвейера». Это касается всех компонентов и дает командам автономию в выборе инструментов, при этом установки по умолчанию остаются легкими, привлекая пользователей к платформе Admiral. Сейчас 55% всех развертываний осуществляется с использованием полной функциональности Admiral. В большинстве остальных случаев мы работаем только с частью возможностей Admiral. И процент подобных развертываний постоянно растет.
Как я уже отмечал, сейчас темпы внедрения инноваций в ПО выше, чем когда-либо прежде. В нашу цифровую эпоху превращение потребностей клиентов в продукты происходит с молниеносной скоростью. Однако часто возникает вопрос: должны ли команды действовать быстро, чтобы не упустить возможности и отреагировать на потребности клиентов, или им нужно действовать более осторожно, заботясь о том, чтобы все созданное ПО работало правильно, хорошо масштабировалось и не содержало ошибок? Однако в действительно хороших софтверных компаниях эта дилемма является ложной. Такие платформы, как Admiral, позволяют разработчикам быстро разрабатывать высококачественный код и коммерчески запускать его с уверенностью, что он не снизит удовлетворенность клиентов.
Главнейшая миссия Джейсона Худака состоит в ускорении работы каждого инженера Twilio, обеспечивая при этом необходимый уровень качества, безопасности и масштабируемости ПО. Можем ли мы создать новую функцию за шесть недель вместо полугода? За шесть дней? За шесть часов? Джейсон считает, что платформа выполняет 80% работы, которую ранее приходилось делать разработчику. Некоторые процессы, которые раньше занимали недели или даже месяцы, теперь можно выполнить «несколькими щелчками мыши за несколько минут». Сегодня Twilio запускает новые программы в эксплуатацию более 160 000 раз в год — это почти 550 раз за рабочий день.
Еще одна проблема, часто возникающая при создании ПО, связана с дублированием работы вместо ее синхронизации. Позволяя командам работать автономно и предоставляя им относительную свободу в выборе методов создания ПО, вы даете им возможность работать быстро, как в стартапе. Но при этом возникает риск, что несколько команд потратят время на создание одинаковых продуктов. Они дублируют работу, решая одну и ту же проблему по-разному. Это расточительно, однако не сильно волнует меня.
Вернер Фогельс из компании Amazon отмечает, что подход, при котором вы сознательно допускаете дублирование работы, часто не подходит традиционным компаниям, неспособным контролировать его. «Это так нелогично для них, поскольку они думают только об эффективности, — объясняет он. — Они привыкли контролировать все сверху донизу. По сути, иерархия для них становится важнее, чем быстрая работа».
Это объясняет, почему меня часто спрашивают, как мы предотвращаем дублирование работы в нашей корпоративной культуре с небольшими, самостоятельными командами. Мой ответ: мы не предотвращаем дублирование.
И вот почему: представьте две компании, которые находятся в противоположных концах шкалы «эффективность-автономность». В одной компании все команды идеально синхронизированы таким образом, что дублирование работы отсутствует. Каждая команда знает свою роль, от каких команд она зависит, а там, где есть возможность дублирования работы, владелец продукта назначается. Это звучит здорово, но работа редко выполняется таким образом. На практике команду обычно ждут те, кто зависит от нее. Когда одна команда не выдерживает сроки, это сказывается на всех остальных участниках рабочего процесса, а вина ложится на того, с кого все началось. Да, здесь нет никакого дублирования, но также нет и ответственности за результат, поскольку слишком много тех, кого можно обвинить, когда что-то идет не так.
А теперь посмотрим на вторую компанию. Команды быстро переходят к обслуживанию своих клиентов, не особенно заботясь о том, дублирует ли их работу кто-то еще. Все, в чем команда заинтересована, — создание успешных продуктов, которые принимаются клиентами, удовлетворяют их и обеспечивают рост доходов. В этой компании разработчикам не нужно спрашивать разрешения или координировать действия с другими командами. Представьте, что каждая из этих команд работает в своем физическом пространстве, имеет свой домен электронной почты и т.д. С тем же успехом это могут быть разные компании. Они настолько несинхронизированы, насколько можно представить. Как и следует ожидать, здесь есть дублирование работы, поскольку команды в действительности не так уж много работают вместе.
Эти две воображаемые компании — примеры крайностей, но они показательны. Какую из них я предпочел бы создать? Конечно, вторую. Компания, в которой люди чувствуют себя самостоятельными и ответственными за результаты, — вот настоящая цель. Совершенная синхронизация неизбежно губит автономию и ответственность.
Вторая компания — это, в принципе, группа стартапов, каждый из которых обслуживает клиентов и получает доход. Прелесть ситуации заключается в том, что цели каждой команды заставляют их хотеть использовать работу других команд при возможности. Зачем изобретать новую систему сборки или инфраструктуру безопасности, если у другой команды уже есть такой продукт, который отвечает вашим потребностям? Это самый короткий путь к достижению целей — увеличению числа клиентов и росту доходов. Но когда нет чужих решений, удовлетворяющих их потребности, они изобретают собственные. По словам Вернера Фогельса, компания Amazon также предпочитает скорость и не зацикливается на дублировании. «Мы позволяем командам просто делать многое самостоятельно, даже если это дублирует некоторые функции. Мы готовы терпеть положение вещей ради быстрого прогресса в работе», — говорит Фогельс.
Другие компании, в первую очередь Microsoft, занялись было искоренением дублирования, но лишь обнаружили, что это съедает больше ресурсов, чем экономит. Дело в том, что слежение за дублированием и/или трата времени на устранение дублирования означает создание нового уровня контроля, который замедляет все. Искоренение дублирования обычно включает в себя рассмотрение дубликатов, выбор одного из них в качестве победителя, а затем навязывание победителя всем остальным командам.
Позволяя командам при необходимости дублировать работу, вы также позволяете им демонстрировать, куда нужно инвестировать. Это как в старой истории: архитектора просят спроектировать кампус колледжа. На презентации окончательного проекта кампуса руководство колледжа отмечает, что на нем отсутствуют пешеходные дорожки. Что ответил архитектор? «Пусть студенты решают своими ногами, где проложить дорожки. Через год это станет очевидно».
Мы разрешаем нашим командам идти вперед и прокладывать путь. Затем мы — технические лидеры и архитекторы — наблюдаем за тем, что появляется. Когда мы видим, что несколько команд создают похожие вещи, то можем вмешаться, выявить тенденцию и создать команду, которая решит эту проблему для всех и повысит эффективность работы. В этом и заключается суть платформ. Но вместо попыток идеально спланировать работу сверху позвольте командам естественным образом показать вам путь.
В конечном счете многое зависит от компромиссов между тем, что вы хотите получить, и тем, что готовы дать. В этом и заключается суть корпоративной культуры. Какие правила нельзя нарушать, если вы хотите, чтобы сотрудники распоряжались своими талантами по-своему? Корпоративные культуры, которые заходят слишком далеко в ту или иную сторону, не работают, а сбалансированность и компромиссы где-то посередине создают почву для создания инновационной организации.
В Twilio существуют решения, которые обязательны для каждой команды, поскольку они жизненно важны для компании. Команды, например, не могут сами решать, должно быть ПО безопасным или нет, — они обязаны выполнять правило безопасности. Наши клиенты и инвесторы, а также рынок требуют этого, и было бы безответственно отправлять небезопасный код. Так что это обязательно. Теперь команды могут использовать, по выражению Джейсона, готовые «проторенные пути», чтобы как можно проще добиться безопасности. Но пока команды соответствуют нашим требованиям, они могут использовать для защиты своего кода и другие механизмы.
То же самое касается надежности. Мы и наши клиенты требуем как минимум безотказной работы всех наших сервисов на уровне 99,95%. Это означает не более 43 секунд простоя в день. Самый простой способ достичь этой строгой цели — полагаться на инфраструктуру, платформы и методы, которые мы разработали для внутреннего пользования. Но если у команды есть уникальное требование или способ, который они считают лучшим и могут доказать это, то они вправе пойти своим путем. Но они по-прежнему несут ответственность за время безотказной работы. Понятно, что у команды должен быть очень сильный мотив для принятия такого решения. Но это иногда приводит и к серьезным инновациям! Только представьте, что команда создает программу, которая помогает повысить безотказность до 99,999%, т.е. допускает всего 26 секунд простоя в месяц! Держу пари, что другие команды тоже захотят воспользоваться ею! На самом деле мы уже близки к этому показателю — немного соперничества нередко приводит к отличным результатам.
Некоторые могут возражать против вложения средств в инфраструктурные команды. Мы обсуждаем этот вопрос почти каждый год при составлении бюджета компании. Легко попасть в ловушку наращивания числа разработчиков, которые создают продукты для клиентов, поскольку отдача от них более заметна. Но инфраструктурные инженеры делают всех разработчиков более эффективными. «Платформы — это мультипликатор нашей эффективности, — говорит Джейсон. — Это как точка опоры. На каждый вложенный доллар я могу вернуть пять».
Вот пример. В 2018 г. нашим разработчикам потребовалось 40 дней, чтобы разработать новый Java-сервис. Мы хотели ускорить процесс. Теоретически можно нанять вдвое больше инженеров, и они будут создавать вдвое больше сервисов в год, так ведь? (На самом деле удвоение числа разработчиков не удвоит производительность, но ради аргументации давайте представим, что это так.) Но это означало бы прием на работу сотен новых разработчиков. Вместо этого Джейсон с двумя платформенными инженерами автоматизировал массу этапов нашего процесса разработки. С их помощью время разработки сократилось вдвое — с 40 до 20 дней. Эффект усиливается еще и в результате того, что мы разрабатываем около 200 новых Java-сервисов в год. Да, мы потратили деньги на этих двух платформенных инженеров. Но их работа экономит нам 4000 человеко-дней в год. Это аргумент в пользу вложения денег в инфраструктуру, а не в увеличение числа разработчиков продукта. Вместо того чтобы концентрировать внимание на том, сколько стоит создание платформенной команды, думайте об отдаче, которую она может принести. Однако не забывайте, что эти инвестиции окупятся не сразу. Мало того, что нужно сформировать команду и создать инфраструктуру — другие команды должны принять ее. Этот процесс требует времени, но он полностью окупается. Такой подход реально становится источником конкурентного преимущества.
Когда мы нанимаем новых разработчиков, они гораздо быстрее включаются в рабочий процесс благодаря платформе Admiral. «Несколько лет назад нам требовалось четыре месяца, чтобы подготовить новых инженеров и превратить их в часть команды, — говорит Джейсон. — Сегодня у нас уходит на это всего неделя». Опять же, все дело в рентабельности инвестиций. Платформенные инженеры приносят намного больше, чем в них вкладывают.
Но какими бы огромными ни были наши достижения, мы полагаем, что платформа может еще больше повысить скорость работы. Джейсон хочет, чтобы процесс развертывания Java, сокращенный с 40 до 20 дней, занимал один день или даже всего несколько часов. Одна из его 13 команд полностью занята оптимизацией самой платформы. Она изучает, как разработчики используют продукт, выясняет, где разработчики испытывают трудности или замедляются, и устраняет проблемы. Чтобы измерить время, которое разработчики тратят на возню с инструментами, Джейсон создал показатель под названием «Время, проведенное вне кода». Он, возможно, никогда у нас не достигнет нуля, но цель состоит в максимальном приближении к нулевому уровню.
«В будущем платформы позволят разработчикам думать только о функциях и клиентах, а не о базовых системах, которые необходимы для превращения программ из задумки в облачное приложение, доступное клиенту», — утверждает Джейсон.
Главное, чтобы современная организация разработки опиралась на лучшие инструменты и методологии, а для этого нужны инфраструктурные инженеры, которые создают платформы, автоматизирующие процесс создания ПО. Все зависит от скорости и качества. Независимо от текущей скорости нашей работы мы можем и должны работать быстрее, не жертвуя при этом надежностью, качеством и безопасностью. Среды разработки, такие как наша платформа Admiral, помогают создавать ПО.
Приступая к созданию платформы, спросите у своих разработчиков, какие процессы еще не автоматизированы. Какая часть процесса разработки станет наиболее вероятной причиной следующего падения вашего сайта или приложения и надо ли ее срочно исправлять? Узнайте, насколько трудоемок процесс развертывания кода в коммерческую поставку. Они разочарованы? Где находятся узкие места и как их можно устранить? Не поддавайтесь желанию урезать инвестиции в платформу — помните, что деньги, потраченные на платформы, делают всех разработчиков более продуктивными. Спросите своих технических руководителей, какой процент бюджета тратится на платформы по сравнению с разработкой продукта и каким должен быть их баланс. Спросите своих руководителей, какая рентабельность инвестиций, с их точки зрения, оправдывает вложения в платформу.
Войти с помощью соц. сетей: