AWatch-rus/docs/DETMIR_SUPPORT_TASKS_RU.md

Задачи поддержки базового комплекса 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.