Що має знати Senior DevOps Engineer, щоб заробляти від $6500

Продовжуємо рубрику «Що має знати Senior» і цього разу поговоримо про обов’язки DevOps Engineer. За даними DOU, медіана зарплат для DevOps Engineer з досвідом понад п’ять років і рівнем англійської від Upper-Intermediate у грудні 2023 року становила $6000 після податків. Я поставив перед собою ціль з’ясувати, які знання та навички очікують від спеціаліста роботодавці, що готові платити вище за медіану.

Для цього я скористався фільтром вакансій на Djinni, встановивши мінімальний поріг зарплати в $6500, а також відібрав вакансії на DOU із зарплатною вилкою від $6500. Таких вакансій я знайшов 25. Тут і позиції, де прямо не вказали тайтл Senior, але є відповідна зарплата. Для зручності абсолютні цифри переведені у відсотки. Поділ технологій на групи умовний.

Графіки нижче демонструють популярність тих чи інших технологій, але, на жаль, мало що говорять про особливості саме ролі Senior. Тому я попросив відомих DevOps-спеціалістів розповісти, що відрізняє DevOps-інженера рівня Senior від Middle. Якими є червоні прапорці при наймі Senior DevOps, а також які цікаві випадки траплялися на співбесідах.

Вакансії, що потрапили в дослідження: (настисніть, щоб розгорнути)

DOU — Dysnix, Naviteq

Djinni — 5Blue Software, Adaptiq, Alty, ATLASLIVE, Career Karma, Data Science UA, Digital Method, EzApp, EpicentrK, FlexMade, GlobalLogic, Evoplay, LotusFlare, MEGOGO, Meest Group, MUGCO, Oncommarket, Raiffeisen Bank, RubyPlay, Social Solutions Group, Stape, TemaBit Fozzy Group, TrafficMarket

А якщо ви хочете обговорити перспективи, кар’єрні можливості та тренди DevOps з колегами, запрошуємо вас на офлайн DOU DevOps Meetup, що відбудеться вже 13 червня у Львові.

Досвід роботи, який вимагають компанії

Більша частина вакансій передбачає, що кандидат пропрацював за спеціалізацією DevOps від п’яти років. Проте отримувати високу зарплатню можна і з меншим досвідом.

Необхідний рівень освіти

У жодній вакансії не йдеться про диплом магістра. Профільний диплом бакалавра очікують від кандидата у 24% вакансій, і це рекордно багато для України, якщо порівнювати з іншими спеціалізаціями. Навіть від Data Scientist диплом бакалавра вимагали лише у 8% вакансій, а від iOS-розробника в 3%.

Public Cloud

AWS є найбільш затребуваною хмарою. GCP та Azure значно їй поступаються.

Контейнеризація

Жодну іншу навичку роботодавці не згадували у вакансіях так часто, як Kubernetes. Фактично DevOps-інженер без Kubernetes не може існувати.

Мови програмування

Дуже поширеною є вимога знати відразу дві мови програмування. Найбільш затребуваною є пара Python + Bash. Але зверніть увагу на популярність Golang. Це може стати вашою конкурентною перевагою.

Далі наведу кілька груп технологій без коментарів. Цілком очікуваними є вимоги знати Linux та CI/CD тощо.

Infrastructure as Code

CI/CD

Monitoring

Cloud Security

Технології персистентності

Message brokers

Операційні системи

Інші технічні навички

Рівень англійської

Сумарно у 56% вакансій згадують англійську мову. Згідно із зарплатним віджетом DOU, підвищення рівня англійської з Upper-Intermediate до Advanced збільшує зарплату DevOps-інженера з $6000 до $6833, або $9996 на рік.

М’які навички

Комунікаційні навички високо цінують. Проте не лише їх. Наприклад, є роботодавці, які прямо вказали, що для них важлива робоча етика.

Скільки зараз заробляють сеньйори-девопси? Ми розповімо зовсім скоро, у літній аналітиці. А поки допоможіть, будь ласка, нам зібрати дані. Вже маємо майже вісім тисяч анкет.

