Наименее осведомленный человек в комнате: как я попал в Google и стал там техлидом

Лектор курса «Архитектура высоких нагрузок» Ярослав Литус уже более 12 лет создает программное обеспечение для Google. Мы решили расспросить его, как в компании работают с высоконагруженными системами, — ведь кто, как не Google, сталкивается с вызовом постоянного роста пользователей и их данных.

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

О том, над чем Ярослав работает в Google, как компания изменилась за 12 лет и как за это время развилась индустрия highload-систем, читайте в интервью robot_dreams.

Все взгляды, изложенные в этом тексте, принадлежат Ярославу и не представляют позицию Google.

Краткое досье:

Ярослав Литус — Staff Software Engineer в Google, PhD в области Computer Science (получил в Университете Саймона Фрезера в Канаде). Живет и работает в Сиэтле, США. В Google работает с 2011 года: строит и интегрирует массивные распределенные высоконагруженные системы.

Ярослав Литус, Staff Software Engineer в Google, лектор курса «Архитектура высоких нагрузок»

Путь в Google: от рядового разработчика до Staff Software Engineer

— Вы пришли работать в Google в 2011 году. Как попали в компанию?

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

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

Тогда друзья в университете сказали мне: «Вот смотри, ты не хочешь общаться с Google, так что вообще останешься без работы». Я еще раз просмотрел приглашение от компании: они предлагали оплатить поездку самолетом на интервью и все сопутствующие расходы. И я согласился — просто из любопытства.

Крупнейший канадский инженерный офис Google расположен в Китченере, Южное Онтарио, — туда я и улетел. В один день у меня было 5 технических интервью с разными специалистами. И эти люди мне так понравились, что я почувствовал: вместе с ними мне было бы интересно работать над любыми проектами. Их уровень знаний поражал! Вскоре я получил оффер и уже без колебаний принял его. Решил, что работа в индустрии — вариант получше, чем карьера преподавателя в колледже.

О своем решении не пожалел. И до сих пор люди, с которыми я работаю, — это главный фактор, почему я остаюсь в компании. У всех наших инженеров разные бэкграунды, поэтому у каждого можно чему-то научиться. Очень часто ты сидишь на совещании с группой инженеров и понимаешь, что ты — the least knowledgeable person in the room (наименее осведомленный человек в комнате — прим. ред.). Это шанс взаимодействовать с лучшими специалистами, перенимать их опыт.

— Над какими продуктами работали эти 12 лет?

Когда я принимал оффер, то не знал, в какой команде буду работать. Но попросил привлечь меня к проекту, над которым работали два инженера из тех, кто меня собеседовал. Так я попал в команду, которая занималась Machine Learning для Direct Response Advertising.

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

Я работал над этим проектом в течение 5 лет, пока не решил вернуться на Западное побережье. В Канаде нет офисов Google в этом регионе, поэтому мне предложили переезд в США, в офис неподалеку от Сиэтла.

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

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

— А как росли карьерно: какие роли и позиции меняли?

Я начинал свой путь в Google как рядовой Software Engineer. За три года дорос до позиции Senior Software Engineer. После переезда в США начал работать как Technical Lead. Сейчас я Staff Software Engineer, это следующая карьерная ступень.

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

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

Но я именно Technical Lead, а не менеджер. В Google заведено, что на одном уровне работают два человека — есть People-менеджер и Technical Lead:

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

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

Селфи из кампуса в Киркланде, 2021 год

Работа в бигтех: преимущества и недостатки

— Каким был Google в 2011 году? Что в целом изменилось за это время?

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

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

— Какими достижениями в своей работе в Google гордитесь больше всего?

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

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

— А допускали ли критические ошибки? Может быть, можете поделиться каким-нибудь поучительным опытом?

Критических — нет. Обычные ошибки, конечно, бывали. Но, к сожалению, не могу раскрыть детали.

Вообще у Google распространена культура blameless postmortem. Если человек совершает ошибку, то команда тщательно анализирует произошедшее. Но не для того, чтобы наказать виновного, а для выводов. Ожидается, что все внутренние системы и процессы построены таким образом, чтобы снизить вероятность ошибки.

Помню случай — он не об ошибке, а скорее о курьезе. Как-то мы с коллегой ехали в командировку из Китченера в Питтсбург, это 5–6 часов езды. Мой коллега — тоже PhD, поэтому мы начали сравнивать жизнь в академии и индустрии. Я говорю ему: «Все-таки в индустрии лучше».

И буквально через 5 секунд у меня звонит телефон: на нашем проекте произошла авария — и нужно было срочно ремонтировать. Хотя в тот день я не был на дежурстве, пришлось включиться. Мы съехали с дороги, остановились. Уже потом я подытоживаю: «Ты знаешь, об этом аспекте я забыл». Ведь в академии никаких аварий или дежурств!

— В последнее время медиа пишут о массовых увольнениях в бигтех-компаниях. Можно ли говорить об определенном кризисе в индустрии?

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

— Что можете посоветовать начинающим, мечтающим попасть в бигтех?

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

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

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

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

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

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

курс по теме: Архитектура высоких нагрузок

Ярослав Литус Staff Software Engineer в Google

 

Высоконагруженные системы: тренды и лучшие подходы к построению

— Какие вызовы стояли перед архитектурой высоконагруженных решений 12 лет назад? А какие — сейчас? Какие тенденции наблюдаете?

На примере Google я, к сожалению, не смогу рассказать. Но могу определить, что вообще изменилось в индустрии. Еще 10–12 лет назад у бизнесов, стремившихся построить высоконагруженную систему, было немного опций. Что приобретение собственных серверов, что развертывание в облаке — оба варианта были дорогими.

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

В то же время в последние годы я замечаю и обратную тенденцию. Ряд компаний, напротив, отказывается от облачных решений и возвращается либо на On-Premise (когда IT-система находится на собственных серверах или в облаке партнеров), либо на использование Bare-Metal серверов (единоличный удаленный доступ к «железу»). Их аргументы следующие: если система имеет стабильную и предполагаемую нагрузку, то не нужна гибкость и автоматическое масштабирование — на этом можно сэкономить миллионы долларов.

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

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

— «Высоконагруженная система» — о каком количестве пользователей или данных идет речь? Все ли сервисы Google по умолчанию высоконагружены?

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

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

Если говорить о Google, да, в компании все экосистемы — высоконагруженные по умолчанию.

— Как вы советуете подходить к построению высоконагруженных систем? Что следует учесть?

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

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