DevZone

The Pulse #146: Как искусственный интеллект меняет технические собеседования

2025-11-06T07:17:43.809Z

Крупные технологические компании задают более сложные вопросы на собеседованиях, в то время как стартапы отказываются от алгоритмических вопросов и заданий. Кроме того, набирает популярность новый тренд — разработка внутренних инструментов для разработчиков.

The Pulse - это серия, освещающая события, идеи и тенденции в сфере крупных технологий и стартапов.

Сегодня мы рассмотрим:

Как искусственный интеллект меняет собеседования при приёме на работу в сфере технологий. Новые подробности о более сложных вопросах для кандидатов, растущих опасениях по поводу мошенничества и распространении процессов собеседования с использованием искусственного интеллекта от 63 инженеров из крупных технологических компаний и стартапов, которые проводят собеседования на платформе для имитационных собеседований interviewing.io.
Новая тенденция: разработчики создают внутренние инструменты с помощью ИИ. Инженеры-программисты всё чаще используют ИИ-агентов для создания простых инструментов, на написание которых обычно уходит несколько часов или дней.
Новости отрасли. Кошмар с безопасностью в npm, Microsoft присоединяется к клубу «три дня в офисе», Klarna выходит на биржу, Meta закрывает небольшие инженерные офисы и многое другое.

1. Как искусственный интеллект меняет собеседования

Команда interviewing.io провела опрос среди интервьюеров на своей платформе, представляющих крупные технологические компании и стартапы, и выяснила, как искусственный интеллект меняет процесс проведения собеседований на их рабочих местах. Они получили 63 подробных ответа, и в этом информационном бюллетене впервые публикуются результаты исследования.

Особая благодарность Алин Лернер, которая поделилась со мной данными. Алин — основательница interviewing.io, соавтор Beyond Cracking the Coding Interview и создательница Whiteboard Confidential Podcast.

Демография

Большинство респондентов работают в крупных технологических компаниях (Apple, Google, Meta, Microsoft или Netflix) или в новых крупных технологических компаниях (Uber, Stripe, DoorDash и других), а также в стартапах.

Из 63 респондентов 45 работают в крупных технологических компаниях, 7 — в «новых крупных технологических компаниях», а 11 — в стартапах

Насколько распространена практика мошенничества на удалённых собеседованиях? Согласно результатам опроса, она широко распространена:

81% интервьюеров из крупных технологических компаний и новых крупных технологических компаний заявили, что подозревали кандидатов в использовании инструментов искусственного интеллекта для обмана во время собеседований
31%интервьюеров в крупных технологических компаниях и новых крупных технологических компаниях поймали кандидатов на обмане во время собеседования, то есть на использовании инструментов искусственного интеллекта для получения ответов, которые они выдают за свои

Meta — единственная крупная технологическая компания, которая проводит общекорпоративные изменения для борьбы с мошенничеством, согласно этому исследованию.Из интервью с представителем Meta на сайте interviewing.io:

«Сейчас в Meta особое внимание уделяется предотвращению мошенничества. Теперь мы должны указывать, есть ли у нас подозрения, что кандидат жульничает, практически на всех типах/уровнях собеседований, и обосновывать это, если есть. Раньше это касалось только собеседований по программированию. Мы также требуем, чтобы кандидаты показывали весь экран и отключали все фоновые фильтры (включая размытие) на большинстве собеседований».

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

«Моя компания развивается медленно, несмотря на многочисленные случаи мошенничества и другие проблемы».

Итак, почему обман с помощью ИИ вызывает беспокойство у интервьюеров, но многие компании не реагируют на это? Я считаю, что это связано с несколькими факторами:

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

Вопросы на собеседованиях в крупных компаниях действительно сложные

Тем временем интервьюеры, похоже, берут дело в свои руки и борются с читерами, использующими инструменты искусственного интеллекта, задавая более сложные вопросы. 58% интервьюеров из крупных технологических компаний заявили, что изменили формат вопросов, которые они задают, чтобы предотвратить потенциальное использование «читерских инструментов» на основе ИИ. Вот что рассказали нам респонденты из разных компаний (каждый пункт — это подход одного интервьюера):

Meta:

Больше открытых вопросов, которые побуждают к размышлениям, а не к применению известного шаблона
Добавляйте вариации к популярным вопросам, потому что это часто застаёт мошенников врасплох — по крайней мере, пока
Задавайте вопросы с более подробными описаниями и сложными инструкциями по настройке, с которыми ИИ-инструментам сложнее справиться

Microsoft:

Использование более сложных задач по программированию, решения которых с помощью LLM часто содержат подсказки, раскрывающие их использование
Задавайте вопросы, которые требуют от кандидатов свободного объяснения концепций, для чего недостаточно просто прочитать ответ, сгенерированный искусственным интеллектом
Проверка того, как кандидаты могут расширить существующую логику с помощью структуры классов, вместо того чтобы переписывать всю логику. Опять же, большие языковые модели пока не очень хороши в этом
Больше внимания уделяйте системному пониманию и более сложным вопросам практической реализации
Задаём изменённую версию вопроса с LeetCode
Формулировка вопросов таким образом, чтобы популярные языковые модели, такие как ChatGPT, давали неправильные ответы

Amazon:

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

Google:

Не задаём вопросы в стиле LeetCode. Вместо этого задаём вопросы, состоящие из множества частей, которые требуют решения, а не кодирования.
Постановка абстрактных задач, не предполагающих однозначного ответа. Кроме того, следует задавать вопросы, имеющие несколько решений, для поиска которых кандидатам необходимо использовать навыки логического мышления.
Используйте другую терминологию и формулируйте вопросы так, чтобы инструменты ИИ не могли их распознать. Задавайте более сложные вопросы, для ответа на которые требуется 2 или более структур данных или алгоритмов

Apple:

Задавайте больше вопросов из реальной жизни и меньше алгоритмических вопросов

Netflix:

Вопросы не изменились.

Как уже упоминалось выше, из-за инструментов для списывания, основанных на искусственном интеллекте, вопросы становятся всё сложнее, а интервьюеры усложняют работу невидимых ИИ-помощников, делая следующее:

Задаем вариации общедоступных вопросов с LeetCode
Задавайте более практичные или более сложные вопросы
Задавая более абстрактные вопросы
Больше внимания решению задач, а не написанию кода

Интервьюеры также меняют свой подход. Интервьюеры из крупных технологических компаний и новых крупных технологических компаний сообщают, что они адаптируются, чтобы бороться с мошенничеством с использованием ИИ, следующим образом:

Ищем «шаблоны ИИ». В ответах, предоставляемых ИИ, есть заметные шаблоны. Когда интервьюер замечает, что кандидат использует шаблон, он обращает на это внимание.
Сосредоточьтесь на вопросе «почему». Спросите, почему кандидат сделал тот или иной выбор, и попросите его подробно объяснить.
Дополнительные вопросы. Побуждаем кандидатов объяснять ход своих мыслей, с чем LLM справляется с трудом.
Более подробные вопросы. «Что делает эта строка кода, что произойдёт, если мы её удалим, как можно сделать то же самое по-другому?»
Задайте вопрос ещё раз. Задайте тот же вопрос ещё раз, позже. Кандидат, не использующий ИИ, даст тот же ответ, в то время как кандидат, полагающийся на ИИ, скорее всего, ответит иначе, поскольку ИИ недетерминирован.
«Стремительные» вопросы. Ускорение темпа вопросов, чтобы не оставалось времени на их ввод в качестве подсказок, и сокращение возможностей для считывания ответов ИИ с экрана.
Кандидаты объясняют ход своих мыслей. Одного хорошего ответа уже недостаточно; интервьюеры просят кандидатов подробно объяснить ход своих мыслей и рассуждений.

Крупные технологические компании: алгоритмические собеседования никуда не денутся

Среди 53 респондентов из крупных технологических компаний и новых крупных технологических компаний НИ ОДИН не сказал, что его компания отказалась от алгоритмических вопросов.

Однако более половины респондентов заявили, что через 2–5 лет алгоритмические собеседования будут менее популярны, чем сейчас. Напротив, около 20% респондентов убеждены, что алгоритмические собеседования никогда не исчезнут.

Мы подробно рассматриваем эту тему в статье Как опытные инженеры справляются с собеседованиями по программированию.

Стартапы внедряют собеседования с использованием ИИ

Забавный факт: крупные технологические компании не сильно меняют процесс собеседования, в отличие от стартапов.

Наиболее распространённые изменения в стартапах:

Больше никаких алгоритмических вопросов. Многие стартапы отказываются от них, поскольку инструменты ИИ легко справляются с ними и они не имитируют повседневную работу.
Больше никаких домашних заданий. Инструменты на основе ИИ очень хорошо справляются с домашними заданиями, и кандидаты всё чаще просто вводят свои ответы в такие инструменты, как Claude Code. Раньше стартапы часто задавали домашние задания, но инструменты на основе ИИ означают, что в наши дни они практически бесполезны, и от них отказываются.
Собеседования с использованием ИИ заменяют алгоритмические собеседования и собеседования на дому. Все больше стартапов добавляют в свой основной цикл собеседования этап, на котором кандидаты должны использовать инструменты ИИ, демонстрируя свой экран. Они решают более сложные задачи, а также имитируют повседневную работу, поскольку почти каждый инженер в стартапах использует инструменты для написания кода на основе ИИ!

Компания Shopify начала проводить собеседования с использованием искусственного интеллекта. Вот что сказал об этом технический директор компании Фархан Тавар (смотрите полное интервью в этой записи, с 41:49):

Гергели: «Подождите. То есть вы используете ИИ во время собеседований?»

Фархан: «Да».

Гергели: «Ты от этого не убежишь».

Фархан: «Мы принимаем это».

Гергели: «Как это работает? Расскажи мне».

Фархан: «Мне это нравится. Потому что сейчас ИИ иногда генерирует полный бред.

Мы позволяем кандидатам использовать всё, что они хотят. Вот что я скажу:

Если они не используют автопилот, то обычно проигрывают тем, кто его использует. Так что у них не будет другого выбора, кроме как использовать автопилот.

Когда кандидат использует автодополнение, мне нравится смотреть на сгенерированный код. Я спрашиваю: что вы думаете? Хороший ли это код? Плохой ли это код? Есть ли в нём проблемы?

Я видел, как инженеры, например, не исправляли то, что было очень легко исправить. Они пытались подсказать, как это исправить. И я говорю: «Ты правда инженер? Я понимаю, что можно просто подсказывать, подсказывать и подсказывать. Но иногда решение прямо перед тобой, а они продолжают подсказывать. Я думаю: «Просто измените этот один символ — но они его не изменят!»

И я думаю, что не хочу, чтобы вы использовали ИИ на 100%. Я хочу, чтобы вы использовали его на 90–95%. Я хочу, чтобы вы могли зайти, посмотреть на код и сказать: «Да, здесь есть ошибка».

Вы можете прослушать полное интервью здесь.

Крупные технологические компании: вернутся ли очные собеседования?

Вот процент респондентов, которые ожидают, что личные собеседования вернутся в формат очных:

Интервьюеры из Apple, Microsoft и Google ожидают, что очные собеседования вернутся. В других компаниях ситуация неоднозначная

Предостережение: все эти данные получены от инженеров, а не от лиц, принимающих решения. Привлечение кандидатов на месте сопряжено с расходами (например, на перелеты и отели) и логистическими трудностями (необходимо освободить переговорные комнаты для проведения собеседований). Проведение собеседований в удаленном режиме позволяет сэкономить деньги и не требует решения проблемы поиска помещений для проведения собеседований. По таким логистическим причинам даже компании, которые предпочитают проводить больше собеседований лично, скорее всего, будут проводить отборочные собеседования в удаленном режиме.

Эл меняет интервью

Мне кажется, что мы переживаем самую масштабную трансформацию технических собеседований за последние 15 лет. С 2010 года собеседования в крупных технологических компаниях и «топовых» стартапах были довольно предсказуемыми: алгоритмические собеседования, собеседования по системному проектированию и поведенческие собеседования. Но сегодня собеседования, похоже, меняются в разных направлениях:

Крупные технологические компании: всё как обычно, но вопросы изменены с учётом ИИ. Интервьюеры задают более сложные алгоритмические вопросы и меняют свои стратегии, чтобы выявлять мошенников, использующих ИИ, во время дистанционных собеседований.
Гибридные и офлайн-компании: возвращение личных собеседований? Для компаний, где инженеры должны проводить в офисе 2–3 дня в неделю, возвращение личных собеседований не является большой проблемой. Кроме того, если новый коллега будет работать в офисе, почему бы кандидатам не прийти и не познакомиться со своими потенциальными коллегами? Пока неясно, какие крупные компании вернут личные собеседования, но есть ощущение, что это могут сделать Apple, Microsoft и Google.
Стартапы и полностью удалённые компании: проведение собеседований с использованием ИИ. Стартапы всё чаще используют Copilot, Cursor и другие инструменты для написания кода в процессе собеседований и предлагают более сложные задачи, для решения которых требуются инструменты для написания кода с помощью ИИ. Это делает собеседования более похожими на повседневную работу, и более крупные полностью удалённые компании, такие как Shopify и Canva, также внедряют этот подход.

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

Надеюсь, вам понравился этот обзор о том, как меняется процесс найма технических специалистов. Большое спасибо команде interviewing.io за их работу. Вы можете прочитать более подробный анализ тех же данных проведенный командой interviewing.io.

2. Новый тренд: разработчики создают внутренние инструменты

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

Инженеры рассказали мне о своём опыте в этой области, в том числе в следующих сферах:

Визуализация данных:

Визуализация трудночитаемых журналов, получение дополнительных данных для контекста и все это в удобном интерфейсе. Создано бэкенд-разработчиком для самопомощи во время разработки.
Извлеките истории из JIRA и создайте диаграмму Ганта. Просто попросите агента сделать это, и он всё сделает.

Дашборды. Инженер создал дашборд по экологическим, социальным и управленческим вопросам (ESG), чтобы поделиться им с несколькими сотрудниками. Они подключили источники данных для этого дашборда и попросили агента самостоятельно создать дашборд, несколько раз подсказав ему, как сделать это правильно.
Анализ данных. Подсказка: создайте небольшие инструменты для анализа источника данных, формирования отчетов и создания визуализаций на их основе.
Пользовательские, «экзотические» инструменты. Инженер создал плагин Figma для поддержки пользовательских аннотаций на основе Swagger файлов (Swagger используется для создания API).
Инструменты с пользовательским интерфейсом. Указание агенту на необходимость добавить пользовательский интерфейс поверх специального инструмента, например инструмента для импорта или экспорта, созданного для разовой операции импорта или экспорта.
Инструменты для автоматизированного тестирования. Предложение агенту создать инструменты для интеграционного или сквозного тестирования, которые потребовали бы больших усилий при ручном тестировании.
«Микро»-инструменты. Небольшие, но полезные инструменты для разработки или отладки, например, запрос к агенту о создании bash-скрипта с виджетами ncurses (с использованием таких виджетов, как поле ввода, контрольный список, кнопка или другие графические элементы) или запуск скрипта с пользовательской цветовой схемой. Вручную это занимает много времени, но с агентом всё просто.

Эти сценарии объединяет то, что на их создание вручную ушло бы до суток, и они используются лишь небольшим количеством коллег. Но потратить даже пару часов на создание одноразового инструмента — это уже слишком, потому что это значительная часть рабочего дня. С помощью агентов вам не придётся тратить столько времени: просто дайте команду, а затем несколько раз исправьте результат, и всё готово!

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

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

Похоже, эта практика быстро распространяется, и её внедрение ускорилось с мая, когда Claude Code стал намного функциональнее. С тех пор другие агенты, такие как OpenAI Codex, Gemini CLI и другие, последовали этому примеру.

Если у вас есть мысли по поводу этой тенденции или личный опыт, пожалуйста, оставьте комментарий.

3. Пульс отрасли

npm: кошмар безопасности?

Последние две недели были неудачными для npm, менеджера пакетов по умолчанию для популярной платформы Node.js. Произошло несколько атак на цепочку поставок, когда вредоносный код внедряется в популярные пакеты npm.

Атака на цепочку поставок № 1: попытка кражи криптовалюты. 8 сентября был взломан аккаунт разработчика, публиковавшего несколько популярных пакетов npm. Пакеты были повторно опубликованы с вредоносным кодом (разработчиком был Qix-.) Среди скомпрометированных пакетов были chalk, strip-ansi и color-convert. Тысячи других пакетов npm используют эти зависимости, и, по оценкам, вредоносный код был загружен более 1 миллиарда раз(!)

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

Атака на цепочку поставок № 2: попытка кражи учётных данных. Начиная с воскресенья, 14 сентября, более 500 пакетов npm были скомпрометированы. Что делал вредоносный код:

Скачал и запустил TruffleHog, легальный сканер секретов
Выполнен поиск в системах хостинга токенов и облачных учётных данных
Проверенные учётные данные разработчика и CI
Созданы неавторизованные рабочие процессы GitHub Actions в репозиториях
Конфиденциальные данные были переданы на жестко запрограммированную конечную точку вебхука

Несколько скомпрометированных пакетов npm поддерживались компанией CrowdStrike, специализирующейся на повышении уровня безопасности, что довольно иронично. Узнайте больше об этой атаке. Если название CrowdStrike вам знакомо, то это потому, что компания стала причиной крупнейшего в мире сбоя в 2024 году, когда её обновление вывело из строя 8,5 млн компьютеров с Windows, отключив аэропорты, банки и супермаркеты по всему миру.

При использовании Node в его нынешнем виде нет очевидного способа защититься от этой атаки. Экосистема Node очень зависима от сторонних пакетов, и большинство из них устанавливаются неявно. Таким образом, если вы используете один пакет, вы неявно получаете все зависимости этого пакета. А в экосистеме Node использование сторонних пакетов очень распространено, поэтому добавление одной зависимости npm может привести к добавлению сотен неявных зависимостей пакетов!

У Node так много зависимостей, потому что у JavaScript как языка программирования нет мощной стандартной библиотеки. Таким образом, чтобы избежать атак на цепочку поставок через пакеты, нужно использовать язык с гораздо более мощной стандартной библиотекой, то есть можно создавать программное обеспечение с гораздо меньшим количеством зависимостей.

Атаки на цепочки поставок с использованием скомпрометированных пакетов характерны не только для Node или npm, но Node — это экосистема с наибольшим количеством зависимостей, поэтому она является идеальной мишенью для злоумышленников.

Один из инженеров-основателей нового стартапа рассказал мне, что они выбирали между использованием TypeScript/Node и Go на бэкенде. Они выбрали Go, чтобы избежать «ада зависимостей npm» и сопутствующего ему кошмара с безопасностью. У Go более мощная стандартная библиотека; на самом деле это одно из главных преимуществ языка, и у программ на Go почти всегда гораздо меньше зависимостей, чем у программ на Node.

Microsoft присоединяется к клубу RTO «3 дня в неделю»

Microsoft была одной из последних компаний, которая не устанавливала жёстких требований к количеству дней, которые сотрудники должны проводить в офисе, и оставляла это на усмотрение команд. На прошлой неделе ситуация изменилась: 9 сентября всем сотрудникам было разослано письмо, в котором сообщалось, что с февраля 2026 года они должны проводить в офисе не менее трёх дней. Внедрение будет осуществляться в зависимости от местоположения в три этапа:

Район Сиэтла: сотрудники, проживающие в радиусе 50 миль от офиса в Сиэтле, начиная с февраля 2026 года
Другие населенные пункты в США
Все остальные страны, кроме США

Если говорить начистоту, Microsoft предоставляет щедрый срок уведомления — не менее 6 месяцев. Также можно запросить исключение. Если бы мне пришлось гадать, я бы предположил, что опытные инженеры с большим стажем, которые переехали в другой город и пользуются уважением в своей организации, могут быть освобождены от этого требования. И даже если запрос на исключение будет отклонён, у вас будет достаточно времени, чтобы решить, искать ли новую работу в следующем году или переехать.

Все крупные технологические компании уже давно настаивают на гибридном формате работы, но после заявления Microsoft все они — Apple, Google, Meta и Microsoft — теперь требуют проводить в офисе 3 дня в неделю, а Amazon — 5 дней.

Недавно мы сообщали, что количество полностью удалённых рабочих мест продолжает сокращаться. Решение Microsoft сократить количество полностью удалённых рабочих мест соответствует общеотраслевой тенденции.

Klarna выходит на публику

Компания Klarna, предоставляющая услугу «Купи сейчас, заплати потом», долгое время готовилась к выходу на биржу, и 10 сентября IPO наконец состоялось. На момент написания статьи Klarna оценивается в 17 миллиардов долларов: это ниже пиковой оценки в 45 миллиардов долларов в 2021 году, но более чем в 2 раза выше оценки 2022 года в 6,5 миллиарда долларов.

Политика компании Klarna в отношении акций обернулась против сотрудников. Некоторые сотрудники потеряют деньги на IPO: те, кто присоединился к компании в период с 2021 по 2022 год, получили RSU при оценке в 45 миллиардов долларов и должны были заплатить налог с этой суммы в Швеции, потому что налог нужно было заплатить, когда RSU перешли в собственность, хотя тогда их нельзя было продать. Но сейчас их акции стоят примерно треть от той суммы, с которой они заплатили налог! Так что, если стоимость компании не вырастет, они понесут убытки.

А с 2020 года все повышения и бонусы включали в себя обязательную составляющую в виде RSU — и налог, который взимался при передаче RSU. Как мы писали в 2022 году в подробном материале «Увольнения в Klarna»:

«В 2020 году сотрудники не получали денежных премий. С 2021 года премии и повышение зарплаты выплачивались как в виде RSU, так и в денежном эквиваленте. Руководство сообщило об этом, так как хотело, чтобы каждый владел частью компании. Разница в том, что большинство частных стартапов выплачивают сотрудникам денежные премии и акции в качестве бонусов.В 2020 году повышения и бонусы выплачивались только в виде RSU, а не наличными. Начиная с 2021 года система стала более сложной. Бонусы по-прежнему выплачиваются в виде RSU. Что касается повышений, то для каждого уровня была установлена целевая сумма RSU. Пока эта сумма не была достигнута, повышение делилось поровну между наличными и RSU.Например, возьмём сотрудника, которому повысили зарплату на 8%, а его целевая доля составляет 5%. Он получит 4% в виде RSU и 4% наличными. Сотрудник, которому повысили зарплату на 11%, получит 5% в виде RSU (достигнув лимита) и 6% наличными.

Это напоминание о том, что выпуск акций не гарантирует автоматического дохода, даже в случае IPO!

Тем не менее для всех, кто присоединился к компании до 2021 года или после 2022 года, IPO означает, что их акции будут чего-то стоить и их можно будет продать после окончания периода блокировки, который обычно длится 6 месяцев после листинга. Поздравляем всех сотрудников Klarna, особенно тех, кто получит выгоду от своих акций!

Meta закрывает небольшие инженерные офисы в Европе?

Я слышал от инженеров Meta, что коллегам из небольших офисов по всей Европе предлагают переехать в лондонский офис (Великобритания) или в офис в США (Менло-Парк, Нью-Йорк, Сиэтл). Инженерам, которые предпочли бы не переезжать, в конечном счёте придётся уйти из компании. Один из таких городов — Амстердам, где инженерам нужно либо перевестись в другой отдел, либо найти работу в другом месте.

До 2020 года у Meta были инженерные офисы только в нескольких центрах. В 2020–2022 годах компания активно нанимала сотрудников за пределами этих центров, в том числе полностью удалённых инженеров в Европе. Похоже, что последнее изменение в политике — это возврат к условиям, существовавшим до 2020 года, когда инженерные ресурсы были ограничены крупными инженерными центрами.

Я наблюдал за тем, как другие компании закрывали небольшие инженерные офисы в Европе, и Uber — хороший тому пример. Гигант в сфере совместных поездок закрыл свои офисы в Литве (Вильнюс) и Болгарии (София) и предложил инженерам переехать в Амстердам, где находится европейская инженерная штаб-квартира Uber.

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

VS Code предпочитает Claude Sonnet ChatGPT

Microsoft является крупным инвестором в OpenAI и исторически предпочитала ChatGPT в качестве своей модели программирования. Сейчас это также меняется, The Verge Сообщает:

«Согласно внутренним тестам, Claude Sonnet 4 является рекомендуемой моделью для GitHub Copilot», — сообщила Джулия Льюсон, глава подразделения разработчиков Microsoft, во внутреннем электронном письме в июне.

Для Microsoft имеет смысл использовать лучшую модель искусственного интеллекта: год назад компания не решалась добавить поддержку Sonnet в GitHub Copilot, и именно тогда популярность Cursor резко возросла, отчасти благодаря Sonnet.

Microsoft предлагает объективно лучшую модель вместо той, в которую она инвестирует напоминает мне о решении компании выпустить Microsoft Office для iPad в 2014 году — после того, как выпуск был отложен на несколько лет из-за опасений, что он отнимет долю рынка у собственного планшета Microsoft Surface, который в то время работал на Windows 8. Это была большая победа для Office (и iPad) и небольшое поражение для Windows 8 и Surface. Таким образом, последняя разработка — это большая победа для VS Code и Claude и небольшая потеря для OpenAI. Тем временем создатель Sonnet, компания Anthropic, продолжает укреплять свои позиции в качестве лаборатории ИИ, ориентированной на разработчиков.

Bending Spoons покупает Vimeo

Bending Spoons — довольно известная итальянская технологическая компания с необычной бизнес-моделью. Они покупают известные компании Кремниевой долины, испытывающие трудности, и пытаются сделать их прибыльными. Компания владеет Evernote, Meetup и StreamYard, а с прошлой недели к этому списку можно добавить и Vimeo, после того как Bending Spoons заплатила $1,38 млрд за публичную компанию, занимающуюся видеохостингом.

Компания Bending Spoons известна тем, что увольняет большинство сотрудников приобретаемых компаний и переводит разработку программного обеспечения на собственные силы. Кроме того, они не стесняются повышать цены.

Но если присмотреться, становится интересно. Я поговорил с командой Bending Spoons в подкасте Pragmatic Engineer и узнал, что после покупки Evernote они провели масштабную миграцию инфраструктуры, потому что существующее приложение работало очень неэффективно и не было оптимизировано во многих аспектах:

«Первое, что мы заметили, когда приобрели Evernote, — это то, что основной причиной всех остальных проблем, которые мы выявили, была очень старая кодовая база с многолетним техническим долгом.Одной из особенностей было то, что он был перенесён с физических серверов в облако. И этот перенос, конечно же, был осуществлён при поддержке поставщика облачных услуг. Перенос осуществлялся в индивидуальном порядке, то есть переноса на самом деле не было. Evernote не перестраивал свою инфраструктуру, чтобы сделать её облачной. В результате мы получили огромный монолит на Java 11.Evernote работал на 750 виртуальных машинах в Google Cloud, но все они были настроены вручную. Данные пользователей распределялись между всеми этими машинами. Но это распределение не было результатом тщательного анализа, а значит, на некоторые машины приходилась более высокая нагрузка, чем на другие. Это также требовало большого количества ручных операций по обслуживанию».

Bending Spoons привели в порядок инфраструктуру:

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

Компания Bending Spoons перешла на архитектуру микросервисов, а также отказалась от опроса серверов клиентами Evernote — довольно расточительного подхода — в пользу коммуникации на основе событий.

Если миграция Evernote хоть как-то намекает на то, что может произойти с Vimeo, то, по моим прогнозам, команда разработчиков Bending Spoons тщательно проанализирует предыдущие решения в области инфраструктуры.

Перевод: https://newsletter.pragmaticengineer.com/p/the-pulse-146

Теория ограничений (ТО) Элияху Голдратта

2025-11-03T07:54:42.470Z

Теория ограничений - это методология улучшения процессов, которая подчеркивает важность выявления "системного ограничения" или узкого места.

Используя это ограничение, организации могут достигать своих финансовых целей, обеспечивая при этом своевременную доставку в полном объеме (OTIF) клиентам, избегая перебоев в цепочке поставок, сокращая время выполнения заказа и т.д.

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

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

Ограничения — аналогия с цепью

Ни одна цепь не может быть прочнее своего самого слабого звена. Точно так же каждая система должна иметь ограничение, которое ограничивает её производительность. Мы знаем это, потому что ни одна система не может производить бесконечно много... например, вы никогда не найдёте компанию с бесконечными продажами или прибылью!

Обратите внимание, что в любой цепи есть ОДНО (и только одно) самое слабое звено. Укрепление других звеньев никогда не повысит общую прочность цепи, потому что они не являются самыми слабыми. На самом деле укрепление не самого слабого звена, скорее всего, ПОНИЗИТ общую прочность цепи из-за дополнительного веса.

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

Что, если мы приложим усилия, чтобы более полно использовать самое слабое звено? Мы могли бы задействовать его в большей степени, сократив время простоя цепи или подчинив ей всё остальное, избегая резких рывков, которые создают дополнительную нагрузку при полной загрузке. Как только мы научимся эффективно использовать цепь, мы сможем начать искать способы укрепить само слабое звено. Даже небольшое увеличение прочности самого слабого звена может существенно повлиять на общую прочность цепи.

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

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

Проверка знаний

Многие люди переоценивают свои знания в области теории ограничений. Уделите немного времени тому, чтобы проверить, насколько хорошо вы её понимаете.

Представьте, что вы отвечаете за управление описанным ниже процессом. Каждая буква обозначает отдельный подпроцесс, например продажи, проектирование, этап 1 производства, этап 2 производства, выставление счетов клиентам, сбор платежей и т.д. На минутку представьте себе простой последовательный процесс, с которым вы знакомы, например в сфере производства или услуг, или даже государственный процесс, например выдачу водительских прав.

Вам предоставлен приведённый выше отчёт с подробным описанием общей эффективности каждого подпроцесса.

На чём вы СОСРЕДОТОЧИТЕ большую часть своего внимания?
Чему вообще не уделите НИКАКОГО внимания?

Какой подпроцесс вы выбрали...?

Были ли у вас какие-либо вопросы или информация, которой, по вашему мнению, не хватало?

Сразу после того, как вы решите, на чём сосредоточить внимание, вы получите отчёт, в котором будет указана максимальная производительность каждого подпроцесса.

Замените на любое значение производительности, подходящее для выбранного вами процесса.

Например, тонны в час.

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

Что такое теория ограничений?

Теория ограничений (ТО) в том виде, в котором она была разработана доктором Элияху Голдраттом, была представлена в его знаменитой книге «Цель.» С годами ТО стала включать в себя множество различных концепций:

Пять шагов к концентрации — первоначальное выражение TOC, которое будет подробно объяснено в этой статье
Сквозной учёт – надёжный метод измерения операций, который устраняет некоторые проблемные искажения в практике финансового учёта, позволяя точно оценивать прогресс в достижении цели и принимать более эффективные решения
TOC «Мыслительные процессы и философия» — набор инструментов для решения проблем и предположений, которые помогают совершать прорывы в самых разных ситуациях и условиях. Они помогают принимать решения:

Что изменить?
На что поменять?
Как вызвать изменения?

Приложения TOC — это усовершенствованные стратегии и тактики, применимые в конкретных отраслях или средах, таких как S-DBR для дискретного производства на заказ, управление больницами, быстрое пополнение запасов для дистрибуции и розничной торговли, а также критическая цепь для проектов. Эти методологии, разработанные с использованием процессов мышления TOC, выходят за рамки данной статьи, но в соответствующих местах будут приведены ссылки, чтобы вы могли узнать больше.

Несмотря на своё название, «теория ограничений» чрезвычайно практична, поскольку помогает находить простые эффективные решения реальных проблем.

Обеспечение исключительного повышения производительности

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

Эти результаты были получены в разных регионах и отраслях. Во многих случаях они представляют собой частичную реализацию инструментов TOC, и нам остаётся только гадать, какого эффекта можно было бы добиться при использовании полного набора приложений.

Теория ограничений работает и в сфере услуг

Невероятная популярность бизнес-романа доктора Голдратта «Гоал» (действие которого происходит в производственной компании) заставила некоторых поверить в то, что теория ограничений применима в первую очередь к производственной среде.

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

Они успешно применяются в таких отраслях, как производство тяжёлого капитального оборудования, розничная торговля, банковское дело, производство товаров повседневного спроса, логистика, трудоустройство, горнодобывающая промышленность, здравоохранение и т.д.

TOC также применяется в некоммерческих организациях, включая начальное образование, религиозные организации, вооружённые силы, судебную систему и другие, с не менее впечатляющими результатами.

Обзор приложений TOC

Эли Голдратт разработал специальные приложения и инструменты для решения конкретных отраслевых задач:

Доступность в сфере поставок и дистрибуции: надёжное и быстрое пополнение запасов
Наличие на складе готовой продукции: упрощённая барабанно-буферная канатная система (S-DBR) для производства на склад или на заказ
Производство в срок: упрощённая барабанно-буферно-канатная система (S-DBR) для изготовления на заказ
Своевременная сборка: Полный комплект
Проекты, завершённые в срок: управление проектами по методу критической цепи
Перепрофилирование инфекционных отделений: нехватка денежных средств
Растущий спрос со стороны клиентов: Нежелательный эффект, «мафиозное предложение», от которого невозможно отказаться
Снижение рисков, связанных со спросом: сегментация клиентов
Вызывающее изменение: 6 уровней сопротивления/вовлечённости
Принятие обоснованных финансовых решений: операционные показатели T/I/OE

Нажмите здесь, чтобы узнать больше о приложениях TOC.

Узнать больше

Бизнес-роман доктора Голдратта «Цель» — это оригинальная классика, с которой началось движение TOC. Она станет хорошей отправной точкой для всех, кто хочет изучить эту область, особенно для тех, кто работает в традиционном производственном секторе.

Ниже приведён тщательно отобранный список ресурсов, которые помогут вам найти лучшие способы узнать больше по каждой из перечисленных тем.

Перевод: https://www.tocinstitute.org/theory-of-constraints.html

Микросервисы

2025-11-03T07:14:16.052Z

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

Авторы: James Lewis, Martin Fowler

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

Вкратце, микросервисная архитектура 1 — это подход к разработке единого приложения в виде набора небольших сервисов, каждый из которых работает в отдельном процессе и взаимодействует с другими с помощью облегчённых механизмов, часто через API HTTP-ресурсов. Эти сервисы создаются на основе бизнес-возможностей и могут быть развёрнуты независимо друг от друга с помощью полностью автоматизированных механизмов развёртывания. Централизованное управление этими сервисами сведено к минимуму. Они могут быть написаны на разных языках программирования и использовать разные технологии хранения данных.

