docs: narrow DetMir support scope
This commit is contained in:
+101
-84
@@ -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.
|
||||||
|
|||||||
Reference in New Issue
Block a user