Установка завершилась. Что ещё проверить до промышленного трафика

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

Поэтому «установлено» и «готово к промышленной эксплуатации» — разные состояния. Их удобно разделить формальным чек-листом, чтобы команда не открывала трафик только из-за зелёного сообщения установщика.

Жив ли процесс и готов ли он работать

GET /healthz подтверждает, что процесс работает, и сообщает версию. GET /readyz агрегирует настроенные проверки готовности и возвращает 503, когда необходимая зависимость недоступна. Состав проб зависит от конфигурации, поэтому не сводите результат только к PostgreSQL. Для балансировщика важнее готовность: живой процесс без обязательной зависимости не способен нормально обслуживать рабочие запросы.

Проверьте обе пробы локально, затем через тот же обратный прокси и DNS, которыми будет пользоваться клиент. Локальный ответ на порту 8780 не доказывает корректность TLS, сертификата, маршрута или заголовков прокси. Зафиксируйте ожидаемый код, версию и время проверки.

Закройте административную поверхность

До открытия недоверенной сети закройте административную поверхность принудительной аутентификацией. Корпоративные механизмы OIDC, SAML и LDAP/AD доступны только при активном тарифном праве Enterprise; локальная аутентификация доступна на всех тарифах. Для организаций с IdP рекомендуемым промышленным вариантом остаётся OIDC. SAML и LDAP/AD реализованы, но перед эксплуатацией их нужно сквозно проверить с конкретным IdP или каталогом. Если принудительная аутентификация не настроена, режим заголовков разработки нельзя оставлять на нелокальном адресе. Это не косметическое предупреждение, а причина остановить запуск до исправления.

Задайте AIHUMMER_MASTER_KEY, чтобы секреты и BYOK-ключи были зашифрованы при хранении. Настройте входящий секрет для коннекторов. Ограничьте рискованные инструменты, выдайте базе для db_query доступ только на чтение и проверьте исходящие сетевые правила. TLS обычно завершается на обратном прокси перед шлюзом.

Проверьте именно свой сценарий

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

aihummer doctor различает проблемы и предупреждения. Отсутствие необязательного рантайма может быть предупреждением, пока функция не используется. Если ваш процесс зависит от него, тот же факт становится блокером. Критерий запуска определяется заявленным сценарием, а не только общим цветом панели.

Резервная копия должна восстанавливаться

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

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

Наблюдаемость для дежурного

Сигналы должны отвечать на вопросы: служба запущена? база готова? очередь доставки растёт? внешний канал отклоняет запросы? какой идентификатор корреляции искать? Где проходит граница между AiHummer и провайдером? Одного графика CPU недостаточно. Для каждого алерта запишите безопасное действие и способ подтвердить восстановление.

Проведите короткое упражнение: остановите тестовую базу, убедитесь в 503 от /readyz, посмотрите вывод status, doctor и журнал, затем восстановите соединение. Отдельно отключите необязательный модуль и проверьте, что оператор не путает его предупреждение с падением шлюза.

Предстартовый список

• /healthz возвращает ожидаемую версию, /readyz подтверждает базу.
• Публичный адрес доступен по TLS, а админский вход защищён.
• Мастер-ключ, входящий секрет и права внешних учётных записей настроены.
• Каждый нужный канал и модуль прошёл живой тест.
• Сквозной тест завершился, журнал не содержит необъяснённых ошибок.
• Резервная копия восстановлена вместе с ключом и медиа.
• Алерты имеют владельцев и действия.
• Откат отрепетирован до открытия трафика.

Не открывайте всё одновременно

Первый запуск проще контролировать волнами. Сначала ограниченный внутренний пользователь и один канал, затем небольшая группа, потом плановое расширение. Для каждой волны задайте критерии входа и остановки: допустимое число ошибок, длина очереди, время реакции дежурного. Это не обещание SLA, а локальный механизм принятия решения.

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

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

После решения «готово» оставьте окно наблюдения. Не вносите одновременно несвязанные изменения, сравнивайте фактические метрики с базовой линией и держите план возврата доступным дежурному. Первый рабочий день — продолжение проверки, а не момент, после которого чек-лист можно забыть.

Моделируемый сценарий решения о запуске

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

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

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

Перед внешним запуском повторите проверку из новой пользовательской сессии: сохранённый вход или локальный доступ администратора способен скрыть ошибку аутентификации, DNS либо маршрута. Сохраните только обезличенный результат. Отдельно подтвердите выход из системы и повторный вход через публичный адрес.

Основной путь опубликован в руководстве по установке, различие проб и предстартовый список — на странице systemd и проверок работоспособности, аппаратная база — в требованиях. Скопируйте подходящие пункты в инструкцию дежурного своей среды и назначьте дату пробного запуска.