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

DevOpsDays Ukraine: Disaster Recovery

Вітання,

14-15 вересня не плануйте додаткових активностей після робочого дня, тому що у нас - DevOpsDays, з вектором на концепцію Аварійного Відновлення. Коли ми планували івент в кінці минулого року, то дуже вірили і сподівались що ця тема буде доречною після перемоги, але зараз можемо констатувати її важливість і протягом бойових дій.

Ви можете знати цих чудових людей:
🇺🇦 Iaroslav Molochko - How to deliver despite wartime. Manager's view
🇺🇦 Maksym Vlasov - Easy way to make your code Legacy™
🇺🇦 Vsevolod Poliakov - TBD
🇺🇦 Valeriia Ivanova - DevOps in GameDev

І багато інших міжнародних експертів.

Компанії, які долучаються спонсорами - донатять на UAResponders, DevOpsDays з інших куточків планети (Chicago, Tel Aviv, Warsaw, Vilnus, Almaty, Taipei) також допомагають гривнею і медійно.

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

14-15 вересня (цей четвер, п’ятниця) спробуйте перезаватажитись і знайти для себе щось нове, цінне у тому, чим займаєтесь кожного дня. Після доповідей - опенспейс дискусії. Побачимось.

https://www.devopsdays.com.ua/#registration

Architecture Decision Record або Architecture Decision Log

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

Вперше про Architecture Decision Log почув коли необхідно було впровадити новий інструмент згідно ріквесту нашого замовника, але він був прямо ну абсолютно не юзабельний. Треба було комунікувати документами, бо на пальцях неможливо мати сильну позицію на обговореннях.

Надалі ми зробити Confluence сторінку, де описали Pros/Cons, фідбеки від команд, потенційні проблеми і пояснювали замовнику, що ми типу можемо, але буде дуже боляче. Це і був ADR, який народився природно.

З часом прийнятих і не прийнятих рішень створюється величезний snowflake, надалі ж - всім відома фраза так склалось історично. Тому, для того, щоб розуміти історію прийнятих або відхилених рішень з питань архітектури, практик, тулсету - рекомендую використовувати Architecture Decision Record підхід, або ж інший його неймінг - Architecture Decision Log.

Додаю приклад, як зробити цей підхід набагато зручніше, ніж сторінки в Confluence:

https://github.com/ministryofjustice/modernisation-platform/tree/main/architecture-decision-record

Забирайте шаблон, і будуйте стійкі докази для прийнятих, або відхилених рішень.

Next War Won't be a Cyber War, it will be a DevOps War

(1) У нас багато роботи
(2) Ми знаємо що робити, в цьому кейсі так точно
(3) F-16, ATACMS ASAP

https://ryanmcbeth.substack.com/p/how-america-loses-the-next-war?sd=pf

TLDR: Орки вчились збивати HIMARS 6+ місяців

DOU DevOps Meetup

Шановні девопси, 26 липня у Києві організовуємо офлайн-мітап! Нічого не плануйте на вечір (середа), будемо спілкуватись, слухати доповіді, подивимось на наше комьюніті під час війни і зберемо трохи донатів на перемогу 🚀

Локацію повідомимо згодом, інженерів з інших регіонів - запрошуємо, онлайн - стрімити будемо.

Станом на зараз у нас є рокстар-спікер Сергій Міхно (на Kyiv DevOps Community розклав ClickHouse + vector.dev по поличкам), тому прохання долучатись до Call For Papers:

https://docs.google.com/forms/d/e/1FAIpQLSepkpfQcY-rEaIOuZzP7w4rrFuJ6LYTI9rWFnvAqnvtPp-xPw/viewform

Що цікаво:
- деліверіс (CNCF, Kuberentes, клауди, хайлоад)
- унікальний досвід роботи під час війни (електрика, датацентри, міграції, атаки)

Що не цікаво:
- реклама
- руснявий тулінг 💩

Долучайтесь у якості спікерів, ETA - 2 тижні.

Разом переможемо! 🇺🇦

Shark + Шалені Кабани

Вітаю, прохання конвертонути новини вчора —> в хороший донат сьогодні.

Підсвічую 2 варіанти:
1) @shaleni_kabany - Альфа, Омега, ГУР, гумові човни, набої, тепловізори. Рекомендую підписатись, ми вже допомагали Шаленим Кабанам і успішно зібрали на частину бандеромобіля.
Останнього разу мене просили підсвітити збори на човни - не знаю наскільки це актуально зараз, енівей - хлопці тримають руку на пульсі, і радують підписників чудовими відео (якщо ви розумієте, про що я) 🚀

2) DOU збирає потужну котлету на борти Shark, а велика котлета збирається з мікродонатів.
Долучайтесь: https://dou.ua/forums/topic/43731/

Тихого і продуктивного дня 🤝

