📦 Зачем DevOps'у уметь читать Dockerfile, даже если он не пишет их сам

Даже если ты не автор образов, в проде ты всё равно будешь отвечать за их поведение. А это значит — как минимум, уметь читать Dockerfile.

Вот зачем это важно:

🔍 Диагностика проблем
Падает контейнер — надо понять, что внутри. Логов нет, трассировки нет, только Dockerfile. И если там на 5-й строке COPY ./random.sh /init.sh && chmod +x /init.sh && /init.sh — ты уже знаешь, где копать.

🛡 Безопасность
Ты удивишься, сколько «готовых» образов тянут curl/bash скрипты из интернета в рантайме. Это мина под твоим кластером. Умение распознать такую «закладку» спасёт прод.

⚡ Оптимизация CI/CD
Каждый RUN apt-get update && install — это дополнительный слой. А если таких RUN-ов 10? Билд будет долгим, кэш бесполезным. Умеешь читать — можешь подсказать разработчику, как сделать быстрее.

🔁 Обновления и патчи
Часто нужно просто пропатчить образ: обновить версию пакета или заменить base image. Без понимания Dockerfile ты будешь звать разработчика. А мог бы уже закатить фикс и спать спокойно.

Так что даже если ты не пишешь Dockerfile — читай их. Это как чтение кода: не надо быть гуру, чтобы понимать, что происходит.


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

🔧 Зачем DevOps'у знать про eBPF?

Если ты ещё не копал в сторону eBPF (extended Berkeley Packet Filter) — пора это менять. Это как иметь суперсилу для наблюдения за системой без перехвата контекста ядра и без перезапуска сервисов.

Вот пара кейсов, где eBPF реально выручает:

🔍 Трассировка сетевых пакетов: без tcpdump и iptables. eBPF-инструменты вроде Cilium или BCC дают возможность видеть, кто, куда и как лезет в сеть прямо сейчас.

🔥 Профилирование процессов в проде: perf и strace хороши, но eBPF делает это без падений и перегрузок. Реально смотришь, где жрётся CPU, в каких функциях, и как это чинить.

🧠 Безопасность: можно отловить подозрительную активность на уровне системных вызовов — почти как антивирус, только кастомный и свой.

🎯 В продакшне eBPF — как рентген, только для Linux. В ядро лезть не надо, зато видишь всё.

👨‍💻 Хочешь пример? Посмотри на bpftrace — пишешь простенькие one-liner скрипты, которые ловят, например, все open() вызовы в системе за секунды.

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

🚀 Как быстро найти самый большой файл в системе?

Иногда диск внезапно заполняется, и ты такой: «Кто всё съел?!»
Вот простой способ найти самых прожорливых:

du -ah / | sort -rh | head -n 10

🔍 Разбор:

du -ah / — показывает размер всех файлов и директорий, начиная с корня.
sort -rh — сортирует по размеру в обратном порядке (от большего к меньшему).
head -n 10 — выводит топ-10 самых тяжёлых файлов и папок.

💡 Хочешь искать только среди файлов, без папок? Вот так:

find / -type f -exec du -h {} + 2>/dev/null | sort -rh | head -n 10

📎 Используй с умом: du может долго работать, особенно на больших дисках. Лучше начать с папки вроде /var или /home.

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

🔧 Проверка сети без telnet и nc

Когда telnet и nc недоступны (например, в проде с урезанными пакетами), на выручку приходит curl и bash.

Вот три приёма:

1. Проверка TCP-порта с curl

curl -v telnet://host:port

Подходит даже в контейнерах без nc. Ответ покажет, удалось ли установить TCP-соединение.

2. Проверка порта с bash

timeout 1 bash -c '</dev/tcp/host/port' && echo OK || echo FAIL

Работает, если bash скомпилен с поддержкой /dev/tcp.

3. curl как ping TCP

curl -s --connect-timeout 2 host:port >/dev/null && echo UP || echo DOWN

Удобно для health-check скриптов.

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

🚨 Почему алерты не спасут твой прод?

Ты настроил алерты. Все по учебнику: CPU > 80%, диск > 90%, latency > 500ms, таймауты, реджекты. Всё работает — ты уверен.

А теперь честно: сколько раз ты видел алерт, но не реагировал, потому что “это бывает” или “оно само отойдёт”? Или наоборот — алерт сработал, но уже поздно, инцидент в разгаре.

Алерты ≠ наблюдение.
Алерт — это реакция на симптом, а не на проблему. И если ты ловишь только симптомы — ты всегда будешь в роли пожарного, а не инженера.

Что делать?

