Микросервисы, Game Days и отказ от PowerPoint в Amazon

Интервью с техническим директором Amazon Вернером Фогельсом, организованное акселератором Y Combinator, раскрывает практические аспекты масштабирования технологических систем и управления инженерной культурой. В основе дискуссии лежит эволюция инфраструктуры Amazon от хрупкого монолита начала 2000-х годов до крупнейшего облачного провайдера AWS. Спикер делится тактическими подходами к созданию автономных команд, методологией разработки от потребностей клиента и стратегиями оптимизации затрат для стартапов различного типа.

🛠️ От медицинских ИТ к масштабам Amazon: путь Вернера Фогельса 0:32

Вернер Фогельс пришел в коммерческую разработку из академической среды, проработав около 10 лет научным сотрудником в Корнеллском университете. Его специализацией было проектирование крупномасштабных распределенных систем. До этого, в середине 1980-х годов, он работал в Голландском институте исследований рака, занимаясь лучевой терапией. Решение сменить сферу деятельности Фогельс объясняет эмоциональным выгоранием от постоянной гибели пациентов, что побудило его в возрасте 28 лет заняться компьютерными науками, где не требовалось прямого взаимодействия с людьми. В академический период Фогельс также участвовал в создании двух стартапов: один из них был успешно продан компании Stratus, а второй завершился неудачей.

Параллельно с научной деятельностью Фогельс консультировал такие крупные корпорации, как Nike, HP и Sun Microsystems. Когда в 2004 году компания Amazon пригласила его прочесть лекцию, он изначально отнесся к этому скептически, посчитав компанию обычным книжным интернет-магазином, архитектура которого состоит из веб-сервера и базы данных. Однако, ознакомившись с внутренними процессами изнутри, Фогельс осознал, что столкнулся с масштабной технологической операцией, функционирующей на беспрецедентном для того времени уровне. Это побудило его принять предложение о работе в сентябре 2004 года, а уже в январе 2005 года он занял пост CTO компании, сменив Эла Вермейлена, который предпочел вернуться к роли рядового разработчика.

🏎️ Скорость против эффективности: инженерные компромиссы и технический долг 3:54

В 2004 году у индустрии отсутствовали готовые методологии и книги по построению сверхмасштабируемых систем, и Amazon приходилось развиваться исключительно за счет практического и прагматичного подхода. По словам Вернера Фогельса, компания опережала технологический сектор в среднем на 5–10 лет как в вопросах разработки, так и в эксплуатации инфраструктуры. В отличие от традиционных предприятий, скованных «дилеммой инноватора», быстрорастущие технологические компании вынуждены осознанно идти на специфические компромиссы ради сохранения темпов инноваций.

Основным приоритетом для Amazon являлось поддержание длинного конвейера экспериментов и высокой скорости вывода продуктов на рынок. Ради этого руководство осознанно допускало:

• Создание контролируемого технического долга.
• Дублирование функций и кодовой базы в различных подразделениях.

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

📊 Дисциплина метрик и «Игры на выживание» в инфраструктуре 7:15

Главной задачей Фогельса при вступлении в должность CTO стало привнесение академической строгости в процессы масштабирования, так как компании требовалось вырасти еще на несколько порядков. Для этого потребовалось перестроить культуру работы с данными. По мнению Фогельса, классические методы оценки производительности, такие как медианная задержка (например, 1,2 секунды), нерелевантны для масштабных систем, так как они означают, что 50% пользователей получают худший опыт. Вместо этого инженерная дисциплина Amazon была сфокусирована на контроле 99-го и 99,9-го перцентилей. Это позволило напрямую связать технические метрики с бизнес-показателями: снижение задержек загрузки страниц гарантированно повышает конверсию.

Вторым этапом реформ стала борьба с едиными точками отказа (Single Points of Failure). В 2004 году надежность обеспечивалась за счет репликации данных между тремя дата-центрами, что теоретически позволяло безболезненно пережить отключение одного или даже двух объектов. Чтобы проверить теорию на практике, команда Фогельса внедрила практику контролируемых аварийных испытаний — Game Days. Суть эксперимента заключалась в полной изоляции одного из дата-центров от сети. Фогельс вспоминает, что в ходе первых тестов процессы, выглядевшие идеально на бумаге, выявили множество проблем в реальности:

• Высокую зависимость от ручных операций.
• Задержки при ручном переключении баз данных на резервные копии.

