Продвинутый

Навыки реальных инженеров: практические практики из .agents

Алексей Кузнецов
Алексей Кузнецов
Системный администратор30 октября 2026 г.12 мин чтения

Навыки реальных инженеров — практические рекомендации из .agents directory, основываясь на 12‑летнем опыте системного администрирования и домашней лаборатории.

ai-agents
ai-agents-skills
инженерные-практики
домашняя-лаборатория

Навыки реальных инженеров: практические практики из .agents

Навыки реальных инженеров — практические рекомендации из .agents directory, основываясь на 12‑летнем опыте системного администрирования и домашней лаборатории.

Контекст и цели инженерных навыков

Почему важен системный подход

Во-первых, системный подход позволяет превратить «пожар» в предсказуемый процесс. Когда каждый элемент инфраструктуры имеет задокументированный конфиг, проверяется через systemd и мониторируется, то не требуется гадать, почему сервис упал.

Справедливый пример: перед тем как менять параметр Nginx, я проверяю текущий статус и наличие резервной копии конфигурации. Команда выглядит так:

bash
# проверяем, что конфиг Nginx не менялся за последние сутки
sudo diff -u /etc/nginx/nginx.conf.orig /etc/nginx/nginx.conf | less

# если всё в порядке, применяем изменения и проверяем сервис
sudo nginx -t && sudo systemctl reload nginx

С практической точки зрения, такой порядок гарантирует, что после внесения правок сервис останется доступным, а откат можно выполнить за пару минут. Без этого подхода «настройка» часто заканчивается тем, что сайт становится недоступным, а логи показывают 502‑ошибки.

К тому же, системный подход упрощает передачу знаний между коллегами. Если у инженера есть documented workflow, любой, кто знаком с systemd и journald, сможет быстро вникнуть в проблему, не тратя время на расшифровку «что делал предыдущий админ».

Наконец, предсказуемость – это не просто удобство, а требование к надёжности. В моей практике (12 лет администрирования) именно системный подход позволил поддерживать серверы без перебоев годами, а не «починить как попало».

Опыт из .agents directory

Опыт, собранный в .agents directory, показывает несколько практических приёмов, которые я использую в своей домашней лаборатории и в продакшене:

  1. Версионирование конфигураций
    Все файлы /etc/ и каталоги с docker‑compose лежат в git‑репозитории. Пример commit‑сообщения:

    bash
    git commit -am "Update docker‑compose for web‑app: add healthcheck for redis"

    Это позволяет откатываться к предыдущей версии в один клик и видеть, кто и когда изменил настройки.

  2. Автоматизация рутинных задач
    Для регулярных операций (например, очистка журналов, проверка диска) я использую systemd‑таймеры. Файл cleanup-journal.service:

    ini
    [Unit]
Description=Очистка старых журналов

[Service]
Type=oneshot
ExecStart=/usr/bin/journalctl --vacuum-time=7d

    И соответствующий таймер cleanup-journal.timer, запускаемый ежедневно в 02:00.

  3. Репроизводимые среды с Docker Compose
    Для тестирования новых сервисов я собираю docker‑compose файл, где каждый сервис имеет свою версию и ограничения ресурсов. Пример фрагмента:

    yaml
    version: "3.8"
services:
  db:
    image: postgres:15-alpine
    restart: unless-stopped
    volumes:
      - db_data:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: "512M"

redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes"]

    Такой подход гарантирует, что «работает у меня на ноутбуке», будет работать и на продакшене, что упрощает отладку.

  4. Снимки и резервное копирование ZFS
    На TrueNAS я использую zfs snapshot перед любыми крупными изменениями. Команда выглядит так:

    bash
    sudo zfs snapshot tank/data@pre-upgrade-$(date +%Y%m%d%H%M)

    При необходимости откат происходит мгновенно: sudo zfs rollback tank/data@pre-upgrade-202409151200.

  5. Мониторинг и алерты
    В моей практике мониторинг – это не «чтобы видеть, когда всё в порядке», а «чтобы знать, когда что‑то сломалось». Prometheus + Alertmanager настроены так, что при превышении загрузки CPU более 80 % на любой ноде приходит уведомление в Telegram. Пример правила в alert_rules.yml:

    yaml
    groups:
  - name: cpu_load
    rules:
      - alert: HighCpuLoad
        expr: node_cpu_seconds_total{mode="system"}[5m] > 0.8
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Высокая загрузка CPU на {{ $labels.instance }}"
          description: "CPU загрузка превысила 80% в течение 10 минут."