✅ Строй SLO/SLA. Алерты — не про метрики, а про бизнес-цели.
✅ Категоризируй: ошибки уровня приложений, инфраструктуры и пользователей — требуют разных подходов.
✅ Визуализируй поведение системы: Grafana, dashboards, traces.
✅ Добавь runbook: алерт без инструкции — шум.
✅ Смотри в ретроспективу. Где ложные срабатывания? Где не хватило раннего сигнала?

Алерт — это не звонок в дверь, это сигнал тревоги. От него зависит, проснёшься ты вовремя или будешь объяснять CTO, почему уронил прод.

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

DevOps и SRE: конкуренты или союзники в борьбе за надёжность?
Где заканчивается зона ответственности DevOps-инженера и начинается область контроля SRE?

Приглашаем на открытый урок, где разберём разницу между подходами DevOps и SRE, особенно — в контексте Service Level Indicators (SLI), Service Level Objectives (SLO) и Service Level Agreements (SLA).

✅ Вы узнаете, как эти практики помогают создавать надёжную платформу и кто за что отвечает в команде.

📌 Обсудим как DevOps и SRE трактуют «качество платформы». И кто за какими метриками следит: производительность, аптайм, алерты, ошибки

⬆️ Протестируй курс «SRE практики и инструменты» на открытом уроке: https://vk.cc/cNl1ly

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

🔧 Как не словить heart attack от systemd после ребута

Сценарий знакомый каждому: выкатываешь новую версию, всё проверено, ребутаешь — и… сервис не стартует. Или стартует, но не так. Или вообще не тот.

Вот пара вещей, которые стоит проверить заранее, чтобы systemd не превратился в твоего личного врага:


✅ Проверь WantedBy и After

Очень часто забывают правильно указать зависимости между юнитами. Если my-app.service зависит от postgresql.service, обязательно пропиши:

[Unit]
After=postgresql.service
Requires=postgresql.service

✅ Не забудь про EnvironmentFile

Если ты грузишь переменные из .env, проверь, что путь указан корректно и файл точно есть:

EnvironmentFile=/etc/my-app/env

И что этот файл читаем для systemd!


✅ Работает в screen, а в systemd — нет?

Часто дело в WorkingDirectory или User. Убедись, что все пути абсолютные и права выставлены правильно.


✅ Логируйся, как будто завтра форензика

StandardOutput=journal
StandardError=journal

Логика простая: чем проще найти ошибку — тем быстрее в проде всё снова работает.


✅ И последнее: не забудь прогнать systemd-analyze verify my-app.service перед выкатыванием. Иногда он спасает от того, что ты бы искал часами.


🙃 systemd — это не враг. Это просто злобный кот. Главное — гладить его по шерсти.

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

🚨 Зачем DevOps-инженеру понимать, как работает сеть?

Ты можешь настроить Kubernetes, автоматизировать CI/CD, мониторить всё через Prometheus и Grafana, но однажды... приложение тупо не работает. А логов — нет. Всё зеленое. И ты лезешь в tcpdump, как в последний оплот здравого смысла.

Вот почему DevOps обязан понимать сетевые основы:

🔹 DNS — это не просто 8.8.8.8.
Не работает curl? Возможно, DNS-запрос завис. dig, nslookup, resolv.conf — должны быть как вторая клавиатура.

🔹 TCP three-way handshake.
Без него ты не поймешь, почему соединение не устанавливается. А SYN_SENT в netstat станет твоим лучшим другом в ночных дебаг-сессиях.

🔹 iptables и firewalld — друзья или враги?
Порой curl localhost:8080 работает, а извне — нет. Порты открыты? Или кто-то по-тихому всё режет?

🔹 Traceroute vs MTR.
Ты видишь, где именно теряются пакеты. Очень помогает, когда AWS говорит: “Проблем на нашей стороне нет”.

🔹 Wireshark.
Графический святой грааль сетевого дебага. Но иногда проще tcpdump -nn -i eth0 port 443.

🧠 Итог: умение разбираться в сетевых траблах — это как знание первой помощи. Редко нужно, но когда нужно — спасает прод.


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

🚨 Непредсказуемый баг из-за таймаута DNS в Kubernetes

На днях столкнулся с очень странным поведением: один из микросервисов начал периодически отваливаться по таймауту при обращении к другому сервису через DNS. Причём — только в кластере, локально всё ок.

🧩 Разгадка оказалась в CoreDNS и его настройках. По умолчанию, в kubelet --resolv-conf указывает на /etc/resolv.conf, где могут стоять опции типа options timeout:5 attempts:3. Это значит, что при проблемах с DNS один запрос может занимать до 15 секунд (!) прежде чем вернётся ошибка. А если у тебя таймаут в приложении стоит 10 секунд — получай баг с мордой из ниоткуда.

