# Задачи поддержки базового комплекса DetMir

Документ описывает задачи сопровождения того комплекса серверов,
виртуализации, сетевых сервисов и прикладного ПО, который существовал до
начала разработки AWatch-rus.

AWatch-rus, ActivityWatch-коллекторы, новые дашборды, новые контуры
телеметрии, ClickHouse-аналитика AWatch-rus и разработка продукта в этот
объем не входят. Их нужно оформлять отдельной следующей задачей.

Документ является рамочным ТЗ на постоянную техническую поддержку базового
контура. Он не заменяет договор, перечень доступов, инвентарную ведомость и
схему сети, но задает границы работ, ожидаемый режим сопровождения и результат,
который должен получать владелец.

## Цель поддержки

Поддержка должна обеспечивать штатную работу базовой ИТ-инфраструктуры
DetMir: серверы доступны, виртуальные машины запущены, web-сервер и
прикладное ПО отвечают штатно, данные сохраняются, резервные копии создаются,
удаленный доступ контролируется, а аварии устраняются с понятной фиксацией
причины.

## Границы ответственности

В рамках этой поддержки исполнитель отвечает за техническое сопровождение
существующего базового контура: диагностику, регламентные проверки,
административные настройки, восстановление штатной работы и документирование
изменений.

В поддержку входят только те серверы, сервисы, сетевые устройства, VM/CT,
правила доступа, VPN-подключения, web-сайты, базы данных и файловые каталоги,
которые переданы владельцем как часть существующего контура DetMir.

Если в процессе работ обнаруживается новый сервис, неизвестная VM, новый
публичный endpoint, сторонний сервис или компонент без понятного владельца, он
сначала фиксируется как находка и риск. Постоянное сопровождение такого
компонента начинается только после подтверждения владельцем, что он включается
в контур поддержки.

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

## Состав поддерживаемого контура

- Узел виртуализации и размещенные на нем виртуальные машины или контейнеры.
- Web-сервер: HTTP/HTTPS-доступность, виртуальные хосты, TLS-сертификаты,
  reverse proxy, access/error logs и место под web-контент.
- Существующие прикладные сервисы и связанные файловые каталоги.
- Существующие базы данных и служебные хранилища, если они уже использовались
  до проекта AWatch-rus.
- Proxmox: состояние узла, VM/CT, storage, snapshots, backups, web-доступ.
- pfSense: firewall, NAT, маршрутизация, VLAN/interface status, DHCP, DNS,
  gateway monitoring, логи и правила доступа.
- OpenVPN: сервер, клиентские профили, сертификаты, маршруты, доступность
  подключений и контроль истекающих ключей.
- Suricata: состояние IDS/IPS, обновление правил, алерты, false positive,
  исключения и влияние блокировок на рабочий трафик.
- Сетевой контур: маршрутизация, VPN, firewall, DNS, DHCP, удаленный доступ.
- Системные сервисы Linux, планировщики задач и фоновые службы.
- Резервное копирование, журналы, учетные записи и права доступа.

## Ежедневные задачи

- Проверять доступность ключевых серверов и виртуальных машин.
- Проверять состояние узла виртуализации: нагрузка CPU/RAM, свободное место,
  состояние storage, отсутствие зависших VM/CT.
- Проверять Proxmox: состояние node, VM/CT, storage, backup jobs, snapshots и
  ошибки в task log.
- Проверять web-сервер: HTTP/HTTPS-ответ, корректность виртуальных хостов,
  срок действия TLS-сертификатов, ошибки 4xx/5xx и переполнение access/error
  logs.
- Проверять работоспособность прикладных сервисов: запуск, доступность,
  отсутствие явных ошибок в журналах.
- Проверять сетевую связность между основными узлами, VPN и удаленный доступ.
- Проверять состояние firewall/NAT/маршрутов, если были жалобы на доступ.
- Проверять pfSense: gateway status, interface status, DHCP leases,
  firewall/NAT rules, логи блокировок по жалобам на доступ.
- Проверять OpenVPN server и клиентов: активные подключения, маршруты,
  reachability внутренних сетей, ошибки TLS/auth/route push.
- Проверять Suricata: запущен ли сервис, нет ли массовых блокировок рабочего
  трафика, критичных алертов и переполнения логов.
- Проверять, что критичные systemd services, timers и cron jobs
  находятся в ожидаемом состоянии.
- Проверять наличие свежих резервных копий по базовым системам.
- Фиксировать найденные проблемы и выполненные действия в журнале поддержки.