Наибольшей неожиданностью, по словам CTO, стал процесс возвращения дата-центра в сеть: синхронизация накопившихся данных с остальными узлами оказалась критически сложной задачей, которую архитекторы изначально не просчитали. Лишь к третьему-четвертому испытанию процессы удалось полностью автоматизировать, исключив человеческий фактор из цепочки восстановления.

🏗️ Эволюция архитектуры: от монолита к микросервисам и рождению AWS 20:33

В конце 1990-х годов Amazon следовал бизнес-лозунгу «расти быстро» (get big fast), жертвуя архитектурными принципами. Результатом стал громоздкий, хрупкий монолит и массивная база данных на бэкенде, которая блокировала дальнейшее развитие. Для решения проблемы компания осуществила переход к сервисно-ориентированной архитектуре (SOA), занявший около трех лет. Основным препятствием для инноваций в монолитную эпоху Фогельс называет «касту администраторов баз данных» (DBA cabal). Любые изменения схем данных требовали их одобрения, а поскольку администраторы отвечали за стабильность сайта, они действовали максимально консервативно, замедляя работу инженеров.

Переход на SOA изолировал команды, предоставив им собственные независимые хранилища данных. Однако на этом этапе была допущена ошибка: три ключевых массива данных — клиенты, товары (каталог) и заказы — были упакованы вместе с обслуживающим их кодом в единые крупные сервисы. За два года эти сервисы разрослись до размеров исходного монолита. Это заставило Amazon провести декомпозицию на микросервисы. Фогельс приводит в пример сервис управления профилями клиентов, который разбили на 10 независимых функциональных блоков. В частности, сервис аутентификации (login), требующийся при каждом просмотре страницы, был отделен от сервиса адресной книги, нужного только на этапе финальной оплаты. До разделения вся система была вынуждена масштабироваться под экстремальные нагрузки сервиса авторизации.

Параллельно в начале 2000-х годов Amazon открыл API к своему каталогу для внешних разработчиков. На этой основе возникло множество сторонних e-commerce стартапов. Однако Фогельс заметил закономерность: как только эти компании достигали успеха, их развитие останавливалось. Причиной была необходимость закупки физического оборудования и найма ИТ-персонала для обслуживания infraestructura. Венчурные инвестиции стартапов фактически уходили на непрямое финансирование американской компьютерной индустрии, а не на развитие продуктов, что приводило к банкротству перспективных проектов.

Этот паттерн лег в основу концепции AWS. Внутри Amazon инженеры также тратили слишком много времени на администрирование баз данных, балансировщиков и серверов вместо создания инноваций. Для автоматизации этих процессов были созданы внутренние программные интерфейсы (API) для управления виртуальной инфраструктурой. На их базе Amazon разработал внешние продукты:

• Весной 2006 года был запущен сервис хранения Simple Storage Service (S3), позиционировавшийся как «хранилище для интернета».
• Осенью 2006 года состоялся релиз Elastic Compute Cloud (EC2), сделавший вычислительные мощности полностью программируемыми.

Появление облака радикально изменило структуру расходов молодых компаний, позволив им направлять капитал на наем профильных специалистов и совершенствование продукта, а не на закупку серверов.

👥 Роли в ИТ-управлении и «правило двух пицц»: как масштабировать культуру 13:14

Вернер Фогельс разделяет роль технического директора на четыре базовых архетипа, существующих на рынке:

1. Менеджер инфраструктуры в крупных предприятиях (подчиняется CIO, управляет аппаратным комплексом).
2. Технический сооснователь в молодых стартапах (формирует технологическое видение, но часто не справляется с операционным менеджментом команд).
3. Глубокий мыслитель / инноватор (руководит лабораториями и созданием технологий следующего поколения, как в AT&T или Lucent).
4. Внешний технолог (актуально для провайдеров, ориентирован на глубокое техническое взаимодействие с клиентами, выявление их болей и интеграцию обратной связи в продукт). Себя Фогельс относит к последней категории, в шутку называя AWS «бизнесом по управлению болью».

Спикер разграничивает позиции CTO и вице-президента по инжинирингу (VP of Engineering). VP of Engineering — это в первую очередь специалист по людям, который ежедневно сфокусирован на эффективности команды, правильной расстановке кадров и процессах доставки кода. В качестве эталона управленческой мысли в этой сфере Фогельс рекомендует читать блог Майкла Лоппа (известного под псевдонимом Rands, автора ресурса «Rands in Repose»). Задача же CTO — думать об архитектуре, инструментах и долгосрочной технологической стратегии.

