Трохи про мультитаскові скіли девопсів 🤪

Порівняння продуктивності Amazon Elastic Kubernetes Service (EKS) та Google Kubernetes Engine (GKE)

⚡ Потужність платформ Kubernetes зазвичай сприймається як належне. Це ОК – ми з цим спокійно живемо і працюємо 😊 Але автор статті пішов далі і хоче розібратися, як поводять себе контейнери на двох різних Kubernetes-managed платформах.

Новенького з візуалізації підвезли 👉 Grafana Dashboards - DevOps Nirvana

Якщо ви працюєте з Nginx Ingress та Prometheus, цей дашборд перевершить ваші очікування. Обирайте зручну візуалізацію для метрик AWS і Kubernetes та насолоджуйтесь 😊

Коли DevOps сказав автоматизувати тести. Мануальники, ви теж таке відчували, чи не так..? 😬

Коли ви працюєте з кількома сутностями, load balancing – річ номер 1, про яку треба подбати. У статті на CloudWeekly досить детально розписана робота з алгоритмами load balancing. Гоу читати 👈

Маємо цікаву новину: 14-15 вересня запрошуємо на DevOpsDays Ukraine: Disaster Recovery ⚙️

Організатори конференції готують для нас Cultural Talks, Ignites & Tech Talks від світових та українських експертів: Charity Majors, Iaroslav Molochko, Manuel Pais, Adriana Villela та інші.

Головні теми заходу: Self-Service Tooling, Future of Platforms, CI/CD та IaC для GameDev, як досягати результатів в умовах війни та багато іншого.

Під час live fireside chat можна буде поставити запитання засновнику DevOpsDays, Patrick Debois, та дізнатися більше про його досвід та ідеї.

І, звісно, буде онлайн-нетворкінг на Open-Spaces з однодумцями з усього світу.

💙💛 А ще на івенті діє благодійна ініціатива — збір для фонду UA Responders. Це допоможе закупити необхідну гуманітарну допомогу для рятівників, медиків, парамедиків та інших працівників служб швидкого реагування. Долучайтесь і ви!

Коли? 14-15 вересня
Де? Онлайн

Деталі на сайті 👀 https://bit.ly/3KQ3jXS

Коли спитали, що таке DevOps 🧐

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

У статті маємо цікавий прикладний кейс переходу від моноліту на cell-based architecture від Slack. Перехід зайняв півтора року, а деталі описані у серії статей на сайті проєкту.
Гоу розбиратися!

🤩 libvirt-k8s-provisioner
Ніколи не буде зайвим покласти до робочої скарбнички ще один інструмент Kubernetes. Ділимося тулом, який за лічені хвилини допоможе побудувати робоче середовище кластеру будь-якою необхідною кількістю нод.

Якщо ви DevOps, Tools Engineer або працюєте з Platform Team, вам знайомо, що команди можуть бути різними не тільки за накопиченим досвідом, а й за рівнем «інженерної зрілости». Наприклад, у компанії Big Tech виділяють такі рівні:
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮‍💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.

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

👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.

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

👉 Запропонуйте кастомізацію. Зазвичай команди хочуть враховувати власні потреби при реалізації будь-яких нових рішень. У ролі лідера/керівника ви маєте дати їм таку можливість та не блокувати здорові побажання.

👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.

👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.

👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.

Підсумуємо: будуючи сервісні платформи/інструментарій у команді, робіть речі простими, доступними та зрозумілими. Мінімізуйте ієрархію узгоджень і максимально впевнено просувайте саме ваші рішення 🚀

Feeling DevOps Power ⚡️

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

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

💥 Pixi – інструмент керування пакетами для розробників. Дає можливість легко встановлювати бібліотеки та застосунки. Працює на Windows, Mac і Linux.

Управління командою SRE вимагає побудови певної системи, в якій ви співпрацюєте як з командою, так і замовниками. У замовників різні потреби й дедлайни, у команди – виклики й рішення. Щоб гармонійно й ефективно управляти цими процесами, автор статті виділяє кілька SRE Engagement Models: Consulting, Embedded, Infra Team. Детальний розбір підходів у статті 🤓

🤓 Чекліст SRE: Хард скілз 🤓

Чеклісти ніколи не бувають зайвими, особливо якщо ви в постійному професійному розвитку та цікавитесь новими ролями. Підготували для вас кілька чеклістів для SRE, але щоб не розгубитися, викатувати будемо релізами, тобто партіями, тобто постами…ну ви зрозуміли :))))

Сьогодні розбираємо hard skills.

👉 Програмування. Не має принципового значення якою мовою, але ви маєте вміти писати (й читати) код. Якщо сумніваєтесь, обирайте Python – оптимально для бази.

👉 Моніторинг. Критична навичка, бо відстеження метрик для забезпечення надійності та стабільності систем – це основа основ SRE.

👉 CI/CD (Continuous Integration/Continuous Delivery). Сьогодні це невіднятна частина будь-якого процесу розробки, що охоплює як безпосередньо саму розробку, так і автоматизацію всього життєвого циклу ПЗ.

👉 IaC (Infrastructure as Code) і CM (Configuration Management). Допомагають автоматизувати як створення коду, так і управління інфраструктурою (й суттєво полегшують життя SRE-інженера).

👌 Опціонально: Containers, Kubernetes, Cloud, Virtualization. Ці напрями не є жорстким мастхевом, але безперечно вони розширюють вашу професійну впевненість і відкривають більше можливостей у роботі.

Що б ви додали до цього чекліста з власного досвіду? Напишіть у коментарях.

🤩 acme-dns 🤩
Спрощений DNS-сервер з RESTful HTTP API для простої автоматизації задач ACME DNS.

👀 Якщо ви мали проблему з деплоєм модулів Terraform у різних регіонах AWS, цей практичний кейс для вас. З кодом та поясненнями – все як ми любимо!

💥 tfvar
Генератор зразків variable definitions у Terraform. Застосунок сканує конфігурації або модулі та витягує перемінні у необхідному для вас форматі.

👀 Розбираємось із підходом config-driven import в Google Cloud. Окрім теорії в статті є кейс налаштування автоматичних сповіщень через Terraform.

Жарт, старий як світ, але й досі актуальний 🙈

У справжнього тім-ліда немає цілі - є тільки беклог 🗡