Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - Джефф Лоусон

велосипедами, однако 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 считаем почти священным: человек, который пишет код, также «живет с пейджером» после его коммерческого запуска.

Это твой код. Если он дает сбой, ты его исправляешь. Нам нравится этот подход, поскольку он подталкивает разработчиков к созданию более качественного кода. Страх перед ночными телефонными звонками служит дополнительным стимулом лишний раз проверить работу продукта перед отправкой.

Это не значит, что мы позволяем командам отправлять код, который постоянно рушится,