Как бороться с конфигурационным дрейфом в инфраструктуре?

Конфигурационный дрейф – это скрытый враг стабильности инфраструктуры. Он возникает, когда фактическое состояние системы начинает расходиться с описанным в коде (IaC). Причины могут быть разные: ручные правки, неучтённые обновления, забытые изменения.

🔥 Как выявить и устранить дрейф?

1️⃣ Используйте периодический аудит
• Terraform: terraform plan поможет выявить разницу между текущим состоянием и кодом.
• Ansible: запустите с флагом --check для проверки соответствия.

2️⃣ Внедрите GitOps-подход
• Используйте ArgoCD или Flux для автоматического применения изменений и приведения системы в соответствие с репозиторием.

3️⃣ Логируйте и мониторьте изменения
• AWS Config, HashiCorp Sentinel, Open Policy Agent помогут отслеживать отклонения от желаемого состояния.

4️⃣ Ограничьте ручные изменения
• Доступ только через IaC.
• Обязательное ревью кода через PR в Git.

5️⃣ Автоматизируйте откат
• Автофиксы через CI/CD при обнаружении дрейфа.
• Используйте immutable-инфраструктуру (замена вместо правок).

Конфигурационный дрейф – это не баг, а особенность живой инфраструктуры. Но держать его под контролем можно и нужно!

Подпишись 👉 @devopslib

🔧 Популярные средства оркестрации

1. Kubernetes
- Описание: Де-факто стандарт оркестрации контейнеров.
- Кейсы:
- Микросервисная архитектура.
- Автоматическое масштабирование на основе нагрузки.
- Blue-Green и Canary-развертывания.
- Высокая отказоустойчивость.

2. Docker Swarm
- Описание: Встроенная система оркестрации в Docker.
- Кейсы:
- Простая кластеризация Docker-контейнеров.
- Быстрые POC и MVP без лишней сложности.
- Небольшие команды или проекты.

3. Nomad (от HashiCorp)
- Описание: Легковесная альтернатива Kubernetes, поддерживает разные типы нагрузок (не только контейнеры).
- Кейсы:
- Микс контейнеров, VMs и standalone-приложений.
- Высоконагруженные и распределённые системы.
- Интеграция с Consul и Vault.

4. Apache Mesos / Marathon
- Описание: Платформа для запуска распределённых приложений.
- Кейсы:
- Big Data ворклоады (Hadoop, Spark).
- Оркестрация большого количества различных ресурсов.

5. OpenShift
- Описание: Коммерческая PaaS от Red Hat на базе Kubernetes.
- Кейсы:
- Корпоративные решения с сильной безопасностью и интеграцией.
- Платформа для CICD.
- Разработка в приватных облаках.


Подпишись 👉@devopslib

🛠 Git в проде: 5 команд, которые спасут тебе жизнь

1. git reflog
Забыл, куда ушёл твой коммит после git reset или rebase?
reflog покажет все твои перемещения по репозиторию. Это как история браузера, только для Git.

2. git cherry-pick
Нужно вытащить один нужный коммит из другой ветки?
git cherry-pick <hash> — и он уже у тебя. Удобно, когда прод живёт отдельно.

3. git bisect
Ломаешь голову, когда что-то отвалилось?
git bisect помогает найти коммит, где всё пошло не так. Работает как бинарный поиск.

4. git clean -fdx
Убрать весь мусор, кроме того, что под Git?
Особенно полезно, если после сборки остаётся куча временных файлов.
⚠️ Осторожно: удалит всё незакоммиченное.

5. git worktree
Параллельная работа с несколькими ветками без лишних клонов.
Хочешь протестить фичу и багфикс в одной папке?
git worktree add ../branch-folder branch-name

Подпишись 👉@devopslib

🚀 Почему стоит отказаться от latest в Docker

Кажется удобно: FROM nginx:latest, docker pull redis:latest, но это ловушка. Вот почему:

🔄 Непредсказуемость
Образ с тегом latest может внезапно обновиться. Сегодня он работает, завтра — уже падает из-за изменений, которых ты не ждал.

🔍 Проблемы с отладкой
У тебя что-то ломается в проде. Образ — latest. Как узнать, какая версия реально использовалась? Где искать баг? Непонятно.

📦 Кэш и CI/CD
CI может закешировать один latest, ты локально — другой. Поведение отличается. В проде — третий вариант. Гемор.

