Привет, Морти.
Ты написал сервис. Протестировал. Задеплоил. Даже мониторинг поставил.
«Всё работает!» — думаешь ты, потирая руки.
Но на самом деле твой продакшен — как дом из спичек на краю вулкана.
Всё «работает», пока никто не чихнёт.
Вот 5 признаков, что ты играл в DevOps, а не занимался им:
🔥 Признак 1: «У нас есть логи» → но их никто не читает
Да, у тебя stdout в stdout, stderr в stderr, и всё уходит в Loki/ELK/Grafana.
Но когда последний раз ты смотрел логи до того, как что-то сломалось?
Если только после инцидента — ты не мониторишь систему.
Ты реагируешь на пожары.
Настоящий DevOps/SRE — читает логи профилактически.
Он ищет паттерны:«Зачем этот сервис каждую минуту логирует “Connected to DB” в INFO?»
«Почему 5% запросов к API заканчиваются 400-й ошибкой с пустым body?»
Что делать:
- Настрой лог-аналитику (например, в Grafana Loki: rate({job="api"} | json | status_code="400"[5m]) > 10)
- Создай алерты на аномалии в логах, а не только на метрики.
- Включи структурированные логи (JSON) — иначе ты просто копаешь в мусоре.
🔥 Признак 2: «Деплой — одна кнопка» → но откат — неделя боли
Ты гордишься, что деплоишься через GitLab CI одной кнопкой.
Но когда ты в последний раз откатывался?
Если:
- тебе нужно вручную менять теги в манифестах,
- или восстанавливать базу из 12-часового бэкапа,
- или искать в Notion, как вернуть старую версию конфига —
→ у тебя нет CI/CD. У тебя односторонняя дорога в ад.
Надёжный деплой = надёжный откат.
Если откат занимает больше 5 минут — ты не готов к продакшену.
Что делать:
- Используй GitOps (FluxCD, ArgoCD): состояние кластера — в Git. Откат = git revert.
- Храни версии конфигов и манифестов вместе с кодом.
- Проводи регулярные учения по откату — как пожарные тренировки.
🔥 Признак 3: «У нас есть алерты» → но они кричат о ерунде
Ты настроил алерты:
- CPU > 90% → кричит,
- Disk > 80% → кричит,
- Pod restarted → кричит.
Но когда упало API — алертов не было.
Почему? Потому что ты мониторишь инфраструктуру, а не пользовательский опыт.
SRE 101: мониторь то, что чувствует пользователь.
Не «сколько ядер занято», а: Latency (p95 > 1s?)
Error rate (5xx > 0.1%?)
Throughput (резкий спад = что-то сломалось?)
Что делать:
- Внедри SLO (Service Level Objective). Например:
«99% запросов должны отвечать за <500 мс» - Ставь алерты на нарушение SLO, а не на «сервер горячий».
- Используй burn rate — чтобы алерт приходил до того, как ты исчерпал бюджет ошибок.
🔥 Признак 4: «Всё в контейнерах» → но секреты — в .env на сервере
Ты гордишься, что всё в Docker, Kubernetes, Helm…
Но в values.yaml лежит DB_PASSWORD: supersecret123.
Или хуже — в Dockerfile:
dockerfile1
Это не DevOps. Это приглашение для хакера с чеком на $1000 за уязвимость.
Что делать:
- Секреты — только через vault (HashiCorp Vault, AWS Secrets Manager) или K8s Secrets + RBAC.
- Никогда — никогда! — не коммить секреты в Git.
- Используй git-secrets или pre-commit hooks для сканирования.
Проверь сейчас:
bash1
Если что-то нашлось — беги чистить историю.
🔥 Признак 5: «Тесты проходят» → но они не проверяют реальность
У тебя 95% coverage. Все тесты зелёные.
Но после деплоя — 50% пользователей видят 500-ю ошибку.
Почему? Потому что твои тесты:
- запускаются в изолированной среде,
- не проверяют внешние зависимости (API, БД, кэш),
- и не эмулируют реальный трафик.
Тесты должны ломаться до продакшена, а не после.
Что делать:
- Внедри contract testing (Pact) для микросервисов.
- Запускай интеграционные тесты в staging, максимально похожем на прод.
- Добавь chaos engineering lite: случайно убивай поды в staging — живёт ли система?
💡 Заключение: продакшен — это не «где работает», а «где выживает»
Если твой сервис требует постоянного присмотра — он не готов.
Если только ты знаешь, как его починить — он не готов.
Если ты боишься деплоить в пятницу — он не готов.
Настоящий продакшен — это когда ты уезжаешь в отпуск на 2 недели, а система сама:
- перезапускает упавшие сервисы,
- масштабируется под нагрузку,
- предупреждает о проблемах до падения,
- и откатывается, если что-то пошло не так.
Хочешь чек-лист “Готов ли твой сервис к продакшену?” — с 20 пунктами, проверенными в реальных инцидентах?
Если вам понравилось — почитайте про Кубер. Удачи)
→ Забирай в ТГ @devvvops_bot. Там нет воды — только то, что спасает карьеру.
#DevOps #SRE #Продакшен #Надёжность #Инфраструктура #Мониторинг #CI_CD #Безопасность #DevvvOps