Cellular architecture останніми роками стала досить популярною серед компаній, які працюють з масштабними онлайн сервісами. Такий тип архітектури націлений суттєво зменшити радіус впливу багів на сервіс. Деякі компанії починають перехід на архітектуру сот саме з сервісів, які безпосередньо впливають на прямий контакт з кінцевим користувачем.
У статті маємо цікавий прикладний кейс переходу від моноліту на cell-based architecture від Slack. Перехід зайняв півтора року, а деталі описані у серії статей на сайті проєкту.
Гоу розбиратися!
У статті маємо цікавий прикладний кейс переходу від моноліту на cell-based architecture від Slack. Перехід зайняв півтора року, а деталі описані у серії статей на сайті проєкту.
Гоу розбиратися!
Engineering at Slack
Slack's Migration to a Cellular Architecture - Engineering at Slack
Summary In recent years, cellular architectures have become increasingly popular for large online services as a way to increase redundancy and limit the blast radius of site failures. In pursuit of these goals, we have migrated the most critical user-facing…
👍3
🤩 libvirt-k8s-provisioner
Ніколи не буде зайвим покласти до робочої скарбнички ще один інструмент Kubernetes. Ділимося тулом, який за лічені хвилини допоможе побудувати робоче середовище кластеру будь-якою необхідною кількістю нод.
Ніколи не буде зайвим покласти до робочої скарбнички ще один інструмент Kubernetes. Ділимося тулом, який за лічені хвилини допоможе побудувати робоче середовище кластеру будь-якою необхідною кількістю нод.
👍1🔥1
Якщо ви DevOps, Tools Engineer або працюєте з Platform Team, вам знайомо, що команди можуть бути різними не тільки за накопиченим досвідом, а й за рівнем «інженерної зрілости». Наприклад, у компанії Big Tech виділяють такі рівні:
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.
Враховуючи різні рівні зрілості, побудова платформи або інструментарію в команді може проходити за геть різними підходами. Але щоб зробити роботу ефективною в будь-якій команді, слідуйте короткому чеклісту (та не обмежуйтесь ним, бо це тільки загальні рекомендації).
👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.
👉 Забезпечте легкий шлях. Методи й підходи мають бути простими та зрозумілими для всіх. Якщо сеньйорна команда дасть вам швидку ефективну реакцію, то «токсики» спробують знайти підводне каміння й виразити супротив. Тож ваше рішення не має залишати їм такого шансу.
👉 Запропонуйте кастомізацію. Зазвичай команди хочуть враховувати власні потреби при реалізації будь-яких нових рішень. У ролі лідера/керівника ви маєте дати їм таку можливість та не блокувати здорові побажання.
👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.
👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.
👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.
Підсумуємо: будуючи сервісні платформи/інструментарій у команді, робіть речі простими, доступними та зрозумілими. Мінімізуйте ієрархію узгоджень і максимально впевнено просувайте саме ваші рішення 🚀
🤓 The stable senior team;
🌟 The newly formed team;
👶 The junior team;
😮💨 The overworked team;
☠️ The toxic team;
🤯 «The manager’s about to be fired» team.
Враховуючи різні рівні зрілості, побудова платформи або інструментарію в команді може проходити за геть різними підходами. Але щоб зробити роботу ефективною в будь-якій команді, слідуйте короткому чеклісту (та не обмежуйтесь ним, бо це тільки загальні рекомендації).
👉 Ставте реальні цілі. Заплануйте реалізацію 80% кейсів, бо зазвичай 15% проходять повз, а 5-ти відсоткам взагалі не судилося втілитися в життя.
👉 Забезпечте легкий шлях. Методи й підходи мають бути простими та зрозумілими для всіх. Якщо сеньйорна команда дасть вам швидку ефективну реакцію, то «токсики» спробують знайти підводне каміння й виразити супротив. Тож ваше рішення не має залишати їм такого шансу.
👉 Запропонуйте кастомізацію. Зазвичай команди хочуть враховувати власні потреби при реалізації будь-яких нових рішень. У ролі лідера/керівника ви маєте дати їм таку можливість та не блокувати здорові побажання.
👉 Майте опції. Навіть якщо ви на 100% впевнені у дефолтних рішеннях і конфігураціях, бажано завжди мати альтернативні варіанти, думки й рекомендації.
👉 Не ускладнюйте. Якщо, наприклад, працюєте з інструментом API, працюйте з ним як з API, не вигадуючи колесо.
👉 Доводьте цінність своїх рішень. Команда має відчути, що саме ваше рішення чи інструмент суттєво перевершує альтернативні варіанти. Так ви отримаєте більше підтримки.
Підсумуємо: будуючи сервісні платформи/інструментарій у команді, робіть речі простими, доступними та зрозумілими. Мінімізуйте ієрархію узгоджень і максимально впевнено просувайте саме ваші рішення 🚀
👍2💯1
Ми всі в курсі, що логи – то наша надійна база, на якій тримаються системи моніторингу та поведінки сервісів. В ідеальному світі на основі логів можна побудувати систему, яка вправно працює та допоможе приймати правильні рішення. Але у неідеальному світі ми стикаємося із лєгасі, різноманітними мовами та фреймворками в одному проєкті, і кожний елемент має свою структуру та підхід до логування.
У своєму блозі Алвін Лі розбирає процеси створення логів, виклики та рішення для масштабних систем і стратегічні підходи до процесів логування.
У своєму блозі Алвін Лі розбирає процеси створення логів, виклики та рішення для масштабних систем і стратегічні підходи до процесів логування.
Hackernoon
How to Extract the Maximum Value From Logs | HackerNoon
Logging for observability across languages, frameworks, and packages is challenging. A thoughtful approach to log design, metrics, and retention will help.
👍5
💥 Pixi – інструмент керування пакетами для розробників. Дає можливість легко встановлювати бібліотеки та застосунки. Працює на Windows, Mac і Linux.
👍5
Управління командою SRE вимагає побудови певної системи, в якій ви співпрацюєте як з командою, так і замовниками. У замовників різні потреби й дедлайни, у команди – виклики й рішення. Щоб гармонійно й ефективно управляти цими процесами, автор статті виділяє кілька SRE Engagement Models: Consulting, Embedded, Infra Team. Детальний розбір підходів у статті 🤓
Substack
SRE Engagement Models
(Cross-posted from certomodo.io)
👍2🔥2
🤓 Чекліст SRE: Хард скілз 🤓
Чеклісти ніколи не бувають зайвими, особливо якщо ви в постійному професійному розвитку та цікавитесь новими ролями. Підготували для вас кілька чеклістів для SRE, але щоб не розгубитися, викатувати будемо релізами, тобто партіями, тобто постами…ну ви зрозуміли :))))
Сьогодні розбираємо hard skills.
👉 Програмування. Не має принципового значення якою мовою, але ви маєте вміти писати (й читати) код. Якщо сумніваєтесь, обирайте Python – оптимально для бази.
👉 Моніторинг. Критична навичка, бо відстеження метрик для забезпечення надійності та стабільності систем – це основа основ SRE.
👉 CI/CD (Continuous Integration/Continuous Delivery). Сьогодні це невіднятна частина будь-якого процесу розробки, що охоплює як безпосередньо саму розробку, так і автоматизацію всього життєвого циклу ПЗ.
👉 IaC (Infrastructure as Code) і CM (Configuration Management). Допомагають автоматизувати як створення коду, так і управління інфраструктурою (й суттєво полегшують життя SRE-інженера).
👌 Опціонально: Containers, Kubernetes, Cloud, Virtualization. Ці напрями не є жорстким мастхевом, але безперечно вони розширюють вашу професійну впевненість і відкривають більше можливостей у роботі.
Що б ви додали до цього чекліста з власного досвіду? Напишіть у коментарях.
Чеклісти ніколи не бувають зайвими, особливо якщо ви в постійному професійному розвитку та цікавитесь новими ролями. Підготували для вас кілька чеклістів для SRE, але щоб не розгубитися, викатувати будемо релізами, тобто партіями, тобто постами…ну ви зрозуміли :))))
Сьогодні розбираємо hard skills.
👉 Програмування. Не має принципового значення якою мовою, але ви маєте вміти писати (й читати) код. Якщо сумніваєтесь, обирайте Python – оптимально для бази.
👉 Моніторинг. Критична навичка, бо відстеження метрик для забезпечення надійності та стабільності систем – це основа основ SRE.
👉 CI/CD (Continuous Integration/Continuous Delivery). Сьогодні це невіднятна частина будь-якого процесу розробки, що охоплює як безпосередньо саму розробку, так і автоматизацію всього життєвого циклу ПЗ.
👉 IaC (Infrastructure as Code) і CM (Configuration Management). Допомагають автоматизувати як створення коду, так і управління інфраструктурою (й суттєво полегшують життя SRE-інженера).
👌 Опціонально: Containers, Kubernetes, Cloud, Virtualization. Ці напрями не є жорстким мастхевом, але безперечно вони розширюють вашу професійну впевненість і відкривають більше можливостей у роботі.
Що б ви додали до цього чекліста з власного досвіду? Напишіть у коментарях.
👍5🤔2🔥1
🤩 acme-dns 🤩
Спрощений DNS-сервер з RESTful HTTP API для простої автоматизації задач ACME DNS.
Спрощений DNS-сервер з RESTful HTTP API для простої автоматизації задач ACME DNS.
👍3🔥3
👀 Якщо ви мали проблему з деплоєм модулів Terraform у різних регіонах AWS, цей практичний кейс для вас. З кодом та поясненнями – все як ми любимо!
Medium
Automated deployment of terraform modules in different AWS regions
If you have created terraform modules and want to deploy them in different AWS regions then this is the right place.
❤6👏1
💥 tfvar
Генератор зразків variable definitions у Terraform. Застосунок сканує конфігурації або модулі та витягує перемінні у необхідному для вас форматі.
Генератор зразків variable definitions у Terraform. Застосунок сканує конфігурації або модулі та витягує перемінні у необхідному для вас форматі.
🔥5👍2
👀 Розбираємось із підходом config-driven import в Google Cloud. Окрім теорії в статті є кейс налаштування автоматичних сповіщень через Terraform.
Medium
Automating alert 🚨 creation with Terraform config-driven import in Google Cloud ☁️
Hello everyone! 👋 In this blog, I will guide you through the concept of Terraform config-driven import.
👍2👏1
Цікаво, якщо серед вас є тім-лідери, як у вас зі впорядкованістю беклогів?
Anonymous Poll
29%
Ретельно очищую перед початком кожного спринта
12%
Розкидую задачі на колег, не глядячи
59%
Боюся навіть відкривати цю скриню Пандори
🤔4
💥 Етеншн! Просто зараз у 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).
Завдання на цій позиції:
🔹 Створювати розподілене сховище з нуля, включаючи планування апаратних ресурсів і вимог до мережі (у співпраці з командою NetOps).
🔹 Обслуговувати та моніторити сервери та пристрої зберігання.
🔹 Створювати сценарії для автоматизації завдань, пов’язаних із зберіганням і обслуговуванням.
🔹 Планувати розвиток клієнтської інфраструктури.
🔹 Створювати й підтримувати плани резервного копіювання та процедур аварійного відновлення.
🔹 Створювати та оновлювати документацію.
Деякі з необхідних скілів на позицію
🔸 Досвід з high-load системами зберігання даних (проєктування, розгортання, налаштування, оцінка продуктивності, аварійне відновлення, моніторинг).
🔸 5+ років досвіду адміністрування Linux / Unix.
🔸 Навички роботи з розподіленими системами зберігання (SDS) і мережевими файловими системами (linstor / DRBD, ceph, gluster, minIO, NFS, StorPool, Nutanix тощо).
🔸 Досвід роботи з ZFS, BTRFS або будь-якою файловою системою Copy-on-Write (CoW).
👍3🔥1
Пропонуємо поміркувати над впливом генеративного штучного інтелекту на Low-Code/No-Code розробку 🤔
👉 Generative AI можна використовувати для автоматизації багатьох завдань, пов’язаних із розробкою програмного забезпечення: генерація коду, створення інтерфейсів користувача, тестування програм тощо. А інтеграція генеративного ШІ з платформами LCNC може зробити розробку ПЗ ще більш доступною для ширшого кола користувачів, зокрема для нетехнічних. Таким чином, розробники можуть зосередитись на більш складних і стратегічних завданнях.
Ба більше, Low-Code/No-Code разом із Artificial Inteligence відкривають безмежні можливості для виплескування креативу користувачів та вираження їхніх ідей, навіть якщо вони не мають відповідного досвіду в розробці чи дизайні.
👉 Але як у випадках з будь-якою новою технологією постає питання конфіденційності й безпеки даних. І тут треба помислити, як знайти той самий баланс між ефективністю та сек’юрністю. Як зробити так, щоб можливі помилки ШІ не коштували користувачеві втрати або витоку даних? Це питання наразі досить актуальне серед інженерів, які працюють зі штучним інтелектом.
👉 Другий нюанс: серед розробників є суттєві побоювання, що ШІ разом з LCNC замінить їх та їхні послуги. Хоча багато корпорацій та бізнесів обережно вводять AI-технології та Low-Code/No-Code підхід і продовжують покладатися на людський ресурс.
👉 Generative AI можна використовувати для автоматизації багатьох завдань, пов’язаних із розробкою програмного забезпечення: генерація коду, створення інтерфейсів користувача, тестування програм тощо. А інтеграція генеративного ШІ з платформами LCNC може зробити розробку ПЗ ще більш доступною для ширшого кола користувачів, зокрема для нетехнічних. Таким чином, розробники можуть зосередитись на більш складних і стратегічних завданнях.
Ба більше, Low-Code/No-Code разом із Artificial Inteligence відкривають безмежні можливості для виплескування креативу користувачів та вираження їхніх ідей, навіть якщо вони не мають відповідного досвіду в розробці чи дизайні.
👉 Але як у випадках з будь-якою новою технологією постає питання конфіденційності й безпеки даних. І тут треба помислити, як знайти той самий баланс між ефективністю та сек’юрністю. Як зробити так, щоб можливі помилки ШІ не коштували користувачеві втрати або витоку даних? Це питання наразі досить актуальне серед інженерів, які працюють зі штучним інтелектом.
👉 Другий нюанс: серед розробників є суттєві побоювання, що ШІ разом з LCNC замінить їх та їхні послуги. Хоча багато корпорацій та бізнесів обережно вводять AI-технології та Low-Code/No-Code підхід і продовжують покладатися на людський ресурс.
👍1🤔1
А що думаєте ви з цього приводу?
Anonymous Poll
40%
З AI та Low-Code/No-Code треба бути обережними. Головне – навчитися працювати з цим.
30%
Обома руками ЗА ці підходи. Вони ж так полегшують рутинну роботу!
30%
Справжнього інженера не замінить ШІ чи LCNC-платформа. Тільки випалені кодом очі, тільки хард-кор!
👍1