🧩 Советы
- Всегда пингуй версии: postgres:14.10, node:20.11.1.
- Используй digest, если нужно железобетонно зафиксировать образ:
nginx@sha256:abc123...
- Храни список используемых версий в Makefile или .env для контроля.

🛡️ Инфраструктура должна быть предсказуемой. latest — враг детерминизма.

Подпишись 👉 @devopslib

🚀 Чеклист для продакшн-сервера на Linux

Проверяешь ли ты каждый новый сервер перед выкатыванием в прод? Вот тебе мини-чеклист, чтобы ничего не забыть:

1. 🔐 Безопасность
- Отключен root-доступ по SSH
- Включен firewall (например, ufw, firewalld)
- Обновлены все пакеты (apt upgrade / yum update)
- Установлены fail2ban / sshguard
- Развернута система логирования (rsyslog, journald + shipping в Loki/ELK)

2. 🛠️ Система
- Настроен NTP / systemd-timesyncd
- hostname прописан в /etc/hosts
- Правильно выставлены лимиты в /etc/security/limits.conf
- swap включен/отключен по требованиям
- Разделение дисков по best practice (/var, /tmp, /home и т.д.)

3. 📈 Мониторинг и алерты
- node_exporter или другой агент установлен
- alertrules настроены
- Логи собираются (Promtail, Filebeat, и т.д.)
- Проверка доступности (blackbox, ICMP, TCP)

4. ⚙️ DevOps ready
- CI/CD агент установлен (GitLab Runner, Jenkins agent, и т.д.)
- SSH ключи от CI добавлены
- Конфиги под контроль версий
- .env файлы спрятаны, secrets — в vault

5. 🧪 Smoke тесты
- Проверка CPU/RAM/Disk через stress-ng
- Проверка открытых портов ss -tuln
- curl и ping до нужных сервисов (внутренних/внешних)

Подпишись 👉 @devopslib

🚀 Зачем DevOps-инженеру уметь читать ядро Linux?

Чтение кода ядра — звучит как занятие для академиков. Но на практике это скилл, который может однажды сэкономить тебе сутки дебага или открыть глаза на то, что происходит "под капотом".

📌 Когда это нужно:
- 🐛 Твой сервис падает на проде с segfault, и strace`/`gdb не дают внятной картины.
- 🔥 Системные лимиты или поведение cgroup'ов не совпадают с документацией.
- ⏱ Ты хочешь точно понять, что делает epoll_wait() или почему OOM killer прибивает твой процесс.

📖 Как начать:
1. Выбери версию ядра, с которой работаешь (uname -r тебе в помощь).
2. Клонируй исходники:

   git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
   cd linux
   git checkout v5.x.x  # нужная версия
   

3. Ищи интересующие syscalls или подсистемы:
- fs/, kernel/, mm/, net/, ipc/ — ключевые директории.
- grep -rn "do_fork" или grep -rn "epoll_wait" — твои друзья.

🧠 Советы:
- Начинай с высокоуровневого понимания — читай документацию kernel.org, LWN.net, статьи от разработчиков.
- Используй cscope, ctags или LSP в редакторе — иначе заблудишься.
- Комментируй код для себя: через неделю забудешь, что понял.

Если ты начнёшь разбираться в ядре — ты уже на пути к тому, чтобы быть не просто DevOps, а системным ниндзя, которому по плечу всё — от тюнинга производительности до траблшутинга на голом железе.

Подпишись 👉 @devopslib

🚀 Твоя система тормозит? А может, просто iowait шалит?

Очень часто мы жалуемся на "тормоза" в Linux, но глядим в top — а CPU загружен всего на 10%. Где подвох? А подвох в iowait.

iowait — это время, которое CPU тратит в ожидании ввода-вывода. То есть процессор мог бы работать, но ждет, пока закончится обращение к диску или сети.

Как диагностировать:

1. Открываем top или htop
Смотрим на строку Cpu(s): — там будет wa (wait):

   %Cpu(s):  5.3 us,  1.0 sy,  0.0 ni, 90.2 id,  3.5 wa, ...
   

2. Проверяем с iostat (из пакета sysstat):

   iostat -xz 1
   

Обрати внимание на await и util.
- await — среднее время ожидания операций I/O (чем выше, тем хуже).
- util — насколько загружен диск (100% = забит под завязку).

3. Используем dstat для наглядности:

   dstat -cdlmn --disk-util
   

