Использование Synology API для администрирования серверов CS2

Когда я только начинал поднимать серверы CS2 на Synology NAS, ручное управление через веб-интерфейс DSM казалось достаточным: зашёл, запустил процесс, иногда почистил демки. Но с ростом числа команд и турниров стало очевидно — такой подход не тянет. Автоматизация через Synology API превращает NAS из простого файлового хранилища в мозг инфраструктуры: мониторинг, бэкапы, перезапуск сервера — всё работает без моего участия, по событийной модели. В этой статье я покажу, как выстроить такую систему, начиная с аутентификации и заканчивая интеграцией с RCON и Telegram. Это не теория — это рабочие сценарии, которые я отладил на своих серверах.

Почему API критичен для инфраструктуры CS2

Ручное администрирование серверов CS2 через DSM — это как играть с завязанными глазами. Вы не видите реальной нагрузки, не можете мгновенно среагировать на зависание процесса, а демо-записи копятся, пока не забьют весь том. API Synology даёт программный доступ к ядру системы: вы можете писать скрипты на Python или Bash, которые напрямую дёргают методы DSM. Это переводит управление на новый уровень — от реактивного «ой, сервер упал» к проактивному «сервер сам перезапустился, а демки уже в облаке».

Ключевые преимущества автоматизации

Мониторинг в реальном времени. Через API я получаю метрики CPU, RAM и сети прямо в свои скрипты. Это позволяет настроить алерты: если нагрузка превышает порог, система сама перезапускает сервер или шлёт уведомление. Для турнирных матчей, где каждая миллисекунда на счету, такой контроль — не роскошь, а обязательное условие. Раньше приходилось постоянно держать открытым Resource Monitor, теперь всё приходит в логи и Telegram.
Автоматическое резервное копирование демо. Демки — это золото для аналитики. Раньше я вручную переносил их после каждого матча, теперь скрипт сам отслеживает новые .dem-файлы, пакует их и отправляет на отдельный том или в Synology C2. Место на диске не заканчивается, а тренер всегда имеет доступ к записям. Как показала практика, добавление даты в имя файла спасает от перезаписи.
Управление жизненным циклом сервера. Если процесс CS2 завис, скрипт может его убить и перезапустить, а перед этим подложить свежий server.cfg. Это избавляет от ночных звонков «сервер лёг, приезжай чинить». Система сама поддерживает сервер в боевом состоянии. Я обычно настраиваю проверку каждые 5 минут: если процесс не отвечает на RCON ping, идёт жёсткий перезапуск.
Интеграция с внешними системами. Данные о матчах — счёт, статистика — могут автоматически уходить на сайт турнира или в Telegram-канал команды. Это не просто удобно, это создаёт единую информационную среду, где все участники видят результаты сразу. Я, например, сделал бота, который после каждого матча публикует итоговый счёт и ссылку на демку.

Ограничения и нюансы

Новички часто ждут, что через Synology API можно напрямую рулить игрой: сменить карту, кикнуть игрока. Это не так. API работает на уровне ОС: файлы, процессы, ресурсы. Для команд внутри игры нужен RCON. Но в связке они творят чудеса: API перезапускает сервер, а RCON меняет карту после матча. Понимание этого разделения — ключ к архитектуре. Я сам поначалу потратил пару часов, пытаясь найти метод для отправки консольных команд, пока не осознал эту границу.

Архитектура Synology WebAPI и подготовка окружения

API Synology — это HTTP/HTTPS с JSON. Никаких SOAP или сложных схем. Но есть нюанс: почти все методы требуют авторизации через сессионный токен. Поэтому первый шаг всегда — получить SID. Я обычно начинаю с того, что вожусь с curl, пока не пойму, какие методы доступны на конкретной версии DSM. Документация Synology местами устарела, и реальные пути могут отличаться от описанных в мануалах.

Основные компоненты API

SYNO.API.Info: Это ваш компас. Без него вы будете гадать, по какому пути обращаться к FileStation. Я всегда начинаю скрипт с запроса к /webapi/query.cgi, чтобы актуализировать пути. В разных версиях DSM они могут отличаться, и жёстко прописанный путь рано или поздно сломается.
SYNO.API.Auth: Метод для входа. Возвращает SID и idToken. Я обычно сохраняю SID в переменную сессии и передаю во всех последующих запросах. Важно: idToken используется для «долгих» сессий, но я предпочитаю классический SID.
Сессионные куки (HTTP Session Cookie): После входа сервер устанавливает куку, но в скриптах проще работать с заголовком X-Synology-Sid. Библиотека requests в Python умеет автоматически подставлять SID, если его добавить в сессию.