Цікавинки, знайдені у вакансіях

  • У компанії Dysnix у вас буде можливість контрибутити в опенсорс. Зарплата до $7500.
  • 5Blue Software працює над проривом в галузі 5G та ШІ. Шукають спеціаліста, що має сім років досвіду управління інфраструктурою великих підприємств.
  • Alty шукала DevOps-інженера на неповний робочий день. Серед їхніх клієнтів «Монобанк», «ПриватБанк», Zakaz.ua та EasyPay.
  • GlobalLogic шукала інженера з досвідом парного програмування в Румунію.
  • TemaBit Fozzy Group шукала DevOps-інженера, «що не є євангелістом конкретної технології, а більше турбується про досягнення цінності для бізнесу».

Думки технічних експертів

Денис Васильєв, Senior Site Reliability Engineer у GfK, автор ютуб-каналу [не]правильний DevOps

Ділити на лички — невдячна справа, адже мідли можуть бути навіть кращими за сеньйорів. Я проводжу безліч співбесід, і вони це доводять. Сеньйорність — це більше про відповідальність. Завдання можуть мати різний рівень невизначеності. Рівень сеньйорності відповідає рівню невизначеності, який людина готова взяти на себе.

На це може впливати досвід і базові знання. Оскільки ми працюємо зі свіжими технологіями, досвід не завжди є показником. А от базові знання, розуміння домену — це основне.

Сьогодні багато дискутують про базові знання. Мовляв, знаю тулсет і я класний сеньйор. На мою думку, мідла від сеньйора відділяють фундаментальні знання в предметній галузі, досвід і відповідальність.

На співбесіді я майже відразу розумію, що це — сеньйор. Тому що він каже: «У мене з’явилося завдання. Ніхто його не міг виконати. Я зробив декомпозицію. Осягнув тайм-менеджмент. Набрав команду. І мені ніхто не давав дороговказів. Я сам можу побудувати флоу для вирішення будь-якого завдання з невизначеністю на певному рівні».

Червоним прапорцем на співбесіді Senior DevOps може стати розповідь про те, як він на минулих проєктах будував фортеці. Щоб його не могли звільнити, він щось хардкодить, десь не ділиться інформацією та ізолює інших від знань. На базі цього виникає токсичність і капітанство. Ми віддаємо перевагу команді, а не зіркам у команді.

«У моїй практиці було, що кандидати намагалися пройти співбесіду за допомогою ШІ-асистентів»

Наприклад, є ідеальне резюме з набором сертифікатів. Якщо позиція сеньйорна, я завжди прошу подивитись GitHub. І там понад сто репозиторіїв. Я починаю вчитуватися в коміти та пул-реквести та доходжу висновку, що це згенеровані репозиторії.

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

Ще один кейс — коли я ставлю питання, а кандидат чітко і голосно його повторює. А потім таке відчуття, ніби він зачитує відповідь з документації. Був навіть прокол, коли людина почала відповідати з прикладами коду з фейковими іменами, які їй згенерував ChatGPT.

Юрій Рочняк, Site Reliability Engineer в Preply, автор телеграм-каналу CatOps

Як і в будь-якій іншій спеціалізації, Senior від Middle відрізняє можливість працювати незалежно та готовність брати на себе відповідальність за проєкти, продукти, фічі. На сеньйорному рівні часто немає нарізаних задач. Потрібно розмовляти з бізнесом, розуміти його пріоритети та цілі, трансформуючи їх у технічні задачі та рішення.

Робота в IT — це про компроміси, і дуже часто good enough is enough. Якщо рішення розв’язує проблему бізнесу, то воно good enough.

Бізнесу не потрібно створити кластер чи налаштувати базу даних. Бізнесу потрібно, щоб платформа працювала, потрібна мінімізація даунтаймів. Умовний CEO не скаже: «Нам треба кластер». Він скаже: «Нам потрібно деплоїтись частіше». Або: «У нас був інцидент, коли сервіс був недоступним 10 хвилин і ми втратили мільйон доларів. Як такого не допустити?». Сеньйорна людина має розуміти, як це трансформувати в технічні рішення і які в них є недоліки.