Эти приёмы, описанные в .agents directory, позволяют держать инфраструктуру под контролем, минимизировать риск «пожара» и быстро реагировать на любые отклонения. Всё это вписывается в общую концепцию системного подхода: всё документировано, проверяемо и воспроизводимо.

Инструменты и инфраструктура реального инженера

Docker и контейнеризация

Во-первых, Docker — это не просто «упаковка», а способ описать зависимости и параметры контейнера в виде кода. На практике я собираю стек из трёх сервисов: Plex для медиа, Nextcloud для файлообмена и контейнер резервного копирования. Всё это описывается в одном docker‑compose.yml, который хранится в репозитории домашнего сервера.

yaml
version: "3.9"
services:
  plex:
    image: linuxserver/plex
    container_name: plex
    restart: unless-stopped
    ports:
      - "32400:32400/tcp"
    volumes:
      - /mnt/storage/media:/config/media
      - /mnt/storage/config:/config
    environment:
      - PLEX_CLAIM=xxx
    networks:
      - internal

  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - /mnt/storage/nextcloud:/var/www/html/data
      - /mnt/storage/nextcloud/config:/var/www/html/config
    environment:
      - MYSQL_PASSWORD=strong_password
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db
    depends_on:
      - db
    networks:
      - internal

  backup:
    image: alpine
    container_name: backup
    restart: unless-stopped
    volumes:
      - /mnt/backup:/backup
    entrypoint: ["/bin/sh", "-c", "while true; do rsync -a /config/ /backup/ && sleep 86400; done"]
    networks:
      - internal

  db:
    image: mariadb:10.11
    container_name: db
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=root_secret
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=strong_password
    volumes:
      - db_data:/var/lib/mysql
    networks:
      - internal

networks:
  internal:

volumes:
  db_data:

Команда docker compose up -d поднимает весь стек, а docker compose down останавливает и удаляет контейнеры. Для очистки неиспользуемых образов удобно выполнить docker system prune -f.

Если требуется изменить параметр, например, добавить переменную окружения, достаточно отредактировать файл и перезапустить сервис командой docker compose up -d <service>.

При работе с контейнерами, где данные должны сохраняться после удаления контейнера, использую volume‑монтирование, как в примере выше. Это избавляет от потери конфигураций и медиа‑библиотек.

Proxmox и кластерная архитектура

Справедливо, один сервер — это уже не то, что называется «домашняя лаборатория». Я построил кластер из трёх узлов на базе Proxmox VE, каждый из которых оборудован одинаковым оборудованием (Dell PowerEdge R730) и подключён к общему хранилищу на TrueNAS (48 ТБ ZFS).

Для создания кластера сначала на каждом узле запускаю pvecm create <hostname>:

bash
# на первом узле (pve-01)
pvecm create pve-01

На втором узле (pve-02) добавляю его в уже существующий кластер:

bash
pvecm add 192.168.1.101

Третий узел (pve-03) подключаю аналогично. После этого проверяю статус:

bash
pvecm status

Кластер использует corosync для синхронизации состояния. Файл /etc/pve/corosync.conf содержит список узлов и параметры таймаутов, но менять его вручную не рекомендуется — делайте это через веб‑интерфейс Proxmox.

Для размещения виртуальных машин и контейнеров я использую ZFS‑томы, экспортируемые через NFS. На TrueNAS создаю share:

bash
zfs create -o mountpoint=none -o sharetype=NFS -o compression=lz4 tank/data/vm
zfs set sharenfs=1 tank/data/vm

На каждом узле Proxmox монтирую этот NFS‑share в /etc/pve/nfs-storage:

bash
echo "192.168.1.20:/data/vm  /etc/pve/nfs-storage  nfsvers=4  rw,noatime  0 0" >> /etc/pve/nfs-storage

Теперь при создании новой ВМ указываю путь к диску в ZFS‑томе, например:

bash
qm create 101 --memory 2048 --cores 2 --net0 virtio,bridge=vmbr0,ostype lxc --disk /etc/pve/nfs-storage/vm/disk-101-disk-0.img

Для резервного копирования кластера применяю vzdump, планируя задачу через cron на одном из узлов:

cron
0 2 * * * /usr/bin/vzdump 101 --mode snapshot --compress lzo --mailto backup@example.com

Таким образом, при сбое любого узла остальные продолжают работать, а данные остаются доступными через общий NFS‑share.

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

Справедливо, такой подход обеспечивает предсказуемость конфигураций, а также упрощает мониторинг и алертинг через Prometheus и Grafana, которые я разворачиваю в отдельном контейнере Docker и подключаю к сети internal.

Во-первых, Docker — это описательная модель, а Proxmox — это инфраструктура, позволяющая управлять виртуализацией и хранилищем в единой экосистеме. Если придерживаться этих практик, домашняя лаборатория будет работать стабильно годами, а не «на коленке».

Автоматизация и надёжность конфигураций

Ansible для стабилизации

Во-первых, Ansible позволяет описать желаемое состояние системы в виде кода, а не вручную менять каждый сервер. Это особенно удобно в домашней лаборатории, где ноды могут перезапускаться или получать новые IP‑адреса.

В моём случае инвенторий выглядит так:

yaml
# inventory.ini
[homelab]
winnie = ansible_host=192.168.1.10
piglet = ansible_host=192.168.1.11
sova = ansible_host=192.168.1.12

Все хосты названы в честь персонажей «Винни‑Пуха», что упрощает ориентацию в списке.

Базовый playbook, который гарантирует установленную базовую пакетную группу и актуальные конфиги, выглядит так:

yaml
# site.yml
- hosts: homelab
  become: true
  vars:
    essential_packages:
      - docker
      - docker-compose
      - nginx
  tasks:
    - name: Установить необходимые пакеты
      apt:
        name: "{{ essential_packages }}"
        state: present
        update_cache: yes

    - name: Скопировать конфиг nginx
      copy:
        src: files/nginx.conf
        dest: /etc/nginx/nginx.conf
        owner: root
        group: root
        mode: '0644'
      notify: Перезапустить nginx

    - name: Убедиться, что Docker запущен
      systemd:
        name: docker
        state: started
        enabled: true

Обратите внимание на раздел «notify» – обработчик, который будет выполнен только при изменении конфигурации, что делает процесс предсказуемым.

Для автоматического обновления playbook‑а используется ansible-pull:

bash
git clone https://github.com/your/repo.git
cd repo
ansible-pull -i inventory.ini site.yml --checkout main

Эта команда Pull‑репозитория, скачивает свежий playbook и применяет его к текущим узлам. Таким образом, любые изменения в конфигурации сразу попадают на все серверы без необходимости вручную запускать ansible-playbook.

Источник: официальная документация Ansible – https://docs.ansible.com/ansible/latest/user_guide/playbooks.html

Systemd как основа управления сервисами

Системный менеджер systemd – это не просто «служба», а полностью fledged‑фреймворк для контроля процессов, их зависимостей, логирования и автоматического восстановления. В домашней лаборатории я использую его для всех критичных сервисов: Plex, Nextcloud, бэкапов и даже для собственного ansible-pull.

Пример unit‑файла для сервиса Plex

ini
# /etc/systemd/system/plexmediaserver.service
[Unit]
Description=Plex Media Server
After=network.target

[Service]
User=plex
Group=plex
ExecStart=/usr/local/bin/plexmediaserver
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
Environment=TZ=Europe/Moscow

[Install]
WantedBy=multi-user.target

