Solutions Architect Ігор Іванюк — про кар’єру в AWS, ключові принципи Amazon і те, як бути архітектором у технологічному гіганті
Понад чотири роки Ігор Іванюк працює архітектором в Amazon Web Services (AWS). За цей час він розв’язував проблеми найрізноманітніших клієнтів від ентерпрайзів до стартапів і отримав підвищення від Senior Solutions Architect до Principal Solutions Architect.
Ми розпитали Ігоря про те, як відбувається найм у техгіганті, що робить архітектор в AWS, чому принципи лідерства в Amazon мають суперечності і скільки годин доводиться працювати.
Запрошуємо на DOU Day — першу велику офлайн-конференцію від DOU! Київ, 18 травня. Серед партнерів — продуктові компанії Genesis, Brainstack_, Universe, SKELAR, Skylum, Readdle, Mojam, а в програмі — Product Stage. Купуйте квитки!
«Я почав отримувати перші відповіді на вакансії через три місяці». Про початок кар’єрного шляху та переїзд до Мюнхена
Ще 2001 року я вступив до КПІ на спеціальність «Комп’ютерні науки». Цей вибір був свідомим. Я почав працювати з комп’ютером 1997 чи 1998 року, коли в нашій сім’ї з’явився IBM-PC 386 (олдам привіт!) з кнопочкою Turbo, яка змінювала частоту з 20 MHz до шалених на той час 40 MHz.
У 2007 році я вийшов на першу комерційну роботу в IT-сфері. Це був маленький дочірній підрозділ французької фірми. В українській команді було близько 15 людей, ми працювали у великій квартирі та робили вебсистеми з бекендом на Java. З того часу я продовжував кар’єру як Java-розробник.
У 2010 році почав працювати в EPAM, а
А потім в певний момент я вирішив шукати роботу в Німеччині. Це був 2015 рік, і на той час багато моїх друзів та знайомих проживали в цій країні. Я сам бував там кілька разів і зрозумів, що мені подобається продумана інфраструктура, зручний громадський транспорт, загальний комфорт. Відчуття стабільного, мультикультурного та інтернаціонального суспільства, і мені захотілося здобути новий життєвий досвід за кордоном.
Щоб знайти роботу в Німеччині, я розіслав резюме у купу компаній. І почав отримувати перші відповіді через три місяці від початку пошуків, коли кількість моїх відгуків перевалила за дві сотні. Але зрештою я пройшов кілька віддалених співбесід. Потім були запрошення на онсайт-інтерв’ю, які примудрився пройти в один день. І пристав на офер від німецької компанії Zooplus. Влітку 2015 року я переїхав до Мюнхена.
«Архітектор — це наче ліфт між відділами». Про кар’єрне зростання
Zooplus — це великий e-commerce, але водночас і продуктова компанія, адже все їхнє програмне забезпечення самописне: системи магазину, логістики. Я працював у команді, яка займалась вебзастосунком, що реалізує магазин. На певному етапі стало зрозуміло, що впираємось у наш спосіб деплойменту. Вебзастосунок магазину хостився на двох десятках фізичних серверів. Реліз нової версії відбувався практично вручну і тривав більше як годину.
На черговій ретроспективі ми вирішили, що потрібно прискорювати релізи. А однією з головних проблем, яка зменшувала їхню швидкість, була залежність від тогочасного релізного циклу. Тоді почали набувати популярності ідеї infrastructure as a service і з’явилися приватні хмарні рішення. Вже існував Kubernetes, але ми в компанії обрали Apache Mesos. Це теж фактично приватна хмара.
Тоді постало дуже цікаве завдання. Магазин був величезним монолітом з купою залежностей, а білд займав добрих 20 хвилин без урахування тестів. Потрібно було цей моноліт спочатку контейнеризувати, а потім поділити, щоб підготувати до запуску в умовах приватної хмари.
Коли ми в команді почали говорити, як до цього підійти, зрозуміли, що потрібна людина, яка б за це відповідала: організовувала процес, координуючи різні команди, і розробила б загальну архітектуру, яка продовжуватиме працювати з масштабуванням. Я почав говорити з лідами та учасниками інших команд, взявся за будівництво цільової архітектури.
У компанії був головний архітектор, а я, бувши просто розробником, став виконувати роль архітектора e-commerce-частини. Мені це вдалося. Тоді я став працювати більше як архітектор, хоча продовжував писати код і у будь-який момент міг в себе на лептопі збілдити всі наші продукти, перевірити помилки. Але все більше часу займали розв’язання та комунікація архітектурних питань. 2018 року я на деякий час повернувся в IntellectEU, але вже як архітектор і працюючи з Мюнхена.
Робота архітектором більше, ніж робота розробником, змушує спілкуватися мовою бізнесу, зокрема з нетехнічними менеджерами. Мені подобається концепція Architect Elevator Грегора Гогпе (Gregor Hohpe). Вона полягає в тому, що різні відділи в компанії — це як різні поверхи будівлі. Якийсь поверх — це розробники, інший поверх — продакт-оунери чи бізнес-директор, ще один поверх —
Щоб ця комунікація була ефективною, архітектор має спілкуватись з людьми різних профілів їхньою мовою. З розробниками про технічні особливості, з бізнесом про KPI і те, які бізнес-вимоги системи можуть підтримати, скільки для цього потрібно часу і грошей.
Під час подорожі в Ісландію, 2021 рік
«Amazon здавався недосяжним місцем роботи». Про перехід в AWS і виклики бути архітектором у технологічному гіганті
На початку 2019 року я почав задумуватися над напрямами розвитку карʼєри. У попередніх компаніях у мене з’явився досвід роботи з сервісами AWS, та сама Amazon здавалася недосяжним місцем роботи для мене, тому таку ймовірність я не розглядав. Але у квітні того ж року до мене в LinkedIn звернувся рекрутер з AWS з вакансією архітектора. Був фокус на Україні, і він переконав мене спробувати пройти співбесіду.
Рекрутинговий процес в AWS складався з двох етапів і почався з двох телефонних інтерв’ю у квітні-травні
Також мені було важливо здобути досвід у FAANG, в одній з найбільших ІТ-компаній у світі. Своєю чергою, від мене очікували ініціативності, здатності самому менеджити свій час і працювати в умовах постійних змін.
За два дні я отримав позитивний фідбек, і ми запланували другий етап, так званий interview loop — це набір з
Ще за кілька днів мені зателефонував рекрутер і повідомив, що я успішно пройшов всі етапи, і скоро я отримав офер. У Німеччині заведено повідомляти про бажання звільнитися за три місяці, тому фактично я почав працювати в AWS з жовтня 2019 року. Кожен новий співробітник отримує детальний і насичений онбординг-план, виконаний у форматі списку завдань і розрахований на три місяці. Перші кілька тижнів я знайомився з командою та з внутрішніми ресурсами, системами, а решту часу витратив на занурення в сервіси AWS і проходження сертифікацій.
Я досі продовжую писати код, бо обираю це
Solutions Architect в AWS — це людина, яка взаємодіє з компаніями, що хочуть використовувати хмарні послуги, і допомагає це робити якомога успішніше. Моє головне завдання — допомагати клієнтам правильно побудувати хмарні системи. Системи мають не лише технічно виконувати певні задачі, а й бути оптимальними з погляду вартості. Це може здатися несподіваним, але я намагаюся робити так, щоб клієнти платили нам менше, а не більше. Ми віримо в побудову довготермінових відносин із замовниками.
У Solutions-архітекторів, як і в більшості учасників акаунт-команди, що працює з клієнтами, немає доступу до клієнтської інфраструктури. Ми не можемо нічого зробити з ресурсами чи даними клієнта. У нас чіткий розподіл відповідальності. Є частина, за яку відповідає Amazon, зокрема підтримання інфраструктури тощо. І частина, за яку відповідає сам клієнт: контроль доступу до клієнтських хмарних ресурсів, до даних, бекапи.
Я досі продовжую писати код, бо я це обираю. В AWS максимальний ступінь свободи у виборі того, що робити. Завдань завжди більше, ніж годин у добі, і ви самі визначаєте, чим вам цікаво займатися. Я менше пишу код, ніж раніше, але інколи розробляю демо для клієнтів. Готую приклади застосунків чи функцій, розробляю інфраструктуру. Також часто добираю навчальні матеріали, роблю воркшопи. Проаналізувавши свої репозиторії, зрозумів, що зараз більше пишу на Python і Node.js, ніж на Java, і в мене стало менше суто кодингу, а більше створення готових рішень з коду, інтеграцій та інфраструктурного коду.
Упродовж одного тижня я можу стикатися з абсолютно різними проєктами. В понеділок взаємодію з великим ентерпрайзом для оптимізації міграції величезної бази даних SAP, де оперативна пам’ять вимірюється терабайтами. В середу працюю з компанією, яка запускає високонавантажений Kubernetes-кластер і свої мікросервіси у нас, спілкуюся з їхніми архітекторами, щоб зрозуміти, як оптимізувати мережеві затримки в їхньому ланцюжку виклику мікросервісів, написаних різними мовами. А в п’ятницю зустрічаюся з українським стартапом, який зацікавлений використовувати наші послуги з комунікації зі супутниками, щоб отримувати з космосу фотографії полів. Наприклад, щоб робити передбачення про врожай для наших фермерів і розпізнавати хвороби рослин. Кожен день щось нове. Це, напевно, найцікавіша частина роботи.
Щоб займатися такими різноманітними завданнями, треба мати широкі знання. Коли я спілкуюся з клієнтами, в їхніх очах я представник AWS, головний технічний контакт і канал доступу до цього гіганта. Мені потрібно дуже багато розуміти й швидко розбиратися в архітектурних деталях.
Ця робота вимагає самодисципліни, щоб працювати менше. Завдань завжди багато, і є дуже велика ймовірність себе перенавантажити. Тут кожен сам відповідає за пріоритезацію роботи та управління часом. Є ризик, скажімо так, перевтомитись, через що проходять всі Solutions-архітектори в AWS після початку роботи. Я теж з початком активної роботи з клієнтами інколи працював ввечері та у вихідні. Після кількох років у такому режимі я все ж зміг повернути своє навантаження приблизно до 40 годин на тиждень. Точного обліку робочого часу в нашій команді немає.
«Amazon має 16 принципів лідерства, і в них можна знайти суперечності». Про філософію роботи AWS
Сам алгоритм відбору і найму людей в AWS заохочує, що в компанії збираються спеціалісти з певним набором моральних цінностей і підходів до роботи. У нас є спільний майндсет. І це допомагає. Якщо ви всі пройшли співбесіду і дієте за цими принципами, то ви на одній хвилі, вам легко комунікувати та працювати з колегами.
Amazon — це дуже децентралізована компанія. Команди мають багато незалежності. І єдина причина, чому AWS досягла свого масштабу, не втративши швидкість інновацій, це наші принципи. Якби ми працювали в плановій моделі чи моделі жорсткого керування, сумніваюся, що можна було б компанію такого масштабу змусити рухатися так швидко.
Лише з приходом в AWS я вперше побачив компанію, яка щодня користується тими корпоративними ідеями, які декларує. Вони називаються Amazon Leadership Principles.
Перший принцип лідерства Amazon, який мені найбільше імпонує — це customer obsession, одержимість клієнтом. Не секрет, що більшість сервісів AWS з’явилися як реакція на запити людей. Коли клієнт звертається з технічними питаннями, то відповідно до цього принципу спеціаліст має розібратися, що насправді потрібно клієнту.
Наприклад, запитують, як прискорити запуск віртуальної машини, на якій працює Microsoft SQL Server, тому що хочуть її вмикати й вимикати залежно від навантаження. Щоб не витрачати гроші на ресурс, який не використовується, скажімо, вночі. Очевидно, що проблема, яку хоче вирішити клієнт — це економія грошей.
Одне з можливих рішень оптимізації конкретної системи — це перехід на опенсорс-рушій бази даних. Відмовитися від Microsoft SQL Server і перейти на Postgres і використовувати базу даних, яка автоматично масштабується. Проблема, яку клієнт хоче вирішити, взагалі зникає, тому що з’являється база, яку не треба вмикати й вимикати. Можливо, економічно це рішення виявиться ефективнішим, ніж увімкнення й вимкнення сервера.
Усього Amazon має 16 принципів лідерства, і в них можна знайти суперечності, але цьому є пояснення. Наприклад, один з принципів — Dive Deep. Він передбачає, що потрібно докопуватись до суті, знаходити причини або мотиви подій. Звертати увагу на маленькі деталі та вимоги. З іншого боку є принцип Bias for Action. Він передбачає, що краще не намагатися дослідити всі деталі, а зробити пілот і подивитися, що вийде. Суперечливість вбудована в ці принципи цілеспрямовано, адже це набір інструментів, що адаптується під різні ситуації.
Одна з ключових концепцій — one-way-door-decision та two-way-door-decision. Ми запитуємо себе, наскільки дорого чи складно буде повернутися. Чи можна все скасувати? Якщо так, то це two-way-door, коли ціна експерименту і можливої помилки не дуже висока, тому краще спробувати щось на практиці, ніж довго моделювати і продумувати. Застосовуємо Bias for Action. Якщо ж рішення може мати незворотні наслідки або повернення буде дорогим, то маємо більше думати — Dive Deep. Детальніше про принципи лідерства компанії можна дізнатись зі статті від досвідченого директора з Amazon.
«Не пускайте свою кар’єру на самоплив». Про підвищення та досвід проведення співбесід в AWS
2023 року мені вдалося отримати підвищення від Senior Solutions Architect до Principal Solutions Architect. Цю ідею подав мій менеджер на 1:1 зустрічі. Для підвищень в AWS готують так званий промодокумент, який описує досягнення фахівця. Головна ідея — продемонструвати, що кандидат уже працює на рівні нової ролі, а масштаб його завдань і вплив більше не обмежується конкретним клієнтом. Наприклад, ви створили воркшоп, який допоміг 10 чи 100 клієнтам опанувати технологію. Або розробили рішення, що використовують замовники з різних країн.
Для промодокумента потрібно збирати описи великих історій і просити відгуки колег. Колеги мають бути того рівня, на який ви хочете перейти, або вище. Люди, які ухвалюють рішення, базуються на цьому документі. Є досить чіткі вимоги на кожну позицію з описом, як людина плюс-мінус має працювати на конкретному рівні. Хоча вони не враховують специфіку клієнтів, адже хтось працює з великими компаніями, а хтось зі стартапами.
Головні відмінності між Senior i Principal SA можна звести до кількох моментів. По-перше, це рівень людей і процесів, на які спеціаліст має вплив. Principal SA має працювати з вищим керівництвом компанії
Звісно, гарантувати промоушен ніхто не може. Так чи інакше розвиток кар’єри — це ваше власне завдання. Потрібно брати це під контроль, ставити собі кар’єрні цілі та планувати. Ставити собі запитання: «Чим я хочу займатися з погляду домену, масштабу? Чому я зараз не можу це робити? Тому що у мене недостатній рівень в цій компанії чи тут цього в принципі не можна досягнути?»
Таке планування може підказати, що час змінювати роботу або навіть сферу. Або розвивати певні навички, скажімо, System Design, оптимізацію швидкодії, інформаційну безпеку, DevOps. Розуміння, як код виконується в рантаймі, як його можна моніторити, виправляти на продакшені та підтримувати, робить вас в очах працедавця ціннішим за людину, яка просто вміє писати код. Не пускайте свою кар’єру на самоплив.
Я провів в Amazon уже понад 120 співбесід
У нас найм — це одна з високопріоритетних задач. Якщо в команді є відкриті вакансії і вас запрошують проводити співбесіду, більшість колег погоджується. На сьогодні я вже провів в Amazon понад 120 співбесід. Частина з них — телефонні скринінги, частина — власне великі інтерв’ю. Переважно спілкувався з кандидатами на позиції архітекторів.
З мого досвіду одним з умінь, яке є важливим для успішного проходження співбесід в Amazon, володіють далеко не всі кандидати. Це вміння звʼязно і послідовно розказати історію з власного робочого досвіду. Більшість сучасних ІТ-компаній проводять поведінкові інтерв’ю або принаймні ставлять відкриті питання. Де кандидату потрібно розповісти, як він вирішив складну проблему в команді або запропонував покращити процеси тощо.
Інтервʼюеру набагато простіше зрозуміти вашу історію, розпитати про деталі й скласти про вас позитивне враження, якщо ваша відповідь буде структурованою, міститиме логічні переходи між частинами, вступ і висновки. Найбільш відомий формат, якого я рекомендую дотримуватись — це STAR: Situation, Task, Action, Result. Під час підготовки до співбесід варто потренуватись складати свої відповіді за STAR, або ще краще — підготувати кілька історій наперед, розписавши їх у цьому форматі.
У моїх найближчих планах спробувати карʼєрний шлях менеджера. І, звісно ж, продовжувати допомагати українським компаніям зростати і розвиватись, ефективно використовуючи AWS.
Про те, як Amazon та AWS допомагають Україні, читайте в новині.