Повертаючись до прикладу з інцидентом: «Гаразд, технічне рішення може бути, зарезервуймо все, будемо тримати по дві й більше реплік всього, що в нас є, але за це треба буде платити гроші. Відповідно, виникає питання, чи можемо ми собі дозволити розширити інфраструктуру удвічі? Чи будуть ці витрати співмірними з ризиками?» Сеньйор мусить відповісти на таке питання. Від мідла я б такого не чекав. Мідлу потрібна міцна технічна база, але хтось має дати задачу.

«В Україні люди нерідко ставляться до співбесід як до іспитів в університеті, де офер — це оцінка»

Насправді людина може бути сильною в технології, яку компанія не використовує. У моїй практиці був випадок, коли ми відхилили класного спеціаліста, тому що його експертиза відрізнялася від того, що ми шукали.

Я бачив мало компаній, де використовують декілька клаудів. Тому є велика варіативність серед спеціалістів. Це може бути сильний фахівець з AWS, але йому доведеться вчити Azure. Якими б класними не були процеси в компанії, спеціаліст починає приносити цінність через пів року, коли він розбереться, як все працює, які є підводні камені тощо. А тут людині ще треба буде вивчити нову технологію.

Якщо компанія є супершвидким стартапом, де пріоритети стрімко змінюються, людина, що звикла до ґрунтовного підходу, не підійде культурно. Якщо ж це медична сфера чи фінанси, не можна працювати за принципом «You live only once, раз-раз і в продакшн». Там вже підійде кандидат з фундаментальним підходом, а тим, хто хоче використовувати останні технології, буде сумно.

Якось ми не найняли спеціаліста, тому що він просив багато грошей. Має бути двосторонній метч.

Загалом не потрібно ставитися до співбесід як до іспитів. Так, я не раз співбесідував людину, яка чогось не знає. Але головне — не бути мудаком.

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному9
LinkedIn


64 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Загалом не потрібно ставитися до співбесід як до іспитів. Так, я не раз співбесідував людину, яка чогось не знає. Але головне — не бути мудаком.

Звичайно, всього знати неможливо, особливо, коли мова йдеться про якісь дрібні речі, як-то абревіатура, чи параметр, який ніхто ніколи не використовує. Саме тому я на інтерв’ю оцінюю потенціал людини і намагаюся зрозуміти, чи є в людини навички та досвід з _вирішення_ проблеми, а не декрарування зазубреної документації :-)

Розбір цієї статті від Дениса Васильєва в подкасті DeadOps Podcast на ютуб-каналі «[не]правильний DevOps».

В огляді Денис зауважує, що серед Message brokers в статті відсутній NATS. На жаль, жодна вакансія з тих, що потрапили в дослідження, не згадувала NATS. Станом на сьогодні в розділі DevOps на DOU є лише одна вакансія, що згадує NATS. Але зверніть увагу на цю технологію!

Є CloudEvents... є Argo Events / Argo Workflows та knative / dapr
Конкретний брокер вже давно максимально абстрагований, а от життєвий цикл операторів типу Strimzi чи RedPanda Operator має значно більший вплив й визначає надійність рішення.

Я бачив мало компаній, де використовують декілька клаудів.

Фактично кожна друга компанія. Один клауд це показник (не)зрілості компанії насправді. Так само як і наявність в компанії таких технологій як Ansible, Salt, чи Puppet — це все застаріле і являє собою сигналом того, що компанія не має ресурсів (людських, чи інтелектуальних — бракує клепок в менеджмента) перейти на більш нову технологію.

Або комаанія в процесі переходу, і це може нести як ризики легасі-мотлоху, так і перспективи цікавих тасок.

Процес переходу означає вже 2 клауди :-)

