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

В хабе на Хабр «Разработка публичных облаков» — свежие статьи от инженеров 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

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

🚀 Как настроить мониторинг SLO/SLA с Prometheus и Grafana В любой современной инфраструктуре важно не просто собирать метрики, а строить на их основе понятные цели уровня обслуживания (SLO) и соглашения об уровне обслуживания (SLA). Вот несколько ключевых шагов: 1. Определите ключевые сервисные метрики 🟢Время отклика API 🟢Доля успешных запросов (error rate) 🟢Задержки базы данных Сфокусируйтесь на показателях, которые прямо влияют на пользовательский опыт. 2. Собирайте метрики в Prometheus 🟢Используйте node_exporter для базового мониторинга хостов. 🟢Внедрите client_golang или client_python в ваши сервисы для экспорта бизнес-метрик. 🟢Настройте alertmanager для уведомлений при выходе за пороговые значения. 3. Проектируйте дашборды в Grafana 🟢Создайте отдельные панели для каждой SLO-метрики. 🟢Используйте графики «Burn rate» для визуализации скорости деградации системы. 🟢Настройте плагины для вычисления ошибок в процентах и «time in state». 4. Устанавливайте целевые уровни и оповещения 🟢Определите допустимую ошибку, например, 99.9% успешных запросов в месяц. 🟢Настройте алерты на 85% и 95% пороги, чтобы предупредить о приближении к SLA-линии. 🟢Включите эскалацию в случае длительных нарушений. 5. Периодически пересматривайте SLO 🟢Анализируйте реальные данные и корректируйте пороги. 🟢Обсуждайте результаты с командой разработки и бизнес-стейкхолдерами. Хорошо выстроенный мониторинг SLO/SLA позволяет увидеть узкие места до того, как они станут инцидентами, и обеспечить стабильность пользователей на нужном уровне. Подпишись 👉@devopslib

🛳️ Канареечные релизы в Kubernetes: безопасный путь к обновлениям В мире SRE и DevOps стремительные релизы — это не просто плюс, а необходимость. Но как выкатывать новые версии сервисов без риска «сломать» продакшн? Ответ — канареечные релизы. Что такое канареечный релиз? Это поэтапный rollout, при котором новая версия приложения сначала попадает на небольшой процент трафика. Если всё OK — долю постепенно увеличивают до 100 %, а при проблемах быстро «откатываются» к старому состоянию. Почему это круто? 🟢 🔍 Минимизируем риски: ошибки затронут лишь небольшой сегмент пользователей. 🟢 ⚡ Быстрый фидбек: метрики сразу покажут, как новая версия ведёт себя под нагрузкой. 🟢 ⏪ Моментальный откат: rollback проще и безопаснее, чем при монолитном апгрейде. Как настроить канареечный релиз в Kubernetes с Argo Rollouts? 1. Установите CRD и контроллер:

   kubectl apply -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
   

2. Описываем Rollout-манифест:

   apiVersion: argoproj.io/v1alpha1
   kind: Rollout
   metadata:
     name: my-app
   spec:
     replicas: 5
     strategy:
       canary:
         steps:
         - setWeight: 10
         - pause: {duration: 60s}
         - setWeight: 50
         - pause: {duration: 60s}
     selector:
       matchLabels:
         app: my-app
     template:
       metadata:
         labels:
           app: my-app
       spec:
         containers:
         - name: my-app
           image: myregistry/my-app:v2
   

3. Запустите Rollout:

   kubectl apply -f rollout.yaml
   argo rollouts get rollout my-app --watch
   

4. Мониторинг и автоматизация: Подключите Prometheus и Grafana — настройте метрики (латентность, ошибки) для автоматической паузы или отката. Советы по продвинутому использованию 🟢 Используйте Webhooks в Argo Rollouts для интеграции с внешними системами тестирования. 🟢 Настройте AnalysisTemplates для автоматической оценки качества релиза по набору SLO. 🟢 Применяйте TrafficRouting через Istio или NGINX Ingress для более гибкого управления трафиком. Такой подход поможет вам выкатывать фичи без лишнего стресса и без полунощных тревог от неожиданного падения сервисов. Подпишись 👉@devopslib