👀 Продовжуємо розбиратися, які ж метрики варто застосовувати в оцінці роботи DevOps. Сьогодні поговоримо про CI/CD-системи. Отже, на що варто звернути увагу:

🔄 Average CI duration (Середня тривалість CI). Розробка ПЗ базується на невеликих змінах, що вносяться до кодової бази, й результатах цих змін. Якщо процес CI/CD повільний, внесення змін стає бідою та накладає негативний відбиток на творчий процес створення коду.

🏃 CI runs per day (Кількість виконань CI на день). Середньостатистичний показник у 4-5 запусків на день є цілком нормальним. Менша цифра свідчить про те, що система CI/CD використовується недостатньо ефективно.

🤕 CI mean time to recovery (MTTR) (Середній час відновлення CI після інциденту). Ця метрика показує, скільки часу необхідно команді, щоб відновити порушений CI-білд.

🥴 CI test failure rate (Відсоток невдалих тестів CI). Показник звітує, як часто CI pipeline провалює тести. Метрика може вказувати на проблеми з локальними тестами у розробників.

🎰 CI success rate (Відсоток вдалих запусків CI). Цифра, що розраховується шляхом ділення кількості вдалих запусків CI на загальну кількість запусків. Занизький показник може вказувати на проблеми з тестуваннями коду розробниками локально.

🌧 Flakiness (Непостійність результатів). Ця метрика може підсвітити, наскільки нестійка та хитка ваша CI/CD. Оцінити вразливість можна за тим, як часто процес збірки зупиняється без видимих причин або через невдалі тести.

🌎 Code coverage (Покриття коду). Процент коду, який покривається пакетом тестів. Варто пам’ятати, що цей показник часто трактують некоректно. Наприклад, вимога 100% покриття не підвищує якість. Навпаки, вона призводить до зайвого тестування тривіального коду.

⏳ CI Defect Escape Ratio (Середній час виправлення інциденту). Вимірює кількість помилок, виявлених CI/CD системою впродовж певного часу.

Метрики – важливі показники вашого проєкту. Поганий показник – це тільки симптом, а не хвороба

Тож трекайте, вживайте превентивних заходів та слідкуйте за прогресом регулярно 🚀

🤌 Robusta KRR (Kubernetes Resource Recommender) – CLI-інструмент для оптимізації розміщення ресурсів у кластерах Kubernetes. Тула збирає дані про використанння подів із Prometheus та пропонує ліміти для центрального процесора й пам’яті. Таким чином, Robusta KRR допомагає зменшити витрати й оптимізувати перформанс.

Наглядна схема CI/CD Pipelines

Leaky Vessels: Docker and runc container breakout vulnerabilities (January 2024) ⚡️

Рорі Макнамара, фахівець з безпеки Snyk Security Labs, розказує про «Діряві судини» – чотири вразливості Docker в основних компонентах контейнерної інфраструктури. Ці недосконалості можуть бути використані зловмисниками для неавторизованого доступу з усіма витікаючими наслідками.
Як тільки команда Snyk Security Labs перевірила та підтвердила ці вразливості, вона ініціювала процес офіційного повідомлення Docker про ці баги.

У статті можна дізнатися як Snyk шукали та підтверджували вразливості, а також таймлайн процесу їх розкриття.

Стаття варта уваги всіх, хто ретельно дбає про безпеку своїх DevOps-інструментів та полюбляє детективні історії пошуку багів та вразливостей.

Хто зрозумів...той зрозумів ;)

Podman Desktop – відкрита альтернатива графічного інструмента Docker Desktop для управління контейнерами на лептопі. Для роботи необхідно встановити також Podman Engine, бо з Docker Engine ця тула не сумісна.

У фіналі можна отримати якісний набір:
▫️ графіка та GUI – Podman Desktop;
▫️ Docker CRI – Podman Engine.
Завантажити можна на офіційному сайті ⬅️

🤓 Linux File System Explained – наглядне й доступне відео про те, як побудована ієрархія файлової системи Linux та її відмінності на різних дистрибутивах. Як каже автор: «Спочатку був хаос…» :))

🤓 Owloops – інструмент для моніторингу сайту в режимі реального часу з приємною візуалізацією.