Подготовка Synology NAS

Включение веб-сервера. Убедитесь, что порт веб-интерфейса DSM доступен (обычно 5000 для HTTP или 5001 для HTTPS). Для безопасности я рекомендую использовать HTTPS, даже внутри локальной сети. Самоподписанный сертификат подойдёт, если нет выхода в интернет, но для внешнего доступа лучше настроить Let’s Encrypt.
Создание пользователя с ограниченными правами. Никогда не используйте admin для скриптов. Я создаю пользователя cs2_api_user с правами только на нужные папки (например, /volume1/cs2_servers) и без доступа к другим ресурсам. Это спасло меня, когда скрипт с ошибкой пытался удалить не ту папку — прав не хватило. Принцип минимальных привилегий — основа безопасности.
Настройка доступа к API. В некоторых версиях DSM нужно явно разрешить API-доступ для пользователя в разделе «Права доступа к API». Проверьте это, иначе будете ловить 403 при любом запросе. Я обычно захожу в Панель управления → Права пользователей → вкладка API и ставлю галочку для нужного пользователя.

Инструментарий для разработки

curl: Идеален для быстрого тестирования без написания кода. Я часто использую curl, чтобы проверить доступность API или понять структуру ответа.
Python (библиотека requests): Мой основной инструмент. Сессии, автоматическая работа с куками, удобная обработка JSON — всё, что нужно для продакшена.
Postman: Графический интерфейс, который помогает визуализировать запросы и ответы. Удобен на этапе разведки, когда нужно быстро проверить несколько методов.

Пошаговая настройка аутентификации

Аутентификация — это фундамент. Если вы неправильно получили SID или не передали его в заголовке, все запросы уйдут в корзину с ошибкой 403. Я обычно трачу больше всего времени на отладку именно этого этапа. Процесс двухшаговый: сначала узнаём пути, потом логинимся.

Шаг 1: Получение списка доступных API (SYNO.API.Info)

Первый запрос всегда к /webapi/query.cgi. Он не требует авторизации и возвращает JSON со всеми доступными API. В ответе нас интересует path для SYNO.API.Auth и других нужных методов. Я обычно сохраняю весь ответ в файл, чтобы потом не дёргать лишний раз.

curl -X GET "https://your-nas-ip:5001/webapi/query.cgi?api=SYNO.API.Info&version=1&method=query"

Пример ответа (сокращён):

{
  "data": {
    "SYNO.API.Auth": {
      "path": "/webapi/auth.cgi",
      "maxVersion": 6,
      "minVersion": 1
    },
    "SYNO.FileStation": {
      "path": "/webapi/FileStation",
      "maxVersion": 2,
      "minVersion": 1
    }
  },
  "success": true
}

Обратите внимание: path для FileStation может быть /webapi/FileStation, а не /webapi/file.cgi, как иногда пишут в старых гайдах. Всегда проверяйте актуальный путь.

Шаг 2: Вход в систему (Login)

После получения пути к auth.cgi отправляем POST с учётными данными. Важно: используйте учётку, созданную специально для API. В ответе придёт SID — это ваш ключ. Я обычно сохраняю его в переменную окружения или файл, чтобы не логиниться каждый раз, но помню, что сессия живёт около часа.

curl -X POST "https://your-nas-ip:5001/webapi/auth.cgi?api=SYNO.API.Auth&version=6&method=login&account=cs2_api_user&passwd=your_password&session=Default"

Успешный ответ содержит sid и idToken:

{
  "data": {
    "sid": "abc123def456",
    "idToken": "xyz789"
  },
  "success": true
}

Код на Python для аутентификации

Вот готовый класс, который я использую в своих скриптах. Он сам получает список API, логинится и сохраняет SID в сессию. Дальше можно просто вызывать request. Это база, на которой строятся все сценарии.

import requests
import json

