🔍 systemd-analyze: что тормозит загрузку Linux

systemd-analyze — встроенный инструмент для диагностики. Показывает какие сервисы жрут время при старте и где система простаивает.

Быстрая диагностика

Проверить общее время загрузки:


Результат:

Startup finished in 3.2s (firmware) + 2.1s (loader) + 
1.8s (kernel) + 12.4s (userspace) = 19.5s

Сразу видно проблему — userspace съел 12 секунд из 19. Копаем дальше.

Смотрим топ медленных сервисов:

systemd-analyze blame

8.234s postgresql.service
2.891s docker.service
1.456s NetworkManager-wait-online.service
0.234s nginx.service

PostgreSQL стартует 8 секунд. Может база огромная, либо что-то не так с конфигом.

Сервисы запускаются не параллельно, а друг за другом по зависимостям:

systemd-analyze critical-chain

graphical.target @19.2s
└─multi-user.target @19.1s
  └─postgresql.service @10.8s +8.2s
    └─network.target @10.7s
      └─NetworkManager.service @8.2s +2.4s

Видно: postgresql ждёт сеть, сеть ждёт NetworkManager. И все остальные сервисы встали в очередь за базой.

График покажет картину целиком:

systemd-analyze plot > boot.noscript
firefox boot.noscript

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

Узнать время старта отдельного сервиса:

systemd-analyze blame | grep nginx

Или посмотреть его зависимости:

systemd-analyze critical-chain nginx.service

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🍷 Свежий Wine

Wine 11.0 вышел после года разработки и тысяч правок. Основные новинки: ARM64EC архитектура, улучшенная поддержка HiDPI, Wayland по умолчанию и экспериментальный FFMPEG-бэкенд для мультимедиа.

➡️ Анонс

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📝 touch — недооценённая команда

Все знают touch как «создать пустой файл». Но это лишь верхушка айсберга.

Что на самом деле делает touch:

Обновляет временные метки файла (access time, modification time). Создание файла — побочный эффект, если файл не существует.

Базовое использование:

# Создать пустой файл
touch app.log

# Обновить время изменения существующего файла
touch config.yaml

# Создать несколько файлов
touch file1.txt file2.txt file3.txt

Продвинутые флаги:

# Установить конкретное время
touch -t 202501150830.00 file.txt
# Формат: [[CC]YY]MMDDhhmm[.ss]

# Установить время как у другого файла
touch -r reference.txt target.txt

# Изменить только access time
touch -a file.txt

# Изменить только modification time  
touch -m file.txt

# Не создавать файл, если не существует
touch -c file.txt

Полезные комбинации:

# Создать структуру директорий с файлами
mkdir -p app/{config,logs,data}
touch app/config/.gitkeep app/logs/.gitkeep

# Найти файлы старше 30 дней и "омолодить"
find /tmp -type f -mtime +30 -exec touch {} \;

# Обновить timestamp только если файл существует
[ -f config.json ] && touch config.json

# Создать файл с правами в одну команду
(umask 077 && touch secret.key)

touch — это швейцарский нож для работы с временными метками и файловыми операциями.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🐳 Секреты из .env в Docker

Мы уже говорили, что переменные из .env файлов при сборке Docker-образов запекаются в слои навсегда. Вот свежий кейс от команды, где ключи БД и токены оказались доступны всем.

Что пошло не так

В Dockerfile скопировали .env в контекст или использовали в RUN-командах. Результат: docker history показывает секреты, любой pull видит их в inspect.

Фикс и лучшие практики

Передавайте через --env-file только на runtime. Для build ARG без дефолтов и --build-arg снаружи. Multi-stage сборка сбрасывает промежуточные слои с данными.

➡️ Живой пример | Зеркало

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#разбор_полётов

🤩 QR-коды чистым SQL в PostgreSQL

Разработчик проснулся рано из-за кота и за час с помощью ИИ написал генератор QR-кодов одним SQL-запросом для Postgres.

Никаких расширений или библиотек не нужно, просто выполним скрипт:

psql -qf pqr.sql -v payload='Hello, World!'

И на выходе нас ждёт QR-код.

➡️ Скрипт забираем здесь

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

🏭 Трудоголики снова в моде

Что происходит, когда рынок из «кандидатского» превращается в «работодательский»? Культ личной эффективности вместо командной работы, up-or-out вместо саббатикала, и «работай или уходи» вместо «мы о тебе заботимся».

2026 год в IT — это конец иллюзии про дружескую атмосферу в офисе и начало честной истории про трудоголизм как норму выживания.

➡️ Узнать в этом кто виноват

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

😤 «Я ненавижу GitHub Actions всей душой»

Разработчик написал эмоциональный текст о том, почему GitHub Actions — это боль. Переводим и разбираем аргументы.

Главные претензии:

1. YAML-ад:

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm ci
      - run: npm test

Выглядит просто? Но здесь довольно просто докинуть багов:

• Опечатка в node-version → silent fail
• Забыл @v3 в actions → неожиданная версия
• Отступы не там → непонятная ошибка

2. Дебаг — это пытка

В других CI можно:

• Подключиться по SSH к раннеру
• Запустить локально (GitLab Runner)
• Посмотреть полные логи

В GitHub Actions:

• Логи обрезаны
• Нельзя зайти на раннер
• Локальный запуск через костыли (act)
• Цикл «коммит → push → wait → fail» занимает минуты

3. Секреты — русская рулетка:

- name: Deploy
  env:
    API_KEY: ${{ secrets.API_KEY }}
  run: ./deploy.sh

Проблемы:

• Секрет не установлен? Пустая строка
• Опечатка в имени? Пустая строка
• Секрет в форке? Не работает
• Дебажить? Удачи, secrets маскируются в логах

4. Кеширование — лотерея:

- name: Cache node modules
  uses: actions/cache@v3
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

Проблемы:

• Кеш иногда не восстанавливается
• Иногда восстанавливается битый кеш
• Лимит 10 GB → старые кеши удаляются

5. Версии actions — dependency hell:

- uses: actions/checkout@v3      # Какая v3? v3.0? v3.5?
- uses: actions/setup-node@v3    # Deprecated через месяц
- uses: docker/build-push-action@v4  # Ломает старые workflow

• Нет lock-файла для actions
• Breaking changes в минорных версиях
• @main — может сломаться завтра
• @sha — нечитаемо и надо обновлять вручную

💬 Как у вас с GitHub Actions? Всё спокойно или тоже есть дровишки в огонь?

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

🏷 Теги и лейблы в Terraform как привычка

Ресурсы без тегов почти всегда превращаются в невидимые расходы и в проблемы с управлением. Если навести порядок в тегах прямо в Terraform модулях, инфраструктуру проще искать, считать и контролировать.

Лучше начинать со схемы на уровне модуля. У каждого модуля должен быть входной map для tags или labels и этот map должен применяться ко всем ресурсам, которые это поддерживают. Идея простая. В модуле есть базовые поля вроде окружения и владельца, а сверху можно передать дополнительные теги и объединить их через мерж.

Пример:

variable "environment" {
  type = string
}

variable "owner" {
  type = string
}

variable "tags" {
  type        = map(string)
  denoscription = "Общие теги для всех ресурсов"
  default     = {}
}

locals {
  common_tags = merge(
    {
      env       = var.environment
      owner     = var.owner
      terraform = "true"
    },
    var.tags
  )
}

resource "proglib_bucket" "this" {
  bucket = var.owner

  tags = local.common_tags
}

Последний шаг это запрет на ресурсы без обязательных тегов. Это можно сделать через policy as code и проверки, чтобы не разгребать мусор уже в проде.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

👀 Наглядная иерархия процессов в Linux

systemd-cgls — это утилита для отображения иерархии control groups в системах на базе systemd. Она показывает древовидную структуру всех процессов, сгруппированных по юнитам systemd.

В отличие от классического ps или top, systemd-cgls показывает не просто список процессов, а их организационную структуру: какие процессы принадлежат каким службам, сессиям пользователей и слайсам системы.

Просто запустите без аргументов:

systemd-cgls

Вы увидите дерево, разделённое на слайсы:

• system.slice — системные службы
• user.slice — пользовательские сессии
• machine.slice — виртуальные машины и контейнеры

Показать только конкретный юнит:

systemd-cgls /system.slice/nginx.service

Показать процессы определённого пользователя:

systemd-cgls /user.slice/user-1000.slice

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

👨‍💻 COPY с chown и меньше боли с правами

Если в контейнере приложение запускается не от root, то права на файлы часто ломают сборку или запуск. Вместо отдельного RUN chown можно сразу копировать файлы с нужным владельцем через COPY с флагом chown.

Простой пример для приложения, которое запускается от appuser:

FROM alpine:3.20

RUN addgroup -S app && adduser -S -G app appuser

WORKDIR /app

COPY --chown=appuser:app . /app

USER appuser
CMD ["./app"]

Если в образе нет /etc/passwd или /etc/group, и указать имя пользователя или группы, сборка может упасть, поэтому для минимальных образов иногда проще использовать числовые UID и GID.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

🗞 Первая рабочая неделя

Собрали для вас новости и материалы прошедшей недели.

— Трудоголики снова в моде

— Свежий Wine

— Когда ls уже не впечатляет

— Linux Mint 22.3 Zena

— SSD за грамм стали дороже золота

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#дайджест_недели

➕ HEALTHCHECK в Dockerfile чтобы контейнер не умирал молча

Контейнер может продолжать работать, даже если внутри уже все сломалось. HEALTHCHECK позволяет Docker периодически проверять состояние и выставлять статус healthy или unhealthy.

Самый простой вариант это дергать внутренний эндпоинт и падать по ненулевому коду, если ответ плохой. Docker поддерживает параметры interval, timeout и retries, чтобы настроить частоту и порог ошибок.

Пример:

HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

Команда может быть любой, главное чтобы успешный результат был exit 0, а неуспешный exit 1.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

🔒 Let’s Encrypt выкатили сертификаты на шесть дней

Let’s Encrypt добавили короткоживущие сертификаты со сроком 160 часов. Это чуть больше шести дней. Чем меньше срок, тем меньше ущерб, если ключ утек.

Подключение сделано как опция. В ACME клиенте нужно выбрать профиль shortlived, и дальше все упирается в автоматизацию выпуска и продления. Если продление не автоматизировано, такой срок будет раздражать и ломать процессы.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

💼 DevOps-портфолио: что включить и как собирать

70% работодателей выбирают кандидатов с hands-on проектами. В DevOps это особенно критично — здесь нужно доказать, что вы умеете автоматизировать, масштабировать и решать задачи. Портфолио — это ваш главный козырь.

Что включить:

🔹 CI/CD пайплайн. Jenkins, GitHub Actions, GitLab CI или CircleCI. Покажите автоматическую сборку, тестирование, деплой с rollback и уведомлениями.

🔹 Infrastructure as Code. Terraform, CloudFormation или Ansible. Разверните веб-приложение с версионируемой инфраструктурой в облаке.

🔹 Контейнеризация. Docker + Kubernetes или Docker Swarm. Контейнеризуйте приложение и разверните его с оркестрацией.

🔹 Мониторинг и логирование. Prometheus + Grafana или ELK stack. Настройте систему отслеживания и алертов в реальном времени.

🔹 Автоматизация безопасности. Интеграция сканирования уязвимостей в пайплайн или автоматизация compliance-проверок.

Где брать идеи:

• Изучите вакансии — воссоздайте описанное окружение

• Автоматизируйте личный проект, например, деплой блога через CI/CD)

• Контрибьютьт в open-source инфраструктурные проекты

• Используйте free tier AWS/Azure/GCP для экспериментов

• Участвуйте в хакатонах и челленджах

Как оформить:

✅ Создайте личный сайт или блог (можно на GitHub Pages)

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

✅ Добавьте README с инструкциями по запуску

✅ Приложите скриншоты дашбордов, пайплайнов, логов

✅ Опишите проблемы и как их решили


💬 А у вас есть портфолио? Что туда включаете? Помогло ли на собеседованиях? Делитесь ссылками и опытом в комментариях! 👇

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#холиварня

🔥 Полигон для драйверов FreeBSD

ChaosBSD — форк FreeBSD, который существует по одной простой причине: upstream не может и не должен принимать сломанные драйверы, полуработающее железо, вендорский мусор или спекулятивные хаки.

Иными словами это лаборатория для издевательств над железом или полигон для разработки драйверов: портирование, реверс-инжиниринг, clean-room реализации.

Идеальный проект для тех, кто хочет поэкспериментировать с диким железом, не ломая прод.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии