🗺 SRE Roadmap 🗺
Забирайте шпаргалку 😉

І так завжди 😅

Готуєтесь стати SRE або покращити свої скіли в цьому напрямі? Тоді цей матеріал для вас – просто must-have.

У блозі Code Reliant виходить серія статей про те, як опанувати Site Reliability Engineering за 6 тижнів. Певний план того, що вчити та практикувати, щоб розвивати свою експертизу в SRE.

Наразі командою випущено вже 3 публікації. Щотижня статті фокусуються на певних знаннях та навичках, наприклад, автоматизація, моніторинг, реагування на інциденти тощо. Автори стверджують, що по закінченню цього 6-тижневого плану ви зможете почуватися впевненим фахівцем на будь-якому інтерв’ю на вакансію SRE.

🤩 croc
Інструмент для обміну файлами. Обираємо файл, надаємо отримувачу спеціальний згенерований код і він за цим кодом завантажує собі потрібний файл.

На цьогорічній конференції HashiConf Global корпорація анонсувала серію інструментів, які суттєво покращать управління інфраструктурою. Багато нових фіч допоможуть в автоматизації процесів DevSecOps.

👉 Наприклад, у Terraform та Terraform Cloud додано тестовий фреймворк, щоб знизити ризики misconfigurations. У бета-версії – інструменти для створення, запуску тестів у інтегрованих модулях Terraform, а також приватний попередній перегляд тулів для забезпечення інфраструктури в масштабі.

👉Також розробники розширили можливості Waypoint на HashiCorp Cloud Platform (HCP). Тепер є більше шляхів для створення застосунків з використанням темплейтів та доданих модулей, а це, зі свого боку, полегшує визначення залежностей.

А ви вже тестили щось з нових фіч? 👀

👀 Стаття про мережі в Kubernetes, а точніше про те, як вони взаємодіють та як управляти їхніми компонентами.

Гайд допоможе створювати мережі та конфігурації для вашого застосунку за допомогою одного компонента – Kube-Proxy.

DevOps прокачує письменницькі скіли ☝️

💡 LightkeeperRM
Тула для віддаленого управління серверами через SSH з використанням shell-команд. Без додаткових демонів чи ПЗ на серверах.

🤓 Нещодавно команда DevOps Research and Assessment (DORA) у Google Cloud опублікувала звіт з цікавими фактами.

Звіт констатує, що у командах з генеративною культурою (ті, що інтегрують штучний інтелект у свої процеси) організаційна ефективність на 30% вища ніж у тих, хто ще не впроваджує у себе генеративну культуру.
Звіт заснований на опитуванні 36 тис. ІТ-фахівців. Він містить оцінку таких даних: частота деплойменту, час внесення змін, частота відмов та час відновлення після невдалого деплойменту.

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

Управління операційними витратами в Kubernetes – тема, яку не слід ігнорувати, адже вона може влетіти в копійочку. Розуміння, за що нараховується оплата та як управляти витратами, є необхідною навичкою для тих, хто працює з цим інструментом. OpenCost був розроблений саме для таких цілей. Ба більше, у поєднанні з VictoriaMetrics (time series database) – це ефективне рішення для відстежування костів.

Пропонуємо детальний гайд з налаштування OpenCost.

⚡️ kptop
CLI для Kubernetes, що надає зручний моніторинг для нод, подів, контейнерів та PVC-ресурсів.

💥 Conventional Commits – зручна шпаргалка для створення повідомлень під час комітів. Це доволі проста специфікація, що містить набір правил, структуру та приклади.

🔧 Helm — інструмент для обміну між материнською та дочірньою діаграмами. Детальний розбір у статті.

Гайд проведення post-mortem мітингу після інциденту 🤓

Як то кажуть, інцидент вирішили, але осад залишився. Навіть якщо ви вчасно розв’язали проблему і користувач не постраждав, бажано провести post-mortem мітинг та проговорити деталі. Звісно, не для того, щоб знайти винного, а для того, щоб попередити подібне в майбутньому. Підготували для вас коротенький гайд для цього.

💥 Основні правила:
- Не шукаємо винного і встановлюємо нейтральний тон спілкування.
- Фіксуємо всі факти й думки.
- Вчимося на помилках та виносимо з них досвід.

👌Чек-ліст:
- Зберіть всіх, хто залучений до інциденту, та ключових стейкхолдерів, що приймають рішення в цьому напрямі.
- Встановіть чітку адженду: тема та цілі зустрічі.
- Зробіть повноцінне рев’ю: таймлайн, вплив на проєкт/компанію, зроблені кроки для розв’язання інциденту тощо.
- Заохочуйте дискусію, аналізуйте різні думки та робіть висновки на майбутнє.
- Проаналізуйте суміжні фактори, які могли вплинути на інцидент: прогалини в бізнес-процесах, людський фактор, технічні недосконалості системи тощо.
- Зафіксуйте результати та best-practices, що винесли з інциденту.
- Пропишіть follow-up зустрічі та домовтеся з командою-оунером про подальші дії.

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

Ви можете створити свій власний шлях post-mortem мітингів, бо жорстких правил тут немає. Головне – аналізувати та робити висновки після кожного інциденту, адже в майбутньому це зекономить ваші нерви і гроші бізнесу 👌

Мікросервіси – прикольна сучасна штука, але далеко не дешева. Тож якщо ваша команда чи компанія замислюється над переходом на мікросервісну архітектуру, варто ретельно порахувати витрати.

Стаття Роберто Вітілло, розробника, техліда та менеджера з десятирічним досвідом, може вам у цьому допомогти. Принаймні, допоможе зрозуміти від чого залежить вартість мікросервісів та що варто врахувати.

✔️ vault-secrets-operator
Інструмент, що допомагає створювати Kubernetes-секрети з Vault. В основі лежить ідея безпечного управління секретами як у GitOps.

🤓 «Хто сьогодні черговий?» – фраза, яка навіює спогади зі шкільних років? Тільки якщо ви не айтівець, який живе своє доросле життя в технологічній компанії 🤪

Чергування – необхідна практика, якщо ваша компанія підтримує сервіси цілодобово або має критичну інфраструктуру, де будь-який інцидент має бути вирішено протягом 24 годин.

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

Майкл Харт у своєму блозі на Medium поглиблюється у цю проблему і пропонує можливі рішення, як на рівні спеціаліста, так і командному. Досить цікава тема, яка може відгукнутися багатьом SRE, DevOps і TechOps-фахівцям.

🏆 Метрики успіху 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.

terraform-local 🤝
Інструмент для Terraform CLI, який допоможе напряму́ деплоїти застосунки із Terraform до LocalStack.