https://github.com/bregman-arie/devops-exercises
#DevOps #SRE
@DevOPSitsec
Please open Telegram to view this post
VIEW IN TELEGRAM
👍19❤2🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
🤖 Opsmate — AI-помощник для SRE и DevOps
Opsmate — это открытый AI-инструмент, созданный для автоматизации и упрощения задач SRE и DevOps. Он предоставляет интерфейс на естественном языке для управления инфраструктурой, устранения неполадок и анализа производительности.
🔧 Что умеет:
• 📝 Интерфейс на естественном языке — управляй инфраструктурой как через чат
• 🎓 Поддержка LLM — OpenAI, Anthropic, xAI
• 🛠️ Локальные, Docker, K8s, SSH
• 📈 Интеграция с Prometheus, контекстные дашборды
• GitHub
#SRE #DevOps #AItools #LLMops
Opsmate — это открытый AI-инструмент, созданный для автоматизации и упрощения задач SRE и DevOps. Он предоставляет интерфейс на естественном языке для управления инфраструктурой, устранения неполадок и анализа производительности.
🔧 Что умеет:
• 📝 Интерфейс на естественном языке — управляй инфраструктурой как через чат
• 🎓 Поддержка LLM — OpenAI, Anthropic, xAI
• 🛠️ Локальные, Docker, K8s, SSH
• 📈 Интеграция с Prometheus, контекстные дашборды
• GitHub
#SRE #DevOps #AItools #LLMops
👍6❤1🔥1
🧩 DevOps-задача с подвохом: всё работает, но тормозит
У вас в Kubernetes кластере работает микросервис
- ✅ нет ошибок 5xx
- ✅ логи чистые
- ✅ CPU и RAM в норме
- ✅ Pod'ы не рестартятся
- ✅ HPA не срабатывает
Но пользователи жалуются: ⚠️ заказы проходят с задержкой до 1.5 сек.
🔍 Что под капотом:
- 3 реплики
- Зависимость:
- Один из `orders`-подов иногда теряет сетевое соединение на ~30 сек
- Readiness-проба —
- HPA срабатывает только по CPU > 80%
- Есть метрика
🎯 Что происходит?
Kubernetes считает проблемный под "живым", потому что
Но этот под не может достучаться до
Часть трафика уходит в никуда и тормозит.
CPU низкий, ошибок нет — HPA не срабатывает.
Проблема остаётся невидимой, пока пользователи страдают.
✅ Как починить:
1. ✂️ **Проверять зависимости в Readiness:**
```yaml
readinessProbe:
exec:
command: ["sh", "-c", "curl -sf https://inventory/healthz || exit 1"]
```
2. 📈 **Добавить алерты на latency, queue size и gRPC ошибки**
3. ⚖️ **Настроить HPA по бизнес-метрикам:**
```yaml
type: External
metric:
name: queue_size
```
4. 🧬 **Добавить 2+ реплики в `inventory`** — избавляемся от SPOF
5. 🧠 **Включить tracing (например, Jaeger)** для отслеживания зависаний
💡 **Урок:** Даже без ошибок система может работать нестабильно.
DevOps-инженер должен уметь **видеть деградацию до того, как её заметит пользователь.**
#DevOps #Kubernetes #SRE #Monitoring #CI_CD #HPA
У вас в Kubernetes кластере работает микросервис
orders
. Всё "зелёное":- ✅ нет ошибок 5xx
- ✅ логи чистые
- ✅ CPU и RAM в норме
- ✅ Pod'ы не рестартятся
- ✅ HPA не срабатывает
Но пользователи жалуются: ⚠️ заказы проходят с задержкой до 1.5 сек.
🔍 Что под капотом:
- 3 реплики
orders
- Зависимость:
inventory
(всего 1 реплика) - Один из `orders`-подов иногда теряет сетевое соединение на ~30 сек
- Readiness-проба —
/healthz
, всегда 200 OK - HPA срабатывает только по CPU > 80%
- Есть метрика
queue_size
, но она нигде не используется 🎯 Что происходит?
Kubernetes считает проблемный под "живым", потому что
/healthz
отвечает. Но этот под не может достучаться до
inventory
. Часть трафика уходит в никуда и тормозит.
CPU низкий, ошибок нет — HPA не срабатывает.
Проблема остаётся невидимой, пока пользователи страдают.
✅ Как починить:
```yaml
readinessProbe:
exec:
command: ["sh", "-c", "curl -sf https://inventory/healthz || exit 1"]
```
2. 📈 **Добавить алерты на latency, queue size и gRPC ошибки**
3. ⚖️ **Настроить HPA по бизнес-метрикам:**
```yaml
type: External
metric:
name: queue_size
```
4. 🧬 **Добавить 2+ реплики в `inventory`** — избавляемся от SPOF
5. 🧠 **Включить tracing (например, Jaeger)** для отслеживания зависаний
💡 **Урок:** Даже без ошибок система может работать нестабильно.
DevOps-инженер должен уметь **видеть деградацию до того, как её заметит пользователь.**
#DevOps #Kubernetes #SRE #Monitoring #CI_CD #HPA
👍10❤8