Inside Datadog’s $5M Outage (Real-World Engineering Challenges #8)

Datadog автоматично насетапили собі апдейт Ubuntu 22.04 з декількома фіксами systemd і завалили собі весь мультиклаудний продакшн. Причому проблема була не в systemd, а в процесі оновлення цього пакету, який перетер їм кастомні eBPF роутинги.

Виглядає не дуже, і далі Datadog виправдовується у частині постмортему під назвою “4. Why did running in 5 regions on 3 different cloud providers not help?” 😅

Загалом багато питань:

- Чи є хоч якийсь інший енв, де ці апдейти деплойнулись за день-два, до проду? Їх ішью зарепродьюсилось би всюди, навіть на якомусь мікро енві, де є лише декілька нод.

- Функціонал ролбеку працює зовсім не так, як потрібно, бо оновлення не зупинилось після Х% unhealthy хостів (типу, ой, цей регіон ми вже поклали - і автоматизація вирішує не продовжувати далі, а пробувати ролбечити не здорові хости)

- Чи знали on-call інженери, що запустився автоапдейт? Через 3 хвилини прилетів перший алерт, далі через 15 хвилин прокинувся перший сапорт, і ще через 16 було очевидно increased latency. Чи можна було розкатати сетінгу “бігом вирубаємо unattended upgrade”?

Власне, в цьому потсмотремі мені не подобається абсолютно все, і навіть прикро за Datadog що все було проти них. Окрім цитат з SRE book, вони завжди подобаються.

Дивимось далі, Datadog робить такі висновки:
- 1. Made OS images resilient to systemd updates.
- 2. No more automatic updates.

Виходить, що вирішили вимкнути security updates. На масштабі Datadog, думаю, доцільно було б найняти окрему команду, і назавжди віддати цю проблему (тестити, деплоїти мануально-автоматизовано, нести відповідальність).

У нас немає такого масштабу, і за день такої сраки ми не втратимо $5M. В той же час, нам потрібні секьюріті апдейти хостової ОС. Амішки, драйвери, пакети - все що можна, має бути свіжим з пофікшеними vulnerabilities, але тепер великий челендж - не отримати такий результат, як у Datadog.

Щоб бути world-class інженерами, треба вирішувати world-class проблеми. Будемо вирішувати.

https://newsletter.pragmaticengineer.com/p/inside-the-datadog-outage

How We Gained Observability Into Our CI/CD Pipeline

Випадково наткнувся на досить непогану динамічну доповідь про observability в CI/CD від компанії Logz.io

Logz - це та компанія, яка давала офер з двозначного числа ще до війни (зараз - не знаю), і на співбесідах уже було настільки напряжно, що не так і хотілось той офер. На співбесідах менеджери насідали так потужно, що мені здавалось що я вже вписався в двіжуху Puppet/Chef/Salt на дедіках, хоч це був якийсь там початковий етап циклу співбесід. Купа кластерів, деплойментів, різних шматків, просто хардкор.

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

Щодо доповіді (ключові поінти):
🔸 Надсилаємо логи білдів в Logging Platform, де аналізуємо (скільки джоб, які помилки, тривалість етапів, etc) і робимо візуалізації + можемо і нотифікації

DevOps Podcast #0

Спеціально переглянув, перед тим як постити, щоб все було ок (хоча це ж DOU, тому мало б бути точно ок, але все ж).

Мої враження:
- Індусам випуск би не сподобався, бо ведучі запропонували зробити каунтер для жартів про індусів
- Це другий прецедент ДевОпс підкасту на нашому ринку (перший - Неправильний ДевОпс), вітаємо команду 👍
- Ведучі - приємні люди, підкаст комфортно слухати, працювати під нього, в тачці думаю теж (але швидкість х1.5)
- Топіки, я так розумію, з коментів, і їх нормально навалило на ще один, і навіть ще пару епізодів - то ж, чекаємо
- В обговореннях не помітив зашкварів, якоїсь лютої дичини, або відверто тригерних моментів - вважаю, що пройшло на досить непоганому рівні

Серед цікавого для себе виніс курс на Coursera - Learning How to Learn, якось за часу та натхнення зверну увагу на цей курс, і сподіваюсь він буде в скарбничці штук, які можна рекомендувати ньюкамерам.

З коментів ютубу, в коментатора трохи підгоріло, а ми можемо зробити висновок - що ведучі говорять з нами мовою ДевОпсів лол 🙂:
На Амазоні дуже багато всього ЧАРДЖИТЬСЯ за просто те, шо це МЕНЕДЖ

З важливого, варто зазначити що ми бачили 4 спікери, але для того щоб це їхало - існує велика команда DOU, яка невпинно формує українське ІТ. І це чудово. Там є свої зірочки. Вони великі молодці.

https://www.youtube.com/watch?v=pocI7wSNFVI

Накидайте швидко пліз 24 698

Доброго дня, точковий і швидкий мікро-збір для НГУ, 7 окремий стрілецький батальйон, 23-тя бригада, військовий лікар самостійно долучився до лав сил оборони, необхідний ноутбук для роботи в полях.

Збір під контрнаступ! Тому треба швидко.

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

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

https://send.monobank.ua/jar/9iWEDkeepe

containerd + fluentbit != json logs?

Шановне DevOps панство, звертаюсь не з вирішенням, а саме з проблемою. Підкажіть пліз, хто стикався з такою штукою, і чи вдалось пофіксити або знайти воркераунд?

У нас після апгрейду на AWS EKS 1.25 з containerd CRI відпав валідний анмаршал json. Тобто після фіксів логи збираються, все ок, приходять в OpenSearch але не парсяться в окремі філди, зручні для фільтерінгу.

Більш детально поведінка описана тут (в нас абсолютно ідентичний кейс):
https://github.com/fluent/fluent-bit/issues/7218

Як пофіксили?