Ключевые моменты:

  • After=network.target гарантирует, что сеть будет инициализирована до старта сервиса.
  • Restart=on-failure и RestartSec=5 позволяют системе автоматически перезапускать процесс при падении.
  • LimitNOFILE поднимает открытые файлы, что важно для медиасервера, работающего с большим количеством потоков.

После размещения файла активируем его:

bash
systemctl daemon-reload
systemctl enable plexmediaserver.service
systemctl start plexmediaserver.service

Проверить статус можно командой:

bash
systemctl status plexmediaserver.service

Вывод покажет PID, состояние и последние строки журнала, что упрощает диагностику.

Таймер для автоматических бэкапов

ini
# /etc/systemd/system/backup.timer
[Unit]
Description=Таймер для выполнения резервного копирования

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

ini
# /etc/systemd/system/backup.service
[Unit]
Description=Бэкап домашней лаборатории

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

bash
systemctl enable --now backup.timer

Таймер будет запускать backup.sh каждый день в 02:30, а Persistent=true гарантирует, что пропущенные запуски будут выполнены после перезагрузки сервера.

Источник: man page systemd.timer – https://manpages.debian.org/systemd-manpages/unstable/systemd.timer.5.html

Во-первых, Ansible делает конфигурацию воспроизводимой и проверяемой, а Systemd обеспечивает предсказуемое управление процессами. Вместе они формируют основу надёжной домашней инфраструктуры, где каждое изменение имеет чёткий след в журнале и легко откатывается при необходимости. Если понадобится более детальная настройка – смотрите конкретные примеры в репозитории, где каждый playbook и unit‑файл сопровождаются комментариями, объясняющими «почему» именно так.

Мониторинг и поддержка в домашней лаборатории

Prometheus и Grafana для оповещений

Во-первых, мониторинг — это фундамент предсказуемости работы любой лаборатории. На домашнем сервере удобно использовать Prometheus для сбора метрик и Alertmanager — для оповещений, а Grafana — для визуализации.

Сначала установите необходимые экспортеры. На примере Ubuntu 22.04:

bash
# node_exporter (сбор метрик ОС)
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.0/node_exporter-1.8.0.linux-amd64.tar.gz
tar xvf node_exporter-1.8.0.linux-amd64.tar.gz
sudo mv node_exporter-1.8.0.linux-amd64/node_exporter /usr/local/bin/
sudo useradd --no-create-home --shell /usr/sbin/nologin node_exporter

yaml
# prometheus.yml (пример конфигурации)
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'docker'
    static_configs:
      - targets: ['localhost:9323']

yaml
# alertmanager.yml (пример простого правила)
global:
  resolve_timeout: 5m

route:
  receiver: 'mail-receiver'

receivers:
  - name: 'mail-receiver'
    email_configs:
      - to: 'admin@example.com'
        from: 'alertmanager@example.com'
        smarthost: 'smtp.example.com:587'

Правило оповещения — пример, когда CPU превышает 80 % в течение 5 минут:

yaml
groups:
  - name: home_lab
    rules:
      - alert: HighCpuUsage
        expr: node_cpu_seconds_total{mode="system"} > 0.8
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокий CPU на {{ $labels.instance }}"
          description: "CPU системного времени выше 80 % уже 5 минут."

Для отправки уведомлений в Telegram удобно добавить веб‑хуук:

yaml
  - name: 'telegram-notifications'
    telegram_configs:
      - api_url: 'https://api.telegram.org/bot<TOKEN>/sendMessage'
        chat_id: '<CHAT_ID>'
        send_resolved: true

Grafana подключается к Prometheus через datasource. В интерфейсе Grafana создайте дашборд, где будет отображаться:

  • график нагрузки CPU (Prometheus query avg by (instance) (rate(node_cpu_seconds_total{mode="system"}[5m])));
  • список активных Docker‑контейнеров (query up{job="docker"}).

Официальная документация Prometheus
Alertmanager configuration
Grafana datasource setup

С практической точки зрения, после того как базовый набор метрик работает, добавьте exporter‑ы для ZFS (zfs_exporter) и Docker‑контейнеров, а также настройте автоматическое перезапускание Alertmanager при изменении конфигурации (systemctl restart alertmanager).

