Dev // Ops

⭐️⭐️⭐️ Класна стаття про те, як наймати SRE до стартапів та невеликих організацій (і чи варто взагалі).

🔎 netscanner – тул для мережевого сканування. Ось деякі з його фіч: - List HW Interfaces - Switching active Interface for scanning & packet-dumping - WiFi networks scanning - WiFi signals strength (with charts) - (IPv4) Pinging CIDR with hostname, oui & mac address - (IPv4) Packetdump (TCP, UDP, ICMP, ARP) - (IPv6) Packetdump (ICMP6) - start/pause packetdump

🗄 Etcd – це key-value сховище даних, що відрізняється високим рівнем доступності та довготривалістю зберігання даних для розподілених застосунків. Ті, хто використовує Kubernetes, напевне знайомі з etcd. Пропонуємо до прочитання корисну статтю, де розбирають ключові метрики для моніторингу etcd.

І останній SRE-архетип: Архітектор 🧑‍💼 🔸 Бере участь у розробці нових систем, заснованих на NFR (non-functional requirements) для забезпечення надійності, масштабування та безпеки. 🔸 Відстежує поведінку систем та процеси траблшутингу для визначення продуктивності та вузьких місць, а також для покращення коду й архітектури в цілому. 🔸 Оцінює ризики у співпраці з продуктовими командами для чіткого визначення оунерства продукту. Допомагає налаштувати цілі й метрики, які будуть використовуватися як командами, так і стейкхолдерами. 🔸 Розробляє стандарти та допомагає командам переходити на спільні рішення, знижуючи операційні витрати та ризики. 🔸 Виступає в ролі ментора для команд, які хочуть навчитися повного управління своїм продуктом та розвивати SRE-mindset.

🤓 Продовжуємо оглядати SRE-архетипи. Сьогодні наш гість – Інструментальник. 🔸 Часто під цей архетип підлягає напрям Platform Engineering. Завдання інструментальника – зменшити навантаження на продуктові команди у частині інфраструктури, надавши їм відповідні інструменти. Тобто, навчити розробників самостійно усувати проблеми, не звертаючись до SRE. 🔸 Фахівець відповідає за налаштування платформ та сервісів від провайдерів (напр., хмарні сервіси, кластери, контейнеризація тощо), а також інструментів моніторингу інцидентів. 🔸 Спеціаліст впроваджує та реалізує автоматизоване E2E (end-to-end) тестування перед релізом продукту в продакшн. 🔸 Допомагає знижувати ризики помилок під час релізів нових фіч у продукт (напр., сапортить з апдейтом фічі на всіх частинах/службах платформи/застосунку). 🔸 Налаштовує автоматизацію процесів, напр. QA-тести, моніторинг інфраструктури, сповіщення про інциденти тощо.

👩‍🚒 SRE-архетип: Пожежник 👩‍🚒 🔸 Відповідальний за усунення інцидентів та PRR (Product Readiness Roadmap) для команд, які використовують сервіси SRE. 🔸 Допомагає продуктовим командам налаштовувати on-call процеси, інструменти та управляти кодом, за який вони відповідають. 🔸 Займається моніторингом ресурсів (напр., відстежування поведінки об’єктів кластера) для виявлення аномалій, попередження інцидентів та налаштування сповіщень. 🔸 Виконує стандартні операційні задачі (напр., перезапуск застосунків, очищення кешу, усунення проблем з обліковими даними та сертифікатами тощо). На відміну від NetOps, SRE може передбачати такі проблеми та керувати ризиками. Вважається, що «гасіння пожеж» не має бути нормою. Тому значна частина часу SRE-спеціаліста має бути відведена саме на попередження інцидентів та зниження частоти їхнього виникнення.

👨‍💼 SRE-архетип: Адміністратор 👨‍💼 🔸 Відповідає за налаштування та підтримку локальної та хмарної інфраструктури (напр., кластеризація, моніторинг, управління доступами та секретами, мережева топологія тощо). 🔸 Контролює контракти та роботу з провайдерами (Kubernetes, AWS, GitHub, Datadog, Cloudflare тощо). 🔸 Оптимізує використання ресурсів і рентабельність інфраструктури та платформ. 🔸 Володіє навичками роботи з кодом та автоматизацією, переважно за допомогою скриптів та конфігурацій (Infrastructure as a Code).

💥 Термін SRE був впроваджений Google понад 20 років тому, але прижився він не одразу. Лише згодом, коли цифровий гігант запустив сайт і книги, присвячені цьому напряму, ком’юніті почало приймати нову роль. Протягом всіх цих років посада SRE проходила різні стадії й трансформувалася, і сьогодні ми маємо більш-менш чіткий опис SRE-фахівця. Отже, можна виділити 4 архетипи SRE, які найточніше описують цю роль. Але це не означає, що архетипи (і, відповідно, задачі) не можуть перекликатися. У наступних дописах розглянемо всі архетипи детально 👌

💥 Термін SRE був впроваджений Google понад 20 років тому, але прижився він не одразу. Лише згодом, коли цифровий гігант запустив сайт і книги, присвячені цьому напряму, ком’юніті почало приймати нову роль. Протягом всіх цих років посада SRE проходила різні стадії й трансформувалася, і сьогодні ми маємо більш-менш чіткий опис SRE-фахівця. Отже, можна виділити 4 архетипи SRE, які найточніше описують цю роль. Але це не означає, що архетипи (і, відповідно, задачі) не можуть перекликатися. У наступних дописах розглянемо всі архетипи детально 👌

Ansible vs Terraform: Choose One or Use Both? Порівняння двох потужних інструментів DevOps та практичний розбір спроби їх поєднання 💥