Спроси разработчика. Как стать лидером рынка с помощью создания собственного ПО - [89]

Нередко крупные софтверные компании направляют более 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 могут потребоваться годы, но для наших целей я дам предельно упрощенное объяснение этой методологии, которое выглядит следующим образом: