Библиотека девопса | DevOps, SRE, Sysadmin

🛠 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

💡 Почему 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

Мониторинг — это не только графики Мы все любим красивые дашборды: CPU, RAM, диск, трафик… Но сколько раз вы смотрели на Grafana, а проблему всё равно приходилось искать вручную? Вот что реально делает мониторинг полезным: - Алерты с контекстом. Сообщение “CPU > 90%” бесполезно, если не понятно на каком сервисе, с чем связано и что делать. - Трассировка. Логи и метрики без распределённого трейса — как карта без маршрута. Jaeger, Tempo и OpenTelemetry — must have. - SLO, а не SLA. Забудьте про “uptime 99.9%”. Важно понимать, что реально чувствует пользователь, и строить алерты на основе опыта, а не железа. - Автоматизация реакции. PagerDuty и OpsGenie хорошо, но скрипт, который сам перезапустит упавший сервис, иногда спасает нервы. Мониторинг — это не про цифры. Это про быстрое понимание: что сломалось, почему и что делать прямо сейчас. Подпишись 👉@devopslib

В хабе на Хабр «Разработка публичных облаков» — свежие статьи от инженеров MWS Cloud Platform ⬜️. ➡️ Создаем S3-хранилище с нуля. Ультимативный лонгрид про современный S3-ландшафт и нашу архитектуру Object Storage. ➡️ Multus в Kubernetes. Как мы подключили поды к сервисам в overlay-сети с IPv4 и зачем это вообще понадобилось. ➡️ DHCP-сервер облака. Как мы раздаём один и тот же IP в изолированных сетевых пространствах (VRF), какие используем опции и как мониторим доступность DHCP-серверов. ➡️ Development Platform. Зачем мы пишем общие библиотеки и компоненты, как развиваем внутренний open source и с помощью каких инструментов общаются сервисы MWS Cloud Platform и их создатели. Если вам интересны архитектурные решения для настоящего highload'а — эти материалы будут вам полезны. 🔗 Подпишись на облачный хаб MWS — там регулярно рассказываем, как строим новое облако с нуля.

Как понять, что пора переписать свой Ansible playbook? Все мы знаем, что конфигурация - это живой организм. Когда-то ты писал маленький playbook на пару тасков, а через полгода он превратился в монстра на 500 строк, который страшно трогать. Вот признаки, что пора остановиться и переписать: 1. Copy-paste вместо ролей. Если в нескольких playbook-ах повторяется один и тот же блок задач - это крик о помощи. Вынеси это в роль. 2. Нет структуры. Папка playbooks/ превращается в свалку из файлов с именами new.yml, fix2.yml. Пора завести нормальную структуру с ролями и группировкой по окружениям. 3. Много условностей. Когда в тасках появляются километровые when, это знак, что playbook делает слишком много за раз. Лучше разделить. 4. Сложно тестировать. Если каждый прогон - это боль и сюрпризы на проде, самое время добавить Molecule и хотя бы минимальные тесты. 5. Никто не хочет трогать. Если команда боится открывать файл, значит, он уже не решает задачи, а создает их. Совет: не бойся переписывать. В Ansible, как и в коде, рефакторинг - это норма. Маленькие, модульные роли проще поддерживать, тестировать и читать. Подпишись 👉@devopslib

Зачем DevOps-у разбираться в лицензиях на ПО? Кажется, что лицензии — это что-то из мира юристов. Но реальность такая: ты выкатываешь инфраструктурный код, ставишь сторонний контейнер или используешь библиотеку — и уже попадаешь под определённые условия. Представь: 🔘 Ты собрал CI/CD с открытым инструментом, а его лицензия запрещает коммерческое использование. 🔘 Ты сделал форк утилиты, но забыл указать оригинальный copyright. 🔘 Ты упаковал в Docker образ проприетарное ПО и выложил в публичный репозиторий. Результат? От штрафов до судебных исков. Что стоит знать: 1. MIT, Apache 2.0, GPL, BSD — это не просто слова. У каждой лицензии есть нюансы: от «делай что хочешь, только оставь копирайт» до «всё твое должно быть тоже open-source». 2. Контейнеры — тоже ПО. Всё, что ты собираешь в образ, может иметь свои условия. 3. Инфраструктурный код (Terraform, Ansible) часто тянет зависимости — смотри, что именно ты используешь. Совет: 🔘 Внедри в пайплайн лицензионный сканер (например, FOSSA или Trivy с лицензиями). 🔘 Веди реестр используемого ПО. 🔘 Минимум раз в квартал делай аудит лицензий. DevOps — это не только про аптайм. Это про то, чтобы не схлопотать иск за чужой код. Подпишись 👉@devopslib

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

Коллеги, поздравляю вас с Днём системного администратора! Подпишись 👉@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

🛠 Что происходит, когда вы вводите 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

🔥 Что такое 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

🚨 Непредсказуемый баг из-за таймаута 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

🚨 Зачем 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

🔧 Как не словить 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 и 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

🚨 Почему алерты не спасут твой прод? Ты настроил алерты. Все по учебнику: CPU > 80%, диск > 90%, latency > 500ms, таймауты, реджекты. Всё работает — ты уверен. А теперь честно: сколько раз ты видел алерт, но не реагировал, потому что “это бывает” или “оно само отойдёт”? Или наоборот — алерт сработал, но уже поздно, инцидент в разгаре. Алерты ≠ наблюдение. Алерт — это реакция на симптом, а не на проблему. И если ты ловишь только симптомы — ты всегда будешь в роли пожарного, а не инженера. Что делать? ✅ Строй SLO/SLA. Алерты — не про метрики, а про бизнес-цели. ✅ Категоризируй: ошибки уровня приложений, инфраструктуры и пользователей — требуют разных подходов. ✅ Визуализируй поведение системы: Grafana, dashboards, traces. ✅ Добавь runbook: алерт без инструкции — шум. ✅ Смотри в ретроспективу. Где ложные срабатывания? Где не хватило раннего сигнала? Алерт — это не звонок в дверь, это сигнал тревоги. От него зависит, проснёшься ты вовремя или будешь объяснять CTO, почему уронил прод. Подпишись 👉@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

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

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

🔧 Зачем DevOps'у знать про eBPF? Если ты ещё не копал в сторону eBPF (extended Berkeley Packet Filter) — пора это менять. Это как иметь суперсилу для наблюдения за системой без перехвата контекста ядра и без перезапуска сервисов. Вот пара кейсов, где eBPF реально выручает: 🔍 Трассировка сетевых пакетов: без tcpdump и iptables. eBPF-инструменты вроде Cilium или BCC дают возможность видеть, кто, куда и как лезет в сеть прямо сейчас. 🔥 Профилирование процессов в проде: perf и strace хороши, но eBPF делает это без падений и перегрузок. Реально смотришь, где жрётся CPU, в каких функциях, и как это чинить. 🧠 Безопасность: можно отловить подозрительную активность на уровне системных вызовов — почти как антивирус, только кастомный и свой. 🎯 В продакшне eBPF — как рентген, только для Linux. В ядро лезть не надо, зато видишь всё. 👨‍💻 Хочешь пример? Посмотри на bpftrace — пишешь простенькие one-liner скрипты, которые ловят, например, все open() вызовы в системе за секунды. Подпишись 👉@devopslib

🚀 MEETUPxSPRINT OFFER для инженеров технической поддержки от YADRO Хочешь узнать, как устроена техническая поддержка в одной из ведущих технологических компаний России? Приходи на онлайн-митап от YADRO! Расскажем, покажем, ответим на любые вопросы — и дадим возможность попасть в команду всего за 3 дня! 🔥 Программа митапа: ✔️ Сервисная служба YADRO: основные ресурсы и направления Василий Бронников, Руководитель отдела техподдержки решений ✔️ Наши продукты: уникальные характеристики и возможности Андрей Антоненко, Ведущий инженер техподдержки TATLIN ✔️ Реальные кейсы: как команды решают сложные задачи Дмитрий Сафонов, Руководитель группы L1-поддержки TATLIN.UNIFIED 🔥 Что тебя ждёт: ➖ Реальные кейсы и инсайты из практики техподдержки ➖ Доклады от инженеров YADRO: продукты, процессы, особенности ➖ Живое общение с командой и ответы на вопросы о работе и технологиях 👨‍💻 А если ты задумываешься о новой работе — у тебя есть возможность быстро попасть в команду YADRO и получить оффер за 3 дня. Для этого нужно пройти короткий тест. Сделать это можно уже сейчас, а также во время или после митапа — выбирай, как тебе удобно (но заявки принимаем до 6 июля). 📌 Тест можно пройти по ссылке. ➖➖➖ 🗓 26 июня, начало в 19:00 мск, четверг 🌐 ОНЛАЙН ✅ Регистрация на мероприятие Реклама. ООО "ЭВРОНЕ.РУ". ИНН 3663057399. erid: 2VtzqvK4SaS