Так само як і наявність в компанії таких технологій як Ansible, Salt, чи Puppet

А можна підказку будьласка — чим зараз прогресивні компанії заміняють наприклад Ansible ?

Один клауд це показник (не)зрілості компанії насправді.

чому так ? Зтикався з мультіклаудними проектами — ще той пи..ць, а не підхід до роботи. Єдине адекватне було — коли AWS + власні ДЦ у компанії по світу були з раутами між ними... Але властний ДЦ — це не клауд.

А можна підказку будьласка — чим зараз прогресивні компанії заміняють наприклад Ansible ?

Прогресивні компанії вже на мікросервісах. Ті, хто й досі використує з якихось причин повні віртуалки, мають обирати щось між Ansible, Chef server, чи ще щось, звичайно — напевно, йдеться мова про якийсь корпоративний софт, який не засунути в мікросервіси.

ну я б так не казав, я працював з одною компанією світового рівня, так от вони замість Terraform використовують Ansible для усієї інфраструктури, та не мають ніяких з тим проблем... Треба зауважити, що далеко під капотом Терраформу буде все той же аналог Ansible ( або на стороні клауда, або на стороні модуля ) Питання в тому, наскільки далеко ви готові зайти по використаних абстракціях

Я оперую поняттям «тренд» і розумію, що є виключення з нього. Будувати свою теорію на одній компанії світового рівня я б не став, бо є тисячі інших компаній, менших за розміром, але які задають тренд — це напрямок більшості. Саме про нього йдеться мова. Коли технологія не використовується масово, вона або вмираюча, або нішева (і все рівно немає масововості через якусь причину). І яка причина в Ansible? Давай про це поговоримо.

ну подивіться хоч в аналітику цієї статті )))
Ansible 48% Terraform 64%
шось не бачу що ансібль вимирає ...

Ця стаття базована на Job Descriptions, які являють собою _вимоги_ до кандидатів, а не _статистикою_ по використанню технологій в проекті :-) До того ж, я орієнтусь на американський маркет (тобто, беру інформацію з перших рук), а не на український, до якого докотуються як раз ті самі старі технології та компанії, які невзмозі перейти на нові технології.

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

Десяток проектів з застарілими технологіями? Мої співчуття :-) Підростайте до справжнього спеціаліста, щоб проекти були нормальними та з бюджетами, як в мене — тоді побачите справжній рівень компаній з США.

Прогресивні компанії вже на мікросервісах.

а я тут не зрозумів — а чим Ansible заважає мікросервісам і навпаки, у мене наприклад є проект на підтримці де один сервіс працює на 300+ серверах, менеджиться за допомогою Ансібла, Ансіблом і деплоїться і оновлюється — без зайвого суачсного лайна . Лід прогерів якось мені мізки проїдав кубіком але був відправлен збирати плюшки від кубіка ніж той підхід коли те не маєш в проекті кубіка :)

звичайно — напевно, йдеться мова про якийсь корпоративний софт, який не засунути в мікросервіси.

є така штука, коли ти враховуєш проект і перспектику. От знову ж таки зі свого досвіду — знуля зробили на MS архітектурі в Амазоні, кубік — все типу так гарно і все наче круто, але сталося не так як гадалося — коли клієнт почав хотіти і вкладати в додаткові фічі — на проекті кількість сервісів стала зростати і почались зараз думки про об’єднаням сервісів і зменшення того зоопарку і це знову ж таки не поясню «прогрессивість» або «незрілість» :)

а я тут не зрозумів — а чим Ansible заважає мікросервісам

А де в мікросервісах місце Ансіблу? Може я пропустив щось.

на проекті кількість сервісів стала зростати і почались зараз думки про об’єднаням сервісів

Можна передати привіт архітекту, якщо він, звичайно, у вас там є взагалі :-)

якось я не зрозумів і не помітив як ми так різко від

Один клауд це показник (не)зрілості компанії насправді. Так само як і наявність в компанії таких технологій як Ansible, Salt, чи Puppet — це все застаріле і являє собою сигналом того, що компанія не має ресурсів (людських, чи інтелектуальних — бракує клепок в менеджмента) перейти на більш нову технологію.

до

А де в мікросервісах місце Ансіблу? Може я пропустив щось.

Ансібл не інструмент для мікросевісів, це як лопатой цвяхи забивати, хоча і можоиво. У нас розмова про наче про інше, хоча в моєму досвіді є проект де все було через Ансібл, без кубіка і зайвого софта. КОжноій задачі свій набір, але поки що ви не довели до логічного пояснення гучний вислів про застарілий Ансібл і іниший софт, та інше.

Можна передати привіт архітекту, якщо він, звичайно, у вас там є взагалі :-)

На цей час я хз хто там аархітектор, працюю з тим що є.

Якщо моя думка про те, що є сучасний стек не сформувалася у Вашому уявленні — вибачайте. Я подав свої критерії та свій погляд на речі :-)

а цей час я хз хто там аархітектор, працюю з тим що є.

Напевно з цього і треба починати: Ваш проект йде через голову.

Якщо моя думка про те, що є сучасний стек не сформувалася у Вашому уявленні — вибачайте.

У нас тут різне мачення не в цьому питанні.

Напевно з цього і треба починати: Ваш проект йде через голову.

я б так не скзаав. Для мене я бачу проблему в тому, що клієнт замовляє літак, який йому роблять, тестують, віддають. Далі клієнт просить додати йому до літака ще бассейн, потім систему прорахунку ризиків, потім особисту нафтобазу з якої літак має брати керосин і пішло поїхало. Загалом це такий сучасний трендовий підхід Agail у якого ще й маніфест є і складно думаю бути софтверним архітектором у підході де «Готовність до змін важливіша за дотримання плану».

Вибачайте, це не підхід у Agile. Це відсутність архітекта та профанація тіми, яка просто робить, що їм кажуть :-) Кліента треба вести до мети і здавати проект по її досягненню. А коли ви просто робите одне, потім розвертаєтеся на 180 і починаєте робити інше — це відробляєте гроші замовника. Тому і Ansible норм, і тренди погані. Я все розумію :-)

це не підхід у Agile. Це відсутність архітекта та профанація тіми

Відкриваєм Аджаіл маніфест і читаємо.

Кліента треба вести до мети і здавати проект по її досягненню.

ну так, а що робити з клієнтом який повертається з замовленням на приватну нафтому компанію ? Або що робити коли у тебе продуктова компанія і три твої найбільщі клієнти просять один додатковий функціонал, але він за рамками архітектури, у клієнтів обмеженний час, бюджет, при цьому бізнес вимогу/запит потрібно закрити ?

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

І шо зараз використовують замість Ansible?

Наприклад, Chef server. Більш важке рішення, ніж Ansible, але дуже доросле. Починаючи від 20 серверів вже можна ставити. Від Ruby спочатку йде голова кругом, але через місяць починаєш отримувати шалене задоволення.

таких технологій як Ansible, Salt, чи Puppet

мені здаєтьс ви тут вже «пєтляєтє», бо поряд з Puppet в коменті мав стояти Chef, а говорячи про

Наприклад, Chef server. Більш важке рішення, ніж Ansible, але дуже доросле.

Не потрібно було юзати в першому коменті Puppet.

дуже доросле

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

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

Мій підхід це практичний досвід з цими продуктами, а тренди лише підтверджують мої висновки. Буду радий помилитися — наведіть аргументацію, а не емоції. Можете? :-)

Мій підхід це практичний досвід з цими продуктами

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

а тренди лише підтверджують мої висновки

