Dev // Ops
400 subscribers
86 photos
133 links
Канал для всіх, хто цікавиться DevOps філософією. Створений на основі досвіду компаній ZONE3000 і Namecheap. Тут ми ділимося корисним контентом і кейсами та відповідаємо на питання. Чекаємо ваші фідбеки, питання та рекомендації тут @educationzone3000
Download Telegram
🤩 Devpod: Improving Developer Productivity at Uber with Remote Development

Розробники Uber діляться, як їм вдалося покращити щоденну роботу edit-build-run розробників за допомогою DevPods, – середовища віддаленої розробки. Команда розповідає про вихідні проблеми, які вони намагалися розв’язати, про архітектуру та нещодавні успіхи зі зниження витрат. Також автори поділилися думками щодо майбутнього віддаленої розробки в Uber.
👍3
👾 Онбординг SRE: проходимо рівні як у комп’ютерній грі.

Ви знайшли ідеального кандидата на роль SRE. Так, знаємо, це нелегко, але you did it! Попереду процес онбордингу (та повнісінький беклог задач), який варто провести лагідно й делікатно, щоб ваш новий тіммейт не пішов, навіть не почавши.

Отже, що важливо:
▫️ ставте робочі задачі по принципу «від простого до складного»;
▫️ не варто у перший день роботи просити нового колегу пофіксити баги, з якими ваша команда не справляється вже довгий період часу;
▫️ дайте час колезі розібратися з тим, що взагалі у вас відбувається 😅

Важливо дати новому SRE можливість прогресувати і поступово виходити на більш складний рівень. Як у комп’ютерній грі – можете сприймати це навіть так. Такий підхід буде надихати колегу до прогресу, а вам дасть час на підготовку нових робочих задач для SRE.

А в наступному дописі ми розкриємо лайфхаки комфортного онбордингу SRE, які полегшать життя менеджера й команди.
👍7
Вічна тема 🤪
🔥4😁2👍1
🤓 5 лайфхаків для онбордингу SRE

Новенький на борту, онбордінг почався, тож робимо все лагідно й делікатно, щоб цінна людина комфортно влилася у колектив (та залишилася з вами надовго)👌

👉 Для junior-SRE давайте мікс із задач «на подумати» та «зробити». Це допоможе новому колезі урізноманітнити воркфлоу та тримати баланс у навантаженні на перших етапах співпраці з командою.

👉 Не ставте нового тіммейта одразу «гасити пожежі». Натомість запропонуйте розібратися у тікетах низької та середньої пріоритетності, надаючи менторську підтримку.

👉 Не варто одразу надавати новим співробітникам повну автономію. Всі члени команди мають бути залучені у хід проєкту та бути в єдиному інформаційному полі.

👉 Ставте колезі невеликі за обсягом задачі, поступово підвищуючи їх складність та обсяг. Давайте регулярний фідбек та оцінку виконаної роботи. Разом проговорюйте складнощі та шляхи їхнього вирішення.

👉 Комбінуйте on-call duties з проактивною роботою. Давайте новому SRE можливість роботи над власними рішеннями з удосконалення роботи системи.

Сподіваємось, наші поради допоможуть вам успішно інтегрувати нового колегу у вашу команду. А якщо маєте що додати до лайфхаків, напишіть у коментарях.
👍4🔥1🤔1🤩1
До речі, а як ви вимовляєте kubectl ? :)))
Anonymous Poll
6%
kube-control
3%
kube-cuttle
91%
kube-cee-tee-ell
🤌 Що ви бачите перед собою? Це скарб! А точніше – серія статей “Terraform Modules: From Development to Deployment on Gitlab” від Vighnesh Prakash.

Ця серія матеріалів буде корисною для розробників, DevOps та всіх, хто цікавиться Terraform і Gitlab. Статті створені за принципом bottom-up: починається серія з хардкорної практики, поступово рухаючись до теоретичної бази. Enjoy!
👍3👏2
Devs, ви знаєте що робити з документаціїю...
😁5💯1
👍3🔥1
Нестандартний підхід Google до SRE 🤔 Цифровий гігант порівнює SRE з кулінарною книгою ресторану з ⭐️⭐️⭐️ зірками Мішлен.