Причины высокого iowait:
- Убитые HDD (с долгими seek time)
- Недостаточно RAM → активный swap
- NFS или медленные блочные устройства (ceph, iscsi)
- Базы данных без индексов или с большим кол-вом random I/O

Что делать:
- Проверить SMART у дисков: smartctl -a /dev/sdX
- Убедиться, что swap не используется без нужды: free -h, vmstat 1
- Настроить кэширование или перенести данные на SSD
- Мониторить в динамике: atop, netdata, grafana + node_exporter

🧠 Не забывай: низкая загрузка CPU не всегда значит, что всё хорошо. Иногда система просто ждёт диск.


Подпишись 👉 @devopslib

🧠 Зачем set -e в bash-скриптах — и почему он может вас подставить

Многие пишут в баш-скриптах в начале:

#!/bin/bash
set -e

Типа: пусть скрипт падает при первой ошибке. Звучит здраво. Но есть нюанс.

Вот такой код:

set -e
mkdir /tmp/test || true
echo "Продолжаем..."

Что произойдёт, если /tmp/test уже существует?

👉 mkdir вернёт ошибку, но || true спасёт нас. Скрипт пойдёт дальше.

А теперь так:

set -e
if some_command; then
  echo "OK"
fi

Если some_command завершится с ненулевым кодом — всё, скрипт упадёт до входа в if.

🧨 И таких подводных камней с set -e хватает.

💡 Решение — аккуратнее: либо продуманные конструкции вроде if, ||, &&, либо использовать trap и обрабатывать ошибки осознанно.


Подпишись 👉 @devopslib

🚨 Как быстро вычислить утечку памяти в Linux?

Когда система начинает “подтормаживать” без видимой причины — пора заподозрить утечку памяти. Вот как можно быстро найти виновника.

🔍 1. Проверяем использование памяти:

free -h

Если available стремится к нулю, есть повод копнуть глубже.

🔧 2. Сортируем процессы по потреблению RAM:

ps aux --sort=-%mem | head -n 10

Тут видно, кто больше всех ест память.

🧠 3. Следим за slab-объектами:

cat /proc/meminfo | grep Slab

Если значение растёт со временем — это сигнал утечки в ядре или драйверах.

🧪 4. Используем smem для точной оценки:

smem -r | sort -k 4 -nr | head

smem учитывает shared memory — оценка куда точнее, чем просто ps.

🎯 5. Если подозрение на конкретный процесс:
pmap — покажет, что именно грузит память:

pmap -x <PID>

🔥 Совет:
Запусти htop, нажми F6, выбери колонку RES, отсортируй. Увидишь — кто на самом деле обжора.

Подпишись 👉@devopslib

🧵 Чеклист перед выкладкой инфраструктурного кода в прод

Инфраструктура как код — мощная штука. Но даже один криво закоммиченный main.tf может повалить пол-продакшена. Вот мини-чеклист, который стоит прогонять перед мержем в main.


✅ 1. План применён?
terraform plan или pulumi preview должен быть свежим и понятным. Никаких сюрпризов в духе «удаляется продовая БД».

✅ 2. Есть backend?
Убедись, что состояние хранится не локально. Используй S3, GCS или аналог — иначе в один день ты потеряешь всё.

✅ 3. -target не попал в CI/CD
Временно использовать -target ок, но не коммить это в pipeline. Это костыль, а не стратегия.

✅ 4. Защищён ли state?
Шифрование включено? Доступ только у нужных людей? terraform state show — часто недооценённый источник чувствительных данных.

✅ 5. Модули не обновились «магически»?
Проверь, что версии всех модулей и провайдеров зафиксированы. Плавающие версии — путь к хаосу.

✅ 6. Документация и комментарии есть?
Ты можешь помнить, зачем это поле у S3, но через месяц ты же сам себе не поверишь. Пиши сразу.

✅ 7. Прогонен tflint / checkov / terraform validate?
Линтеры и валидация — это как spellcheck, но для продакшена. Лишними не будут.

✅ 8. Обратная совместимость учтена?
Изменения в ресурсах типа ALB, IAM policy или security group могут незаметно порушить весь трафик.

✅ 9. Всё в Git?
Terraform code без Git — это как сервер без мониторинга. Безответственно.

✅ 10. Apply сначала в staging!
Если у тебя нет stage-среды — ты и есть stage. Надеюсь, у тебя хорошая страховка.


