​​💥 Етеншн! Просто зараз у ZONE300 відкрита цікава вакансія Senior Storage Engineer.

Завдання на цій позиції:
🔹 Створювати розподілене сховище з нуля, включаючи планування апаратних ресурсів і вимог до мережі (у співпраці з командою NetOps).
🔹 Обслуговувати та моніторити сервери та пристрої зберігання.
🔹 Створювати сценарії для автоматизації завдань, пов’язаних із зберіганням і обслуговуванням.
🔹 Планувати розвиток клієнтської інфраструктури.
🔹 Створювати й підтримувати плани резервного копіювання та процедур аварійного відновлення.
🔹 Створювати та оновлювати документацію.

Деякі з необхідних скілів на позицію
🔸 Досвід з high-load системами зберігання даних (проєктування, розгортання, налаштування, оцінка продуктивності, аварійне відновлення, моніторинг).
🔸 5+ років досвіду адміністрування Linux / Unix.
🔸 Навички роботи з розподіленими системами зберігання (SDS) і мережевими файловими системами (linstor / DRBD, ceph, gluster, minIO, NFS, StorPool, Nutanix тощо).
🔸 Досвід роботи з ZFS, BTRFS або будь-якою файловою системою Copy-on-Write (CoW).

Пропонуємо поміркувати над впливом генеративного штучного інтелекту на Low-Code/No-Code розробку 🤔

👉 Generative AI можна використовувати для автоматизації багатьох завдань, пов’язаних із розробкою програмного забезпечення: генерація коду, створення інтерфейсів користувача, тестування програм тощо. А інтеграція генеративного ШІ з платформами LCNC може зробити розробку ПЗ ще більш доступною для ширшого кола користувачів, зокрема для нетехнічних. Таким чином, розробники можуть зосередитись на більш складних і стратегічних завданнях.
Ба більше, Low-Code/No-Code разом із Artificial Inteligence відкривають безмежні можливості для виплескування креативу користувачів та вираження їхніх ідей, навіть якщо вони не мають відповідного досвіду в розробці чи дизайні.

👉 Але як у випадках з будь-якою новою технологією постає питання конфіденційності й безпеки даних. І тут треба помислити, як знайти той самий баланс між ефективністю та сек’юрністю. Як зробити так, щоб можливі помилки ШІ не коштували користувачеві втрати або витоку даних? Це питання наразі досить актуальне серед інженерів, які працюють зі штучним інтелектом.

👉 Другий нюанс: серед розробників є суттєві побоювання, що ШІ разом з LCNC замінить їх та їхні послуги. Хоча багато корпорацій та бізнесів обережно вводять AI-технології та Low-Code/No-Code підхід і продовжують покладатися на людський ресурс.

🗺 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-фахівцям.