В 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, не имея серьезного опыта во всех этих специальных дисциплинах». Они не разрабатывают ПО, поставляемое клиентам. Они создают ПО, которое разработчики используют для написания, тестирования, развертывания и мониторинга собственных программ. Если что-то в нашем рабочем процессе напоминает сборочную линию, то это, вероятно, самый близкий аналог. Платформенные инженеры – это специалисты, которые проектируют и оптимизируют «сборочную линию», ускоряющую инновации.

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