🛠 Ты можешь автоматизировать почти всё из этого списка. Но думать всё равно придётся. Хотя бы пока.


Подпишись 👉@devopslib

🚀 Проверка сетевых подключений с помощью ss

Команда ss — мощный инструмент для диагностики сетевых соединений в Linux. Она быстрее и информативнее старого доброго netstat. Вот несколько фишек, которые стоит знать:

🔸 Все соединения:

ss -tunap

Покажет TCP/UDP соединения, номера портов, PID процесса и имя.

🔸 Слушающие сокеты:

ss -tuln

Флаг -l фильтрует только те сокеты, которые находятся в состоянии LISTEN.

🔸 Фильтрация по порту:

ss -tuln sport = :22

Можно искать соединения по конкретному порту. Например, 22 — SSH.

🔸 Сокеты определённого процесса:

ss -p | grep nginx

Находит все подключения, где участвует nginx.

🔸 Состояния TCP:

ss -tan state established

Показывает только активные установленные TCP-соединения.

🧠 Если ты до сих пор используешь netstat, попробуй ss.

Подпишись 👉@devopslib

🧩 Почему важно использовать .env файлы в DevOps-проектах

Когда проект начинает обрастать конфигурацией, секретами, API-ключами и разными переменными окружения — легко всё потерять или случайно выложить в Git. Именно тут на сцену выходят .env файлы.

📦 Что такое .env?
Это простой текстовый файл с ключ-значениями, например:

DB_HOST=localhost
DB_USER=admin
DB_PASS=secret

Он не исполняется напрямую, но может быть подгружен в окружение с помощью утилит вроде dotenv, source, или встроенных механизмов в Docker, Compose, CI/CD и так далее.

🔐 Почему это круто:

- Безопасность: не хардкодим чувствительные данные в коде
- Гибкость: можно легко переключаться между dev/stage/prod окружениями
- Поддержка: большинство инструментов CI/CD и фреймворков умеют работать с .env
- Удобство: один файл — все переменные

🛡️ Совет:
Добавь .env в .gitignore, иначе можно случайно закоммитить секреты.

📌 Если работаешь с Docker Compose — укажи env_file в docker-compose.yml:

services:
  app:
    env_file:
      - .env

Так контейнеры будут сразу знать, какие переменные им нужны.

Подпишись 👉@devopslib

🚀 История одной фичи: systemd-run
(aka когда надо быстро запустить что-то от другого пользователя)

Ситуация: ты по SSH, нужно срочно что-то запустить от имени другого пользователя. sudo su? su -? screen? tmux? crontab?
Остановись. Посмотри на это:

sudo systemd-run --uid=appuser --pty bash

💡 Что происходит:
Ты создаёшь временный unit в systemd, от имени пользователя appuser, и получаешь интерактивную сессию в его окружении. Всё красиво, под контролем systemd, с логами, cgroup и т.п.

Можно запускать и отдельные команды:

sudo systemd-run --uid=appuser --pty top

Или фоново:

sudo systemd-run --uid=appuser --scope my-command

🔥 Преимущества:
- работает даже если shell пользователя отключён
- не требует входа в сессию
- всё логируется в journald
- systemd сам подчищает за собой

👀 Используй, когда:
- хочешь тестить что-то от другого юзера
- автоматизируешь запуск задач
- нет желания возиться с su/sudo/scripts

Подпишись 👉@devopslib

🧠 Фичи в Kubernetes, которые ты почти точно не используешь (а зря)

Сегодня делюсь парочкой полезных, но часто игнорируемых возможностей Kubernetes, которые могут упростить жизнь DevOps'а.


🚀 Init Containers
Всё ещё пихаешь скрипты и ожидания в основной контейнер? Init containers — твои друзья. Они запускаются до основного контейнера и идеально подходят для всяких подготовительных задач: прогрев кэша, валидация конфигов, ожидание зависимостей и т.д.


🔒 PodSecurityPolicy (PSP) (устарело, но ты знал?)
Да, PSP deprecated, но оно до сих пор используется в куче продакшенов. Если не хочешь мигрировать на OPA/Gatekeeper прямо сейчас — хотя бы убедись, что PSP у тебя не дырявая.


📦 Ephemeral Containers
Идеальны для отладки. Хочешь зайти в прод-под без шелла или нужных утилит? Добавляешь ephemeral контейнер с bash’ем, curl’ом и всем нужным, не перезапуская под.