Які саме тренди ? Ну я можу навести пару десятків прикладів коли в компанії з Forbs, з багаторічною історією юзається Java 7 наприклад, Ansible, Jenkins тощо. У цієї компанії працює загалом (зараз точної цифри не має), але було десь близьно 20к людей і це лише ті що в компанії, с кільки ще з сервісних компаній — то там взагалі капець. Тобто з вашого підхода ця компанія:
— не зріла
— юзає застарілі інструменти тому що немає ресурсів, клепки тощо
Хоча в компанії вистачає і грошей, і технарів, і менеджерів. Так в таких компаніх доречі, як у зрілих і з досвідом вже є заокументовані вимоги для багатьох речей — типу там інфру менеджимо через Терраформ, ніякого Клаудформейшину.

Додам ще як приклад Red Hat Enterprise Linux — в якому немає надсучасних трендів і перш ніж в нього додати чергове оновлення — пройде певний час і тут неможна скзаати що Red Hat це застаріла комнанія без грошей, менеджерів тощо.

Ну і додам Perl — який досі використовується дефолтно в Linux і вже є з коробки. Використання PCRE — це загалом не тренд чи ще щось таке — а на мою думку дефакто стандарт при роботі з текстом, конфігами.

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

наведіть аргументацію, а не емоції

Та я вам тут вже навів аргументів і без емоцій. Ви якось не сказали нічого про проект який виглядає як один сервіс, мереджиться за допомогою Ansible, працює на 300+ серверах, на підтримку інфри використовуєтьсяс менше ніж 10к долларів і всії це влаштовує. Без клаудів, без мегасучасних вчергове вигаданих колес та іншого.

Які саме вам ще приклади навести ?

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

Тренд складається з думок окремих людей. Виходьте з цього.

Тобто з вашого підхода ця компанія:
— не зріла
— юзає застарілі інструменти тому що немає ресурсів, клепки тощо

Саме так. На моїй пам’яті є проект, який заробляє 3 мільярди доларів на рік, має 2 тис робітників, а її софтом користуються половина компаній в Top500. Вони й досі юзають Saltstack, в якому 150 тис. строчок коду. Це старий підхід та анахронізм. Дійсно, в компанії бракує або ресурсів чи клепок, щоб це переписати на новий стек.

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

Наприклад в чому? «СЕО любить ночами писати код на Ansible, тому компанія й досі використовує цю тулзу» — так по-Вашому? :-) Назвіть будь-ласка конкретні об’єктивні причини того, що компанія зависає на старому софті.

Дійсно, в компанії бракує або ресурсів чи клепок, щоб це переписати на новий стек.
Назвіть будь-ласка конкретні об’єктивні причини того, що компанія зависає на старому софті.

Подивіться на це з боку бізнесу, нашо переписувати те, що вже працює ?
Хто надасть карантії що вчорашній Ansible, який був в тренді через 10 років не здохне як Perl ?
Переписування проекту з Java 7 + Scala на умовний Python, перемикання клієнтів, зворотня сумістність, підтримка легасі і нової версії в плані інфраструктури, коду — це величезний головняк. Клієнти не завжди згодні з оновленнями і подібними рішеннями — в такі часи починається ще й юридична тяжба по умовам надання послуг які прописані в договорах. Компанія починає наймати на роботу додактових девів, менеджерів, аналітиків тощо — для планування потенційной міграції на сучасний стек, що в тренді. Я просто через таке проходив і розумію на скільки це пекельно, складно і тут питання не в тому — що подобається CEO або CTO, а саме бізнес питання і не в одній компанії. Переписаний проект з верогідністю 99.9% буде працювати з новими багами як в самому проекті, так і в інфраструктурі. Тому якщо проект працює і у проекта багато клієнтів — простіше його перевести на KTLO і якщо потрібно доплатити Oracle за підтримку Java і тут копійки в реалності, а з AWS домовитись про свої потреби. В такому режимі можна не витрачати багато грошей, так простіше і довше буде жити.

Нащо переписувати? Тому що Opex. Станьте на бік бізнеса з калькулятором і порахуйте. Розумієте про що я?

Нащо переписувати?

я може знову втрачаю суть розмови, але як я розумію оцей посил

Дійсно, в компанії бракує або ресурсів чи клепок, щоб це переписати на новий стек.

означає саме переписувати, а тут ви питаєте нащо переписувати...