class SynologyAPI:
    def __init__(self, base_url, username, password):
        self.base_url = base_url
        self.username = username
        self.password = password
        self.session = requests.Session()
        self.sid = None
        self._load_api_info()

    def _load_api_info(self):
        resp = self.session.get(f"{self.base_url}/webapi/query.cgi",
                                params={"api": "SYNO.API.Info", "version": "1", "method": "query"})
        data = resp.json()
        if not data.get("success"):
            raise Exception("Failed to get API info")
        self.api_info = data["data"]

    def login(self):
        auth_info = self.api_info["SYNO.API.Auth"]
        url = f"{self.base_url}{auth_info['path']}"
        params = {
            "api": "SYNO.API.Auth",
            "version": auth_info["maxVersion"],
            "method": "login",
            "account": self.username,
            "passwd": self.password,
            "session": "Default"
        }
        resp = self.session.get(url, params=params)
        data = resp.json()
        if data.get("success"):
            self.sid = data["data"]["sid"]
            self.session.headers.update({"X-Synology-Sid": self.sid})
        else:
            raise Exception("Login failed")

    def request(self, api_name, method, version=None, **kwargs):
        if api_name not in self.api_info:
            raise Exception(f"API {api_name} not found")
        info = self.api_info[api_name]
        url = f"{self.base_url}{info['path']}"
        params = {
            "api": api_name,
            "version": version or info["maxVersion"],
            "method": method
        }
        params.update(kwargs)
        resp = self.session.get(url, params=params)
        return resp.json()

Управление файловой системой сервера CS2

Файловая система — это то, с чем вы будете работать чаще всего. Демки, конфиги, логи — всё лежит на дисках NAS. FileStation API даёт полный контроль: копировать, перемещать, удалять. Я обычно начинаю автоматизацию именно с архивации демо, потому что это сразу даёт ощутимую пользу и экономит часы ручного труда.

Основные методы FileStation

Метод	Описание	Применение для CS2
`list`	Получение списка файлов в директории	Проверка наличия новых демо-записей после матча
`download`	Скачивание файла	Экспорт демо для разбора с командой
`upload`	Загрузка файла	Обновление конфигурационных файлов (например, `server.cfg`)
`delete`	Удаление файла	Очистка старых логов и демо, чтобы не занимать место
`copy` / `move`	Копирование или перемещение	Архивация демо в папку `/backup/cs2_demos`
`mkdir`	Создание директории	Создание папок для новых турниров или сезонов

Метод list поддерживает фильтры по расширению, что позволяет сразу запрашивать только .dem-файлы. Это ускоряет работу и снижает нагрузку на NAS.

Сценарий 1: Автоматическая архивация демо-записей

Это мой любимый сценарий. После каждого матча сервер генерирует .dem-файлы. Скрипт каждые N минут проверяет папку, фильтрует новые файлы и переносит их в архивную директорию с добавлением даты. Так я никогда не теряю записи и не забиваю диск.

Алгоритм работы:

Вызвать метод list с фильтром по *.dem.
Сравнить с предыдущим списком (я храню его в текстовом файле или в памяти скрипта).
Для новых файлов вызвать move в /volume1/backup/cs2_demos/YYYY-MM-DD/.
Записать в лог пути к архивированным файлам.

Пример кода на Python:

def archive_demos(api, source_path, archive_base):
    # Получаем список демок в исходной папке
    resp = api.request("SYNO.FileStation", "list",
                       folder_path=source_path,
                       filter="*.dem")
    if not resp.get("success"):
        return

    files = resp["data"]["files"]
    # Создаём папку с текущей датой
    date_folder = datetime.now().strftime("%Y-%m-%d")
    archive_path = f"{archive_base}/{date_folder}"
    api.request("SYNO.FileStation", "mkdir",
                folder_path=archive_path,
                name="")

    for f in files:
        src = f["path"]
        # Перемещаем файл в архив
        api.request("SYNO.FileStation", "move",
                    path=src,
                    dest_folder_path=archive_path,
                    overwrite=False)
        print(f"Archived: {src} -> {archive_path}")

Важные нюансы:

Пути всегда начинаются с /volume1/ (или другого тома). Относительные пути не работают.
Если файл с таким именем уже существует в архиве, move с флагом overwrite=False вернёт ошибку. Я рекомендую добавлять к имени файла временную метку (например, demo_20260717_001.dem).
Для больших объёмов демок лучше использовать copy вместо move, чтобы избежать потери данных при обрыве соединения, и только после успешного копирования удалять оригинал.

Сценарий 2: Обновление конфигураций сервера

Часто перед матчем нужно подложить новый server.cfg с другими настройками. Вместо того чтобы лазить в File Manager, скрипт сам загружает файл через upload. Я обычно готовлю конфиг локально, тестирую, а затем скрипт отправляет его на сервер и перезапускает процесс.

Пример загрузки файла (упрощённый):

