Ми вже розповідали про DORA, який є одним з базових підходів до оцінки DevOps-команд.

Сьогодні поговоримо про три ключові психологічні моменти, які варто враховувати, коли справа стосується відстежування метрик у DevOps.

👉 Люди поводяться по-іншому, коли знають, що за ними стежать або вони знаходяться під тиском. Це ще називають Хоторнським ефектом. За можливості, метрики краще не прив’язувати до певної ролі/фахівця та робити їх анонімними.

👉 Метрики мають порівнювати результати певної команди протягом визначеного періоду, а не різні команди. Так само не варто порівнювати прогрес членів однієї команди одне з одним.

👉 Занадто багато уваги до процесу оцінювання може призвести до того, що люди будуть намагатися «перехитрити систему».

Тому, розробляючи систему метрик, враховуйте, що ваша задача – виявити помилки у рішеннях та підходах з метою підвищення ефективності команди. Не фокусуйтеся на певних членах команди й оцінюйте результат спільної роботи.

А в наступному дописі підкинемо вам ідей, з якими показниками це можна робити.

Метрики в DevOps не завжди використовуються однаково – все залежить від контексту. Показники, які вимірюються, можуть вказати на помилки, слабкі сторони або попередити від застосування низькоефективних рішень.
Підготували для вас чек-ліст метрик, які допоможуть оцінити результат роботи команди. Ловіть першу порцію.

⏳Cycle time (Тривалість циклу). Важливий показник, який оцінює середній час між виникненням ідеї реалізувати фічу до моменту виходу її в продакшн.

🕘 Uptime (Час роботи застосунку). Процент часу, коли застосунок є доступним і працює. Вкрай важлива метрика, яка впливає на кількість клієнтів, що втрачаються через недоступність застосунку.

🤌 Quality (Якість). Цей показник залежить від того, що вкладає в нього кожна окрема команда. Він може відображати відповідність ПЗ стандартам, високий рівень безпеки або рівень задоволення користувача.

🗣 Customer feedback (Зворотний зв’язок користувача). Зворотний зв’язок може оцінюватися кількістю відкритих тікетів, згадок у соцмережах, оцінки продукту в опитуваннях та дослідженнях тощо.

👍 Employee satisfaction (Задоволення співробітників). Задоволеним має бути не тільки користувач, але й люди, які працюють над продуктом: розробники, тестувальники, бізнес-аналітики, продакт-менеджери тощо. Найкращі ідеї генеруються впевненими, позитивними та задоволеними життям людьми.

А в наступному дописі опублікуємо показники, які оцінюють роботу CI/CD-пайплайну. Не пропустіть!

Squashing bugs like a boss 😎

👀 Продовжуємо розбиратися, які ж метрики варто застосовувати в оцінці роботи 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.