Труха⚡️Україна
Труха⚡️Україна
View
Николаевский Ванёк
Николаевский Ванёк
View
Инсайдер UA
Инсайдер UA
View
Труха⚡️Україна
Труха⚡️Україна
View
Николаевский Ванёк
Николаевский Ванёк
View
Инсайдер UA
Инсайдер UA
View
ДевОпс Інженер 🇺🇦 avatar

ДевОпс Інженер 🇺🇦

Technology
ДевОпс Інженер - авторський канал @mukolaich - Head of DevOps у SQUAD.
Я розглядаю технології та рішення, роблю огляд архітектурних проблем, включаючи контейнери, оркестратори, скейлінг, моніторинг, etc.
TGlist rating
0
0
TypePublic
Verification
Not verified
Trust
Not trusted
LocationУзбекістан
LanguageOther
Channel creation dateMay 10, 2025
Added to TGlist
Sep 18, 2023
I own this channel
History of changes
Linked chat
ДевОпс Інженер Чат
ДевОпс Інженер Чат
44

Records

14.08.202423:59
5.4KSubscribers
03.06.202423:59
200Citation index
31.08.202423:59
1.9KAverage views per post
09.05.202502:05
1.8KAverage views per ad post
13.05.202522:39
5.98%ER
31.08.202423:59
35.80%ERR

Growth

More details
Subscribers
Citation index
Avg views per post
Avg views per ad post
ER
ERR
JUL '24OCT '24JAN '25APR '25
More details

Popular posts ДевОпс Інженер 🇺🇦

All posts
12.05.202520:03
Вступ до MLOps і LLMOps

Добрий вечір пані і панове,

Сьогодні прийшов до вас з вебінаром по MLOps і LLMOps, який проводить Дмитро Сподарець - і він займався цим ще до мейнстріму. Враховуючи глибоку експертизу, ми запросили Дмитра допомогти в організації DevOpsDays Ukraine: AI Chapter (відбудеться восени), і я хотів би порекомендувати відвідати безкоштовний міт:

➡️ https://lu.ma/pz9mltkn?tk=4k0AIj

Також і я працюю в цьому домені, тому тримайте мікро-підбірку технологій, які не будуть зайвими в Machine Learning Operations. Частину ми використовуємо або використовували, частину я бачив на суміжних проектах, тощо.

Основна суть - додати собі в "контекст", щоб коли зустрічаєте статтю або гайд - не скіпали, а розбирались. Все це (ну майже) сетапиться на K8S, і цього набору буде достатньо щоб створити і потикати ML pipeline.

Отже, поїхали, по доменам:
1) Annotation - CVAT, Label Studio
2) Pipelines - KubeFlow / Metaflow / Airflow
3) Experiment tracking - MLFlow
4) Distributed Training - Ray, Horovod
5) Data Versioning - DVC
6) Serving - скиньте в коменти, у нас модельки на еджі (BentoML? KServe? Seldon Core? )
7) Feature Store - Feast
8) Model Registry - також MLFlow
9) Monitoring - Prometheus Stack
10) Tracing - OpenTelemetry + Jaeger

(закінчив список на тулах, які ви ВЖЕ знаєте - для хорошого настрою)

По KubeFlow у нас прям топова експертиза, в сторону multi-region, на 1000+ GPU-шних нод (автоскейлінг звісно). А ще ми випалили лям доларів через залипші поди в кубфлоу, але про це колись буде окремий пост.

Тихої ночі!
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: на початку ковіду я вже напаяв всіх тут в каналі, і вийшло абсолютно не так 😆 не скріньте цей твіт
Reposted from:
DOU | DevOps avatar
DOU | DevOps
16.05.202513:39
Триває найбільша конференція IT-спільноти – DOU Day – і ми вирішили запитати спікерів, як їм подія 😎

Ділимось відповідями Всеволода Полякова, Head of Infrastructure в Let's Enhance. А вам як конфа?
Post media background
Post media
14.05.202509:37
✅ Fwdays Academy відкриває набір на другий потік Platform Engineering Course! Ви зануритеся в Terraform CDK, AWS CDK, Pulumi, Kubernetes CRDs та Helm, отримаєте практичні навички та створите рішення для автоматизації платформ.

Згідно з дослідженнями IT-ринку, в 2025 році фахівці з Platform Engineering заробляють на 20% більше, ніж DevOps-інженери!

👉 Реєстрація та деталі: https://bit.ly/4jNpNI0
📅 Дати: 2-13 червня 2025
⚙️ Формат: 6 практичних онлайн-занять з реальними кейсами, груповою роботою та індивідуальними завданнями
🚀 Кількість місць обмежена
💰 Промо на -10%: mukolaich

Кому буде цікаво?
🔸 DevOps-інженерам
🔸 Розробникам
🔸 Системним адміністраторам
🔸 QA-спеціалістам
🔸 Всім, хто прагне прокачати навички Kubernetes, IaC та автоматизації інфраструктури

💡 Ментор курсу: Anton Grishko — Chief Architect у ProfiseaLabs, спікер DevOps-конференцій, автор статей на DOU і Medium. Понад 15 років у сфері ІТ, один із засновників стартапу з Platform Engineering.

🔥 Отримайте нові знання разом з Fwdays Academy!
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"
- Трохи більше часу на пошук компанії, але ринок +- норм.
- Очікування від кандидатів ростуть, і будуть продовжувати рости.

Виглядає оптимістичніше, ніж попередній пост на цю тему 🙂 Рекомендую прочитати статтю повністю. І продовжуємо вчитись проходити інтерв'ю - це окремий скіл, який покращується з досвідом і роботою над помилками. Всім успіхів!
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% зросту від дна ринку (як в опозицію до поста, який писав вище). Успіхів!
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 це логує на балансерах, функціях і інших компонентах. Прочитайте це будь ласка, і я прямо зараз фолоу-апну питанням.
Log in to unlock more functionality.