CONTROL CENTER CORE — DESIRED STATE, ACTUAL STATE, CHANGES И JOBS Продукт: Control Center Версия: [ТРЕБУЕТ УТОЧНЕНИЯ: VERSION] Тип документа: Руководство по базовой модели эксплуатации Последнее обновление: 09.09.2026 ЧТО МЫ НАСТРОИМ Документ объясняет основную модель Control Center Core: как задается требуемое состояние, как фиксируется фактическое состояние, как система выявляет расхождения и как безопасно исполняются изменения. АРХИТЕКТУРА Основной эксплуатационный поток: Администратор | v Desired State / Intent | v Diff / Validation | v Change | v Job / Typed Action | v Managed Node / Service | v Actual State + Health | +----> Audit / Events КЛЮЧЕВЫЕ ТЕРМИНЫ Термин | Значение Desired State | состояние, которое администратор хочет получить Actual State | состояние, фактически обнаруженное на управляемом объекте Drift | расхождение Desired и Actual State Change | контролируемая операция изменения с контекстом, diff и состоянием выполнения Job | техническое выполнение Change или его части Health | нормализованная оценка работоспособности и freshness Audit | неизменяемая/append-oriented история административных действий Typed Action | заранее определенное допустимое действие вместо произвольного скрытого shell ПРИНЦИПЫ 1. Control Center не должен считать форму Web UI источником истины. Сервер повторно проверяет права и входные данные. 2. Опасная mutation не должна выполняться напрямую без Change/Job-контекста. 3. Успешный Job не равен успешному результату, пока Actual State и Health не подтверждают ожидаемое состояние. 4. Если Actual State неизвестен или устарел, система должна явно показывать freshness/неопределенность, а не выдавать старые данные за текущие. 5. Повторное выполнение опасной операции должно учитывать idempotency и текущую revision. ПЕРЕД НАЧАЛОМ Перед любым значимым изменением: - убедитесь, что объект находится в актуальном Healthy/known состоянии; - проверьте свежесть Actual State; - убедитесь, что нет конфликтующего незавершенного Change; - проверьте текущую revision/ETag, если она отображается; - для сетевых, кластерных и data-changing операций подготовьте rollback/backup. Шаг 1. Открытие объекта Откройте управляемый ресурс в [Уточнить название элемента интерфейса]. Проверьте минимум: - идентификатор/имя объекта; - тип ресурса; - узел-владелец или placement; - Desired State; - Actual State; - Health; - freshness/время последней проверки; - последние Changes/Jobs. Ожидаемый результат: Вы видите однозначно определенный объект и можете отличить желаемую конфигурацию от фактически обнаруженной. Шаг 2. Формирование изменения Desired State 1. Откройте изменение конфигурации [Уточнить название элемента интерфейса]. 2. Измените только необходимые параметры. 3. Запросите preview/diff. 4. Проверьте старое и новое значение. 5. Оцените риск и blast radius. 6. Если операция затрагивает сеть/данные/HA, проверьте recovery plan. Не подтверждайте Change, если diff содержит параметры, которые вы не намеревались менять. Шаг 3. Проверка revision/conflict Control Center использует модель явной revision/конкурентного изменения. Если другой администратор успел изменить объект, старая форма не должна молча перезаписать новое состояние. Ожидаемый результат: При конфликте revision изменение отклоняется или требует повторного просмотра актуального diff. Действие при конфликте: 1. перечитайте Actual/Desired State; 2. изучите последний Change; 3. сформируйте новую конфигурацию на свежей revision; 4. повторно проверьте diff. Шаг 4. Создание Change После проверки preview подтвердите операцию. Ожидаемый результат: Control Center создает Change с уникальным идентификатором, фиксирует пользователя, исходную revision, цель, risk/metadata и переводит операцию в штатный lifecycle. [ТРЕБУЕТ УТОЧНЕНИЯ: точные состояния Change текущего релиза и названия кнопок]. Проверка: Откройте Change и убедитесь, что видите ожидаемый diff и целевой объект. Шаг 5. Выполнение Job Если Change требует исполнения, Control Center создает Job/Jobs и направляет только зарегистрированные typed actions соответствующему worker/node runtime. Не используйте внешние произвольные команды для «доделывания» незавершенного Change, если штатная процедура recovery еще доступна: это разрывает Desired/Actual/Audit цепочку. Ожидаемый результат: Job переходит по штатным состояниям и предоставляет progress/evidence. [ТРЕБУЕТ УТОЧНЕНИЯ: точный каталог состояний Job и вид progress UI]. Шаг 6. Проверка Actual State После завершения Job дождитесь повторного обнаружения фактического состояния. Проверьте: - Actual State совпадает с Desired State; - Health = Healthy или другой ожидаемый нормальный статус; - freshness обновлена после операции; - нет нового drift; - evidence относится к текущему Job. Критически важно: Статус Job «успешно» без подтверждения Actual State не является достаточным основанием считать изменение завершенным. Шаг 7. Работа с drift При обнаружении расхождения: 1. определите, является ли drift внешним ручным изменением, частичным отказом Job, задержкой discovery или допустимым отклонением; 2. не запускайте массовую remediation, пока причина неизвестна; 3. просмотрите последнее известное корректное состояние; 4. выберите: вернуть Actual к Desired либо осознанно изменить Desired; 5. сформируйте новый Change. Риск: Автоматическое «исправление» неизвестного drift может перезаписать аварийное ручное изменение или усугубить отказ. Rollback: Создавайте обратный Change или используйте поддерживаемую recovery-процедуру; не редактируйте внутреннее состояние Control Center напрямую. Шаг 8. Failed/Partial Change Если Job завершился ошибкой: 1. остановите дальнейшие зависимые изменения; 2. прочитайте error/evidence; 3. проверьте Actual State — часть операции могла уже примениться; 4. определите безопасный rollback/compensation; 5. выполните восстановление штатной операцией; 6. подтвердите итог повторным discovery/Health. Ожидаемый результат: После recovery система снова имеет однозначные Desired/Actual State и понятный Audit trail. ПРОВЕРКА ПОСЛЕ НАСТРОЙКИ/ИЗМЕНЕНИЯ - [ ] выбран правильный ресурс; - [ ] Desired State соответствует намерению; - [ ] diff проверен; - [ ] revision актуальна; - [ ] Change создан один раз; - [ ] Job относится к нужному Change; - [ ] Actual State обновлен после Job; - [ ] Desired и Actual совпадают либо известное отклонение документировано; - [ ] Health ожидаемый; - [ ] Audit содержит действие; - [ ] нет незавершенных зависимых Jobs. ТИПОВЫЕ ОШИБКИ Симптом | Возможная причина | Проверка | Решение Change отклонен конфликтом | устаревшая revision | перечитать объект и последний Change | сформировать новый diff на свежем состоянии Job успешен, но drift остается | действие не дало требуемого результата или discovery устарел | Actual State/freshness/evidence | обновить discovery, затем расследовать причину Actual State Unknown/Stale | узел недоступен или источник не обновился | Health/connectivity/freshness | восстановить наблюдаемость; не выполнять опасную remediation вслепую Job Failed | typed action вернул ошибку | evidence/log correlation | исправить причину и выполнить штатный retry/recovery Два администратора меняют один объект | конкурентные Changes | revision/Audit | завершить/отменить конфликтующие операции и пересобрать Change РЕКОМЕНДАЦИИ ДЛЯ PRODUCTION - используйте Change/Job для любых значимых mutations; - привязывайте аварийные действия к Audit и последующей reconciliation; - контролируйте freshness Actual State; - не создавайте автоматическую remediation без ограничений blast radius; - используйте staged rollout для массовых изменений; - критические Changes предваряйте backup/recovery point; - регулярно анализируйте drift как индикатор неконтролируемых ручных изменений или неисправности automation. ИТОГ Desired State описывает намерение администратора, Actual State — фактическую инфраструктуру. Надежная эксплуатация Control Center строится на проверяемом переходе через Change и Job с последующим подтверждением Actual State, Health и Audit. ТРЕБУЕТ УТОЧНЕНИЯ ПЕРЕД ПУБЛИКАЦИЕЙ - VERSION; - точные названия экранов Resource/Change/Job; - полный state machine Change; - полный state machine Job; - правила approval по risk-классам; - точные freshness thresholds; - поддерживаемые варианты retry/cancel/compensation.