kubectl debug -it pod-name --image=busybox

🌐 NetworkPolicy
Ты уверен, что твои поды не могут лезть куда угодно? Пока не включены NetworkPolicy, твой кластер — как квартира без дверей. Даже самый кривой Dev может случайно (или не очень) сломать пол интернета изнутри.


⏱ Liveness vs Readiness
Это не одно и то же. Readiness говорит, когда трафик можно пускать. Liveness — когда под умер. Если перепутал — получишь либо DDoS от своих же сервисов, либо перезапуск в вечном цикле.


Пользуешься всеми? Респект. Нет? Самое время попробовать.

Подпишись 👉@devopslib

🚀Проблема, которой нет — и почему это важно замечать

Сегодня на проде упал alert: "Disk usage > 90%". Все бросились проверять, начали чистить старые логи, сносить временные файлы…
Через час выяснилось — в этом pod-е выключен log rotation. Логи не собираются, monitoring — через copy-paste из другого сервиса.
А теперь внимание — это staging. Его давно никто не трогал, и его… можно было просто пересоздать.

💡Мораль:
Иногда мы влетаем в тушение "проблем", не задавая себе один простой вопрос: а это вообще проблема?
DevOps — не только про решение задач, но и про грамотный приоритез. Не каждое красное — это пожар.

Подпишись 👉@devopslib

🧰 Тёмные уголки CI/CD: почему твой pipeline тормозит и как его починить

Когда pipeline в CI/CD работает медленно, это не просто раздражает — это напрямую бьёт по скорости релизов и нервам команды. Вот тебе список часто забываемых причин, почему всё может тормозить, и как это исправить:


🔥 1. Лишние шаги в pipeline
Ты удивишься, сколько "временных" тестов или сборок остаются навсегда. Проверяй каждый шаг — реально ли он нужен?

💡 Что делать:
Периодически проводи ревизию pipeline. Удаляй устаревшие шаги или разделяй pipeline на fast/slow треки.


🐌 2. Медленные Docker-образы
Если ты каждый раз тащишь 1GB образ, то ничего удивительного. Особенно если не используешь кеш.

💡 Что делать:
- Используй multi-stage build
- Обрезай base-образы
- Включи кеширование слоёв в CI


🔁 3. Нет параллельного выполнения
Когда всё идёт строго по очереди, даже быстрая задача может затянуться.

💡 Что делать:
- Разбивай pipeline на независимые джобы
- Включай matrix билд, если тестируешь на разных платформах/версиях


🧪 4. Тесты без приоритета
Падают все тесты? А если бы сначала шли самые "ломкие", ты бы быстрее увидел фейл.

💡 Что делать:
- Отдели "fast-fail" тесты
- Используй тегирование и запускай важные тесты в первую очередь


📦 5. Устаревшие dependencies
Половина времени уходит на попытки подтянуть несуществующие версии библиотек или ждать response от старых package registry.

💡 Что делать:
- Используй lock-файлы
- Ставь кеш для зависимостей
- Обновляй registry mirror


Медленный pipeline — это технический долг. Он не только тратит твое время, но и мешает экспериментам. Оптимизируй — и сам себя поблагодаришь.

Подпишись 👉@devopslib

🚀 Terraform vs Pulumi: Что выбрать?

Инфраструктура как код (IaC) давно уже не новость, но выбор инструмента всё ещё вызывает споры. Terraform и Pulumi — два мощных игрока, и вот коротко о том, где каждый из них shines ✨:

🟩 Terraform — стабильный, проверенный временем:
- HCL читается легко, даже если ты не девелопер.
- Большое сообщество, куча модулей.
- Отлично подходит для "декларативных" команд — описал состояние и забыл.
- Работает везде: AWS, Azure, GCP, даже VMware и всякие niche-провайдеры.

🟦 Pulumi — больше, чем просто IaC:
- Пишешь инфраструктуру на реальных языках: TypeScript, Python, Go, C#.
- Можно строить абстракции, писать модули как нормальный код, использовать CI/CD-практики без боли.
- Очень удобно для Dev-first команд.

🤔 Что выбрать?
- Если у тебя инфраструктурная команда и важна стабильность — бери Terraform.
- Если у вас fullstack/DevOps-инженеры, которые уже пишут на Go или TS — Pulumi даст больше гибкости.