def upload_config(api, local_file, remote_folder):
    with open(local_file, 'rb') as f:
        files = {'file': (os.path.basename(local_file), f)}
        # FileStation upload требует multipart/form-data
        resp = api.session.post(
            f"{api.base_url}/webapi/FileStation/upload",
            params={
                "api": "SYNO.FileStation",
                "version": "2",
                "method": "upload",
                "path": remote_folder,
                "overwrite": "true"
            },
            files=files
        )
    return resp.json()

После загрузки скрипт может отправить RCON-команду exec server.cfg или перезапустить сервер, чтобы применить изменения.

Управление процессами и мониторинг сервера

Управление процессом CS2 — самая тонкая часть. API не умеет напрямую запускать игровые серверы, но даёт доступ к системным процессам и ресурсам. Я обычно комбинирую API для мониторинга и Task Scheduler для перезапуска. На старых DSM (до 7.0) API для процессов может отсутствовать, поэтому приходится использовать обходные пути.

Мониторинг ресурсов (SYNO.Core.System)

Мониторинг CPU и RAM — это глаза и уши. Если процесс CS2 начинает жрать 100% CPU, это верный признак, что он завис или вошёл в бесконечный цикл. Я настроил скрипт, который раз в минуту проверяет нагрузку и, если она выше порога, дёргает перезапуск.

Пример проверки нагрузки:

def check_server_health(api, cpu_threshold=90):
    resp = api.request("SYNO.Core.System", "get_cpu_usage")
    if resp.get("success"):
        cpu_usage = resp["data"]["cpu_usage"]
        if cpu_usage > cpu_threshold:
            print(f"Warning: CPU usage is {cpu_usage}%")
            return False
    return True

Аналогично можно проверять память и свободное место на диске. Я обычно добавляю проверку, что свободного места не менее 10%, иначе скрипт принудительно чистит старые логи.

Управление процессами (SYNO.Core.Process)

API для управления процессами доступен не на всех DSM. Там, где он есть, можно получить список процессов, найти PID сервера CS2 и убить его. Но я чаще использую обходной путь — Task Scheduler с bash-скриптом, потому что это надёжнее и не зависит от версии DSM.

Алгоритм перезапуска сервера при сбое:

Проверить нагрузку CPU (метод выше).
Если нагрузка критическая, получить список процессов через SYNO.Core.Process.list.
Найти PID процесса CS2 (обычно по имени или командной строке).
Вызвать SYNO.Core.Process.kill с этим PID.
Через 5 секунд запустить процесс снова (через вызов bash-скрипта или SYNO.Core.Process.run).

Пример получения списка процессов:

resp = api.request("SYNO.Core.Process", "list")
if resp.get("success"):
    for proc in resp["data"]["processes"]:
        if "cs2" in proc["name"].lower():
            print(f"Found CS2 process: PID={proc['pid']}")

Но повторю: на многих моих NAS этот API отсутствует. Поэтому я рекомендую сразу освоить Task Scheduler.

Использование Task Scheduler для периодических задач

Если API для процессов недоступен, Task Scheduler — ваш лучший друг. Я создаю задачу, которая запускает bash-скрипт каждые 5 минут. Скрипт проверяет наличие демок, архивирует, проверяет нагрузку и, если нужно, делает kill -9 процессу CS2 и запускает его снова. Это простой, но безотказный механизм.

Пример bash-скрипта для Task Scheduler:

#!/bin/bash
# Проверка, жив ли процесс CS2
if ! pgrep -f "cs2_server" > /dev/null; then
    echo "CS2 server is down, restarting..."
    /volume1/cs2_servers/start.sh
fi

# Архивация демок (можно вызвать Python-скрипт)
python3 /volume1/scripts/archive_demos.py

Настройте задачу в DSM: Панель управления → Планировщик задач → Создать → По расписанию. Укажите путь к скрипту и интервал.

Интеграция с внешними системами и RCON

RCON — это мостик к игровой консоли. Через него можно сменить карту, объявить о начале матча или перезапустить раунд. Synology API тут не помощник, но ваш Python-скрипт может легко подключиться к RCON-порту сервера. Я обычно использую библиотеку python-valve, она проста и надёжна.

Как это работает

Скрипт на Python/Bash запускается через API или Task Scheduler.
Скрипт использует библиотеку python-rcon (или python-valve) для подключения к порту RCON сервера CS2.
Через RCON отправляются команды: changelevel map_arena, sv_restart 1, say "Турнир начался".
Результат выполнения команды возвращается в скрипт и может быть записан в лог или отправлен в Telegram.