ZFS и резервное копирование

Во-первых, ZFS — это не просто файловый система, а набор механизмов snapshots, репликации и проверки целостности. Для домашней лаборатории с тремя нодами Proxmox + TrueNAS (48 ТБ)Snapshot‑ы позволяют быстро откатиться к рабочему состоянию.

Создайте базовый dataset:

bash
zfs create -o compression=lz4 -o atime=off tank/data

Сделайте snapshot с текущей датой:

bash
zfs snapshot tank/data@$(date +%Y-%m-%d)

Для отправки снапшота на резервный сервер (например, отдельный TrueNAS) используйте zfs send/zfs receive:

bash
zfs send -R tank/data@$(date +%Y-%m-%d) | ssh user@backup zfs receive -F backup/tank/data

Для автоматизации можно добавить cron‑запись, которая будет создавать ежедневный snapshot и отправлять его на удалённый хост:

bash
# /etc/cron.d/zfs-backup
0 2 * * * root /usr/sbin/zfs snapshot tank/data@$(date +\%Y-\%m-\%d) && \
    /usr/sbin/zfs send -R tank/data@$(date +\%Y-\%m-\%d) | ssh user@backup zfs receive -F backup/tank/data

Если у вас есть несколько нод, удобно настроить репликацию в самом ZFS:

bash
zfs send -R tank/data@snap | ssh user@replica zfs receive -F tank/data

Для VM‑образов, запущенных в Proxmox, рекомендуется использовать zfs send/receive на уровне dataset, а не только через vzdump. Это обеспечивает согласованность файловой системы и экономит место за счёт deduplication.

Официальная документация ZFS
Proxmox ZFS guide

С практической точки зрения, после налаживания репликации проверяйте целостность snapshot‑ов командой zfs scrub — это гарантирует, что данные не испорчены. Регулярные тесты восстановления (например, zfs rollback) помогут убедиться, что ваш бэкап действительно рабочий.

Если вы используете Grafana для визуализации ZFS‑метрик, подключите zfs_exporter и добавьте в дашборд графики использованного пространства, соотношения ошибок и статуса pool‑ов. Это даст вам быстрый обзор health‑а вашей хранилищной инфраструктуры.

Часто задаваемые вопросы

Как безопасно вносить изменения в конфигурацию без риска простоя?

Во-первых, сравните текущий файл с резервной копией, используя diff, чтобы убедиться, что изменения минимальны. Затем проверьте синтаксис команды (например, nginx -t), после чего перезагрузите сервис через systemctl reload. При необходимости подготовьте быстрый откат — сохраните оригинальный файл в Git или сделайте копию вручную, чтобы при проблемах вернуть состояние за пару минут.

Как лучше вести историю изменений конфигураций серверов?

Все файлы в /etc/ и каталоги с docker‑compose размещайте в Git‑репозитории, делая коммиты после каждой логической правки. В сообщении коммита указывайте суть изменения и, при возможности, номер tickets или дату. Это позволяет быстро отследить, кто и когда изменил конфиг, а также использовать git revert для мгновенного отката.

Что делать, если после изменения сервис перестал работать?

Сразу проверьте статус сервиса командой systemctl status <service> и просмотрите журнал journalctl -u <service> за последние минуты. Если ошибка связана с конфигурацией, откатите файл к предыдущей версии через Git или восстановите его из резервной копии, затем перезапустите сервис. При повторяющихся сбоях включите дополнительный мониторинг или алерт, чтобы получать уведомление о падении сразу.

Как убедиться, что внесенные изменения не нарушают работу мониторинга?

После применения правки проверьте метрики в Prometheus или Grafana, убедившись, что ключевые индикаторы (CPU, память, сетевой трафик) остаются в обычных пределах. Запустите несколько тестовых запросов к сервису и проверьте, что логи не содержат новых ошибок. Если есть алерты, убедитесь, что они не сработали в течение ожидаемого периода, и при необходимости доработайте правила оповещений.

Поделиться:TelegramX / TwitterVK