Чек-лист готовности рабочей среды

Используйте этот чек-лист как запись решения о запуске, а не как список, который один оператор отмечает без обсуждения. Владелец сервиса определяет критичные бизнес-пути, владелец платформы подтверждает восстановление инфраструктуры, владелец безопасности согласует идентичности и публикацию, а владельцы приложений проверяют данные и откат. Назначьте ответственного за каждый раздел до проверки готовности.

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

Плоскость управления

• Канонический HTTPS-адрес, cookies, WebSockets и перенаправления OAuth работают.
• PostgreSQL, Redis, идентичность Relay, ключи шифрования и загруженные артефакты размещены в постоянном хранилище и резервируются.
• Relay владеет публичным 9443/tcp и восстанавливается после перезапуска.
• Лицензия активна, а необходимые права тарифного плана доступны.

Идентичность

• Настроены два независимых способа восстановления администратора.
• MFA и области групп проверены с реальными пользователями без административных прав.
• Учётные данные API, OAuth и MCP имеют минимальные права, владельца и порядок ротации.

Управляемые ноды

• Каждая роль сообщает ожидаемые возможности и канал обновлений.
• Проверены поведение при отключении, перезапуск демона, перезапуск ноды и повторное подключение.
• Межсетевые экраны разрешают только документированный трафик.
• Ноды хранилища имеют доступ к ghcr.io, а у ноды хранилища в LXC набор loop-устройств рассчитан на все управляемые экземпляры и одновременные резервные копирования.
• На нодах Docker, держащих аренду Availability, работает сторожевой процесс аренды, и они достигают каждого Relay.

Рабочие нагрузки и данные

• Проверены Deployment, проверка состояния, откат, журналы, резервное копирование и восстановление.
• Привязки управляемых баз данных переживают контролируемые перезапуски Opfield, Relay, демона, ноды и рабочей нагрузки.
• В конфигурации рабочей нагрузки нет учётных данных владельца базы.

Клиентский трафик

• Проверены DNS, продление TLS, перенос Ingress, режим обслуживания и сбой целевой службы.
• Уведомления и сообщения страницы состояния достигают нужных получателей.

Эксплуатация

• Инструкции обновления и отката имеют владельцев.
• Оповещения диска, сертификатов, баз данных, очередей, Relay и нод активны.
• Проведена тренировка инцидента без недокументированных изменений через командную оболочку.

Пакет свидетельств

Не одобряйте запуск только по визуальной проверке. Сохраните подтверждения для:

• версии установки и дайджестов образов;
• завершённой резервной копии и недавнего теста восстановления;
• внешней проверки DNS, TLS и HTTP;
• проверки прав без административной учётной записи;
• перезапуска и повторного подключения нод каждой используемой роли;
• поведения при перезапуске Opfield, Relay, демона и рабочей нагрузки;
• запросов через привязку базы данных до и после пересоздания;
• открытия и закрытия оповещения и доставки уведомлений;
• репетиции обновления и отката;
• неустранённых исключений с владельцем и сроком.

Используйте единый шаблон: дата и время UTC — ресурс или путь — выполненная проверка — результат — ссылка на Task, журнал или снимок — проверил — откат или исключение. Так подтверждение конкретного пути не смешивается с общим впечатлением о системе.

Барьер запуска

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

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

Наблюдение первого дня

После включения бизнес-трафика наблюдайте за Route, TLS, нагрузкой Relay, свежестью нод, перезапусками рабочих нагрузок, подключениями к базам данных, ростом диска, очередями уведомлений и аудитом. Владелец отката должен быть доступен всё окно наблюдения; несвязанные изменения платформы на это время остановите.

Формат проверки готовности

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

Начните с трёх путей с немедленным влиянием на бизнес: восстановление администратора, публичный клиентский трафик и доступ приложения к постоянным данным. Затем проверяйте сборки, Pages, уведомления, AI и необязательные интеграции, которые действительно включены. Неиспользуемая функция не блокирует запуск; включённая критичная функция без проверки — блокирует.

Минимальные приёмочные сценарии

1. Новый разрешённый пользователь входит, завершает MFA и получает отказ для ресурса вне своей области.
2. Поддерживаемая рабочая нагрузка развёртывается, наблюдается, перезапускается и откатывается без правок хоста.
3. Публичный Route проверяется из внешней сети с ожидаемым сертификатом и поведением проверки состояния.
4. Управляемая нода отключается и подключается без потери желаемого состояния.
5. Opfield перезапускается, а клиентские рабочие нагрузки сохраняют документированное состояние.
6. Резервная копия восстанавливается в чистой совместимой среде, а необходимые секреты расшифровываются.
7. При контролируемом сбое оповещение открывается и закрывается, а нужный получатель получает уведомление.

В решении о запуске укажите проверенную область. Не заявляйте готовность всего продукта, если испытана только одна роль ноды, один движок базы данных, один профиль среды выполнения или один путь обновления.