В моём Руководстве по ресурсам для микросервисов вы найдёте ссылки на лучшие статьи, видео, книги и подкасты о микросервисах.

Чтобы объяснить, что такое микросервисный стиль, полезно сравнить его с монолитным стилем: монолитное приложение представляет собой единое целое.

Корпоративные приложения часто состоят из трёх основных частей: клиентского пользовательского интерфейса (состоящего из HTML-страниц и JavaScript-кода, выполняемого в браузере на компьютере пользователя), базы данных (состоящей из множества таблиц, введённых в общую, как правило, реляционную систему управления базами данных) и серверного приложения.

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

Такой монолитный сервер — естественный подход к созданию подобной системы.

Вся логика обработки запросов выполняется в рамках одного процесса, что позволяет использовать базовые возможности языка для разделения приложения на классы, функции и пространства имён.

При должном подходе вы можете запускать и тестировать приложение на ноутбуке разработчика, а также использовать конвейер развёртывания, чтобы обеспечить надлежащее тестирование изменений и их развёртывание в рабочей среде.

Вы можете горизонтально масштабировать монолит, запустив множество экземпляров за балансировщиком нагрузки.

Монолитные приложения могут быть успешными, но люди всё чаще разочаровываются в них, особенно по мере того, как всё больше приложений переносится в облако.

Циклы изменений взаимосвязаны: изменение, внесённое в небольшую часть приложения, требует перестройки и развёртывания всего монолита.

Со временем становится всё сложнее поддерживать хорошую модульную структуру, а значит, и вносить изменения, которые должны затрагивать только один модуль.

Масштабирование требует масштабирования всего приложения, а не его частей, которым требуется больше ресурсов.

Рис. 1. Монолиты и микросервисы

Эти проблемы привели к появлению микросервисной архитектуры: приложения стали создаваться в виде наборов сервисов. Помимо того, что сервисы можно развертывать и масштабировать независимо друг от друга, каждый из них представляет собой отдельный модуль, что позволяет писать разные сервисы на разных языках программирования. Кроме того, ими могут управлять разные команды.

Мы не утверждаем, что микросервисный стиль является чем-то новым или инновационным. Его корни уходят как минимум в принципы разработки Unix.

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

Особенности микросервисной архитектуры

Мы не можем сказать, что существует формальное определение архитектурного стиля микросервисов, но мы можем попытаться описать то, что, по нашему мнению, является общими характеристиками архитектур, которые можно отнести к этому стилю. Как и в случае с любым определением, в котором описываются общие характеристики, не все архитектуры микросервисов обладают всеми этими характеристиками, но мы ожидаем, что большинство архитектур микросервисов будут обладать большинством этих характеристик. Хотя мы, авторы, являемся активными участниками этого довольно разрозненного сообщества, мы хотим попытаться описать то, что мы видим в нашей собственной работе и в аналогичных проектах известных нам команд. В частности, мы не предлагаем какого-либо определения, которому нужно следовать.

Компонентизация с помощью Сервисов

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

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

В микросервисных архитектурах используются библиотеки, но основной способ компоновки собственного программного обеспечения заключается в разделении на сервисы. Мы определяем библиотеки как компоненты, которые подключаются к программе и вызываются с помощью вызовов функций в памяти, в то время как сервисы — это внешние компоненты, которые взаимодействуют с помощью таких механизмов, как запрос веб-сервиса или удалённый вызов процедуры. (Это понятие отличается от понятия сервисного объекта во многих объектно-ориентированных программах)

Одна из основных причин использования сервисов в качестве компонентов (а не библиотек) заключается в том, что сервисы можно развертывать независимо друг от друга. Если у вас есть приложение 4, состоящее из нескольких библиотек в одном процессе, то при изменении любого компонента придется заново развертывать все приложение. Но если это приложение разделено на несколько сервисов, то при изменении одного сервиса потребуется заново развернуть только его. Это не абсолютное правило, некоторые изменения затрагивают интерфейсы сервисов, что требует определённой координации, но цель хорошей микросервисной архитектуры — свести эти изменения к минимуму за счёт согласованных границ сервисов и механизмов развития в контрактах на обслуживание.

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

У использования подобных сервисов есть свои недостатки. Удалённые вызовы обходятся дороже, чем вызовы внутри процесса, поэтому удалённые API должны быть более грубыми, что часто затрудняет их использование. Если вам нужно изменить распределение обязанностей между компонентами, сделать это будет сложнее, если вы пересекаете границы процессов.

В первом приближении можно заметить, что сервисы сопоставляются с процессами среды выполнения, но это лишь первое приближение.

Сервис может состоять из нескольких процессов, которые всегда разрабатываются и развертываются вместе, например процесс приложения и база данных, которая используется только этим сервисом.

Организация на основе бизнес-возможностей

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

Когда команды разделены по такому принципу, даже простые изменения могут привести к тому, что проект будет затрагивать несколько команд, а его реализация потребует времени и утверждения бюджета.

Умная команда оптимизирует этот процесс и выберет меньшее из двух зол — просто перенесёт логику в то приложение, к которому у неё есть доступ.

Другими словами, логика повсюду. Это пример закона Конвея в действии.

Любая организация, разрабатывающая систему (в широком смысле), создаст проект, структура которого будет копией коммуникационной структуры организации.

— Мелвин Конвей, 1968

Рис. 2. Закон Конвея в действии

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

Рис. 3. Границы сервисов, усиленные границами команд

Одна из компаний, организованных таким образом, — это www.comparethemarket.com. Межфункциональные команды отвечают за создание и поддержку каждого продукта, а каждый продукт разделён на несколько отдельных сервисов, взаимодействующих через шину сообщений.

Большие монолитные приложения также всегда можно модульизировать с учетом бизнес-возможностей, хотя это не обычный случай. Certaкроме того, мы бы настоятельно призвали большую команду, создающую монолитное приложение, разделиться по бизнес-направлениям. Впроблема, которую мы видели здесь, заключается в том, что они, как правило, организованы вокруг слишком многих контекстов. Если чеe monolith охватывает многие из этих модульных границ, и отдельным членам команды может быть трудно поместить их в свою кратковременную память. Кроме того, мы видим, что модульные линии требуют строгой дисциплины. Неизбежно более чёткое разделение, требуемое для сервисных компонентов, упрощает соблюдение границ команды.

Насколько велик микросервис?

Хотя «микросервис» стал популярным названием для этого архитектурного стиля, оно приводит к нежелательному акценту на размере сервиса и спорам о том, что считать «микро». В беседах с разработчиками микросервисов мы видим, что сервисы бывают разных размеров. Самые крупные сервисы соответствуют понятию Amazon о команде из двух пицц (т. е. вся команда может прокормиться двумя пиццами), то есть не более чем о дюжине человек. В меньших масштабах мы видели системы, в которых команда из полудюжины человек поддерживала полдюжины сервисов.

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

Продукты, а не Проекты

В большинстве случаев разработки приложений, с которыми мы сталкиваемся, используется проектная модель: цель состоит в том, чтобы создать программное обеспечение, которое затем считается завершённым. После завершения работы программное обеспечение передаётся организации, занимающейся его обслуживанием, а проектная команда, которая его создала, распускается.

Сторонники микросервисов, как правило, избегают этой модели, предпочитая вместо этого идею о том, что команда должна владеть продуктом на протяжении всего его жизненного цикла. Источником вдохновения для этого подхода послужила идея Amazon о том, что «вы создаёте, вы и управляете», где команда разработчиков берёт на себя полную ответственность за программное обеспечение в рабочей среде. Это позволяет разработчикам ежедневно наблюдать за тем, как их программное обеспечение работает в рабочей среде, и чаще взаимодействовать с пользователями, поскольку им приходится брать на себя хотя бы часть обязанностей по поддержке.

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

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

Умные конечные точки и тупые каналы

При создании коммуникационных структур между различными процессами мы сталкивались со многими продуктами и подходами, в которых особое внимание уделялось интеллектуальным возможностям самого механизма коммуникации. Хорошим примером этого является корпоративная сервисная шина (ESB), продукты которой часто включают в себя сложные средства для маршрутизации сообщений, организации процессов, преобразования и применения бизнес-правил.

Сообщество разработчиков микросервисов предпочитает альтернативный подход: умные конечные точки и «глупые» каналы. Приложения, созданные на основе микросервисов, должны быть максимально независимыми и согласованными. Они содержат собственную логику предметной области и действуют скорее как фильтры в классическом понимании Unix: получают запрос, применяют соответствующую логику и выдают ответ. Они управляются с помощью простых протоколов REST, а не сложных протоколов, таких как WS-Choreography, BPEL или оркестрация с помощью центрального инструмента.

Чаще всего используются два протокола: HTTP-запросы с ответами и API ресурсов, а также облегчённый обмен сообщениями. Без первого не обойтись.

Будь в сети, а не за её пределами

— Иэн Робинсон

Команды, работающие с микросервисами, используют принципы и протоколы, на которых построена всемирная паутина (и в значительной степени Unix). Часто используемые ресурсы можно кэшировать без особых усилий со стороны разработчиков или администраторов.

Второй распространённый подход — обмен сообщениями через облегчённую шину сообщений. Выбранная инфраструктура, как правило, «глупая» (в том смысле, что она выступает только в роли маршрутизатора сообщений). Простые реализации, такие как RabbitMQ или ZeroMQ, не делают ничего, кроме обеспечения надёжной асинхронной структуры. Вся «умность» сосредоточена в конечных точках, которые создают и получают сообщения, то есть в сервисах.

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

Микросервисы и SOA

Когда мы говорим о микросервисах, часто возникает вопрос, не является ли это просто сервис-ориентированной архитектурой (SOA), которую мы видели десять лет назад. В этом есть доля правды, потому что стиль микросервисов очень похож на то, за что выступали некоторые сторонники SOA. Проблема, однако, в том, что SOA означает слишком много разных вещей, и в большинстве случаев то, что мы называем «SOA», существенно отличается от стиля, который мы здесь описываем, обычно из-за того, что основное внимание уделяется ESB, используемым для интеграции монолитных приложений.

В частности, мы видели множество неудачных попыток внедрить сервисную ориентацию — от стремления скрыть сложность в ESB 5 до провальных многолетних инициатив, которые стоили миллионы и не принесли никакой пользы, а также централизованных моделей управления, которые активно препятствовали изменениям. Из-за этих проблем иногда трудно увидеть что-то за их пределами.

Безусловно, многие методы, используемые в сообществе микросервисов, выросли из опыта разработчиков, интегрирующих сервисы в крупных организациях. Примером этого является шаблон Tolerant Reader. Использование веб-технологий и простых протоколов — ещё один подход, основанный на этом опыте, — реакция на центральные стандарты, которые достигли такой сложности, что, откровенно говоря, дух захватывает. (Всякий раз, когда вам нужна онтология для управления вашими онтологиями, вы понимаете, что у вас серьёзные проблемы.)

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

Децентрализованное Управление

Одним из последствий централизованного управления является тенденция к стандартизации на основе единых технологических платформ. Опыт показывает, что такой подход ограничивает возможности: не каждая проблема — это гвоздь, а не каждое решение — молоток. Мы предпочитаем использовать подходящий инструмент для конкретной задачи, и хотя монолитные приложения могут в определённой степени использовать преимущества разных языков, это не так распространено.

Разделяя компоненты монолита на сервисы, мы получаем выбор при создании каждого из них. Выхотите использовать Node. js для создания простой страницы с отчетами? Делайте это. C++ дляособо сложного компонента, работающего в режиме, близком к реальному времени? Отлично. Выхотите заменить базу данных на другой тип, который лучше подходит для чтения данных одним из компонентов? У нас естьтехнология для его пересоздания.

Конечно, если вы можете что-то сделать, это не значит, что вы должны это делать, но разделение системы таким образом означает, что у вас есть такая возможность.

Команды, создающие микросервисы, тоже предпочитают другой подход к стандартам. Вместо того чтобы использовать набор определённых стандартов, записанных где-то на бумаге, они предпочитают создавать полезные инструменты, которые другие разработчики могут использовать для решения проблем, схожих с теми, с которыми сталкиваются они. Эти инструменты обычно извлекаются из реализаций и становятся доступными для более широкой группы, иногда, но не исключительно, с использованием внутренней модели с открытым исходным кодом. Теперь, когда git и github стали де-факто предпочтительной системой контроля версий, практики с открытым исходным кодом становятся всё более распространёнными внутри компаний.

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

Для сообщества разработчиков микросервисов накладные расходы особенно нежелательны. Это не значит, что сообщество не ценит контракты на обслуживание. Совсем наоборот, их, как правило, гораздо больше. Просто они ищут другие способы управления этими контрактами. Такие шаблоны, как Tolerant Reader и контракты, ориентированные на потребителя, часто применяются в микросервисах. Это помогает сервуконтракты ice развиваться независимо. Выполнение минусовконтракты, основанные на umer, как часть вашей сборки повышают доверие и обеспечивают быструю обратную связь о том, функционируют ли ваши службы. Действительно, мы знаем из команды в Австралии, которая занимается созданием новых сервисов с помощью контрактов, ориентированных на потребителя. Они используют простые инструменты, которые позволяют им определять контракт на услугу. Это становится part автоматизированной сборки еще до того, как будет написан код для нового сервиса. Сервис затем разрабатывается только до той степени, в которой он соответствует контракту. Это элегантный подход, позволяющий избежать дилеммы «YAGNI»9 при разработке нового программного обеспечения. Эти методы и инструменты, которые развиваются вокруг них, снижают потребность в централизованном управлении контрактами за счёт уменьшения временной связи между сервисами.

Возможно, апогеем децентрализованного управления является принцип «создай и запусти», популяризированный Amazon. Команды отвечают за все аспекты создаваемого ими программного обеспечения, включая его круглосуточную эксплуатацию. Передача такого уровня ответственности определённо не является нормой, но мы видим, что всё больше компаний перекладывают ответственность на команды разработчиков. Netflix — ещё одна организация, которая приняла этот принцип10. Когда вас будят в 3 часа ночи с помощью пейджера, это, безусловно, мощный стимул сосредоточиться на качестве кода. Эти идеи настолько далеки от традиционной модели централизованного управления, насколько это вообще возможно.

Много языков, много вариантов

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

Децентрализованное управление данными

Децентрализация управления данными проявляется по-разному.На самом абстрактном уровне это означает, что концептуальная модель мира в разных системах будет отличаться. Это распространённая проблема при интеграции в рамках крупного предприятия: представление о клиенте в отделе продаж будет отличаться от представления в отделе поддержки. Некоторые объекты, которые в отделе продаж называются клиентами, могут вообще не отображаться в отделе поддержки. Те, что отображаются, могут иметь разные атрибуты и (что ещё хуже) общие атрибуты с немного отличающейся семантикой.

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

Помимо децентрализации решений, касающихся концептуальных моделей, микросервисы также децентрализуют решения, связанные с хранением данных.
В то время как монолитные приложения предпочитают использовать единую логическую базу данных для хранения постоянных данных, предприятия часто предпочитают использовать единую базу данных для целого ряда приложений. Многие из этих решений обусловлены коммерческими моделями поставщиков в отношении лицензирования. Микросервисы предпочитают, чтобы каждый сервис управлял собственной базой данных, будь то разные экземпляры одной и той же технологии баз данных или совершенно разные системы баз данных. Такой подход называется Polyglot Persistence. Вы можете использовать многоязычную персистентность в монолитной архитектуре, но чаще она встречается в микросервисах.

Децентрализация ответственности за данные между микросервисами влияет на управление обновлениями. Обычно для управления обновлениями используются транзакции, гарантирующие согласованность при обновлении нескольких ресурсов. Этот подход часто используется в монолитных системах.

Использование подобных транзакций помогает обеспечить согласованность, но накладывает значительные ограничения по времени, что проблематично при работе с несколькими сервисами. Распределённые транзакции, как известно, сложно реализовать, и, как следствие, в микросервисных архитектурах делается акцент на бестранзакционной координации между сервисамис явным признанием того, что согласованность может быть лишь потенциальной, а проблемы решаются с помощью компенсирующих операций.

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

Проверенные в боях стандарты и обязательные стандарты

Парадоксально, но команды, работающие с микросервисами, как правило, избегают жёстких стандартов, установленных группами по корпоративной архитектуре, но с радостью используют и даже пропагандируют открытые стандарты, такие как HTTP, ATOM и другие микроформаты.

Ключевое различие заключается в том, как разрабатываются стандарты и как они применяются. Стандарты, разрабатываемые такими группами, как IETF, становятся стандартами только тогда, когда в мире существует несколько их реализаций, которые часто появляются в результате успешных проектов с открытым исходным кодом.

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

Автоматизация инфраструктуры

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

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

Рис. 5. Базовый конвейер сборки

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

Монолитное приложение будет создано, протестировано и запущено в этих средах без особых проблем. Оказывается, если вы вложили средства в автоматизацию процесса запуска монолита в производство, то развертывание других приложений уже не кажется таким пугающим. Помните, что одна из целей непрерывной доставки — сделать развертывание скучным, поэтому не имеет значения, одно это приложение или три, если оно все равно скучное.

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

Рис. 6. Развертывание модулей часто отличается

Сделайте так, чтобы поступать правильно было легко

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

Конструкция на случай отказа

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

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

Поскольку сервисы могут выйти из строя в любой момент, важно иметь возможность быстро обнаруживать сбои и, по возможности, автоматически восстанавливать работу сервиса. Микросервисные приложения уделяют большое внимание мониторингу приложения в режиме реального времени, проверяя как архитектурные элементы (например, сколько запросов в секунду получает база данных), так и важные для бизнеса показатели (например, сколько заказов в минуту поступает). Семантический мониторинг может обеспечить систему раннего оповещения о сбоях, которая побуждает команды разработчиков к дальнейшим действиям и расследованию.

Это особенно важно для архитектуры микросервисов, поскольку предпочтение, отдаваемое микросервисами хореографии и совместной работе над событиями, приводит к эмерджентному поведению. Хотя многие эксперты высоко оценивают ценность эмерджентного поведения, правда в том, что иногда оно может быть нежелательным. Мониторинг необходим для быстрого выявления нежелательного эмерджентного поведения, чтобы его можно было исправить.

Монолиты могут быть такими же прозрачными, как микросервисы, — на самом деле они должны быть такими. Разница в том, что вам обязательно нужно знать, когда сервисы, работающие в разных процессах, отключаются. В случае с библиотеками, работающими в рамках одного процесса, такая прозрачность вряд ли будет полезна.

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

Синхронные вызовы считаются вредными

Каждый раз, когда у вас происходит несколько синхронных вызовов между сервисами, вы сталкиваетесь с мультипликативным эффектом простоев. Проще говоря, это когда простой вашей системы становится результатом простоев отдельных компонентов. Вам предстоит сделать выбор: сделать вызовы асинхронными или управлять простоями. На сайте www.guardian.co.uk на новой платформе действует простое правило: один синхронный вызов на запрос пользователя, а в Netflix при редизайне API платформы асинхронность была встроена в структуру API.

Эволюционный Дизайн

Специалисты по микросервисам, как правило, имеют опыт эволюционного проектирования и рассматривают декомпозицию сервисов как дополнительный инструмент, позволяющий разработчикам приложений контролировать изменения в своих приложениях без замедления процесса. Контроль изменений не обязательно означает сокращение количества изменений — при правильном подходе и использовании нужных инструментов можно вносить частые, быстрые и хорошо контролируемые изменения в программное обеспечение.

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

Веб-сайт The Guardian — хороший пример приложения, которое было спроектировано и создано как монолитное, но развивается в направлении микросервисов. Монолит по-прежнему является основой веб-сайта, но разработчики предпочитают добавлять новые функции, создавая микросервисы, которые используют API монолита. Такой подход особенно удобен для функций, которые по своей сути являются временными, например для специализированных страниц, посвященных спортивным событиям. Такую часть веб-сайта можно быстро создать с помощью языков быстрой разработки и удалить после завершения мероприятия. Мы видели подобные подходы в финансовом учреждении, где новые услуги добавляются для удовлетворения потребностей рынка, а через несколько месяцев или даже недель от них отказываются.

Этот акцент на взаимозаменяемости является частным случаем более общего принципа модульного проектирования, который заключается в том, чтобы обеспечивать модульность за счёт шаблона изменений 13. Вы хотите, чтобы элементы, которые меняются одновременно, находились в одном модуле. Части системы, которые меняются редко, должны находиться в разных сервисах, чем те, которые в настоящее время претерпевают значительные изменения. Если вы постоянно меняете два сервиса одновременно, это признак того, что их следует объединить.

Включение компонентов в сервисы предоставляет возможность для более детального планирования выпуска. При использовании monolith любые изменения требуют полной сборки и развертывания всего приложения. Однако в случае с микросервисами вам нужно повторно развернуть только измененные вами службы. Это может упростить и ускорить процесс выпуска. Недостатком является то, что вам приходится беспокоиться о том, что изменения в одной услуге нанесут ущерб ее потребителям. Традиционный подход к интеграции заключается в том, чтобы попытаться решить эту проблему с помощью управления версиями, но в мире микросервисов предпочитают использовать управление версиями только в крайнем случае. Мы можем избежать большого количества операций по управлению версиями, если будем проектировать сервисы так, чтобы они были максимально устойчивы к изменениям у поставщиков.

За микросервисами будущее?