Пример интеграции RCON в скрипт

import rcon

def send_rcon_command(host, port, password, command):
    try:
        with rcon.RCON(host, port, password, timeout=5) as rcon_conn:
            response = rcon_conn.command(command)
            return response
    except Exception as e:
        print(f"RCON error: {e}")
        return None

# Использование: после архивации демо меняем карту
send_rcon_command("192.168.1.100", 27015, "rcon_password", "changelevel de_inferno")

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

Отправка уведомлений в Telegram

Уведомления в Telegram — это must have. Я настроил бота, который шлёт сообщения при сбоях, успешной архивации или начале матча. Это позволяет быть в курсе, даже если я не за компом.

import requests

def send_telegram_message(bot_token, chat_id, text):
    url = f"https://api.telegram.org/bot{bot_token}/sendMessage"
    payload = {"chat_id": chat_id, "text": text}
    requests.post(url, json=payload)

# Пример: уведомление о сбое
send_telegram_message("your_bot_token", "@your_channel", "⚠️ Сервер CS2 перезапущен из-за высокой нагрузки")

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

Типовые ошибки и способы их решения

За годы работы с API я наступил на все грабли. Вот самые частые ошибки и как их избежать.

Ошибка 403: Unauthorized

Причина: Неверный SID, сессия истекла или пользователь не имеет прав на доступ к API.

Решение: Я сначала грешил на права, а оказалось, что сессия умерла. Теперь в скрипте всегда проверяю ответ на 403 и автоматически перелогиниваюсь. Также убедитесь, что пользователь имеет права API в настройках DSM. Если сессия истекает слишком часто, можно увеличить время жизни сессии в DSM (не рекомендуется) или просто добавить обработчик.

Ошибка 404: Not Found

Причина: Неверный путь к API.

Решение: Всегда начинайте с SYNO.API.Info. Я один раз потратил полдня, потому что использовал путь из старой статьи, а в новой DSM он изменился. Проверьте, что path в ответе совпадает с тем, что вы используете.

Ошибка при загрузке файлов (Upload)

Причина: Неправильный формат multipart/form-data или отсутствие файла.

Решение: Используйте библиотеку requests с параметром files, как в примере выше. Проверьте, что путь к файлу на сервере существует и является директорией, а у пользователя есть права на запись. Я часто забывал про права и ловил 403.

Процесс не убивается (Kill)

Причина: Процесс запущен от другого пользователя или имеет приоритет.

Решение: Запускайте скрипт с правами root или пользователя, который запустил процесс CS2. Если обычный kill не работает, используйте kill -9 (SIGKILL). Но помните, что это жёсткое завершение, могут потеряться логи. Лучше сначала попробовать мягкий stop через RCON (команда quit).

Ограничения по количеству запросов

Причина: Synology может ограничивать количество запросов в секунду для защиты от перегрузки.

Решение: Добавляйте небольшие паузы (time.sleep(0.5)) между запросами в цикле. Для массовых операций (например, удаление 1000 файлов) разбивайте их на пакеты по 50-100 с паузой в 1-2 секунды. Я однажды положил веб-интерфейс DSM, отправив 200 запросов подряд без задержки.

Чек-лист для запуска автоматизации

Этот чек-лист я составил на основе своих запусков. Пройдитесь по нему перед тем, как запускать скрипты в продакшен.

Оборудование и сеть:
- [ ] Установить Synology NAS с достаточной мощностью (минимум 4 ядра CPU, 8GB RAM для CS2).
- [ ] Настроить статический IP-адрес для NAS в сети.
- [ ] Включить HTTPS (порт 5001) для безопасности.
Настройка DSM:
- [ ] Создать пользователя cs2_api_user с правами только на папку сервера.
- [ ] Проверить доступность веб-интерфейса извне (если нужно) или из локальной сети.
- [ ] Включить API в настройках безопасности (если требуется).
Разработка скрипта:
- [ ] Написать класс SynologyAPI (как в примере выше).
- [ ] Реализовать метод login и тестировать его через curl.
- [ ] Реализовать метод archive_demos для архивации файлов.
- [ ] Реализовать метод check_server_health для мониторинга CPU.
- [ ] Добавить интеграцию с RCON для смены карт.
- [ ] Добавить отправку уведомлений в Telegram.
Тестирование и запуск:
- [ ] Запустить скрипт вручную и проверить логи.
- [ ] Настроить Task Scheduler для периодического запуска (например, каждые 5 минут).
- [ ] Проверить работу в режиме реального времени (во время матча).
- [ ] Настроить мониторинг ошибок (если скрипт падает, отправлять уведомление).
Безопасность:
- [ ] Не хранить пароли в коде скрипта (использовать переменные окружения).
- [ ] Ограничить доступ к API только с локальных IP.
- [ ] Регулярно обновлять скрипт и проверять безопасность.

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

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

