MARKET: INVENTORY АППАРАТНОГО И ПРОГРАММНОГО ПАРКА Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по инвентаризации и compliance Последнее обновление: 09.09.2026 СТАТУС КОМПОНЕНТА Inventory — отдельный Market-модуль. Он не входит в Control Center Core. ЧТО МЫ НАСТРОИМ Инструкция описывает сбор и нормализацию данных о компьютерах, серверах, ОС, аппаратной конфигурации, сетевых параметрах, установленном ПО и состоянии управления. Отдельно рассматриваются freshness, история изменений, software compliance и безопасная remediation через Software Automation. МОДЕЛЬ ДАННЫХ Inventory Actual State может включать: - identity устройства; - аппаратные характеристики; - CPU/RAM/storage; - сетевые интерфейсы и адреса; - ОС и версия/build; - установленное ПО и версии; - состояние management/enrollment; - freshness; - историю изменений; - compliance state относительно Desired State. Точный набор полей зависит от версии/ОС/метода сбора. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Market | Inventory установлен и Healthy Targets | Определен разрешенный scope устройств Collection | [ТРЕБУЕТ УТОЧНЕНИЯ: agent/agentless/providers] Credentials | В Secret Store, если нужны Network | Только необходимые management flows Retention | Определена политика истории Privacy | Определено, какие данные допустимо собирать Automation | Требуется только для remediation, не для read-only inventory Права | Inventory read/manage по scope АРХИТЕКТУРА Endpoints/Servers | inventory collection | v Normalization → Device identity → Actual State → Freshness/History | v Desired software/policy | Compliance diff | optional approved remediation | Software Automation | Re-inventory ПЕРЕД НАЧАЛОМ 1. Определите, какие сети/устройства входят в scope. 2. Не запускайте широкое network discovery за пределами разрешенного диапазона. 3. Определите identity keys, чтобы не создавать дубли одного устройства. 4. Проверьте privacy/retention. 5. Подготовьте test group. 6. Не выдавайте Inventory credentials более широкие права, чем нужны для чтения фактов. Шаг 1. Установка модуля Установите Inventory через Market по документу 14. Проверьте: - signature; - compatibility; - collection providers; - permissions; - storage growth; - Health. Шаг 2. Выбор способа инвентаризации Откройте настройки Inventory [Уточнить название элемента интерфейса]. Выберите поддерживаемый метод: - agent; - agentless management transport; - импорт из поддерживаемого источника; - иной provider. [ТРЕБУЕТ УТОЧНЕНИЯ: точные providers по Windows/Linux]. Не предполагается автоматическое активное сканирование всей сети без явного задания scope. Шаг 3. Создание scope Определите targets через поддерживаемую модель: - конкретные hosts; - CIDR/network range, если discovery поддерживается и разрешен; - группу; - доменную/управляемую коллекцию; - импортированный список. Перед запуском preview должен показывать ожидаемый scope [ТРЕБУЕТ УТОЧНЕНИЯ: UI]. Риск: Слишком широкий scope увеличивает network load, объем данных и может включить системы, на которые нет административного разрешения. Rollback: Остановите schedule/discovery и сузьте scope. Уже собранные данные удаляются только по штатной retention/data deletion procedure. Шаг 4. Credentials Если collection требует credentials: 1. создайте secret reference; 2. назначьте минимальные read permissions; 3. ограничьте scope; 4. протестируйте один endpoint; 5. только затем используйте credential для группы. Не храните credentials в inventory notes/export. Шаг 5. Pilot inventory Выберите один Windows и/или Linux endpoint в зависимости от среды. Запустите Inventory Job. Ожидаемый результат: Создается Device/Asset с актуальным Actual State и freshness timestamp. Проверьте: - hostname/FQDN; - device identity; - ОС; - CPU/RAM; - storage; - network; - installed software; - management state. Шаг 6. Устранение дублей Если одно устройство появилось дважды: 1. сравните stable identity fields; 2. проверьте, не произошло ли переименование/reinstall; 3. используйте штатный merge/reconcile, если поддерживается; 4. не удаляйте одну запись до проверки history/relations. [ТРЕБУЕТ УТОЧНЕНИЯ: identity algorithm и merge semantics]. Шаг 7. Планирование расписания Настройте collection schedule с учетом: - размера парка; - bandwidth; - endpoint load; - database/storage growth; - необходимой freshness. Не задавайте максимально частый интервал без необходимости. [ТРЕБУЕТ УТОЧНЕНИЯ: минимальный interval, concurrency и rate limits]. Шаг 8. Freshness Inventory record должен четко показывать время последнего успешного сбора. Состояние старше принятого threshold следует считать Stale, а не текущим фактом. [ТРЕБУЕТ УТОЧНЕНИЯ: default freshness thresholds]. Перед remediation всегда обновляйте stale inventory. Шаг 9. Hardware inventory Проверьте доступные поля: - CPU model/count; - RAM; - disks/volumes; - NICs; - firmware/serial, если поддерживается и допустимо; - другие hardware facts. Используйте эти данные для capacity/asset management, но не считайте отсутствие поля доказательством отсутствия компонента, если provider его не собирает. Шаг 10. OS inventory Проверьте: - platform; - edition/distribution; - version/build; - architecture; - update/management state, если поддерживается. Шаг 11. Software inventory Для каждого endpoint Inventory должен нормализовать доступные сведения об установленном ПО: - product/package name; - version; - provider/source; - install state; - last seen/freshness. [ТРЕБУЕТ УТОЧНЕНИЯ: Windows/Linux package/software sources]. Шаг 12. История изменений Используйте history для выявления: - установленного/удаленного ПО; - изменения версий; - изменения hardware; - смены ОС; - изменения management state. Сопоставляйте изменения с Control Center Change/Audit, чтобы отличать управляемые операции от внешнего drift. Шаг 13. Desired Software State Если используется Software Inventory & Compliance: 1. создайте policy: какое ПО/версия должны быть на конкретном scope; 2. выполните preview; 3. сравните Desired и Actual; 4. получите compliant/non-compliant/unknown состояния [ТРЕБУЕТ УТОЧНЕНИЯ: exact statuses]. Не классифицируйте Stale endpoint как подтвержденно compliant. Шаг 14. Remediation Безопасная цепочка: Inventory Actual → Compliance diff → Change/Approval → Job → Software Automation → Re-inventory → новый Actual State. 1. Обновите inventory. 2. Выберите небольшую non-compliant pilot group. 3. Проверьте exact diff. 4. Создайте remediation Change. 5. Выполните Software Automation по документу 17. 6. Дождитесь Job. 7. Запустите re-inventory. 8. Подтвердите compliance. Риск: Автоматическая mass-remediation на ошибочном inventory/policy может изменить весь парк. Rollback: Остановите rollout, выполните поддерживаемый software/config rollback и re-inventory. Шаг 15. Экспорт и отчеты Если поддерживается экспорт: - выбирайте минимальный набор полей; - учитывайте device/user-related data privacy; - защищайте exported file; - не включайте credentials/secrets; - задавайте retention. [ТРЕБУЕТ УТОЧНЕНИЯ: export formats/report catalog]. Шаг 16. Удаление устройства из Inventory ПРЕДУПРЕЖДЕНИЕ: удаление inventory record не означает физическое удаление устройства и не должно автоматически запускать destructive action. Перед удалением: 1. проверьте, что устройство действительно decommissioned; 2. сохраните нужную историю/export; 3. проверьте связи с Automation/PXE/Domain Services; 4. используйте штатный archive/delete flow. [ТРЕБУЕТ УТОЧНЕНИЯ: archive vs delete и retention]. ПРОВЕРКА - [ ] collection scope разрешен; - [ ] credentials least privilege; - [ ] pilot successful; - [ ] device identity однозначна; - [ ] hardware facts доступны; - [ ] OS facts доступны; - [ ] software list доступен; - [ ] freshness отображается; - [ ] history работает; - [ ] duplicates обработаны; - [ ] schedule не перегружает сеть/DB; - [ ] compliance не доверяет stale data; - [ ] remediation идет через Change/Automation/Reinventory; - [ ] exports защищены; - [ ] Audit фиксирует изменения policy/scope. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение Device Stale | collection failed/offline | last seen/Job | восстановить connectivity и повторить collection Два одинаковых assets | identity mismatch/reinstall | stable IDs/history | штатный reconcile/merge ПО отображается неверно | provider normalization limitation | raw evidence/provider | уточнить source и обновить normalization/module Сеть перегружена inventory | слишком частый/широкий scan | schedule/network metrics | уменьшить concurrency/frequency/scope Remediation меняет лишние endpoints | policy scope ошибочен | target preview | остановить Change, сузить scope, rollback affected РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - разделяйте discovery и remediation; - используйте freshness как обязательный критерий доверия; - не сканируйте сети без разрешения; - применяйте least-privilege collection accounts; - сохраняйте history изменений; - отслеживайте duplicates; - планируйте storage growth Inventory; - mass remediation всегда начинайте с pilot; - после Automation обязательно выполняйте re-inventory. ИТОГ Inventory формирует нормализованный Actual State парка компьютеров и серверов, включая hardware, ОС, сеть и ПО. Freshness и history позволяют отличать актуальные факты от устаревших, а compliance/remediation выполняются безопасно через Change, Software Automation и обязательную повторную инвентаризацию. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - collection providers/agents; - supported Windows/Linux versions; - network discovery modes; - credential model; - identity/dedup algorithm; - freshness defaults; - schedule/concurrency/rate limits; - hardware/software field catalog; - compliance statuses; - export/report formats; - archive/delete retention; - privacy controls.