Для поддержания высокой скорости разработки в Amazon используется концепция малых автономных групп — «команд двух пицц» (размером в 10–12 человек). По мнению Фогельса, иерархические структуры противоестественны, поскольку в природе (например, в стаях приматов или у муравьев) существуют вожаки и самоорганизующиеся группы, но нет систем «лейтенантов». Малый размер команд гарантирует, что каждый сотрудник четко понимает задачи коллег, тогда как проведение утренних стендапов на 25 человек Фогельс считает неэффективным. В компании действуют 14 принципов лидерства (включая Customer Obsession, Ownership, Dive Deep), которые служат главным фильтром при найме. Фогельс отмечает, что технические навыки соискателя проверяются на этапе предварительных созвонов, в то время как очные интервью полностью посвящены оценке культурного соответствия, поскольку одна деструктивная личность способна полностью разрушить работу небольшой автономной команды.

🚀 Стратегия минимального продукта: как клиенты управляют дорожной картой AWS 32:15

По состоянию на момент проведения интервью каталог AWS насчитывал около 130 сервисов. При этом около 95% всех новых функций и продуктов создаются как прямой ответ на запросы клиентов. Если базовые элементы (хранилище, вычисления, СУБД) были очевидны изначально, то последующие направления — аналитика, решения для Интернета вещей (IoT), мобильная разработка и блокчейн — формировались под влиянием рынка.

Инженерная культура AWS предписывает выводить продукты на рынок в формате минимально жизнеспособного набора функций (MVP), но с бескомпромиссным уровнем надежности и безопасности бэкенда. Гость поясняет, что клиенты строят на технологиях AWS свой бизнес, поэтому сырые или нестабильные решения недопустимы. Запуск с минимальным функционалом необходим для наблюдения за реальными паттернами использования, которые почти всегда отличаются от первоначальных гипотез создателей. В качестве примеров такой эволюции Фогельс приводит следующие кейсы:

• DynamoDB: разработчики знали о необходимости вторичных индексов, но запустили продукт без них. Клиенты скорректировали дорожную карту, потребовав в первую очередь управление доступом на уровне отдельных элементов (item-level access management), что заставило команду изменить приоритеты.
• AWS Lambda: запущенная в 2014 году бессерверная среда изначально позиционировалась как инструмент для событийно-ориентированных микросценариев (например, обработка файла при загрузке в S3). Однако решение мгновенно переняли крупнейшие корпорации для исполнения тяжелых пакетных задач, поскольку модель оплаты исключительно за время вычислений (без затрат на простаивающие серверы EC2) кардинально меняла экономику разработки. На основе этих наблюдений AWS впоследствии развернула целую экосистему сопутствующих инструментов, включая отладчик X-Ray и сервис оркестрации Step Functions.

Фогельс приводит статистику: за предыдущий год AWS выпустила более 1400 новых функций и сервисов, и скорость релизов продолжает расти по мере диверсификации продуктовых команд.

✍️ Метод Working Backwards и культура шести страниц: как Amazon уничтожил PowerPoint 38:43

Чтобы предотвратить ситуацию, когда инженеры создают абстрактные технологии ради самих технологий, а не для решения конкретных болей пользователей, в Amazon повсеместно внедрен процесс Working Backwards («работа от клиента в обратную сторону»). Любая инициатива — от создания СУБД до открытия нового офиса — начинается с подготовки четырех документов:

1. Пресс-релиз: внутренний текст, описывающий будущий продукт в простых и понятных для конечного потребителя терминах.
2. FAQ: список из 20 наиболее вероятных и сложных вопросов от пользователей и стейкхолдеров с емкими ответами.
3. UX-документ: описание интерфейса и механики взаимодействия пользователя с системой.
4. Руководство пользователя: черновик документации и глоссарий терминов.

Фогельс отмечает, что до начала написания первой строки кода эти документы могут дорабатываться и переписываться от 10 до 15 раз. Правило компании строго запрещает инженерам реализовывать функции, выходящие за рамки утвержденного пресс-релиза, что отсекает попытки заложить избыточную функциональность под гипотетическую «вторую версию».

