Нагружаем приложение и смотрим, как оно себя ведёт!

Сегодня прогоняем тестовое веб‑приложение через обычную нагрузку и простейшую «атаку», чтобы увидеть разницу по метрикам и логам. Всё через терминал и пару утилит: hey/ab для нагрузки и curl для имитации агрессивного клиента.

Сначала замерим «здоровое» состояние с равномерной нагрузкой:

hey -z 30s -c 20 http://localhost:8080/

За 30 секунд получим средний RPS, latency и процент ошибок. Это будет базовый уровень, с которым будем сравнивать.

Теперь устроим «атаку» с одного IP — резкий всплеск запросов:

hey -z 30s -c 200 http://localhost:8080/login

Следим в это время за приложением:

tail -f app.log
htop

В логах увидишь частые обращения к одному эндпоинту и рост 5xx/4xx, а по ресурсам — скачок CPU/памяти.

Можно вынести это в простой скрипт:

load_test() {
  hey -z 20s -c 30 "$1"
  hey -z 20s -c 200 "$1"
}
load_test "http://localhost:8080/login"

🔥 Так удобно быстро смотреть, где приложение начинает «сыпаться» под нагрузкой: код, база или сеть.

➡️ DevOps Ready | #практика

Знали, что «битый» YAML-файл может уронить весь CI/CD пайплайн еще до того, как начнется деплой?

Лишний пробел или неверный отступ в манифестах Kubernetes или Ansible это классическая причина падений. Чтобы не тратить время на запуск тяжелых пайплайнов ради проверки синтаксиса, стоит использовать легковесные утилиты для локальной валидации.

Самый быстрый способ проверить файл без установки лишнего софта — встроенные возможности Python:

python3 -c 'import yaml, sys; yaml.safe_load(sys.stdin)' < deployment.yaml

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

Для продвинутой проверки с учетом лучших практик используй специализированный линтер:

yamllint -d relaxed config.yaml

Это подсветит не только ошибки синтаксиса, но и нарушение стилистики (слишком длинные строки, лишние пробелы в конце).

Добавь проверку в pre-commit хук своего репозитория, чтобы ошибки вообще не попадали в Git:

- repo: https://github.com/adrienverge/yamllint.git
  rev: v1.33.0
  hooks:
    - id: yamllint

🔥 Маленькая проверка на входе экономит десятки минут ожидания «красного» пайплайна в GitLab или GitHub.

➡️ DevOps Ready | #совет

📂 Напоминалка по DNS!

Например, когда домен вводится в браузере, он сначала проверяет кеш, если IP не найден — запускается цепочка DNS-запросов: Root - TLD - Authoritative сервер. В итоге браузер получает IP и только после этого отправляет HTTP-запрос на сервер.

На картинке — наглядная схема того, как именно работает DNS-резолв шаг за шагом.

Сохрани, чтобы не забыть!

➡️ DevOps Ready | #ресурс

Устраняем случайные падения пайплайна из-за нехватки ресурсов!

Случайные сбои CI/CD часто вызваны переполнением диска раннера или конфликтами портов при параллельных сборках. Мы настроим автоматическую очистку мусора и изоляцию сервисов, чтобы сделать выполнение шагов предсказуемым.

Добавим в конфигурацию CI автоматическую очистку старых Docker-объектов перед началом каждой сборки:

before_script:
  - docker system prune -f --volumes --filter "until=24h"
  - df -h | grep '/dev/'

Команда df покажет реальное наличие свободного места в логах пайплайна.

Используем механизм сервисов для изоляции базы данных, чтобы избежать конфликтов за порты на общем раннере:

services:
  - name: postgres:15-alpine
    alias: db_host
variables:
  DATABASE_URL: "postgresql://user:pass@db_host:5432/test_db"

Результат: база доступна по внутреннему DNS-имени db_host, не занимая порты хост-системы.

Настроим автоматический перезапуск шага только при системных ошибках связи или сбоях инфраструктуры:

# Умные ретраи для сетевых лагов
job_step:
  retry:
    max: 2
    when: runner_system_failure

🔥 Регулярно мониторьте объем логов и размер артефактов, чтобы они не забивали дисковое пространство раннеров.

➡️ DevOps Ready | #практика

Как гарантировать, что скрипт или команда не запустится дважды?

Часто cron запускается повторно, деплой стартует дважды, скрипт пересекается сам с собой.

PID-файлы — ненадёжны.
Проверки через ps — гонки.

В Linux есть решение — flock.
Запустить команду, только если она ещё не выполняется:

flock -n /tmp/deploy.lock deploy.sh

Если блокировка занят, flock завершится с ошибкой, команда не стартует.

Для скриптов ещё надёжнее:

exec 9>>/tmp/job.lock
flock -n 9 || exit 1

С этого момента гарантированно: только один экземпляр, блокировка снимается автоматически при exit.

🔥 flock — это advisory-блокировка ядра с атомарной установкой, а не договорённость скриптов. Используйте её для cron, деплоя, миграций, бэкапов и CI-шагов.

➡️ DevOps Ready | #совет

Анализ поведения приложения через фаззинг статус-кодов!

Изучение ответов сервера на нестандартные запросы помогает выявить скрытые директории, ошибки конфигурации или утечки данных.
Используем инструмент ffuf для массовой проверки того, как веб-приложение реагирует на различные манипуляции с путями.

Для начала установим инструмент ffuf, который является золотым стандартом для быстрого фаззинга веб-ресурсов:

sudo apt update && sudo apt install ffuf -y

Результат: утилита готова к работе, проверь установку командой ffuf -V

Создадим небольшой словарь потенциальных путей и запустим сканирование целевого узла с фильтрацией по кодам ответа:

# Фаззинг путей с отображением кодов 200, 301 и 403
ffuf -u http://localhost:8080/FUZZ -w /usr/share/wordlists/dirb/common.txt -mc 200,301,403

Результат: в консоли появится таблица с путями, которые вернули указанные статусы.

Исключаем ответы с размером 4242 байта, которые могут быть кастомной страницей 404:

ffuf -u http://localhost:8080/FUZZ -w dict.txt -fs 4242

Результат: в выводе останутся только те запросы, чей контент отличается от стандартной заглушки.

Команда для быстрой проверки доступности целевого URL перед началом фаззинга:

curl -I http://localhost:8080

🔥 Помни, что агрессивное сканирование легко детектируется системами защиты (WAF/IDS), поэтому всегда настраивай задержки между запросами.

➡️ DevOps Ready | #практика

✍️ TLDR Pages — короткая и полезная документация для командной строки!

Если ты устал от длинных и перегруженных man-документаций сохраняй этот репозиторий. Tldr-pages даёт короткие и практичные примеры команд для Linux, macOS и Windows: git, docker, ssh, grep, tar и сотен других утилит. Без теории и лишнего текста - только то, что действительно используют в работе.

Оставляю ссылочку: GitHub 📱

➡️ DevOps Ready | #ресурс

Низкоуровневый аудит процесса в Linux!

Когда top и htop уже не дают ответов, вся реальная картина состояния процесса находится в /proc.

Аргументы запуска процесса (argv):

cat /proc/PID/cmdline | tr '\0' ' '

Показывает текущие аргументы процесса. Полезно для диагностики, но argv может быть изменён самим процессом и не всегда отражает исходную команду запуска.

Пример вывода:

/usr/bin/python3 worker.py --queue=emails --env=prod

Память процесса:

cat /proc/PID/status | grep -E 'VmRSS|VmSize|VmSwap'

VmRSS — реально занятая RAM

VmSize — виртуальное адресное пространство процесса

VmSwap — объём, вытесненный в swap

Пример:

VmRSS:   412384 kB
VmSwap:   65536 kB

Детальная карта памяти процесса:

cat /proc/PID/smaps

Позволяет понять, где именно расходуется память: private, shared, file-backed. На больших процессах может быть тяжёлым.

Открытые файлы и сокеты процесса:

ls -l /proc/PID/fd

Здесь видны логи, сокеты, pipes и удалённые файлы, которые всё ещё удерживаются процессом (доступ зависит от прав).

Количество потоков внутри процесса:

ls /proc/PID/task | wc -l

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

Реальный исполняемый файл процесса:

readlink /proc/PID/exe

Права и capabilities процесса:

cat /proc/PID/status | grep Cap

🔥 Короткая практическая выжимка для анализа процессов на уровне procfs/ядра.

➡️ DevOps Ready | #практика