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

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

Разделение работы на специализированные роли давало определенные преимущества, однако замедляло процесс разработки. Разработчики передавали код инженерам по качеству, которые интенсивно работали с ним и отправляли назад для исправления. Так происходило многократно. Затем код отправлялся инженерам по выпуску, которые могут отправить его обратно, а затем инженерам по надежности сайта, которые также могут завернуть его. (Вы, наверное, уже поняли, что я не любитель подобной организации работы.) На каждом этапе могут возникать задержки, поскольку разработчик ждет, пока инженер по качеству или инженер по выпуску закончит другие проекты, а затем займется его продуктом. Умножьте эти потенциальные задержки на количество итераций, и вы увидите, что процесс может вообще остановиться.

Методология DevOps, впервые предложенная около десяти лет назад, представляет собой попытку ускорить процесс, поручив выполнение всех этапов одному разработчику. Концепция отражена в самом названии: вместо того, чтобы иметь «разработчиков», пишущих код, и «операторов», делающих все остальное, вы объединяете все обязанности в одном лице. В среде DevOps один и тот же разработчик пишет код, тестирует его, упаковывает, контролирует и отвечает за него после коммерческого запуска продукта.

Это последнее предложение представляет один из самых важных элементов современной разработки программного обеспечения и то, что мы в Twilio считаем почти священным: человек, который пишет код, также «живет с пейджером» после его коммерческого запуска.

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

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

В традиционной модели разработчики реализуют лишь некоторые из этих практик. Они могут писать кое-какие тесты, но не полные сквозные тесты. Возможно, они документируют свой код, но не выполняют функции команды поддержки. Возможно, у них есть хорошие методы обеспечения безопасности, но не практики конфиденциальности. Нельзя сказать, что им все равно – просто они не слишком хорошо понимают, как выглядит совершенство. Лучший способ добиться успеха в подобной работе заключается, естественно, в автоматизации. Вместе с тем, если каждой команде придется стать экспертом и самостоятельно автоматизировать процесс в каждой из категорий, это займет целую вечность. Вот тут-то и появляется команда Джейсона.

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

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