Компанії бажають спробувати готувати за мішленівськими «рецептами», але на їхніх кухнях безлад. Деякі починають будувати для цього сучасну кухню (platform engineering). Певні організації концентруються на закупівлі якісних продуктів (outsourcing). Інші самостійно вирощують продукти та розводять курей (нестандартні рішення на базі open-source інструментів).
Все це – кроки до кінцевої мети (приготування їжі), але це не означає, що кожен з цих процесів можна назвати приготуванням їжі. Ба більше, налаштувавши ці окремі процеси, але не поєднавши їх, ви, врешті реш, нічого не приготуєте.

Ну, ми навіть не знаємо 😅 А ви що думаєте про таку метафору? Поділіться у коментарях.
👍3
🤩 testkube нативно інтегрує оркестрацію та виконання у Kubernetes та CI/CD/GitOps-конвейер.

Ключові переваги:
⚡️ Дозволяє уникнути прив’язки до провайдера при оркестрації та виконанні тестів у CI/CD.
⚡️ Полегшує оркестрацію та запуск будь-якого виду тестів (functional, load/performance, security, compliance та ін.) без «загортання» їх у docker-images.
⚡️ Дозволяє відокремити виконання тестів від процесів збірки.
⚡️ Централізує результати тестів у послідовному форматі для QA-аналітики.
⚡️ Забезпечує модульну архітектуру для додавання нових типів тестів та виконавців.
👍4
Ansible vs Terraform: Choose One or Use Both? Порівняння двох потужних інструментів DevOps та практичний розбір спроби їх поєднання 💥
🔥4👍1
💥 Термін SRE був впроваджений Google понад 20 років тому, але прижився він не одразу. Лише згодом, коли цифровий гігант запустив сайт і книги, присвячені цьому напряму, ком’юніті почало приймати нову роль.

Протягом всіх цих років посада SRE проходила різні стадії й трансформувалася, і сьогодні ми маємо більш-менш чіткий опис SRE-фахівця.

Отже, можна виділити 4 архетипи SRE, які найточніше описують цю роль. Але це не означає, що архетипи (і, відповідно, задачі) не можуть перекликатися.

У наступних дописах розглянемо всі архетипи детально 👌
👍5🔥1
👨‍💼 SRE-архетип: Адміністратор 👨‍💼

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

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

Вважається, що «гасіння пожеж» не має бути нормою. Тому значна частина часу SRE-спеціаліста має бути відведена саме на попередження інцидентів та зниження частоти їхнього виникнення.
👍4👏1
🤓 Продовжуємо оглядати SRE-архетипи. Сьогодні наш гість – Інструментальник.

🔸 Часто під цей архетип підлягає напрям Platform Engineering. Завдання інструментальника – зменшити навантаження на продуктові команди у частині інфраструктури, надавши їм відповідні інструменти. Тобто, навчити розробників самостійно усувати проблеми, не звертаючись до SRE.

🔸 Фахівець відповідає за налаштування платформ та сервісів від провайдерів (напр., хмарні сервіси, кластери, контейнеризація тощо), а також інструментів моніторингу інцидентів.

🔸 Спеціаліст впроваджує та реалізує автоматизоване E2E (end-to-end) тестування перед релізом продукту в продакшн.

🔸 Допомагає знижувати ризики помилок під час релізів нових фіч у продукт (напр., сапортить з апдейтом фічі на всіх частинах/службах платформи/застосунку).

🔸 Налаштовує автоматизацію процесів, напр. QA-тести, моніторинг інфраструктури, сповіщення про інциденти тощо.
👍7🔥1
І останній SRE-архетип: Архітектор 🧑‍💼

🔸 Бере участь у розробці нових систем, заснованих на NFR (non-functional requirements) для забезпечення надійності, масштабування та безпеки.

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

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

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

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

Пропонуємо до прочитання корисну статтю, де розбирають ключові метрики для моніторингу etcd.
👍6
🔎 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
👍4😁1