Наша главная цель при написании этой статьи — объяснить основные идеи и принципы микросервисов. Мы потратили время на написание этой статьи, потому что считаем, что архитектурный стиль микросервисов — это важная идея, заслуживающая серьёзного рассмотрения при создании корпоративных приложений. Недавно мы создали несколько систем в этом стиле и знаем других разработчиков, которые используют и предпочитают этот подход. Среди тех, кто, насколько нам известно, в той или иной степени является первопроходцем в области архитектурного стиля, — Amazon, Netflix, The Guardian, Цифровая служба правительства Великобритании, realestate.com.au, Forward и comparethemarket.com. На конференциях в 2013 году было много примеров компаний, которые переходили на микросервисную архитектуру, включая Travis CI. Кроме того, существует множество организаций, которые уже давно используют то, что мы называем микросервисами, но никогда не используют это название. (Часто это называют сервис-ориентированной архитектурой, хотя, как мы уже говорили, сервис-ориентированная архитектура имеет множество противоречивых форм.

Однако, несмотря на этот положительный опыт, мы не утверждаем, что микросервисы — это будущее архитектуры программного обеспечения. Хотя наш опыт работы с микросервисами по сравнению с монолитными приложениями положителен, мы понимаем, что прошло недостаточно времени, чтобы делать окончательные выводы.

Часто истинные последствия ваших архитектурных решений становятся очевидными лишь спустя несколько лет после того, как вы их приняли. Мы видели проекты, в которых хорошая команда, стремящаяся к модульности, создавала монолитную архитектуру, которая с годами приходила в упадок. Многие считают, что с микросервисами такое происходит реже, поскольку границы сервисов чётко определены и их трудно обойти. Однако, пока мы не увидим достаточное количество систем с большим сроком эксплуатации, мы не сможем по-настоящему оценить, как развиваются микросервисные архитектуры.

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

Недостатки микросервисов

Многие команды разработчиков считают, что микросервисная архитектура превосходит монолитную. Но другие команды считают, что она снижает производительность. Как и любой архитектурный стиль, микросервисная архитектура имеет свои преимущества и недостатки. Чтобы сделать правильный выбор, нужно понимать их и учитывать особенности вашего контекста.

Мартин Фаулер

Другая проблема заключается в том, что если компоненты не взаимодействуют друг с другом должным образом, то всё, что вы делаете, — это переносите сложность из одного компонента в другие. Это не просто перемещение сложности, а перенос её в менее очевидное и более сложное для контроля место. Легко подумать, что всё в порядке, когда смотришь на внутреннюю часть небольшого простого компонента, не замечая беспорядочных связей между сервисами.

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

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

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

Перевод: https://martinfowler.com/articles/microservices.html

Как на самом деле работает RPC

2025-10-31T08:12:39.580Z

Что такое RPC? Разбираемся в удалённых вызовах процедур для микросервисов.

Как сотни внутренних сервисов таких компаний, как Netflix или Google, взаимодействуют друг с другом? И как это происходит миллионы раз в минуту?

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

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

И самое главное, он должен обеспечивать удобство для разработчиков без ущерба для производительности.

Современные приложения используют множество распределённых сервисов. Однако это создаёт серьёзную проблему:

Как добиться максимальной эффективности взаимодействия между машинами? Вызов функции через сеть должен быть таким же простым, как и локальный вызов.

Ответ: удалённый вызов процедуры (RPC). Это протокол, разработанный для высокопроизводительной внутренней коммуникации.

Вперед.

Я хочу представить Ашутоша в качестве приглашённого автора.

Он работает инженером-программистом в YouTube, ранее работал в Google Search и Microsoft Azure.

Что такое удалённый вызов процедуры

Давайте приступим!

RPC — это протокол, который позволяет вызывать функции из адресного пространства одной программы в адресном пространстве другой. Это освобождает разработчика от необходимости вручную управлять точками подключения к сети (сокетами) или преобразовывать данные в формат, пригодный для отправки (сериализацию).

Когда ваш код вызывает такую функцию, как math.sqrt(9), вас не волнует сложный алгоритм, работающий внутри математической библиотеки. Вы просто доверяете её общедоступному API и знаете сигнатуру функции.

RPC распространяет эту концепцию на всю сеть.

Клиентское приложение получает объект-заглушку — локальный прокси-сервер, который отражает API удалённого сервиса. Но его методы содержат только логику для переадресации вызова по сети. Когда вы вызываете функцию на этом объекте-заглушке, он выполняет всю сложную сетевую коммуникацию в фоновом режиме, чтобы код выполнялся на сервере.

Таким образом, вызов, подобный result = paymentService.charge(userId, amount), не обращается напрямую к платежному механизму. Вместо этого он вызывает локальный прокси-метод, который затем выполняет удаленную операцию. Благодаря этому удаленный вызов выглядит как простой вызов локальной библиотеки.

Прежде чем двигаться дальше, давайте разберемся в следующем:

Как работает Удаленный вызов процедуры

1. Клиентская заглушка (местный представитель)

Ваш код не обращается напрямую к удалённому сервису. Вместо этого он взаимодействует с заглушкой — локальным представителем, единственная задача которого — замещать удалённый сервис.

У него есть те же методы, которые вы хотите использовать, например, «.charge()”. Но его настоящая цель — запустить процесс удалённой связи.

2. Маршалинг (упаковка сообщения)

Заглушка принимает указанные вами параметры, например userId, amount, и упорядочивает их.

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

Представьте, что вы аккуратно упаковываете свои инструкции в универсальный контейнер для доставки, который может открыть любой сервер в мире. Этот формат часто представляет собой JSON или более компактный и быстрый формат, например буферы протокола.

3. Сетевое путешествие

Затем клиент отправляет это упакованное сообщение по сети на сервер, используя эффективные протоколы, такие как HTTP/2. Это «удаленная» часть вызова.

4. Скелет сервера

На сервере прослушивается «скелет». Это аналог клиентской заглушки.

Его задача — получить входящее сообщение и распаковать (или десериализовать) его. Представьте, что вы распаковываете транспортировочный контейнер и возвращаете данные в формат, понятный серверу.

Затем скелет вызывает фактический метод сервиса с этими распакованными данными.

5. Обратный путь

После того как сервер завершает свою работу, весь процесс повторяется в обратном порядке.

Скелет маршалирует возвращаемое значение, например, {success: true}. Затем отправляет его обратно по сети, а клиентская заглушка демаршалирует его.

После этого строка кода, в которой был выполнен исходный вызов, получает результат.

Далее я расскажу вам о различных сценариях сбоев RPC и способах их устранения.

Обработка ошибок при вызове удалённых процедур

В распределённой системе сеть может быть ненадёжной.

Соединения обрываются. Службы работают медленно. Происходят сбои.

Надежная реализация RPC подразумевает не только успешные вызовы, но и корректную обработку ошибок. Вот несколько стратегий:

1. Тайм-ауты (не ждите вечно)

Тайм-аут — это простой срок ожидания.

Каждый раз, когда клиент отправляет запрос, запускается таймер. Если клиент не получает ответ до истечения времени, отведённого на выполнение запроса, он прекращает попытку.

Почему это важно: без тайм-аутов ваше приложение может бесконечно ждать ответа от медленного или недоступного сервиса. Это приведет к нехватке ресурсов, таких как потоки или память, и в конечном итоге может привести к зависанию всего приложения. Тайм-ауты — это первая линия защиты клиента.

2. Повторные попытки (если первый вызов не увенчался успехом)

Многие сетевые ошибки носят временный характер: это сбой, который быстро устраняется.

Иногда сервер может отвечать слишком долго или сетевой пакет может потеряться при передаче. В таких случаях имеет смысл автоматически повторить неудачный запрос.

Важное предостережение (идемпотентность): повторные попытки могут быть опасны, если один и тот же запрос вызывает побочные эффекты при каждом выполнении. Операция является идемпотентной, если её многократное выполнение даёт тот же результат, что и однократное.

Например,

Безопасно повторять (идемпотентно): получение баланса аккаунта пользователя. Повторное выполнение не изменит состояние системы.
Повторное выполнение (не идемпотентное) может привести к списанию средств с кредитной карты пользователя. Повторное выполнение может привести к дублированию платежей.

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

3. Автоматические выключатели (защита системы)

Если сервис не работает или работает медленно, отправка дополнительных запросов только усугубит ситуацию.

Автоматический выключатель — это интеллектуальное устройство, которое предотвращает подобные ситуации.

Если клиент замечает, что многие обращения к сервису завершаются неудачей, автоматический выключатель «срабатывает» и на короткое время прекращает отправку запросов к этому сервису. В этот период любые новые обращения завершаются мгновенным сбоем, а не отправляются по сети.

Почему это важно: Автоматические выключатели предотвращают каскадные сбои. Они дают сбойной службе время на восстановление. И не позволяют клиенту тратить время и ресурсы на вызовы, которые, скорее всего, завершатся неудачей.

4. Продление сроков (не начинайте работу, которую не сможете закончить)

Один пользовательский запрос часто запускает цепочку вызовов между несколькими сервисами. Например, сервис A вызывает сервис B, а сервис B вызывает сервис C.

Если общий тайм-аут исходного запроса составляет 500 мс, а служба A уже использует 300 мс. Тогда службе C нет смысла запускать задачу, которая займёт ещё 400 мс, потому что клиент уже перестанет ждать.

Распространение крайнего срокаисправляет эту проблему, передавая оставшийся срок выполнения при каждом вызове. Таким образом, каждый сервис знает, сколько времени у него осталось, и может решить, успеет ли он выполнить свою часть работы до истечения срока.

Почему это важно: Такой подход позволяет избежать лишней работы и обеспечивает быстродействие и отзывчивость системы. Сервисы могут «быстро завершать работу» вместо того, чтобы выполнять длительные операции для запроса, который уже не имеет значения.

Как и любая технология, RPC не идеальна. У неё есть свои сильные стороны, но есть и недостатки, на которые следует обратить внимание. Продолжим!

RPC: хорошее, плохое и ужасное

Преимущества

Простая модель программирования: вы можете вызывать удалённые функции так же, как и локальные, что делает ваш код чище и проще.
Высокая производительность: RPC использует компактные двоичные форматы, которые быстро обрабатываются компьютерами.
Строгая типизация: поскольку обе стороны соблюдают строгие правила, ошибки часто выявляются на ранней стадии, до того как они приведут к проблемам.
Языковая совместимость: клиент и сервер могут использовать разные языки программирования и при этом беспрепятственно взаимодействовать.

Недостатки

Тесная связь: при изменении API сервера обычно требуется обновление и клиента, что может замедлить процесс разработки.
Менее доступны для обнаружения, чем REST: Вы не сможете легко протестировать или просмотреть RPC API без специальных файлов контрактов.
Требуется специализированное оборудование: для генерации кода для клиента и сервера нужны специальные инструменты.
Абстракция скрывает сетевые реалии. Поскольку удалённые вызовы выглядят как локальные, разработчики могут забыть, что имеют дело с сетью, и не обработать должным образом тайм-ауты или ошибки.

Теперь давайте рассмотрим, как на самом деле работает RPC в реальных системах и с какими трудностями можно столкнуться при его масштабировании.

RPC в реальном мире

Использование RPC в реальных системах сопряжено с рядом практических трудностей. Вот четыре наиболее распространённые из них, с которыми приходится сталкиваться разработчикам:

1. Обнаружение сервисов (как сервисы находят друг друга?)

В современных системах серверы постоянно меняются: их добавляют, удаляют или перезапускают, часто присваивая им новые IP-адреса.

Но вы не можете просто указать местоположение сервера в своём коде. Так как же клиент узнаёт, куда отправлять запрос?

Вот тут-то и вступает в игру обнаружение сервисов.

Аналогия: Представьте, что это живой, самообновляющийся список контактов. Вам не нужно запоминать точный домашний адрес вашего друга. Вместо этого вы просто ищете его имя в списке контактов, чтобы узнать его последний адрес.

Как это работает: Центральный реестр (например, Consul или Zookeeper) отслеживает все работоспособные сервисы и их местоположение. Поэтому, когда клиент хочет связаться с платёжным сервисом, он спрашивает у реестра: «Где я могу его найти?»

Затем реестр возвращает список работоспособных серверов, и клиент выбирает один из них для отправки RPC-вызова.

2. Эволюция API (как обновлять сервисы, не нарушая работу всего остального?)

Когда сервис добавляет новую функцию, может потребоваться изменить параметры функции. Если клиенты не обновят систему сразу, это может привести к сбоям из-за тесной связи.

Решение заключается в обратной совместимости.

Аналогия: Представьте, что вы разослали форму для опроса. Вы можете спокойно добавить новый необязательный вопрос; старые формы по-прежнему будут работать. Но если вы удалите вопрос или сделаете новый вопрос обязательным, все старые формы станут недействительными.

Как это работает: RPCфреймворки, такие как gRPC, следуют строгим правилам обновления API. Например, вы можете спокойно добавлять необязательные поля, но не должны удалять или изменять существующие. Это позволяет новым версиям сервиса работать без сбоев, а старым клиентам — продолжать работать.

3. Потоковая передача (больше, чем просто запрос и ответ)

RPC не ограничивается моделью «один запрос — один ответ».

Современные фреймворки, такие как gRPC, поддерживают потоковую передачу, при которой данные непрерывно передаются между клиентом и сервером.

Аналогия: Обычный RPC-вызов похож на отправку текстового сообщения и получение одного ответа. Потоковый RPC-вызов похож на телефонный звонок или видеопоток: обе стороны могут обмениваться информацией в режиме реального времени.

Как это работает:

Потоковая передача с сервера: клиент отправляет один запрос и получает в ответ поток данных (например, при подписке на обновления в реальном времени).
Клиентская потоковая передача: клиент отправляет поток сообщений и получает один ответ (например, при загрузке большого файла).
Двунаправленная потоковая передача: и клиент, и сервер могут отправлять сообщения в любое время (например, в чате в реальном времени).

4. Обработка ошибок и коды состояния (сообщение о том, что пошло не так)

Когда что-то идёт не так, клиенту нужно больше информации, чем просто сообщение «что-то пошло не так». Тогда он сможет предпринять необходимые шаги.

Вот тут-то и появляются коды состояния.

Как и в случае с кодами состояния HTTP (404 Not Found, 403 Forbidden, 500 Internal Server Error), в RPC-фреймворках есть свои стандартизированные коды:

NOT_FOUND,
PERMISSION_DENIED,
INVALID_ARGUMENT,
UNAVAILABLE.

Как это работает: Возвращая определённый код ошибки, сервер сообщает клиенту, что делать дальше.

Повторите попытку, если услуга была временно недоступна.
Сообщите об ошибке ввода данных пользователем, если аргумент был недопустимым.
Или прекратите попытки, если проблему невозможно решить автоматически.

Теперь, когда мы увидели, как работает RPC в реальных системах, давайте сравним его с другими моделями взаимодействия.

Выбор правильного шаблона общения

RPC (gRPC, Thrift): лучше всего подходит для высокопроизводительных внутренних микросервисов.
REST: идеально подходит для общедоступных API и операций, ориентированных на ресурсы.
GraphQL: отлично подходит для получения данных, специфичных для конкретного клиента.
Очереди сообщений: идеально подходят для асинхронных, автономных рабочих процессов.

Итог

RPC скрывает большую часть сетевых деталей, но не устраняет их полностью. Вам всё равно нужно предусмотреть возможность сбоев.

В то же время gRPC с буферами протокола стал новым стандартом для быстрой и надёжной связи между внутренними сервисами.

Помните, что успешная настройка RPC зависит от поддерживающих систем. Поэтому для бесперебойной работы необходимы обнаружение сервисов, трассировка и мониторинг.

Перевод: https://newsletter.systemdesign.one/p/how-rpc-works

MCP Protocol: новый строительный блок для инструментов разработки ИИ

2025-10-31T06:26:27.189Z

Протокол Model Context, расширяющий возможности искусственного интеллекта в IDE, стремительно набирает популярность. Почему так происходит и почему нам, разработчикам, стоит обратить на это внимание?

Одной из актуальных тем на стыке инструментов для написания кода на основе ИИ и инструментов для разработчиков стал протокол MCP (Model Context Protocol), представленный в ноябре 2024 года компанией Anthropic. Он стремительно набирает популярность, а модели ИИ и инструменты для разработчиков стремятся добавить его поддержку.

Аналогия с MCP заключается в том, что это «порт USB-C для приложений ИИ», поскольку он создаёт универсальную точку расширения для подключения LLM и инструментов разработки друг к другу, а также к базам данных, системам обработки заявок и т. д. Эта концепция становится популярной и в других областях, но изначально MCP создавался как способ расширить возможности таких IDE для разработчиков, как Claude Desktop, Claude Code, VS Code, Cursor, Windsurf и других. Сегодня мы сосредоточимся на этой области и рассмотрим:

Что такое MCP? Практический пример. Раньше я использовал отдельный инструмент для запросов к базе данных в рабочем приложении. Но с помощью MCP я могу «общаться» с базой данных прямо из IDE, и это меняет всё!
Происхождение MCP. Два инженера из Anthropic — Дэвид Сориа Парра и Джастин Спар-Саммерс — решили улучшить работу Claude Desktop с помощью инструментов для разработчиков.
Чтобы понять MCP, нужно разобраться в протоколе Language Server Protocol (LSP). Многие ключевые идеи MCP основаны на подходе Microsoft, направленном на упрощение добавления поддержки языков программирования в IDE.
Архитектура MCP. Клиенты и серверы, где серверы часто представляют собой локальные процессы.
Исходный код MCP-сервера. Как простой локальный MCP-сервер помогает нам понять, как он работает.
Угрозы безопасности. При текущей реализации MCP защита выглядит удручающе слабой, и злоумышленники, скорее всего, воспользуются возможностью получить SSH-ключи и другие личные учётные данные, к которым локальные серверы MCP могут легко получить несанкционированный доступ. Эту проблему нужно решать, и быстро.
Сценарии использования в будущем. Подключение Figma к VS Code, 3D-моделирование с помощью Cursor и управление 3D-принтером из Windsurf — всё это возможно с помощью MCP. Кроме того, MCP набирает популярность за пределами IDE.

Для этой статьи я побеседовал с одним из создателей MCP, Дэвидом Сорией Паррой, инженером-программистом в Anthropic. Спасибо за информацию!

1. Что такое MCP? Практический пример

У меня есть API, который обеспечивает работу этого микросайта, где участники с годовой подпиской могут запросить промокод на 12 месяцев бесплатного доступа к Perplexity и 3 месяца бесплатного доступа к Kagi. Сайт работает на Node. js с использованием TypeScript и PostgreSQL в качестве базы данных.

Всякий раз, когда я вношу изменения в бэкенд или фронтенд и редактирую данные, я делаю две вещи:

Моя IDE с самим кодом и встроенным терминалом
Интерфейс администратора базы данных для запроса таблиц или изменения схем, если это необходимо. Я использую PgAdmin.

В моей системе открыт pgAdmin (административный интерфейс PostgreSQL)

IDE становятся все умнее благодаря функциональности LLM; Windsurf и Cursor обладают агентскими возможностями, поэтому могут предлагать изменения для нескольких файлов одновременно. Однако они не могут подключиться к моей базе данных PostgreSQL для запроса данных. Но с MCP они могут – и я тоже.

MCP расшифровывается как Model Context Protocol и является связующим звеном, позволяющим инструментам LLM, таким как IDE с улучшенным искусственным интеллектом, таким как Cursor, Windsurf и другим, получать доступ к дополнительным инструментам.

Вот как я использую подсказки LLM, чтобы сделать свою базу данных доступной в IDE. В этом примере я использовал Windsurf, но то же самое можно сделать в Cursor, Zed и VS Code.

Добавление MCP-сервера PostgreSQL в мою IDE

Для начала в разделе «Настройки» в подразделе «Cascade» (агентские возможности Windsurf) я выбираю «Добавить сервер MCP». Здесь отображается раскрывающийся список с готовыми серверами:

Windsurf поддерживает несколько MCP-серверов. Я выбрал MCP-сервер на базе PostgreSQL

Добавление означает настройку строки подключения к вашей базе данных, которая может быть локальной базой данных Postgres, работающей на вашем компьютере, или удалённой. Я использовал строку удалённого подключения для подключения к базе данных на моём сервере. После добавления подключённая база данных отображается как сервер MCP, готовый к использованию:

Добавлен сервер Postgres, и наша IDE стала ещё функциональнее

В дальнейшем при вводе любой команды в интерфейсе Cascade LLM может принять решение использовать этот сервер. Позвольте мне начать с вопроса о промокодах:

«Сколько пользователей воспользовались промокодами kagi за последние 10 дней?»

Языковая модель пытается сгенерировать SQL-сервер для получения ответа, но выдаёт имя несуществующей таблицы (что довольно типично для языковых моделей):

LLM попытался использовать мою базу данных Postgres, но неправильно назвал таблицу

Однако именно здесь начинается «волшебство», благодаря тому, что LLM выполняет дополнительные итерации, используя этот новый инструмент базы данных. LLM обращается к моему экземпляру PostgreSQL, чтобы найти правильное имя таблицы:

LLM начинает «правильно» использовать сервер PostgreSQL MCP и определяет, к каким таблицам у него есть доступ

Затем он отправляет ещё один запрос:

Ещё одна попытка, на этот раз с правильным названием

Чёрт! — названия столбцов снова неверны! Но программа запрашивает определение таблицы и быстро исправляет его:

LLM использует сервер PostgreSQL MCP для самокоррекции

Наконец-то всё стало правильно:

Правильный ответ!

Что действительно впечатляет, так это то, что процесс занял всего несколько секунд, и мне не пришлось ничего вводить. Языковая модель «вычислила» правильные названия таблиц и столбцов, имея доступ к базе данных.

Уровень LLM над PostgreSQL

Теперь, когда я добавил свою базу данных в качестве сервера MCP, я могу «общаться» со своими данными на естественном языке, а LLM преобразует их в SQL-запрос, а затем обратно в мой вопрос. Это касается не только простых вопросов с простым SQL-запросом, но и более неоднозначных.

Другие вопросы, которые я задавал:

«Наблюдался ли необычный всплеск регистраций за последние два месяца?»
«Какие подозрительные адреса электронной почты были зарегистрированы недавно? Есть какие-то закономерности?»
«В каких доменах больше всего регистраций?»
«Сколько осталось невостребованных промокодов?»

Возможность взаимодействовать с инструментами разработчика через мою IDE кажется «будущим». Не то чтобы я не мог найти ответы на вышеперечисленные вопросы без этого; я мог бы написать SQL-команды, или их серию, или небольшую программу для циклического выполнения команд и их обобщения. Однако я, скорее всего, не стал бы этого делать, потому что на ввод SQL-кода уходит время. Но поскольку я могу легко вводить вопросы, я это и сделал!

Подумайте о том, что произойдёт, если вы сможете «общаться» со своими инструментами разработчика через IDE. Например, использовать естественный язык для взаимодействия с:

Система контроля версий («Можете ли вы создать пул-реквест со всеми изменениями, кроме одного в index.ts?»)
Базы данных («Можете ли вы создать новую таблицу для регистрации пользователей? Используйте инкрементный счетчик в качестве первичного ключа и сохраняйте временную метку для каждого журнала регистрации»)
Система отслеживания заявок/ошибок («Были ли зарегистрированы ошибки, связанные с этой функцией?»)
Поставщик услуг мониторинга («Были ли за последнюю неделю всплески активности, связанные с ошибками при входе в систему или выходе из неё?»)
Система флагов функций / экспериментов («Какие флаги были полностью внедрены как минимум за неделю? Можете ли вы помочь определить их и создать PR-запрос для их удаления?»)

Использование этих инструментов из IDE упрощает работу. Кроме того, если мы можем их использовать, то и ИИ-агенты смогут, а значит, они смогут выполнять более сложные задачи.

Мне кажется, что концепция MCP может стать ещё одним шагом вперёд в повышении продуктивности разработчиков. Вероятно, это также расширит возможности ИИ-агентов, поскольку у них появятся дополнительные инструменты для решения более сложных задач. Трудно представить, что коммерческие поставщики не будут стремиться добавить серверы MCP, которые позволят клиентам проще использовать инструменты из IDE.

Как разработчики, мы сможем экспериментировать с инструментами, которые повысят нашу продуктивность. Следует отметить, что MCP всё ещё находится на ранней стадии развития и не имеет проверенных торговых площадок, поддержка MCP в IDE появилась всего несколько месяцев назад, а в реализациях MCP есть много тревожных уязвимостей, о которых мы расскажем в разделе «Угрозы безопасности» ниже.

2. Происхождение MCP

Протокол MCP был разработан двумя инженерами-программистами из Anthropic, Дэвидом Сорией Паррой и Джастином Спаром-Саммерсом. Дэвид рассказал историю создания в выпуске подкаста Latent Space.

«В июле 2024 года я работал над внутренними инструментами для разработчиков. Мы стремились дать больше возможностей сотрудникам Anthropic для глубокой интеграции с нашими моделями и максимально эффективного обучения наших моделей.Имея опыт работы с инструментами для разработки, я быстро оценил все преимущества Claude Desktop, в том числе такие функции, как Artifacts, но был разочарован ограниченным набором функций и отсутствием возможности его расширения. В то же время я выполняю свою повседневную работу в IDE. В IDE есть доступ к таким вещам, как локальная файловая система, но нет такого инструмента, как Artifacts, или чего-то подобного.Я постоянно копировал данные между Claude Desktop и IDE, и это меня раздражало. Я думал, что знаю, как создавать все интеграции, но что мне нужно сделать, чтобы эти IDE могли создавать интеграции?Если присмотреться, то можно увидеть, что проблема «интеграции ИИ» — это проблема MxN. У вас есть M приложений (например, IDE) и N интеграций.Размышляя над этой проблемой, я работал над протоколом Language Server Protocol (LSP) внутри компании, но этот проект ни к чему не привёл. Но если объединить эти идеи: LSP и недовольство интеграцией с IDE, — и дать им настояться несколько недель, то появится идея «давайте создадим какой-нибудь протокол для решения этой проблемы».

Подробнее об истории протокола MCP можно узнать из этого выпуска подкаста Latent Space.

Открытый исходный код протокола MCP

Дэвид объединился с коллегой-инженером Джастином, и они создали первые прототипы, продолжили работу над ними и через шесть недель получили первую работающую интеграцию MCP для Claude Desktop.

Они поделились прототипом внутри компании, и коллеги-разработчики из Anthropic были в восторге. Готовясь к публикации протокола в открытом доступе, участники внутреннего хакатона Anthropic создали множество интересных приложений, в том числе сервер MCP, управляющий 3D-принтером. Это подтвердило догадку Дэвида и Джастина о том, что MCP может быть очень полезен в реальном мире.

Они провели дополнительную доработку и объявили об открытом доступе к протоколу MCP 25 ноября прошлого года. На тот момент протокол MCP был таким:

Веб-сайт, на котором описан протокол, способы реализации сервера MCP и руководства для клиентов (например, по интеграции протокола в IDE)
Спецификация самого протокола
SDKдля Python, TypeScript, Java, Kotlin и C#
Примерысерверных и клиентских реализаций для справки

Быстрое внедрение в отрасль

Всего за четыре месяца MCP превратился из простого протокола, который использовал Claude Desktop с открытым исходным кодом, во все основные IDE, а инструменты искусственного интеллекта добавили поддержку MCP, включая OpenAI:

Июль 2024 года: в Anthropic начинается разработка MCP
Август:

Zed редактор добавляет поддержку сервера MCP. Забавный факт: Дэвид и Джастин использовали Zed на работе и встроили клиент MCP в Zed!

Январь 2025 года:

Зед редактор объявляет о поддержке MCP
Cline добавляет поддержку MCP
Курсор добавляет поддержку MCP

Февраль:

Claude Code — это запущенный Anthropic — агентный инструмент командной строки с поддержкой MCP
Виндсерфинг добавляетдобавляет поддержку MCP
Neovim получаетподдержку MCP через плагин

Марш:

Cloudflare выпускаетруководство по развертыванию готового к работе удаленного сервера MCP.
Sentry запускает свой сервер MCP, став первым крупным поставщиком, добавившим готовый к использованию удаленный сервер. Реализация Sentry была основана на руководстве, предоставленном Cloudflare.
OpenAI добавляетподдержку MCP в свой Agents SDK

Апрель:

VS Code добавляетподдержку MCP
GitHub запускает свой официальный сервер MCP (в режиме публичного предварительного просмотра)
Zapier запускаетсписок серверов MCP
Сервисы CI/CD, такие как Bitrise и CircleCI (CI/CD), запускают свои серверы MCP

Единственная заметная IDE, в которой на данный момент отсутствует поддержка MCP, — это JetBrains IDEs, которая должна добавить поддержку MCP в следующем выпуске IDE, который ожидается в ближайшее время. Редко можно увидеть такое быстрое внедрение во всех основных IDE. Очевидно, что MCP даёт большие преимущества разработчикам, использующим инструменты искусственного интеллекта, поэтому IDE хотят добавить эту функцию. Так совпало, что лучшие IDE, которые инженеры чаще всего называли любимыми IDE с функциями искусственного интеллекта — Cursor, VS Code, Windsurf, Zed, Neovim и Cline — одними из первых получили поддержку MCP!

Но как они работают?

3. Разберитесь в LSP, чтобы понять MCP

Давайте заглянем в мир протоколов языковых серверов, потому что именно это решение вдохновило разработчиков MCP.

Общая проблема, с которой IDE сталкивались десятилетиями, заключалась в том, что они хотели добавить поддержку как можно большего числа языков программирования, что также означало добавление поддержки таких вещей, как:

Подсветка синтаксиса
Завершение кода (автозаполнение)
Пометка предупреждений / ошибок в строке
Выполнение простых операций по рефакторингу

Предполагая, что существует M IDE и N языков программирования, это проблема MxN. Наивное решение состояло в том, чтобы для каждой M IDE создать ручную поддержку для каждого N языков, насколько это возможно. Для поставщиков IDE это была большая работа, которую необходимо повторять всякий раз, когда начинает распространяться новый язык программирования:

Статус-кво сохранялся примерно до 2016 года: каждая IDE реализовывала языковые функции для каждого поддерживаемого языка

Для нас, разработчиков, это означало, что IDEs хорошо поддерживает лишь ограниченное количество языков. Например, удачи в попытках кодирования с использованием C # в Android Studio!

Расширения / плагины — это обходной путь, позволяющий IDE выполнять сложную работу: в IDE, поддерживающих фреймворки расширений / плагинов, сторонние разработчики могут создавать плагины, например для подсветки синтаксиса на определённом языке. Это лучше, чем ничего, но требует от разработчиков больших усилий. Кроме того, многие IDE не предоставляют возможности расширения, которые обеспечивали бы удобство для разработчиков при использовании таких функций, как автодополнение и подсветка синтаксиса.

В 2016 году Microsoft выпустила протокол Language Server Protocol (LSP), изначально разработанный для Visual Studio Code. Идея заключается в том, что для каждого языка реализация LSP-сервера может предоставлять языковые функции. Теперь редакторы могут использовать LSP-сервер — существующую реализацию, часто с открытым исходным кодом, — вместо того чтобы создавать собственную:

Идея LSP заключается в том, чтобы создать серверы LSP для каждого соответствующего языка

Это повлияло на количество разрабатываемых IDE:

Новые и уже существующие интегрированные среды разработки могут легко добавлять поддержку новых языков благодаря простому в использовании протоколу (LSP)
Для большинства языков существует официальная реализация LSP, предоставляемая разработчиками языка (например, gopls для Go), и часто разработчики или поставщики IDE могут выбирать из нескольких реализаций LSP. Например, для C# популярными LSP являются OmniSharp и csharp-ls

Сегодня LSP поддерживают следующие IDE:

VS Код

Благодаря этому все пользователи VS Code любят Курсор, Виндсерфинг и т. д.

Зед Редактор
IntelliJ интегрированные среды
Eclipse, Neovim, Emacs
Многие другие небольшие редакторы, такие как Atom, Helix Editor, Kate и другие

Известные отсутствующие включают:

Visual Studio — флагманская интегрированная среда разработки Microsoft (не путать с VS Code). Использует собственные языковые инструменты для поддержки языков
XCode — существует официальный сервер Swift LSP, но XCode использует собственную систему анализа кода
Android Studio: отсутствует поддержка LSP, поскольку IDE основана на IntelliJ Community Edition и поддерживает более ограниченный набор языков программирования, чем полноценные IDE IntelliJ

4. Архитектура MCP

Успех LSP убедил Дэвида и Джастина в том, что протокол позволяет:

Разработчикам IDE следует уделять больше внимания созданию других отличительных функций IDE, а не языковых функций LSP
Разработчики языковых серверов сосредоточились на создании надёжных реализаций
... в результате улучшилась вся экосистема

Основная идея MCP схожа с идеей LSP: вместо того чтобы каждая IDE или другой инструмент на основе ИИ создавали поддержку для множества функций, можно определить серверы MCP, которые добавят поддержку нужной функции. Серверы MCP могут использоваться несколькими IDE, и они сами решают, какие функции интегрировать или создавать.

Обзор архитектуры MCP

MCP сделала несколько других выборов в отличие от LSP. Дэвид говорит, что они тщательно изучили распространённую критику в адрес LSP и приняли несколько других проектных решений:

Инициализация серверов: разработчики хотели сделать этот процесс максимально простым с точки зрения реализации. Недостаток LSP в том, что инициализация серверов — довольно сложный процесс
Заголовки: в протоколе LCP используется довольно уникальный подход к JSON-RPC, который предполагает отправку HTTP-заголовков на входе и выходе. Команда Anthropic выбрала более стандартный подход на основе JSON

Одним из содержательных постов, повлиявших на мнение команды, была статья LSP: хорошее, плохое и ужасное Майкла Пейтона Джонса.

Примеры MCP-серверов из эталонных серверов:

PostgreSQL: доступ к базе данных только для чтения с проверкой схемы.
GitHub: управляйте своим репозиторием, выполняйте операции с файлами git и получайте доступ к GitHub API
Файловая система: выполняет безопасные операции с файлами в вашей локальной файловой системе
Google Диск: поиск файлов и доступ к ним на подключенном Google Диске
Puppeteer: автоматизация браузеров и выполнение операций по веб-скрапингу
Sentry: извлекает логи и анализирует их из подключенной учетной записи Sentry.io
Redis: взаимодействие с подключенными хранилищами данных Redis типа «ключ-значение»

Серверы могут быть локальными или удалёнными:

Локальный сервер MCP:интегрированная среда разработки подключается к локально запущенному процессу, который может выполнять любые действия: от взаимодействия с удалённым сервером до доступа к локальной файловой системе. Слово «локальный» указывает на место, где запущен процесс. Например, сервер MCP PostgreSQL — это локальный процесс, запущенный в Node, который подключается к локальной или удалённой базе данных PostgreSQL.
Удаленный сервер MCP: интегрированная среда разработки подключается к удаленному серверу, а не к локальному процессу, например к серверу MCP компании Sentry, где IDE подключается к серверу Sentry, проходит аутентификацию с использованием учетных данных, а затем может отправлять запросы о данных, доступных клиенту Sentry.

Разновидности MCP-серверов

Я наблюдаю за несколькими условными группами серверов MCP в зависимости от того, кто их создаёт:

Официальные удалённые серверы MCP: в случае с GitHub, поддерживающим различные действия, связанные с GitHub, через MCP, они могут создать сервер. На данный момент лишь у немногих поставщиков есть официальный удалённый сервер, но ситуация может измениться.
Проверенные локальные серверы MCP: локальные оболочки для доступа к таким ресурсам, как файловая система, различные базы данных, например Postgres или Redis, или сервисы, такие как GitLab или Slack. На данный момент я видел только те, которые не предоставляются официальными поставщиками, но они проверены, так как созданы доверенной стороной. Подробнее об этом в разделе о безопасности ниже.
Серверы с открытым исходным кодом: многие серверы MCP имеют открытый исходный код, поэтому вы можете изучить их код. Если лицензия позволяет, создайте форк и свой собственный сервер.
Закрытый исходный код / приватность: любой может создать приватный сервер MCP с закрытым исходным кодом, который будет доступен только ему или его коллегам, как в примере выше, где сервер MCP написан на одном файле Python и запускается локально или даже распространяется внутри команды.

Однако пока не существует удобного сервиса для поиска проверенных серверов. Кроме того, в текущем, раннем поколении инструментов MCP есть проблемы с безопасностью.

5. Исходный код сервера MCP

Итак, как выглядит сервер MCP? Это зависит от того, локальный он или удалённый.

Серверы могут быть написаны на любом языке. Давайте рассмотрим простой сервер, написанный на Python, который получает данные о погоде с помощью API Национальной метеорологической службы США. Это пример из документации MCP. Этот пример показателен: мы могли бы легко создать серверы, которые вместо получения данных о погоде выполняли бы локальные операции или отправляли другие удалённые запросы.

Мы создаём файл weather.py и начинаем с инициализации сервера MCP. Вот как это выглядит:

Инициализация сервера MCP

Класс FastMCP — это оболочка, которая автоматически генерирует определения инструментов, упрощая создание инструментов MCP.

В файле weather.py мы определяем вспомогательный метод make_nws_request для получения данных о погоде:

Вспомогательная функция make_nws_request

Теперь давайте добавим основную функцию этого инструмента: получение прогноза погоды. Мы определяем метод get_forecast и помечаем его как «инструментальный» метод для MCP Server с помощью атрибута @mcp.tool().

Получение прогноза с помощью веб-запроса и возврат проанализированных результатов

Обратите внимание на важность четких описаний! Мы добавили четкие описания для функции («Получить прогноз погоды для определенного места») и аргументов («Широта/долгота места»). Это важно, потому что языковая модель будет пытаться заполнить параметры на основе описаний. С таким описанием, если мы спросим у LLM: «Какой прогноз погоды в Нью-Йорке?», LLM сможет определить, что этот сервер MCP подходит для использования и что сначала нужно получить долготу и широту Нью-Йорка — данные, которые более крупная модель, такая как Anthropic Sonnet 3.7, может сгенерировать достаточно точно.

Мы почти закончили, осталось только инициализировать и запустить сервер. Добавляем это в weather.py:

Настройка нашего сервера MCP

Тестирование MCP-сервера: для базового тестирования мы можем запустить MCP-сервер из командной строки с помощью:

uv run weather.py

В качестве контекста uv — это менеджер пакетов Python, аналогичный Node в мире Node.js. Эта команда запускает наш файл weather.py, и мы можем вызвать

Мы можем проверить, правильно ли работает MCP-сервер, запустив его из Claude Desktop (или любой другой IDE, поддерживающей MCP-серверы). В Claude Desktop нам нужно добавить MCP-сервер в файл конфигурации claude_desktop_config.json. Мы просто указываем на наш локальный файл weather.py:

Нам нужно сообщить нашему MCP-клиенту (в данном случае: Claude Desktop), где найти файл (ы) для нашего локального MCP-сервера и как запустить сервер

Как это работает во время выполнения

Подключение серверов MCP при инициализации: после добавления в конфигурацию IDE или инструмент (в данном случае Claude Desktop) подключает сервер MCP при перезапуске:

Claude Desktop сообщает, что найден новый инструмент MCP

Этот инструмент — погодный инструмент, а метаданные берутся из нашего описания в файле weather.py

А теперь давайте спросим: «Какая погода в Нью-Йорке?»

Принятие решения об использовании MCP-сервера: после нашего вопроса наша языковая модель решает, что, вероятно, следует использовать погодный MCP-инструмент. Она преобразует «Нью-Йорк» в широту и долготу и хочет вызвать наш MCP-сервер. Прежде чем сделать это в первый раз, Claude выводит полезное предупреждение о том, что MCP может быть вредоносным.

Перед первым запуском нам нужно подтвердить сервер MCP

Разбор ответа. Клод обращается к нашему серверу MCP и получает этот ответ. Затем LLM анализирует этот ответ и генерирует выходные токены (наш ответ):

Ответ, полученный с помощью MCP

Вот и всё! Мы создали сервер MCP и сделали его доступным для нашего клиента MCP (интегрированной среды разработки или такого инструмента, как Claude Desktop).

6. Угрозы безопасности

MCP — это мощный протокол, который позволяет подключать множество полезных источников данных. Однако при подключении таких объектов, как базы данных или сервисы, вам часто приходится передавать секретные данные на сервер MCP, а также предоставлять серверу доступ к вашей файловой системе. Это означает, что злоумышленники могут получить доступ к конфиденциальным данным и нанести серьёзный ущерб. С точки зрения безопасности, существующие инструменты MCP несовершенны и полны уязвимостей.

Атаки на цепочки поставок не являются чем-то новым, и локальный сервер MCP представляет собой скрытый вектор атаки. При обновлении до последней версии и запуске сервера существует риск кражи конфиденциальных данных, таких как SSH-ключи. Защита от атак на цепочки поставок аналогична защите от атак на пакеты npm. Например, используйте локальный реестр, в котором хранятся только проверенные пакеты, не обновляйте пакеты вслепую и используйте области видимости, чтобы все запросы к пакетам отправлялись в реестр по умолчанию.

Атаки на цепочку поставок для локальных MCP-серверов представляют такую же угрозу, как и для LSP. В случае с LSP речь идёт об установке расширения, которое может быть вредоносным, и IDE должна защищаться от этого. Новый вектор атак для MCP связан с поддержкой удаленных MCP-серверов, о которых LSP не имеет ни малейшего представления.

Имейте в виду, что в пространстве MCP существуют новые типы атак, о которых рассказал стартап в области искусственного интеллекта Invatiant Labs:

Атака с использованием инструмента-отравителя: атака, которой особенно уязвимы инструменты LLM, в том числе MCP. На первый взгляд безобидный инструмент содержит скрытые вредоносные инструкции, которые не видны пользователю, одобряющему инструмент, и которые заставляют LLM выполнять вредоносные действия. Ниже приведён пример сервера MCP, используемого для простой задачи сложения. Пользователь вводит запрос, который запускает этот инструмент, и инструмент затем раскрывает файл конфигурации mcp.json, который может содержать конфиденциальные данные, например строку подключения к базе данных или сохранённые SSH-ключи:

Отравление инструмента: на первый взгляд безобидный MCP-сервер выполняет вредоносные действия, которые пользователь может легко не заметить, например считывает и, вероятно, передает конфиденциальный файл mcp.json. Источник: Invariant Labs

Обман MCP: злоумышленник на сервере меняет описание инструмента после того, как клиент его одобрил. Уязвимость, позволяющая проводить атаки с подменой инструментов, заключается в том, что клиенты MCP, такие как Cursor, Windsurf или Claude Desktop, позволяют серверу MCP менять описание после того, как пользователь его одобрил. Очевидно, что эти инструменты не сообщают об этом пользователю. Злоумышленник на сервере MCP вводит в заблуждение, а затем, после одобрения и нескольких использований, незаметно меняет область применения, чтобы можно было проводить вредоносные манипуляции.

Атака MCP с использованием спуфинга. Источник изображения: Invariant Labs

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

«Спящая угроза»: сервер MCP WhatsApp тайно крадёт сообщения WhatsApp. Чтобы продемонстрировать эти уязвимости, компания Invariant Labs создала на первый взгляд безобидный сервер MCP, который позволяет взаимодействовать с WhatsApp для отправки и получения сообщений. В настоящее время WhatsApp не предлагает сервер MCP, поэтому все серверы MCP, позволяющие большим языковым моделям использовать WhatsApp, являются сторонними. Атака происходит следующим образом:

Пользователь устанавливает на первый взгляд безобидный сервер WhatsApp MCP, который позволяет отправлять и получать сообщения WhatsApp
После установки плагин выполняет атаку с отравлением инструмента, имитируя кражу MCP: он незаметно меняет описание инструмента, чтобы все сообщения перенаправлялись на другой номер, неизвестный пользователю

Полное описание атаки см. здесь. Эта атака может быть направлена на любой сервис; она может привести к раскрытию строк подключения к базе данных, утечке учетных данных GitHub, а также любой другой конфиденциальной информации, которую вы используете!

Для того чтобы MCP можно было использовать повсеместно, необходимо решить проблемы с безопасностью. Эти проблемы нужно будет решать на стороне клиента, то есть в IDE, которые запускают серверы MCP. На данном этапе вполне понятно, что IDE, интегрирующие MCP, сосредоточены на выпуске работающего продукта.

Сейчас я бы действовал с особой осторожностью при использовании ненадёжных MCP-серверов, потому что безопасность MCP-серверов во всех IDE оставляет желать лучшего.Новые векторы атак наверняка будут вскоре устранены IDE или, по крайней мере, их будет сложнее реализовать, но пока я бы посоветовал следующее:

Для локальных MCP-серверов: используйте только те, которые вы проверили и которым доверяете. Используйте проверенную торговую площадку, например ту, что есть в вашей IDE, или создайте список проверенных пакетов, в котором вы фиксируете версии и избегаете автоматических обновлений, или запускайте только те пакеты, которые вы собрали самостоятельно.
Для удаленных MCP-серверов: используйте только те, которые поставляются поставщиками.

7. Сценарии использования в будущем

Протокол MCP предоставляет языковым моделям инструменты для взаимодействия с любыми другими приложениями, открывая такие инновационные возможности, как:

Подключите свой код к проектам Figma. Figma создала плагин MCP, который может взаимодействовать с IDE, поэтому вы можете дать LLM команду реализовать проект Figma или создать проекты Figma для вас.

Даём LLM задание: «разработайте современный дизайн экрана для мобильного устройства». Это делается с помощью Figma и Figma MCP Server. Источник: Шубхан Сабу в X

Создавайте музыку, общаясь с языковой моделью. Дизайнер и разработчик Сиддхарт Ахуджа создал сервер MCP для прямого взаимодействия с программой для создания музыки Abelton. Подключив этот MCP, языковая модель может создавать музыку на основе запроса. Послушайте здесь.

Клод создал мелодию после нескольких попыток в музыкальном редакторе Ableton. Послушайте здесь

Создавайте 3D-модели с помощью подсказок. В 3D-играх, очевидно, используются 3D-модели, которые часто создаются с помощью программы Blender. Теперь Claude Desktop может взять изображение и создать 3D-модель в Blender. Подсказка:

Источник: Билавал Сидху в X

Результат работы LLM в Blender:

Источник: Билавал Сидху в X

Создайте карту, подключив геопространственное программное обеспечение. Подключив программное обеспечение для пространственной визуализации QGIS, вы можете создать векторную карту на основе реальной карты с учетом ваших предпочтений, например в отношении цветовой гаммы:

Создание векторной карты определенного региона с помощью Claude Desktop и QGIS. Источник: Билавал Сидху в X

Для этих целей вам не нужно использовать LLM из вашей IDE! В большинстве приведённых выше примеров используется Claude Desktop, но другие LLM могут легко добавить поддержку протокола MCP в свои приложения. Трудно представить, почему ChatGPT и Google Gemini не последуют этому примеру, а когда они это сделают, люди, не связанные с разработкой, скорее всего, начнут использовать MCP ещё чаще. Поставщики LLM вынуждены добавлять эту функцию, иначе они рискуют потерять долю рынка в пользу Claude Desktop из-за постоянно растущего числа поставщиков медицинских услуг, которые уже работают с Claude.

LLM, подключенный к любому программному обеспечению, открывает множество новых возможностей, в том числе:

Управляйте аппаратным обеспечением с помощью LLM! Команда Anthropic добавила поддержку MCP в 3D-принтер и теперь может давать ему команды. Мы можем представить себе множество других типов аппаратного обеспечения, которые можно добавить. Один из инженеров-программистов наверняка подключит самодельные праздничные гирлянды с компьютерным управлением к своей IDE к началу праздников.
Люди могут “разговаривать” с программным обеспечением. Например, спросите магистра права: “Создайте векторное изображение в Photoshop на основе этой фотографии, но с этими отличиями”.
Агенты с искусственным интеллектом получают больше инструментов для работы. С каждым новым созданным программным обеспечением агенты с искусственным интеллектом могут начать использовать их для выполнения более сложных задач. Например, подключив к IDE такие инструменты, как Linear, Slack, Figma и инструмент для создания скриншотов, разработчик может дать команду: «Возьми задачу по улучшению дизайна экрана входа в систему, возьми прикреплённый дизайн Figma, выполни первую реализацию, сделай скриншот результата реализации и опубликуй его в канале Slack команды после завершения».

Это возможности, которые потенциально могут изменить то, как выполняется работа, и то, какой объем работы может выполнить один инженер-программист. Это еще одно подтверждение того, что LLM являются крупнейшим прорывом в разработке программного обеспечения за последние десятилетия.

Блюда на вынос

MCP обладает огромным потенциалом для повышения продуктивности инженеров, а значит, этот подход, скорее всего, будет быстро распространяться.

Поставщики инструментов для разработчиков ухватились за возможность создавать MCP-серверы и ещё больше «привязывать» разработчиков к использованию своих инструментов — теперь через IDE!
IDEs, скорее всего, сосредоточатся на устранении уязвимостей в системе безопасности MCP. Это новая область, поэтому поиск подходящих решений для поставщиков атак может занять больше времени

Показательно, что именно стремление инженеров-программистов решить эту проблему привело к изобретению универсального коммуникационного моста между большими языковыми моделями и программным обеспечением. Были и другие попытки определить протоколы, которые позволили бы большим языковым моделям выполнять универсальные задачи и быть расширяемыми:

Агенты OpenAI:SDK для создания автономных агентов
Langbase Pipes: ИИ-агент, представляющий собой бессерверный API

В обоих случаях разработчики сосредоточились на агентах, а не на инструментах для разработчиков. Но кто создаёт агентов? Конечно же, разработчики!

Команда Anthropic, создававшая MCP, не стремилась решить глобальную проблему. Они просто хотели улучшить инструменты для разработчиков. Поэтому они решили проблему MxN, связанную с тем, что M инструментов для разработчиков (интегрированных сред разработки) должны поддерживать N различных плагинов/инструментов для разработчиков.

Решив эту проблему с помощью универсального коммуникационного уровня для инструментов разработки, они добились быстрого внедрения в IDE. Теперь все IDE поддерживают этот универсальный коммуникационный уровень под названием MCP. Возможно, мы сможем использовать тот же уровень для общего развития ИИ, не ограничиваясь инструментами для разработчиков?

Открытые подходы, как правило, распространяются на рынке разработчиков быстрее, чем закрытые. Одна из причин, по которой MCP так быстро распространился, заключается в том, что он открытый. Его создала компания Anthropic, но лицензия у него разрешительная, как у MIT, и мы приветствуем вклад разработчиков. Проект на GitHub не зависит от Anthropic, и легко заметить, что этот проект со временем может стать независимым, даже если для его развития потребуется поддержка компании.

Внедрение разрешительного протокола с открытым исходным кодом сопряжено с относительно низким риском для разработчиков, и, возможно, именно поэтому многие IDE поспешили добавить поддержку. Сравните это с ситуацией, когда протокол не является открытым или его реализация привязана к компании: разработчики IDE не спешили бы внедрять его, и он, скорее всего, не стал бы отраслевым стандартом.

Опытные инженеры-программисты станут ещё более востребованными. За два с половиной года никто не изобрёл протокол связи между LLM и программным обеспечением, который пользовался бы большой популярностью. Так как же двум инженерам из Anthropic, которые не являются специалистами по искусственному интеллекту, удалось это сделать?

Ранее Дэвид почти 10 лет проработал в Meta, занимаясь инфраструктурой для разработчиков, а Джастин был инженером-программистом в GitHub, а затем в Meta, где создавал программные системы, работавшие в огромных масштабах.

Одна из причин популярности протокола MCP заключается в том, что он хорошо продуман и прост в интеграции. Как будто разработчики, создавшие его, уже прошли этот путь и знают, что нужно для создания чего-то, что практически напрашивается на внедрение. Здесь важен опыт: время, которое Дэвид потратил на работу над протоколами Language Server, было очень полезным, как и опыт Джастина в масштабировании систем. Эта пара разработала протокол MCP, чтобы обеспечить его максимальную эффективность в долгосрочной перспективе, и их опыт помог им достичь этой цели. Они даже изучили самые слабые места LSP от Microsoft и разработали протокол с учётом этих недостатков, чтобы MCP не сталкивался с прогнозируемыми проблемами.

Если вы разработчик, изучите серверы MCP; они могут повысить продуктивность вашего рабочего процесса и показать, насколько полезными могут быть большие языковые модели в повседневной работе. Я советую осторожно поэкспериментировать с некоторыми из них и всегда помнить об их уязвимостях в плане безопасности.

Если вы работаете в компании, которая продает продукты разработчикам, рассмотрите возможность создания локальных или удаленных MCP-серверов для клиентов. У Cloudflare есть хорошее руководство по созданию удаленных серверов. Если вы работаете над инструментами для разработчиков, которые считаются MCP-клиентами, то поддержка MCP вскоре, скорее всего, станет базовым требованием для клиентов, поэтому вы можете рассмотреть возможность добавления поддержки MCP.

Каков ваш опыт использования MCP? Если вы его используете, не стесняйтесь оставлять комментарии.

Перевод: https://newsletter.pragmaticengineer.com/p/mcp

Инженерная культура Google: стек технологий (часть 2)

2025-10-31T06:17:34.807Z

Узнайте, как работает Google, с точки зрения технических специалистов этого технологического гиганта: инфраструктура планетарного масштаба, стек технологий, внутренние инструменты и многое другое

«Каково это на самом деле — работать в Google?» — вот вопрос, который рассматривается в этом мини-сериале. Чтобы узнать подробности, мы поговорили с 25 нынешними и бывшими инженерами-программистами и руководителями инженерных отделов с 4-го по 8-й уровень. Кроме того, мы потратили последний год на исследования: изучали статьи и книги, в которых обсуждаются эти системы. В процессе мы собрали много информации и интересных фактов, которые объединены в этой статье (и мини-сериале). Мы надеемся, что это обеспечит беспрецедентную детализацию по сравнению с тем, что сейчас доступно в интернете.

В первой части мы уже рассмотрели:

Обзор Google
Что делает Google особенным?
Уровни и роли
Компенсация
Наем

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

Мы покрываем:

Инфраструктура планетарного масштаба. Внутренняя инфраструктура Google по умолчанию рассчитана на «планетарный масштаб», но Google Cloud не поддерживает его «из коробки»; поэтому большинство инженерных команд используют стек Google PROD, а не GCP.
Монорепозиторий. Также известный как «Google3», он на 95 % состоит из кода Google, хранящегося в одном гигантском репозитории с миллиардами строк. Разработка на основе магистрали является нормой. Кроме того, монорепозиторий не означает, что у Google монолитная кодовая база.
Технологический стек. Официально поддерживаются C++, Kotlin, Java, Python, Go и TypeScript с активным использованием Protobuf и Stubby. У Google есть руководства по языковому стилю для большинства языков, которые почти всегда соблюдаются.
Инструменты для разработки. Набор инструментов для разработки отличается от любого другого рабочего места. Прощайте, GitHub, Jenkins, VS Code и другие известные инструменты: здравствуйте, Piper, Fig, Critique, Blaze, Cider, Tricorder, Rosie и другие.
Вычисления и хранение данных. Borg, Omega, Kubernetes, BNS, Borgmon, Monarch, Viceroy, Analog, Sigma, BigQuery, Bigtable, Spanner, Vitess, Dremel, F1, Mesa, GTape и многие другие пользовательские системы, на которых работает Google. Этот стек инфраструктуры не похож ни на один другой.
ИИ. Gemini интегрирован в инструменты для разработчиков и большинство внутренних инструментов, и Google всячески поощряет команды к созданию ИИ, когда это возможно. Команды могут запрашивать ресурсы графического процессора для тонкой настройки моделей, и существует множество внутренних проектов GenAI.

1. Инфраструктура планетарного масштаба

Инфраструктура Google отличается от инфраструктуры любой другой технологической компании тем, что она полностью создана на заказ: не только инфраструктура, но и инструменты для разработчиков. Google это технологический остров, и инженеры, присоединяющиеся к этому технологическому гиганту, могут забыть об инструментах, к которым они привыкли: GitHub, VS Code, Kubernetes и т. д. Вместо этого им приходится использовать собственную версию инструмента Google, даже если есть аналог.

Планетарный масштаб против GCP

Инженеры Google используют термин «планетарный масштаб» для обозначения способности компании обслуживать каждого человека на Земле. Все инструменты компании работают в глобальном масштабе. Это резко контрастирует с Google Cloud Platform (GCP), где нет встроенных возможностей для развертывания в «планетарном масштабе». Можно создавать приложения, которые могут масштабироваться до таких размеров, но это потребует большого количества дополнительной работы. Крупными клиентами GCP, которым удалось масштабировать инфраструктуру GCP до планетарных масштабов, являются Snap, использующая GCP и AWS в качестве облачного бэкенда, и Uber, использующая GCP и Oracle, как подробно описано в «Переход Uber в облако».

Google использует инфраструктуру планетарного масштаба не только для «крупных проектов», таких как поиск и YouTube. На этом стеке под названием PROD создается и развертывается множество новых проектов.

Кстати, корни базы данных Planetscale (база данных Cursor в настоящее время работает на) уходят в Google и его системы «планетарного масштаба». До того как стать соучредителем Planetscale, Сугу Сугумаране работал в Google на YouTube, где он создал Vitess — базу данных с открытым исходным кодом для масштабирования MySQL. Сейчас Сугу работает над Multigres, адаптацией Vitess для Postgres. Я спросил, откуда взялось название Planetscale. Он ответил:

«Впервые я услышал термин «планетарный масштаб» в Google. Я немного посмеялся, когда услышал его, потому что невозможно создать глобально распределённую ACIDбазу данных без компромиссов. Но тогда Vitess уже работал в «планетарном масштабе» на YouTube, с центрами обработки данных во всех уголках мира.Итак, когда мы решили назвать проект PlanetScale, это было смелое заявление, но мы знали, что Vitess сможет его поддержать.

Изначально Planetscale был запущен с использованием облачного экземпляра Vitess и завоевал популярность благодаря своей способности поддерживать крупномасштабные базы данных. Интересно, что амбиции Google в отношении «планетарного масштаба» воплотились в стартапе по созданию баз данных, соучредителем которого стал выпускник Google!

PROD Стек

«PROD» — это название внутреннего технологического стека Google, и по умолчанию все проекты, как новые, так и уже существующие, создаются на базе PROD. Есть несколько исключений для проектов, созданных на GCP, но использование PROD является нормой.

Некоторые сотрудники Google считают, что PROD не должен не должен использоваться по умолчанию, по мнениюодного из штатных инженеров-программистов. Они сказали нам:

«Многие сотрудники Google часто жалуются — и я с ними согласен, — что лишь немногие сервисы действительно должны быть «планетарными» с первого дня! Но сложность создания планетарного сервиса даже на базе PROD на самом деле снижает производительность и время выхода на рынок для новых проектов.Запуск нового сервиса занимает несколько дней, если не недель. Если бы мы использовали более простой стек, настройка заняла бы несколько секунд, и именно столько времени должно уходить на запуск новых проектов, которым, возможно, никогда не понадобится масштабирование! Как только проект наберет обороты, у вас будет достаточно времени, чтобы добавить поддержку в планетарном масштабе или перейти на инфраструктуру, которая это поддерживает.

Создание продуктов для внутреннего использования на базе GCP может быть сопряжено с трудностями. Инженер-программист привел нам такой пример:

«Есть несколько примеров внутренних версий продуктов, созданных на базе GCP, которые действительно обладали совершенно другими функциями или возможностями».Например, внутренняя версия GCP Pub/Sub называется GOOPS (Google Pub/Sub). Для настройки GOOPS нельзя было использовать удобный интерфейс GCP: нужно было использовать файл конфигурации. По сути, у внешних пользователей GCP Pub/Sub гораздо больше возможностей для разработки, чем у внутренних пользователей.”

Нет смысла использовать общедоступный сервис GCP, если уже есть один в PROD. Другой инженер Google сказал нам, что внутреннюю версию Spanner (распределённой базы данных) гораздо проще настроить и контролировать. Внутренний инструмент для управления Spanner называется Spanbob, а также существует внутренняя расширенная версия SpanQSL.

Google выпустила Spanner на GCP как общедоступный сервис. Но если какая-либо внутренняя команда Google использовала Spanner на GCP, она не могла использовать Spanbob — и ей приходилось проделывать гораздо больше работы только для того, чтобы настроить сервис! — и не могла использовать внутренний расширенный SpannerSQL. Поэтому неудивительно, что практически все команды Google выбирают инструменты из стека PROD, а не из стека GCP.

Единственная крупная технологическая компания, которая не использует собственное облако для новых продуктов

Google находится в ситуации, когда ни один из её «основных» продуктов не использует инфраструктуру GCP: ни Поиск, ни YouTube, ни Gmail, ни Google Docs, ни Календарь Google. Новые проекты по умолчанию создаются на PROD, а не на GCP.

Сравните это с Amazon и Microsoft, которые поступают наоборот:

Amazon: почти полностью на AWS, и все новое создается на этой платформе. Почти все сервисы перешли на AWS. «Современный стек» — это NAWS (Native AWS), и все новые проекты используют его. Остальная часть стека — это MAWS (Move to AWS); устаревшие системы еще не переведены на AWS.
Microsoft: активное использование Azure, на основе которого строится всё новое. Microsoft 365, Microsoft Teams, Xbox Live, GitHub Actions и Copilot работают на базе Azure. Такие приобретения, как LinkedIn и GitHub, постепенно переходят на Azure, на основе которого по умолчанию строится каждый новый проект.

Почему технические специалисты Google сопротивляются внедрению GCP?

Поддержка в «планетарном масштабе» не предусмотрена. Обычно PROD выбирают потому, что в случае резкого роста популярности продукта или услуги инфраструктура может расширяться бесконечно без миграции.
Превосходный опыт разработки с помощью PROD. Spanner — очевидный пример; в целом инструменты, созданные на основе PROD, гораздо удобнее и проще в работе для разработчиков Google.
Историческое отторжение GCP. 5–10 лет назад было сложно представить, что на GCP можно что-то создать. Тогда в ней отсутствовали некоторые внутренние системы, необходимые для внутренних проектов, такие как аудит и контроль доступа с использованием внутренних систем. Сейчас ситуация изменилась, но отторжение GCP осталось прежним.

Один из нынешних инженеров-программистов Google подытожил:

“Внутренняя инфраструктура соответствует мировым стандартам и, вероятно, является лучшей в отрасли. Я думаю, что многие инженеры Google хотели бы использовать GCP, но внутренняя инфраструктура создавалась специально для них, в то время как GCP более универсальна и ориентирована на более широкую аудиторию”.

Другой инженер-программист из этой компании сказал:

“В конце концов, PROD просто настолько хорош, что GCP по сравнению с ним - ступенька вниз. Это относится к:Безопасность — это то, что есть по умолчанию. GCP требует дополнительных размышлений и работыПроизводительность — добиться хорошей производительности внутреннего стека несложноПростота — внутренняя интеграция не требует особых усилий, в отличие от GCP, где работы гораздо большеОсновная причина использования GCP — это оптимизация для дога, но у этого подхода много недостатков, поэтому команды, которые ищут лучший инструмент, просто используют PROD».

Отсутствие директивы сверху, скорее всего, является ещё одной причиной. Переход с собственной инфраструктуры на облачные сервисы компании — сложная задача! Когда я работал в Skype в составе Microsoft в 2012 году, нам сверху дали указание полностью перевести Skype на Azure. Этой работой занималась команда Skype Data, которая работала со мной в одном отделе. Это был изнурительный и сложный процесс, потому что в то время Azure не могла похвастаться достаточной поддержкой и надёжностью. Но поскольку это был приказ сверху, в конечном счёте всё получилось! Команда Azure уделила первостепенное внимание потребностям Skype и внесла необходимые улучшения, а команда Skype пошла на компромиссы. Без давления сверху этот переход никогда бы не состоялся, поскольку у Skype был целый список причин, по которым Azure была не лучшим выбором в качестве инфраструктуры по сравнению с текущим положением дел.

Google действительно уникальная компания с внутренней инфраструктурой, которую инженеры считают гораздо более совершенной, чем общедоступное облако GCP. Возможно, такой подход также объясняет, почему GCP занимает третье место среди поставщиков облачных услуг и не демонстрирует особых признаков того, что может догнать AWS и Azure. В конце концов, Google не пользуется доверием к своему облаку — не говоря уже о том, чтобы внедрять его по принципу «сверху вниз»! — как это сделали Amazon и Microsoft со своими облаками.

2. Монорепозиторий

Google хранит весь код в одном репозитории под названием monorepo, который также называют «Google3». Размер репозитория поражает — вот статистика за 2016 год:

2+ миллиарда строк кода

1 миллион файлов
9 миллионов исходных файлов

45 000 коммитов в день

15 000 от инженеров-программистов
30 000 с помощью автоматизированных систем

95%инженеров Google используют монорепозиторий
800 000 QPS: количество запросов на чтение в репозитории в пиковые моменты, в среднем 500 000 запросов в секунду в каждый рабочий день. Большая часть трафика поступает не от инженеров, а от автоматизированных систем сборки и тестирования Google.

Сегодня масштабы монорепозитория Google, несомненно, увеличились в несколько раз.

В монорепозитории хранится большая часть исходного кода.Заметными исключениями являются проекты с открытым исходным кодом:

Android: операционная система для смартфонов от Google
Chromium: веб-браузер с открытым исходным кодом от Google. Google Chrome, Microsoft Edge, Opera, Brave, браузер DuckDuckGo и многие другие созданы на основе Chromium.
Go: серверный язык программирования, созданный Google

Интересный факт: эти проекты с открытым исходным кодом долгое время размещались на внутреннем Git-хостинге под названием «git-on-borg» для удобства внутреннего доступа (подробнее о Borg мы расскажем в разделе «Вычисления и хранение данных».) Затем это внутреннее репозиторий было зеркалировано на внешнем сервере.

Разработка на основе магистральной ветки является нормой. Все разработчики работают в одной основной ветке, которая является источником достоверной информации («магистральной веткой»). Разработчики создают краткосрочные ветки для внесения изменений, а затем объединяют их с магистральной веткой. Команда разработчиков Google обнаружила, что использование долгосрочных веток разработки снижает продуктивность. В книге «Разработка программного обеспечения в Google» объясняется:

«Если мы представим незавершённую работу как аналог ветки разработки, это ещё больше укрепит нас во мнении, что работа должна выполняться небольшими порциями и регулярно фиксироваться».

В 2016 году в монорепозитории Google работало более 1000 инженерных команд, и лишь немногие из них использовали долгосрочные ветки разработки. Во всех случаях использование долгосрочной ветки было связано с необычными требованиями, а распространённой причиной была поддержка нескольких версий API.

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

Документация часто хранится в монорепозитории, и это может создавать проблемы. Вся общедоступная документация по API для Android и Google Cloud хранится в монорепозитории, а это значит, что к файлам документации применяются те же правила читабельности, что и к коду Google. Google предъявляет строгие требования к читабельности всех файлов с исходным кодом (см. ниже). Однако в случае с внешним кодом примеры обычно не соответствуют внутренним рекомендациям по читабельности намеренно!

По этой причине рекомендуется хранить примеры кода за пределами монорепозитория, в отдельном репозитории GitHub, чтобы избежать проблем с читабельностью (например, если файл с примером называется quickstart.java.txt).

Например, вот старый пример документации, где исходный код находится в отдельном файле репозитория GitHub, чтобы избежать проверки читабельности Google. В новых примерах таких как этот код записывается непосредственно в файл документации, который настроен таким образом, чтобы не вызывать проверку читабельности.

Не весь монорепозиторий доступен каждому инженеру. Доступна большая часть кодовой базы, но некоторые разделы ограничены:

Файл OWNERS: этот файл содержит список владельцев кода. Чтобы что-то объединить, вам нужно получить одобрение хотя бы от одного разработчика из этого списка. Модель «OWNERS» применяется в проектах с открытым исходным кодом, таких как Android или Chromium.
Хранилища для конфиденциальных данных: доступ на чтение к конфиденциальным проектам или их частям ограничен. Например, некоторые подсказки в проекте Gemini доступны для чтения только инженерам, работающим над ним.
Инфраструктурные решения для конфиденциальных проектов: командам, занимающимся инфраструктурой, нужен доступ даже к конфиденциальным проектам, чтобы они могли настроить такие инструменты, как codemod (для автоматического преобразования инструментов). Команды, занимающиеся инфраструктурой, обычно назначают одного или двух специалистов по инфраструктуре, которых добавляют в глобальный список разрешённых пользователей, чтобы они могли видеть эти конфиденциальные проекты и помогать разработчикам с настройкой инструментов и решением проблем.

Архитектура и проектирование систем

В 2016 году менеджер по разработке Google Рэйчел Потвин объяснила, что, несмотря на монорепозиторий, кодовая база Google не является монолитной. Мы спросили у нынешних инженеров, так ли это до сих пор, и нам ответили, что ничего не изменилось:

«Честно говоря, я не вижу особой разницы с организациями, которые используют отдельные репозитории, например AWS. В любом случае у нас есть инструменты для поиска по всему коду, на который у вас есть права». — Инженер-программист 6-го уровня в Google.“Процесс разработки программного обеспечения распределен, а не централизован. Система сборки похожа на Bazel (внутренне она называется Blaze). У отдельных команд могут быть свои собственные цели сборки, которые проходят через отдельный CI / CD ”. – Благодарность сотрудников L6 в Google.

Еще одна крупная технологическая компания, которая с самого начала использовала монорепозиторий — это Meta. Подробнее о ее монорепозитории можно прочитать в Статье о культуре разработки в Meta.

Каждая команда в Google выбирает свой подход к проектированию систем, что означает, что продукты часто имеют разный дизайн! Сходство заключается в инфраструктуреи инструментах разработки, которые используют все системы, а также в низкоуровневых компонентах, таких как Protobuf и Stubby, внутренний gRPC. Ниже приведены несколько общих тем, которые обсуждались с более чем 20 сотрудниками Google:

Сервисы распространены повсеместно. Google не считает их «микросервисами», поскольку многие из них большие и сложные. Но команды редко ориентируются на монолитную архитектуру. Когда сервис становится слишком большим, его обычно разбивают на более мелкие сервисы, в основном из соображений масштабирования, а не модульности.
Stubby используется для обмена данными между сервисами. Это стандартный способ взаимодействия сервисов друг с другом; gRPC используется редко и обычно только для внешних сервисов.

Один из нынешних инженеров Google описал это место с архитектурной точки зрения:

«Google похож на множество маленьких соборов, собранных на одном большом базаре».

Хаотичный базар с аккуратно построенными соборами. Изображение от Gemini

Эта метафора взята из книги «Собор и базар», где собор — это разработка с закрытым исходным кодом (организованная, нисходящая), а базар — разработка с открытым исходным кодом (менее организованная, восходящая).

Несколько интересных фактов о крупных сервисах Google:

YouTube раньше был монолитом на Python, но позже был переписан на C++ и Java. Много лет назад каждый релиз проходил 50-часовой цикл ручного тестирования, проводимого удалённой командой контроля качества.
Поиск Google — это самая большая и монолитная кодовая база. Наличие монолитных кодовых баз — это исключение, а не правило.
Реклама и облачные сервисы используют всё больше (микро)сервисов.
Переработка сервисов в микросервисы — это подход, который Google использует в некоторых случаях. Переработка приложения с нуля в микросервисную архитектуру (для обеспечения нужного уровня модульности) требует меньше усилий, чем разделение монолита на части.

3. Технологический стек

Официально поддерживаемые языки программирования

Внутри компании Google официально поддерживает следующие языки программирования. Это означает, что для них существуют специальные инструменты и платформы:

C++
Котлин и Ява
Питон
Вперед
TypeScript и JavaScript

Инженеры могут использовать другие языки, но они не получат специальной поддержки от команд разработчиков платформы.

TypeScript заменяет JavaScript в Google,рассказали нам несколько инженеров. Компания больше не позволяет добавлять новые файлы JavaScript, но существующие файлы можно изменять.

Kotlin становится очень популярным не только в мобильной разработке, но и в серверной. Новые сервисы пишутся почти исключительно на Kotlin или Go, а Java кажется «устаревшей». Переход с Java на Kotlin происходит по инициативе разработчиков, большинство из которых считают Kotlin более удобным в работе.

Для мобильных устройствиспользуются следующие языки:

Objective C и Swift для iOS
Kotlin для Android (и Java для устаревших приложений). Кроме того, для Android регулярно используется Rust.
Dart для Flutter (для кроссплатформенных приложений)

Руководства по языковому стилю существуют в Google, и для каждого языка есть своё руководство. Вот несколько примеров:

Стиль Google Java — Инструмент форматирования Google Java форматирует код в соответствии с этим стилем
Стиль Google TypeScript
Стиль Google Python
Стиль Google Go
См. все руководства по языковому стилю Google

Функциональная совместимость и удалённый вызов процедур

Protobuf — это подход Google к обеспечению совместимости, который заключается в работе с разными языками программирования. Protobuf — это сокращение от «буферов протокола»: языково-независимый способ сериализации структурированных данных. Вот пример определения protobuf:

издание = «2024»;лицо , Передающее сообщение {строка name = 1;int32 id = 2;строка email = 3;}

Это можно использовать для передачи объекта Person между разными языками программирования; например, между приложением на Kotlin и приложением на C++.

Интересная особенность собственных API Google, будь то GRPC, Stubby, REST и т. д., заключается в том, что они все определены с помощью protobuf. На основе этого определения создаются клиенты API для всех языков. Таким образом, внутри компании легко использовать этих клиентов и вызывать API, не беспокоясь о базовом протоколе.

gRPC — это современная высокопроизводительная платформа с открытым исходным кодом для удаленных процедурных вызовов (RPC) между сервисами. Компания Google открыла исходный код и популяризировала этот протокол связи, который теперь является популярной альтернативой REST. Самое большое различие между REST и gRPC заключается в том, что REST использует HTTP для удобочитаемого форматирования, в то время как gRPC — это двоичный формат, который превосходит REST за счет меньшего размера полезной нагрузки и меньших затрат на сериализацию и десериализацию. Внутри компании сервисы Google, как правило, взаимодействуют с помощью «внутренней реализации gRPC от Google» под названием Stubby и не используют REST.

Stubby — это внутренняя версия gRPC и её предшественник. Почти все взаимодействия между сервисами осуществляются через Stubby. По сути, у каждого сервиса Google есть API Stubby для доступа к нему. gRPC используется только для внешних взаимодействий, например для внешних вызовов gRPC.

Название «stubby» происходит от того, что в протобуферах может быть определено обслуживание, а заглушки могут быть сгенерированы из этих функций на каждом языке. А от «заглушки» происходит «stubby».

4. Инструменты Dev

В некотором смысле повседневные инструменты Google для разработчиков наиболее наглядно демонстрируют, насколько эта компания отличается от других.

Инструменты разработчика в большинстве компаний, кроме Google

Давайте рассмотрим эти инструменты и то, как они работают в технологическом гиганте:

Контроль версий

Piper — это основное решение Google для контроля версий. В 2020 году оно обрабатывало 60–70 000 коммитов в день и хранило более 80 ТБ метаданных и контента (!). Раньше Piper был построен на Bigtable, а теперь использует Spanner. Он распределён по более чем 10 центрам обработки данных и использует алгоритм Паксоса (который также используется в сервисе распределённых блокировок Chubby) для обеспечения согласованности между репликами.

В первые годы своего существования Google использовала Perforce для контроля версий, но столкнулась с проблемами масштабирования и перешла на другой инструмент в 2012 году. Это показывает, насколько масштабнее деятельность Google по сравнению с другими компаниями: Perforce — это предпочтительное в отрасли решение для контроля версий в крупных кодовых базах. Такие компании, как Nintendo, Ubisoft, Electronic Arts и другие, используют его, потому что Git не поддерживает кодовые базы с большим количеством ресурсов, например игр.

Fig — это новая внутренняя система контроля версий, основанная на Mercurial, по словам нынешних инженеров Google. Многие новые проекты используют Fig, но поддерживаются и Piper, и Fig.

Gerrit — это «интерфейс управления версиями», созданный на основе Git и схожий с системами GitHub и GitLab. Он был открыт компанией Google и использовался в таких проектах, как Chromium и Android. Он поддерживает такие рабочие процессы, как работа со списками изменений (CL) вместо веток.

Проверка кода

Критика — это инструмент для проверки кода от Google. Он работает в веб-браузере и на первый взгляд предлагает те же функции, что и GitHub:

Критический анализ

Для многих сотрудников Google любимым инструментом, вероятно, является Critique. Согласно внутренним опросам, уровень удовлетворённости пользователей составляет целых 97 % (!!)

В Critique есть удобные интеграции:

Если кто-то добавляет комментарий, а вы открываете это рабочее пространство в своей IDE в Cider, вы видите комментарии прямо в IDE и можете ответить на них. Не нужно возвращаться в Critique
Встроенный поиск и редактор кода
Поддерживает просмотр файлов по одному

LGTM — это сокращение от «на мой взгляд, выглядит неплохо», и именно так в Critique одобряется CL (запрос на изменение). Это ещё один пример культуры «гуглости»: вместо формального глагола «одобрить» разработчики просто используют LGTM.

Рабочий процесс CL

CL расшифровывается как «список изменений» и является аналогом запросов на вытягивание (pull requests, PR). Несмотря на то, что эти два инструмента похожи, CL отличаются от PR. Вот чем:

По сути, рабочий процесс CL гораздо более регламентирован, чем рабочий процесс PR. В нем приоритет отдается предоставлению полных, а не частичных комментариев, отслеживанию того, кто выполняет следующее действие, а также строгим проверкам качества, которые должны быть завершены до того, как CL будет отправлен на слияние.

Более подробную информацию о рабочем процессе CL можно найти в этом разделекниги«Разработка программного обеспечения в Google».

Поиск кода

Поиск кода эволюционировал от grep-подобного инструмента, который использовался в Google на ранних этапах, когда он мог найти любое использование слова или фразы, до сегодняшнего дня, когда он может ответить на такие вопросы, как:

«Где определена эта функция?»
«Как мне использовать этот класс?»
«Когда эта переменная была добавлена в кодовую базу?»

Kythe — это инструмент семантического индексирования, который лежит в основе поиска кода. Это инструмент, который позволяет задавать такие вопросы, как «кто вызывает эту функцию?» и «какие классы наследуются от этого класса?»

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

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

Вместе с Critique Code Search является одним из самых популярных внутренних инструментов Google. Вот как его описали два нынешних и бывших сотрудника Google:

«Инструмент для поиска кода настолько хорош, что для меня он был чем-то вроде LLM-lite: я использовал его как систему поиска кода».

Sourcegraph — это инструмент для поиска кода, созданный на основе Code Search и предоставляющий возможности «поиска кода» для многих компаний. По словам нескольких инженеров Google, которые используют оба инструмента, в наши дни Sourcegraph по функциональности не уступает Code Search. Мы подробно изучили инженерную культуру Sourcegraph.

Инструменты для поиска кода на базе искусственного интеллекта также упростили воспроизведение «волшебства поиска кода» от Google. Один из сотрудников Google так охарактеризовал поиск кода:

«Мне кажется, что Sourcegraph и другие компании догнали нас в этой области — на самом деле они даже немного превзошли возможности Code Search. Это связано с тем, что в команде Code Search меньше сотрудников, а также с тем, что Code Search в настоящее время не использует поиск кода на основе искусственного интеллекта».

Система сборки

Blaze — это декларативная и распределённая система сборки от Google, созданная специально для монорепозитория. Таким образом, она предназначена для работы в планетарном масштабе. Она использует файлы BUILD для декларативного описания сборок, а также распределена и кэширована на нескольких компьютерах. Шаги сборки «герметичны», то есть зависят только от заявленных входных данных. Они также детерминированы, что означает надёжность системы сборки в целом.

Bazel — это внешняя версия Blaze с открытым исходным кодом, и надёжность является её важной характеристикой, как разработчики программного обеспечения в Google обсуждают:

«Многие старые системы сборки пытаются найти компромисс между скоростью и корректностью, прибегая к упрощениям, которые могут привести к сбоям в сборке. Основная цель Bazel — избежать необходимости выбирать между скоростью и корректностью, предоставляя систему сборки, которая гарантирует эффективную и стабильную сборку кода».

Подробнее о системах сборки в Google и Bazel читайте в главе Системы сборки и философия сборки в вышеупомянутой книге.

В нескольких проектах Google используются разные системы сборки:

Soong: система сборки используется в Android
GN: используется в Chromium
Gradle: используется в AndroidX (набор библиотек с открытым исходным кодом, созданных для Android)

Облачные среды разработки

CitC (Clients in the Cloud) — это инструмент, который позволяет создавать виртуальные рабочие пространства без необходимости извлекать код или хранить его на компьютерах разработчиков, как и в других облачных средах разработки. Подробнее об этом в подробном обзоре облачных сред разработки.

Fig — это преемник CitC, который большинство разработчиков используют для виртуальных рабочих пространств.

IDE

Cider — это интегрированная среда разработки от Google, которой пользуется большинство разработчиков. Она основана на VS Code и выглядит так же, за исключением того, что она хорошо интегрирована с внутренними системами Google, такими как:

Критика (проверка кода)
Blaze (инструмент для сборки)
Гитара (сквозное тестирование с использованием реальных систем)
TAP (платформа автоматизации тестирования, непрерывная сборка от Google)
Tricorder (статический анализ)
CodeSearch (инструмент для поиска кода)

Инженер Google привёл нам пример того, насколько всё там взаимосвязано:

«Очень легко получить ссылку на CodeSearch, которая ведёт на строку, открытую в Cider. Затем вы можете поделиться этой ссылкой, и она откроет Cider на той же строке для всех остальных. Так что это отличный инструмент для обмена вопросами или кодом, который вы просматриваете».

Несколько лет назад Cider был веб-версией IDE с гораздо меньшим количеством возможностей и меньшим объёмом внутреннего использования. После перехода на форк VS Code объём внутреннего использования значительно увеличился.

Масштабный рефакторинг

Rosie — это инструмент для крупномасштабного рефакторинга, который очень полезен, учитывая строгие правила проверки кода в Google. Он может разбивать крупные изменения в коде на более мелкие части. Эти более мелкие части можно тестировать, проверять и отправлять на доработку независимо друг от друга. При разбиении учитывается авторство кода. Инженер L4 объяснил нам, почему они любят Rosie:

«Как разработчику инфраструктуры, вам часто приходится вносить масштабные изменения (кодовые моды) во всё репозиторий. Из-за файла OWNERS внесение таких изменений в виде одного большого коммита вызывает раздражение из-за большого количества необходимых согласований.Рози возьмёт ваш огромный CL с сотнями или тысячами изменённых файлов и разделит его на более мелкие части, которые будут отправлены отдельным командам.

Статический анализ

Tricorder — это инструмент статического анализа от Google. Инженер, работавший над ним, объясняет:

«Tricorder — это инструмент для статического и программного анализа, который запускает линтеры и анализаторы, тесно интегрированные с любой другой системой разработки:Запуск при проверке кодаПри развертыванииПри каждом коммите (так называемом «снимке»).Это платформа по принципу «подключи и работай», на которой команды могут создавать собственные анализаторы кода и определять предварительные условия для их запуска.

Команда попыталась открыть исходный код версии Tricorder под названием ShipShape, но этот проект сейчас заархивирован. Один из инженеров рассказал нам, что из-за разнообразия систем сборки во внешнем мире сделать Tricorder таким же полезным для других компаний, как для Google, гораздо сложнее.

Более подробную информацию о Tricorder можно найти в этой статье.

Перейти по ссылкам

В Google просто введите «go/что угодно», чтобы перейти по быстрой ссылке. Это полезная функция, и многие другие компании создали аналогичную функцию быстрых ссылок, например Stripe со своим инструментом go.

Теперь есть даже сервис под названием GoLinks, который реализует эту простую, но полезную идею!

5. Вычисления и хранение данных

Google расширила свою инфраструктуру до глобального масштаба раньше, чем любая другая технологическая компания. В конце 1990-х — начале 2000-х годов большинство технологических компаний приобретали дорогие и большие мейнфреймы для масштабирования своего парка серверов. В отличие от них, Google создавала вычислительные системы и хранилища на базе стандартного оборудования. Для этого им нужно было создать новые типы программного обеспечения для управления парком стандартного оборудования в невиданных ранее масштабах. Поэтому неудивительно, что у Google уникальная, специализированная программная инфраструктура.

Borg и связанные с ним системы

Borg — это система, которая управляет физической инфраструктурой Google. Borg управляет кластерами из десятков тысяч машин и выполняет на них сотни тысяч заданий. Вот как в статье 2015 года кратко описывается высокоуровневая структура Borg:

Архитектура Borg. Источник: Управление крупномасштабными кластерами в Google с помощью Borg

Borg обеспечивает работу всех крупных приложений Google планетарного масштаба, таких как Поиск, Gmail и Реклама. Но и небольшие приложения часто начинают работу с Borg. Например, он используется даже для запуска простых блокнотов на Python. Borg является частью технологического стека PROD, поэтому начать работу с ним внутри компании довольно просто.

Омега был исследовательским прототипом, созданным на основе знаний о Борге с целью его усовершенствования. По сравнению с Боргом он был более гибким и ориентированным на транзакции. В итоге система не получила широкого распространения внутри компании.

Kubernetes был создан компанией Google как проект с открытым исходным кодом на основе разработок Borg и Omega. По сей день Google использует Borg, но Kubernetes стал ведущим в отрасли решением для управления контейнерами. Подробнее об истории Kubernetes мы рассказываем в выпуске подкаста The Pragmatic Engineer, Как устроен Kubernetes.

BNS — это «внутренний DNS» Google. Это сокращение от «Borg Naming Service». BNS использует уровень абстракции над IP-адресами, а Borg использует эту абстракцию для распределения задач между машинами. Вот как в книге Google SRE объясняется как работает BNS:

«Вместо использования IP-адреса и номера порта другие процессы подключаются к задачам Borg через имя BNS, которое преобразуется в IP-адрес и номер порта с помощью BNS. Например, путь BNS может выглядеть так: /bns/<кластер>/<пользователь>/<название задания>/<номер задачи>, что соответствует <IP-адрес>:<номер порта>».

Один из нынешних инженеров Google объяснил необходимость BNS:

«DNS считается ненадёжным и неспособным обновляться так быстро, как того требуют внутренние сервисы Google. Поэтому для привязки сервисов к сетевым протоколам и конечным точкам используется совершенно отдельная система».

Боргмон сокращение от «Борг Мониторинг». Он предназначен для отслеживания работоспособности запущенных сервисов и существует с первых дней существования Google.

Prometheus — это, по сути, «Боргмон для другой работы». Это решение для мониторинга с открытым исходным кодом, разработанное компанией SoundCloud в 2012 году по мотивам Borgmon. Prometheus часто используется вместе с Grafana с открытым исходным кодом для создания платформ мониторинга. Именно эту комбинацию использовала компания Shopify, отказавшись от Datadog в пользу собственной платформы мониторинга.

Использование Prometheus с Grafana для мониторинга работоспособности узлов. Это похоже на Borgmon в Google. Источник: Balena

Monarch — это усовершенствованная версия Borgmon, которая заменила Borgmon для мониторинга многих крупномасштабных рабочих нагрузок в Google. Вот несколько интересных фактов о Monarch:

Поставляется с базой данных временных рядов планетарного масштаба в памяти
Используется для мониторинга показателей во всей инфраструктуре Google
Горизонтально масштабируемый
Включает поддержку графиков

Наместник является преемником Монарха и часто используется для наблюдения за узлами Борга.

Analog — это внутренний инструмент логирования для Borg.

Sigma — это инструмент для управления конфигурацией кластера в Borg.

Хранение

Вполне вероятно, что Google хранит самый большой объём данных среди всех компаний в мире. В 2015 году только в Gmail хранилось несколько эксабайт данных (1 эксабайт = 1 миллион терабайт), а в 2025 году на YouTube будет размещено более 5 миллиардов видео. Так что можно с уверенностью сказать, что сегодня компания хранит сотни эксабайт данных, если не больше. В сложившихся обстоятельствах вполне понятно, что она разработала несколько собственных решений для хранения данных.

Внешние услуги

BigQuery — это бессерверное облачное хранилище данных, доступное в Google Cloud, альтернатива Snowflake или Amazon Redshift. Оно доступно в GCP с 2011 года.

Bigtable — это сервис баз данных NoSQL с низкой задержкой, совместимый с Cassandra и HBase. Google вывел Bigtable на внешний рынок в 2015 году, и теперь его можно использовать на GCP.

Spanner является базой данных по умолчанию в большинстве сервисов Google. Это глобально распределённая база данных, и в 2017 году Google сделал Spanner общедоступным; он доступен в Google Cloud.

Vitess — это решение для масштабирования и управления большими кластерами баз данных MySQL. Оно было создано в 2010 году для решения проблем с MySQL, с которыми столкнулся YouTube, и успешно справилось с этой задачей. YouTube по-прежнему активно использует Vitess. В 2018 году проект стал открытым.

Услуги только для внутренних пользователей

Dremel раньше был «внутренним эквивалентом» BigQuery. Сейчас это устаревшее название для внутреннего стека технологий бизнес-аналитики, который используется реже.

F1 заменила Dremel в качестве распределённой реляционной базы данных Google. F1 была изначально создана для поддержки бизнеса AdsWords, и её целью было создание базы данных, сочетающей в себе высокую доступность, масштабируемость систем NoSQL, таких как Bigtable, а также согласованность и удобство использования традиционных баз данных SQL. Она построена на базе Spanner.

Mesa — это распределённая база данных, предназначенная для аналитики в реальном времени и составления отчётов по рекламе.

GTape раньше была системой резервного копирования Google с использованием физических носителей. В 2011 году GTape всё ещё использовалась для восстановления Gmailпосле сбоя, повлекшего за собой потерю данных. Нынешние инженеры Google, с которыми мы общались, не уверены, используется ли GTape до сих пор или её заменило другое решение для резервного копирования.

Другие пользовательские инфра-инструменты

У Google есть сотни внутренних инструментов, в том числе несколько интересных:

BeyondCorp. Внутренняя система безопасности Google с нулевым доверием, используемая вместо VPN. Каждый запрос проверяется, поскольку предполагается, что сеть ненадежна. Аутентификация происходит через единый вход Google, после чего выполняется проверка устройства. BeyondCorp была выведена за пределы компании в 2020 году.
Dapper: распределённая система отслеживания. Подробнее.
Chubby: распределённая служба блокировки и координации для выбора лидера и хранения метаданных. Использует алгоритм Паксоса. Подробности.
B4: Частная программно-определяемая глобальная сеть Google. Подробности.
Devsite: внутренняя система для создания общедоступных страниц документации. Создана на Django (веб-фреймворк на Python).
Специальное оборудование. Google также производит собственное специализированное оборудование, такое как серверы, сетевые устройства и даже чипы. Примером может служить облачный тензорный процессор (TPU, ускоритель искусственного интеллекта), разработанный в сотрудничестве с Broadcom.

Центр обработки данных Google TPU. Серверы, сети, системы охлаждения и чипы, изготовленные по индивидуальному заказу. Источник: Data Center Dynamics / Google

Инструменты, которые помогают инженерам запускать сервисы:

Серверная платформа: Универсальная внутренняя платформа для запуска сервиса Stubby со всеми необходимыми компонентами, такими как определение владельцев, CI/CD, мониторинг и т. д. Это стало необходимостью, так как стек технологий Google усложнился. Преимущество серверной платформы в том, что она скрывает многие сложности сервисов Google. Однако из-за этого инженеры перестали понимать, к каким платформам подключается сервис, чтобы всё работало.
Boq: платформа для микросервисов, которая берет на себя большую часть работы по мониторингу, развертыванию, авторизации, аутентификации, балансировке нагрузки, интеграционному тестированию и составлению сервисов.

У Google так много собственных инструментов, что для поиска инструментов существует собственный инструмент. Есть внутренний сайт для поиска инструментов, поддерживающих определенный стек технологий, потому что даже внутри компании сложно уследить за всеми создаваемыми и устаревшими системами!

Кстати, об устаревании. Возможно, вы заметили, что Google постоянно выпускает новые версии своих инструментов (например, Borgmon → Monarch → Viceroy.) Есть старая как мир шутка о том, что в Google есть только два типа систем: устаревшие и те, что находятся в разработке.

Изображение Ману Корнет, “неофициальный карикатурист” Google

6. ИИ в Google

В 2017 году компания Google изобрела трансформеры — основную концепцию больших языковых моделей — и создала одну из самых мощных моделей искусственного интеллекта под названием Gemini. Она используется в большинстве общедоступных продуктов, таких как Workspace, Gmail и Search. Разумеется, компания уже интегрировала Gemini во многие свои внутренние системы. Cider, Critique и CodeSearch имеют интеграцию с искусственным интеллектом, которая позволяет делать следующее:

Автодополнение кода (довольно «базовый» вариант использования), а также многострочное автодополнение кода
Попросите ИИ внести изменения в текущий файл.
Задавайте вопросы о кодовой базе/текущем файле
Генерировать тесты
Попросите ИИ добавить комментарии к коду в CLs
Когда код вставляется в Cider, он автоматически адаптируется под текущий контекст. Разработчики, с которыми мы общались, считают это очень полезным

По словам инженеров, возможности искусственного интеллекта в Cider всё ещё уступают возможностям Cursor. Но в Cider можно добавлять сочетания клавиш для пользовательских подсказок, чего нет в Cursor.

Похоже, что подход Google к инструментам для написания кода на основе ИИ заключается в том, чтобы сначала завоевать доверие. Похоже, что команда разработчиков инструментов на основе ИИ уделяет первостепенное внимание выпуску действительно эффективных функций, а не недоработанных функций, которые могут ассоциироваться с ненадёжностью ИИ.

Поисковая система MOMA — это внутренняя система базы знаний, которая выполняет поиск по всем внутренним документам. Естественно, она уже как минимум два года интегрирована с искусственным интеллектом. Мы слышали, что поначалу она часто выдавала ложные результаты, но с тех пор ситуация значительно улучшилась.

Внутренние модели Gemini: для внутреннего использования доступны различные модели Gemini, в том числе большие и маленькие модели Gemini, модели с настроенными инструкциями, мыслящие модели и экспериментальные модели. Эти модели размещены на серверах, к которым можно обращаться с помощью внутренних инструментов, таких как блокноты Python, чтобы изучить их возможности. Разумеется, использование этих моделей не ограничено по стоимости.

Игровая площадка LLM: похожа на игровую площадку для разработчиковOpenAI, которая появилась раньше. Доступны различные модели и форматы Gemini, с которыми можно экспериментировать.

Ресурсы графического процессора: Графические процессоры для размещения пользовательских моделей с тонкой настройкой или ресурсы для тонкой настройки моделей обычно выделяются для каждой команды. Мы неоднократно слышали жалобы на то, что время ожидания доступа к графическим процессорам довольно велико и это становится узким местом.

Тестирование внутренних продуктов:приложение Gemini и функции искусственного интеллекта Google Workspace тестируются внутри компании перед выпуском для широкой публики.

NotebookLM: внешне представленный продукт, который позволяет «общаться» с загруженными текстовыми, аудио- и другими ресурсами. Он очень популярен в Google: мы слышали о том, что в него загружают все документы с требованиями к продукту, а затем задают вопросы по ним.

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

Рой внутренних проектов GenAI

По словамсотрудника L6, который поделился этим наблюдением, многие команды создают продукты GenAI, чтобы получить финансирование:

«В Google разрабатывается множество инструментов GenAI для конкретных организаций и команд. Руководству это нравится. Как ни странно, в наши дни это отчасти помогает получить больше финансирования».

Я понимаю, почему Google поощряет проекты в области генеративного искусственного интеллекта и выделяет сотрудников для поддержки перспективных проектов:

В худшем случае инженеры начинают работать с ИИ напрямую. Создавая ИИ-решения, они все становятся ИИ-инженерами, что само по себе ценно!
В некоторых случаях может быть создан новый продукт, который Google позже выпустит в открытый доступ. NotebookLM — пример такого продукта.

Наконец, если проект с использованием ИИ не имеет смысла, то ничего страшного не произойдёт. Google — очевидно, очень прибыльная компания, поэтому команда, потратившая месяц или два на проекты с использованием ИИ, которые не увенчались успехом, не понесёт больших убытков.

Этот «рой GenAI» и стимулирование команд к созданию ИИ-решений немного напоминают мне о политике Google в отношении 20% проектов. До начала 2010-х годов всем инженерам Google выделялся один день в неделю (20% рабочего времени) на создание всего, что они хотели, что привело к появлению таких проектов, как Gmail, Google News и AdSense. Google в целом отказался от этой политики, хотя в некоторых подразделениях компании она всё ещё действует. Карикатурист Ману Корнет работал в Google, когда это решение было отменено, и считал, что это вредит инновациям:

Инновационный дух «20% проектов» может возродиться в виде роя ИИ. Источник изображения: Ману Корне

GenAI создаст новые категории программного обеспечения, и, на мой взгляд, Google возвращает «масштабные инновации», поощряя любые проекты, связанные с искусственным интеллектом. Это вполне объяснимо, поскольку компания может потерять позиции на рынке, если не позволит своим командам создавать решения на основе ИИ.

Выводы

В технических кругах Google считается золотым стандартом в области внутренних инструментов для разработчиков и, наоборот, примером того, что происходит, когда всё в технологическом стеке сделано на заказ.

Borg, Piper, Critique и другие инструменты работают намного лучше в целом, чем инструменты для разработки, к которым имеет доступ большинство инженеров на своих рабочих местах. С другой стороны, они настолько хороши, что инженеры Google не хотят использовать публичный GCP и предпочитают работать с внутренним стеком инфраструктуры. В случае с распределёнными базами данных, такими как Spanner, они всё равно будут использовать внутреннюю версию, а не публичную!

Мы подробно рассказали о пользовательских инструментах, которые есть у инженеров технологического гиганта. Возможно, это покажется вам чрезмерным, но мы хотели дать вам рекомендации и объяснить, почему Google решил создать так много пользовательских инструментов.

В следующей статье этой серии мы расскажем о карьерном росте, внутренней мобильности и дадим несколько советов о том, как добиться успеха в такой компании, как Google.

Если вам есть что сказать по темам, затронутым в этой статье, оставьте комментарий ниже.

Перевод: https://newsletter.pragmaticengineer.com/p/google-part-2

Инженерная культура Google: часть 1

2025-10-31T06:06:33.312Z

Подробное и глубокое погружение в работу Google с точки зрения инженеров-программистов и технических руководителей. Что делает Google особенным с инженерной точки зрения, инженерные роли, оплата труда и многое другое

Сегодня технологический гигант Google с помощью таких продуктов, как Google Search, Android, Chrome, Gmail и других, охватывает больше людей, чем любая другая компания в мире, во всех отраслях. Он также управляет самым посещаемым веб-сайтом в мире и вторым по посещаемости веб-сайтом: YouTube. Основанная в 1998 году компания Google в прошлом году получила самую большую прибыль ($115 млрд после вычета всех расходов и налогов) среди всех компаний в мире.

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

Но каково на самом деле работать в Google? Какая там корпоративная культура, как всё организовано, как команды добиваются результатов — и чем Google действительно отличается от любого другого крупного технологического бизнеса?

Эта статья представляет собой «то, что я хотел бы знать о Google до того, как устроился туда инженером-программистом / менеджером по разработке».Она предназначена для всех, кто хочет работать в Google, а также для тех, кто хочет узнать, понять и, возможно, вдохновиться подходами, которые работают в одной из ведущих мировых компаний.

Эта мини-серия статей, посвященных Google, содержит больше информации о различных аспектах инженерной культуры компании, чем когда-либо публиковалось в одном месте. Мы потратили почти 12 месяцев на ее изучение, в том числе пообщались с 25 нынешними и бывшими руководителями технических отделов и инженерами-программистами Google, большинство из которых занимают должность Staff (L6) или выше.

Конечно, невозможно описать каждую деталь в компании, где работает более 60 000 инженеров-программистов, а продуктовые направления (в Google это называется orgs) и команды работают по-разному. Google предоставляет инженерам и командам большую свободу в принятии решений о том, как им работать, и, хотя мы не можем охватить всё это разнообразие, мы стремимся предоставить практичный и полезный обзор.

В первой части этого мини-сериала мы рассказываем о:

Обзор. Google приносит больше прибыли, чем Microsoft и Meta, и является крупным технологическим гигантом, в котором, вероятно, работает больше всего инженеров-программистов в более чем 25 инженерных подразделениях. Миссия компании заключается в том, чтобы «систематизировать мировую информацию и сделать её общедоступной и полезной».
Что делает Google особенным? За разнообразием подходов к работе стоит универсальная инженерная культура в отношении инструментов и практик. У Google уникальный, специально разработанный инженерный стек, и с самого первого дня компания создавала системы, отличающиеся от систем конкурентов, что сделало её «технологическим островом». Google исторически была более открытой, чем другие крупные технологические компании, в отношении своей внутренней работы. Имея более 120 активных продуктов, она больше всего похожа на Microsoft по широте своей деятельности и возможностям для инженеров-программистов работать над разными проектами.
Уровни и роли. Между уровнями L2 и L11 существует двухуровневая карьерная лестница, а роль технического руководителя (TLM) является «третьим карьерным путём». Процесс определения уровня в Google во время собеседований является самым строгим в отрасли, а «технический руководитель» — это роль, а не уровень. К другим инженерным ролям относятся SRE, EngProd, научный сотрудник, DevRel и UXE. К другим должностям, связанным с разработкой, относятся менеджеры по продуктам, менеджеры программ, TPM, дизайнеры и технические писатели.
Вознаграждение. Google платит больше, чем на других региональных рынках, и известна своими выдающимися выплатами, которые включают базовую зарплату, акции, денежные премии, а иногда и бонус за подписание контракта. Примеры таких высоких зарплат:

Инженер среднего звена (L4) обычно получает зарплату в диапазоне:

Общая сумма компенсации в США составляет 250–350 тысяч долларов
Другие регионы: 125–185 тысяч фунтов стерлингов в Великобритании, 140–180 тысяч евро в Германии, 210–260 тысяч швейцарских франков в Швейцарии, 210–280 тысяч канадских долларов в Канаде, 200–280 тысяч австралийских долларов в Австралии, 380–450 тысяч злотых в Польше и 65–88 миллионов индийских рупий в Индии

Штатный инженер-программист (L6) обычно получает зарплату в диапазоне:

Общая сумма компенсации в США составляет 550–700 тысяч долларов
Другие регионы: 270–380 тысяч фунтов стерлингов в Великобритании, 250–330 тысяч евро в Германии, 370–500 тысяч швейцарских франков в Швейцарии, 420–650 тысяч канадских долларов в Канаде, 350–550 тысяч австралийских долларов в Австралии, 750–850 тысяч злотых в Польше и 1,5–2,2 миллиона индийских рупий в Индии

Мы предлагаем пакеты для начинающих (L3), старших сотрудников (L5), руководящего состава (L7), а также специальные бонусы от Google, такие как бонусы для коллег, разовые бонусы и программы поощрения.
Google — одна из немногих компаний, которая предлагает инженерам финансово выгодную карьерную траекторию, не вынуждающую их становиться менеджерами

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

Во второй частимы дополнительно рассмотрим:

Инфраструктура планетарного масштаба. Внутренняя инфраструктура Google по умолчанию рассчитана на «планетарный масштаб», но Google Cloud не поддерживает его «из коробки»; поэтому большинство инженерных команд используют стек Google PROD, а не GCP.
Монорепозиторий. Также известный как «Google3», он на 95 % состоит из кода Google, хранящегося в одном гигантском репозитории с миллиардами строк. Разработка на основе магистрали является нормой. Кроме того, монорепозиторий не означает, что у Google монолитная кодовая база.
Технологический стек. Официально поддерживаются C++, Kotlin, Java, Python, Go и TypeScript с активным использованием Protobuf и Stubby. У Google есть руководства по языковому стилю для большинства языков, которые почти всегда соблюдаются.
Инструменты для разработки. Набор инструментов для разработки отличается от любого другого рабочего места. Прощайте, GitHub, Jenkins, VS Code и другие известные инструменты: здравствуйте, Piper, Fig, Critique, Blaze, Cider, Tricorder, Rosie и другие.
Вычисления и хранение данных. Borg, Omega, Kubernetes, BNS, Borgmon, Monarch, Viceroy, Analog, Sigma, BigQuery, Bigtable, Spanner, Vitess, Dremel, F1, Mesa, GTape и многие другие пользовательские системы, на которых работает Google. Этот стек инфраструктуры не похож ни на один другой.
ИИ. Gemini интегрирован в инструменты для разработчиков и большинство внутренних инструментов, и Google всячески поощряет команды к созданию ИИ, когда это возможно. Команды могут запрашивать ресурсы графического процессора для тонкой настройки моделей, и существует множество внутренних проектов GenAI.

Эта статья почти в два раза длиннее большинства подробных обзоров. О Google можно рассказать очень много интересного!

Похожие подробные обзоры см. в Инсайдерском обзоре инженерной культуры Meta, Инсайдерском обзоре инженерной культуры Amazon и других подробных обзорах инженерной культуры, в том числе в OpenAI, Stripe и Figma.

Примечание для программистов: на этой неделе выпуск подкаста The Pragmatic Engineer выйдет завтра (в среду), а выпуск The Pulse не выйдет.

1. Общий обзор

Давайте начнём с краткого обзора показателей, благодаря которым у Google больше пользователей и клиентов, чем у любой другой компании в мире:

#1 и #2 самых посещаемых сайта: Google.com — это самый популярный сайт в мире, а YouTube занимает второе место. Google.com посещают 85 миллиардов раз в месяц — больше, чем следующие 9 самых посещаемых сайтов, вместе взятых
Android: около 4,2 миллиарда пользователей (около 75 % мирового рынка смартфонов)
Chrome: около 3,45 миллиарда пользователей (около 65 % мирового рынка браузеров)
Gmail: примерно 1,8 миллиарда активных пользователей

В 2015 году, когда Google сменила название на Alphabet, это было сделано для того, чтобы отделить основной бизнес по веб-поиску, который приносил львиную долю дохода, от убыточных проектов, таких как Waymo, Google DeepMind, Google Fiber и т. д. На практике почти весь доход Alphabet поступает от подразделения Google, и с тех пор мало что изменилось. В этой статье при упоминании Alphabet используется название «Google».

Невероятно прибыльно и с большим количеством рекламы

В абсолютном выражении Google в настоящее время является самой прибыльной компанией в мире. За последние 12 месяцев её прибыль (чистый доход) составила 115 миллиардов долларов при выручке в 371 миллиард долларов. Для сравнения приведём чистые доходы других крупных технологических компаний за этот период:

Microsoft: 101 миллиард долларов (из 281 миллиарда долларов выручки)
Apple: 99 миллиардов долларов (доход — 408 миллиардов долларов)
Meta: 71 миллиард долларов (доход — 178 миллиардов долларов)
Amazon: 70 миллиардов долларов (доход — 670 миллиардов долларов)

По своей сути Google по-прежнему остаётся рекламной компанией: около 75 % дохода поступает от продажи рекламы в Google Поиске, на YouTube и в сети Google Рекламы. Однако у компании есть несколько сервисов, которые не зависят от рекламы:

Google Cloud:третий по величине поставщик облачных услуг после AWS и Azure, годовой доход которого составляет более 50 миллиардов долларов (около 13 % от общего дохода). В эту цифру включен доход от Google Workspace.
Оборудование плюс подписки: смартфоны Pixel, гаджеты для умного дома Nest, носимые устройства Fitbit, подписки на YouTube Premium и Google One. Google зарабатывает на этом более 40 миллиардов долларов в год (около 10 % дохода)

У Google есть несколько убыточных подразделений, которые в будущем могут начать приносить прибыль, например:

Gemini и искусственный интеллект: Google является лидером в области искусственного интеллекта благодаря своим моделям Gemini, которые интегрированы в несколько продуктов, таких как веб-поиск. Это как бесплатный, так и платный продукт, который в настоящее время, скорее всего, приносит убытки.
Waymo: лидер в области беспилотных транспортных средств, который в настоящее время обслуживает более 1 миллиона поездок в месяц в Сан-Франциско и Финиксе, США.
Google Fiber: сверхбыстрый оптоволоконный провайдер со скоростью передачи данных от 1 до 8 Гбит/с. Он работает в 25 городах в 19 штатах США, включая Остин (Техас), Атланту (Джорджия), Чикаго (Иллинойс), Майами (Флорида), Денвер (Колорадо) и Сан-Диего (Калифорния).

Структура доходов Google на 2024 год

Глобальные офисы

В Google по всему миру работает 183 000 человек, а в 2022 году их число достигло пика — 190 000 сотрудников. В 2023 году произошли массовые увольнения, и с тех пор численность сотрудников перестала расти.

Google уже не развивается так быстро, как до 2022 года

Как упоминалось выше, в Google работает около 60 000 инженеров-программистов, о чём мы можем судить по тому, что в 2020 году их было 50 000, как указано в книге «Разработка программного обеспечения в Google» — около 35 % от общего числа сотрудников. Рост численности персонала с тех пор говорит о том, что сегодня там работает 60 000 инженеров. Это делает Google одним из крупнейших работодателей для инженеров-программистов. В Amazon работает почти 35 000 разработчиков, а в Meta около 32 000 инженеров-программистов. Мы уверены, что у Google самый высокий «коэффициент инженеров-программистов» среди крупных технологических гигантов.

У Google более 25 инженерных офисов. Самый крупный из них:

США: Маунтин-Вью (штаб-квартира компании) и прилегающий к нему район залива Сан-Франциско, Сан-Франциско, Нью-Йорк и Сиэтл (Киркленд), а также несколько небольших офисов в таких городах, как Кембридж (Массачусетс), Лос-Анджелес (Калифорния), Сан-Диего (Калифорния), Питтсбург (Пенсильвания), Роли и Дарем (Северная Каролина).
Канада: Торонто, Монреаль, Ватерлоо и Китченер
Европа: Цюрих (Швейцария), Лондон (Великобритания), Дублин (Ирландия), Мюнхен (Германия) и Париж (Франция) — крупнейшие. К более мелким офисам относятся Гамбург (Германия), Милан (Италия), Амстердам (Нидерланды), Мадрид (Испания), Стокгольм (Швеция), Копенгаген и Орхус (Дания), Хельсинки (Финляндия), Варшава и Краков (Польша), Прага (Чехия), Вильнюс (Литва), Бухарест (Румыния) и Будапешт (Венгрия).
Индия: Крупнейшими офисами являются Бангалор и Хайдарабад.
Южная Америка: Мехико (Мексика), Сан-Паулу и Белу-Оризонти (Бразилия)
Ближний Восток, Азия и Австралия: Тель-Авив (Израиль), Токио (Япония), Сидней (Австралия), Новый Тайбэй (Тайвань)

У Google есть более 70 офисовв более чем 50 странах. Общее количество офисов превышает количество инженерных офисов, потому что во многих офисах Google нет команд разработчиков программного обеспечения, а есть нетехнические команды, такие как отделы продаж, маркетинга, консалтинга (например, для Google Cloud) и другие.

Хотя это и не является стандартной практикой, Google может нанимать инженеров для работы в основном в неинженерных отделах в качестве «одиночек». Один из нынешних инженеров Google рассказал нам:

«Одиночки встречаются не так уж часто, скорее это исключения из правил. Некоторые из них остались после короткого периода удалённой работы во время пандемии, некоторые — специалисты или очень высокопоставленные сотрудники, у которых больше возможностей для ведения переговоров и выбора места работы».

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

История, миссия, ценности

Как известно, Google был основан аспирантами Ларри Пейджем и Сергеем Брином, которые разработали более эффективный алгоритм поисковой системы под названием PageRank. Использование PageRank для поиска в интернете позволило значительно улучшить результаты по сравнению с самыми популярными поисковыми системами того времени, такими как Yahoo!, AltaVista, Lycos и Ask Jeeves. Некоторые из них были порталами, на которых «рекомендовались» сайты для посещения (например, AltaVista), а другие представляли собой примитивные поисковые системы, выдававшие до 15 не особо точных результатов.

Ведущие поисковые системы в 2000 году. Google отказался от популярного в то время дизайна «избранных сайтов»

Остальное, как говорится, уже история: через два года после запуска Google стал доминирующей поисковой системой, а также глаголом («давай погуглим это»). Он выдавал больше релевантных результатов и имел гораздо более удобный интерфейс, чем его конкуренты.

Со временем миссия компании изменилась:

«Систематизировать мировую информацию и сделать ее общедоступной и полезной». Это была миссия компании с момента ее основания в 1998 году, и она не изменилась.
«Не будь злым». Неофициальный девиз, который был частью кодекса поведения Google примерно с 2000 года, чтобы напоминать сотрудникам о необходимости действовать этично. Он оставался актуальным до 2015 года, когда Google стала частью Alphabet.
«Поступай правильно». Девиз компании с 2015 года, который заменил собой «не будь злым».

У Google также есть пять основных ценностей:

Защита пользователей
Ответственный подход к созданию и внедрению ИИ
Расширяющиеся возможности
Помощь в решении проблем общества
Строительство для всех

Нынешние сотрудники Google сообщают, что эти ценности не особо учитываются в повседневной работе и кажутся довольно абстрактными и «корпоративными». Такой поверхностный подход отличается от подхода конкурентов, таких как интернет-магазин Amazon, чьи 16 принципов лидерства с таким же успехом могли бы быть высечены на камне на стенах.

«Гугловость» — это то, что объединяет большинство сотрудников компании. Это качество, на которое Google обращает внимание при найме сотрудников, и которым должны обладать все работники. Этот термин не имеет четкого определения, но подразумевает, что сотрудник должен быть умным, легко адаптирующимся и командным игроком, с которым приятно работать. Подробнее о «гугловости» мы рассказываем в разделе «Найм».

Игривый и амбициозный: стиль Google начинается со знаменитой кепки «Нуглер». Источник: бывший инженер Google Мохаммад Фраз («Хуглер») из своего видео «Набор для вступления в Google»

В собственных продуктах Google можно найти множество примеров «гугловости», которые показывают, насколько ориентирована на инженеров корпоративная культура. Например, попробуйте ввести в Google запрос «рекурсия»:

Рекурсия — непростая для понимания концепция. Вместо того чтобы объяснять, Google просто демонстрирует эту концепцию в поиске Google, предлагая вариант «Вы имели в виду: рекурсия?» Нажмите на эту ссылку, и вы вернётесь на ту же страницу… рекурсия!

2. Что делает Google особенным?

Мы поговорили с 25 нынешними и бывшими сотрудниками Google и выяснили, что отличает эту компанию от других крупных технологических корпораций.

Никакого “единого” Google

Google разделена на продуктовые направления, которые функционируют как отдельные компании. Внутри компании их часто называют «направлениями» или «организациями». Основные направления:

Знания и информация: включает поиск Google, внутренние платформы и основные сервисы
YouTube: всё, что связано с платформой для обмена видео
Облако: Gоблачная платформа и рабочее пространство Google
Реклама и монетизация: такие продукты, как Google Ads, AdSense и AdMob
Платформы и устройства: программные платформы, такие как Android, Chrome, Chrome OS, и аппаратные устройства, такие как Pixel, Nest, Fitbit, Chromecast, Google TV и Google Home

У организаций есть свои цели, приоритеты, показатели и графики планирования. А внутри каждой организации команды обладают достаточной независимостью, чтобы определять свой подход к работе. Опыт инженера в одной команде организации может сильно отличаться от опыта другого инженера в другой команде другой организации! Вот как один из нынешних инженеров Google объяснил нам это:

«Ваш опыт во многом зависит от вашей команды. Если вы работаете над зрелым продуктом, вам предстоит пройти через множество этапов. Если вы работаете над проектом, который только запускается, вам придётся написать больше кода».

Технический руководитель подтвердил, что приоритеты у разных PA различаются.

«Приоритеты между продакт-агентами сильно различаются. Честно говоря, они также различаются между подгруппами в рамках одного продакт-агента. В Google принято договариваться между собой, чтобы добиться результата, а не следовать приоритетам, установленным сверху. Лично я считаю, что такое количество переговоров неэффективно и утомительно, и я бы не отказался от более четких указаний сверху!»

Единая инженерная культура

Несмотря на то, что продуктовые направления и команды работают независимо друг от друга, инженерная культура, судя по отзывам инженеров, с которыми мы общались, довольно универсальна.

Практики, инструменты и технологические стеки очень похожи. Независимо от того, работает ли человек в YouTube, в отделе рекламы и коммерции или в другой продуктовой области, он использует одни и те же внутренние инструменты, одни и те же процессы для проверки кода, тестирования и документирования, а также одни и те же процессы монорепозитория и непрерывной интеграции — за исключением нескольких проектов с открытым исходным кодом, таких как Android и Chromium.

Тот факт, что большинство из 60 000 инженеров Google используют практически идентичные инструменты, означает, что для перемещения команд требуется минимум усилий. Это упрощает внутренние перемещения, так как предполагает гораздо меньше изменений в процессах и инструментах, а значит, и меньшую когнитивную нагрузку, что в целом ускоряет адаптацию.

Политика и культура в разных подразделениях и командах отличаются. Невозможно, чтобы культура в тысячах инженерных команд, разбросанных по десяткам локаций, была одинаковой. Вот основные различия, по мнению инженеров:

Политика. Как вы влияете на лиц, принимающих решения в вашей организации, чтобы они отдавали приоритет тому, что важно для вашей команды? Для этого нужно хорошо разбираться в тонкостях влияния, знать самых влиятельных людей и сделать их своими союзниками. Это непростая задача для любой компании среднего или крупного размера. Ранее мы рассказывали о внутренней политике для разработчиков и менеджеров.
Культура и эффективность. Google утверждает, что существует «единая инженерная культура», но инженеры рассказали нам, что в разных организациях расставляют приоритеты по-разному: одни больше ценят качество, другие сосредоточены на инновациях, а третьи ставят во главу угла быструю доставку. Оценка эффективности называется GRAD (Google Reviews and Development) и зависит от организации, то есть ожидания для каждого уровня немного отличаются в разных организациях. Мы рассмотрим эту тему во второй части этой мини-серии.

Уникальный инженерный пакет

Инженерная организация Google существует в другом мире, отличном от того, в котором работают другие технологические компании. Всё сводится к одному: масштабу.

Google пришлось создавать системы, способные обслуживать сотни миллионов пользователей, за десять лет до того, как какая-либо другая компания в мире достигла аналогичных масштабов. Это означало, что компания внедряла уникальные системы и решения для масштабных задач по масштабированию, а общедоступные инструменты появились за пределами Google лишь десять лет спустя.

Какие бы инструменты или поставщиков ни использовала ваша компания для масштабирования, скорее всего, Google создала свои собственные версии на 10 или более лет раньше.

Борг (управление контейнерами в масштабе): предшественник платформы для оркестрации контейнеров Kubernetes
Боргмон/Монарх (наблюдаемость в масштабе): предшественник решения для наблюдаемости, Datadog
Поиск кода (поиск кода в больших кодовых базах): предшественник поставщика услуг поиска кода Sourcegraph
Piper (система контроля версий в масштабе Google): предшественник лидера в области контроля версий, GitHub

Google занимает необычную позицию: ему нет смысла внедрять такие стандартные отраслевые инструменты, как GitHub и Kubernetes, поскольку его существующий стек хорошо интегрирован. Один из инженеров Google объяснил, почему компания редко использует внешние сервисы или инструменты, даже если они могут справиться с масштабами Google:

«Благодаря Google все работает так хорошо. Поскольку весь технологический стек разработан внутри компании, каждая система имеет встроенную прозрачную интеграцию с корпоративной системой аутентификации и авторизации, а также с «волшебной» системой выставления счетов.Внешние средства всегда должны:Предоставлять абстракции аутентификацииПредоставлять абстракции выставления счетовЭти два ограничения делают внедрение новых инструментов действительно чертовски сложным!”

С самого начала создавайте системы по-разному

С момента своего основания компания Google отличалась от других компаний в сфере разработки.С самого начала, в 1998 году, компания делала ставку на скорость и надёжность как отличительные черты всех своих продуктов. Они рассчитывали, что инструмент веб-поиска справится с нагрузкой планетарного масштаба, как и последующие продукты, такие как Gmail, который в 2004 году был запущен с 1 ГБ бесплатного хранилища. Это было неслыханно в то время, когда хранение данных стоило гораздо дороже. Предполагалось, что эти продукты должны были быть рассчитаны на миллиарды пользователей.

Чтобы достичь такого масштаба, Google с самого начала пришлось создавать собственный технологический стек, поскольку не существовало готовых технологических стеков, способных справиться с нагрузкой планетарного масштаба. В конце 90-х общепринятой практикой было вертикальное масштабирование машин, то есть покупка максимально мощного сервера (называемого мейнфреймом) и попытка запустить приложение на одном сервере. Компания Sun была одним из крупнейших производителей мейнфреймов того времени, и большинство компаний вкладывали значительные средства в дорогостоящее высокопроизводительное оборудование.

Компания Google пошла другим путём, решив закупать дешёвое стандартное оборудование и создавать кластеры центров обработки данных, в которых использовались десятки тысяч относительно недорогих машин для обработки нагрузок, с которыми не могли справиться даже самые большие мейнфреймы в мире.

Вот как работал поисковый кластер Google в 2003 году, согласноофициальному документу Googleописывающему архитектуру кластера Google:

«Чтобы обеспечить достаточную пропускную способность для обработки запросов, наш сервис состоит из нескольких кластеров, распределённых по всему миру.В каждом кластере насчитывается несколько тысяч машин, а географически распределённая система защищает нас от катастрофических сбоев в работе центров обработки данных (например, вызванных землетрясениями или масштабными отключениями электроэнергии).Система балансировки нагрузки на основе DNS выбирает кластер с учётом географической близости пользователя к каждому физическому кластеру. Система балансировки нагрузки минимизирует время обработки запроса пользователя, а также учитывает доступную пропускную способность в различных кластерах.

В то время такой подход был революционным, и ни одна другая компания не публиковала столько подробностей о своей индивидуальной настройке центра обработки данных. Google продолжала публиковать информацию о том, как она организовывала и эксплуатировала кластеры, например, в этой статье в «Инженерии надёжности сайтов в Google» книге:

«Топология центра обработки данных Google:

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

Топология кампуса центра обработки данных Google. Источник: Отдел обеспечения надёжности сайтов в Google

Необычная открытость

По сравнению с другими крупными технологическими компаниями Google очень открыто и прозрачно рассказывает о своей работе как внутри компании, так и за её пределами. Обратите внимание, что с 2020 года эта открытость, похоже, снизилась.

Внутри компании по сути всёбыло доступно всем сотрудникам: документы по планированию, стратегии, код, документация и т. д. После утечек в 2020 году доступ в масштабах всей компании был заменён на доступ в масштабах продуктовой области. Бывший инженер Google Cloud рассказал нам:

«Политика открытости по умолчанию» начала меняться примерно в 2019–2020 годах. Именно тогда Google начал заниматься более спорными темами, и в прессу стало чаще попадать конфиденциальные документы.По умолчанию доступ к внутренним документам Google Docs был открыт для всех сотрудников компании. Примерно с 2019–2020 годов доступ по умолчанию предоставляется только на уровне подразделения, то есть вы можете искать документы только в своём подразделении, а не во всём Google.

Внешне Google опубликовал более 10 000 статей с подробным описанием того, как работает компания и как создаются продукты. Ни одна другая компания не публиковала столько информации о своей внутренней работе.

Как известно, в 2017 году компания Google опубликовала статью под названием «Внимание — это всё, что вам нужно», в которой описывалась новая сетевая архитектура под названием «трансформеры». Эта статья легла в основу больших языковых моделей (БЯМ), и эта идея лежит в основе ChatGPT и других БЯМ. Опубликовав эту статью вместо того, чтобы придержать свой прорывной метод, компания Google, возможно, ускорила развитие ИИ на несколько лет!

Технологический остров

В Google всё, что связано с разработкой программного обеспечения, уникально. Новички могут забыть о том, как использовать систему контроля версий, как запускать CI/CD и как управлять инфраструктурой. В Google используются разные уникальные системы для всего, что связано с созданием, развертыванием и поддержкой программного обеспечения, и всему этому нужно учиться.

Термин «технологический остров» был придуман Урсом Хёльцле, восьмым сотрудником Google, во внутреннем документе почти десять лет назад. Как рассказал нам бывший сотрудник Google:

Термин «технологический остров» впервые был использован Урсом Хёльцле много лет назад в его докладе о том, что уникальный технологический стек Google (он же «жизнь на собственном технологическом острове») может стать проблемой в долгосрочной перспективе. В своём докладе он утверждал, что нам следует искать способы приблизиться к «технологическому материку», а не продолжать существовать на нашем собственном острове.В начале 2000-х подход «по-гугловски» был преимуществом. Но по мере того, как отрасль развивалась и появлялись новые технологии с открытым исходным кодом, этот «технологический остров» начал негативно влиять на производительность. Например, новым сотрудникам Google требуется больше времени на обучение по сравнению с компаниями, которые используют «стандартные для отрасли» технологические стеки.

Дискуссия о том, должен ли Google оставаться технологическим островком или ему следует стать ближе к материку, вызывает споры. Вот что рассказал нам действующий инженер Google:

«Сама идея перехода на более стандартизированный стек технологий вызывает некоторые разногласия внутри Google. Некоторые давние сотрудники Google, с которыми я общался, настолько привыкли к внутренним технологиям, что искренне считают их лучшими. Конечно, есть и те, кто придерживается противоположного мнения и пытается перевести Google на GCP, поскольку сервисы GCP общедоступны и не привязаны к Google, а значит, являются «мейнстримом». Однако все попытки провалились.В наши дни более распространена точка зрения, согласно которой Google следует использовать гибридный подход: использовать GCP и объединять его с открытым исходным кодом, когда это целесообразно. Это отличается от подхода «поднять и перенести», при котором всё переносится на более стандартный стек. Гибридный подход предполагает, что некоторые сервисы Google никогда не будут работать без внутренних технологий.”

Делаю много вещей

По сравнению с такими компаниями, как Meta и Amazon, Google создаёт множество продуктов, платформ и технологий.

Поисковая система: основной продукт
Операционные системы: Android и ChromeOS
Браузер: Chrome
Аппаратное обеспечение: устройства Pixel и ноутбуки ChromeOS
Облачный провайдер: Google Cloud
Корпоративные инструменты: Google Документы и Google Meet
Платформа для контента: YouTube
Сервис потоковой передачи музыки: YouTube Music
Инструменты разработчика: Flutter, Firebase
Языки программирования и открытый исходный код: Go, Kubernetes, Angular, PyTorch и другие

Крупнейшая технологическая компания, наиболее близкая к Google по широте ассортимента продуктов, — это, вероятно, Microsoft. У производителя Windows также есть поисковая система (Bing), операционная система (Windows), браузер (Edge), аппаратное обеспечение (Surface), облачный провайдер (Azure), корпоративные инструменты (Office 365, Microsoft Teams), социальные сети (LinkedIn, GitHub), инструменты для разработчиков (VS Code) и языки программирования / открытый исходный код (TypeScript, .NET и другие).

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

У Google более 120 активно разрабатываемых продуктов

3. Уровни и роли

В Google есть карьерная лестница с двумя направлениями для инженеров-программистов и технических руководителей, а также интересная должность под названием «технический ведущий менеджер» (Tech Lead Manager, TLM). На каждом уровне, как правило, одинаковая общая сумма вознаграждения (подробнее о вознаграждении мы расскажем в следующем разделе).

Это значит, что, работая индивидуально, можно зарабатывать столько же, сколько менеджеры и директора, при этом не нужно управлять инженерами. На уровнях L5 и L6 инженеры, которые берут на себя обязанности технического руководителя, часто получают возможность подняться по карьерной лестнице до уровня менеджера. Те, кто хочет руководить небольшими командами, но не хочет становиться менеджерами, могут быть техническими лидами. Вот как выглядят уровни на этих параллельных путях:

Инженерные уровни Google: IC, менеджер и TLM

Мы опубликовали подробный обзор сходств и различий между ролями IC, менеджера и TLM в инженерных карьерных траекториях в крупных технологических компаниях и стартапах.

Карьера программиста

Карьерная лестница SWE мало чем отличается от карьерных лестниц в других крупных технологических компаниях и стартапах. Отчасти это связано с тем, что многие компании создают свои карьерные лестницы для инженеров, взяв за образец Google.

В Google самые строгие требования к уровню подготовки на собеседованиях. Новых инженеров часто понижают в должностикогда они приходят: например, старший инженер в Amazon может получить должность L4 (старший инженер III уровня), а штатному инженеру в быстрорастущей компании могут предложить должность L5 (старший инженер) в Google. Обычно это происходит по двум причинам:

Комитет по найму Google принимает решения о найме и повышении в должности, и понижение в должности встречается гораздо чаще. Компания скорее наймёт человека, у которого есть потенциал для роста, чем возьмёт того, кто не справится с работой.
Google платит больше, чем в среднем по рынку. Даже при понижении в должности предложение от Google часто означает повышение зарплаты. Если есть предложение с более высокой зарплатой на должности, с которой будет проще перейти на следующий уровень, то почему бы не согласиться?

Подробнее о понижении и повышении уровня мы рассказываем в выпуске «Американские горки» стажа.

«Технический руководитель» — это должность, а не уровень. Технические руководители отвечают за технические аспекты проектов, такие как разработка архитектуры, принятие технических решений, определение приоритетности задач и управление проектами. Они назначаются техническим руководителем каждого проекта и не занимаются управлением персоналом.

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

Стать научным сотрудником Google очень сложно. В настоящее время в компании работает не более 20 научных сотрудников Google из 60 000 инженеров; на этом уровне находятся менее 0,1 % всех инженеров Google. В некотором смысле это логично: перейти на следующий уровень после уровня L6 (штатный сотрудник) становится экспоненциально сложнее, поэтому логично, что сотрудников уровня L7 гораздо меньше, чем сотрудников уровня L6, а сотрудников уровня L8 — ещё меньше, чем сотрудников уровня L7, и т. д.

Среди известных сотрудников Google Урс Хёльцле (инженер № 8 и первый вице-президент Google по инженерным вопросам), Амит Сингхал (возглавлял Google Search в течение 15 лет) и Блейз Агуэра-и-Аркас (технический директор по технологиям и обществу).

В Google всего два старших научных сотрудника (на уровне L11): Санджай Гхемават и Джефф Дин. Эта пара внесла огромный вклад в создание масштабируемой и отказоустойчивой инфраструктуры Google, в том числе написав MapReduce. The New Yorker рассказывает об их истории в статье «Дружба, которая сделала Google огромным».

Роль Ведущего технического менеджера

Должность технического руководителя появилась в Google раньше, чем в других компаниях, таких как Uber, была введена аналогичная должность. Это сочетание функций индивидуального разработчика и менеджера, при котором индивидуальный разработчик уровня L6 или выше принимает на себя ответственность за 4–6 непосредственных подчиненных и получает должность «технического руководителя».

По словам технических руководителей Google, логика этой роли такова:

Многие инженеры Staff+ (на уровне L6 и выше) не хотят становиться менеджерами на полную ставку или руководить большими командами
Тем не менее многие из них — отличные технические руководители
Для проектов, в которых задействована небольшая команда — максимум 5–6 человек, — почему бы не создать «гибридную» руководящую должность? Технический руководитель L6+ фактически выполняет функции менеджера
Ограничение: команда не может состоять более чем из 6 человек
В качестве отдельной роли TLM учитывает, что они занимаются некоторыми аспектами управления персоналом и не могут выполнять столько же работы, как коллеги, не имеющие отчетов

Роль TLM более распространена в Google, чем в других крупных технологических компаниях. Как рассказал нам действующий штатный инженер:

«Я не видел, чтобы TLM использовались так же широко, как в Google. На позициях TLM обычно работают самые сильные специалисты, управляющие небольшими командами. Цель состоит в том, чтобы выпускать продукт быстрее и с меньшими бюрократическими проволочками. Например, у меня был TLM уровня L7, и я видел, как TLM уровня L8 управляют командами из 4–6 специалистов.Эти TLM, как правило, являются оченьталантливыми специалистами, которые хотят работать очень быстро с очень небольшой командой. Роль TLM также довольно распространена в исследовательских проектах».

Самый большой недостаток роли TLM заключается в том, что продвигаться по карьерной лестнице в этой должности сложно. На уровнях IC и менеджер достаточно чётко обозначены требования для перехода на следующий уровень. Но инженер, занимающий должность TLM, может рассчитывать на то, что останется на этом уровне до тех пор, пока он занимает эту должность. Это ещё одна причина, по которой эта должность больше подходит для специалистов IC уровня 7+, которые не ожидают — и даже не хотят — повышения.

Карьерный рост менеджера

Менеджеры по инжинирингу отвечают за продуктивность, эффективность и удовлетворённость своих подчинённых. Наиболее распространённое соотношение между менеджером и инженерами — от 1:8 до 1:12. В крайних случаях это может быть всего 3 подчинённых или около 30. Чем больше число, тем меньше внимания менеджер может уделять каждому подчинённому и тем выше риск выгорания.

В обязанности технических руководителей входит:

Обучение инженеров для их профессионального роста
Содействие карьерному росту сотрудников
Управление эффективностью: пройдите процедуру GRAD (Google Reviews and Development)
Участвуйте в найме сотрудников и обсуждении вопросов оплаты труда. Чем выше должность технического руководителя, тем больше у него возможностей для участия. Директора и вышестоящие руководители часто имеют больше прав при обсуждении вопросов оплаты труда

Менеджеры по инжинирингу должны быть инженерами. В книге «Инженерия программного обеспечения в Google» объясняется, почему компания требует наличия инженерного образования:

«Многие компании нанимают квалифицированных менеджеров по работе с персоналом, которые могут практически ничего не знать о разработке программного обеспечения, чтобы те руководили инженерными командами. Компания Google с самого начала решила, что менеджеры по разработке программного обеспечения должны иметь инженерное образование. Это означало, что нужно было нанимать опытных менеджеров, которые раньше были инженерами-программистами, или обучать инженеров-программистов менеджменту».

Раньше Google гораздо меньше доверял своим техническим руководителям.Бывший штатный инженер Google рассказал нам:

«В первые годы Google не доверял менеджерам. Все системы были устроены таким образом, что влияние отдельных менеджеров было ограниченным. Решения о продвижении по службе принимались не менеджерами, а комитетом по продвижению, состоящим из инженеров! Ваша оценка как менеджера была лишь одним из факторов, учитываемых комитетом.Менеджеры не могли запрещать членам команды переходить в другие команды и не могли устанавливать ограничения на приём в свои команды.В какой-то момент менеджеры стали отвечать за вашу зарплату, но не за долю в компании, которая предоставлялась на уровне директора, поэтому ваш менеджер даже не знал о вашем полном компенсационном пакете.

Сегодня менеджеры пользуются большим доверием, но по-прежнему не имеют решающего голоса при распределении акций, хотя и видят общую сумму вознаграждения своих непосредственных подчинённых.

Подробнее об управлении и лидерстве в Google читайте в главе «Как руководить командой» в книге «Разработка программного обеспечения в Google».

Другие роли

Помимо инженеров-программистов (SWE) и технических менеджеров, в Google есть и другие инженерные должности.

Инженеры по обеспечению надёжности сайтов (SRE) — это должность, появившаяся в Google в 2003 году. «Сайт» изначально означал «Google.com», а SRE отвечают за работу крупных сайтов и приложений. Как вспоминал Дэйв О’Коннор, один из первых SRE, о происхождении этой должности:

«В 2003 году появилась должность SRE-инженера. Бену Трейнору Слоссу было поручено создать «производственную команду» Google, и, по его собственным словам, он создал «то, что получается, когда вы просите инженера-программиста разработать операционную команду». Так в Google появилась должность SRE-инженера. С самого начала в SRE-команде в разной степени присутствовали специалисты по системам и операциям, а также инженеры-программисты. Значительная часть работы команды заключалась в создании инструментов и методов, необходимых для управления автопарком Google.

В каждой продуктовой организации есть собственная команда SRE, обычно состоящая из 30–200 специалистов. Они сотрудничают с инженерами-программистами, как описано в Как Google SRE и разработчики работают вместе:

Как SRE и разработчики сотрудничают в Google

Роль SRE была популяризирована в книге Google о SRE в 2016 году. Это бесплатная книга, которую можно прочитать здесь. Мы также подробнее рассказали о роли SRE в статье Что такое инженерия надёжности.

Другие роли, о которых стоит упомянуть:

EngProd: Функция, которая обеспечивает инженеров и команды необходимыми инструментами и средой для работы над продуктом: настройка тестовых стендов, запуск приложений, упаковка, настройка тестовых лабораторий для устройств, промежуточных сред и т. д.

Исследователи (RS). Работают вместе с SWE и занимаются исследованиями. Требования к кандидатам очень высоки, и одной докторской степени недостаточно. На самом деле в Google большинство людей с докторской степенью, которые занимаются исследованиями, — это SWE, а не RS, которые должны не только иметь внушительный список научных публикаций, но и хорошо разбираться в программировании.

DevRel:сокращение от «отношения с разработчиками», иногда также используется термин «поддержка разработчиков». В обязанности входит:

Создание статей и видеороликов для инженеров
Выступления на конференциях и онлайн
Быть «нулевым клиентом»: первопроходцами и тестировщиками новинок
Фрикшн-логгинг (также называемый «фрикшн-ингом»): ведение блога с явной целью зафиксировать моменты трения

DevRel — это инженерная должность, а не маркетинговая; многие функции и инструменты для продуктов Google созданы DevRels.

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

UX-инженеры (UXE): это подмножество SWE и гибридная роль, в рамках которой UXE работают с командами дизайнеров и разработчиков над такими задачами, как:

Создание прототипов
Разработка интерфейса
Разработка дизайн-систем, например работа над Material Design
Разработка фреймворка пользовательского интерфейса

Недостаток работы UX-дизайнером в Google по сравнению с работой SWE-инженером заключается в том, что внутри компании гораздо меньше возможностей для карьерного роста, потому что вакансий SWE в 10 раз больше, чем вакансий UX-дизайнеров.

Инженер по продажам (SE), инженер по работе с клиентами (CE), инженер по техническим решениям: эти должности чаще встречаются в подразделении Google Cloud. Инженеры по продажам работают с клиентами GCP и обычно участвуют в процессе продаж. Инженеры по работе с клиентами взаимодействуют с отделами продаж, клиентами и продуктовыми командами и выполняют функции, аналогичные инженерам с расширенным доступом (FDE). Инженеры по техническим решениям часто работают с крупными клиентами, в том числе из государственного сектора, выполняя функции, аналогичные функциям инженеров с расширенным доступом. Подробнее о FDE мы рассказали в выпуске Кто такие инженеры передового базирования и почему они так востребованы?

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

Вы можете просмотреть все открытые вакансии Google на сайте вакансий.

Неинженерные роли в технической организации: люди, занимающие эти должности, обычно не пишут код или делают это крайне редко. Разработчики часто работают с:

Менеджеры по продукту: они работают с разработчиками, чтобы убедиться, что нужная вещь будет создана.
Менеджеры программ: похожи на менеджеров по продукту, но они управляют проектами, процессами или операциями.
Менеджеры технических программ (TPM): выполняют те же функции, что и менеджеры программ, но обладают дополнительными техническими знаниями. Ранее мы рассказывали о том, чем занимаются TPM и чему инженеры-программисты могут у них научиться.
Дизайнеры: существует множество разновидностей этой профессии: UX-дизайнеры, UI/визуальные дизайнеры, моушн-дизайнеры, исследователи пользовательского опыта, UX-исследователи (UXR), менеджеры программ дизайна (DPM) и разговорные дизайнеры (CUI)
Технические писатели: создают документацию и примеры кода, которые публикуются на страницах для разработчиков, например на Android, в облаке и т. д.

4. Компенсация

Если Google и известен чем-то среди технических специалистов, так это компенсацией. Девяносто девять процентов компаний не могут или не хотят платить столько, сколько предлагает Google, и ни для кого не секрет, что компания готова платить больше, чем конкуренты, за высококлассных специалистов и кандидатов, которых они действительнохотят привлечь.

Будучи менеджером в Uber, я столкнулся с такой ситуацией, когда мы набирали сотрудников в новый офис в Бангалоре, Индия. Кандидаты, которым мы предлагали работу, а также Google, почти всегда выбирали не Uber. Дело в том, что, когда они сообщали Google о нашем предложении, компания просто добавляла 10%, чтобы перебить наше предложение.

Структура компенсации

Компенсационный пакет состоит из нескольких компонентов:

Базовая зарплата.Годовая компенсация выплачивается раз в две недели в США и Канаде и ежемесячно в Европе. Это фиксированная сумма, на которую не влияют никакие факторы, связанные с эффективностью работы.
Акции / паи. При трудоустройстве в Google вы получаете новый пакет акций, которые распределяются в течение 4 лет. 33 % распределяются в первый год, 33 % — во второй, 22 % — в третий и 12 % — в четвёртый. После распределения акций их можно продать в любое время или оставить у себя.
Бонус за трудоустройство. Не предоставляется каждому новому сотруднику, но более опытные сотрудники (L5 и выше) могут договориться о единовременной выплате денежного бонуса при трудоустройстве в Google. Бонус выплачивается в течение первых месяцев работы, но может быть возвращен, если сотрудник уволится в течение двух лет.

В конце года бонусы выплачиваются как наличными, так и в виде акций:

Денежный бонус. При выполнении плановых показателей выплачивается целевой денежный бонус. Если показатели выше или ниже плановых, размер бонуса может варьироваться.
Повторное распределение акций. В конце года, если ожидания по результатам работы оправдались, обычно проводится повторное распределение акций наряду с выплатой денежного бонуса. Повторное распределение акций происходит в течение 4 лет с шагом в 25 %.

Общая сумма вознаграждения (ОСВ) представляет собой сумму базового оклада + денежного бонуса + выплаченного акционерного капитала.

Типичные компенсационные пакеты L3 и L4

Давайте рассмотрим несколько типичных пакетов для новых сотрудников. Лучшим источником данных об этих пакетах является Levels.fyi, где вы можете ознакомиться с тысячами пакетов Google.

Разработчик начального уровня: 160 000–250 000 долларов в США, и пропорционально меньше в других регионах. Должность L3 в Google — это должность начального уровня. Компания нанимает выпускников и специалистов с опытом работы от нескольких лет.

Реальные предложения от Google. Источник большинства данных: Levels.fyi, вознаграждение Google L3

Вознаграждение в Google зависит от местоположения. Компания выплачивает вознаграждение высшего уровня в рамках тримодальной модели вознаграждения. Однако компания корректирует пакеты вознаграждения в зависимости от местоположения и гарантирует, что выплачивает больше, чем региональные конкуренты. Однако, если посмотреть на пакеты вознаграждения L3, становится ясно, что общая сумма вознаграждения в США и Швейцарии значительно выше, чем в других регионах.

Поскольку оплата в Google зависит от местоположения, теоретически сотрудник из региона с более низкой стоимостью жизни может получить более выгодное предложение о полностью удалённой работе, чем в Google. Но, по моему опыту, такое случается редко, потому что высокооплачиваемые полностью удалённые должности обычно предназначены для старших инженеров-программистов и выше, а на этом уровне Google начинает платить действительно хорошо. Кроме того, очень сильным кандидатам компания всегда может предложить больше.

L4 — это средний уровень, который всё же ниже уровня старшего SWE (L5). Типичные диапазоны для этого уровня:

США: 250 000–350 000 долларов (общая годовая компенсация)
Швейцария: 210 000–260 000 швейцарских франков
Великобритания: от 125 000 до 185 000 фунтов стерлингов
Германия и Ирландия: 140 000–180 000 евро
Канада: 210 000–280 000 канадских долларов
Австралия: 200 000–280 000 австралийских долларов
Польша: 380 000–450 000 злотых в Польше,
Индия: 65–88 лакхов

Компенсация старшим SWE (L5) и штатным SWE (L6)

Старший специалист по SWE может зарабатывать в США до 500 000 долларов. На этом уровне опционы становятся более значимыми по сравнению с базовой зарплатой. На уровне старшего специалиста (L5) вознаграждение значительно увеличивается за счёт пакетов опционов. Обычно при получении предложения можно договориться об опционах, но имейте в виду, что они могут быть намного ниже или — в удачных случаях! — выше, чем в предложениях ниже:

Реальные компенсационные пакеты в Google, в том числе для сотрудников с большим стажем. Источник: Levels.fyi, Пакеты L5 в Google

L6 — это должность штатного инженера. На эту должность сложно как устроиться, так и продвинуться по карьерной лестнице, в отличие от перехода с L4 на L5. Вот как обычно оплачивается эта должность в годовом исчислении:

США: $550,00–700,000
Швейцария: 370 000–500 000 швейцарских франков
Великобритания: от 270 000 до 380 000 фунтов стерлингов
Германия и Ирландия: 250 000–330 000 евро
Канада: 420 000–650 000 канадских долларов
Австралия: 350 000–550 000 австралийских долларов
Польша: 750 000–850 000 злотых в Польше,
Индия: 1,5–2,2 миллиона рупий

Работа на миллион долларов: старший специалист SWE

Должность L7 (старший штатный инженер-программист) — это самая низкая должность, на которой некоторые специалисты в США могут зарабатывать более 1 млн долларов в год — обычно в районе залива Сан-Франциско. Компенсационные пакеты в значительной степени зависят от акций: размер пакета определяется первоначальным грантом и дополнительными выплатами. В США на таких должностях почти всегда платят больше 600 000 долларов, и разброс становится очень большим.

Фактические компенсационные пакеты в Google. Источник данных: Levels.fyi, Пакеты L7 в Google

В Google достаточно сложно получить должность L6, а продвинуться по карьерной лестнице до L7 ещё сложнее. Чтобы получить эту должность извне, кандидатам обычно нужно долгое время проработать на аналогичной должности в другой крупной технологической компании, добиться влияния в отрасли или получить признание в конкретной области. В настоящее время специалисты по машинному обучению и искусственному интеллекту получают более высокие зарплаты, поскольку на эти должности сложнее найти кандидатов, чем на «традиционные» должности SWE.

В небольших офисах очень сложно получить должность уровня L6+. Должности уровня L7 в основном встречаются в США и в крупных офисах, например в Швейцарии. В таких офисах, как Бангалор, таких должностей очень мало, а в небольших офисах часто нет должностей уровня L7 и выше. Должности уровня L8 обычно встречаются в крупных офисах в районе залива Сан-Франциско, Нью-Йорке, Сиэтле и Лос-Анджелесе, а также в Швейцарии.

Высокая зарплата — одна из причин, по которой опытные инженеры остаются в компании на 10 и более лет. Google предлагает опытным инженерам предсказуемый карьерный рост. При наличии навыков и удачи можно продолжать увеличивать свой доход, оставаясь индивидуальным разработчиком!

Большинство компаний требуют, чтобы инженеры становились менеджерами или старшими менеджерами, чтобы получать такое же вознаграждение, как инженеры уровня L6 и выше в Google. Это можно назвать «золотыми наручниками», потому что инженеру уровня L6+ в Google сложно найти место, где он мог бы работать как индивидуальный специалист, не согласившись на значительное снижение зарплаты!

Бонусы для коллег, разовые бонусы, программы поощрения

Щедрые выплаты Google не ограничиваются базовыми окладами, акциями и ежегодными денежными премиями: у компании есть виды премий, которые редко встречаются в других технологических компаниях.

Премии от коллег — это небольшие награды, на которые вы можете номинировать коллег. Сумма варьируется в зависимости от региона: около 200 долларов за номинацию в США и Цюрихе. Премии используются для того, чтобы сказать «спасибо» за хорошую работу. Сумма довольно небольшая, но особенность в том, что она исходит от коллег! И она может накапливаться: если вы получаете одну такую номинацию в месяц от коллеги, которому помогаете, то это около 2400 долларов в год. Как объяснил нам один из нынешних инженеров-программистов:

«Премии для коллег используются часто, и вы можете выплачивать до пяти таких премий в квартал. Обычно это делается, например, так: «Спасибо, что отвлеклись от своей обычной работы и помогли мне вчера исправить эту ошибку!»

Существуют разумные ограничения на получение бонуса: каждый инженер может выплатить до пяти бонусов коллегам в течение квартала и не может назначать одного и того же человека на несколько кварталов подряд. Во многих крупных компаниях есть внутренние системы, позволяющие сотрудникам благодарить друг друга (так, чтобы это видел их руководитель), но микробонусы в виде наличных — это уникальная особенность Google!

Разовые премии выплачиваются менеджерами в качестве благодарности за сверхурочную работу и значительный вклад. Размер разовых премий обычно составляет от 200 до 2000 долларов. Разовые премии выплачиваются за успешное завершение крупных проектов, а также за выдающиеся (иногда героические!) достижения.

Программы поощрения — это награды для целых команд, добившихся значительных успехов. Например, все члены команды могут получить премию в размере 5000 долларов или полностью оплаченную поездку в Исландию за успешное завершение очень важного проекта.

5. Прием на работу

В процессе найма сотрудников в Google есть уникальные элементы: алгоритмические собеседования, «гугловость» и подбор команды.

Алгоритмические интервью

Google, вероятно, стал первопроходцем в области алгоритмических собеседований, которые мы называем «LeetCode-интервью».

Цикл собеседований в Google для инженеров-программистов почти всегда включает в себя написание кода, то есть решение алгоритмической задачи за 30–60 минут. Этот тип собеседования часто называют собеседованием по структурам данных и алгоритмам (DSA).

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

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

Книга «Как пройти собеседование по программированию» была написана бывшим инженером-программистом Google Гейл Лаакманн Макдауэлл, чтобы помочь инженерам подготовиться к алгоритмическим собеседованиям. Книга переиздавалась шесть раз, а также было выпущено продолжение, «Как пройти собеседование по программированию. Часть 2». Ведущий автор Майк Мроцка поделился в этом информационном бюллетене советами о том, как опытные инженеры справляются с трудностями во время собеседований по программированию.

Распространённая критика в адрес таких собеседований заключается в том, что они не отражают повседневную работу. Однако Google и многие другие крупные компании проводят такие собеседования по веским причинам:

Достаточно хорошая эвристика. Инженеры, которые успешно проходят такие собеседования, обычно хорошо пишут код. С другой стороны, кандидатам очень сложно показать себя с лучшей стороны, если их навыки программирования слабы.
Легко масштабируется для новых интервьюеров. В Google работают десятки тысяч инженеров, которые проводят собеседования, и каждый год к ним присоединяются тысячи новых специалистов. По этой причине необходим процесс, в который легко вовлечь людей, чтобы даже новые интервьюеры могли достаточно хорошо оценивать кандидатов.
Легко заменить утекшие вопросы. В масштабах Google утечка вопросов во внешний мир — это обычное дело. Поэтому необходим процесс собеседования с банком из тысяч взаимозаменяемых вопросов.
Можно сделать за час. Собеседования не должны затягиваться, а процесс, который занимает несколько дней или недель, не сработает, потому что кандидаты часто работают полный день в другом месте и не могут взять несколько дней отгула, например, для испытательного срока.

Google предлагает материалы для подготовки к собеседованиям по программированию, в которых перечислены возможные вопросы и даны пояснения к понятиям, которые могут встретиться.

Типичный процесс собеседования

Вот как проходит типичное собеседование с инженером-программистом в самой прибыльной компании мира:

Чтобы получить предложение о работе инженером-программистом в Google, нужно пройти несколько собеседований

Каждый этап сложнее и занимает больше времени, чем предыдущий. Собеседование на месте обычно состоит из 2–3 последовательных собеседований, перерыва на обед и ещё 2–3 собеседований. Термин «собеседование на месте» связан с тем, что раньше Google привозил кандидатов «на место» в офис. С 2020 года большинство собеседований на месте проводятся по видеосвязи в Google Meet. Есть признаки того, что Google начинает возвращать очные собеседования для некоторых собеседований, но на момент публикации большинство собеседований проводится по видеосвязи.

«Гугловость» — это гугловская версия «соответствия корпоративной культуре». В своей книге Work Rulesбывший вице-президент Google по работе с персоналом Ласло Бок даёт следующее определение:

«Гугловость» включает в себя такие качества, как интеллектуальная скромность, добросовестность, терпимость к неопределённости и склонность к сотрудничеству. Она воплощает в себе соответствие корпоративной культуре, которое Google ищет не только в технических навыках».

Ветеран Google Энди Майло работает там уже 15 лет и определяет «гугловость» следующим образом:

«За годы работы здесь я понял, что в Google есть множество составляющих. Если бы мне нужно было выделить три наиболее важных аспекта, я бы сказал следующее:

Ставя пользователя на первое место
Мышление в 10 раз
Всегда поступаю правильно.

Я думаю, что, ориентируясь на эти три принципа, мы сможем помочь миру достичь невероятных высот».

«Гуглистость» обычно сводится к демонстрации таких качеств, как:

Любопытство
Будьте скромны и открыты для обратной связи
Доводить дела до конца
Поступаешь правильно
Поддержание высоких стандартов
Наличие новых идей

Для уровней L5 и выше также проводится оценка лидерских качеств. В руководстве, которое Google разослал менеджерам по продуктам, содержатся советы по проведению собеседований на Googleyness и Leadership:

«Менеджеры по продукту Google мечтают о новой прорывной идее, преуспевают в условиях неопределённости, ценят обратную связь, эффективно бросают вызов существующему положению дел и поступают правильно. Они эффективно руководят и оказывают влияние, управляют проектами, доводят дела до конца, работают в команде и стремятся к саморазвитию.Они проявляют любознательность и стремятся узнать больше, а также способны предлагать новые концепции продуктов и улучшать их функции. Узнайте, что значит быть «гуглистом», прочитав корпоративную философию Google и «Ценности Google».

Этот совет предназначен для менеджеров по продукту, но также применим к старшим инженерам и техническим руководителям.

Подробнее о процессе найма мы рассказываем в подробных обзорах Найм инженеров-программистов и Найм технического директора.

Подготовка к собеседованиям в Google

Немногие собеседования при приёме на работу требуют более тщательной подготовки, чем собеседования Google по структуре данных, алгоритмам и проектированию систем, и они стали стандартом для большинства крупных технологических компаний и стартапов. Ниже приведены несколько популярных ресурсов. Я не имею никакого отношения к этим ресурсам, и ни одна из ссылок не является партнёрской. Подробнее читайте в моём заявлении об этике.

Собственные материалы Google для подготовки: Google предлагает подборку видео, статей и упражнений для подготовки к собеседованиям. В отличие от многих других ресурсов, они бесплатны и заслуживают внимания.

Руководство Google по подготовке к собеседованию

Технический скрининг, структуры данных и алгоритмы: Существует бесчисленное множество книг, видео и онлайн-курсов по подготовке к собеседованиям в стиле LeetCode:

Книги: «Как пройти собеседование по программированию» очень известна, а более поздняя книга «Как пройти собеседование по программированию. Часть 2» является своевременным обновлением. «Элементы собеседований по программированию», «Жемчужины программирования» и «Руководство по разработке алгоритмов» также будут полезны при подготовке.
Сайты: LeetCode — самый популярный сайт для подготовки к тысячам собеседований по алгоритмическому программированию. Среди других сайтов можно выделить Codewars, Project Euler и другие.
Курсы: NeetCode — самый популярный онлайн-курс на данный момент. Есть десятки других курсов.
YouTube: на YouTube огромное количество контента; просто введите в поиск «структуры данных и алгоритмы» или более конкретный термин. Многие инженеры-программисты, прошедшие эти собеседования, делятся своими подходами и советами по подготовке.

Проектирование систем: это ещё одна область, которая была тщательно задокументирована.

Книги: «Интервью по системному проектированию: том 1» и «Том 2» Алекса Сю и «Проектирование приложений с интенсивным использованием данных» Мартина Клеппманна — самые популярные материалы для подготовки. Мы опубликовали главу о проектировании платёжной системы из книги «Интервью по системному проектированию»
Курсы: ByteByteGo от Алекса Сю популярен. По запросу «курс по прохождению собеседований по системному проектированию»
Видео на YouTube: как и в случае с видео по подготовке к экзаменам по структурам данных и алгоритмам, здесь много полезного материала

Глубокое погружение в предметную область: подготовьтесь к успеху, став экспертом в своей области и освоив распространённые инструменты, фреймворки и практики. Вы должны знать, как именно они работают, каковы их недостатки, а также уметь создавать продукты в этой области.

Собеседование на тему Google и лидерства: разберитесь в ценностях Google, кратко опишите свой опыт и достижения, чтобы привести лучшие примеры во время собеседования, и ознакомьтесь с советами по проведению поведенческих собеседований, такими как метод STAR. Это собеседование довольно типично для «собеседования с менеджером по найму». Большинство кандидатов испытывают трудности на технических собеседованиях, а не на этом.

Приёмная комиссия (ПК)

В большинстве компаний решение о найме принимается после собеседования на месте и подведения итогов. Как правило, решение принимает менеджер по найму, который часто является будущим руководителем кандидата. Но в Google всё по-другому. После каждого собеседования интервьюеры оставляют письменный отзыв и выставляют общую оценку кандидату в соответствии с системой оценки рекомендаций при найме:

Сильный найм (SH)
Прокат (H)
Бережливый наем (LH)
Бережливое увольнение (LNH)
Без проката (NH)
Strong No Hire (SNH)

На этом этапе специальная комиссия по найму рассматривает отзывы и принимает решение о найме. Гейл Лаакманн Макдауэлл описала этот процесс в выпуске 2016 года Cracking The Coding Interview:

«Письменный отзыв передается в комитет по найму (КН), состоящий из инженеров и менеджеров, для вынесения рекомендации о найме/отказе в найме. Отзыв обычно разбивается на четыре категории (аналитические способности, программирование, опыт и коммуникация), и вам выставляется общая оценка от 1,0 до 4,0. В состав КН обычно не входят ваши интервьюеры. Если это происходит, то исключительно по воле случая.Чтобы продлить предложение, HC хочет видеть хотя бы одного интервьюера, который является «энтузиастом и сторонником». Другими словами, пакет с баллами 3,6, 3,1, 3,1 и 2,6 лучше, чем пакет со всеми баллами 3,1.Вам не обязательно блистать на каждом собеседовании, а качество экрана вашего телефона обычно не является решающим фактором при принятии окончательного решения.Если комиссия по найму рекомендует принять вас на работу, ваше резюме будет передано в комиссию по компенсациям, а затем в комиссию по управлению персоналом. Принятие решения может занять несколько недель, поскольку процесс состоит из множества этапов и комиссий.

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

Подбор команд и срок действия пакетов

После того как комиссия по найму принимает решение о «приеме на работу», предложение о работе поступает не сразу. Успешному кандидату сначала нужно найти команду, которой он нужен. До 2023 года этот процесс был довольно быстрым, потому что Google постоянно расширялся, а команды нуждались в новых сотрудниках. Однако сегодня подбор команды становится препятствием, из-за которого некоторые рекомендации о «приеме на работу» остаются без внимания. Как мы сообщали в The Pulse:

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

После одобрения комитетом по найму следует годичный период, в течение которого команда должна «заявить» права на успешного кандидата, прежде чем ему будет сделано предложение. Поскольку подбор команды становится всё более сложной задачей, стоит знать, что существует крайний срок, до которого вы должны занять своё место в компании. В недавнем посте на Reddit внешний кандидат уровня L4, проходивший собеседование в Google, пожаловался, что получил один отзыв «Strong Hire», два отзыва «Hire» и один отзыв «Lean Hire», а также общую рекомендацию «Hire» от комитета. Но, несмотря на эти заслуги, они не получили ни одного предложения. Один из комментаторов предположил, что это произошло из-за отсутствия интереса со стороны команд, написав:

«Менеджеры по найму просто не проявили к вам интереса. После сокращения штата в Google стало очень распространённым явлением, когда кандидат «проходит» собеседование, но не получает предложения о работе. У вас есть год, чтобы найти работу в команде, прежде чем истечёт срок действия вашего пакета документов для собеседования».

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

«Фундаментальное отличие от других компаний заключается в том, что Google проводит подбор персонала в масштабах всей компании, а не в рамках отдельных команд. Google нанял вас, и вы попали в команду. Это значит, что люди, которые проводили собеседование с вами, могли больше никогда вас не увидеть, менеджер команды не проводил собеседование с людьми, которые присоединялись к команде, и т. д.»Предполагалось, что такой подход приведёт к повышению стандартов. Когда руководителю действительнонужно кого-то нанять, он может быть готов снизить требования к кандидату, чтобы нанять его сейчас, а не ждать несколько месяцев.Недостаток такого подхода в том, что, когда вы присоединяетесь к команде, вы ещё не знаете, в какую команду попадаете. Обычно люди принимали предложение Google, а в первый рабочий день узнавали, в какой команде они работают. Люди, у которых были чёткие предпочтения в отношении команд, иногда просто не принимали предложение Google.Плюсами были более доверительные отношения между командами и внутренняя мобильность. В такой компании, как Microsoft, чтобы перейти в другую команду, нужно было пройти повторное собеседование, потому что в каждой команде были свои стандарты найма, и команды не доверяли друг другу. В Google, если вы хотите перейти в другую команду, собеседование не требуется.

В эпоху стремительного роста Google подбор команды сводился к «вытягиванию жребия».Бывший менеджер по разработке делится интересным анекдотом о том, как происходил подбор команды:

«Когда я в 2007 году устроился в нью-йоркский офис, там действовала система, в рамках которой все команды с открытыми вакансиями ранжировались по приоритету. Список новых сотрудников на предстоящий понедельник рассылался. В порядке приоритета каждая команда могла выбрать кого-то из списка или пропустить его и передать дальше. Это повторялось до тех пор, пока все новые сотрудники не были распределены по командам.Этот процесс вызывал разногласия между кандидатами и новыми сотрудниками, потому что были кандидаты, которых определенные команды с более низким приоритетом действительно хотели видеть в своих рядах, но не получали их, а некоторые кандидаты были действительно готовы работать в командах с более низким приоритетом, но не попадали в них. За прошедшие годы этот процесс претерпел множество изменений, чтобы лучше учитывать предпочтения команд и кандидатов».

Выводы

Фух! Это было очень познавательно — а ведь мы едва ли наполовину изучили материал, который собирали в течение нескольких месяцев, изучая, каково это — работать в Google. Во второй части этой мини-серии мы расскажем о процессе оценки эффективности работы инженеров в Google, о внутренних системах, инженерных процессах, о том, как команды и инженеры добиваются результатов, а также поделимся полезными советами от сотрудников Google о том, как преуспеть в одной из самых успешных компаний мира.

Спасибо всем нынешним и бывшим сотрудникам Google, которые поделились подробностями и идеями, многие из которых публикуются здесь впервые.

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

Перевод: https://newsletter.pragmaticengineer.com/p/google

The Pulse #149: Новый тренд: программирование с помощью запуска параллельных ИИ-агентов

2025-10-31T06:01:32.818Z

Кроме того: протокол ACP, инструменты для обеспечения безопасности ИИ, сравнение опыта проведения собеседований в 8 технологических компаниях и многое другое

The Pulse — это серия публикаций о событиях, инсайтах и тенденциях в сфере крупных технологических компаний и стартапов.

Сегодня мы рассмотрим:

Новая тенденция: программирование с помощью запуска параллельных ИИ-агентов. Всё больше разработчиков экспериментируют с параллельным запуском агентов для написания кода
Протокол ACP. Новый протокол, разработанный командой Zed, который упрощает создание инструментов ИИ для IDE по сравнению с протоколом MCP
Инструменты для обеспечения безопасности на основе ИИ работают на удивление хорошо? Инструменты для обеспечения безопасности на основе ИИ хорошо справляются с выявлением уязвимостей в зрелых проектах с открытым исходным кодом
Является ли ИИ единственным двигателем экономического роста в США? Сорок процентов ВВП США в этом году приходится на расходы, связанные с ИИ, а 60% венчурного капитала направляется в сферу ИИ. Будем надеяться, что это не обернётся пузырём, который лопнет, как в 2001 году
Сравнение собеседований в 8 крупных технологических компаниях. Пунит Патвариподал заявки в 8 крупных технологических компаний и получил 6 предложений. Он сравнивает свои впечатления от собеседований в Meta, Amazon, Uber и 5 других компаниях

1. Новая тенденция: программирование с использованием параллельных ИИ-агентов

Поскольку агентские интерфейсы командной строки, такие как Claude Code, OpenAI Codex, Cursor и многие другие, становятся всё более популярными, я наблюдаю тенденцию к тому, что всё больше разработчиков программного обеспечения экспериментируют с одновременным запуском нескольких агентов для выполнения отдельных задач.

Я поговорил с инженером-антропологом Сидом Бидасарией о том, как создается Claude Code, и в конце нашего разговора он упомянул, что у него было несколько агентов, работающих повсюду, и что это сделало его работу более продуктивной. Аналогичным образом, инженер-программист Саймон Уиллисон, которого я считаю экспертом в области искусственного интеллекта, опубликовал статью о “принятии образа жизни агента параллельного программирования.” Он пишет:

«Некоторое время назад я получил несколько сообщений от инженеров, которые запускают сразу несколько агентов для написания кода — несколько экземпляров Claude Code или OpenAI Codex одновременно, иногда в одном репозитории, иногда в нескольких контрольных версиях или рабочих деревьях git.Поначалу я относился к этому довольно скептически. Код, сгенерированный ИИ, нуждается в проверке, а это значит, что естественным ограничением во всём этом является скорость, с которой я могу проверять результаты. Сложно уследить за одной большой языковой моделью, учитывая, как быстро она генерирует данные. Какой смысл запускать несколько моделей одновременно, если это только отдаляет меня от цели?Несмотря на мои опасения, за последние несколько недель я заметил, что постепенно начинаю привыкать к образу жизни агента по параллельному кодированию.Я могу сосредоточиться только на проверке и внедрении одного существенного изменения за раз, но я обнаруживаю, что всё больше задач можно выполнять параллельно, не перегружая мозг основной работой.

Саймон делится советами о том, что ему помогает, упоминая в качестве примеров использования исследования, задачи по обслуживанию и целенаправленную работу.

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

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

Разбираться в движущихся частях
Разработайте решение, проверьте его, доработайте
Когда вы будете довольны результатом, отправьте запрос на проверку кода — или, если проверка не требуется, просто объедините и опубликуйте его

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

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

Рецензирование кода. Придя в офис, просмотрите открытые рецензии на код, оставленные с прошлой ночи
Кодинг. Займитесь программированием самостоятельно
Встаньте.Как обычно
Ещё код. Выполняйте работу. По крайней мере, такова идея. На самом деле:
Прерывания: обзоры кода, просьбы о помощи, похлопывания по плечу. Самый продуктивный инженер в команде регулярно получает сообщения с просьбой проверить код, чтобы разблокировать товарищей по команде или помочь кому-то еще, кто застрял, или менеджер (прошу прощения!) хлопает их по плечу, прося о помощи в чем-либо.

Интересно, будут ли старшие инженеры и выше «естественным образом» работать с параллельными ИИ-агентами, исходя из их существующих привычек и того, чем они занимаются сейчас:

Держите в голове параллельные рабочие процессы, например то, чем в данный момент занимаются члены команды.
Проверка кода в нескольких рабочих потоках: они являются основными проверяющими код и обычно проверяют все изменения кода в 2–5 рабочих потоках. Они могут не выполнять работу, но знают, когда она выполнена правильно.
Умеют справляться с отвлекающими факторами: они научились добиваться успеха, несмотря на то, что их постоянно отвлекают.
Умеют направлять коллег: поскольку их постоянно отвлекают, они научились делегировать задачи и объяснять членам команды, почему работа должна быть выполнена срочно.
Навыки письма: эти инженеры часто пишут отзывы о коде, составляют такие документы, как RFC, в которых описывается работа, создают тикеты для разделения проектов на части и критикуют работу коллег. Все это требует эффективного письменного общения.

Благодаря ИИ-агентам инженеры, которые хотят работать продуктивнее, могут развить в себе качества, присущие хорошим техническим руководителям. На данный момент я слышал только о том, что параллельных агентов успешно используют старшие инженеры.

Впрочем, этот рабочий процесс подходит не всем: я спросил создателя Flask Армина Ронахера о его опыте работы с параллельными агентами. Он сказал мне:

«Иногда я отключаю параллельных агентов, но не так часто, как раньше.Дело в том, что мой разум может обработать лишь определённый объём информации!

Но теперь мы на новой территории, где любой разработчик может запустить параллельное кодирование с помощью агентов. Повысит ли это продуктивность инженеров или просто заставит людей чувствовать себя более продуктивными? Возможно, со временем станет ясно, что инженеры, которые делают что-то одно за раз и не отвлекаются, создают более надёжное программное обеспечение. Или, может быть, окажется, что работа с параллельными агентами приводит к тому, что больше задач остаётся нерешёнными, а итераций становится больше, что сводит на нет все преимущества.

Мы это выясним. Лично я вижу только то, что всё больше разработчиков экспериментируют с параллельными агентами.

Мне кажется, что при работе с ИИ-агентами важнее основы разработки программного обеспечения. Я начал использовать ИИ-агентов в своих сторонних проектах, и пока что успешно. Я делаю несколько вещей:

Тестирование: во всех побочных проектах есть модульные тесты, потому что я научился не доверять своей работе без проверки
Небольшие описательные задания: я даю небольшие по объёму задания, которые объясняю, и привожу примеры
Рефакторинг: каждая третья или четвёртая задача заключается в том, чтобы агент рефакторил написанный им код (например, выделил его в метод или перенёс в новый класс)
Отзыв: я слежу за тем, что делает агент
Делайте мелочи сами: я не закрываю IDE и вручную меняю всё, что требует внесения изменений в несколько строк, чтобы быть в курсе состояния кодовой базы

Я постоянно слышу одно и то же от других инженеров: «обязательные» инженерные практики, такие как проверка агентом всех тестов перед продолжением работы, приводят к лучшим результатам. Это неудивительно, и именно поэтому такие практики становятся всё более популярными. ИИ-агенты недетерминированы и в некоторой степени ненадёжны; эти практики делают их гораздо более надёжными и удобными в использовании.

2. Протокол ACP

Компании JetBrains и Zed объявили о сотрудничестве в рамках протокола Agent Client Protocol. Крупнейшие конкуренты VS Code, использующие собственные интегрированные среды разработки, которые не являются ответвлениями VS Code, заявляют, что цель ACP — обеспечить взаимодействие между редакторами кода и агентами. Протокол ACP был изначально создан командой Zed.

Постоянные читатели этой публикации могут спросить: «Подождите, разве MCP не решает эту проблему?» И действительно, MCP (Model Context Protocol, «USB-C для приложений ИИ») был создан под влиянием интерфейсов IDE. И один из вариантов его использования заключается в том, что он значительно упрощает подключение IDE к агентам. Из статьи Протокол MCP: новый строительный блок для инструментов разработки ИИ:

Краткий обзор архитектуры MCP. Из Протокола MCP: новый строительный блок для инструментов разработки ИИ

Итак, зачем нужен новый протокол, почему бы просто не продолжать использовать MCP? Дело в том, что MCP создавался не для IDE: компания Anthropic разработала его как способ взаимодействия любого приложения с агентами. IDE взяли его на вооружение, потому что это было лучше, чем отсутствие возможности добавлять интеграцию с агентами.

ACP поддерживает несколько функций, которых нет в MCP:

Двунаправленная связь между агентами и IDE
Поддержка интерактивных рабочих процессов, таких как генерация кода и встроенные подсказки
Поддержка вызова локальных инструментов в среде разработки, включая чтение файлов

ACP был сделан совместимым с MCP, и можно использовать существующие серверы MCP. Однако ACP позволяет поставщикам добавлять улучшенную поддержку сценариев использования, связанных с кодированием.

На первый взгляд, протокол ACP гораздо больше подходит для IDE, чем MCP. Учитывая, что Zed и JetBrains добавили поддержку, я ожидаю, что VS Code и его форки, такие как Cursor, Windsurf и другие, последуют их примеру. Поздравляю команду Zed с созданием этого протокола. Узнайте больше на сайте ACP.

3. Инструменты для обеспечения безопасности на основе ИИ работают на удивление хорошо?

Два недавних события показали, что инструменты на основе ИИ весьма полезны для выявления проблем в системе безопасности:

Обнаружены десятки уязвимостей в Curl (URL клиента) Популярный инструмент командной строки был выпущен в 1996 году и на сегодняшний день является очень зрелым программным обеспечением. Две недели назад инженер-программист Джошуа Роджерс отправил список проблем, которые он обнаружил с помощью инструментов на базе искусственного интеллекта. На основе этого разработчик Curl Дэниел Стенберг выпустил 22 исправления, и их число продолжает расти. Выяснилось, что все проблемы с безопасностью присутствовали, но разработчики пока не сообщали о них. Как здорово использовать инструменты искусственного интеллекта!

ИИ-агент Google для обеспечения безопасности кода: Поисковый гигант поделился подробностями о внутреннем проекте под названием CodeMender. Этот ИИ-инструмент использует статический анализ, динамический анализ, дифференциальное тестирование и другие методы для поиска проблем. Затем отладчик и браузер исходного кода генерируют и проверяют исправления. Google сообщает, что за последние 6 месяцев CodeMender помог исправить 72 уязвимости в проектах с открытым исходным кодом. CodeMender не является готовым продуктом, но тот факт, что Google делится этими результатами, говорит о том, что на основе этого исследования будет выпущен какой-то продукт для обеспечения безопасности с помощью ИИ.

Мне кажется, что инструменты на основе ИИ теперь полезны не только для выявления потенциальных проблем с безопасностью, но и для проверки, исправления и создания новых задач.

4. Является ли искусственный интеллект единственным фактором роста экономики?

В СМИ появились сообщения о том, что инвестиции в ИИ являются практически единственным фактором роста экономики США. Например, в статье Financial Times говорится, что Америка сделала большую ставку на ИИ:

«Сотни миллиардов долларов, которые компании инвестируют в ИИ, в этом году составляют поразительные 40 % от общего роста ВВП США. Некоторые аналитики считают, что эта оценка не отражает в полной мере расходы на ИИ, поэтому реальная доля может быть ещё выше.В 2025 году на долю компаний, занимающихся искусственным интеллектом, пришлось 80 % прироста акций в США. Это помогает финансировать и стимулировать рост экономики США, поскольку фондовый рынок, основанный на искусственном интеллекте, привлекает деньги со всего мира и способствует буму потребительских расходов среди богатых людей.

Более 60 % венчурных инвестиций направляется в компании, занимающиеся искусственным интеллектом. Из Pitchbook:

ИИ доминирует в сфере венчурного финансирования. Источник: Анализ Pitchbook

Тем временем цены на акции таких компаний, как AMD, резко выросли. Были заключены несколько интересных сделок, например, OpenAI пообещала купить чипы AMD на сотни миллиардов долларов (за деньги, которых у неё нет), а AMD предложила OpenAI до 10 % акций компании.

Это странная на первый взгляд сделка, которая пришлась по душе фондовому рынку. Вот как её охарактеризовал аналитик Bloomberg Мэтт Левин кратко:

«Как проходят переговоры [между OpenAI и AMD]? Если в общих чертах:OpenAI: нам бы понадобились ваши чипы мощностью шесть гигаватт для логического вывода.AMD: Потрясающе. Это будет стоить 78 миллиардов долларов. Как вы хотите заплатить?OpenAI: Мы думали объявить о сделке, и это увеличило бы стоимость вашей компании на 78 миллиардов долларов, что должно было покрыть расходы.AMD: …Открытый доступ: …AMD: Нет, я почти уверен, что за чипы нужно платить.OpenAI: Почему?AMD: Не знаю, просто кажется неправильным этого не делать.OpenAI: Хорошо. Почему бы нам не заплатить вам наличными за стоимость чипов, а вы вернёте нам акции, и когда мы объявим о сделке, акции вырастут в цене, и мы вернём свои 78 миллиардов долларов.AMD: Да, думаю, это сработает, хотя мне кажется, что мы должны получить хоть какую-то выгоду.OpenAI: Хорошо, можешь забрать половину. Ты даёшь нам акции на сумму около 35 миллиардов долларов, а остальное оставляешь себе».

Одновременно происходят три вещи:

Инвестиции в ИИ в этом году составят ~40% ВВП США. По сути, если бы не эти масштабные инвестиции, мы могли бы оказаться на грани рецессии.
Инвестиции в ИИ составляют ~60% всего венчурного капитала. По сути, если вы не технологическая компания, которая занимается ИИ, вам будет всё сложнее и сложнее привлекать деньги.
Компании, занимающиеся искусственным интеллектом, используют бухгалтерский учёт для повышения цен на акции. OpenAI заинтересована в том, чтобы стоимость акций таких партнёров, как AMD, продолжала расти, если она заключает сделки, по которым OpenAI получает графические процессоры бесплатно, когда стоимость акций становится достаточно высокой.

С одной стороны, подобные сложные финансовые механизмы могут создать ощущение раздувающегося «пузыря» ИИ, который в какой-то момент может лопнуть — примерно так же, как сложные финансовые инструменты привели к мировому финансовому кризису 2007–2008 годов.

С другой стороны, ИИ и большие языковые модели являются революционными технологиями, которые позволяют нам создавать то, что раньше было невозможно! Мы видим это в разработке программного обеспечения: ИИ-агенты генерируют больше кода, который проверяется разработчиками, но не пишется ими. Некоторые разработчики отключают ИИ-агентов, и теперь вы можете назначить ИИ-агенту задачу, чтобы он в одно касание исправил ошибку — например, как это уже поддерживает Linear.

По сути, LLM позволяют добавлять диалоговый интерфейс к любому типу системы, которую мы создали заранее, плюс они обещают новые типы продуктов и варианты использования. И примеры использования искусственного интеллекта распространяются повсюду: разработка программного обеспечения и поддержка клиентов - это две области, в которых агенты нашли “соответствие продукта рынку”, и за ними наверняка последуют другие.

Если рассматривать это с точки зрения технологического прорыва, то инвестиции в ИИ вполне рациональны:

Инвестиции в ИИ могут принести более высокую прибыль, чем вложения в другие перспективные направления. Для компании с бюджетом на исследования и разработки в размере 1 млн долларов США вложение большей части средств в эксперименты с ИИ сейчас кажется вполне разумным, поскольку эта технология обладает большим потенциалом. К тому же конкуренты делают то же самое!
С точки зрения венчурного инвестора, инвестиции в ИИ кажутся лучшей краткосрочной инвестицией. Всего за 4 года стоимость OpenAI выросла в 25 раз: в 2021 году компания оценивалась в 20 миллиардов долларов, а сегодня её стоимость составляет 500 миллиардов долларов. Ещё более поразительно то, что Anthropic была основана в 2021 году (когда OpenAI уже оценивалась в 20 миллиардов долларов!) и стоит 183 миллиарда долларов! Инвесторы, вложившие деньги в первый раунд финансирования Anthropic в 2022 году (когда компания была оценена в 4 миллиарда долларов), получили 45-кратную прибыль всего за 3 года
ИИ способствует росту фондового рынка. Инвесторы видят потенциал ИИ и спешат приобрести компании, которые вкладывают значительные средства в эту область, в надежде получить высокую прибыль, став одними из первых дальновидных «инвесторов в ИИ»

В последний раз мы наблюдали такие инвестиции и такой энтузиазм в сфере технологий на пороге нового тысячелетия (примерно в 1999 году), когда интернет начал стремительно развиваться: начался бум доткомов, который превратился в пузырь, а затем лопнул в 2001 году. Сектору потребовались годы, чтобы оправиться от этого краха, и невозможно сказать, не движемся ли мы сегодня к чему-то подобному. Есть множество признаков того, что рынок и экономика выигрывают от позитивного отношения к искусственному интеллекту, и неизвестно, изменится ли что-то в этом отношении и когда это произойдёт.

Даже после краха доткомов технологическая отрасль восстановилась и вернулась к росту в течение нескольких лет. А некоторые из крупнейших технологических компаний современности были основаны незадолго до этого или сразу после: Google в 1998 году (до краха) и Facebook в 2004 году (после краха).

5. Сравнение собеседований в 8 крупных технологических компаниях

Пунит Патвари (Puneet Patwari) недавно принял предложение о работе в Atlassian в качестве главного инженера-программиста. За три месяца он прошёл более 60 собеседований в 11 компаниях, рассказал он мне, при этом он отказался ещё от трёх собеседований после того, как принял предложение Atlassian, в том числе от Meta. После этого он сравнил собеседования в крупнейших компаниях:

На что был похож каждый этап собеседования. Источник: Пунит Патвари

Вот ещё несколько наблюдений, которыми поделился со мной Пунит (Puneet):

Amazon: собеседование с менеджером по подбору персонала в Amazon было одним из самых необычных, в которых я когда-либо участвовал. Мы так увлеклись беседой, что она заняла 160 минут вместо запланированных 60! Нам пришлось сделать перерыв между собеседованиями.

Atlassian: Два этапа собеседования, посвящённые лидерским качествам (ЛК) и ценностям, сыграли решающую роль в определении того, что я буду работать на уровне Principal. Конечно, собеседование по системному проектированию тоже сыграло свою роль. Atlassian уделяет большое внимание ЛК для инженеров уровня Principal.

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

Confluent: когда я говорю, что это было самое сложное с точки зрения умственных способностей собеседование, я имею в виду, что каждый навык проверялся на двух собеседованиях! То есть 2 собеседования по структурам данных и алгоритмам (СДА), 2 собеседования по проектированию систем, 2 поведенческих собеседования.

Я не могу не подчеркнуть, насколько важны поведенческие интервью на уровнях Staff+ и выше. Успешное прохождение этих собеседований сыграло решающую роль в получении предложений о работе на уровнях Staff и Principal. Конечно, нужно было хорошо разбираться в программировании и системном проектировании, но, по моему мнению, именно поведенческие аспекты определяли уровень и возможность получения предложения о работе.

Из рассказа Пунита о его собеседованиях в ведущих технологических компаниях я выделил несколько моментов:

Собеседования по алгоритмическому программированию проводятся повсеместно! Чтобы претендовать на должность старшего специалиста и выше, вам нужно хорошо разбираться в таких сложных темах, как динамическое программирование. В этой статье мы расскажем, как успешно пройти такое собеседование. Как опытные инженеры справляются с собеседованиями по программированию
Собеседования проходят тяжело и отнимают много времени. Даже после того, как Пунит получил предложения, ни одна компания не сократила процесс рассмотрения. Пуниту пришлось отказаться ещё от трёх собеседований, в том числе от собеседования в Meta, потому что к тому времени, когда они должны были состояться, он уже получил предложение от Atlassian и принял его.
На сложном рынке труда по-прежнему востребованы «лучшие» кандидаты. Мы рассказали о том, насколько сложен текущий рынок труда в сфере технологий для соискателей, но Пунит прошёл собеседования в 11 компаниях и получил 6 предложений. Чтобы пройти отбор по резюме, его кандидатура должна была соответствовать многим требованиям: опыт работы более 10 лет и должность старшего инженера-программиста в Microsoft. Он также был действительно хорошо подготовлен.
Невезение может случиться в любой момент. Похоже, что Пуниту не повезло на собеседовании в Uber: интервьюер был непреклонен и не готов к диалогу. Возможно, у него был тяжёлый день или он хотел поскорее закончить собеседование. Или это могло быть тем, что Стив Йегге называет антипетлёй интервьюера

Перевод: https://newsletter.pragmaticengineer.com/p/the-pulse-149-new-trend-programming

Инженерная культура Google

2025-10-31T05:54:16.580Z

Мы с Элин Нильссон рассказываем о том, как на самом деле устроены инженерная культура, инструменты и системы Google.

В этом видео

Каково это на самом деле быть инженером в Google?

В этом специальном выпуске, посвящённом глубокому погружению в тему, мы рассказываем о том, как на самом деле работает инженерное дело в Google. Мы несколько месяцев изучали инженерную культуру поискового гиганта и поговорили с более чем 20 нынешними и бывшими сотрудниками Google, чтобы провести это глубокое погружение с Элин Нильссон, исследователем технологической отрасли из The Pragmatic Engineer и бывшим стажёром Google.

Google всегда была организацией, ориентированной на инженерное дело. Мы рассказываем о её собственном стеке и инструментах, культуре проектирования документации, а также о системах оценки эффективности и продвижения по службе, которые определяют карьерный рост. Мы также изучаем корпоративную культуру, которая, кажется, создана для инженеров: щедрые льготы, удивительно лёгкое дежурство, которое часто считается лучшим в отрасли, и пристальное внимание к решению масштабных технических проблем.

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

https://newsletter.pragmaticengineer.com/p/googles-engineering-culture

Что такое хорошая архитектура программного обеспечения?

2025-10-31T05:41:34.925Z

Как выглядит хорошая архитектура, как улучшить свои навыки в её создании и почему архитекторы не всегда являются решением проблемы. Гостевая публикация Мэтью Хоторна, который создавал крупные системы в Netflix и Twitter

Чтобы попытаться ответить на этот, казалось бы, простой вопрос, я обратился к ветерану разработки программного обеспечения Мэттью Хоторну. Он работает инженером-программистом более 25 лет и является автором готовящейся к выходу книги «Добейся результата или умри, пытаясь», в которой он делится опытом работы с программным обеспечением, архитектурой и выводом продукта на рынок. Книга находится на стадии раннего выпуска и должна выйти в следующем году.

Мэтт работал в Comcast, Twitter и Netflix, где он провёл шесть лет в 2010-х. Во время его работы в Netflix каждый инженер ежедневно принимал архитектурные решения и часто выпускал новые функции, которые становились доступны десяткам миллионов пользователей — и всё это без единого упоминания должности «архитектор».

В этом выпуске Мэтт рассказывает о:

Архитекторы не решают архитектурных проблем. В Netflix долгое время не было архитекторов, но основы архитектуры оставались прочными.
Отказ от решения сегодняшних проблем в пользу решения проблем завтрашних: переход на AWS. Переход в облако AWS создал множество проблем для Netflix, на решение которых впоследствии потребовались серьёзные усилия. Но это также устранило существующие проблемы.
Положительные характеристики архитектуры. Они уравновешивают практические и амбициозные задачи, объединяют людей и системы и не связаны с хорошим кодом.
Плохая архитектура — это большой объём работы, который мало что меняет. Это всё равно что переставлять мебель в доме, который нужно снести и построить на его месте что-то более удобное.
Удачные архитектурные решения в проектах Netflix. Необычные компромиссы, создание инструментов для сокращения объёма оперативной работы, отказ от одних ограничений в пользу других и модернизация систем для повышения их эффективности в будущем.
Как улучшить свои навыки в области архитектуры. Разрабатывайте системы, исходя из того, что может сломаться, изучайте свою аудиторию, уделяйте внимание нужным деталям и становитесь ценным сотрудником на нескольких должностях.

Если вы хотите следить за публикациями Мэтта, подпишитесь на его рассылку Push to Prod. Вы также можете приобрести его незавершённую книгу Push to Prod or Die Trying, которая на данный момент готова на 40 %.

На этом Мэтт заканчивает:

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

Мне всегда казалось, что работа, определяемая фразой архитектура программного обеспечения, расплывчата, а ценность, приносимая архитекторами с большой буквы, сомнительна. Я говорю это исходя из личного опыта после моего недолгого и ничем не примечательного пребывания в должности «архитектора предметной области» — опыта, из которого я многое почерпнул, но мало что привнёс. Со временем я понял, что если и есть что-то, что я знаю об архитектуре, так это то, что:

Хорошая архитектурная работа заключается в целенаправленном решении проблем, с которыми вы сталкиваетесь сегодня, ради решения более сложных проблем в будущем. По сути, если вы не решаете свои проблемы, вы просто переставляете мебель.

1. Архитекторы не являются решением архитектурных проблем

Я проработал в Netflix 6 лет, и за это время я увидел сотни вещей, которые делали компанию уникальной. Одной из них было отсутствие архитекторов программного обеспечения — по крайней мере, в названии должности. На самом деле у нас вообще не было инженерных уровней; каждый инженер был старшим инженером-программистом.

Первые четыре года я проработал в команде Edge, в которой было около 20 инженеров, занимавшихся разработкой и эксплуатацией программного уровня, расположенного между клиентскими устройствами и внутренними сервисами. «Edge» в данном случае — это граница серверной инфраструктуры Netflix, на которую приходилась большая часть эксплуатационных нагрузок.

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

За несколько лет мы решили самые насущные проблемы, повысив отказоустойчивость, создав гибкую периферийную маршрутизацию и внедрив предиктивное автомасштабирование. Если задуматься об этих и других проектах, над которыми я работал в гиганте потокового видео, то можно сказать, что архитектуры в привычном понимании там не было. Те, кто предлагал идеи, сами выполняли работу, что позволяло избежать неловкого разделения на «белых воротничков» и «синих воротничков», которое часто возникает между архитекторами и инженерами в технологических компаниях. Большинство технических идей зарождалось в «окопах», что приводило к осознанному выбору архитектурных решений, имевших очевидную ценность. Со временем мы вступили в новую эру, которая характеризовалась обильными дискуссиями о создании новых масштабных систем для решения воображаемых проблем будущего, а не реальных проблем настоящего.

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

Я думал, что Netflix не нуждается в архитекторах, и рассуждал об этом в более широком смысле: действительно ли они нужны какой-либо компании? Давайте разберёмся, зачем нужна должность архитектора. Я считаю, что это пережиток старой школы:

Дизайн: архитекторы мыслят масштабно и рисуют схемы
Сборка: инженеры превращают схемы в код
Тест: QA находит ошибки
Эксплуатация: отдел эксплуатации обеспечивает бесперебойную работу систем

Эти четыре этапа неизбежны, и каждая компания подходит к ним по-своему. Представьте себе ось: слева на ней изображена отдельная роль для каждого этапа, а справа — единая роль, выполняющая все функции. Каждая компания находится где-то на этой оси.

Например, переход крупных компаний на гибкую методологию разработки сделал менее популярным подход «большой дизайн, заранее», и часто Дизайн и Сборка объединялись в один непрерывный этап. А переход к облачным технологиям, DevOps и модели «ты пишешь, ты запускаешь» часто объединяет Сборку, Тестирование и Эксплуатацию в один этап.

Итак, зачем Netflix нанял архитекторов? На мой взгляд, это было связано с масштабом: наше руководство считало, что нам нужны более масштабные и смелые идеи, чтобы переосмыслить работу наших систем, и что тем, кто должен был воплотить эти идеи в жизнь, нужна была дистанция от повседневной работы.

Звучит вполне логично, но я никогда не видел, чтобы это работало. Я не пытался это исправить — я сменил команду и перешёл в группу «Инфраструктура персонализации», которая всегда меня интересовала. Эта команда была новой, и они решали конкретные проблемы. Насколько я понимаю, команда Edge продолжила успешно ревизуализировать свою платформу.

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

2. Решение сегодняшних проблем ради завтрашних: переход на AWS

Самый значительный компромисс, который я наблюдал в Netflix, был связан с решением, принятым ещё до моего прихода в компанию: перенос всей инфраструктуры на AWS. «Ну и что?» — можете подумать вы. Многие компании используют AWS.

Конечно, многие компании делают это сегодня, но в 2010 году ни одна крупная компания этого не делала. Я помню, как читал несколько блогов постов о миграции Netflix на AWS до того, как устроился туда, и думал: «Они сумасшедшие». Но после того, как я устроился и увидел ситуацию своими глазами, я понял, что в этом есть смысл.

Каковы последствия работы в центре обработки данных, в локальной, не облачной среде?

Стабильная сеть и оборудование.
Ограничения по фиксированной мощности. Возможно, нет на постоянной основе фиксировано, но мощность можно увеличить по мере приобретения, установки и подключения оборудования.

Каковы последствия работы в AWS или других облачных средах?

Практически неограниченная, эластичная ёмкость.
Нестабильная работа сети и оборудования. Если слово «нестабильная» звучит резко, давайте скажем «намного менее стабильная, чем хотелось бы».

Если бы дело было только в этом, то экономическая целесообразность использования эластичных мощностей была бы достаточно веской, чтобы считать миграцию на AWS выгодной сделкой. Но с точки зрения команды Edge, эта сделка привела к возникновению множества других проблем.

Например:

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

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

3. Хорошие архитектурные характеристики

Давайте обсудим несколько характеристик хорошей и плохой архитектуры.

Хорошая архитектура не связана с хорошим кодом

В самом начале моей карьеры я присутствовал на совещании и наблюдал, как недавно принятый на работу опытный инженер в течение 30 минут что-то лихорадочно рисовал на доске. Я понятия не имел, о чём он говорит, но старшие коллеги его очень уважали, поэтому я внимательно слушал.

Несколько недель спустя у меня появилось свободное время, и мы вместе начали воплощать в жизнь некоторые из его идей. Его код был ужасен, и ему с трудом удавалось заставить что-либо работать. Но он сказал кое-что, что показалось моему юному разуму глубоким:

«В пользовательском интерфейсе у нас жёстко прописаны SQL-запросы, — сказал он.
— Нам нужно изменить это так, чтобы пользовательский интерфейс обращался к сервису, который абстрагирует запрос за счёт концепции, например „получить все элементы для текущего пользователя“».

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

Способность человека писать качественный код совершенно не зависит от его способности создавать или распознавать качественную архитектуру.

Я работал с руководителями технических отделов, которые годами не писали код, но при этом прекрасно разбирались в технических основах. Когда было нужно, они брали бразды правления в свои руки и направляли свои команды, уводя их от дорогостоящих ошибок и открывая перед ними широкие возможности. У них не было особых навыков программирования, но они обладали безупречным чувством стиля, интуицией и вкусом.

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

Архитектура объединяет системы, созданные с помощью кода, но при этом является отдельной дисциплиной, имеющей мало общего с программированием. Вы не сможете с помощью LeetCode создать целостную, гибкую архитектуру, которая будет служить бизнесу.

Почему бы и нет? Давайте рассмотрим архетип «хорошо разбирается в архитектуре, но плохо пишет код». Я заметил, что таких людей привлекают самые важные детали. При разработке новой системы они задают такие вопросы:

Какие данные мы можем собрать, чтобы обеспечить правильную работу системы?
Какова максимально допустимая задержка для клиентов этой системы?
Нужно ли нам рассчитывать результаты в режиме реального времени или это можно сделать в автономном режиме, в пакетном режиме?

Как правило, их меньше волнуют такие детали, как иерархия классов, названия методов и структура каталогов, которые не имеют большого значения в контексте бизнеса и распределённых систем.

Но код не может быть совершенно бесполезным, верно? Давайте рассмотрим архетип «хорошо разбирается в коде, но плохо разбирается в архитектуре». Я думаю, что он возникает, когда у людей нет опыта работы с такими вещами, как задержка в сети, резервные варианты или режимы отказа.

Обратите внимание, что я использую слово «архитектура» в значении «архитектура распределённых систем», что является общепринятым и отражает мой личный опыт.

В Netflix мы часто сталкивались с тем, что в серверных службах возникали медленные утечки памяти, которые было сложно обнаружить и устранить, потому что из-за политики автомасштабирования инстансы редко работали дольше 48 часов. Если бы мы сосредоточились на устранении утечек памяти, а не на автомасштабировании, Netflix не смог бы масштабироваться в соответствии со спросом и был бы гораздо менее прибыльным.

Хорошая архитектура объединяет людей, а не только системы

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

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

В ходе этих мероприятий была получена следующая информация:

Какой контент кому был показан в какое время
Оценка модели машинного обучения для каждой пары пользователь/товар

Эти данные позволили нам:

Отслеживайте предвзятость на разных этапах персонализации: от подбора кандидатов до фильтрации, ранжирования и показа
Изучайте и устраняйте такие проблемы, как:

Почему некоторые пользователи видят пустые страницы без рекомендаций?
Почему некоторые материалы неожиданно становятся более популярными, чем другие?

С «социальной» точки зрения нужно было многое учесть:

Моя очередь из заинтересованных лиц росла в геометрической прогрессии, поскольку каждый предлагал привлечь ещё двух человек для консультаций.
«Нам нужен дизайн» — эту фразу часто повторяли те, с кем я разговаривал. Когда я спросил, каких целей мы не можем достичь из-за текущего дизайна, я не получил внятных ответов.
У нас был прототип конкурирующего проекта, который, по мнению нескольких инженеров в команде, мы должны были использовать вместо текущей системы.
Граница между тем, что было «аналитикой», и тем, что ею не являлось, была размытой. Например, нас несколько раз спрашивали, можем ли мы регистрировать функции машинного обучения вместе с аналитическими данными. Мы всегда отказывались из-за плотного графика, но я чувствовал, что мы упускаем возможность решить более масштабную и важную проблему.

Нам нужно было выработать единое видение, чтобы все были на одной волне, поэтому я написал документ с описанием проблемы, которую мы решали, — как с точки зрения бизнеса, так и с точки зрения масштаба, — и добавил несколько диаграмм. Я представил несколько вариантов доработки проекта и объяснил, какой из них, по моему мнению, был лучшим и почему. Затем я поделился этим документом.

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

Вскоре после этого я ушёл из компании, так как понял, что это не моё. Но ещё несколько месяцев я задавался вопросом, что я мог бы сделать по-другому, чтобы добиться лучшего результата. Я всегда прихожу к одному и тому же ответу:

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

Моя задача заключалась не только в том, чтобы принимать оптимальные технические решения. Моя задача состояла в том, чтобы объединить всех вокруг единой концепции, независимо от того, была она технически оптимальной или нет.

В упомянутом выше случае с ранжированием видео я более года периодически лоббировал этот проект, прежде чем началась работа: я представлял слайды и рассылал их всем, кого мог найти, собирал кучу данных и делал новые слайды. На какое-то время всё затихло. А потом, наконец, звёзды сошлись, и мы начали действовать.

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

Хорошая архитектура сочетает в себе практичность и устремлённость ввысь

Примерно в 2020 году я работал главным инженером в крупной американской телекомпании. Моя работа была связана с масштабными улучшениями в области персонализированного ранжирования видео, и я вместе с архитектором работал над решением проблемы повышения гибкости ранжирования видео. Исторически сложилось так, что большая часть контента предоставлялась продуктом либо через поиск, либо через различные подборки, составленные людьми. Для полной персонализации контента требовалось по-новому объединить несколько функций, систем и команд.

Давайте вкратце поговорим об этих командах. Нашим основным партнёром была команда Search — группа из 20 или около того инженеров, которые управляли большим поисковым индексом, а также системой доступа ко всем коллекциям контента, отобранным редакторами. Их приоритетной задачей была стабильная и высокодоступная выдача релевантных результатов поиска. Обычно на внедрение изменений в их систему уходило не меньше месяца.

Мы были командой по персонализации, в которую входило около 10 специалистов по машинному обучению и инженеров-программистов. Мы владели несколькими сервисами, которые предоставляли пользователям персонализированный контент во время работы, а также многочисленными конвейерами данных и случайными пакетными заданиями. Нашим приоритетом было повышение вовлечённости пользователей за счёт максимального увеличения объёма персонализированного контента. Если бы вы попросили нас внести изменения в нашу систему, мы, скорее всего, смогли бы запустить их в производство за два рабочих дня.

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

Мой партнёр-архитектор не согласился с этим и сказал:

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

Это была интересная идея, но в то время предложение, требующее реорганизации, в этой компании быстро уходило в никуда. Кроме того, это ограничило бы мои возможности для написания будущих предложений.

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

Распространённый стереотип об архитекторах заключается в том, что они предлагают решения, которые не работают в реальном мире. Их решения требуют предварительного создания нового, идеального мира. В нашем случае идеальный мир можно создать путём реорганизации, которая разделит команду Search, или, возможно, путём переписывания всех сервисов с нуля.

Но проблема не в том, чтобы придумать новые миры, а в том, чтобы совместить идеальный мир с тем, что существует на самом деле. Конечно, было бы идеально провести реорганизацию или переписать правила, но можем ли мы сделать что-то ценное в рамках существующих ограничений, чтобы выявить возможности, которые упускаются в текущем состоянии?

Мы стратегически подошли к решению этой проблемы и устранили её с помощью прототипирования. Мы не смогли заручиться поддержкой для масштабного предложения, поэтому предложили три разные архитектуры и запустили их параллельно с небольшим объёмом реального клиентского трафика. Вариант, который пользовался наибольшим спросом у команды по поиску, работал значительно хуже остальных, отчасти из-за некоторых архитектурных недостатков, но в основном из-за того, что они работали медленнее, чем команда по персонализации. Производственный трафик — это главное практическое отличие.

4. Плохая архитектура — это большой объём работы, который мало что меняет

Давайте обсудим роль главного инженера из «Хорошая архитектура сочетает в себе практичность и стремление к идеалу» раздела выше. Меня попросили рассмотреть предложение по «улучшению архитектуры персонализации», подготовленное инженером из команды, с которой я работал. Оно содержало чётко сформулированные решения, такие как:

Разделение нашего монолитного «сервиса персонализации» на микросервисы.
Запуск наших контейнеров с помощью Amazon EKS.
Использование CloudWatch для сбора журналов.

Предложение было чётким, подробным и хорошо написанным. Оно произвело впечатление как на моего руководителя, так и на вышестоящее руководство. Но у меня было одно серьёзное опасение: в нём не рассматривались наиболее важные проблемы.

Проблема № 1: слишком сложно проводить A/B-тестирование. У нас были функциональные, но громоздкие инструменты. Распределение пользователей по тестам включало в себя:

Поиск пользователей вручную
...выгрузка пользователей в файлы CSV
... разделение пользователей на контрольную и экспериментальную группы
... сбор метрик для каждой группы путем ручного запуска заданий Spark
…или выполнение сложных запросов, связанных с файлами CSV

Процесс не был масштабируемым: одновременное выполнение большого количества тестов было сложной задачей.

Проблема № 2: слишком сложно внедрять новые модели машинного обучения. Нам нужно было внедрить новые модели машинного обучения для ранжирования видео. Мы создали библиотеку-оболочку для встроенной модели машинного обучения, которая использовалась для ранжирования видео в системе поиска и хранения, принадлежащей другой команде. Мы надеялись перейти на систему, в которой ранжирование предоставлялось бы как услуга по протоколу HTTP, или, возможно, инвертировать модель, чтобы RankingService вызывал SearchService, а не наоборот. В любом случае нам нужно было развиваться в этой области, иначе мы бы так и продолжали использовать старые модели и двигались бы очень медленно.

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

Плохая архитектурная работа — это перестановка мебели, когда нужен новый дом. Может быть, здесь изменена технология или там система разделена на несколько частей, но в конечном счёте это стазис, маскирующийся под архитектуру: ничего важного не происходит.

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

Возвращаясь к предложению — оно было одобрено высшим руководством, которое внесло изменения, и всё прошло хорошо. Но мне не кажется, что что-то улучшилось настолько, чтобы это имело значение.

5. Удачные архитектурные решения в проектах Netflix

Мы обсудили несколько архитектурных нюансов и антипаттернов. Теперь давайте вернёмся к моему основному тезису о том, что хорошая архитектура — это последовательное решение существующих проблем с помощью более эффективных решений. Ниже приведены несколько моих любимых архитектурных компромиссов, к которым я пришёл за время работы в Netflix.

Необычные компромиссы: Зуул

В первый год моей работы в Netflix для трафика API использовался сторонний прокси-сервер. Внутренний Netflix API использовался практически для всего, что можно было делать на устройстве, не связанном напрямую с воспроизведением: аутентификации, поиске, получении персонализированного контента и т. д.

Сторонний прокси-сервер был надёжным, но неудобным в настройке, и у нас было мало информации о том, что он делает. Например, у нас не было возможности отслеживать количество одновременных подключений прокси-сервера к конкретной нижестоящей системе, кроме как через SSH-подключение к серверу и передачу netstat в grep, что было круто, но неудобно.

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

Переписать критически важную для бизнеса систему, которая обрабатывала более 50 000 запросов в секунду (RPS), было смелее, чем обычно, но такова была культура Netflix.

Zuul был написан двумя инженерами, одним из которых был я. Мы прошли путь от идеи до запуска в производство менее чем за шесть месяцев. Это был тернистый и увлекательный путь, особенно во время запуска, когда мы откатывали и повторно развертывали систему десятки раз, чтобы исправить различные проблемы на стороне устройства, связанные с OAuth, манипуляциями с HTTP-заголовками и тому подобным. Но быстрое обнаружение и исправление ошибок становится привычным делом, когда вы заменяете стабильную скучную систему гибкой, которую вы постоянно настраиваете и модифицируете.

Мы пошли на весьма необычный компромисс с Zuul: снижение стабильности ради значительного повышения гибкости в важной части нашего стека. Обычно стабильность не меняют ради гибкости, но мы сделали такой выбор, потому что у нас было много идей о том, как использовать эту гибкость, например:

Пользовательские правила маршрутизации для перенаправления определённых пользователей или устройств в определённые кластеры серверных служб
Пограничная маршрутизация и переход на другой ресурс
Подробная информация о трафике
Повышенная безопасность, в том числе защита от DoS-атак и мошенничества

Zuul изменил подход компании к маршрутизации трафика, не связанного с CDN. Но мне всегда было интересно, как мы использовали Zuul в нестандартных ситуациях:

Мы взломали фильтры, чтобы удалить или преобразовать заголовки HTTP-ответов, которые вызывали ошибки на устройствах. Нам нужно было действовать очень точно, поскольку взаимодействие устройств и заголовков сильно различалось в зависимости от устройств и версий, и удаление заголовка ответа могло решить проблему на одном устройстве, но вызвать сбой на десяти других.
Мы столкнулись со множеством особенностей устройств, в том числе с отсутствием или неправильным написанием конечных точек и параметров HTTP, странными пользовательскими схемами аутентификации и многим другим. Зачастую лучше устранить подобные недочёты в одном месте, чем распределять их по всему стеку.
Один из коллег написал фильтр, который временно блокирует Netflix у него дома, чтобы мотивировать сына делать уроки. Фильтр легко настраивается: как только уроки сделаны, он отключается.

Создание инструментов для сокращения объёма оперативной работы: Grepzilla

В команде On the Edge в Netflix было много оперативной работы, которая постоянно отвлекала нас от повседневных дел. Часто к нам обращались случайные инженеры из других команд с вопросами вроде: «Вы не знаете, почему я получаю ответ HTTP 5xx на этот конкретный запрос?»

У нас также было много производственных инцидентов. Чтобы их устранить, нам часто приходилось отвечать на такие вопросы, как «наблюдали ли вы за последние 15 минут увеличение количества сбоев в работе каких-либо конкретных вышестоящих служб?»

Крупномасштабные инциденты — это плохо, но обычно их можно быстро устранить. По моему опыту, гораздо более болезненными были длительные проблемы с небольшим количеством запросов, которые затрагивали небольшое число клиентов. Чтобы решить такие проблемы, мы задавали вопросы, например о том, можем ли мы просмотреть все сеансы запросов с устройств типа X и найти что-то необычное.

Если ваша команда перегружена вопросами и расследованиями, можно использовать несколько подходов:

Направляйте все запросы одному дежурному инженеру или инженеру службы поддержки
Попробуйте нормализовать потребление с помощью JIRA, Google Forms, электронных таблиц или аналогичного инструмента
Смиритесь с тем, что постоянные вопросы — это часть работы, и ничего не делайте, чтобы улучшить ситуацию
Перепоручите работу подрядчикам

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

Одним из внутренних инструментов, которые мы создали, был Grepzilla, распределённый аналог tail и grep, или специализированная, но значительно менее функциональная версия Splunk. Мы с коллегой работали над ним неполный рабочий день в течение трёх месяцев, пока не набралось достаточно функционала для запуска в производство. Если посмотреть шире, то можно увидеть, что мы пожертвовали необходимостью отвечать на бесконечный поток рабочих вопросов ради использования системы запросов событий в реальном времени.

Это открыло доступ к нескольким полезным функциям:

Группировка HTTP-ошибок по зонам доступности, типам устройств, местоположению клиентов и многим другим параметрам в режиме реального времени
Быстрое устранение ошибок в конкретных бэкенд-системах, которые давали сбой
Для ошибок с меньшим количеством символов нужно найти конкретные узлы, на которых возникла ошибка, чтобы мы могли SSH подключиться к ним и найти более подробную информацию в журналах ошибок
Поиск медленных запросов с последующим разделением их на самые медленные подзапросы для выявления основных причин задержек

Grepzilla действительно помогла нам сократить время, затрачиваемое на расследование пограничных случаев. Однажды я заметил всплеск трафика в нашем европейском кластере Zuul, запустил Grepzilla для анализа трафика и увидел, как в режиме реального времени происходит атака по словарю, в ходе которой злоумышленник перебирал пароли в алфавитном порядке.

Замена одних ограничений другими: маршрутизация на границе нескольких регионов

В 2012 году произошёл масштабный сбой в работе AWS us-east-1 в канун Рождества, который затронул многие критически важные балансировщики нагрузки Netflix.

Мы ненадолго задумались о создании собственных балансировщиков нагрузки, но решили этого не делать. Вместо этого мы расширили наши возможности, развернув Zuul в AWS us-west-2 и направив трафик с западного побережья Северной Америки на наши существующие серверы в us-east-1. Мы назвали Zuul в us-west-2 нашим Перешейком. Идея заключалась в том, что если у нас снова выйдет из строя балансировщик нагрузки в us-east-1, мы сможем перенаправить DNS на us-west-2, чтобы избежать этого. Задержка была бы выше, но и доступность была бы выше, что является хорошим компромиссом.

Но такой подход повысил отказоустойчивость только на периферии. Остальная часть нашего серверного стека по-прежнему была уязвима для сбоев в us-east-1. Поэтому мы перенесли весь наш стек в us-west-2и разделили трафик между регионами.

Очевидно, что управлять трафиком в нескольких регионах сложнее, чем в одном. Нам нужно было обеспечить разумное распределение трафика, доставлять все развертывания и изменения конфигурации во все регионы, а также определять нужный регион при отладке. Технически мы уже работали с несколькими регионами, потому что в 2011 году развернули сервис в eu-west-1 для запуска в Европе. Однако это решение было принято в первую очередь для развития бизнеса, а не для обеспечения отказоустойчивости, и не предполагало переноса существующего трафика, поскольку все европейские клиенты были новыми.

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

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

Модернизация системы для повышения эффективности в будущем: глобальные модели персонализации на основе ИИ и МО

До 2016 года многие основные модели персонализации Netflix обучались на региональном уровне. Это означало, что модели, используемые для рекомендаций контента в определённом географическом регионе, обучались только на данных пользователей из этого региона.

Одним из преимуществ такого подхода было то, что собрать обучающие данные было несложно: достаточно было отфильтровать данные из соответствующего региона. Но у этого подхода были и недостатки, один из которых заключался в том, что модель не могла обучаться глобально. Модели, обученные на данных из небольших стран, не учитывали соответствующие модели использования в других странах.

Итак, когда в 2016 году Netflix вышел на мировой рынок, то же самое сделали многие модели персонализации.

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

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

При случайной выборке в наборе данных преобладают самые многочисленные группы. В то время при случайной выборке наших данных об использовании 90 % пользователей из США были бы в базе данных с длительным стажем. Это было не лучшим решением для обучения модели, которая также использовалась для обслуживания новых пользователей в Индии или Японии.
Если вы хотите проводить обучение с использованием одинакового объёма данных по каждой стране, размер набора данных будет ограничен численностью населения самой маленькой страны. Это не лучший вариант, так как большинство моделей плохо работают при недостаточном количестве обучающих примеров.

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

Когда мы увидели, насколько плохи некоторые из наших обучающих данных, мы ужаснулись. Но после того, как мы это исправили, продукт стал лучше.

Когда мы обнаружили, что случайность, которую мы внедряли для 10 % пользователей, меняющихся каждые 10 дней, на самом деле не менялась, а просто месяцами показывалась одним и тем же пользователям, мы снова расстроились. Но, опять же, после того как мы это исправили, продукт стал лучше.

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

6. Как улучшить свои навыки в области архитектуры

Мы обсудили архитектурные нюансы и рассмотрели примеры исключительных архитектурных решений, с которыми я сталкивался за свою карьеру. Теперь я хотел бы завершить эту статью несколькими советами о том, как улучшить свои навыки в области архитектуры.

Разрабатывайте системы, исходя из того, что может сломаться

На протяжении всей своей карьеры я задавал на собеседованиях такой вопрос: я рисую простую систему, состоящую из двух сервисов, которые взаимодействуют по протоколу HTTP — один в качестве клиента (сервис 1), а другой в качестве сервера (сервис 2). Затем я прошу кандидата описать все возможные сбои в работе системы.

Обычно в ответ на это говорят, что service2 может «стать медленным», на что я отвечаю:

Что именно означает «медленно»?
По каким причинам запросы от сервиса 1 к сервису 2 могут выполняться медленно?
Как измеряется задержка?

Могут ли другие факторы влиять на воспринимаемую задержку service2 в зависимости от способа измерения?

Каковы последствия замедления работы сервиса 2 и как их можно смягчить?

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

Мы также начнём искать решения:

Чтобы ускорить работу сервиса 2, можно добавить кэш.
Если данные меняются нечасто, мы всегда можем проверить кэш перед отправкой запросов в сервис.
Если запуск кластера, способного кэшировать всё, обходится слишком дорого, то какой процент обращений к кэшу можно считать приемлемым?
Если кэш исчезнет во время сбоя, как мы сможем ограничить зону поражения?

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

Знайте свою аудиторию

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

Я помню, как смотрел презентацию, в которой была идея, которая запала мне в душу: цель любой презентации — убедить аудиторию совершить какое-то действие. Всё, что вы говорите, должно быть направлено на достижение этой цели.

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

Перед каждым разговором тщательно продумывайте, какие действия вы хотите, чтобы совершила аудитория, и следите за тем, чтобы ваши слова и схемы способствовали достижению этой цели. Если вы знаете свою аудиторию — кто эти люди, что они знают и чего не знают, чего они хотят, — то эта задача становится намного проще.

Сосредоточьтесь на правильных деталях

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

Для этого есть несколько причин. Во-первых, нужно определить все решения, которые необходимо принять. Во-вторых, нужно классифицировать решения как важные или не очень. Незначительные решения можно отложить или делегировать кому-то другому, чтобы сосредоточиться на самых важных. Эти два типа решений можно сравнить с «односторонними» и «двусторонними» дверями, о которых говорил Джефф Безос в письме акционерам Amazon в 2015 году.

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

Если говорить конкретнее, то одна из деталей, которая часто не даёт мне покоя, — это задержка. За эти годы я видел множество предложений, связанных с вычислениями, которые невозможно выполнить за приемлемое время из-за таких ограничений, как логическая последовательность, размер данных и задержка в сети. Если вы спросите об этом на совещании или при обсуждении документа, вам могут ответить: «Мы разберёмся с этим позже». Но «позже» — это слишком поздно, если фундаментальные аспекты архитектуры невозможно оптимизировать для достаточно быстрого выполнения. Чтобы донести эту мысль, вам действительно нужно углубиться в детали. В долгосрочной перспективе это будет только лучше.

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

Сделай себя полезным

Независимо от должности или стажа работы, все мы занимаемся тем, что переводим проекты из стадии идеи в стадию реализации. Если следующий шаг неясен, найдите способ — любой способ — двигаться дальше.

Это может быть связано со многими вещами. Вот несколько личных примеров:

Потратьте месяц на то, чтобы повысить скорость развёртывания, так как это позволит добиться многих улучшений в дальнейшем.
Руководить проектом, выступая посредником между несколькими командами, которые не ладят друг с другом.
Написание стратегических или концептуальных документов или помощь коллегам в их доработке.
Написание тестов, инструментов или скриптов для повышения надёжности или удобства использования конкретной системы.

Этот список можно отнести к «черновой работе», поэтому следите за тем, сколько времени вы на неё тратите, если ваша организация не ценит её. Но я заметил, что если вы зарекомендовали себя как компетентный специалист, то заполнение этих пробелов и продвижение вперёд могут расширить ваши возможности в будущем. Кроме того, я заметил, что архитекторам, которые не боятся запачкать руки и выполнять чёрновую работу, гораздо проще оказывать влияние на других. Авторитет можно заслужить разными способами, и это один из них.

Постоянно приносить пользу, выполняя несколько функций, — хороший способ быть ценным сотрудником. Самые эффективные старшие инженеры и архитекторы, которых я встречал, совмещали в себе роли инженера, технического директора, менеджера по продукту и руководителя проекта. Диаграммы последовательности и крупные технические инициативы — это круто, но не всегда необходимо, в то время как умение продвигать проекты вперёд — критически важный навык.

Выводы

За свою более чем 25-летнюю карьеру я видел, как архитектурная работа принимает самые разные формы: от документов до манифестов, от концепций до «воздуха», от смелых переписываний до бессмысленных, а также от обычной работы над функциями до масштабного брендинга.

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

За время моей работы в Netflix компания была далека от идеала, но мы решали архитектурные проблемы лучше, чем где-либо ещё, где я работал. На ум сразу приходят две причины: практический подход к решению проблем и бесстрашие.

Временами это бесстрашие приводило к серьёзным проблемам. Меня будили в 3 часа ночи, и я работал по 60 с лишним часов в неделю чаще, чем мне хотелось бы. Но я сталкивался и с другой крайностью: часами просиживать на совещаниях, выбирая OKR, и неделями дорабатывать квартальные планы. Позвольте мне сказать, что слишком медленное развитие вредит гораздо сильнее, чем слишком быстрое.

Если вам пригодились мои наблюдения об архитектуре и вы не знаете, как быстрее перейти от идеи к реализации, смело обращайтесь ко мне через мою консалтинговую компанию Supreme Informatics. Спасибо, что прочитали. А теперь идите и что-нибудь постройте!

Гергели здесь. Большое спасибо Мэтту за то, что он объяснил, что для него значит хорошая архитектура и как в ней совершенствоваться. Вы можете следить за Мэттом в LinkedIn и подписаться на его рассылку Push to Prod. И, конечно же, его книга о создании устойчивых к сбоям систем в настоящее время находит своё завершение.

Что для вас значит хорошая архитектура программного обеспечения? Поделитесь своими мыслями в комментариях.

Перевод: https://newsletter.pragmaticengineer.com/p/what-is-good-software-architecture