MARKET: SOFTWARE AUTOMATION ДЛЯ WINDOWS И LINUX Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по автоматизации ПО и конфигурации Последнее обновление: 09.09.2026 СТАТУС КОМПОНЕНТА Software Automation — отдельный Market-модуль. Он не входит в Control Center Core. ЧТО МЫ НАСТРОИМ Инструкция описывает автоматизированную установку, обновление, удаление и приведение ПО/конфигурации к Desired State на Linux и Windows. Базовым provider-подходом является Ansible; архитектура допускает другие поддерживаемые providers. ТРАНСПОРТЫ Linux | SSH через безопасную аутентификацию и проверку host identity Windows | WinRM/PSRP согласно поддерживаемой защищенной конфигурации Другие | [ТРЕБУЕТ УТОЧНЕНИЯ: supported automation providers/transports] Не отключайте host verification, TLS, authentication или firewall ради «быстрого» подключения automation. ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ Требование | Значение Market | Software Automation установлен и Healthy Inventory | Целевые hosts однозначно идентифицированы Network | Transport доступен только из разрешенного management scope Credentials | В Secret Store/поддерживаемом credential mechanism Linux | SSH доступен и host identity подтверждена Windows | WinRM/PSRP настроен безопасно и разрешен политикой Artifacts | Package/playbook/config source проверен Backup | Для destructive config changes есть recovery point Права | Automation + target scopes АРХИТЕКТУРА Desired software/config | v Automation policy/playbook | preview/check + target scope | Change | Job | provider (Ansible/other) / \ SSH WinRM/PSRP | | Linux Windows \ / Actual State → Inventory/recheck ПЕРЕД НАЧАЛОМ 1. Подключите Inventory или создайте точный список targets. 2. Разделите группы: pilot, canary, staged rings, production. 3. Убедитесь, что credentials не находятся в playbook/plain text. 4. Определите rollback для package/config. 5. Ограничьте parallelism с учетом blast radius и Capacity Planner. 6. Не запускайте mass-remediation на stale Inventory. Шаг 1. Установка модуля Установите Software Automation через Market по документу 14. Проверьте: - signature; - compatibility; - provider support; - permissions; - network requirements; - Health. Шаг 2. Создание credential reference Откройте credential/secret management [Уточнить название элемента интерфейса]. Создайте credential reference для automation transport. ПРЕДУПРЕЖДЕНИЕ: Не вставляйте пароль/private key в playbook, Job description, Audit comment или открытый inventory field. [ТРЕБУЕТ УТОЧНЕНИЯ: Secret Store UI, credential types и rotation]. Шаг 3A. Подготовка Linux target Убедитесь, что Linux host: - разрешается по FQDN; - имеет корректный NTP; - доступен по поддерживаемому SSH transport; - имеет подтвержденный host key/fingerprint; - учетная запись имеет только необходимые privilege escalation permissions. Безопасная диагностическая проверка, если `ssh` доступен: ```bash ssh @ 'hostname && id' ``` Не используйте параметры, отключающие проверку host key. Ожидаемый результат: Подключение идет к ожидаемому host identity, команда возвращает hostname и identity без изменения системы. Шаг 3B. Подготовка Windows target Убедитесь, что Windows host: - разрешается по FQDN; - время синхронизировано; - WinRM/PSRP включен поддерживаемой административной политикой; - firewall разрешает только нужный management flow; - transport использует поддерживаемую authentication/TLS policy. Из PowerShell на административной станции можно проверить L3/TCP reachability к подтвержденному порту: ```powershell Test-NetConnection -ComputerName -Port ``` `` должен быть взят из фактической поддерживаемой конфигурации; не подставляйте случайный порт. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемая WinRM/PSRP authentication и TLS configuration]. Шаг 4. Создание inventory/group scope Создайте группу, например: - `pilot-linux`; - `pilot-windows`; - `production-ring-1`. Названия — пример организационной схемы, не обязательные системные идентификаторы. Проверьте список targets перед каждым массовым Change. Риск: Ошибка фильтра может расширить blast radius на весь парк. Rollback: До запуска Job отмените Change/исправьте scope. После применения используйте package/config rollback, а не просто удаление группы. Шаг 5. Добавление automation artifact Импортируйте playbook/package/config через [Уточнить название элемента интерфейса]. Проверьте: - source/provenance; - version/digest; - required variables; - secret references; - supported OS; - idempotency expectations; - rollback/compensation. Не храните в automation artifact реальные секреты. Шаг 6. Preview / dry-run Если provider поддерживает check/dry-run, используйте его перед mutation. [ТРЕБУЕТ УТОЧНЕНИЯ: как Control Center отображает Ansible check mode/preview]. Проверьте: - сколько hosts затронуто; - какие packages/config files/services изменятся; - будут ли reboot/restart; - ожидаемый downtime; - rollback. Не воспринимайте dry-run как абсолютную гарантию результата: некоторые действия невозможно полностью смоделировать без выполнения. Шаг 7. Pilot rollout 1. Выберите один или несколько некритичных pilot hosts. 2. Создайте Change. 3. Дождитесь Job. 4. Проверьте каждый target. 5. Выполните повторную Inventory/Actual State проверку. 6. Сравните Desired и Actual. 7. Только после success расширяйте rollout. Ожидаемый результат: Pilot hosts достигли Desired State, Inventory подтверждает фактическую версию/конфигурацию. Шаг 8. Staged rollout После pilot: 1. ring 1 — малая группа; 2. проверка failure rate/Health; 3. ring 2 — следующая группа; 4. повторная проверка; 5. production-wide только после стабильных rings. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемые batch size, concurrency и pause conditions]. ПРЕДУПРЕЖДЕНИЕ: Не запускайте обновление критического ПО одновременно на всех HA-узлах/контроллерах/репликах. Шаг 9. Установка ПО Automation action должен указывать: - package/software identity; - target version/channel; - targets; - dependencies; - reboot/restart policy; - validation. [ТРЕБУЕТ УТОЧНЕНИЯ: поддерживаемые package providers для Windows/Linux]. После установки Inventory должен подтвердить фактическую версию. Шаг 10. Обновление ПО 1. Зафиксируйте current version. 2. Проверьте compatibility. 3. Создайте rollback point/config backup. 4. Pilot. 5. Staged rollout. 6. Reinventory. 7. Закройте Change только после Actual verification. Шаг 11. Удаление ПО ПРЕДУПРЕЖДЕНИЕ: удаление package может удалить shared dependencies или данные приложения. Перед removal: - проверьте зависимости; - определите data retention; - сделайте backup; - pilot на одном target; - используйте штатный uninstall provider. Не используйте произвольный shell command в Web UI вместо typed automation action, если поддерживаемый provider/action существует. Шаг 12. Конфигурационный Desired State Для configuration management: 1. зафиксируйте желаемое значение; 2. выполните preview/diff; 3. примените на pilot; 4. проверьте service health; 5. выполните staged rollout; 6. reinventory/recheck; 7. отслеживайте drift. Если внешний администратор вручную изменил конфигурацию, сначала выясните причину drift, затем выбирайте remediation. Шаг 13. Rollback Что изменится: Rollback возвращает package/config к заранее определенному безопасному состоянию, если это поддерживается. Риск: Downgrade package/data format может быть несовместим. Порядок: 1. остановите rollout; 2. определите затронутые hosts; 3. сохраните failure evidence; 4. примените поддерживаемый package/config rollback на pilot failed host; 5. проверьте service/data; 6. распространите rollback только на реально затронутые targets; 7. reinventory. [ТРЕБУЕТ УТОЧНЕНИЯ: provider-specific rollback semantics]. Шаг 14. Credentials rotation При смене automation credential: 1. добавьте новый credential; 2. проверьте pilot connection; 3. обновите references; 4. подтвердите Jobs; 5. только затем отзовите старый credential; 6. проверьте Audit. Не удаляйте старый credential до подтверждения нового management path. ПРОВЕРКА - [ ] targets имеют свежий Inventory; - [ ] transport защищен; - [ ] host identity проверяется; - [ ] secrets хранятся через Secret Store/reference; - [ ] preview выполнен; - [ ] blast radius проверен; - [ ] pilot успешен; - [ ] staged rollout используется; - [ ] rollback определен; - [ ] Inventory подтверждает Actual State; - [ ] drift анализируется; - [ ] Audit содержит Change/Job. ТИПОВЫЕ ОШИБКИ Симптом | Причина | Проверка | Решение Linux SSH denied | credential/host key/network/sudo | connection evidence | исправить конкретный trust/access issue, не отключать host verification Windows unreachable | WinRM/PSRP/firewall/DNS | Test-NetConnection/transport evidence | восстановить защищенный management path Job затронул лишние hosts | неверный group/filter | target list/Audit | остановить rollout; оценить изменения; rollback только affected hosts Package установлен, Inventory старый | reinventory не выполнен/stale | freshness | обновить inventory и подтвердить Actual Mass rollout ломает service | не было pilot/staged | Change history | остановить rollout; rollback; восстановить через меньшие rings РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - используйте dedicated automation identities; - храните credentials в Secret Store; - не отключайте SSH host key/TLS protections; - применяйте least privilege; - всегда preview target list; - используйте pilot и staged rollout; - ограничивайте concurrency; - для критических систем обновляйте replicas последовательно; - после каждого rollout делайте reinventory; - рассматривайте Inventory как подтверждение фактического результата, а не только Job status. ИТОГ Software Automation безопасно приводит Windows/Linux парк к Desired State через контролируемые providers, защищенные transports, secrets, preview, Change/Job, pilot и staged rollout. Финальным доказательством успеха является повторная проверка Actual State/Inventory, а не только завершение automation Job. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - supported Ansible version/provider model; - other providers; - Linux SSH bootstrap/host-key handling; - Windows WinRM/PSRP ports/auth/TLS; - Secret Store UI/types; - package providers; - check/dry-run support; - concurrency/rings; - reboot/restart policy; - rollback semantics; - exact Inventory integration.