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

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

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

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

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

Принципы джейсона

Когда Джейсон Худак пришел в Twilio, он составил список принципов и ценностей, чтобы показать всем, как он строит платформу и управляет ей. Ему пришлось искать баланс между предоставлением разработчикам свободы и автономии и принуждением их придерживаться набора стандартных процедур. Стандарты помогают нам обеспечить связанность почти во всех частях кодовой базы (как я уже говорил в главе 6, правильно разработанные ограничения могут освобождать людей). Но нам не нужна жесткость, которая подавляет инновации. Мы стараемся поддерживать этот баланс должным образом.

Вот его принципы.

Проторенный путь

Платформа Admiral включает в себя все необходимые разработчику инструменты. Но разработчики не обязаны их использовать. Если вам нравится конкретный инструмент тестирования, но его нет в платформе, вы можете пользоваться им. Джейсон называет это «бездорожьем» по сравнению с «проторенным путем», имея в виду, что у тех, кто использует инструменты, выбранные нами, жизнь будет легкой, как езда по проторенной дороге. Тем не менее вы вольны ездить по бездорожью. Вы все равно доберетесь в пункт назначения, но это может занять больше времени. Одно из любимых выражений Джейсона: «У нас нет правил – у нас есть ограничения». Но тем, кто едет по бездорожью, все равно нужна безопасность и устойчивость, а с этой точки зрения проторенный путь лучше.

Выберите свой язык

Другой пример: мы не заставляем разработчиков использовать только один язык программирования. Мы поддерживаем четыре языка – Python, Java, Scala и Go. Разработчик может использовать любой из них и при этом получать полностью поддерживаемую платформу. Но, как и в случае с инструментами, разработчики имеют право выбирать и другие языки. Вопрос опять о том, где ехать – по проторенной дороге или по бездорожью. «Если вы хотите писать что-то на языке C или на другом языке, это ваше право – мы здесь не для того, чтобы говорить, что можно, а что нельзя делать, – объясняет Джейсон. – Просто знайте, что вам придется попотеть больше, поскольку вы не сможете использовать инструменты платформы разработчика».

Самообслуживание

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

Выбор в пользу сложности

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

Сочувствуйте, но жестко расставляйте приоритеты

«Нам не нравится говорить “нет”, – утверждает Джейсон. – Но если у одной команды есть запрос на нечто, что было бы круто сделать, а у другой команды есть проект, который принесет компании $90 млн постоянного дохода, мы сначала решим второй вопрос, а первый внесем как запрос в наш бэклог».

Многокомпонентное, а не монолитное

Наше ПО построено на архитектуре, состоящей из сотен микросервисов. Каждый микросервис предоставляет одну функцию или возможность. Преимущество микросервисов в том, что