🔍 Что помогло:

🔹Проверил настройки resolv.conf в Pod'ах (cat /etc/resolv.conf)
🔹Установил timeout:1 attempts:1 — теперь ошибки быстрее, но предсказуемо
🔹В некоторых случаях можно использовать dnsPolicy: "None" и задать dnsConfig вручную

💡 Совет: всегда проверяйте, какие настройки DNS попадают внутрь Pod'а, особенно если ловите баги «иногда и непонятно почему».

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

🔥 Что такое Kubernetes Finalizers и как не словить боль

Когда ты удаляешь объект в Kubernetes — например, CustomResource, — он не исчезает сразу. Вместо этого kube-apiserver помечает его как deletionTimestamp, и объект "ждёт" удаления. Почему? Потому что в его манифесте может быть finalizer — специальный маркер, что "я не готов умереть, пока кто-то не выполнит важную работу".

🤔 Пример:

metadata:
  finalizers:
    - mycompany.com/cleanup

Это значит, что перед удалением кто-то (обычно контроллер) должен сделать, например, очистку ресурсов в AWS или GCP. Только после этого finalizer удаляется, и объект реально исчезает.

💣 Где тут подводные камни?

Если контроллер, который должен удалить финалайзер, умер, сломался или вообще не запущен — объект останется висеть в статусе "Terminating" вечно. А это может заблокировать ресурсы, сломать пайплайны, вызвать боль в проде.

🔧 Как починить?

Иногда приходится руками чистить финалайзеры:

kubectl patch myresource myname -p '{"metadata":{"finalizers":[]}}' --type=merge

⚠️ Только если ты точно знаешь, что cleanup не нужен или уже сделан.

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

🛠 Что происходит, когда вы вводите curl google.com?

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

1. DNS-резолвинг
curl сначала узнаёт IP-адрес для google.com. Для этого он обращается к системному резолверу, который опрашивает DNS-сервер (например, 8.8.8.8).

2. Установление TCP-соединения
Как только IP получен, curl инициирует TCP Handshake (SYN → SYN-ACK → ACK) на порт 80 (или 443 для HTTPS).

3. TLS Handshake (если HTTPS)
Если вы не указали http://, curl по умолчанию стучится по HTTPS (порт 443). Тогда идёт обмен сертификатами, проверка CA, установка сессионных ключей.

4. Отправка HTTP-запроса
После установления соединения curl отправляет HTTP-запрос вида:
GET / HTTP/1.1
Host: google.com
User-Agent: curl/7.79.1
...

5. Получение ответа
Google возвращает HTTP-ответ (200 OK, 301 Redirect и т.д.) и тело страницы, если оно есть.

6. Закрытие соединения
curl может держать соединение открытым или закрыть его в зависимости от заголовков (Connection: keep-alive / close).

🧠 Это базовый сценарий. Но вы можете добавить -v для отладки, --resolve для подмены DNS, --http2 для тестов HTTP/2, и кучу всего ещё.


Используете curl только для запросов? Пора качнуть скилл: тест API, дебаг прокси, TLS-тесты, даже работа с SOCKS5 — это всё в арсенале curl.

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

🎯 Почему логи — твои лучшие друзья (или враги)

Сегодняшний кейс: одна из прод — JVM-аппка начала резко жрать CPU.
Люди в панике, мониторинг орёт, прод выдыхает. Что первым делом? Лезем в логи.

Но вот нюанс: логи в формате
INFO 2025-07-22 14:33:12,987 [thread-1] com.example.Class - Doing something
— это как искать иголку в стоге syslog’ов. А когда они ещё и с ротацией без Retention Policy, то удачи…

🔍 Что помогает в таких случаях:

Structured Logging: JSON-формат рулит, особенно когда поверх — ELK или Loki.
Correlation ID: у каждой операции — уникальный ID, без него в микросервисной каше ты слеп.
Уровни логов: DEBUG, INFO, WARN, ERROR — это не просто украшение, а ориентиры.
Контроль verbosity: хочешь логировать всё — логируй в dev, но не тащи это в прод.

🧠 Плохие логи — как плохая карта: вроде дорога есть, но ты всё равно заблудишься.
Делай так, чтобы твою систему можно было "прослушать" без шаманства.

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

Коллеги, поздравляю вас с Днём системного администратора!

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

Как не сойти с ума, если у тебя 50+ сервисов в проде

В какой-то момент любой проект превращается в зоопарк: десятки микросервисов, разные стеки, свои деплой-пайплайны и непонятно, что вообще сейчас где крутится.

Что помогает выжить:

- Единый шаблон для сервисов. Helm-чарты, Terraform-модули, пайплайны — всё должно быть максимально унифицировано. Новая фича? Меняешь в одном месте, обновляешь все.
- Service Catalog. Даже если это просто таблица в Confluence/Notion, где описано: кто владелец сервиса, где код, как деплоится и где алерты.
- Алерты с приоритетами. Не всё, что сломалось, нужно чинить ночью. Разделяйте: что критично (P1), что можно отложить (P3).
- Автоматизация рутины. Никаких ручных деплоев, ручных настроек в проде. Автообновления, автоалерты, автодеплой.

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

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

Как понять, что пора переписать свой Ansible playbook?

Все мы знаем, что конфигурация - это живой организм. Когда-то ты писал маленький playbook на пару тасков, а через полгода он превратился в монстра на 500 строк, который страшно трогать. Вот признаки, что пора остановиться и переписать:

1. Copy-paste вместо ролей.
Если в нескольких playbook-ах повторяется один и тот же блок задач - это крик о помощи. Вынеси это в роль.

2. Нет структуры.
Папка playbooks/ превращается в свалку из файлов с именами new.yml, fix2.yml. Пора завести нормальную структуру с ролями и группировкой по окружениям.

3. Много условностей.
Когда в тасках появляются километровые when, это знак, что playbook делает слишком много за раз. Лучше разделить.

4. Сложно тестировать.
Если каждый прогон - это боль и сюрпризы на проде, самое время добавить Molecule и хотя бы минимальные тесты.

5. Никто не хочет трогать.
Если команда боится открывать файл, значит, он уже не решает задачи, а создает их.

Совет: не бойся переписывать. В Ansible, как и в коде, рефакторинг - это норма. Маленькие, модульные роли проще поддерживать, тестировать и читать.

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

Мониторинг — это не только графики

Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную?

Вот что реально делает мониторинг полезным:

- Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать.
- Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have.
- SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа.
- Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы.

Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас.

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

💡 Почему devops-ам важно уметь читать чужой Terraform

Многие любят писать свой код IaC с нуля — «я же всё делаю правильно». Но реальность другая: половину времени DevOps проводит, разбираясь в чужих модулях, которые писали люди с разным опытом, стилем и, иногда, без особой любви к документации.

👉 Что важно при чтении чужого Terraform:

1. Понять архитектуру целиком
Не лезь сразу в main.tf. Сначала посмотри, как устроены модули, переменные (variables.tf) и выходные значения (outputs.tf). Это даст картину, что и куда деплоится.

2. Следить за провайдерами
Версии провайдеров часто ломают совместимость. Если ты видишь ~> 3.0, проверь changelog — иначе можно «внезапно» словить падение пайплайна.

3. Где переменные и секреты
Иногда секреты лежат в terraform.tfvars или вообще в репозитории (да, это ужасно, но встречается). Убедись, что конфиденциальное вынесено в Vault или хотя бы в CI/CD переменные.

4. Понять логику окружений
Terraform любят разбивать на env/prod, env/stage. Но бывает, что переменные переопределяются через -var-file в пайплайне. Если пропустишь этот момент, в прод может уехать конфиг от стейджа.

🛠 Мастерство DevOps — не только писать, но и быстро разбирать чужие хаотичные конфиги, чтобы не потратить на это неделю.


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

🛠 DevOps-лайфхак: как не потерять вечер на docker pull

Если у вас на сервере при каждом деплое идёт медленный docker pull, а сеть вроде нормальная — проблема может быть не в интернет-канале, а в layer cache.

🔍 Почему так бывает

- Docker Registry (особенно приватный) иногда не поддерживает эффективные Range-запросы. Тогда даже небольшой слой тянется целиком.
- Если образы лежат в разных регионах, latency сильно бьёт по скорости загрузки.
- Частая ошибка — переупаковка слоёв при сборке, из-за чего кэш на нодах не используется.

⚡ Что можно сделать

1. Локальный кэш-реестр

- Запускаем маленький registry:2 рядом с нодами.
- Настраиваем Docker daemon через registry-mirrors.
- При деплое тянем образы сначала из локального кэша.

2. Слои без изменений — без перекачки

- Следите за порядком инструкций в Dockerfile:

     RUN apt-get update && apt-get install -y deps
     COPY . .
     

Так базовые слои останутся закэшированы.

3. Предзагрузка образов

- В k8s можно использовать imagePullPolicy: IfNotPresent.
- Для больших апдейтов — cronjob, который тянет образы на все ноды заранее.

💡 Итог: пару простых правок — и вместо 5 минут на деплой у вас будет 20 секунд.

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