docs: narrow DetMir support scope

This commit is contained in:
igor04091968
2026-06-17 23:06:14 +03:00
parent b7209771f6
commit 371a1e2728
+101 -84
View File
@@ -1,109 +1,126 @@
# Задачи поддержки комплекса DetMir # Задачи поддержки базового комплекса DetMir
Документ описывает регулярные и инцидентные работы, которые должны входить в Документ описывает задачи сопровождения того комплекса серверов,
сопровождение производственного комплекса DetMir на базе AWatch-rus, виртуализации, сетевых сервисов и прикладного ПО, который существовал до
ActivityWatch, Windows/RDP-коллекторов, Grafana, ClickHouse, 1C-аналитики и начала разработки AWatch-rus.
операторского gateway.
AWatch-rus, ActivityWatch-коллекторы, новые дашборды, новые контуры
телеметрии, ClickHouse-аналитика AWatch-rus и разработка продукта в этот
объем не входят. Их нужно оформлять отдельной следующей задачей.
## Цель поддержки ## Цель поддержки
Поддержка должна обеспечивать не формальное состояние сервисов `active`, а Поддержка должна обеспечивать штатную работу базовой ИТ-инфраструктуры
доказуемую работоспособность всего контура: свежие данные в bucket'ах, DetMir: серверы доступны, виртуальные машины запущены, пользователи могут
корректные отчеты для владельца, рабочие дашборды, доступность gateway, работать через RDP и прикладное ПО, данные сохраняются, резервные копии
исправные Windows-задачи и отсутствие накопленных очередей. создаются, удаленный доступ контролируется, а аварии устраняются с понятной
фиксацией причины.
## Состав поддерживаемого контура
- Узел виртуализации и размещенные на нем виртуальные машины или контейнеры.
- Windows/RDP-серверы и пользовательские рабочие сессии.
- Существующие прикладные сервисы, включая 1C и связанные файловые каталоги.
- Существующие базы данных и служебные хранилища, если они уже использовались
до проекта AWatch-rus.
- Сетевой контур: маршрутизация, VPN, firewall, DNS, DHCP, удаленный доступ.
- Системные сервисы Linux/Windows, планировщики задач и фоновые службы.
- Резервное копирование, журналы, учетные записи и права доступа.
## Ежедневные задачи ## Ежедневные задачи
- Проверять свежесть данных ActivityWatch: AFK, window, worktime sessions, - Проверять доступность ключевых серверов и виртуальных машин.
web category, DLP endpoint signals, file operations, email, collector guard. - Проверять состояние узла виртуализации: нагрузка CPU/RAM, свободное место,
- Проверять состояние RDP-хоста `SHARKON2025`: активные и отключенные сессии, состояние storage, отсутствие зависших VM/CT.
зависшие PowerShell-процессы, дубли `aw-watcher-*`, process storm. - Проверять доступность RDP и возможность входа пользователей.
- Проверять Windows-задачи и сервисы: - Проверять состояние Windows-сервера: свободная память, диск, pagefile,
`AWatchRusCollectorGuard`, `ActivityWatch Recovery`, критические ошибки в журналах, зависшие процессы.
`ActivityWatch Launch [...]`, `ActivityWatch File1C Upload`, - Проверять работоспособность 1C и связанных сервисов: запуск, доступность,
`ActivityWatch DLP Evidence Sync`, `ActivityWatch Hayabusa Upload`. отсутствие явных ошибок в журналах.
- Проверять доступность AW server, worktime API, Grafana, gateway, - Проверять сетевую связность между основными узлами, VPN и удаленный доступ.
1C manager brief/actions/recovery. - Проверять состояние firewall/NAT/маршрутов, если были жалобы на доступ.
- Проверять ClickHouse-контур: состояние Docker-контейнера, healthcheck, - Проверять, что критичные systemd services, Windows services и scheduled tasks
сетевую доступность с AW-сервера, ingest timer, свежесть данных. находятся в ожидаемом состоянии.
- Проверять ошибки в логах collector guard, browser collector, DLP, - Проверять наличие свежих резервных копий по базовым системам.
file operations, File1C upload, DLP evidence sync и Hayabusa upload. - Фиксировать найденные проблемы и выполненные действия в журнале поддержки.
- Реагировать на `STALE`/`DEAD` bucket'ы точечно: перезапускать конкретный
collector, scheduled task или guard, а не выполнять массовые рестарты без
диагностики.
- Проверять, что owner-facing ссылки через gateway открываются штатно и не
требуют доступа к внутренним портам.
## Еженедельные задачи ## Еженедельные задачи
- Готовить короткий отчет владельцу: что работало, что ломалось, какие периоды - Проверять свободное место на всех важных дисках и хранилищах.
данных неполные, что было исправлено. - Проверять накопление старых логов, временных файлов, дампов и архивов.
- Проверять основные Grafana-дашборды и корректность отображения сотрудников. - Проверять успешность резервного копирования за неделю.
- Контролировать отсутствие дублей пользователей в отчетах: `USER5/user5`, - Проверять, что резервные копии реально читаются и доступны для восстановления.
машинные аккаунты, битая кодировка, неверная кириллица. - Проверять системные журналы Linux/Windows на повторяющиеся ошибки.
- Проверять накопление файлов в drop/inbox зонах Hayabusa, File1C и ClickHouse. - Проверять состояние учетных записей, срок действия паролей, лишние
- Проверять свободное место, память, pagefile, Docker, nginx, systemd timers и административные доступы.
журналы ошибок на серверной стороне. - Проверять стабильность VPN/удаленного доступа и отсутствие неожиданных
- Проверять, что scheduled tasks имеют ожидаемые интервалы запуска и последние открытых портов.
результаты без ошибок. - Готовить короткий отчет владельцу: что проверено, что исправлено, какие
- Просматривать небольшие исправления и обновления, которые можно применить без риски остаются.
риска простоя.
## Ежемесячные задачи ## Ежемесячные задачи
- Проверять резервные копии Grafana DB, ClickHouse-конфигов и данных, - Проводить контрольный тест восстановления из резервной копии на безопасном
ActivityWatch-конфигов, Windows deployment config, SSH-ключей и gateway участке данных или тестовой копии.
credentials. - Проверять обновления ОС и прикладного ПО, отдельно выделяя безопасные и
- Проводить контрольное восстановление ключевых частей контура: AW server, рискованные обновления.
gateway, Grafana, ClickHouse ingest, Windows collectors. - Планировать окно обслуживания для обновлений, перезагрузок и чистки.
- Выполнять аудит доступов: Basic Auth, SSH, WinRM, открытые порты, - Проверять состояние сертификатов, доменных имен, VPN-профилей и учетных
сертификаты, firewall. данных удаленного доступа.
- Обновлять эксплуатационную документацию: IP-адреса, сервисы, task names, - Проводить аудит firewall-правил, пробросов портов и внешне доступных
owner-facing ссылки, команды восстановления. сервисов.
- Проверять качество перед изменениями: Ansible syntax-check, PowerShell parse, - Обновлять эксплуатационную документацию: IP-адреса, учетные записи без
Rust tests/build для затронутых компонентов. паролей, роли серверов, схемы доступа, процедуры восстановления.
- Проверять, что нет устаревших или неизвестных сервисов, запущенных без
владельца и назначения.
## Инцидентные задачи ## Инцидентные задачи
- Восстанавливать сбор данных после остановки collector'ов или Windows-задач. - Восстановление доступа к серверу, VM, RDP или прикладному сервису.
- Лечить зависшие RDP-сессии, stale watcher bucket'ы и дубли процессов. - Устранение нехватки места, памяти, pagefile, зависших процессов и служб.
- Перезапускать или пересоздавать конкретные Windows scheduled tasks. - Восстановление работы 1C, файловых каталогов, баз данных или сетевых шар.
- Устранять process storm, нехватку памяти и проблемы pagefile. - Разбор проблем VPN, маршрутизации, DNS, firewall и удаленного доступа.
- Восстанавливать DLP endpoint signals и DLP evidence sync. - Восстановление после неудачного обновления, сбоя питания или некорректной
- Восстанавливать File1C upload, server ingest и ClickHouse health. перезагрузки.
- Восстанавливать Hayabusa EVTX upload, drop processing и очереди intake. - Восстановление данных из резервной копии.
- Исправлять Grafana-дашборды, gateway routes и права доступа. - Проверка подозрительной активности: неизвестные подключения, новые учетные
- Проводить ручную валидацию после аварии: bucket freshness, отчеты, записи, неожиданные открытые порты, странные scheduled tasks.
gateway/Grafana HTTP-коды и отсутствие новых ошибок в логах. - Подготовка краткого инцидентного отчета: причина, влияние, что сделано, что
нужно изменить, чтобы сбой не повторился.
## Изменения и развитие ## Правила выполнения работ
- Все изменения выполнять по схеме backup-first. - Перед рискованными изменениями делать резервную копию конфигурации или
- Перед деплоем проверять синтаксис, тесты и применимость к текущему окружению. snapshot, если это технически возможно.
- После деплоя проверять живые endpoints, timers, bucket freshness и - Не менять сетевые маршруты, firewall, VPN и удаленный доступ без понимания
owner-facing дашборды. пути отката.
- Не переписывать стабильные компоненты без причины; новые сервисные утилиты - Не устанавливать обновления на production без оценки риска и окна
делать автономными, systemd-friendly и с явными timeout'ами. обслуживания.
- Вести журнал изменений: что изменено, причина, дата, как проверить и как - Не удалять старые данные и логи без проверки, что они не нужны для бизнеса
откатить. или расследования.
- После каждого изменения проверять фактический результат: доступность сервиса,
вход пользователя, состояние VM, журнал ошибок, место на диске.
- Все изменения фиксировать: дата, сервер, действие, причина, результат,
способ отката.
## Минимальный SLA ## Минимальный SLA
- Плановый контроль: один раз в рабочий день. - Плановая проверка: один раз в рабочий день.
- Реакция на критичный сбой сбора данных: в течение 2-4 часов. - Реакция на полный простой ключевого сервиса: в течение 2-4 часов.
- Реакция на частичную деградацию: в течение рабочего дня.
- Еженедельный отчет владельцу. - Еженедельный отчет владельцу.
- Плановые изменения только с резервной копией и проверкой результата. - Плановые изменения только с резервной копией и проверкой результата.
- После каждого инцидента: краткое описание причины, выполненных действий и - После каждого серьезного инцидента: краткий отчет и список мер против
мер против повторения. повторения.
## Критерии приемки поддержки ## Что не входит в этот объем
- Все ключевые bucket'ы свежие или по каждому stale/dead bucket есть объяснение - Разработка и сопровождение AWatch-rus как продукта.
и план восстановления. - Новые ActivityWatch-коллекторы и новые telemetry pipelines.
- Владелец видит отчеты через защищенный gateway, без доступа к внутренним - Новые Grafana-дашборды и управленческая аналитика AWatch-rus.
техническим портам. - Новые ClickHouse/1C-аналитические контуры, созданные специально под
- Windows/RDP collector'ы работают в правильных пользовательских сессиях. AWatch-rus.
- ClickHouse, File1C, DLP и Hayabusa не имеют накопленных необработанных - Коммерческая упаковка, roadmap, CI/CD и разработка новых модулей AWatch-rus.
очередей.
- Любое исправление подтверждается командой проверки, логом или HTTP-кодом, а Эти работы нужно оформлять отдельным приложением к поддержке, когда владелец
не только статусом systemd/Task Scheduler. готов заказывать сопровождение уже разработанной системы AWatch-rus.