ДевОпс Інженер 🇺🇦
08.05.202518:26
DOU DAY + The Reality of Tech Interviews in 2025
Вітання!
Вибрав для вас декілька доповідей з DOU DAY, на які варто звернути увагу:
- Jujutsu, GitButler: make git fun again - Всеволод Поляков
- Великий вихід з гіперскейлерів. Стратегія міграції інфраструктур - Володимир Цап
- Операційна система: що насправді відбувається, коли ви запускаєте вашу програму - Віктор Турський
- TBA - Ігор Дворецький
- Розвиток і впровадження AI агентів - Денис Попов
Також як і домовлялись, мікро-огляд статті The Reality of Tech Interviews in 2025:
https://newsletter.pragmaticengineer.com/p/the-reality-of-tech-interviews
➡️ New reality of tech hiring
2021-2021 ми бачили пік ринку, потім падіння в 2023, і зараз +40% порівняно з низом ринку. Тобто, порівнюємо не з перегрітим ринком, а з низом ринку - і таким чином покращуємо свій mental health.
➡️ Analyzing the tech hiring market
2023 163K вакансій, зараз - 230К. Перспективні напрямки: AI Infrastructure, Machine Learning Operations. В стандартних доменах, типу бек, фронт, мобайл - складно. Сіньйори в шоколаді - все так само отримують офери, особливо - якщо вакансія і ваш досвід матчиться. Джунам - важко як ніколи. Більше етапів інтервью. Менеджери - теж важко.
➡️ Interview process changes
Стандартно DSA, але якість очікують вищу, і складність - більшу. Системний Дизайн - знову очікують більше. Також більше шансів отримати промоушн в мідла, якщо прийшли на вакансію сіньйора. Тім матчінг (aka team lunch) - ще один неформальний раунд співбесіди.
➡️ Interview format differences at startups and Big Tech
Тут все очевидно - FAANG - DSA, компанії менше - щось схоже до того, чим будете займатись в компанії.
➡️ Preparation strategies by experience level
Джуни: 80% DSA, 20% behave
Мідли: 50% DSA, 25% сисдиз, 25% behave
Сіньйори: 50% сисдиз, 20% DSA, 30% behave
Стафи: 90% біхейв, бо в них DSA і сисдиз і так від зубів відскакує
Executive Summary:
- 2020 - 2021: golden rush, "please take our money"
- 2025: "prove you're worth it"
- Трохи більше часу на пошук компанії, але ринок +- норм.
- Очікування від кандидатів ростуть, і будуть продовжувати рости.
Виглядає оптимістичніше, ніж попередній пост на цю тему 🙂 Рекомендую прочитати статтю повністю. І продовжуємо вчитись проходити інтерв'ю - це окремий скіл, який покращується з досвідом і роботою над помилками. Всім успіхів!
Вітання!
Вибрав для вас декілька доповідей з DOU DAY, на які варто звернути увагу:
- Jujutsu, GitButler: make git fun again - Всеволод Поляков
- Великий вихід з гіперскейлерів. Стратегія міграції інфраструктур - Володимир Цап
- Операційна система: що насправді відбувається, коли ви запускаєте вашу програму - Віктор Турський
- TBA - Ігор Дворецький
- Розвиток і впровадження AI агентів - Денис Попов
Також як і домовлялись, мікро-огляд статті The Reality of Tech Interviews in 2025:
https://newsletter.pragmaticengineer.com/p/the-reality-of-tech-interviews
➡️ New reality of tech hiring
2021-2021 ми бачили пік ринку, потім падіння в 2023, і зараз +40% порівняно з низом ринку. Тобто, порівнюємо не з перегрітим ринком, а з низом ринку - і таким чином покращуємо свій mental health.
➡️ Analyzing the tech hiring market
2023 163K вакансій, зараз - 230К. Перспективні напрямки: AI Infrastructure, Machine Learning Operations. В стандартних доменах, типу бек, фронт, мобайл - складно. Сіньйори в шоколаді - все так само отримують офери, особливо - якщо вакансія і ваш досвід матчиться. Джунам - важко як ніколи. Більше етапів інтервью. Менеджери - теж важко.
➡️ Interview process changes
Стандартно DSA, але якість очікують вищу, і складність - більшу. Системний Дизайн - знову очікують більше. Також більше шансів отримати промоушн в мідла, якщо прийшли на вакансію сіньйора. Тім матчінг (aka team lunch) - ще один неформальний раунд співбесіди.
➡️ Interview format differences at startups and Big Tech
Тут все очевидно - FAANG - DSA, компанії менше - щось схоже до того, чим будете займатись в компанії.
➡️ Preparation strategies by experience level
Джуни: 80% DSA, 20% behave
Мідли: 50% DSA, 25% сисдиз, 25% behave
Сіньйори: 50% сисдиз, 20% DSA, 30% behave
Стафи: 90% біхейв, бо в них DSA і сисдиз і так від зубів відскакує
Executive Summary:
- 2020 - 2021: golden rush, "please take our money"
- 2025: "prove you're worth it"
- Трохи більше часу на пошук компанії, але ринок +- норм.
- Очікування від кандидатів ростуть, і будуть продовжувати рости.
Виглядає оптимістичніше, ніж попередній пост на цю тему 🙂 Рекомендую прочитати статтю повністю. І продовжуємо вчитись проходити інтерв'ю - це окремий скіл, який покращується з досвідом і роботою над помилками. Всім успіхів!
27.03.202510:09
Thousands of exposed GitHub repositories, now private, can still be accessed through Copilot
Хто буде на мітапі, запитайте будь ласка, чому Github Copilot тренують на приватних репозиторіях 🤦♂️
Хто буде на мітапі, запитайте будь ласка, чому Github Copilot тренують на приватних репозиторіях 🤦♂️
16.09.202417:39
Deprecation plan
Поділюсь сьогодні з вами подією, яка пройшла дуже тихо в середині літа, але для декого стала досить неприємною. 31-го липня, у своєму <strike>твіттері</strike> X, Jeff Barr повідомив ось таку новину на широкий загал:
Тут варто сказати, що цей AWS CodeCommit в цілому і був не дуже хорошим рішенням, тому дивного тут нічого не було. Проблема полягає в тому, що Jeff Barr зробив це до офіційної комунікації AWS, і клієнти цього чудового сервісу почали у своїх компаніях, у лічках, пересилати посилання на твіттер (а він, повірте, використовується, особливо в тих випадках, коли регулятор забороняє будь-який third-party сервіс поза межами AWS).
Чи це нормально? Звісно, ні, бо мали б пересилати посилання на блог або імейл, в якому було б сказано: “сорі, так і так — ось вам купа часу і промо на Х грошей, ми цю штуку прибираємо зі свого портфоліо. Хто користується — користуйтеся, але нові репозиторії вже не створюйте, будь ласка”.
Далі за хронологією полетіло багато чого по трубам, і AWS вирішив додати в статтю, яка називалась “How to migrate your AWS CodeCommit repository to another Git provider” і в якій спочатку нічого не було про “we made the decision”, ось такий хідер:
Ну, і в принципі на цьому вся комунікація від AWS і закінчилася.
Ось ви це прочитали, чи залишились у вас питання? Наприклад: скільки ще він буде працювати для існуючих клієнтів — місяць, рік чи ще 5 років? Чи можна додатково заплатити і розблокувати можливість створення репозів? Який альтернативний solution є всередині самого AWS? А що з цим прекрасним CI/CD тулсетом — він теж депрекейтиться чи він strong enough? (CodeBuild / CodePipeline / CodeStart і т.д.)
Як бачите, таким чином комунікувати неефективно, і комунікувати не рекомендується, якщо ви хочете, щоб клієнти були задоволені. Тому, шановні DevOps / SRE / Infra / Platform Engineers, ви, як представники сервісів, тулів, платформ, які працюють неефективно, не робіть так, як це було зроблено з AWS CodeCommit.
Трохи подумавши, це можна було б пофіксити ось так:
1. За рік до події, зловивши тренд, розіслати кастомерам survey: “ми думаємо, що сервіс не вдався, і ви теж даєте нам такий фідбек. Ми хотіли б його задепрекейтити. Що ви думаєте?”
2. Цей фідбек ніхто не бачить, тож тут можемо діяти як завгодно. Наприклад, комунікуємо за півроку: “ми отримали результати опитувань, які свідчать, що цей сервіс не вдався, і ми не хочемо його розвивати. Починаючи з dd/mm/yyyy, він переходить на deprecation path, але до цієї дати він працюватиме як завжди. Це стосується виключно цього сервісу. Ось comprehensive guide, як з нього мігрувати”.
3. Фінальний нотіф: “Як ми повідомляли раніше, сьогодні dd/mm/yyyy ми припиняємо можливість створювати нові репозиторії. Так як сервіс на deprecation path, ми займаємось тільки його безпекою, і до кінця yyyy року ви змушені з нього зʼїхати, бо буде повний sunset. Команда AWS доступна для ваших запитів.”
Використовуйте цей патерн для депрекейшну старих, нових, потрібних і непотрібних сервісів, які є у ваших системах.
Ключ до ефективності — ранній нотіф клієнтам (офіційна, формальна комунікація). Для збереження відносин — comprehensive guide. І ще бажано мігронути клієнта на нову систему, можливо навіть смузлі. Тоді буде win-win.
Пропрацьовуйте ваші депрекейшн плани "in upfront". Будьте здорові.
Поділюсь сьогодні з вами подією, яка пройшла дуже тихо в середині літа, але для декого стала досить неприємною. 31-го липня, у своєму <strike>твіттері</strike> X, Jeff Barr повідомив ось таку новину на широкий загал:
After giving it a lot of thought, we made the decision to discontinue new access to a small number of services, including AWS CodeCommit.
While we are no longer onboarding new customers to these services, there are no plans to change the features or experience you get today, including keeping them secure and reliable.
Тут варто сказати, що цей AWS CodeCommit в цілому і був не дуже хорошим рішенням, тому дивного тут нічого не було. Проблема полягає в тому, що Jeff Barr зробив це до офіційної комунікації AWS, і клієнти цього чудового сервісу почали у своїх компаніях, у лічках, пересилати посилання на твіттер (а він, повірте, використовується, особливо в тих випадках, коли регулятор забороняє будь-який third-party сервіс поза межами AWS).
Чи це нормально? Звісно, ні, бо мали б пересилати посилання на блог або імейл, в якому було б сказано: “сорі, так і так — ось вам купа часу і промо на Х грошей, ми цю штуку прибираємо зі свого портфоліо. Хто користується — користуйтеся, але нові репозиторії вже не створюйте, будь ласка”.
Далі за хронологією полетіло багато чого по трубам, і AWS вирішив додати в статтю, яка називалась “How to migrate your AWS CodeCommit repository to another Git provider” і в якій спочатку нічого не було про “we made the decision”, ось такий хідер:
After careful consideration, we have made the decision to close new customer access to AWS CodeCommit, effective July 25, 2024. AWS CodeCommit existing customers can continue to use the service as normal. AWS continues to invest in security, availability, and performance improvements for AWS CodeCommit, but we do not plan to introduce new features.
Ну, і в принципі на цьому вся комунікація від AWS і закінчилася.
Ось ви це прочитали, чи залишились у вас питання? Наприклад: скільки ще він буде працювати для існуючих клієнтів — місяць, рік чи ще 5 років? Чи можна додатково заплатити і розблокувати можливість створення репозів? Який альтернативний solution є всередині самого AWS? А що з цим прекрасним CI/CD тулсетом — він теж депрекейтиться чи він strong enough? (CodeBuild / CodePipeline / CodeStart і т.д.)
Як бачите, таким чином комунікувати неефективно, і комунікувати не рекомендується, якщо ви хочете, щоб клієнти були задоволені. Тому, шановні DevOps / SRE / Infra / Platform Engineers, ви, як представники сервісів, тулів, платформ, які працюють неефективно, не робіть так, як це було зроблено з AWS CodeCommit.
Трохи подумавши, це можна було б пофіксити ось так:
1. За рік до події, зловивши тренд, розіслати кастомерам survey: “ми думаємо, що сервіс не вдався, і ви теж даєте нам такий фідбек. Ми хотіли б його задепрекейтити. Що ви думаєте?”
2. Цей фідбек ніхто не бачить, тож тут можемо діяти як завгодно. Наприклад, комунікуємо за півроку: “ми отримали результати опитувань, які свідчать, що цей сервіс не вдався, і ми не хочемо його розвивати. Починаючи з dd/mm/yyyy, він переходить на deprecation path, але до цієї дати він працюватиме як завжди. Це стосується виключно цього сервісу. Ось comprehensive guide, як з нього мігрувати”.
3. Фінальний нотіф: “Як ми повідомляли раніше, сьогодні dd/mm/yyyy ми припиняємо можливість створювати нові репозиторії. Так як сервіс на deprecation path, ми займаємось тільки його безпекою, і до кінця yyyy року ви змушені з нього зʼїхати, бо буде повний sunset. Команда AWS доступна для ваших запитів.”
Використовуйте цей патерн для депрекейшну старих, нових, потрібних і непотрібних сервісів, які є у ваших системах.
Ключ до ефективності — ранній нотіф клієнтам (офіційна, формальна комунікація). Для збереження відносин — comprehensive guide. І ще бажано мігронути клієнта на нову систему, можливо навіть смузлі. Тоді буде win-win.
Пропрацьовуйте ваші депрекейшн плани "in upfront". Будьте здорові.
05.06.202417:55
Зарплатне опитування і мітап у Львові
Добрий вечір, пройдіть свіже зарплатне опитування і / або відвідайте DevOps мітап у Львові. Якщо ви це зробите, графіки будуть виглядати краще, і пропозиції будуть приємніше.
Прохання сабмітити тільки крепкі ЗП-хи (ніт) 💰
Ну а на мітап просто сходіть.
Також зараз відбувається DevOpsDays Ukraine, і вчора в кімнаті "Disaster Recovery" ми обговорили цей топік. Короткі нотатки:
1. Створіть бекап план (так званий Backup Strategy)
2. Зберігайте бекапи в іншому регіоні, краще - в іншому аккаунті, ще краще - в іншому клауді.
3. Завжди тестуйте бекапи.
4. Дуже обережно поводьтесь з Базами Даних.
5. Не приховуйте, якщо ви щось дропнули 🌚
6. Репліка БД не є достатнім підходом, все ж треба бекапи.
7. Репліка БД, яка відстає на X годин - це добре, але краще - репліка в ріалтаймі + транзакшн лог.
8. Додайте умову в автоматизацію, яка видаляє інфру, щоб вона не потерла всі ресурси. Краще exit 1 :)
[ нотатки є думками людей які долучились до обговорення, і можуть не збігатись з моєю / вашою думкою ]
Напишіть комент, якщо у вас є Lessons Learned по Disaster Recovery 🤝
Добрий вечір, пройдіть свіже зарплатне опитування і / або відвідайте DevOps мітап у Львові. Якщо ви це зробите, графіки будуть виглядати краще, і пропозиції будуть приємніше.
Прохання сабмітити тільки крепкі ЗП-хи (ніт) 💰
Ну а на мітап просто сходіть.
Також зараз відбувається DevOpsDays Ukraine, і вчора в кімнаті "Disaster Recovery" ми обговорили цей топік. Короткі нотатки:
1. Створіть бекап план (так званий Backup Strategy)
2. Зберігайте бекапи в іншому регіоні, краще - в іншому аккаунті, ще краще - в іншому клауді.
3. Завжди тестуйте бекапи.
4. Дуже обережно поводьтесь з Базами Даних.
5. Не приховуйте, якщо ви щось дропнули 🌚
6. Репліка БД не є достатнім підходом, все ж треба бекапи.
7. Репліка БД, яка відстає на X годин - це добре, але краще - репліка в ріалтаймі + транзакшн лог.
8. Додайте умову в автоматизацію, яка видаляє інфру, щоб вона не потерла всі ресурси. Краще exit 1 :)
[ нотатки є думками людей які долучились до обговорення, і можуть не збігатись з моєю / вашою думкою ]
Напишіть комент, якщо у вас є Lessons Learned по Disaster Recovery 🤝
06.05.202517:46
Дякую за те, що прочитали офіційну специфікацію GCP і проголосували. Я зупинив опитування.
По результатам також видно конфуз:
- 49% Server Side Request Latency
- 12% TTFB
- 12% RTT
- 28% Total Response Time
Поясню причину unexpected behaviour:
- по опису метрики, яку я закинув з офіційної доки - очевидно це Server Side Request Latency
- тут пишуть що це Total Response Time, а в коментах - що RTT
- тут пишуть що це Total Response Time
- в коменті до опитування пишуть, що взагалі НЕМАЄ правильної відповіді
- ще є купа тредів і форумів де люди конфьюзяться
В моєму випадку я помітив цю штуку на slow clients на пет-проджекті, і грішив на бекенд. Далі зробив profiling + tracing, також k6 перформанс тести і зрозумів що в мене немає жодних питань до бекенду. Але є дуже багато питань до метрики 😆
З моєї сторони, значення яке туди потрапляє виглядає як Total Response Time, і пруфається через curl --limit-rate
➡️ Тепер я попрошу GCP сертифікованих інженерів, або тих хто точно знає зайти в коменти сюди, і дати відповідь що є дійсно таке HttpRequest.latency в логах GCP до балансера
Сподіваюсь розберемось разом, на тижні ще закину чудову статтю з Pragmatic Engineer про стан ІТ в 2025, де є +40% зросту від дна ринку (як в опозицію до поста, який писав вище). Успіхів!
По результатам також видно конфуз:
- 49% Server Side Request Latency
- 12% TTFB
- 12% RTT
- 28% Total Response Time
Поясню причину unexpected behaviour:
- по опису метрики, яку я закинув з офіційної доки - очевидно це Server Side Request Latency
- тут пишуть що це Total Response Time, а в коментах - що RTT
- тут пишуть що це Total Response Time
- в коменті до опитування пишуть, що взагалі НЕМАЄ правильної відповіді
- ще є купа тредів і форумів де люди конфьюзяться
В моєму випадку я помітив цю штуку на slow clients на пет-проджекті, і грішив на бекенд. Далі зробив profiling + tracing, також k6 перформанс тести і зрозумів що в мене немає жодних питань до бекенду. Але є дуже багато питань до метрики 😆
З моєї сторони, значення яке туди потрапляє виглядає як Total Response Time, і пруфається через curl --limit-rate
➡️ Тепер я попрошу GCP сертифікованих інженерів, або тих хто точно знає зайти в коменти сюди, і дати відповідь що є дійсно таке HttpRequest.latency в логах GCP до балансера
Сподіваюсь розберемось разом, на тижні ще закину чудову статтю з Pragmatic Engineer про стан ІТ в 2025, де є +40% зросту від дна ринку (як в опозицію до поста, який писав вище). Успіхів!
27.03.202510:05
Приходьте на івент про GitHub Copilot — розберемо, як він спрощує життя.
Генерує CI/CD конфіги, Dockerfile і Docker Compose, пише скрипти для автоматизації, швидко фіксить баги і доповнює код на льоту. Це апгрейд для DevOps інженерів, розробників і тих, хто хоче працювати швидше!
Долучайтесь до онлайн мітапу Cloud Builders 10 квітня — на вас чекають тренди від GitHub, демо та реальні кейси від SoftwareOne та DevRain.
У програмі:
*AI в розробці: нові фічі GitHub Copilot
*Безпека коду: як GitHub Advanced Security та AI працюють на тебе
*End-to-End проєкти з GitHub Copilot
А ще разом з фондом Angry Corgi збираємо на 3 планшети для сил ППО. Чекаємо на твої 20 грн та реєстрацію. До зустрічі!
📍Деталі та реєстрація: https://cloud-builders.org/github-copilot
Генерує CI/CD конфіги, Dockerfile і Docker Compose, пише скрипти для автоматизації, швидко фіксить баги і доповнює код на льоту. Це апгрейд для DevOps інженерів, розробників і тих, хто хоче працювати швидше!
Долучайтесь до онлайн мітапу Cloud Builders 10 квітня — на вас чекають тренди від GitHub, демо та реальні кейси від SoftwareOne та DevRain.
У програмі:
*AI в розробці: нові фічі GitHub Copilot
*Безпека коду: як GitHub Advanced Security та AI працюють на тебе
*End-to-End проєкти з GitHub Copilot
А ще разом з фондом Angry Corgi збираємо на 3 планшети для сил ППО. Чекаємо на твої 20 грн та реєстрацію. До зустрічі!
📍Деталі та реєстрація: https://cloud-builders.org/github-copilot
06.09.202416:30
Офлайн DOU DevOps meetup. Київ
Доброго вечора пані і панове,
Знову понабирають невідомого кого на мітапи, ми тут тільки Вову Цапа знаємо 😁
Якщо серйозно, то як я зрозумів, буде тільки 1 спікер і панельна дискусія після доповіді. Хто може прийти - приходьте, подейкують що це можливо і останній подібний офлайновий DevOps-мітап від DOU.
На пост не сваріться, бо мене попросила запостити @dzzzvinka з DOU, а в них є розділ "Зарплати", за допомогою цієї аналітики ми собі багато років підвищували винагороду :)) зазвичай способом "ну там не актуальне, там тільки джуни відповідають"
Реєстрація, як прийнято, зі збором імейлів, телеграмів і лінкедінів (там далі фіолетова кнопка):
https://dou.ua/goto/Zp45
Доброго вечора пані і панове,
Знову понабирають невідомого кого на мітапи, ми тут тільки Вову Цапа знаємо 😁
Якщо серйозно, то як я зрозумів, буде тільки 1 спікер і панельна дискусія після доповіді. Хто може прийти - приходьте, подейкують що це можливо і останній подібний офлайновий DevOps-мітап від DOU.
На пост не сваріться, бо мене попросила запостити @dzzzvinka з DOU, а в них є розділ "Зарплати", за допомогою цієї аналітики ми собі багато років підвищували винагороду :)) зазвичай способом "ну там не актуальне, там тільки джуни відповідають"
Реєстрація, як прийнято, зі збором імейлів, телеграмів і лінкедінів (там далі фіолетова кнопка):
https://dou.ua/goto/Zp45
03.06.202408:17
DevOpsDays: Let's talk security
Шановні, завтра конференція. Не пропустіть і зареєструйтесь:
https://devopsdays.com.ua/
Шановні, завтра конференція. Не пропустіть і зареєструйтесь:
https://devopsdays.com.ua/
06.05.202516:35
GCP HttpRequest.latency
Доброго вечору, сьогодні історія про GCP, їх логування, специфікацію логів і unexpected behaviour.
Референс:
https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#HttpRequest
latency string (Duration format)
The request processing latency on the server, from the time the request was received until the response was sent. For WebSocket connections, this field refers to the entire time duration of the connection.
A duration in seconds with up to nine fractional digits, ending with 's'. Example: "3.5s".
Більше контексту:
GCP це логує на балансерах, функціях і інших компонентах. Прочитайте це будь ласка, і я прямо зараз фолоу-апну питанням.
Доброго вечору, сьогодні історія про GCP, їх логування, специфікацію логів і unexpected behaviour.
Референс:
https://cloud.google.com/logging/docs/reference/v2/rest/v2/LogEntry#HttpRequest
latency string (Duration format)
The request processing latency on the server, from the time the request was received until the response was sent. For WebSocket connections, this field refers to the entire time duration of the connection.
A duration in seconds with up to nine fractional digits, ending with 's'. Example: "3.5s".
Більше контексту:
GCP це логує на балансерах, функціях і інших компонентах. Прочитайте це будь ласка, і я прямо зараз фолоу-апну питанням.
15.02.202510:47
Раді представити вам DevOps fwdays'25 — конференція від Fwdays, присвячена DevOps практикам та інструментам 🤩
Серед тем конференції: DevOps Approach, DevOps Technologies, DevOps Tools, DevOps World Experience. Доповіді будуть англійською та українською мовами.
🗓 Дата: 22 лютого
🗣 Формат: офлайн (у Києві) та онлайн
🎙 Мови доповідей: українська та англійська
Спікери та їх доповіді:
📍 Володимир Цап – керує інженерною та продуктовою командами в якості CTO в SHALB та cluster.dev. Виступить із доповіддю “Перетворюємо Kubernetes на повноцінний приватний Cloud”.
📍Денис Васільєв –Senior SRE, NIQ у GfK Сompany. Сертифікований Kubernetes Administrator та автор курсу Kubernetes DIY.
Під час доповіді “Kubernetes оператори. Як ми мігрували Release Management на контролери” розповість історію еволюції Promotion (Release) системи від простих Kubernetes API REST колів до інформерів та контролерів на власному досвіді.
📍Микола Маржан – Director of Engineering у Canonical / Ubuntu.
Презентує доповідь “Бази даних у Kubernetes: бути чи не бути”.
Використайте промокод 2FDFF90CAB та отримайте знижку 10%, деталі за посиланням 👉 https://bit.ly/4gtzxoD
Хочете поринути у світ DevOps? Дізнатись більше про DevOps практики та інструменти? Приєднуйтесь!
Серед тем конференції: DevOps Approach, DevOps Technologies, DevOps Tools, DevOps World Experience. Доповіді будуть англійською та українською мовами.
🗓 Дата: 22 лютого
🗣 Формат: офлайн (у Києві) та онлайн
🎙 Мови доповідей: українська та англійська
Спікери та їх доповіді:
📍 Володимир Цап – керує інженерною та продуктовою командами в якості CTO в SHALB та cluster.dev. Виступить із доповіддю “Перетворюємо Kubernetes на повноцінний приватний Cloud”.
📍Денис Васільєв –Senior SRE, NIQ у GfK Сompany. Сертифікований Kubernetes Administrator та автор курсу Kubernetes DIY.
Під час доповіді “Kubernetes оператори. Як ми мігрували Release Management на контролери” розповість історію еволюції Promotion (Release) системи від простих Kubernetes API REST колів до інформерів та контролерів на власному досвіді.
📍Микола Маржан – Director of Engineering у Canonical / Ubuntu.
Презентує доповідь “Бази даних у Kubernetes: бути чи не бути”.
Використайте промокод 2FDFF90CAB та отримайте знижку 10%, деталі за посиланням 👉 https://bit.ly/4gtzxoD
Хочете поринути у світ DevOps? Дізнатись більше про DevOps практики та інструменти? Приєднуйтесь!
Қайта жіберілді:
Українська девопсарня
29.08.202415:19
полайкайте PR від якого русня горить
https://github.com/opentofu/registry/pull/817
https://github.com/opentofu/registry/pull/817
22.04.202520:15
Books & Growth
Доброго вечора, шановне панство!
Нагадаю, що ми всі успішно прочитали наступні книги за останні N років:
- Continuous Delivery: Reliable Software Releases
- Site Reliability Engineering
- The Site Reliability Workbook
- Building Secure and Reliable Systems
Частково хтось міг також прочитати:
- The Phoenix Project
- Designing Data-Intensive Applications
Крім того, ми охопили чимало матеріалів про Infrastructure as Code (на початку), Docker (дуже давно), Kubernetes (просто давно), а також, можливо, хтось із вас, хто пішов у лідершип, знайшов корисними такі книги:
- Software Engineering at Google (рекомендую)
- The Staff Engineer’s Path (теж дуже якісна)
Ми зробили величезну роботу — покрили клауди, процеси, моніторинг, логування, фінопс, reliability, скейлінг, сек’юріті, self-healing і багато іншого. Але, як бачите, з моменту виходу першої книги минуло вже 15 років. Попри еволюцію, може бути (?) настав час або для pivot, або для generalization.
Поділюсь кількома думками щодо Generalization Path:
- Гіпотеза: передусім ви — Software Engineer, і вже потім фокусуєтесь на DevOps / Infrastructure / Platforms
- Nobody will hire you if you don't have coding skills
- Це будуть перевіряти через live coding на співбесідах (у тому числі - літкод)
- Часу лишилося не так уже й багато, але роки 2-3-x має бути
- Поговорити про апдейт воркер-ноди чи terraform state вже не вийде :) Точніше, вийде — але лише на одному з 5 етапів інтерв’ю.
Альтернативний Pivot Path
Якщо ви вже працюєте в цьому напрямку - дуже круто!
- ML Operations та все, що з цим пов’язано - у цих вакансіях очевидно всі раунди з літкодом і вишматом
Наприклад:
- Software Engineer, Infrastructure - OpenAI (200к-400k мінус податки плюс еквіті)
- Systems Engineer, Infrastructure - Anthropic (те ж саме)
Можливо, це і звучить як булшит, або читаючи ви не згодні десь всередині, але я хотів цим із вами поділитися. Це стосується тільки топ ЗП-шок, я не думаю що середній DevOps Engineer з медіаною на доу помітить зміни на ринку до наступного gartner hype cycle. Скоріше за все - ні. Міг би ще додати графік кількості відкритих вакансій на глобальному ринку, але передумав. Україна дає чудовий сервіс за вигідну ціну (вітання ФОПам!), тож у нас є час адаптуватися під новий стан речей.
Що робити - Generalization Path:
Додаємо активну розробку скілів:
- CSosvita: алгоритми на практиці (старт 1 травня), performance engineering (старт 29 квітня) — лінки додам у коментарях. Це не реклама - мені за це не платять. Просто ділюся якісним продуктом.
- Лаби / MVPs / бібліотеки — definition of done: ви можете зайти в позицію Middle Software Developer по скілам, (ваша основна експертиза зберігається - інфра-фокус). Це буде ефективно. Тут виходить T-shaped, якщо вас перевіряють як дева - чудово, ви можете, і ще є глибина знань в інфрі. Якщо перевіряють як інфра / platform / sre - чудово, ви ще й бек напишете. Одні плюси!
Що робити - Pivot Path:
- Продовжуємо читати - Reliable Machine Learning (гуглиться через filetype: pdf)
- Проходимо всі лаби на Kaggle
- Згадуємо вишмат
- Купуємо nvidia за декілька К і ганяємо лабки (будуємо end-to-end пайплайн)
Доповідь закінчив 🫡
Також додам, що цю думку я частково почув від Севи Полякова (не прямо цю, але в тому ж напрямку), тож ділюся і своїм баченням, що спостерігаю навколо. Буду радий почути розширену доповідь на DOU Day (у нас присутні шанси послухати цілу доповідь - fingers crossed!)
Усім продуктивного тижня, продовжуємо розвиватися, впевнено дивимось уперед - і запрошую в коментарі: напишіть, чи це булшит, чи все ж має сенс. Буду радий фідбеку! Можливо я даремно всіх напаяв :))
UPD1: на початку ковіду я вже напаяв всіх тут в каналі, і вийшло абсолютно не так 😆 не скріньте цей твіт
Доброго вечора, шановне панство!
Нагадаю, що ми всі успішно прочитали наступні книги за останні N років:
- Continuous Delivery: Reliable Software Releases
- Site Reliability Engineering
- The Site Reliability Workbook
- Building Secure and Reliable Systems
Частково хтось міг також прочитати:
- The Phoenix Project
- Designing Data-Intensive Applications
Крім того, ми охопили чимало матеріалів про Infrastructure as Code (на початку), Docker (дуже давно), Kubernetes (просто давно), а також, можливо, хтось із вас, хто пішов у лідершип, знайшов корисними такі книги:
- Software Engineering at Google (рекомендую)
- The Staff Engineer’s Path (теж дуже якісна)
Ми зробили величезну роботу — покрили клауди, процеси, моніторинг, логування, фінопс, reliability, скейлінг, сек’юріті, self-healing і багато іншого. Але, як бачите, з моменту виходу першої книги минуло вже 15 років. Попри еволюцію, може бути (?) настав час або для pivot, або для generalization.
Поділюсь кількома думками щодо Generalization Path:
- Гіпотеза: передусім ви — Software Engineer, і вже потім фокусуєтесь на DevOps / Infrastructure / Platforms
- Nobody will hire you if you don't have coding skills
- Це будуть перевіряти через live coding на співбесідах (у тому числі - літкод)
- Часу лишилося не так уже й багато, але роки 2-3-x має бути
- Поговорити про апдейт воркер-ноди чи terraform state вже не вийде :) Точніше, вийде — але лише на одному з 5 етапів інтерв’ю.
Альтернативний Pivot Path
Якщо ви вже працюєте в цьому напрямку - дуже круто!
- ML Operations та все, що з цим пов’язано - у цих вакансіях очевидно всі раунди з літкодом і вишматом
Наприклад:
- Software Engineer, Infrastructure - OpenAI (200к-400k мінус податки плюс еквіті)
- Systems Engineer, Infrastructure - Anthropic (те ж саме)
Можливо, це і звучить як булшит, або читаючи ви не згодні десь всередині, але я хотів цим із вами поділитися. Це стосується тільки топ ЗП-шок, я не думаю що середній DevOps Engineer з медіаною на доу помітить зміни на ринку до наступного gartner hype cycle. Скоріше за все - ні. Міг би ще додати графік кількості відкритих вакансій на глобальному ринку, але передумав. Україна дає чудовий сервіс за вигідну ціну (вітання ФОПам!), тож у нас є час адаптуватися під новий стан речей.
Що робити - Generalization Path:
Додаємо активну розробку скілів:
- CSosvita: алгоритми на практиці (старт 1 травня), performance engineering (старт 29 квітня) — лінки додам у коментарях. Це не реклама - мені за це не платять. Просто ділюся якісним продуктом.
- Лаби / MVPs / бібліотеки — definition of done: ви можете зайти в позицію Middle Software Developer по скілам, (ваша основна експертиза зберігається - інфра-фокус). Це буде ефективно. Тут виходить T-shaped, якщо вас перевіряють як дева - чудово, ви можете, і ще є глибина знань в інфрі. Якщо перевіряють як інфра / platform / sre - чудово, ви ще й бек напишете. Одні плюси!
Що робити - Pivot Path:
- Продовжуємо читати - Reliable Machine Learning (гуглиться через filetype: pdf)
- Проходимо всі лаби на Kaggle
- Згадуємо вишмат
- Купуємо nvidia за декілька К і ганяємо лабки (будуємо end-to-end пайплайн)
Доповідь закінчив 🫡
Також додам, що цю думку я частково почув від Севи Полякова (не прямо цю, але в тому ж напрямку), тож ділюся і своїм баченням, що спостерігаю навколо. Буду радий почути розширену доповідь на DOU Day (у нас присутні шанси послухати цілу доповідь - fingers crossed!)
Усім продуктивного тижня, продовжуємо розвиватися, впевнено дивимось уперед - і запрошую в коментарі: напишіть, чи це булшит, чи все ж має сенс. Буду радий фідбеку! Можливо я даремно всіх напаяв :))
UPD1: на початку ковіду я вже напаяв всіх тут в каналі, і вийшло абсолютно не так 😆 не скріньте цей твіт
Қайта жіберілді:Українська девопсарня
27.12.202411:56
❄️❄️❄️
Надворі була справжня зимова казка. Землю вкрив пухнастий сніг, дерева стояли у білих шатах, ніби вдягли святкове вбрання. Зі ставка долинав тихий тріск льоду, а місяць, мов срібний ліхтар, освітлював засніжені пагорби. Але в цьому холоді було щось тепле й затишне – дух свята, що вже був зовсім близько.
Віталька сидів на підвіконні, загорнувшись у плед. Він дивився на це диво-зиму і думав про те, що скоро свято Різдва. Але ось біда – він досі не вирішив, що попросити.
– Новий велосипед? Але ж у мене є старий, ще їздить. Може, смартфон? Але чи не краще книжки? Ох, як важко…
Раптом почув Віталька, як на подвір’ї щось зашурхотіло. Виглянув – а там стоїть Миколай! У теплому кожусі, з кошиком подарунків.
– Доброго вечора, Віталько, – каже Миколай. – Чому це ти так задумався?
Віталька зніяковів, але чесно відповів:
– Я хочу попросити щось, що зробить мене щасливим. Але я не знаю, що це.
Миколай усміхнувся:
– Хм, мудра твоя думка, хлопчику. Знаєш, що я тобі скажу? Щастя не в подарунках, а в тому, наскільки щосливі люди навколо тебе.
Віталька замислився і раптом вигукнув:
– Тоді я хочу, щоб ти подарував мені РЕБ "Сармат" для 144 ОБ 116 ОБр ТРО.
Миколай зрадів, бо подарунок був чудовим і важливим, але потім засмутився, бо в нього не достатньо грошей.
Тому ми відкриваємо допоміжний збір.
❄️❄️❄️
🎯Ціль: 80 000.00 ₴
🔗Посилання на збір
https://send.monobank.ua/jar/9B9jG3GujU
А щоб і добродіям, і добродійкам було приємно робити гарну справу — кожен донат кратний 200 грн це шанс виграти офігезну книгу 📚 "Чипси: українські наївні мозаїки" з ілюстраціями і описом мозаїк (фотки книг у першому коменті).
Чудова і красива книга, яку классно мати у бібліотеці.
Надворі була справжня зимова казка. Землю вкрив пухнастий сніг, дерева стояли у білих шатах, ніби вдягли святкове вбрання. Зі ставка долинав тихий тріск льоду, а місяць, мов срібний ліхтар, освітлював засніжені пагорби. Але в цьому холоді було щось тепле й затишне – дух свята, що вже був зовсім близько.
Віталька сидів на підвіконні, загорнувшись у плед. Він дивився на це диво-зиму і думав про те, що скоро свято Різдва. Але ось біда – він досі не вирішив, що попросити.
– Новий велосипед? Але ж у мене є старий, ще їздить. Може, смартфон? Але чи не краще книжки? Ох, як важко…
Раптом почув Віталька, як на подвір’ї щось зашурхотіло. Виглянув – а там стоїть Миколай! У теплому кожусі, з кошиком подарунків.
– Доброго вечора, Віталько, – каже Миколай. – Чому це ти так задумався?
Віталька зніяковів, але чесно відповів:
– Я хочу попросити щось, що зробить мене щасливим. Але я не знаю, що це.
Миколай усміхнувся:
– Хм, мудра твоя думка, хлопчику. Знаєш, що я тобі скажу? Щастя не в подарунках, а в тому, наскільки щосливі люди навколо тебе.
Віталька замислився і раптом вигукнув:
– Тоді я хочу, щоб ти подарував мені РЕБ "Сармат" для 144 ОБ 116 ОБр ТРО.
Миколай зрадів, бо подарунок був чудовим і важливим, але потім засмутився, бо в нього не достатньо грошей.
Тому ми відкриваємо допоміжний збір.
❄️❄️❄️
🎯Ціль: 80 000.00 ₴
🔗Посилання на збір
https://send.monobank.ua/jar/9B9jG3GujU
А щоб і добродіям, і добродійкам було приємно робити гарну справу — кожен донат кратний 200 грн це шанс виграти офігезну книгу 📚 "Чипси: українські наївні мозаїки" з ілюстраціями і описом мозаїк (фотки книг у першому коменті).
Чудова і красива книга, яку классно мати у бібліотеці.
14.08.202414:01
Көрсетілген 1 - 14 арасынан 14
Көбірек мүмкіндіктерді ашу үшін кіріңіз.