Класна стаття про моніторинг в Kubernetes, швидкий та ефективний, як любить кожен девопс ☺️

Сьогодні п'ятниця, а значить - жодних необдуманих дій!

🔧 Eraser – софт для систематизації документів та схем інженерних команд. Централізація всіх файлів та командна скарбничка знань у вигляді репозиторію.

🤩 Ловіть інструмент для автоматизації деплойменту та менеджменту Helm charts (k8s applications) з version-controlled коду.

⚡️ Корисна серія постів про логування в Kubernetes

▪️ How It Works: Cluster Log Shipper as a DaemonSet
▪️ Getting Started with Grafana Loki, Part 1
▪️ Getting Started with Grafana Loki, Part 2: Up and Running

🔧 Пакет Terraform та OpenTofu GitHub Actions створено для сумісного використання при побудові ефективної інфраструктури.

Жиза :))))

У вашу команду потрібен SRE, але пошуки вперлися в глухий кут? Погляньте на ці п'ять пунктів, які можуть заважати найму ідеального кандидата.

📌 Вимоги до кандидата та робочого прогресу зависокі.
📌 Задачі фахівця описані нечітко й непрозоро.
📌 Роль кандидата в команді незрозуміла.
📌 Немає розуміння, на що майбутній SRE може впливати в компанії (глобальна роль в організації).
📌 Відсутня згадка про взаємодію SRE з іншими командами.

Відгукнулося щось з цього списку? Тож, можливо, варто переглянути опис вакансії й пошуки вашого ідеального кандидата значно прискоряться. Успіхів!
Невдовзі розповімо, як провести онбординг фахівця на позиції SRE.

🤩 Devpod: Improving Developer Productivity at Uber with Remote Development

Розробники Uber діляться, як їм вдалося покращити щоденну роботу edit-build-run розробників за допомогою DevPods, – середовища віддаленої розробки. Команда розповідає про вихідні проблеми, які вони намагалися розв’язати, про архітектуру та нещодавні успіхи зі зниження витрат. Також автори поділилися думками щодо майбутнього віддаленої розробки в Uber.

👾 Онбординг SRE: проходимо рівні як у комп’ютерній грі.

Ви знайшли ідеального кандидата на роль SRE. Так, знаємо, це нелегко, але you did it! Попереду процес онбордингу (та повнісінький беклог задач), який варто провести лагідно й делікатно, щоб ваш новий тіммейт не пішов, навіть не почавши.

Отже, що важливо:
▫️ ставте робочі задачі по принципу «від простого до складного»;
▫️ не варто у перший день роботи просити нового колегу пофіксити баги, з якими ваша команда не справляється вже довгий період часу;
▫️ дайте час колезі розібратися з тим, що взагалі у вас відбувається 😅

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

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

Вічна тема 🤪

🤓 5 лайфхаків для онбордингу SRE

Новенький на борту, онбордінг почався, тож робимо все лагідно й делікатно, щоб цінна людина комфортно влилася у колектив (та залишилася з вами надовго)👌

👉 Для junior-SRE давайте мікс із задач «на подумати» та «зробити». Це допоможе новому колезі урізноманітнити воркфлоу та тримати баланс у навантаженні на перших етапах співпраці з командою.

👉 Не ставте нового тіммейта одразу «гасити пожежі». Натомість запропонуйте розібратися у тікетах низької та середньої пріоритетності, надаючи менторську підтримку.

👉 Не варто одразу надавати новим співробітникам повну автономію. Всі члени команди мають бути залучені у хід проєкту та бути в єдиному інформаційному полі.

👉 Ставте колезі невеликі за обсягом задачі, поступово підвищуючи їх складність та обсяг. Давайте регулярний фідбек та оцінку виконаної роботи. Разом проговорюйте складнощі та шляхи їхнього вирішення.

👉 Комбінуйте on-call duties з проактивною роботою. Давайте новому SRE можливість роботи над власними рішеннями з удосконалення роботи системи.

Сподіваємось, наші поради допоможуть вам успішно інтегрувати нового колегу у вашу команду. А якщо маєте що додати до лайфхаків, напишіть у коментарях.