## Еженедельные задачи

- Проверять свободное место на всех важных дисках и хранилищах.
- Проверять накопление старых логов, временных файлов, дампов и архивов.
- Проверять успешность резервного копирования за неделю.
- Проверять, что резервные копии реально читаются и доступны для восстановления.
- Проверять системные журналы Linux и web-сервера на повторяющиеся ошибки.
- Проверять web-сервер: рост 5xx, подозрительные запросы, устаревающие
  сертификаты, переполнение логов, доступность ключевых URL и корректность
  reverse proxy.
- Проверять pfSense и сетевые журналы: повторяющиеся блокировки, падение
  gateway, flapping интерфейсов, ошибки DNS/DHCP/VPN.
- Проверять OpenVPN: список активных клиентов, неиспользуемые профили,
  приближающиеся к истечению сертификаты, корректность клиентских маршрутов.
- Проверять Suricata alerts: отделять реальные риски от false positive,
  фиксировать исключения и изменения правил.
- Проверять состояние учетных записей, срок действия паролей, лишние
  административные доступы.
- Проверять стабильность VPN/удаленного доступа и отсутствие неожиданных
  открытых портов.
- Готовить короткий отчет владельцу: что проверено, что исправлено, какие
  риски остаются.

## Ежемесячные задачи

- Проводить контрольный тест восстановления из резервной копии на безопасном
  участке данных или тестовой копии.
- Проверять обновления ОС и прикладного ПО, отдельно выделяя безопасные и
  рискованные обновления.
- Планировать окно обслуживания для обновлений, перезагрузок и чистки.
- Проверять состояние сертификатов, доменных имен, VPN-профилей и учетных
  данных удаленного доступа.
- Проводить аудит firewall-правил, пробросов портов и внешне доступных
  сервисов.
- Проводить аудит web-сервера: виртуальные хосты, TLS-настройки, redirects,
  reverse proxy, права на каталоги, logrotate, backup web-конфигурации и
  отсутствие лишних публичных endpoints.
- Проводить аудит pfSense: WAN/LAN/VPN rules, NAT, aliases, floating rules,
  DHCP/DNS settings, gateway groups и резервную копию конфигурации.
- Проводить аудит OpenVPN: server mode, client-specific overrides,
  сертификаты, отозванные клиенты, push routes и доступы по пользователям.
- Проводить аудит Suricata: режим IDS/IPS, включенные rulesets, suppress list,
  pass/drop правила и влияние на критичные сервисы.
- Проводить аудит Proxmox: версии, состояние repositories, backup schedule,
  storage utilization, snapshots, права пользователей и доступ к web UI.
- Обновлять эксплуатационную документацию: IP-адреса, учетные записи без
  паролей, роли серверов, схемы доступа, процедуры восстановления.
- Проверять, что нет устаревших или неизвестных сервисов, запущенных без
  владельца и назначения.

## Результаты работ

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

Минимальные результаты:

- журнал выполненных проверок и изменений;
- отметка о ежедневной проверке базового состояния;
- еженедельный отчет владельцу с перечнем проверок, исправлений и рисков;
- краткий инцидентный отчет после серьезных сбоев;
- актуализация схемы доступа, списка серверов, VM/CT, сетевых сервисов и
  ответственных лиц при выявлении изменений;
- список открытых рисков и отложенных работ, которые требуют отдельного
  решения владельца.

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

## Инцидентные задачи

- Восстановление доступа к серверу, VM, web-серверу или прикладному сервису.
- Устранение нехватки места, памяти, зависших процессов и служб.
- Восстановление работы прикладных сервисов, файловых каталогов, баз данных
  или сетевых шар.
- Разбор web-инцидентов: недоступность HTTP/HTTPS, ошибки TLS, неверный
  redirect, поломка reverse proxy, массовые 4xx/5xx, переполнение логов или
  нехватка места под web-контент.
- Разбор проблем VPN, маршрутизации, DNS, firewall и удаленного доступа.
- Разбор и восстановление pfSense после ошибки правил, NAT, gateway, DHCP,
  DNS, interface/VLAN или некорректного firewall reload.
- Разбор и восстановление OpenVPN server/clients: TLS/auth ошибки, истекшие
  сертификаты, невыданные маршруты, недоступность внутренних сетей.
- Разбор Suricata-инцидентов: ложная блокировка рабочего трафика, всплеск
  алертов, обновление правил, отключение/исключение проблемной сигнатуры.
- Восстановление Proxmox VM/CT после зависания, нехватки storage, ошибки
  backup/snapshot или некорректного shutdown.
