Мир сегодня с "Юрий Подоляка"

Труха⚡️Україна

Ko'rish

Николаевский Ванёк

Ko'rish

Мир сегодня с "Юрий Подоляка"

Ko'rish

Труха⚡️Україна

Ko'rish

Николаевский Ванёк

Ko'rish

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

ДевОпс Інженер - авторський канал @mukolaich - Head of DevOps у SQUAD.
Я розглядаю технології та рішення, роблю огляд архітектурних проблем, включаючи контейнери, оркестратори, скейлінг, моніторинг, etc.

TGlist reytingi

TuriOmmaviy

Tekshirish

Tekshirilmagan

Ishonchnoma

Shubhali

JoylashuvУзбекістан

TilBoshqa

Kanal yaratilgan sanaFeb 26, 2018

TGlist-ga qo'shildi

Sep 18, 2023

Men kanal egasiman

O'zgartirishlar tarixi

Muxrlangan guruh

ДевОпс Інженер Чат

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

Batafsil

Obunachilar

5 218

24 soat00%Hafta

9-0.2%Oy

26-0.5%

Iqtiboslar indeksi

0

Eslatmalar0Kanallardagi repostlar0Kanallardagi eslatmalar0

Bitta postning o'rtacha qamrovi

0

12 soat00%24 soat00%48 soat00%

Ishtirok (ER)

0%

Repostlar0Izohlar0Reaksiyalar0

Qamrov bo'yicha ishtirok (ERR)

0%

24 soat0%Hafta0%Oy

0.07%

Bitta reklama postining qamrovi

0

1 soat00%1 – 4 soat00%4 - 24 soat00%

Batafsil

Botimizni kanalingizga ulang va ushbu kanal auditoriyasining jinsini bilib oling.

24 soat ichidagi barcha postlar

0

Dinamika

"ДевОпс Інженер 🇺🇦" guruhidagi so'nggi postlar

Barcha postlar

27.03.202510:09

Thousands of exposed GitHub repositories, now private, can still be accessed through Copilot

Хто буде на мітапі, запитайте будь ласка, чому Github Copilot тренують на приватних репозиторіях 🤦‍♂️

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 практики та інструменти? Приєднуйтесь!

Repost qilingan:

Українська девопсарня

27.12.202411:56

❄️❄️❄️
Надворі була справжня зимова казка. Землю вкрив пухнастий сніг, дерева стояли у білих шатах, ніби вдягли святкове вбрання. Зі ставка долинав тихий тріск льоду, а місяць, мов срібний ліхтар, освітлював засніжені пагорби. Але в цьому холоді було щось тепле й затишне – дух свята, що вже був зовсім близько.

Віталька сидів на підвіконні, загорнувшись у плед. Він дивився на це диво-зиму і думав про те, що скоро свято Різдва. Але ось біда – він досі не вирішив, що попросити.
– Новий велосипед? Але ж у мене є старий, ще їздить. Може, смартфон? Але чи не краще книжки? Ох, як важко…

Раптом почув Віталька, як на подвір’ї щось зашурхотіло. Виглянув – а там стоїть Миколай! У теплому кожусі, з кошиком подарунків.
– Доброго вечора, Віталько, – каже Миколай. – Чому це ти так задумався?

Віталька зніяковів, але чесно відповів:
– Я хочу попросити щось, що зробить мене щасливим. Але я не знаю, що це.
Миколай усміхнувся:
– Хм, мудра твоя думка, хлопчику. Знаєш, що я тобі скажу? Щастя не в подарунках, а в тому, наскільки щосливі люди навколо тебе.
Віталька замислився і раптом вигукнув:
– Тоді я хочу, щоб ти подарував мені РЕБ "Сармат" для 144 ОБ 116 ОБр ТРО.

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

Тому ми відкриваємо допоміжний збір.
❄️❄️❄️

🎯Ціль: 80 000.00 ₴

🔗Посилання на збір
https://send.monobank.ua/jar/9B9jG3GujU

А щоб і добродіям, і добродійкам було приємно робити гарну справу — кожен донат кратний 200 грн це шанс виграти офігезну книгу 📚 "Чипси: українські наївні мозаїки" з ілюстраціями і описом мозаїк (фотки книг у першому коменті).

Чудова і красива книга, яку классно мати у бібліотеці.

16.09.202417:39

Deprecation plan

Поділюсь сьогодні з вами подією, яка пройшла дуже тихо в середині літа, але для декого стала досить неприємною. 31-го липня, у своєму ~~твіттері~~ 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". Будьте здорові.

06.09.202416:30

Офлайн DOU DevOps meetup. Київ

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

Знову понабирають невідомого кого на мітапи, ми тут тільки Вову Цапа знаємо 😁

Якщо серйозно, то як я зрозумів, буде тільки 1 спікер і панельна дискусія після доповіді. Хто може прийти - приходьте, подейкують що це можливо і останній подібний офлайновий DevOps-мітап від DOU.

На пост не сваріться, бо мене попросила запостити @dzzzvinka з DOU, а в них є розділ "Зарплати", за допомогою цієї аналітики ми собі багато років підвищували винагороду :)) зазвичай способом "ну там не актуальне, там тільки джуни відповідають"

Реєстрація, як прийнято, зі збором імейлів, телеграмів і лінкедінів (там далі фіолетова кнопка):

https://dou.ua/goto/Zp45

Repost qilingan:

Українська девопсарня

29.08.202415:19

полайкайте PR від якого русня горить
https://github.com/opentofu/registry/pull/817

14.08.202414:01

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 🤝