Параллельно в Amazon действует жесткий мораторий на использование презентационных слайдов (PowerPoint или Keynote) на совещаниях. По мнению Фогельса, презентации неэффективны: половина участников отвлекается на смартфоны, а вторая начинает задавать деструктивные вопросы уже на втором слайде, не видя картины целиком. Вместо этого авторы идеи обязаны составить связный шестистраничный текстовый нарратив (Six-Pager). Любая встреча начинается с того, что все присутствующие первые 30 минут проводят в абсолютной тишине, вчитываясь в документ. Написание качественного текста требует строгости и ясности мышления, поэтому документы часто готовятся коллективно. Фогельс констатирует, что после получасового чтения дискуссия сразу переходит на экспертный уровень, поскольку вся базовая информация уже усвоена участниками в равной степени.

🔒 Будущее разработки: бессерверная эволюция и паранойя безопасности 43:57

Анализируя технологические тренды, Вернер Фогельс отмечает, что многие современные стартапы начинают пропускать этап контейнеризации приложений (Docker, Kubernetes) и переходят сразу к бессерверной архитектуре (Serverless). Контейнеры стали популярны как промежуточный шаг при распиле монолитов на микросервисы, однако они накладывают на команды скрытые инфраструктурные издержки. До появления таких решений, как AWS Fargate (позволяющего запускать контейнеры напрямую без управления виртуальными машинами), инженерам приходилось администрировать операционные системы, балансировщики и распределение мощностей по зонам доступности, что Фогельс называет «налогом на технологии». В ближайшие годы, по прогнозам CTO, фокус сместится на развитие комплексных Serverless-экосистем и инструментов их глубокой интеграции.

Критически важным вызовом для индустрии Фогельс считает обеспечение информационной безопасности, которая должна стать приоритетом номер один для каждого сотрудника — от рядового инженера до CEO. Гость выражает глубокое возмущение тем, что регулярные сообщения о массовых утечках данных стали восприниматься обществом и бизнесом как норма. По его жесткому утверждению, компания, не способная защитить данные своих клиентов, не имеет права на существование. Попытки внедрить безопасность «задним числом» (retrofit) через 2–3 года после запуска, когда стартап уже достиг масштаба, неизбежно оборачиваются технологической катастрофой.

Фогельс настаивает на радикальной перестройке пайплайнов непрерывной интеграции и доставки (CI/CD):

• Любое добавление новой сторонней open-source библиотеки в код должно автоматически триггерить тревогу и отправлять компонент на аудит безопасности.
• Комплаенс-проверки (например, на соответствие медицинскому стандарту HIPAA или финансовым регуляциям) должны быть полностью автоматизированы внутри конвейера развертывания.

При этом Фогельс развеивает миф о небезопасности непрерывного деплоя (Continuous Deployment). По его мнению, автоматизированный анализ пяти измененных строк кода в реальном времени на порядок надежнее старой практики, когда ИТ-отдел раз в полгода пытался вручную верифицировать массив из 50 000 строк кода, не понимая до конца его устройство.

💰 Миссионеры против наемников: две стратегии выживания стартапов 52:16

Распространенной технической ошибкой новичков Фогельс называет перенос старых паттернов физических дата-центров в облако (Lift-and-Shift). Используя AWS исключительно как набор виртуальных серверов и дисков, компания теряет ключевые преимущества эластичности и производительности, которые дают высокоуровневые управляемые сервисы аналитики и мобильной разработки.

На стратегическом уровне основателям необходимо четко определить фундаментальный тип своего бизнеса, поскольку от этого зависит целевая архитектура и модель управления затратами. Фогельс разделяет стартапы на две категории, ссылаясь на классификацию Джеффа Безоса:

1. Наемники (Mercenaries) — предприниматели, ориентированные исключительно на финансовую выгоду и быструю продажу бизнеса. Их стратегия — агрессивный рост («get big fast»), максимизация абонентской базы любой ценой на венчурные деньги без оглядки на текущую маржинальность. В этой модели расходы на инфраструктуру не являются приоритетом, ключевая цель — скорость адаптации под запросы пользователей.
2. Миссионеры (Missionaries) — основатели, движимые любовью к своему продукту и стремящиеся построить устойчивый, прибыльный бизнес на десятилетия вперед. В качестве примера Фогельс приводит создателей Basecamp (37signals) Дэвида Хайнемайера Ханссона (DHH) и Джейсона Фрида. Данный путь требует совершенно иной инженерной архитектуры: жесткого контроля юнит-экономики, минимизации издержек и прозрачной корреляции между стоимостью инфраструктуры и стоимостью привлечения каждого нового клиента.

Фогельс резюмирует, что AWS одинаково эффективно поддерживает обе бизнес-модели, однако архитектурный фундамент, закладываемый инженерами на старте, должен строго соответствовать глобальной стратегии основателей.