В: Можно ли управлять сервером CS2 только через Synology API?
О: Нет. Synology API управляет системой (файлами, процессами, ресурсами), но не консолью игры. Для команд внутри игры (смена карты, рестарт) используется RCON. Автоматизация строится на комбинации: API для управления файлами и процессами + RCON для команд игры. Я обычно строю связку: API для файлов и процессов, RCON для игровых команд.

В: Какой API лучше использовать для управления процессами?
О: В новых версиях DSM (7.x) доступен SYNO.Core.Process. В старых версиях его может не быть, и тогда управление процессами выполняется через стандартные команды Linux (через SYNO.Core.Terminal или Task Scheduler). Я предпочитаю Task Scheduler с bash-скриптами — это более универсально и не зависит от версии DSM.

В: Как часто нужно обновлять SID?
О: Сессия (SID) обычно живет 30-60 минут. В скриптах рекомендуется проверять статус сессии перед каждым запросом и автоматически выполнять login при ошибке 403. Я в своих скриптах перед каждым запросом делаю тестовый вызов, и если получаю 403, перелогиниваюсь. Так скрипт может работать сутками без присмотра.

В: Можно ли использовать API для обновления сервера CS2?
О: Да. Вы можете скачать новый бинарник SteamCMD через API (или через curl), заменить файлы в директории сервера через SYNO.FileStation.upload и перезапустить процесс. Однако для безопасности лучше использовать встроенный в SteamCMD механизм обновления (steamcmd.sh +quit). API я использую только для перезапуска после обновления.

В: Что делать, если API недоступен (ошибка 500)?
О: Проверьте версию DSM и наличие обновлений. Возможно, API временно недоступен из-за высокой нагрузки. В этом случае скрипт должен иметь механизм повторных попыток (retry) с паузой. Я обычно даю 3 попытки с экспоненциальной задержкой: 5, 10, 20 секунд.

В: Как защитить пароли в скрипте?
О: Используйте переменные окружения (например, export SYN_USER=... и export SYN_PASS=...), а не храните их прямо в коде. В Python можно использовать библиотеку os.environ. Я также рекомендую хранить секреты в отдельном файле с ограниченными правами (chmod 600).

В: Можно ли использовать API для мониторинга демо-записей в реальном времени?
О: API не поддерживает веб-сокеты для событий. Вам нужно периодически (например, каждые 5 минут) вызывать метод list и сравнивать список файлов с предыдущим состоянием. Для мгновенного уведомления можно использовать inotify на уровне ОС, но это уже не API.

В: Как настроить автоматическое обновление карты после матча?
О: Скрипт проверяет наличие нового демо-файла (через list). Если файл найден, скрипт отправляет RCON-команду changelevel map_next и архивует демо. Я также добавил проверку, что прошло достаточно времени с момента начала матча, чтобы не переключить карту раньше времени.

В: Какие ограничения есть у API по количеству запросов?
О: Synology не публикует жестких лимитов, но рекомендуется не делать более 10-20 запросов в секунду. Для массовых операций (удаление файлов) используйте пакеты. Я заметил, что больше 20 запросов в секунду начинают вызывать задержки, поэтому всегда ставлю паузы.

Заключение

Автоматизация через Synology API — это не просто «чтобы работало само». Это переход от кустарного администрирования к профессиональной инфраструктуре. Когда каждая демка сохранена, сервер не падает, а статистика уходит в Telegram, тренер и игроки могут сосредоточиться на игре, а не на технических проблемах.

Главное, что я вынес из своего опыта: начните с малого. Напишите скрипт архивации демо — он сразу сэкономит вам часы. Потом добавьте мониторинг, потом RCON. Постепенно вы построите систему, которая работает как часы. И помните: безопасность и минимальные привилегии — это не паранойя, а основа стабильности.

Я надеюсь, эта статья поможет вам сделать первый шаг. Если появятся вопросы — пишите на форум, будем разбираться вместе.