🏆 Метрики успіху DevOps: DORA metrics
Кожен процес у розробці унікальний та вимірюється своїми метриками. Тому важко проводити певні паралелі між різними процесами. Важливо розуміти: порівнювати за метриками варто не кількох фахівців або команди, а прогрес/результат конкретного фахівця чи команди. Розглянемо один з популярних підходів оцінки DevOps – DORA metrics.
DORA (DevOps Research and Assessment) – найбільша та найстаріша дослідницька програма, що працює в області вивчення доставки ПЗ та операційної продуктивності.
Ось 4 метрики, за якими DORA пропонує оцінювати успіх DevOps-процесів:
👉 Deployment frequency (DF): частота успішних релізів у компанії (як у продакшен, так і до кінцевого користувача).
👉 Lead time to changes (LT): час, протягом якого коміт доходить до продакшену чи релізу.
👉 Mean time to restore service (MTTR): час відновлення після інциденту в продакшені.
👉 Change failure rate (CFR): процент релізів/деплойментів, які спричиняють помилки в продакшені.
Відповідно до цих метрик DORA ділить команди розробки на Low, Medium, High та Elite.
Кожен процес у розробці унікальний та вимірюється своїми метриками. Тому важко проводити певні паралелі між різними процесами. Важливо розуміти: порівнювати за метриками варто не кількох фахівців або команди, а прогрес/результат конкретного фахівця чи команди. Розглянемо один з популярних підходів оцінки DevOps – DORA metrics.
DORA (DevOps Research and Assessment) – найбільша та найстаріша дослідницька програма, що працює в області вивчення доставки ПЗ та операційної продуктивності.
Ось 4 метрики, за якими DORA пропонує оцінювати успіх DevOps-процесів:
👉 Deployment frequency (DF): частота успішних релізів у компанії (як у продакшен, так і до кінцевого користувача).
👉 Lead time to changes (LT): час, протягом якого коміт доходить до продакшену чи релізу.
👉 Mean time to restore service (MTTR): час відновлення після інциденту в продакшені.
👉 Change failure rate (CFR): процент релізів/деплойментів, які спричиняють помилки в продакшені.
Відповідно до цих метрик DORA ділить команди розробки на Low, Medium, High та Elite.
👍3🔥3
terraform-local 🤝
Інструмент для Terraform CLI, який допоможе напряму́ деплоїти застосунки із Terraform до LocalStack.
Інструмент для Terraform CLI, який допоможе напряму́ деплоїти застосунки із Terraform до LocalStack.
👍4
⚡️ togomak
Декларативний оркестратор пайплайну, побудований на базі HashiCorp Configuration Language (HCL) та найкращих фішок архітектури Terraform.
Декларативний оркестратор пайплайну, побудований на базі HashiCorp Configuration Language (HCL) та найкращих фішок архітектури Terraform.
👍1🔥1
Якщо ви працюєте з проєктами у Terraform, вам відомий біль того, як важко підтримувати зрозумілу документацію та апдейти. А з ростом проєктів це питання стає все більш обтяжливим.
Створення документації вручну – процес не дуже приємний, бо забирає багатенько часу й уваги. Автор статті діліится своїм досвідом використання terraform-docs – утиліти з відкритим кодом, яка автоматично генерує документацію з ваших модулей у Terraform. Звучить досить багатонадійно. Гоу розбиратися 🚀
Створення документації вручну – процес не дуже приємний, бо забирає багатенько часу й уваги. Автор статті діліится своїм досвідом використання terraform-docs – утиліти з відкритим кодом, яка автоматично генерує документацію з ваших модулей у Terraform. Звучить досить багатонадійно. Гоу розбиратися 🚀
Medium
Terraform documentation made easy with terraform-docs
A complete guide to Terraform documentation with terraform-docs
👍5
🤓 Architecture Patterns: The Circuit-Breaker. Стаття для тих, хто працює з мікросервісами та цікавиться різними підходами до роботи з ними.
Medium
Architecture Patterns : The Circuit-Breaker
What is “Circuit Breaker”?
👍2👏1
👋 Якщо ви не тестуєте ретельно у Terraform, ми йдемо до вас. Стаття про важливість тестів та інструменти з прикладами.
Landadevopsjob
Where Did All The Terraform Testing Go?
A deep dive into the state of Terraform testing in the wild
👍5
🌧 Handling a Regional Outage: Comparing the Response From AWS, Azure and GCP.
Що може статися, якщо відключиться регіон у cloud-провайдера? Простими словами, будь-що: від зависання застосунку McDonalds до неможливості входу користувача у Slack. У статті автор детально розбирає кейси Regional Outage трьох хмарних гігантів – AWS, Azure та Google Cloud.
Що може статися, якщо відключиться регіон у cloud-провайдера? Простими словами, будь-що: від зависання застосунку McDonalds до неможливості входу користувача у Slack. У статті автор детально розбирає кейси Regional Outage трьох хмарних гігантів – AWS, Azure та Google Cloud.
The Pragmatic Engineer
Handling a Regional Outage: Comparing the Response From AWS, Azure and GCP
This year, AWS, Azure, and Google Cloud have all suffered comparable regional outages. How did they respond, and why do Azure’s processes stand out compared to its rivals?
👍3🤔1
🤓 Shift Mon
Інструмент для моніторингу та логів на базі Telegraf, Victoriametrics, Loki, Grafana та Uptime Kuma.
Інструмент для моніторингу та логів на базі Telegraf, Victoriametrics, Loki, Grafana та Uptime Kuma.
👍2🔥1
Інсайти з тестування та валідації Infrastructure-as-a-Code (IaaC) у HashiCorp Terraform 🔥
👍3
gh-copilot 🔧
GitHub Copilot – це розширення для командного рядка GitHub. Пропонує інтерфейс у вигляді чату в терміналі, де можна ставити питання щодо CLI. Можна питати, наприклад, про певні команди або попросити запропонувати конкретну команду для вашого use case.
GitHub Copilot – це розширення для командного рядка GitHub. Пропонує інтерфейс у вигляді чату в терміналі, де можна ставити питання щодо CLI. Можна питати, наприклад, про певні команди або попросити запропонувати конкретну команду для вашого use case.
👍2
Ми вже розповідали про DORA, який є одним з базових підходів до оцінки DevOps-команд.
Сьогодні поговоримо про три ключові психологічні моменти, які варто враховувати, коли справа стосується відстежування метрик у DevOps.
👉 Люди поводяться по-іншому, коли знають, що за ними стежать або вони знаходяться під тиском. Це ще називають Хоторнським ефектом. За можливості, метрики краще не прив’язувати до певної ролі/фахівця та робити їх анонімними.
👉 Метрики мають порівнювати результати певної команди протягом визначеного періоду, а не різні команди. Так само не варто порівнювати прогрес членів однієї команди одне з одним.
👉 Занадто багато уваги до процесу оцінювання може призвести до того, що люди будуть намагатися «перехитрити систему».
Тому, розробляючи систему метрик, враховуйте, що ваша задача – виявити помилки у рішеннях та підходах з метою підвищення ефективності команди. Не фокусуйтеся на певних членах команди й оцінюйте результат спільної роботи.
А в наступному дописі підкинемо вам ідей, з якими показниками це можна робити.
Сьогодні поговоримо про три ключові психологічні моменти, які варто враховувати, коли справа стосується відстежування метрик у DevOps.
👉 Люди поводяться по-іншому, коли знають, що за ними стежать або вони знаходяться під тиском. Це ще називають Хоторнським ефектом. За можливості, метрики краще не прив’язувати до певної ролі/фахівця та робити їх анонімними.
👉 Метрики мають порівнювати результати певної команди протягом визначеного періоду, а не різні команди. Так само не варто порівнювати прогрес членів однієї команди одне з одним.
👉 Занадто багато уваги до процесу оцінювання може призвести до того, що люди будуть намагатися «перехитрити систему».
Тому, розробляючи систему метрик, враховуйте, що ваша задача – виявити помилки у рішеннях та підходах з метою підвищення ефективності команди. Не фокусуйтеся на певних членах команди й оцінюйте результат спільної роботи.
А в наступному дописі підкинемо вам ідей, з якими показниками це можна робити.
👍2🔥2👏1🤔1
Метрики в DevOps не завжди використовуються однаково – все залежить від контексту. Показники, які вимірюються, можуть вказати на помилки, слабкі сторони або попередити від застосування низькоефективних рішень.
Підготували для вас чек-ліст метрик, які допоможуть оцінити результат роботи команди. Ловіть першу порцію.
⏳Cycle time (Тривалість циклу). Важливий показник, який оцінює середній час між виникненням ідеї реалізувати фічу до моменту виходу її в продакшн.
🕘 Uptime (Час роботи застосунку). Процент часу, коли застосунок є доступним і працює. Вкрай важлива метрика, яка впливає на кількість клієнтів, що втрачаються через недоступність застосунку.
🤌 Quality (Якість). Цей показник залежить від того, що вкладає в нього кожна окрема команда. Він може відображати відповідність ПЗ стандартам, високий рівень безпеки або рівень задоволення користувача.
🗣 Customer feedback (Зворотний зв’язок користувача). Зворотний зв’язок може оцінюватися кількістю відкритих тікетів, згадок у соцмережах, оцінки продукту в опитуваннях та дослідженнях тощо.
👍 Employee satisfaction (Задоволення співробітників). Задоволеним має бути не тільки користувач, але й люди, які працюють над продуктом: розробники, тестувальники, бізнес-аналітики, продакт-менеджери тощо. Найкращі ідеї генеруються впевненими, позитивними та задоволеними життям людьми.
А в наступному дописі опублікуємо показники, які оцінюють роботу CI/CD-пайплайну. Не пропустіть!
Підготували для вас чек-ліст метрик, які допоможуть оцінити результат роботи команди. Ловіть першу порцію.
⏳Cycle time (Тривалість циклу). Важливий показник, який оцінює середній час між виникненням ідеї реалізувати фічу до моменту виходу її в продакшн.
🕘 Uptime (Час роботи застосунку). Процент часу, коли застосунок є доступним і працює. Вкрай важлива метрика, яка впливає на кількість клієнтів, що втрачаються через недоступність застосунку.
🤌 Quality (Якість). Цей показник залежить від того, що вкладає в нього кожна окрема команда. Він може відображати відповідність ПЗ стандартам, високий рівень безпеки або рівень задоволення користувача.
🗣 Customer feedback (Зворотний зв’язок користувача). Зворотний зв’язок може оцінюватися кількістю відкритих тікетів, згадок у соцмережах, оцінки продукту в опитуваннях та дослідженнях тощо.
👍 Employee satisfaction (Задоволення співробітників). Задоволеним має бути не тільки користувач, але й люди, які працюють над продуктом: розробники, тестувальники, бізнес-аналітики, продакт-менеджери тощо. Найкращі ідеї генеруються впевненими, позитивними та задоволеними життям людьми.
А в наступному дописі опублікуємо показники, які оцінюють роботу CI/CD-пайплайну. Не пропустіть!
👍4❤1🔥1
👀 Продовжуємо розбиратися, які ж метрики варто застосовувати в оцінці роботи 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 системою впродовж певного часу.
Метрики – важливі показники вашого проєкту. Поганий показник – це тільки симптом, а не хвороба
Тож трекайте, вживайте превентивних заходів та слідкуйте за прогресом регулярно 🚀
🔄 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 системою впродовж певного часу.
Метрики – важливі показники вашого проєкту. Поганий показник – це тільки симптом, а не хвороба
Тож трекайте, вживайте превентивних заходів та слідкуйте за прогресом регулярно 🚀
👍3🔥1
🤌 Robusta KRR (Kubernetes Resource Recommender) – CLI-інструмент для оптимізації розміщення ресурсів у кластерах Kubernetes. Тула збирає дані про використанння подів із Prometheus та пропонує ліміти для центрального процесора й пам’яті. Таким чином, Robusta KRR допомагає зменшити витрати й оптимізувати перформанс.
👍2
Leaky Vessels: Docker and runc container breakout vulnerabilities (January 2024) ⚡️
Рорі Макнамара, фахівець з безпеки Snyk Security Labs, розказує про «Діряві судини» – чотири вразливості Docker в основних компонентах контейнерної інфраструктури. Ці недосконалості можуть бути використані зловмисниками для неавторизованого доступу з усіма витікаючими наслідками.
Як тільки команда Snyk Security Labs перевірила та підтвердила ці вразливості, вона ініціювала процес офіційного повідомлення Docker про ці баги.
У статті можна дізнатися як Snyk шукали та підтверджували вразливості, а також таймлайн процесу їх розкриття.
Рорі Макнамара, фахівець з безпеки Snyk Security Labs, розказує про «Діряві судини» – чотири вразливості Docker в основних компонентах контейнерної інфраструктури. Ці недосконалості можуть бути використані зловмисниками для неавторизованого доступу з усіма витікаючими наслідками.
Як тільки команда Snyk Security Labs перевірила та підтвердила ці вразливості, вона ініціювала процес офіційного повідомлення Docker про ці баги.
У статті можна дізнатися як Snyk шукали та підтверджували вразливості, а також таймлайн процесу їх розкриття.
Стаття варта уваги всіх, хто ретельно дбає про безпеку своїх DevOps-інструментів та полюбляє детективні історії пошуку багів та вразливостей.
Snyk Labs
Leaky Vessels: Docker and runc Container Breakout Vulnerabilities - January 2024 | Snyk Labs
Snyk Security Labs Team has identified four container breakout vulnerabilities in core container infrastructure components including Docker and runc, which also impacts Kubernetes.
👍3👏1