💡 А может и то, и другое? Некоторые проекты используют оба инструмента: core-инфра — на Terraform, динамические окружения — на Pulumi.

Подпишись 👉@devopslib

🔧 Почему systemd – это не только про запуск сервисов

Многие до сих пор думают, что systemd нужен только для того, чтобы стартовать сервисы. Но на деле он — как швейцарский нож для линуксоидов.

Вот несколько его «скрытых» возможностей, которые ты, возможно, упускаешь:

🔹 systemd timers — альтернатива cron. Более гибкая, с логами, юнитами, и возможностью зависимости от других сервисов.

🔹 systemd-run — запускай любые команды как временный сервис. Отлично подходит для тестов, отложенного выполнения или запуска с нужными лимитами ресурсов.

🔹 Resource control (cgroups) — через systemd можно ограничить CPU, память, IO для любого юнита. Прям как в Kubernetes, только локально.

🔹 journalctl — лог-менеджер, которого ты заслуживаешь. Фильтры по юниту, по времени, по PID, по приоритету — goodbye, grep.

🔹 User units — можно писать юниты не только для root, но и для обычных пользователей. Отлично для изоляции окружений.

Если ты до сих пор относишься к systemd как к init-процессу — попробуй копнуть глубже. Он вполне может заменить кучу сторонних тулзов и сделать твою систему чище.

Подпишись 👉@devopslib

Kubernetes: не клади всё в один namespace 🧠

Кажется мелочью, но namespace — один из ключевых инструментов для поддержания порядка в проде. Правильное разделение — это безопасность, изоляция и удобство поддержки. Разберём, как использовать namespace’ы по-взрослому.


Зачем это вообще нужно?

Namespace в Kubernetes — способ логической изоляции ресурсов. Если не следить за этим, вы рискуете:
- словить конфликт имён между сервисами
- дать доступ тем, кому не надо
- усложнить отладку и мониторинг


Что стоит выносить в отдельные namespace'ы:

1. По окружениям
Создайте dev, staging, prod — и не пересекайте. Это основа безопасного и предсказуемого CI/CD.

2. По командам или микросервисам
Например, team-a, team-b, billing, auth. Удобно для разграничения прав и алертов.

3. По системным компонентам
Например, monitoring, logging, infra. Не мешайте Prometheus и Nginx Ingress с боевыми сервисами.


Бонусы от правильной изоляции:

- RBAC на namespace — это 🔐 DevSecOps must-have
- Снижается blast radius при ошибках (kubectl delete all --all -n wrong-namespace — и прод цел)
- Упрощается мониторинг: фильтрация по namespace в Grafana — как отдельный дешборд
- Логи в Loki, метрики в Prometheus — нагляднее и чище


Антипаттерны, которых стоит избегать:

🚫 Один namespace на всё (особенно default)
🚫 Генерация namespace в CI (ns-392839) без чистки
🚫 Namespace без resource quotas и limit ranges


Вывод:
Разделяй и властвуй. Namespace — не просто "для красоты", а фундамент для масштабируемого, безопасного и поддерживаемого кластера. Если вы до сих пор всё кидаете в default — пора рефакторить 🛠


📚 Дополнительно:
- https://kubernetes.io/ru/docs/concepts/overview/working-with-objects/namespaces/
- https://github.com/kubernetes-sigs/kustomize

Подпишись 👉@devopslib

🛠 Как DevOps превращается в саппорта: незаметный дрейф

Инфра стабильна. Мониторинг молчит. Алёрты — тишина.
Ты думаешь: «Ну наконец-то! Можно позакрывать долги, потрогать Terraform, почитать про eBPF…»

И тут приходит тикет:
> «Что-то не работает»
> «Перезапустите под»
> «Очистите кеш в Redis»
> «Можно дать доступ другу моего кота в Kubernetes?»

И ты уже не инженер. Ты саппорт. Уровень 0.
С каждым таким тикетом ты немного забываешь, как настраивать Helm-чарты и лочить версии в Ansible.

📌 Как не утонуть:
- Фильтруй. Не всё требует DevOps-инженера. Делегируй.
- Автоматизируй. Скрипты, self-service, боты.
- Защищай фокус. Оповести команду: есть баг — пиши в багтрекер, а не в личку.
- Заводи «тихие часы» без чатов — только код.

DevOps — не helpdesk.
Напоминай об этом не только другим, но и себе.

Подпишись 👉@devopslib