Найменш обізнана людина в кімнаті: як я потрапив у 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 (коли ІТ-система знаходиться на власних серверах чи у хмарі партнерів), або на використання Bare-Metal серверів (одноосібний віддалений доступ до «заліза»). Їхні аргументи наступні: якщо система має стабільне та передбачуване навантаження, то не потрібна гнучкість й автоматичне масштабування — на цьому можна зекономити мільйони доларів.

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

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

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

Єдиного визначення, що таке високонавантажена система, не існує. В англомовній літературі термін Highload Systems майже не використовується. Зазвичай йдеться про конкретні вимоги до архітектури, як-от легка масштабованість.

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

Якщо казати про Google, так, у компанії всі екосистеми — високонавантажені за замовчуванням.

— Як ви рекомендуєте підходити до побудови високонавантажених систем? Що слід враховувати?

Ключовий момент під час розробки будь-якого програмного забезпечення — детально зрозуміти вимоги. Зокрема: яким саме буде навантаження? Чи буде воно змінюватися — як кількість користувачів, так і обсяг даних, що потрібно обробляти? Чи є система чутливою до затримок? Якою буде географія клієнтів, тобто у якому регіоні мають бути розташовані сервери?

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