Какие плюсы и минусы у systemd в Linux-инфраструктуре?

Плюсы с точки зрения DevOps:

• Стандартизация управления сервисами: Единый интерфейс (systemctl) для всех дистрибутивов, упрощает написание idempотентных скриптов (Ansible, Terraform).
• Интеграция с cgroups: Позволяет легко ограничивать ресурсы (CPU, memory) для сервисов через CPUQuota= и MemoryLimit= в unit-файлах, что критично для плотной упаковки сервисов на хостах.
• Встроенные механизмы отказоустойчивости: Restart=, RestartSec=, StartLimitInterval= позволяют гибко настраивать политики перезапуска упавших процессов.
• Структурированное логирование через journald: Централизованный сбор логов всех сервисов с метаданными. Легко пересылать в fluentd или vector для дальнейшей агрегации.
• Таймеры (systemd.timer): Более надежная альтернатива cron, с интеграцией в журнал и зависимостями от других unit-файлов.

Минусы:

• Сложность отладки: Цепочки зависимостей (Requires=, Wants=) и сложные состояния сервисов могут затруднять поиск корневой причины проблемы при загрузке.
• Монолитный дизайн: Нарушает философию UNIX «делать одну вещь и делать ее хорошо». Поломка в одной части systemd может повлиять на всю систему.
• Собственный синтаксис конфигурации: Unit-файлы — это еще один язык конфигурации, который нужно знать, помимо скриптов оболочки.

Пример unit-файла для сервиса с ограничением ресурсов:

# /etc/systemd/system/my-api.service
[Unit]
Description=My API Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/my-api
Restart=on-failure
RestartSec=5
# Ограничение ресурсов через cgroups v2
MemoryMax=512M
CPUQuota=150%

[Install]
WantedBy=multi-user.target