Tasks, события и аудит

Используйте Tasks, события и аудит вместе, чтобы понять ход операции, её инициатора и фактический результат для клиента. Task сообщает оператору, завершилась ли продолжительная работа. Событие помогает интерфейсу и автоматизации отреагировать на изменение состояния. Запись аудита показывает специалисту по безопасности, кто или что попыталось выполнить значимое действие. Ни один из этих источников сам по себе не доказывает клиентский результат.

Владелец ресурса решает, нужен ли повтор или откат, оператор сверяет состояние Task с фактической средой выполнения владельца, а владелец безопасности определяет сроки хранения и экспорт аудита. Связывайте записи стабильными идентификаторами ресурса, запроса, Task и операции.

Tasks представляют долговечную продолжительную работу: сборки, Deployments, миграции, импорты, подготовку ресурсов и обновления. Следите за состоянием, ходом выполнения, журналами, кодом ошибки и доступностью повтора или отмены. Не запускайте дубликат только потому, что браузер отключился.

События обновляют состояние интерфейса в реальном времени и запускают поддерживаемые операционные процессы. Потребители должны повторно проверять авторизацию и корректно обрабатывать повторное подключение и повторную доставку.

Записи аудита связывают значимые для безопасности и конфигурации действия с пользователями или системными субъектами. Блокировка или удаление пользователя не удаляет историческую атрибуцию. Экспортируйте записи в SIEM, если требуется независимое хранение или сопоставление событий.

Сведения аудита должны определять действие и ресурс, не сохраняя секреты, необработанные учётные данные, закрытые ключи, запросы или ответы моделей.

Жизненный цикл Task

Типичные состояния Task различают операции queued, running, waiting, succeeded, failed, cancelled и interrupted. Доступные состояния и действия зависят от операции. Ход выполнения — это данные от владеющего обработчика или демона, а не анимация браузера.

Запишите идентификатор Task до ухода со страницы продолжительной операции. После перезагрузки страница должна подключиться к долговечному состоянию, а не создать вторую операцию. Если ответ команды потерян, до повтора проверьте и Task, и владеющий ресурс.

Повтор, отмена и принудительная отмена

Повторяйте операцию, только если контракт Task помечает её как допускающую повтор или Reconciliation подтверждает, что предыдущая попытка достигла конечного состояния. Запрос Cancel выполняется совместно с владельцем, если тот поддерживает отмену. Force Cancel может прекратить ожидание заброшенной операции со стороны Opfield, но не доказывает, что базовое действие в среде выполнения не произошло.

После отмены или прерывания обновите состояние ресурса от его владельца и устраните отметку операции, прежде чем запускать следующее изменение.

События и состояние в реальном времени

События в реальном времени уменьшают задержку интерфейса, но не являются единственным источником истины. Клиенты должны учитывать разрыв соединения, повторную доставку, дубликаты и ситуацию, когда событие приходит до обновлённого снимка. После повторного подключения загрузите авторитетный снимок и объедините с ним более новые события по стабильной идентичности ресурса.

События, запускающие автоматизацию, должны заново проверять текущую авторизацию, владение, Entitlement и состояние жизненного цикла. Права, действовавшие при создании события, не разрешают более позднее изменение.

Интерпретация аудита

Запись аудита определяет субъекта, действие, ресурс, время, результат и относящийся к нему контекст запроса. Системные субъекты и субъекты автоматизации должны отличаться от пользовательских сеансов и Impersonation. Блокировка или удаление пользователя сохраняет историческую атрибуцию.

Аудит — не отладочный журнал. Для подробностей реализации используйте операционные журналы и Tasks, а аудит — для ответственности за безопасность и конфигурацию. Экспортируйте его в независимо управляемое хранилище SIEM, если данные должны пережить инцидент Opfield.

«Неизменяемая атрибуция» означает, что блокировка или удаление учётной записи не переписывает исторического инициатора в записи аудита. Это не означает, что локальная база аудита является WORM-хранилищем или криптографически защищена от человека, который управляет хостом Opfield, PostgreSQL, резервными копиями или ключами шифрования. Такие администраторы остаются внутри границы доверия.

Если политика требует доказательства, способного пережить компрометацию контура управления, непрерывно экспортируйте аудит в независимо администрируемую SIEM или WORM-совместимое хранилище. Ограничьте удаление на стороне назначения, синхронизируйте время и отслеживайте разрывы экспорта. Политику хранения и проверку доступа к внешнему хранилищу отделите от администрирования Opfield.

Чек-лист расследования

1. Определите ресурс и видимое клиенту последствие.
2. Найдите исходную запись аудита и идентификатор запроса.
3. Найдите долговечную Task или операцию.
4. Сравните желаемое состояние с текущим состоянием владельца.
5. Просмотрите ограниченный набор операционных журналов.
6. Зафиксируйте повтор, отмену, откат и итоговую проверку.

Интерпретация успеха и ошибки

Состояние Task succeeded означает, что рабочий процесс владельца достиг документированного конечного состояния. Оно не обязательно подтверждает распространение DNS, доступ внешнего клиента, корректность приложения, доставку письма, обработку вебхука или восстановление бизнес-данных. Добавьте независимую проверку, соответствующую ресурсу.

Состояние Task failed или interrupted не доказывает отсутствие побочного эффекта. До потери подтверждения владелец мог создать Container, записать файл, изменить данные у поставщика или завершить действие в среде выполнения. Перед очисткой или повтором прочитайте текущее состояние владельца и историю операции.

Состояние waiting должно указывать зависимость или необходимые входные данные. Если Task остаётся в waiting без понятного владельца, сохраните идентификаторы и передайте проблему на разбор, не используя Force Cancel как обычную очистку.

Сигнал расследования — состояние Task и видимое клиенту последствие. Сначала определите вероятный слой по владельцу операции, затем откройте страницу Task, проверьте её код ошибки и ограниченные журналы, сопоставьте запись аудита и обновите состояние ресурса от владельца. Безопасное следующее действие — независимая проверка результата, а повтор или откат допустимы только после подтверждения конечного состояния и возможных побочных эффектов.

Автоматическая очистка и хранение

Автоматическая очистка удаляет данные, которые Opfield больше не нужны, по умолчанию ежедневно в 02:00. Настройте её в Settings > Features > Housekeeping: housekeeping:view показывает настройки, статистику и историю запусков, housekeeping:run запускает очистку, а housekeeping:configure меняет категории и расписание. Каждую категорию можно отключить. Категория Audit Log по умолчанию хранит записи 90 дней; если политика требует более долгого хранения, экспортируйте записи аудита в SIEM.

Две категории, добавленные в 2.11, включены по умолчанию:

Категория	Что удаляет
Operation History	Завершённые Task контейнеров Docker через сутки. По истечении срока хранения, по умолчанию 90 дней: завершённые сборки вместе с журналами, пустые пакеты сборок, завершённые операции Compose, отказоустойчивости рабочих нагрузок и хостинга, а также доставки вебхуков источников Git. У каждого ресурса сохраняются 10 последних запусков, а записи, которые ещё что-то использует — артефакт сборки, размещение отказоустойчивости, снимок или происхождение ноды хостинга, — не удаляются
Expired OAuth Grants	Просроченные коды авторизации OAuth, токены доступа и обновления, а также клиенты OAuth без разрешений в течение 90 дней. Токен обновления хранится до истечения срока, чтобы его повторное использование по-прежнему обнаруживалось

Остальные категории охватывают журналы nginx, закрытые оповещения, доставки уведомлений, структурированные журналы, системные таблицы ClickHouse, неиспользуемые артефакты AI, внутренний реестр образов, неиспользуемые тома, выведенные из работы системные ключи PKI, файлы проверок ACME и старые образы Opfield.

Хранение и внешние свидетельства

Записи аудита не теряются при остановке Opfield. При завершении работы Opfield записывает ещё не сохранённые записи, прежде чем закрыть соединение с базой данных. Если база данных уже недоступна, как при выключении хоста, когда все контейнеры останавливаются одновременно, запись, которую не удаётся сохранить, добавляется в файл очереди на томе данных приложения (/var/lib/gateway/audit-spool) и сохраняется при следующем запуске со своим исходным идентификатором, поэтому прерванная на середине повторная загрузка никогда не добавляет запись дважды; экспорт в SIEM забирает сохранённые записи. Кроме того, новые установки останавливают PostgreSQL в режиме smart shutdown, который до 75 секунд ждёт, пока Opfield закроет свои соединения; существующие установки получают это при следующем пересоздании контейнера PostgreSQL.

Храните записи аудита согласно политике безопасности и соответствия требованиям. Экспортируйте их в независимо управляемое хранилище SIEM, если свидетельства должны пережить недоступность Opfield или компрометацию администратора. Для операционных журналов Task могут действовать другие сроки хранения и требования к чувствительности. Не добавляйте в аудит секреты или необработанные тела запросов только ради удобства отладки.

Передавая свидетельства в поддержку или другую команду, включайте время, стабильные идентификаторы, конечное состояние, очищенные сведения об ошибке и результат независимой проверки. Удаляйте учётные данные, внутреннюю топологию, клиентские данные, запросы, ответы моделей и неограниченные журналы.