мы можем обойти или выдержать сбой. Например, отказ одного микросервиса не выведет из строя всю голосовую систему 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, обеспечивая при этом необходимый уровень качества, безопасности и масштабируемости ПО. Можем ли мы создать новую функцию за шесть недель вместо полугода? За шесть дней? За шесть часов? Джейсон считает,