Тому що Opex.

та ні, то просто менеджменту закортіло попиляти черговий річний бюджет і це запропонували під соусом суачсності, економії, тренодвості тощо.

Розумієте про що я?

Чесно — ні, бо є моментами протиріччя у вас самому собі, а також якесь суб’єктивне бачення пов’язане на тренди. Як я вже писав — у мене інший підхід і бачення, так само як і визнавати ти чі інші технології показником рівня компанії, менеджменту тощо.

проект, який заробляє 3 мільярди доларів на рік, має 2 тис робітників, а її софтом користуються половина компаній в Top500

Але ж

Це старий підхід та анахронізм. Дійсно, в компанії бракує або ресурсів чи клепок

Як кажуть, if you’re so smart, why aren’t you rich?

Я так розумію, по суті питання немає що сказати. Тому перехід на особистості.

Тому перехід на особистості.

Так здається перехід вже був, з клепкою. Я лише наслідую модель.

По суті — за кожним legacy «працює — не чіпай» стоять гроші. Це відповідь на

Назвіть будь-ласка конкретні об’єктивні причини того, що компанія зависає на старому софті.

Я дивлюся на ситуацію з точки зору девелопера та майбутнього проекта. Це сайт для девелоперів, чи не так?

з точки зору девелопера

Вона зазвичай нікого не цікавить. Sad but true.

та майбутнього проекта

«Жахливе» legacy якось проіснувало свої 10-15-20 років до цього, і, скоріше за все, проіснує ще стільки ж. А от модномолодьожний фреймворк, цілком можливо, за цей час отримає 20 нових major версій і буде мати повну відсутність backward compatibility.

Якщо що — я цілком за рефакторінг, новітні технології і таке інше — але це повинно бути засобом, а не ціллю. Як тільки це стає ціллю — ініціатора потрібно слати наxуй.

Вона зазвичай нікого не цікавить. Sad but true.

При виборі проекту це має турбувати самого девелопера. Я саме про це і написав в самому першому повідомленні, коли зазначив, які проекти для мене є нецікавими. Можливо, хтось у захваті від легасі? Хто зна’.

«Жахливе» legacy якось проіснувало свої 10-15-20 років до цього, і, скоріше за все, проіснує ще стільки ж.

При такому підході Україна скоро зможе забути про нормальні проекти. Тому що спеціалісти, які міркують саме такою логікою не ростуть і, відповідно, не можуть рухати прогрес.

Можливо, хтось у захваті від легасі?

Не повірите — я у захваті. Для мене legacy — це щось дійсно корисне, те, що мало змогу проіснувати довго, і мало змогу приносити користь. Користь програмного продукту не у його технологіях, а у тому, які проблеми він вирішує — і legacy це те, що має доведену можливість вирішувати проблеми, замість того, щоб створювати нові.

При такому підході Україна скоро зможе забути про нормальні проекти.

Взагалі не зрозумів, до чого тут Україна.

Для мене legacy — це щось дійсно корисне, те,

Кожному своє. А можливо, Ви просто боїтеся challenges? Знаєте, люди бояться нового.

Взагалі не зрозумів, до чого тут Україна.

Ну дійсно, до чого тут Україна до українців на українському ресурсі. Дивні речі.

А можливо, Ви просто боїтеся challenges?

Ба більше — я ще й із зони комфорту виходити не бажаю.

Ну дійсно, до чого тут Україна до українців на українському ресурсі. Дивні речі.

І як, над багатьма українськими проектами довелося у GL працювати?

Можете? :-)

доречі додам ще один прикольний прикол, відноситься до трендів. — це коли ліві ліберали роблять PR в Python репу з перейменування master-slave.

Слідування трендам це невід’ємна частина ІТ-життя. Я не завжди розділяю свою думку з трендами (фаза «заперечення»). Але з часом або розумієш чому так, або просто приймаєш зціпивши зуби. Се-ля-ві.

Слідування трендам це невід’ємна частина ІТ-життя.

