⚡️ kptop
CLI для Kubernetes, що надає зручний моніторинг для нод, подів, контейнерів та PVC-ресурсів.
CLI для Kubernetes, що надає зручний моніторинг для нод, подів, контейнерів та PVC-ресурсів.
👍4👏2
💥 Conventional Commits – зручна шпаргалка для створення повідомлень під час комітів. Це доволі проста специфікація, що містить набір правил, структуру та приклади.
👍1🔥1
🔧 Helm — інструмент для обміну між материнською та дочірньою діаграмами. Детальний розбір у статті.
Medium
Helm — Data Sharing Between Parent and Child Chart
Data exchange between parent and child chart in helm
👍3
Гайд проведення post-mortem мітингу після інциденту 🤓
Як то кажуть, інцидент вирішили, але осад залишився. Навіть якщо ви вчасно розв’язали проблему і користувач не постраждав, бажано провести post-mortem мітинг та проговорити деталі. Звісно, не для того, щоб знайти винного, а для того, щоб попередити подібне в майбутньому. Підготували для вас коротенький гайд для цього.
💥 Основні правила:
- Не шукаємо винного і встановлюємо нейтральний тон спілкування.
- Фіксуємо всі факти й думки.
- Вчимося на помилках та виносимо з них досвід.
👌Чек-ліст:
- Зберіть всіх, хто залучений до інциденту, та ключових стейкхолдерів, що приймають рішення в цьому напрямі.
- Встановіть чітку адженду: тема та цілі зустрічі.
- Зробіть повноцінне рев’ю: таймлайн, вплив на проєкт/компанію, зроблені кроки для розв’язання інциденту тощо.
- Заохочуйте дискусію, аналізуйте різні думки та робіть висновки на майбутнє.
- Проаналізуйте суміжні фактори, які могли вплинути на інцидент: прогалини в бізнес-процесах, людський фактор, технічні недосконалості системи тощо.
- Зафіксуйте результати та best-practices, що винесли з інциденту.
- Пропишіть follow-up зустрічі та домовтеся з командою-оунером про подальші дії.
У кожній організації структура та наповнення таких мітингів може відрізнятися. Наприклад, хтось готує документ для аналізу до зустрічі, а інші можуть наповнювати його під час мітингу згідно з наявним шаблоном. Деякі команди-оунери залучають стейкхолдерів вже на початковому етапі, а інші звітують по зробленому аналізу з висновками.
Ви можете створити свій власний шлях post-mortem мітингів, бо жорстких правил тут немає. Головне – аналізувати та робити висновки після кожного інциденту, адже в майбутньому це зекономить ваші нерви і гроші бізнесу 👌
Як то кажуть, інцидент вирішили, але осад залишився. Навіть якщо ви вчасно розв’язали проблему і користувач не постраждав, бажано провести post-mortem мітинг та проговорити деталі. Звісно, не для того, щоб знайти винного, а для того, щоб попередити подібне в майбутньому. Підготували для вас коротенький гайд для цього.
💥 Основні правила:
- Не шукаємо винного і встановлюємо нейтральний тон спілкування.
- Фіксуємо всі факти й думки.
- Вчимося на помилках та виносимо з них досвід.
👌Чек-ліст:
- Зберіть всіх, хто залучений до інциденту, та ключових стейкхолдерів, що приймають рішення в цьому напрямі.
- Встановіть чітку адженду: тема та цілі зустрічі.
- Зробіть повноцінне рев’ю: таймлайн, вплив на проєкт/компанію, зроблені кроки для розв’язання інциденту тощо.
- Заохочуйте дискусію, аналізуйте різні думки та робіть висновки на майбутнє.
- Проаналізуйте суміжні фактори, які могли вплинути на інцидент: прогалини в бізнес-процесах, людський фактор, технічні недосконалості системи тощо.
- Зафіксуйте результати та best-practices, що винесли з інциденту.
- Пропишіть follow-up зустрічі та домовтеся з командою-оунером про подальші дії.
У кожній організації структура та наповнення таких мітингів може відрізнятися. Наприклад, хтось готує документ для аналізу до зустрічі, а інші можуть наповнювати його під час мітингу згідно з наявним шаблоном. Деякі команди-оунери залучають стейкхолдерів вже на початковому етапі, а інші звітують по зробленому аналізу з висновками.
Ви можете створити свій власний шлях post-mortem мітингів, бо жорстких правил тут немає. Головне – аналізувати та робити висновки після кожного інциденту, адже в майбутньому це зекономить ваші нерви і гроші бізнесу 👌
👍5
Мікросервіси – прикольна сучасна штука, але далеко не дешева. Тож якщо ваша команда чи компанія замислюється над переходом на мікросервісну архітектуру, варто ретельно порахувати витрати.
Стаття Роберто Вітілло, розробника, техліда та менеджера з десятирічним досвідом, може вам у цьому допомогти. Принаймні, допоможе зрозуміти від чого залежить вартість мікросервісів та що варто врахувати.
Стаття Роберто Вітілло, розробника, техліда та менеджера з десятирічним досвідом, може вам у цьому допомогти. Принаймні, допоможе зрозуміти від чого залежить вартість мікросервісів та що варто врахувати.
Roberto's blog
The costs of microservices
An application typically starts its life as a monolith. Take a modern backend of a single-page Javascript application, for example - it starts out as a single stateless web service that exposes a RESTful HTTP API and uses a relational database as a backing…
👍6
✔️ vault-secrets-operator
Інструмент, що допомагає створювати Kubernetes-секрети з Vault. В основі лежить ідея безпечного управління секретами як у GitOps.
Інструмент, що допомагає створювати Kubernetes-секрети з Vault. В основі лежить ідея безпечного управління секретами як у GitOps.
👍4
🤓 «Хто сьогодні черговий?» – фраза, яка навіює спогади зі шкільних років? Тільки якщо ви не айтівець, який живе своє доросле життя в технологічній компанії 🤪
Чергування – необхідна практика, якщо ваша компанія підтримує сервіси цілодобово або має критичну інфраструктуру, де будь-який інцидент має бути вирішено протягом 24 годин.
Втім, практика to be on-call має свою частку негативного впливу на фахівців: напруження під час зміни, підвищене відчуття відповідальності, непорозуміння із родиною (робота у свята та важливі сімейні дати) тощо.
Майкл Харт у своєму блозі на Medium поглиблюється у цю проблему і пропонує можливі рішення, як на рівні спеціаліста, так і командному. Досить цікава тема, яка може відгукнутися багатьом SRE, DevOps і TechOps-фахівцям.
Чергування – необхідна практика, якщо ваша компанія підтримує сервіси цілодобово або має критичну інфраструктуру, де будь-який інцидент має бути вирішено протягом 24 годин.
Втім, практика to be on-call має свою частку негативного впливу на фахівців: напруження під час зміни, підвищене відчуття відповідальності, непорозуміння із родиною (робота у свята та важливі сімейні дати) тощо.
Майкл Харт у своєму блозі на Medium поглиблюється у цю проблему і пропонує можливі рішення, як на рівні спеціаліста, так і командному. Досить цікава тема, яка може відгукнутися багатьом SRE, DevOps і TechOps-фахівцям.
Medium
How to be on-call
A few years ago at Arctic Wolf I put together a talk titled “How to be on-call”, in response to the rapid growth of the organization and…
👍5
🏆 Метрики успіху 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