- Восстановление после неудачного обновления, сбоя питания или некорректной
  перезагрузки.
- Восстановление данных из резервной копии.
- Проверка подозрительной активности: неизвестные подключения, новые учетные
  записи, неожиданные открытые порты, странные timers или cron jobs.
- Подготовка краткого инцидентного отчета: причина, влияние, что сделано, что
  нужно изменить, чтобы сбой не повторился.

## Критичность заявок

- P1, полный простой: недоступен ключевой сервис, web-сервер, VM, VPN,
  firewall/gateway или хранилище, из-за чего пользователи не могут выполнять
  основную работу.
- P2, деградация: сервис работает частично, есть ошибки, падение
  производительности, нестабильность VPN/сети, переполнение диска или риск
  скорого отказа.
- P3, плановая заявка: настройка, проверка, обновление, добавление правила,
  выпуск сертификата, изменение доступа или регламентная работа без текущего
  простоя.
- P4, консультация и документация: уточнение схемы, подготовка инструкции,
  разбор логов без текущего влияния на работу, рекомендации владельцу.

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

## Правила выполнения работ

- Перед рискованными изменениями делать резервную копию конфигурации или
  snapshot, если это технически возможно.
- Перед изменениями pfSense/OpenVPN/Suricata сохранять текущий config backup и
  фиксировать путь отката.
- Перед изменениями Proxmox делать snapshot/backup для затронутой VM/CT, если
  это не ухудшает ситуацию и есть достаточно места.
- Не менять сетевые маршруты, firewall, VPN и удаленный доступ без понимания
  пути отката.
- Не устанавливать обновления на production без оценки риска и окна
  обслуживания.
- Не удалять старые данные и логи без проверки, что они не нужны для бизнеса
  или расследования.
- После каждого изменения проверять фактический результат: доступность сервиса,
  состояние VM, HTTP/HTTPS-ответ web-сервера, журнал ошибок, место на диске.
- Все изменения фиксировать: дата, сервер, действие, причина, результат,
  способ отката.

## Условия выполнения поддержки

Для нормального выполнения поддержки владелец должен предоставить и
поддерживать актуальными:

- административный доступ к Proxmox, pfSense, Linux-серверам, web-серверу,
  VPN и другим компонентам, входящим в контур;
- безопасный способ хранения и передачи учетных данных;
- контакт ответственного лица для согласования рискованных изменений;
- список критичных сервисов и допустимые окна обслуживания;
- сведения о провайдерах, доменах, сертификатах, внешних адресах и каналах
  связи;
- возможность получить физический доступ к оборудованию через сотрудника на
  месте, если удаленная диагностика недостаточна;
- подтверждение, какие сервисы являются основными, резервными или
  историческими.

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

## Минимальный SLA

- Плановая проверка: один раз в рабочий день.
- Реакция на P1, полный простой ключевого сервиса: начало диагностики в течение
  2-4 часов в рабочее время.
- Реакция на P2, частичная деградация: начало диагностики в течение рабочего
  дня.
- Реакция на P3/P4: планирование и выполнение по согласованию с владельцем.
- Еженедельный отчет владельцу.
- Плановые изменения только с резервной копией и проверкой результата.
- После каждого серьезного инцидента: краткий отчет и список мер против
  повторения.

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

## Что не входит в этот объем

- Разработка и сопровождение AWatch-rus как продукта.
- Новые ActivityWatch-коллекторы и новые telemetry pipelines.
- Новые Grafana-дашборды и управленческая аналитика AWatch-rus.
- Новые аналитические контуры, созданные специально под AWatch-rus.
- Коммерческая упаковка, roadmap, CI/CD и разработка новых модулей AWatch-rus.
- Покупка, поставка и замена оборудования, если это не оформлено отдельно.
- Оплата, продление и сопровождение лицензий, доменов, сертификатов и услуг
  провайдеров, если это требует отдельного договора или платежа.
- Физическая прокладка кабелей, монтаж СКС, электрика и работы в серверной,
  требующие присутствия монтажной организации.
- Полноценный аудит информационной безопасности, пентест, расследование
  инцидента ИБ и внедрение новых средств защиты сверх текущих pfSense,
  OpenVPN и Suricata.
- Разработка нового прикладного ПО, изменение бизнес-логики существующих
  систем и перенос данных между платформами.

Эти работы нужно оформлять отдельным приложением к поддержке, когда владелец
готов заказывать сопровождение уже разработанной системы AWatch-rus.