кожному своє. Я себе відношу до тієї категорії технарів — коли рішення має бути не трендовим, а вже відпрацьовнним, відстоявшимся, мінімально багів, максимальна кількість людей — які можуть з цим працювати. Мінімальні бізнес ризики на майбутнє з максимальними EOL періодами для софта. Тому що у 2024 роца те, що зараз є трендовим і ви це юзаєте у 2035 може статись так що буде як ви вище писали про незрілі компанії, клепку, менеджмент тощо...

Це дуже глибока теорія.

В нашій реальності ситуація трохи інакша. Графік к-сті питань на stack overflow показує рівень зацікавленості продуктом. medium.com/...​f-to-ansible-da97051f2ae6
Відносно ruby<>chef досвід максимально негативний. 17 темплейт файлів сумарно 50кб оброблялись 8 хв (банальна заміна шаблонів). Ansible — 2 сек.

8 хвилин на 17 темплейтів? Це щось не те робите. Я запускав Chef з пайплайнів для точно таких операцій — там лічені секунди, не хвилини.

Йдеш на прямий контракт — отримуєш 12

Ціни в США дуже попадали. Не думаю, що це актуальне на сьогодні. Хіба що для дуже невеликого відсотка інженерів.

Ну так можна піти та подивитися, що 130-150к то середня ціна зараз на ремоут

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

як з України знайти прямий контракт? якщо всі хочуть іншу локацію і документи.

1. Розвивати власний бренд
2. Мати знайомих людей у C-level
3. Шукати вакансії без привʼязки до локації.
p.s. з оплатою все стандартно, або wire transfer або Payoneer

Згідно із зарплатним віджетом DOU, підвищення рівня англійської з Upper-Intermediate до Advanced збільшує зарплату DevOps-інженера з $6000 до $6833, або $9996 на рік.

9 996 на рік — не так вже й багато ))

Трохи не так треба рахувати: приріст становить 13.88% лише за вищій рівень англійської. Це дуже суттєво насправді.

$9996 це річна ЗП чи місячна? В статті написано що це на рік! Який Senior DevOps на таку річну ЗП?

9996 — це річна надбавка за Advanced English.

6833 — 6000 = 833
833×12 = 9996

тоді в тексті не завадило б додати «на» —

з $6000 до $6833, або на $9996 на рік.

Бо й справді виглядає як зарплата за рік

Так, ви праві, я пропустив слово «на».

дякую за цікавий матеріал

Уточню щодо CI/CD. 64% вакансій містять вимогу знати CI/CD, часто не уточнюючи конкретну технологію. Тому я включив CI/CD як навичку окремим пунктом в групу «CI/CD».

Якщо не брати до уваги кількість років «відсидки», маю враження, що спектр вимог по технологіях такий самий і до мідлів, і до джуніорів.

Саме так. Я теж звернув увагу на те, що вакансії Senior за стеком технологій схожі на вакансії Middle, тому і звернувся до відомих DevOps-фахівців із запитанням про відмінності між спеціалістом рівня Middle та Senior.

Від Senior очікують видатних теоретичних знань по всіх напрямках, сутичних з DevOps. Це: сек’юріті за рівні infra та application, програмування на Python на рівні середнього розробника, хмарна архітектура на рівні архітекта-початковця, який «з голови» може накидати архітектуру чого-небуть та змінювати її з додаванням нових умов. Також питають різні терміни, які зазвичай пропускаєш повз вуха і не вертаєш на це уваги — бо на проекті люди використовують більш прості поняття, наприклад, я ніколи не чув, щоб інженери використовувати абревіатуру MTTA — це просто Acknowledge time і завжди ним буде. Тобто, Senior має бути дуже начитаним та обізнаним в теорії на 100%, і в цьому місці я запитую себе — а яка ж тоді різниця між Senior та Architect? Бо Senior ще вміє працювати руками, чого у Architect не завжди побачиш.

Дякую — було цікаво дізнатися що і як)

Підписатись на коментарі